作者丨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 ASSELECT Book.title 'Book', Author.first_name 'Author firstname', Author.last_name 'Author surname', Publisher.name 'Publisher', Book.publication_dateFROM Book, Publisher, AuthorWHERE Book.author_id = Author.author_idAND Book.publisher_id = Publisher.publisher_id;#我們就能在下方的表格中從DB Fiddle取得所需的結果檢視：
圖片
第二個姓氏中包含了中間名稱“M”，看起來有些彆扭。接下來，我們將探討與此相關的問題。
#正如我在前一篇關於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，輸入經過修改的資料以配合使用，並查看我們是否能再次獲得理想的結果：
圖片
實際上，現在筆名欄只是一個字段，表格看起來更整潔了。
現在，我將提出進一步的架構修改要求。我們知道一本書可以有多位作者（你可能還記得上次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) );
因此，關係變更如下：
圖片
（注意，在描述了最初幾段關係後出現了奇怪的括號錯誤。這個錯誤在所有關係的描述中都有重複出現。 4o也在遵循單一的對話線索——它將其先前的工作內容納入了上下文考慮。這種廣受讚譽的能力確實使得與它的互動更加自然。總體而言，它表現得很好（並且非常迅速）地解析了我們的英語描述，以調整其建議的架構。
3.在我們太過興奮之前
針對SQL查詢和架構進行最佳化一直都有點兒像一門藝術。需要理解哪些常見查詢會最適合某種設計、會涉及多少張表、查詢間的依賴性、索引定義、分區等等。而這只是在處理CAP定理困境──一致性與可用性的權衡──之前。在這些技術抽象之下，是人們對資料檢索遠非簡單的預期。
我毫不懷疑，隨著時間的推移，大型語言模型與專業化的某種結合將逐步解決這些工程問題，但目前我們應該為GPT-4o能夠高效地生成和修改合理架構的能力而感到勝利。
參考連結：https://thenewstack.io/gpt-4o-and-sql-how-well-can-an-llm-alter-its-own-schema/
#想了解更多AIGC的內容，請造訪：51CTO AI.x社群以上是GPT-4o與SQL：大模型改變自身架構的能力有多強？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
