GPT-4o dan SQL: Sejauh manakah model besar mengubah seni binanya sendiri?

. peranan pengangkutan dalam. Mereka serupa dengan apa yang disediakan oleh pembangun perisian sebagai sejenis pengetahuan dunia sebenar seperti semantik yang digabungkan dengan pemahaman tentang dunia teknikal. Kami melihat ini dengan jelas dalam artikel baru-baru ini di mana kami dapat menjana skema SQL mudah untuk penerbitan buku hanya dengan menerangkannya dalam bahasa semula jadi.

Walaupun saya gembira dengan prestasi skema penciptaan Llama 3, rakan sekerja dari hari-hari saya sebelumnya di Oracle menunjukkan bahawa skema penerbitan buku adalah contoh yang agak biasa. Untuk memudahkan pemahaman, ini sememangnya satu perkara yang baik, tetapi untuk mengembangkan lagi keupayaan LLM, dalam artikel ini saya akan meneroka keupayaan model bahasa besar untuk menyesuaikan seni binanya mengikut masalah yang diterangkan dalam bahasa Inggeris. Kali ini, saya akan menggunakan GPT-4o OpenAI kerana ia telah membantu saya dengan ulasan kod baru-baru ini.

Sebagai titik permulaan, kami akan mulakan dengan soalan yang sama seperti dalam artikel pertama dan merumuskan jawapannya. Jawapan ini sama seperti kali terakhir. Kali ini, GPT-4o bukan sahaja memberikan kami ERD (gambar rajah hubungan entiti), tetapi juga menerangkan hubungan antara entiti dengan sangat baik.

Imej

Sama seperti percubaan sebelumnya, ia mencadangkan skema seperti ini:

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

Saya lebih suka nama jadual menggunakan bentuk jamak bagi objek yang terkandung, saya rasa ini diterima secara meluas. Model bahasa yang besar menunjukkan had perhubungan ini:

Imej

Jadi, menggunakan data contoh yang sama dari kali terakhir, mari kita semak sama ada kita mendapat hasil yang sama dalam persekitaran kotak pasir SQL DB Fiddle.

Jika kita mengisi data ini dan menambah paparan terakhir...

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;

kita boleh mendapatkan paparan hasil yang diingini daripada DB Fiddle dalam jadual di bawah:

Imej

Nama Keluarga Kedua "M Nama Keluarga Kedua" " disertakan di dalamnya, yang kelihatan agak janggal. Seterusnya, kita akan meneroka isu-isu yang berkaitan dengan ini.

1. Semakan pertama

Seperti yang saya nyatakan dalam artikel saya sebelum ini tentang penjanaan SQL, "Ian Banks" dan "Ian M Banks" sebenarnya adalah pengarang yang sama. Kali terakhir, kami tidak menangani isu nama pena ini. Jadi, mari kita minta model besar untuk membetulkan perkara ini:

Gambar

Jadi itu permulaan yang baik. Kali ini ia perlu memetakan konsep sastera "nama pena" pada reka bentuk seni bina sedia ada yang dihasilkannya. Jadi ia perlu melakukan lebih daripada sekadar mencari penyelesaian sedia ada. Mula-mula, mari kita lihat hubungan yang baru dibentuk:

Gambar

Ini nampaknya munasabah. Berikut ialah struktur jadual terbaharu yang diubah suai:

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

Ini juga terasa betul. Skema kini mengaitkan buku dengan nama pena dan bukannya terus kepada pengarang. Mari kita buat semula dbfiddle dengan skema baharu, masukkan data yang diubah suai untuk dimuatkan, dan lihat sama ada kita boleh mendapatkan hasil yang diingini semula:

Gambar

Malah, kini ruangan nama pena hanyalah medan , bentuk Ia kelihatan lebih kemas.

2. Satu lagi Permintaan Pengubahsuaian

Sekarang, saya akan meminta pengubahsuaian skema selanjutnya. Kami tahu bahawa buku boleh mempunyai berbilang pengarang (anda mungkin ingat bahawa Llama 3 mencadangkan perkara ini tanpa menggesa kali terakhir), jadi kami menjangkakan GPT-4o menyemak semula seni binanya.

Gambar

Jadual baharu yang perlu ditambah ialah:

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

Jadi perhubungan berubah seperti berikut:

Gambar

(Perhatikan bahawa terdapat ralat kurungan pelik selepas menerangkan beberapa perhubungan pertama. Ralat ini berulang dalam penerangan semua perhubungan. Ia seolah-olah menghalang Pencetakan teks "1:M" atau "M:M" - mungkin disebabkan oleh kekeliruan emoji?)

Sudah tentu, GPT-4o juga mengikuti satu utas perbualan - ia meletakkan kerja sebelumnya dalam konteks mempertimbangkan. Keupayaan yang sangat dipuji ini menjadikan interaksi dengannya lebih semula jadi. Secara keseluruhan, ia melakukan kerja yang baik (dan sangat cepat) menghuraikan huraian bahasa Inggeris kami untuk menyesuaikan skema cadangannya.

3 Sebelum kita terlalu teruja

Seni bina terutamanya mengenai hubungan antara perkara - ia tidak memerlukan pemahaman yang mendalam tentang perkara itu sendiri. Walau bagaimanapun, ini tidak sepenuhnya bermakna jalan yang jelas untuk model besar untuk mengambil alih reka bentuk pangkalan data.

Mengoptimumkan pertanyaan dan skema SQL sentiasa menjadi sedikit seni. Anda perlu memahami pertanyaan biasa yang paling sesuai untuk reka bentuk tertentu, bilangan jadual yang akan terlibat, kebergantungan antara pertanyaan, definisi indeks, pembahagian dan sebagainya. Dan itu sebelum menangani dilema teorem CAP - pertukaran antara konsistensi dan ketersediaan. Di bawah abstraksi teknikal ini adalah jangkaan bahawa pengambilan data akan jauh lebih mudah.

Saya tidak ragu-ragu bahawa beberapa gabungan model bahasa besar dan pengkhususan akan menyelesaikan masalah kejuruteraan ini secara beransur-ansur dari semasa ke semasa, tetapi buat masa ini kita harus kagum dengan keupayaan GPT-4o untuk menjana dan mengubah suai kemenangan seni bina yang munasabah dengan cekap.

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

Jika anda ingin mengetahui lebih lanjut tentang AIGC , Sila layari:

51CTO AI.x Community

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

Atas ialah kandungan terperinci GPT-4o dan SQL: Sejauh manakah model besar mengubah seni binanya sendiri?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!