作者丨David Eastman

編譯丨諾亞

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

盡管沒(méi)有任何大型語(yǔ)言模型（LLM）騎過(guò)自行車，但它們顯然理解騎行在人類交通領(lǐng)域中的作用。它們似乎為軟件開(kāi)發(fā)者提供的是一種類似語(yǔ)義的現(xiàn)實(shí)世界知識(shí)，結(jié)合了對(duì)技術(shù)世界的理解。我們?cè)谧罱囊黄恼轮星宄乜吹搅诉@一點(diǎn)，僅通過(guò)用自然語(yǔ)言描述，我們就能夠生成一個(gè)簡(jiǎn)單的圖書(shū)出版SQL架構(gòu)。

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

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

圖片

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

復(fù)制

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) 
);

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

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

圖片

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

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

復(fù)制

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é)果視圖：

圖片

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

1.首次修改

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

圖片

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

圖片

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

復(fù)制

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) 
);

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

圖片

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

2.另一個(gè)修改請(qǐng)求

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

圖片

需要增加的那一個(gè)新表就是：

復(fù)制

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)了奇怪的括號(hào)錯(cuò)誤。這個(gè)錯(cuò)誤在所有關(guān)系的描述中都有重復(fù)出現(xiàn)。它似乎阻止了文本“1:M”或“M:M”的打印——可能是由于表情符號(hào)混淆？）

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

3.在我們太過(guò)興奮之前

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

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

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

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

本文轉(zhuǎn)載自51CTO技術(shù)棧，作者：諾亞