作者丨David Eastman
編譯丨諾亞
出品 | 51CTO技術(shù)棧（微信號：blog51cto）
盡管沒有任何大型語言模型（LLM）騎過自行車，但它們顯然理解騎行在人類交通領(lǐng)域中的作用。它們似乎為軟件開發(fā)者提供的是一種類似語義的現(xiàn)實(shí)世界知識，結(jié)合了對技術(shù)世界的理解。我們在最近的一篇文章中清楚地看到了這一點(diǎn)，僅通過用自然語言描述，我們就能夠生成一個(gè)簡單的圖書出版SQL架構(gòu)。
雖然我對Llama 3創(chuàng)建架構(gòu)的性能感到滿意，但我之前在Oracle工作時(shí)期的一位同事指出，圖書出版架構(gòu)是一個(gè)相當(dāng)為人熟知的例子。為了便于理解，這自然是件好事，但為了進(jìn)一步拓展LLM的能力，本文中我將探索大型語言模型根據(jù)英語描述的問題調(diào)整其自身架構(gòu)的能力如何。這一次，我將使用OpenAI的GPT-4o，因?yàn)樗罱诖a審查方面為我提供了很好的幫助。
作為出發(fā)點(diǎn)，我們將從與第一篇文章中相同的問題開始，并總結(jié)答案，這個(gè)答案與上次相似。這一次，GPT-4o不僅為我們提供了一個(gè)ERD（實(shí)體關(guān)系圖），還很好地解釋了各實(shí)體間的關(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é)果視圖：
圖片
第二個(gè)姓氏中包含了中間名“M”，看起來有些別扭。接下來，我們將探討與此相關(guān)的問題。
1.首次修改
正如我在前一篇關(guān)于SQL生成的文章中提到的，“Ian Banks”和“Ian M Banks”實(shí)際上是同一位作者。上次，我們沒有解決這個(gè)筆名問題。所以，讓我們要求大模型來修復(fù)這個(gè)問題：
圖片
所以這是個(gè)好的開始。這次它需要將“筆名”這一文學(xué)概念映射到它已經(jīng)產(chǎn)生的現(xiàn)有架構(gòu)設(shè)計(jì)上。因此，它不僅要發(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)重新做一個(gè)dbfiddle，輸入經(jīng)過修改的數(shù)據(jù)以配合使用，并查看我們是否能再次獲得理想的結(jié)果：
圖片
實(shí)際上，現(xiàn)在筆名欄只是一個(gè)字段，表格顯得更加整潔了。
2.另一個(gè)修改請求
現(xiàn)在，我將提出進(jìn)一步的架構(gòu)修改要求。我們知道一本書可以有多個(gè)作者（你可能還記得上次Llama 3在沒有提示的情況下就提出了這一點(diǎn)），所以我們希望GPT-4o再次修改其架構(gòu)。
圖片
需要增加的那一個(gè)新表就是：
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)了奇怪的括號錯(cuò)誤。這個(gè)錯(cuò)誤在所有關(guān)系的描述中都有重復(fù)出現(xiàn)。它似乎阻止了文本“1:M”或“M:M”的打印——可能是由于表情符號混淆？）
當(dāng)然，GPT-4o也在遵循單一的對話線索——它將其先前的工作內(nèi)容納入了上下文考慮。這種廣受贊譽(yù)的能力確實(shí)使得與它的交互更加自然。總體而言，它表現(xiàn)得很好（并且非常迅速）地解析了我們的英語描述，以調(diào)整其建議的架構(gòu)。
3.在我們太過興奮之前
架構(gòu)主要關(guān)乎事物之間的關(guān)系——并不需要對事物本身的深入了解。然而，這并不完全意味著大模型接管數(shù)據(jù)庫設(shè)計(jì)的道路已經(jīng)暢通無阻。
針對SQL查詢和架構(gòu)進(jìn)行優(yōu)化一直都有點(diǎn)兒像一門藝術(shù)。需要理解哪些常見查詢會最適合某種設(shè)計(jì)、將涉及多少張表、查詢間的依賴性、索引定義、分區(qū)等等。而這還只是在處理CAP定理困境——一致性與可用性之間的權(quán)衡——之前。在這些技術(shù)抽象之下，是人們對數(shù)據(jù)檢索遠(yuǎn)非簡單的預(yù)期。
我毫不懷疑，隨著時(shí)間的推移，大型語言模型與專業(yè)化的某種結(jié)合將逐步解決這些工程問題，但目前我們應(yīng)該為GPT-4o能夠高效地生成和修改合理架構(gòu)的能力而感到勝利。
參考鏈接：https://thenewstack.io/gpt-4o-and-sql-how-well-can-an-llm-alter-its-own-schema/
