SQL2NL Prompt Engineering - KCC(1)

SQL2NL Module의 정확도를 향상시키는 법에대한 고찰이다.

 

일단 생각해낼 것은, 어찌어찌 SQL2NL 정확도 올리는 법을 찾았다고 쳤을때 그 것을 어찌 판단할 것인가?

 

검색을 통해 얻은 NL Accuracy Evaluation Matrix는 아래와 같다.

 

1. ROUGE

2. BERTScore

 

그리고, Paper SQL-to-Text Generation with Graph-to-Sequence Model(2019Feb12 Kun Xu et al.)에 나온 BLEU-4 score.

이 논문의 저자도 이것만으론 좀 부족했는지 결국 Human Study(사람이 직접 문장보고 유사도 평가)를 사용했다.

 

연구의 골자는 다음과 같다.

 

LLM을 통해서 SQL을 NL로 바꾸어 보려고 한다. 이것의 필요성은

1. NL2SQL Module의 정확도 향상 : NL ambiguity(모호성) 해소 및 NL2SQL Accuracy double check.

2. SQL<->NL Pair Augmentation : SQL2NL / NL2SQL Model 학습용 Data-set이 부족하다. SQL2NL 정확도만 향상되면 시중의 많은 SQL을 가지고 NL pair를 만들 수 있다.

3. SQL 개발자용 보조툴 : 현재 코딩을 하는 개발자들은 Gemini, Copilot과 같은 코딩 보조 Tool의 도움을 많이 받는다. SQL Engineer 역시, SQL2NL Module을 통해 본인의 SQL문이 의도대로 잘 작성되었는지 보조를 받을 수 있다.

 

주제는, SQL2NL Version LLM Prompt Engineering이다. 즉, SQP input을 LLM에 넣어서 변환된 NL의 Semantic 정확도를 좀 더 올릴 수 있는 방안에 대한 연구다.

 

이런 식으로 대충 Abstract와 Introduction을 적고난 뒤에..

 

평가지표로 ROUGE(Recall-Oriented Understudy for Gisting Evaluation) / BERTScore / BLEU(Bilingual Evaluation Understudy) 등등.. 을 사용할 예정인데 일단 각 Matrix에 대해 공부좀 해보고 Vocabulary 보단 Semantic에 초점을 둔 Score를 2개 정도 Pick하고 그것에 대한 설명을 추가한다.(With Paper Reference)

 

그리고 제일 중요한 것은 Experiment 설계와, Evaluation 부분이다.

 

LLM으론 GPT4-mini와 Llama3 7b(Light Version)을 사용해볼 예정. 너무 좋은 놈 쓰면 괜시리 Naive하게 정확도가 좋을까봐.. 그리고 GPT Legacy version은 API돌리는데 Cost 이슈도 무시 못한다 ㅎㅎ

 

각 LLM Model 별로 Naive / Naive + Table-schema / Naive + Parsing-info / Naive + Table-schema + Parsing-info

이렇게 4가지로 나눠보고 Bird / Spider or Wiki data-set을 사용한다.

 

대충 아래와 같이 개요를 잡아본다.

	Bird - Data Set
Naive GPT	ROUGE Score	BLEU-4 Score
Naive GPT + Table Schema
Naive GPT + Parsing info
Naive GPT + Both
	Wiki - Data Set
Naive Llama	ROUGE Score	BLEU-4 Score
Naive Llama + Table Schema
Naive Llama + Parsing info
Naive Llama + Both

 

추가로 설명이 필요한 부분은, Table-Schema에 대한 설명은 무엇을 의미하는 것일까..

일단 PostgreSQL/Oracle을 쓰는 것이 아니니까 DB서버에서 Schema를 따온다는 생각은 하지말고, 단순 DB 내 Table과 각 Table의 Column 명에 대한 Type소개, Table 간 FK/PK 정보 즉 Table DDL 정보 정도만 있으면 될 거 같다.

 

Parsing-info는 내가 PostgreSQL 안에서 SQL Syntax를 따져서 Clause별로 Rule-base를 통해 SQL을 NL로 변환한 그 정보를 주면 될 거 같다.

 

사실, Parsing-info는 SQL을 어느 정도 아는 중급자 기준으로 SQL문의 의도를 파악하는데 도움이 되는 것이지 NL변환의 Semantic을 보존하는 것에는 큰 의미가 없을 거 같아서 넣을지 뺄지 고민 중.. 근데 이걸 빼자니 논문 Idea 참신함이 부족하긴 하다.

 

대충 이 정도로 해서, LLM을 통한 SQL2NL을 할 시 이런 이런 정보를 같이 Prompt Engineering으로 주면 정확도가 올라가요~ 라는 데이터가 나오고 간단한 논문을 제출하고 싶다.

 

여기까지가 Draft Version..!