GPT-4o と SQL: 大規模モデルは、自身のアーキテクチャを変更する能力がどの程度あるのでしょうか?

著者丨David Eastman

コンピレーション丨Noah

プロデュース | 51CTO Technology Stack (WeChat ID: blog51cto)

大規模言語モデル (LLM) は自転車を運転したことがありませんが、人間の分野での運転行動を明確に理解しています。における輸送の役割。これらは、ソフトウェア開発者が技術的な世界の理解を組み合わせた、一種の意味論的な現実世界の知識として提供するものに似ています。このことは、自然言語で記述するだけで簡単な書籍出版 SQL スキーマを生成できた最近の記事ではっきりとわかりました。

私は Llama 3 作成スキーマのパフォーマンスに満足していましたが、オラクルでの以前の時代の同僚は、書籍出版スキーマが非常によく知られた例であると指摘しました。理解を容易にするために、これは当然良いことですが、LLM の機能をさらに拡張するために、この記事では、英語で記述された問題に応じてアーキテクチャを調整する大規模な言語モデルの機能を検討します。最近コードレビューでよく役立っているOpenAIのGPT-4oを今回は使います。

出発点として、最初の記事と同じ質問から始めて、回答をまとめます。この回答は前回と同様です。今回、GPT-4o は ERD (エンティティ関係図) を提供するだけでなく、エンティティ間の関係も非常によく説明します。

Image

以前の試みと同様に、次のようなスキーマを提案しています:

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

テーブル名に含まれるオブジェクトの複数形を使用することを希望します。これは広く受け入れられている標準だと思います。

大規模な言語モデルは、次のリレーショナル制限を指摘しています:

Image

そこで、前回と同じサンプル データを使用して、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 から目的の結果ビューを取得できます:

画像

2 番目の姓 ミドルネーム "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/

AIGCについて詳しく知りたい方は、ご覧ください:

51CTO AI.xコミュニティ

https://www.51cto.com/aigc/

以上がGPT-4o と SQL: 大規模モデルは、自身のアーキテクチャを変更する能力がどの程度あるのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。