GPT-4o 및 SQL: 자체 아키텍처를 변경하는 대규모 모델의 능력은 얼마나 됩니까?

저자丨David Eastman

컴필레이션丨Noah

제작 | 51CTO 기술 스택(WeChat ID: blog51cto)

자전거를 운전한 LLM(대형 언어 모델)은 없지만 인간 분야의 운전 행동을 명확하게 이해합니다. 운송 역할을 합니다. 이는 소프트웨어 개발자가 기술 세계에 대한 이해와 결합된 일종의 의미론적 실제 지식으로 제공하는 것과 유사합니다. 우리는 자연 언어로 간단히 설명함으로써 간단한 서적 게시 SQL 스키마를 생성할 수 있었던 최근 기사에서 이를 명확하게 확인했습니다.

저는 Llama 3 생성 스키마의 성능에 만족했지만, Oracle에서 근무했던 동료는 도서 출판 스키마가 상당히 친숙한 예라고 지적했습니다. 이해를 돕기 위해 이는 당연히 좋은 것이지만 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에서 원하는 결과 뷰를 얻을 수 있습니다.

Image

두 번째 성 중간 이름 "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을 다시 실행하고 수정된 데이터를 입력하여 원하는 결과를 다시 얻을 수 있는지 살펴보겠습니다.

Picture

사실 이제 펜 이름 열은 단지 필드일 뿐입니다. , 형태가 더 깔끔해 보이네요.

2. 또 다른 수정 요청

이제 추가 스키마 수정 요청을 하겠습니다. 우리는 한 책에 여러 명의 저자가 있을 수 있다는 것을 알고 있습니다(Llama 3가 지난 번 메시지를 표시하지 않고 이를 제안했다는 것을 기억하실 것입니다). 따라서 GPT-4o가 아키텍처를 다시 수정할 것으로 예상합니다.

Pictures

추가해야 할 새 테이블은 다음과 같습니다.

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

그래서 관계는 다음과 같이 변경되었습니다.

Pictures

(처음 몇 개의 관계를 설명한 후 이상한 괄호 오류가 있다는 점에 유의하세요. 이 오류는 모든 관계 설명에서 반복됩니다. 텍스트 인쇄를 방해하는 것 같습니다." 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 Community

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

위 내용은 GPT-4o 및 SQL: 자체 아키텍처를 변경하는 대규모 모델의 능력은 얼마나 됩니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!