SQL2NL 모델 개선방안에 대한 검토 - Prompt & RAG

https://eglife.tistory.com/358

연구주제 고찰(2)

 

SQL to NL Model을 좀 검토해보기로 하고, 개선방안은 기존 NL2SQL 연구 트랜드를 벤치마크한다.

 

위 연구주제 고찰(2) 글에서 첫 번째 연구주제에 대한 내용이다.

 

빠르게 설계를 해보자.

 

일단 주제는, Generative AI ( Large Language Model ) 을 이용한 SQL to NL Framework이고, 연구는 Model Finetuning / Prompt Engineering / RAG 를 이용해보려고 한다.

 

그간, Text to SQL 영역에서 위 요소들은 정말 많이 다뤄져 왔다. 하여 NL2SQL(Text to SQL)에서 사용한 방법을 거의 유사하게 차용하되, Evaluation Matrix만 기존 BERT Recall / BART Score에서 BLEU , METEOR 등 추가 지표를 사용해서 실험을 진행하려 한다.

 

일단, Finetuning의 경우 시간과 Cost가 들기때문에 Prompt와 RAG를 이용해서 먼저 SQL2NL 최적화를 해보자.

 

---

1. Prompt

Prompt의 경우 Zero-shot / Few-shot / Chain-of-Thought(CoT) / Schema-aware prompting으로 구분된다. 그 중 Schema-aware prompting의 경우, 내가 KCC에서 DB Table Schema를 Prompt와 함께 LLM에 전달하여 SQL2NL을 성사시킨 케이스다.

즉, Schema Linking의 유효성은 이미 검증한 것이다.

 

이제 내가 해볼만한 것은 Few-shot 정도이다. 아니면 SQL2NL 전용 CoT Prompt를 설계해볼 수도 있다. 

사실 실험 해보기도 전이지만 Few Shot 역시 당연히 유요할 거 같아서 좀 애매하긴 허다..

2. RAG (Retrieval Augmented Generation)

DB내 테이블/칼럼 설명을 Retrieval 해서 Prompt에 삽입하는 활용처가 많다. 근데 그건 그냥 Prompt Engineering의 연장선이지 않나..? Novelty가 부족하다.

 

---

 

논문을 보다보니까, 어떤 새로운 방법론을 제시할 때 특별히 근거가 있어서가 아니라 "그냥 시도를 해보았더니 괜찮았다" 라는 것도 많다. 즉, 어떤 공식이나 선행하는 관련 논문이 없어도 NL2SQL, SQL2NL은 無 에서 有 를 창조하는 방법론을 알아서 제시해도 되는 것이다. 아이디어 싸움이라는 말!

 

SQL to Text 과정을 역산해보자. 그러다보면 아이디어가 떠오를 수도..?

 

일단 LLM마다 세부적인 Logic detail은 조금씩 다르겠지만, SQL input이 들어오고 이를 Text로 바꾸는 대략적인 Flow는 아래와 같다.

 

SQL Input 예시 - 쪼매 복잡한 녀석

SELECT s.name, c.name
FROM students s
JOIN enrollments e ON s.id = e.student_id
JOIN courses c ON e.course_id = c.id
WHERE e.year = 2023
  AND s.id IN (
    SELECT student_id
    FROM honors
    WHERE gpa > 3.7
  );

 

Text Output 예시

"List the names of students and the courses they enrolled in during 2023, but only include students who are on the honors list with a GPA above 3.7."

 

✅ [1] Tokenization & Embedding : 토큰화 및 인코딩 단계 입력된 SQL문을 Subword 수준으로 tokenize 한다. SQL 키워드(SELECT, FROM, WHERE 등)를 개별 토큰으로 분해 테이블명, 컬럼명 등의 식별자를 토큰화 연산자(=, >, < 등)와 구분자(,, ;)를 별도 토큰으로 처리 ✅ [2] Self-Attention Encoding Attention 메커니즘으로 [1]에서 분류한 토큰을 가지고 SQL구문의 계층적 분석을 실시한다. Transformer 기반으로 모든 토큰 간 관계를 계산한다. 이 때, 우리가 알고 있는 Query/Key Value를 가지고 문맥 구조를 포착하는 것. 자세한 사항은, Attention 공부 글을 참고 (https://eglife.tistory.com/328)   여기서 LLM은 Parser를 사용하진 않지만, 은연중에 SQL에 대해 구조적 Reasoning을 수행한다. 절(Clause) 식별: SELECT절, FROM절, WHERE절 등의 경계 인식 중첩 구조 이해: 서브쿼리, JOIN 조건 등의 중첩된 구조 파악 의존성 추적: 어떤 컬럼이 어떤 테이블에서 오는지 추적 ✅ [3] Internal Template Matching or Concept Mapping : 의미론적 패턴 매칭 이 부분에서 Training Data가 사용된다. 사전 학습된 Data를 가지고 SQL구조에 대응되는 Text표현을 찾는 것 또는 이런식으로 변경 가능하다. SELECT * → "all columns" 또는 "all information" WHERE x = y → "where x equals y" 또는 "with x being y" JOIN → "combined with" 또는 "linked to" GROUP BY → "grouped by" 또는 "organized by" SQL2NL에 RAG를 이용한다면, 바로 이 부분에 적용시킬 수 있지 않으려나..? LLM의 학습단계는 이제 건들게 없으니 Training Data에 대해 건드는 것으로 넘어가야 하는데 알다시피 LLM을 Train 하는 거 자체가 Time / Cost 소모가 크다. 그래서, Domain 별로 SQL <-> Gold Text Data-set만 준비되어 있다면(논문 실험용으론 BIRD / SPIDER dataset) 그 data들을 Vector DB에 저장 후 RAG로 LLM에 끌어와 Prompt를 때린다면 효과적이지 않을까? 각 단체, 기업에서 자체적으로 본인들 DB상황에 맞는 SQL<->NL Dataset만 추출해서(Gold Pair이어야 하니까, User가 NL을 날리고 그에 대응하는 SQL이 생성되었을 때, User가 본인이 의도한 바데로 Data가 추출되었다고 판단했을 시, 이를 자체 DB에 저장) Vector DB로 관리하고 있으면, SQL2NL Model이 RAG로 이 Vector DB를 참고해서 정확도를 올릴 수 있다. +++) 추가적으로 이렇게 Vector DB에 Gold Data가 쌓여갈 수록 SQL2NL 정확도는 올라가고, 이것이 역설적으로 다시 기업 내 NL2SQL 모델의 검증에도 사용될 수 있고 또는 기업 DB에 SQL을 날리는 Engineer의 개발보조 Tool로도 사용될 수 있다. 예를 들어 Engineer가 SQL을 날렸을 때 이것을 NL로 바꿔서 다시 Engineer에게 제시하며, 본인의 의도가 이것이 맞냐고 재확인도 가능하다.  즉, 완전히 Major하진 않지만 그래도 효용성이 있는 Task라는 것은 알 수 있다. (역시나.. 기획단계는 너무 재미있다 😊 근데 이건.. 다시 생각해보면 뭐.. 당연히 도움이 되는거라 굳이 실험, 논문을 해야하나.. 싶긴 하지만.. 이 AI 연구 영역이라는 것이 그런 거 같다. 당연한 것을 먼저 찜꽁해놓는 사람이 승자인 것😥) ✅ [4] Natural Language Generation (Decoder 단계) 그리고 마지막이 Decoder 단계이다. 이 부분도 위에 강조한 [3]과 같이 Train Data에 의지해서 Context기반 해석이 가미된 자연스러운 스타일의 Text가 생성되는 것이다. COUNT(*) + orders → "number of orders" (단순 "count"가 아닌) status = 'completed' → "completed orders" (문맥상 적절한 형용사 위치) 이 밖에,  SQL 서브쿼리, 집계 함수 처리, 논리 연산 변환, 정렬, Limit 등의 표현도 LLM이 Logic처리를 할 수 있다.

---

다시 정리하면, 그냥 Prompt에 Few-Shot을 RAG를 통해 추출하여 SQL2NL을 시도하는 것인데..

RB-SQL 논문과 내용이 너무 유사하다 ㅠ(https://arxiv.org/pdf/2407.08273v1) 차별점을 줄 수 없을까?

 

아니면 그냥 KCC Schema Linking까지 넣어서 NL2SQL의 모든 Task를 SQL2NL로 정리해보는 것으로 논문을 진행할까..

 

TAG(Table-Augmented Generation, https://medium.com/@sridevi.gogusetty/from-rag-to-tag-leveraging-the-power-of-table-augmented-generation-tag-a-leap-beyond-9158c0efce61) 을 이용해볼까도 싶었는데, 이건 되려 NL2SQL에 적합한 기술같다.

 

어찌됐건, 중요한 것은 BIRD든 Spider든 SQL2NL은 한 Domain에서 진행이 되어야 한다. 즉, Schema Linking은 필수라고 본다. 아니면 Column 이름만 보고 이게 무엇을 뜻하는지 LLM은 알 수가 없다.

---

TAG를 SQL2NL에 쓴다면?

LLM에 DB Data전체를 넘길 수 있다. 근데 이건 좀 내용이 많아서 과하지 않나 싶긴하다. Schema Linking과 같이 당연히 효과는 있지 싶은데, 이게 내 KCC논문과 어떤 '큰' 차별점을 갖는지는 모르겠다.

 

내 연구의 Novelty

RB-SQL과 차이를 주려면, Vector DB 형성부분 + Vector DB Retrieve 부분에서 차별점을 줘야 한다. KCC에서도 참고했던 SQLGlot(https://github.com/tobymao/sqlglot) 같은 녀석을 다시 활용해서 Gold SQL을 임베딩할때 SQL의 Structure 특징을 잘 구분해서 임베딩 시킬 수 있어야한다. 그리고, Input SQL과 Vector DB SQL간 Similarity 측정을 할 때도 이 SQL의 Strucutre를 활용한 유사도로 Top - K를 추출하고 그것을 Prompt로 쓰면 뻔한 RAG+Prompt 구조이지만 그래도 나름의 Novelty가 분명한 방법이라고 생각한다.

 

후.. 이제 좀 정리가 된다.

나의 Novelty는 Input <-> Vector DB Retrieve 시 그 Evaluation Matrix가 얼마나 SQL Structure 기반으로 계산이 되느냐이다.

그리고 이것은 LLM이 SQL을 받아서 TEXT를 만드는 과정에서 유일하게 우리가 건들 수 있는 부분인 Train(Fine-tune)쪽을 건드는 것이며 이것을 일단 시간/돈을 절약하기 위해 RAG로 실험먼저 진행하는 것이다.

 

한계는, 앞서 언급했듯이 Domain 특화 限 이라는 것이다. 그래서 RAG도 특정 Domain의 SQL<->Gold pair를 쓴다. Fine-tuning을 할 때도 당연히 특정 Domain 위주로 LLM학습을 시킬 것이다. 근데 이건 비단 SQL2NL 분야가 아니더라도, 모든 분야가 마찬가지일 것이다. 슈퍼마켓 손님 Chat bot을 만들 때 슈퍼마켓 데이터만 집어넣지 옆 동네 종합병원 데이터를 집어 넣진 않으니까 말이다. 물론 'SQL'이라는 언어활용을 전부 Cover하고 싶다면 OpenAI가 한글/영어 질문을 GPT에 사전학습시켰 듯 학습량을 방대하게 늘리면 다 Cover가 가능하다.

근데 생각해보면 그건 꽤나 쉽다. 한글/영어로 우리가 그냥 시시콜콜하게 일상의 궁금증을 묻는 거와 달리 SQL이라는 것은 질의 방식이 무한정하지 않고, 정해진 규격이 있기 때문이다. 학습 수준은 요즘 많은 사람들이 건들고 있는 프로그래밍 도움 ChatBot 수준을 만드는데 필요한 데이터양만 확보되면 어느 정도 커버가 가능할 거 같다.

 

이상 사담을 줄이고 가다(?)를 잡았으니 얼른 실험을 진행하며 또 기록을 남기고 Insight를 공유해야겠다.