作者丨David Eastman

編譯丨諾亞

出品 | 51CTO技術(shù)棧（微信號：blog51cto）

盡管沒有任何大型語言模型（LLM）騎過自行車，但它們顯然理解騎行在人類交通領(lǐng)域中的作用。它們似乎為軟件開發(fā)者提供的是一種類似語義的現(xiàn)實世界知識，結(jié)合了對技術(shù)世界的理解。我們在最近的一篇文章中清楚地看到了這一點，僅通過用自然語言描述，我們就能夠生成一個簡單的圖書出版SQL架構(gòu)。

雖然我對Llama 3創(chuàng)建架構(gòu)的性能感到滿意，但我之前在Oracle工作時期的一位同事指出，圖書出版架構(gòu)是一個相當(dāng)為人熟知的例子。為了便于理解，這自然是件好事，但為了進一步拓展LLM的能力，本文中我將探索大型語言模型根據(jù)英語描述的問題調(diào)整其自身架構(gòu)的能力如何。這一次，我將使用OpenAI的GPT-4o，因為它最近在代碼審查方面為我提供了很好的幫助。

作為出發(fā)點，我們將從與第一篇文章中相同的問題開始，并總結(jié)答案，這個答案與上次相似。這一次，GPT-4o不僅為我們提供了一個ERD（實體關(guān)系圖），還很好地解釋了各實體間的關(guān)系：

圖片

和之前的嘗試類似，它提出了以下這樣的架構(gòu)：

CREATE TABLE Author ( 
 author_id INT AUTO_INCREMENT PRIMARY KEY, 
 first_name VARCHAR(50), 
 last_name VARCHAR(50), 
 birth_date DATE, 
 nationality VARCHAR(50) 
); 
 
CREATE TABLE Publisher ( 
 publisher_id INT AUTO_INCREMENT PRIMARY KEY, 
 name VARCHAR(100), 
 address VARCHAR(255), 
 contact_number VARCHAR(20), 
 email VARCHAR(100) 
); 
 
CREATE TABLE Book ( 
 book_id INT AUTO_INCREMENT PRIMARY KEY, 
 title VARCHAR(100), 
 genre VARCHAR(50), 
 publication_date DATE, 
 isbn VARCHAR(20) UNIQUE, 
 author_id INT, 
 publisher_id INT, 
 FOREIGN KEY (author_id) REFERENCES Author(author_id), 
 FOREIGN KEY (publisher_id) REFERENCES Publisher(publisher_id) 
);

我更傾向于讓表名使用所包含對象的復(fù)數(shù)形式，我認(rèn)為這是被廣泛接受的標(biāo)準(zhǔn)。

大型語言模型指出了這些關(guān)系限制：

圖片

因此，使用上次相同的示例數(shù)據(jù)，讓我們在SQL沙盒環(huán)境DB Fiddle中檢查是否能得到相同的結(jié)果。

如果我們填充這些數(shù)據(jù)并添加上次的視圖……

INSERT INTO Author (first_name, last_name, birth_date) 
VALUES ('Iain', 'Banks', '1954-02-16'); 
 
INSERT INTO Author (first_name, last_name, birth_date) 
VALUES ('Iain', 'M Banks', '1954-02-16'); 
 
INSERT INTO Publisher (name, address) 
VALUES ('Abacus', 'London'); 
 
INSERT INTO Publisher (name, address) 
VALUES ('Orbit', 'New York');
 
INSERT INTO Book (title, author_id, publisher_id, publication_date)
VALUES ('Consider Phlebas', 2, 2, '1988-04-14');
 
INSERT INTO Book (title, author_id, publisher_id, publication_date)
VALUES ('The Wasp Factory', 1, 1, '1984-02-15');
 
CREATE VIEW ViewableBooks AS
SELECT Book.title 'Book', Author.first_name 'Author firstname', Author.last_name 'Author surname', Publisher.name 'Publisher', Book.publication_date
FROM Book, Publisher, Author
WHERE Book.author_id = Author.author_id
AND Book.publisher_id = Publisher.publisher_id;

我們就能在下方的表格中從DB Fiddle獲得所需的結(jié)果視圖：

圖片

第二個姓氏中包含了中間名“M”，看起來有些別扭。接下來，我們將探討與此相關(guān)的問題。

1.首次修改

正如我在前一篇關(guān)于SQL生成的文章中提到的，“Ian Banks”和“Ian M Banks”實際上是同一位作者。上次，我們沒有解決這個筆名問題。所以，讓我們要求大模型來修復(fù)這個問題：

圖片

所以這是個好的開始。這次它需要將“筆名”這一文學(xué)概念映射到它已經(jīng)產(chǎn)生的現(xiàn)有架構(gòu)設(shè)計上。因此，它不僅要發(fā)現(xiàn)現(xiàn)有的解決方案，還必須做更多的工作。首先，我們來看看新建立的關(guān)系：

圖片

這看起來是合理的。以下是經(jīng)過修改的新表結(jié)構(gòu)：

CREATE TABLE Pseudonym ( 
 pseudonym_id INT AUTO_INCREMENT PRIMARY KEY, 
 pseudonym VARCHAR(100), 
 author_id INT, 
 FOREIGN KEY (author_id) 
 REFERENCES Author(author_id) 
); 
 
CREATE TABLE Book ( 
 book_id INT AUTO_INCREMENT PRIMARY KEY, 
 title VARCHAR(100), 
 genre VARCHAR(50), 
 publication_date DATE, 
 isbn VARCHAR(20) UNIQUE, 
 pseudonym_id INT, 
 publisher_id INT, 
 FOREIGN KEY (pseudonym_id) REFERENCES Pseudonym(pseudonym_id), 
 FOREIGN KEY (publisher_id) REFERENCES Publisher(publisher_id) 
);

這感覺也是正確的。架構(gòu)現(xiàn)在將書籍關(guān)聯(lián)到筆名，而不是直接關(guān)聯(lián)到作者。讓我們使用新的架構(gòu)重新做一個dbfiddle，輸入經(jīng)過修改的數(shù)據(jù)以配合使用，并查看我們是否能再次獲得理想的結(jié)果：

圖片

實際上，現(xiàn)在筆名欄只是一個字段，表格顯得更加整潔了。

2.另一個修改請求

現(xiàn)在，我將提出進一步的架構(gòu)修改要求。我們知道一本書可以有多個作者（你可能還記得上次Llama 3在沒有提示的情況下就提出了這一點），所以我們希望GPT-4o再次修改其架構(gòu)。

圖片

需要增加的那一個新表就是：

CREATE TABLE BookAuthor 
( 
 book_id INT, 
 pseudonym_id INT, 
 PRIMARY KEY (book_id, pseudonym_id), 
 FOREIGN KEY (book_id) REFERENCES Book(book_id), 
 FOREIGN KEY (pseudonym_id) REFERENCES Pseudonym(pseudonym_id) 
);

因此，關(guān)系變更如下：

圖片

（注意，在描述了最初幾段關(guān)系后出現(xiàn)了奇怪的括號錯誤。這個錯誤在所有關(guān)系的描述中都有重復(fù)出現(xiàn)。它似乎阻止了文本“1:M”或“M:M”的打印——可能是由于表情符號混淆？）

當(dāng)然，GPT-4o也在遵循單一的對話線索——它將其先前的工作內(nèi)容納入了上下文考慮。這種廣受贊譽的能力確實使得與它的交互更加自然。總體而言，它表現(xiàn)得很好（并且非常迅速）地解析了我們的英語描述，以調(diào)整其建議的架構(gòu)。

3.在我們太過興奮之前

架構(gòu)主要關(guān)乎事物之間的關(guān)系——并不需要對事物本身的深入了解。然而，這并不完全意味著大模型接管數(shù)據(jù)庫設(shè)計的道路已經(jīng)暢通無阻。

針對SQL查詢和架構(gòu)進行優(yōu)化一直都有點兒像一門藝術(shù)。需要理解哪些常見查詢會最適合某種設(shè)計、將涉及多少張表、查詢間的依賴性、索引定義、分區(qū)等等。而這還只是在處理CAP定理困境——一致性與可用性之間的權(quán)衡——之前。在這些技術(shù)抽象之下，是人們對數(shù)據(jù)檢索遠(yuǎn)非簡單的預(yù)期。

我毫不懷疑，隨著時間的推移，大型語言模型與專業(yè)化的某種結(jié)合將逐步解決這些工程問題，但目前我們應(yīng)該為GPT-4o能夠高效地生成和修改合理架構(gòu)的能力而感到勝利。

參考鏈接：https://thenewstack.io/gpt-4o-and-sql-how-well-can-an-llm-alter-its-own-schema/

想了解更多AIGC的內(nèi)容，請訪問：

51CTO AI.x社區(qū)

http://www.scjtxx.cn/aigc/