GPT-4o und SQL: Wie fähig ist ein großes Modell, seine eigene Architektur zu ändern?

Autor: David Eastman: Zusammenstellung: Noah: Produziert | Transportrolle in. Sie ähneln dem, was Softwareentwickler als eine Art semantisches Wissen aus der realen Welt, gepaart mit einem Verständnis der technischen Welt, bereitstellen. Wir haben dies in einem kürzlich erschienenen Artikel deutlich gesehen, in dem wir ein einfaches SQL-Schema für die Buchveröffentlichung generieren konnten, indem wir es einfach in natürlicher Sprache beschrieben.

Während ich mit der Leistung des Llama 3-Erstellungsschemas zufrieden war, wies ein Kollege aus meinen vorherigen Tagen bei Oracle darauf hin, dass das Buchveröffentlichungsschema ein ziemlich bekanntes Beispiel sei. Aus Gründen des besseren Verständnisses ist dies natürlich eine gute Sache, aber um die Fähigkeiten von LLM weiter zu erweitern, werde ich in diesem Artikel die Fähigkeit großer Sprachmodelle untersuchen, ihre Architektur an die im Englischen beschriebenen Probleme anzupassen. Dieses Mal werde ich GPT-4o von OpenAI verwenden, da es mir in letzter Zeit bei Codeüberprüfungen gute Dienste geleistet hat.

Als Ausgangspunkt beginnen wir mit den gleichen Fragen wie im ersten Artikel und fassen die Antworten zusammen. Diese Antwort ähnelt dem letzten Mal. Dieses Mal liefert uns GPT-4o nicht nur ein ERD (Entity-Relationship-Diagramm), sondern erklärt auch die Beziehung zwischen Entitäten sehr gut.

Image

Ähnlich wie bei früheren Versuchen wird ein Schema wie dieses vorgeschlagen:

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

Ich würde es vorziehen, wenn die Tabellennamen die Pluralform der enthaltenen Objekte verwenden würden. Ich denke, das ist ein weithin akzeptierter Standard.

Große Sprachmodelle weisen auf diese relationalen Einschränkungen hin:

Bild

Anhand der gleichen Beispieldaten vom letzten Mal prüfen wir also, ob wir in der SQL-Sandbox-Umgebung DB Fiddle die gleichen Ergebnisse erhalten.

Wenn wir diese Daten ausfüllen und die letzte Ansicht hinzufügen...

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;

können wir die gewünschte Ergebnisansicht von DB Fiddle in der folgenden Tabelle erhalten:

Bild

Zweiter Nachname Der zweite Vorname „M " ist darin enthalten, was etwas umständlich erscheint. Als nächstes werden wir die damit verbundenen Probleme untersuchen.

1. Erste ÜberarbeitungWie ich in meinem vorherigen Artikel über die SQL-Generierung erwähnt habe, sind „Ian Banks“ und „Ian M Banks“ tatsächlich derselbe Autor. Beim letzten Mal haben wir dieses Pseudonym-Problem nicht angesprochen. Bitten wir also die großen Models, das Problem zu beheben:

Bilder

Das ist also ein guter Anfang. Dieses Mal musste das literarische Konzept des „Pseudonyms“ auf den bestehenden architektonischen Entwurf übertragen werden, den es erstellt hatte. Es muss also mehr tun, als nur bestehende Lösungen zu entdecken. Werfen wir zunächst einen Blick auf die neu entstandene Beziehung:

Bilder

Das erscheint vernünftig. Hier ist die neue modifizierte Tabellenstruktur:

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

Das fühlt sich auch richtig an. Das Schema ordnet Bücher nun Pseudonymen statt direkt Autoren zu. Lassen Sie uns ein DBFiddle mit dem neuen Schema erneut durchführen, die geänderten Daten eingeben, damit sie hineinpassen, und sehen, ob wir wieder die gewünschten Ergebnisse erhalten können:

Bild

Tatsächlich ist die Spalte mit dem Pseudonym jetzt nur noch ein Feld , Form Es sieht ordentlicher aus.

2. Noch eine ÄnderungsanfrageJetzt werde ich eine weitere Schemaänderung anfordern. Wir wissen, dass ein Buch mehrere Autoren haben kann (Sie erinnern sich vielleicht, dass Llama 3 dies beim letzten Mal ohne Aufforderung vorgeschlagen hat), daher gehen wir davon aus, dass GPT-4o seine Architektur erneut überarbeiten wird.

Bilder

Die neue Tabelle, die hinzugefügt werden muss, ist:

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

Die Beziehungen haben sich also wie folgt geändert:

Bilder

(Beachten Sie, dass nach der Beschreibung der ersten paar Beziehungen ein seltsamer Klammerfehler auftritt. Dieser Fehler wird in der Beschreibung aller Beziehungen wiederholt. Er scheint das Drucken der zu verhindern Text „1:M“ oder „M:M“ – möglicherweise aufgrund von Emoji-Verwirrung?)

Natürlich verfolgt GPT-4o auch einen einzelnen Konversationsthread – es stellt seine bisherige Arbeit in den Kontext und betrachtet sie. Diese viel gelobte Funktion macht die Interaktion damit natürlicher. Insgesamt hat es unsere englischen Beschreibungen gut (und sehr schnell) analysiert, um das vorgeschlagene Schema anzupassen.

3. Bevor wir uns zu sehr aufregen: Bei der Architektur geht es hauptsächlich um die Beziehungen zwischen Dingen – es ist kein tiefes Verständnis der Dinge selbst erforderlich. Dies bedeutet jedoch nicht ganz, dass der Weg für große Modelle frei ist, das Datenbankdesign zu übernehmen.

Die Optimierung von SQL-Abfragen und -Schemas war schon immer eine Kunst. Sie müssen verstehen, welche allgemeinen Abfragen für ein bestimmtes Design am besten geeignet sind, wie viele Tabellen beteiligt sein werden, Abhängigkeiten zwischen Abfragen, Indexdefinitionen, Partitionierung usw. Und das, bevor wir uns mit dem CAP-Theorem-Dilemma befassen – dem Kompromiss zwischen Konsistenz und Verfügbarkeit. Hinter diesen technischen Abstraktionen steckt die Erwartung, dass der Datenabruf weit mehr als nur einfach sein wird.

Ich habe keinen Zweifel daran, dass eine Kombination aus großen Sprachmodellen und Spezialisierung diese technischen Probleme im Laufe der Zeit nach und nach lösen wird, aber vorerst sollten wir von der Fähigkeit von GPT-4o beeindruckt sein, vernünftige Architekturen effizient zu generieren und zu modifizieren.

Referenzlink: https://thenewstack.io/gpt-4o-and-sql-how-well-can-an-llm-alter-its-own-schema/

Wenn Sie mehr über AIGC erfahren möchten , Bitte besuchen Sie:

51CTO AI.x Community

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

Das obige ist der detaillierte Inhalt vonGPT-4o und SQL: Wie fähig ist ein großes Modell, seine eigene Architektur zu ändern?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!