GPT-4o et SQL : dans quelle mesure un grand modèle est-il capable de modifier sa propre architecture ?

Auteur丨David Eastman

Compilation丨Noah

Produit | 51CTO Technology Stack (WeChat ID: blog51cto)

Bien qu'aucun grand modèle de langage (LLM) n'ait jamais conduit un vélo, ils comprennent clairement le comportement de conduite dans le domaine de l'humain rôle de transport dans. Ils sont similaires à ce que les développeurs de logiciels fournissent comme une sorte de connaissances sémantiques du monde réel combinées à une compréhension du monde technique. Nous l'avons clairement vu dans un article récent dans lequel nous avons pu générer un schéma SQL simple pour l'édition d'un livre simplement en le décrivant en langage naturel.

Bien que j'étais satisfait des performances du schéma de création de Llama 3, un collègue de mes précédents jours chez Oracle a souligné que le schéma de publication de livres était un exemple assez familier. Pour faciliter la compréhension, c'est naturellement une bonne chose, mais afin d'étendre davantage les capacités de LLM, dans cet article j'explorerai la capacité des grands modèles de langage à ajuster leur architecture en fonction des problèmes décrits en anglais. Cette fois, j'utiliserai le GPT-4o d'OpenAI car il m'a bien servi récemment lors des révisions de code.

Pour commencer, nous commencerons par les mêmes questions que dans le premier article et résumerons les réponses. Cette réponse est similaire à la dernière fois. Cette fois, GPT-4o nous fournit non seulement un ERD (diagramme de relation d'entité), mais explique également très bien la relation entre les entités.

Image

Semblable aux tentatives précédentes, il propose un schéma comme celui-ci :

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

Je préférerais que les noms de tables utilisent la forme plurielle des objets contenus, je pense que c'est une norme largement acceptée.

Les grands modèles de langage soulignent ces limitations relationnelles :

Image

Donc, en utilisant les mêmes exemples de données de la dernière fois, vérifions si nous obtenons les mêmes résultats dans l'environnement sandbox SQL DB Fiddle.

Si nous remplissons ces données et ajoutons la dernière vue...

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;

nous pouvons obtenir la vue de résultat souhaitée à partir de DB Fiddle dans le tableau ci-dessous :

Image

Deuxième nom de famille Le deuxième prénom "M " est inclus, ce qui semble un peu gênant. Ensuite, nous explorerons les questions liées à cela.

1. Première révision

Comme je l'ai mentionné dans mon précédent article sur la génération SQL, "Ian Banks" et "Ian M Banks" sont en fait le même auteur. La dernière fois, nous n’avons pas abordé ce problème de nom de plume. Alors, demandons aux grands modèles de remédier à ça :

Photos

C'est donc un bon début. Cette fois, il lui fallait adapter le concept littéraire de « nom de plume » à la conception architecturale existante qu'il avait produite. Il ne suffit donc pas de découvrir les solutions existantes. Tout d’abord, jetons un coup d’œil à la relation nouvellement formée :

Photos

Cela semble raisonnable. Voici la nouvelle structure de table modifiée :

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

Cela semble bien aussi. Le schéma associe désormais les livres aux noms de plume plutôt que directement aux auteurs. Refaisons un dbfiddle avec le nouveau schéma, entrons les données modifiées pour les intégrer et voyons si nous pouvons à nouveau obtenir les résultats souhaités :

Image

En fait, maintenant la colonne du nom de plume n'est plus qu'un champ , formulaire Cela semble plus soigné.

2. Une autre demande de modification

Maintenant, je vais demander une autre modification du schéma. Nous savons qu'un livre peut avoir plusieurs auteurs (vous vous souvenez peut-être que Llama 3 l'a proposé sans y être invité la dernière fois), nous nous attendons donc à ce que GPT-4o révise à nouveau son architecture.

Photos

Le nouveau tableau qui doit être ajouté est :

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

Les relations ont donc changé comme suit :

Images

(Notez qu'il y a une étrange erreur entre parenthèses après la description des premières relations. Cette erreur est répétée dans la description de toutes les relations. Elle semble empêcher l'impression du texte "1:M" ou "M:M" - peut-être à cause d'une confusion avec les emoji ?)

Bien sûr, GPT-4o suit également un seul fil de conversation - il met ses travaux antérieurs en contexte. Cette capacité très appréciée rend l’interaction avec elle plus naturelle. Dans l’ensemble, il a fait du bon travail (et très rapidement) en analysant nos descriptions anglaises pour adapter le schéma suggéré.

3. Avant de devenir trop excités

L'architecture concerne principalement les relations entre les choses - elle ne nécessite pas une compréhension profonde des choses elles-mêmes. Cependant, cela ne signifie pas entièrement que la voie est libre pour que les grands modèles prennent en charge la conception des bases de données.

Optimiser les requêtes et les schémas SQL a toujours été un peu un art. Vous devez comprendre quelles requêtes courantes seront les mieux adaptées à une certaine conception, combien de tables seront impliquées, les dépendances entre les requêtes, les définitions d'index, le partitionnement, etc. Et cela avant d’aborder le dilemme du théorème de la PAC : le compromis entre cohérence et disponibilité. Derrière ces abstractions techniques se cachent des attentes selon lesquelles la récupération des données sera bien plus que simple.

Je n'ai aucun doute qu'une combinaison de grands modèles de langage et de spécialisation résoudra progressivement ces problèmes d'ingénierie au fil du temps, mais pour l'instant, nous devrions être impressionnés par la capacité de GPT-4o à générer et modifier efficacement des architectures raisonnables.

Lien de référence : https://thenewstack.io/gpt-4o-and-sql-how-well-can-an-llm-alter-its-own-schema/

Si vous souhaitez en savoir plus sur l'AIGC , Veuillez visiter :

Communauté 51CTO AI.x

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

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!