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