꿈꾸는공학도

[논문작업] SQL2NL for NL2SQL (3)

eatplaylove — Mon, 15 Dec 2025 21:07:00 +0900

https://eglife.tistory.com/373

[논문작업] SQL2NL for NL2SQL (2)

https://eglife.tistory.com/372 [논문작업] SQL2NL for NL2SQL (1)너무 놀았다.. 이제는 피할 수가 없는 졸논작업 박사에 비하면 큰 관심이 없는 게 석사논문이기도 하고,, 사실 내가 경력채용으로 가려고 하는

eglife.tistory.com

우당탕탕 Llama3.2 3b Base로 이런저런 실험은 끝냈다.

이제는 데이터추출 / 실험은 그만하고, 논문 Writing 작업을 실시할 때인데...

의외로 Rule-based SQL2NL을 했던 data를 finetuning한 Model이 NL2SQL 성능이 좋았다.

물론, 한정된 Data수량 / 다양한 LLM으로 시도해보진 않았음.. 등의 이슈가 있지만
(더 다양한 Dataset, LLM으로 실험하는 건 혼자 하기엔 넘 ㅜ벅차다.. 구찮고 번거롭다 이 말이다!!!)

이 결과를 눈으로 한 번 확인해본 이상 찐막으로, 이 Rule-based만 한 번 NL2SQL 모델 파인튜닝에 이용을 해볼까 한다.

이것만 돌리고 리얼로 Writing 들어가자. 더 이상 미룰 수가 없소이다!!

+++) 흠.. 추가로 사실 SQL2NL 모델을 이용해서 Data augmentation 쫙 때리고 파인튜닝하면 효과도 더 좋을 거 같긴한데..

그거는 나중에 해보는 것으로 하자. 구찮다.

1. Abstract : 대충 씨부리기

NL2SQL에 비해 다소 관심이 없던 분야인 SQL2NL을 연구했으며 이것을 이용해 다시 NL2SQL을 최적화할 수 있는 방안이 없는지 검토했다. SQL2NL은 RAG + Hybrid 방식과, Parsing Rule Based 이렇게 2가지를 소개할 것이다. 각각의 방법은 NL2SQL Evaluation, Bench mark data audit 등 다양하게 쓰일 수 있지만, 이번 연구에선 SQL2NL이 어떻게 NL2SQL Finetuning 과정에 적용되어 NL2SQL Task에 도움을 줄 수 있을지 알아본다.

2. Introduction : 초록내용 이어서 주절주절, 여기 까지는 사진, 테이블 등은 딱히 필요가 없을듯

NL2SQL이 무엇이고, SQL2NL 이 무엇이고, 요즘 동향은 어떤지, 최근 기술은 무엇이 있는지?

SQL2NL 모델 2가지를 소개할 것이고, 각각은 다양한 활용처가 있다.

- SQL copilot -> SQL 개발자를 위해 실시간으로 SQL을 NL로 변환해 보여줘서 디버깅

- SQL 교육용

- NL2SQL 개선용

a) NL2SQL 평가

b) NL2SQL Benchmark dataset audit

c) NL2SQL Finetuning과정에 활용

여기서 c)를 해볼 것이다.

RAG-Hybrid based -> Finetuning 용으로 제격이지만, cost 발생

Rulebased -> cost는 없지만 사람친화적인 NL을 만들진 못한다라는 특징

---> Finetuning에도 효과가 있나?? 위 Last 실험결과 보고 판단.

NL2SQL/SQL2NL과 관련된 논문 Reference들을 여기다가 많이 적으면 되겠다.

3. Background :

- 각종 용어 정의(NL2SQL, Finetuning / PEFT(LoRA) ,

- 나의 SQL2NL 방법 2가지 소개

- SQL2NL에 쓰인 Evaluation Matrix에 대한 설명 ( In Rag - Hybrid )

- 내가 사용한 SQL-to-Vec Embedding 이란? ( In Rule based )

Chapter 2 Background 부분도 좀 적어줘.
2.1 NL2SQL 이란?
2.2 SQL2NL 이란
2.2.1. SQL-to-Vec Embedding ( Function 구성 예시 Table 모양으로 제시 예정 )
2.2.2. RAG-Hybrid SQL2NL
2.2.3 Rule-Based SQL2NL
2.3 Finetuning / PEFT 란?
2.4 Model evaluation ( 2.2.2 -> BERT_Recall , BLEU_4 에 대한 설명, 2.2.3 -> NL2SQL을 이용해 평가한다는 설명, 2.3 -> 파인튜닝 후 BIRD Benchmark EX로 정확도 평가한다는 설명)

4. Motivation :

NL2SQL finetuning에 관한 연구를(Reference) 소개하고, 일반적인 LLM finetuning과정에 있어서 Data augmentation(Reference) 하는 것 소개하고, 틀린 문제에 대해서 LoRA 하는 것 소개하고(Reference)

이 틀린문제를 합성해내는데 위 SQL2NL 모델들을 사용하면 좋겠다는 생각이 들었다.

SQL2NL for NL2SQL 실험엔 Low parameter LLM을 썼는데, 그 이유는 파인튜닝의 효과를 좀 더 극적으로 보고 싶어서이다.

( Reference ) -> Parameter 개수에 따라 파인튜닝효과에 대해 정리한 논문

5. Methodology

- SQL2NL 소개, 실험 Flow Figure.

- RAG-Hybrid SQL2NL - 각 실험 Flow, Prompt Template 소개 Figure.

- Rule-based SQL2NL - 각 실험 Flow, Prompt Template 소개 Figure. - KSC발표와 연계.

- SQL2NL for NL2SQL - PEFT를 어떻게 할 건지 Flow Figure 소개. - 예비 발표때 사용했던 그림 참고

Chapter 4 Methodoloy
- 대충 설명
4.1 SQL2NL Framework
RAG-Hybrid SQL2NL의 경우 추론을 할 때 LLM prompt에 Input SQL과 관련된 DB Schema는 Metadata로 제공한다. 그리고 실험에 사용한 NL2SQL benchmark data에서 gold SQL / NL 제외하고 따로 Evidence도 제공이 되었다면, SQL2NL에도 그 evidence를 똑같이 제공한다. 모델에 쓰인 Prompt template은 Appendix를 참고한다. RAG-Hybrid의 실험 flow는 figure 4.1과 같다. 위 모델의 경우 Output이 NL이기 때문에 자연어가 얼마나 Semantic을 유지한체 잘 표현되었는지를 객관적으로 측정하는 것이 어렵다. 그래도 가장 이 분야에서 가장 유망한 BERT_Recall, BLEU(Referece)를 사용하였고 추가로 SQL을 현업에서 사용하는 Engineer에게 survey를 통해 Output NL에 대한 Human-based 평가를 실시했다.(그냥 할까 Human based 평가..)
RAG-Hybrid SQL2NL의 경우, RAG를 이용한 Few-shot candidates를 일부 추출 후 diff method를 통해 진짜 few-shot exemplars를 뽑아내는데, 이 때 RAG는 retrieve속도는 빠르지만 accuracy가 떨어지고 diff method는 1:1 compare라서 similarity 계산정확도는 높지만 계속 latency가 크다. 따라서 이 RAG retrieve sample과 diff method를 사용하는 sample의 개수를 적절히 조정하는 것이 accuracy조절에 큰 도움이 된다.

반면, Rule-Based SQL2NL의 경우 SQL을 NL로 변환할때 SQL의 AST기반으로 정해진 Parsing rule에 의해 SQL을 분석하므로 LLM의 추론과정 없이(LLM call cost가 없다) instant하게 SQL이 NL형태로 표현된다. Rule-Based SQL2NL로 인해 표현된 input SQL과 Output NL의 예시는 figure 4.2.1를 참고하라. 다만, 이 모델역시 평가가 필요한데, 이 때 SOTA LLM을 NL2SQL 모델로 이용해 SQL2NL의 output에 대해 평가하였다. 평가 로직은 figure4.2.2와 같으며 평가로직엔 RAG-Hybrid SQL2NL때와 같이 DB Schema metadata를 제공했고 필요에 따라 추론 evidence도 제공했다. 왜냐하면 Rule-based SQL은 편의상 사용된 SQL문 내의 alias를 있는 그대로 적어내고 DB내 column명도 있는 그대로 적어내기 때문에 DB schema metadata가 없으면 이 것을 효과적으로 사람의 언어에 친숙한 형태로 바꿀 수 없기 때문이다.
평가과정에서, GOLD NL을 추론한 것과 Rule-Based SQL2NL을 거쳐 나온 Pred NL을 추론한 것의 EX 결과 같으면 EX-hit이라고 판단하고(둘 다 EX=0 또는 둘 다 EX=1) Rule-Based SQL2NL을 이용하는 것이 SQL과 NL사이 Sync를 잘 맞추는 것이라 판단해서 이를 측정했다. 그리고, Benchmark 별로 Pred NL , Gold NL의 NL2SQL EX 값도 동일한 환경에서 체크했다. Rulebased SQL2NL의 EX 값 결과가 또 어떻게 분석될 수 있을지는 Experiment chapter에서 다루겠다.

4.2 SQL2NL for NL2SQL
(Prompt에 Self correction을 넣었다는 것도 추가 -> Figure로 추가 , logic flow도 figure로 추가, Rule-based / zeroshot / RAG-hybrid)

SQL2NL for NL2SQL은 SQL2NL을 NL2SQL 성능향상을 돕기 위해 사용하는 것이다. 이를 특히 NL2SQL의 Finetuning과정에 사용해보기로 했다. 파인튜닝 효과를 dramatic하게 확인해보기 위해 parameter는 3b 수준의 low level의 LLMs를 base로 이용했다. 기본 Naive LLM에서 FULL SFT도 진행해보기도 했고, 다른 한 실험은 NL2SQL training과정에서 wrong answer인 부분에 대해서 위 SQL2NL을 이용해 해당 건을 Augmentation을 통해 유사한 NL-SQL dataset 10개를 각 wrong case마다 만들어서 train이 끝난 후 다시 해당 문제들로 PEFT를 돌려서 효과가 있는지 확인해보았다. 이 오답위주로 PEFT하는 실험 logic flow는 Figure 4.2.1을 참고하면 된다. NL2SQL 실험 prompt엔 기본적으로 SQL2NL때와 마찬가지로 Schema linking을 적용시켰으며 low parameter라 오답률이 너무 높아 sql self correction(referenece + 이에대한 설명 추가) 을 prompt에 추가했다. 이 prompt template도 뒤 Appendix에서 확인할 수 있다. 그리고, specific하게, SQL2NL을 활용한 data augmentation이 효과가 있는지를 확인하기 위해서 다양한 Finetuning을 시도할 때 실험 대조군으로 이 실험에서 다루어진 SQL2NL 기법이 사용된 것 외에 그냥 단순 prompt로 Naive하게 LLM에게 data augmentation을 요청한 것을 선정해서 비교실험을 진행했고 우리는 이 케이스를 zero-shot case로 명명한 뒤 비교실험을 진행했다.

6. Experiments

- 1) RAG-Hybrid SQL2NL Setting / Graph / Table -> Humanbased 평가 추가

- 2) Rule-Based SQL2NL Setting / Graph / Table

- 3) NL2SQL Finetuning - Llama3.2 3b 수준이라 Evaluation 정확도 절대값은 낮다. 다만 accuracy상승폭은 좀 더 잘 확인할 수 있으니 참고하자.

실험결과 분석

또한, 이 SQL2NL모델을 이용해서 만든 Pred NL의 NL2SQL EX를 분석해보면, 벤치마크의 난이도별로 결과가 달라지는 것을 알 수 있다. 우리의 실험에선 상대적으로 난이도가 쉬운 Spider1.0과 난이도가 어려운 BIRD dataset을 이용했는데, 난이도가 쉬운 Spider1.0에선 거의 100%에 가까운 Nl2SQL정확도를 얻을 수 있었고 BIRD에선 그렇지 않았다. 이는 Rule-based SQL2NL을 이용해서 Benchmark의 난이도도 평가할 수 있고, 또 Benchmark dataset 자체에 대한 신뢰성도 확인해볼 수 있다는 것이다.

- SQL2NL for NL2SQL

a. 실험 Setting

b. LoRA configure

c. 유효성 보여주기 with Table / Graph --> 2) 위 Last Rule Based 실험 결과에 따라 마지막으로 실험데이터 추가여부 결정

다시 정리해보자,

일단 구성은

5.1 Experimental Setup

실험 Dataset은 크게 BIRD와 Spider 1.0을 사용했다. 조금 더 난이도가 높은 Spider 2.0 , Beaver 등의 Benchmark를 이용한 실험은 이 논문연구 이후에 Futurework로 남긴다. RAG Hybrid와 Rule based SQL2NL Model 자체에 대한 실험을 진행할 때는 BIRD, Spider 1.0 dataset을 모두 사용했고, NL2SQL finetuning 실험에선 BIRD dataset만 사용했다. Spdier 1.0의 경우 dev set 1034ea, BIRD의 경우 dev set 1534ea를 사용했다. Finetuning 실험에선 BIRD dev set 1534ea 중 100ea를 test data로 관리하고 1434ea를 training data로 사용했다. 그리고 Wrong case에 대해서 data augmentation은 각 case 당 10개를 새로 SQL2NL 합성을 했다. RAG-Hybrid 내에서 각 case 별로 정확도 측정하는 것과 Rule-based SQL2NL model 정확도 측정은 LLM output variance를 고려하여 모두 각각 5회씩 실시해서 mean 값을 측정했다. Finetuning 실험 역시 tuning후 3회 독립적으로 평가를 실시한 뒤 EX의 mean값을 측정했다.

RAG Hybrid의 경우 SQL-to-Vec embedding feature는 100개를 선정했고, Vector DB로는 FAISS, similarity 계산은 Jaccard를 사용했다.

RAG Hybrid의 경우 LLM으로 GPT-5-mini를 사용했고(Reference) , Rulebased model 평가용 NL2SQL도 GPT-5-mini를 사용했다. NL2SQL Finetuning엔 Meta의 Llama3.2 3b 모델을 사용했으며 huggingface를 이용해 base model, fine tuned model을 관리했다. BIRD Dev set을 이용해 NL2SQL Finetuning을 진행할 때의 Finetuning setting 값과, Training loss graph는 아래 Figure 5.1.1 을 참고하라.

5.2 Overall Results of the SQL2NL

첫 번째로, RAG Hybrid SQL2NL과 관련된 실험결과를 공유하자면 실험은 우리의 예상대로 RAG-Hybrid기법을 적용시켰을 때 가장 정확도가 높았다. BIRD, Spider 각각에서 test용 data 10개를 제외하고 나머지 SQL-NL pair data를 vectorDB에 embedding 시켜 놓은 뒤 few-shot은 Random, RAG only, RAG Hybrid의 방법으로 각각 5개씩 뽑았다. 특히 RAG Hybrid를 할 때에는 일차적으로 Candidates 100개를 뽑은 뒤에 거기서 diff method를 통해 5개의 few-shot exemplar를 선정했다. Human based 평가의 경우(첨부 사진을 참고해서 Excellent ~ poor 까지 각각이 의미하는 것을 설명해) SQL을 현업에서 사용하는 Engineer들 interview를 통해 5단계로 SQL2NL 변환 정확성을 평가한 것의 the most 응답을 선정했다. GPT, LLama 두 LLM에서 BIRD, Spider 모두 RAG Hybrid SQL2NL 변환정확도가 제일 높은 것을 확인할 수 있었고 자세한 값은 Table5.1, 5.2를 확인하라.

그리고 추가로 각 Case 별로 Few-shot selection time도 비교해보았다. Figure5.2를 보면 알 수 있듯이 RAG의 Retrieval 속도는 Random 함수와 크게 다르지 않았다. 반면 RAG, VectorDB를 사용하지 않고 전체 Candidate 데이터들을 diff을 통해서 1:1로 비교하는 것은 dramatic하게 latency가 발생하며 RAG Hybrid가 타협점임을 알 수 있다.

%%%%%%%%%%%%%%% Rule Base SQL2NL %%%%%%%%%%%%%%%%%%%%

Rule basd SQL2NL은 Figure 4.1.2와 같이 SQL을 기계적으로 NL로 표현한다. 따라서 NL output을 gold output과의 semantic 유사도를 비교하는 BERT나 단어 일치도를 평가하는 BLEU 지표사용은 무의미하다. 하여, 우리는 Figure 4.1.3과 같이 NL2SQL model을 이용해서 PredNL, GoldNL을 모두 input으로 넣은 뒤 이 둘의 결과가 (EX=1 or EX=0) 같으면 EX_hit을 count했고, 이 EX_hit이 높을수록 Rule based SQL2NL은 LLM 입장에서 Gold NL과 유사한 input을 받았다고 판단할 수 있다. BIRD , Spider의 EX hit ration graph는 figure 5.2.2 와 같다. 각 벤치마크별로 5회 try를 했는데 BIRD에선 80% 이상, Spider에선 85% 이상의 hit-ratio를 보였다. 또한, 이 Rule Based SQL2NL을 이용해 NL2SQL + EX를 측정해보았는데, 이론상으론 SQL을 있는 그대로 NL로 옮겨담은 것이기 때문에 거의 100%에 가까운 NL2SQL EX가 나와야 하는데 Table 5.3 을 보면 Bird에선 그렇지 않은 것을 볼 수 있다. 이 점이 시사하는 바는 뒤 Analysis에서 다루겠다.

5.3 NL2SQL Finetuning with SQL2NL

이번엔 위 SQL2NL 모델을 이용해서 NL2SQL task를 enhance해보는 것을 실험해본 결과를 소개하겠다. 실험세팅은 Experimental Setup chapter를 참고하면 되고, 실험의 골자는 SQL2NL을 NL2SQL task finetuning에 이용해보는 것이다.

첫 번째 실험은 Full SFT을 해봤는데, LLM을 dev set으로 training하는 것과 같은 수량의 데이터를 SQL2NL을 이용해 dev set을 synthesize한 data를 training하여 서로 성능을 비교해봤는데 synthesize한 data를 FT할때 성능이 더 좋지 않았다. 아직 SQL2NL도 error rate이 있어서 완전히 dev set을 대체할 정도로 퀄리티가 좋진 않다는 것이며 결과는 Appendeix를 참고하라.

이번엔 Main point로 NL2SQL을 dev set으로 학습하는 과정에서 틀린 문항에 대해서 SQL2NL로 data augmentation을 한 뒤 추가로 PEFT실험을 해보았다. RAG-Hybrid SQL2NL로 합성한 뒤 PEFT를 했을 땐 정확도 소폭 상승하였고 이는 Naive하게 동일한 Wrong case를 합성한 뒤 PEFT했을 때보다도 정확도 상승폭이 컸다. 이는, 우리의 SQL2NL 모델이 input SQL에 대해서 Semantic하게 정확한 NL을 생성해내고 그 pair dataset은 SQL , NL 사이의 결합력이 좋다는 것을 의미한다. 반면에 Rule-based SQL2NL을 이용한 PEFT는 아무래도 output NL이 User case NL과는 비슷하지가 않아 PEFT에는 적합하지 않았다. 자세한 실험결과는 Table 5.4를 참고하라.

추가로, Wrong case가 아닌 이미 training dataset 1434ea로 파인튜닝된 모델에 추가로 또 1434ea data를 서로다른 SQL2NL 기법으로 합성하여 PEFT한 뒤에 EX performance비교도 해보았따. Figure5.3.1을 참고하라.

5.4 Analysis

Rule based에서 BIRD SQL2NL Accuracy가 70%인건 gold error라고 판단한다 -> 벤치마크 audit성능 좋을듯. TBD

위 일련의 실험내용을 분석해보면, LLM을 이용한 SQL2NL은 RAG-Hybrid가 적합하고 User가 능동적으로 RAG Candidates sample을 정함으로써 retrieve time을 조정할 수 있다는 측면에서 자유도가 높은 장점이 있다. 그리고 특정 domain (이 실험에선 BIRD, Spider) 에 Gold dataset이 많으면 많을수록 이 방법은 refer할 dataset이 vectorDB에 많아지니까 정확도는 올라갈 것이다. 즉, 위 기법에서 prompt만 조금 다듬으면 특정 사업에서 꽤나 정확하게 SQL을 NL로 변환시키는 task를 만들 수 있다는 것이다.

Rulebased SQL2NL은 cost가 들지 않다는 장점은 있으나 PEFT에 쓰이기엔 부적합하다는 결론을 내렸다. 하지만, Table5.3을 잘 보면 SQL2NL Accuracy로 BIRD, Spider 등 벤치마크를 audit하는데 좋은 역할을 할 수 있다. BIRD의 경우 지금 정확도가 70.2%가 나오는데 실제 BIRD dev set의 Gold error가 20~30%는 존재한다(Reference 추가 https://aclanthology.org/2024.acl-short.34.pdf) 즉, 다양한 NL2SQL 벤치마크에 Rule based SQL2NL을 돌려보면 해당 벤치마크의 gold NL과 gold SQL사이 연관성이 얼마나 있는지 체크할 수 있는 것이다..

NL2SQL for SQLNL 측면에선, 역시 Wrong case만을 PEFT하는 것의 효과가 있었다. 다만, SQL2NL 정확도가 좋지않은 zero-shot이나 Rule-based의 경우엔 되려 파인튜닝을 진행하는 것이 EX 값이 낮아지는 것을 가져왔다. 즉, SQL2NL을 PEFT에 쓰려면 잘 갈고 닦인 SQL2NL model을 가져와야 할 것이다.

6. Conclusion

Summary :

SQL2NL을 어떻게 할 수 있는지 2가지 방법을 제시했고 각 방법에 대한 상세한 내용을 제시했다.

그리고 나아가 이 SQL2NL을 NL2SQL task에 활용하는 SQL2NL for NL2SQL에 대해서 고민했다.

RAG Hybrid의 경우 Data augmentation을 통해서 NL2SQL의 finetuning과정에 활용될 수 있고 효과가 있는 것을 확인했다. 반면 Rule based SQL2NL의 경우 PEFT쪽에선 효과가 좋지 않지만, NL2SQL benchmark audit이나 즉각적으로 SQL을 NL형태로 표현해서 SQL engineer의 개발자용copilot 형태로 쓰일 수 있을 것이라 기대한다.

Futurework:

Gray Space가 너무 많다. 더 다양한 LLM, Parameter, Benchmark, Finetuning Configure을 이용해서 실험을 돌려보고 비교분석 해보고 싶었으나 시간적/경제적 한계가 있었다. 기회가 되면 나의 이런 실험 Logic이 다양한 실험 Setting에서도 유요한지 꼭 재확인을 해봐야 한다.

추가적으로, 사람의 언어는 SQL보다 이해하기가 어렵다. 왜냐하면 SQL은 Syntax rule에 완전히 종속적인 언어이지만, NL은 언어별로 확장성이 너무나도 크고, 국가별로 언어 특징도 매우 다르기 때문이다. 따라서 SQL을 LLM의 Input으로 넣었을때 좀 더 우리가 원하는 결과값을 잘 유도해낼 수 있을 것이다. 하여, SQL2NL 분야는 기존 NL2SQL이 갖는 NL input에 대한 모호성 문제를 뛰어 넘어 좋은 성과를 가져올 것이고, 이것을 NL2SQL에 나의 연구처럼 잘 적용시키면 NL2SQL의 performance를 끌어올릴 수 있는 게임체인저가 될 수 있을 것이라 생각한다.

7 Appendix

-> 실험 Code 예시 / 실험 Prompt Template / SQL-to-Vec function / Rule-based SQL2NL 예시 -> KSC 연동

구체화

--> SQL2NL RAG-Hybrid Prompt Template - 앞에서 언급했어서 무조건 必

--> NL2SQL for SQL2NL에서 self correction을 사용한 prompt - 앞에서 언급했어서 무조건 必

--> 실패한 실험, 가령 Rule based를 Full로 FT했더니 되려 정확도 낮아지고 그런거.. 그냥 FULL FT는 Rule base, RAG Hybrid 전부 포함해서 결과 차트 하나[FIGURE] 올리고, 아직 dev set을 완전 대체할만큼은 아니라고 언급하자, SQL2NL Error rate이 존재하니까. - 앞에서 언급했어서 무조건 必

8. Bibliography : 출처

9. 국문초록

위 Flow로 이제 오버리프 작성하면 된드아...........!!

추가로 해야할 건, Figure / Table 잘 뽑기 + 오버리프 템플릿에 잘 맞춰서 규격? 통일시키기

[논문작업] SQL2NL for NL2SQL (2)

eatplaylove — Wed, 10 Dec 2025 10:54:14 +0900

https://eglife.tistory.com/372

[논문작업] SQL2NL for NL2SQL (1)

너무 놀았다.. 이제는 피할 수가 없는 졸논작업 박사에 비하면 큰 관심이 없는 게 석사논문이기도 하고,, 사실 내가 경력채용으로 가려고 하는 분야와 크게 주제가 맞진 않지만 석사과정은 자고

eglife.tistory.com

위 (1) 편에서 엄청나게 고민해봤지만, Rule based SQL2NL을 NL2SQL에 어떻게 이용해야 할 지 감이 잡히지가 않는다.

기존 KSC 논문에서도 Rule based 기법을 Finetuning하는 것은 고려하지 않았었다...

지난 1화 정리본 요약

이게 Finetuning에만 집착하면, Rule-based를 쓰지 못 한다.

그리고, Rule-based를 쓰지 못하면 예비논문심사 이후 개선점을 어필할 수가 없다.

그라하여.. 그냥 논문구성을

" 나 SQL2NL 이렇게나 다양하게 연구해봤어요~ 각 모델의 특성은 이러이러하고 성능은 이 정도에요~ "

→ " 각 모델을 NL2SQL을 위해서 이런이런 방법으로 적용시킬 수 있겠네요~ "

이렇게 해야겠다.

그래서, 위 'a'은 진짜 NL2SQL Finetuning에 넣어보고 'b'도 이왕 하는 거 같이 파인튜닝해보고 효과가 없으면 얘는 파인튜닝단계에선 빼야겠다.

그리고 SQLCopilot으로 쓸 수 있다는 말을 언급하고, NL2SQL Benchmark NL-SQL pair data 감시용으로 쓰일 수 있는 case를 몇 개 보여주자.

아니면,,

논문구성을 먼저하는 것보다 이것저것 실험해보고, 결과에 따라서 유의미한 것만 취사선택해서 논문을 써야겠다.

혹시 a, b 둘 다 파인튜닝에 효과가 있을 수도 있으니까 말이다.

Spider2.0은 너무 빡세다.. 아래는 Spider2.0 예시 1개.. 진짜 아무거나 Pick했는데도 허덜덜한 난이도..

WITH
  ref AS (
    SELECT DATE '2021-10-01' AS "ref_date"
  ),
  users_base AS (
    SELECT
      "id" AS "user_id",
      CAST(TO_TIMESTAMP("creation_date" / 1000000.0) AS DATE) AS "creation_date_dt",
      "reputation"
    FROM "STACKOVERFLOW"."STACKOVERFLOW"."USERS"
  ),
  users_filtered AS (
    SELECT ub.*
    FROM users_base ub
    JOIN ref r ON 1=1
    WHERE ub."creation_date_dt" <= r."ref_date"
  ),
  users_years AS (
    SELECT
      "user_id",
      "creation_date_dt",
      "reputation",
      (DATEDIFF(year, "creation_date_dt", r."ref_date")
        - CASE WHEN DATEADD(year, DATEDIFF(year, "creation_date_dt", r."ref_date"), "creation_date_dt") > r."ref_date" THEN 1 ELSE 0 END
      ) AS "complete_years"
    FROM users_filtered uf
    JOIN ref r ON 1=1
  ),
  badges_per_user AS (
    SELECT
      "user_id",
      COUNT(*) AS "num_badges"
    FROM "STACKOVERFLOW"."STACKOVERFLOW"."BADGES"
    GROUP BY "user_id"
  )
SELECT
  uy."complete_years" AS "complete_years",
  COALESCE(CAST(AVG(uy."reputation") AS FLOAT), 0) AS "avg_reputation",
  COALESCE(CAST(AVG(COALESCE(b."num_badges", 0)) AS FLOAT), 0) AS "avg_badges",
  COUNT(*) AS "user_count"
FROM users_years uy
LEFT JOIN badges_per_user b
  ON uy."user_id" = b."user_id"
GROUP BY uy."complete_years"
ORDER BY uy."complete_years" ASC;

뭔가 어거지로 틀리게 하려고 만든 Text-to-SQL 같기도 하고.. 일단 Spier1.0과 BIRD에 집중하는 걸로 하자.

(Spider2.0 Dataset을 받아놓긴 했음)

Fine-tuning 관련 사전지식

1. Fine-tuning : 이미 사전학습된 LLM의 가중치를 작게 조정해서 특정 Task에 맞춘다. 데이터가 수천~수만 건이어도 효과가 크고, 비용시간 측면에서 효율적이다. 보통 PEFT ( LoRA / QLoRA )로 일부 가중치 또는 어댑터만 학습시킨다.
※ OpenAI 계열 모델은 API로 파인튜닝을 지원해서 로컬에서 미세조정은 불가하다.

2. GPT 계열을 파인튜닝하는 방법
- OpenAI API로 파인튜닝한다. 배포/EarlyStopping/모니터링은 OpenAI에서 제공한다
https://platform.openai.com/docs/guides/supervised-fine-tuning?utm_source=chatgpt.com
- 로컬 PC에선 Llama 등 오픈소스 GPT-아키텍처를 학습시키거나 Hugging Face에서 Transformer를 따와서 학습시킨다.
※ SFT란 Supervised Fine-tuning (지도 미세조정) 이라는 뜻으로, LLM에 정답(Gold data pairs)을 주고 정답을 맞추도록 일반적인 지도학습(Cross-entropy)을 통해 미세조정하는 단계.

3. Hugging Face로 파인튜닝하는 법
- Dataset 로딩 : datasets로 JSON/JSONL 파일 불러오기
- 모델/토크나이저 : AutoModelForCausalM, AutoTokenizer을 Load
- PEFT 설정 : LoraConfig ( r = ... , alpha = ... , target_modules = [ "q_prj" , "v_prj" ,,, ] )
- 양자화 (Optional) : bitsandbytes 로 4-bit 로더 (QLoRA)로 VRAM 절약
- 학습 : TRL SFTTrainger로 학습 / 검증
- 저장/배포 : 어댑터 (수MB ~ 수백MB)를 저장하고, 필요 시 Hugging Face Hub에 push_to_hub()로 Upload! (베이스모델에 어댑터만 얹어서 재현한다.)

4. 파인튜닝 시 GPU 必 ?
- Open API로 SFT한다면 GPU 신경쓸 필요 X
- 하지만 Hugging Face로 실험해야 Local 반복 실험 / 세밀제어에 유리하다.
- Hugging face QLoRA기준 ~7B 모델은 16GB VRAM 권장, 13B는 24GB VRAM권장, GPU의 경우는 RTX 4090 권장.

5. 파인튜닝시 특정 Domain 별 학습데이터 수
- 특정 도메인 한정이라면 + 질 좋은 Data set이라면 수천개여도 충분

졸업 전에, Hugging Face를 함 써보고 싶긴 하다만..

일단 GPT로 파인튜닝을( 약간의 과금은 있지만 ㅎㅎ.. ) 쉽게 해보자.

실험 돌려! 데이터 뽑아!

( Schema Linking [Metadata제공] 과 기본적인 Prompt는 고정 )

0. SQL2NL RAG based 정확도측정 다시 - GPT-5-mini [어차피 LLM기반 SQL2NL이면 GPT-5-mini로 고정하자]

: RAG Embedding Spider2.0 고려해서 feature 추가, BERT/BLEU/Time Graph, Table + Human based평가 제시

0-2. SQL2NL Rule based 정확도측정 다시 - GPT-5-mini [ NL2SQL을 이용한 SQL2NL 검증용 ]

: 내가 평가지표로 알아봤던 EX-hit ratio라는 개념 설명 꼼꼼하게 必

※ Issue 발생 : Open AI GPT API 로는 PEFT가 되지 않는다.
※ 급하게 Hugging Face + Llama 조합을 찾아봐야 할듯..

1. 그냥 Naive LLM으로 NL2SQL 정확도 측정해보기(BIRD_dev, Spider1.0, 가능하다면 Spider2.0) - 能

1-a . Naive LLM을 그냥 Dataset으로 파인튜닝해보기 ··· Model 'a' 저장

: NL2SQL 정확도 측정

1-b . ' a ' 에다가 위 0번으로 PETF 시도 ··· Model 'b' 저장 - 中 ( Hugging Face + Llama 빠른 적응 必 )

: NL2SQL 정확도 측정

1-c . ' a ' 에다가 위 0-2 번으로 PETF 시도 ··· Model 'c' 저장

: NL2SQL 정확도 측정 ··· 정확도 후질걸로 예상, 생각보다 후지면 논문에서 빼기

1-d . ' Naive LLM ' 에다가 위 0-2 번으로 PETF 시도 ··· Model 'd' 저장

: NL2SQL 정확도 측정 ··· 어떻게든 0-2번을 활용해보려고 시도, 생각보다 성능 후지면 논문에서 빼기

1-e . ' a ' 에다가 1-b에서 PEFT 한 만큼 추가 학습 Data를 추가해서 PEFT 시도 ··· Model 'e' 저장

: NL2SQL 정확도 측정 ··· 1-b 비교군

2. 결과정리 :

- 각 Try의 결과를 xlsx로 뽑고 Graph , Table 규격 통일해서 Overleaf 스타일로 쭉쭉 데이터 뽑기

- 위 결과에 따라 0번 0-2번이 모두 유효하면 둘 다 실험결과 Data를 제공, 0-2번은 NL2SQL Finetuning에 그닥 영향이 없다면 0-2번 활용안은 그냥 SQLCopilot, NL2SQL Benchmark audit 정도로 언급만 하기

하나씩 그어가면서 Check list 관리해보기

~~( Schema Linking [Metadata제공] 과 기본적인 Prompt는 고정 )~~
0. SQL2NL RAG based 정확도측정 다시 - GPT-5-mini [어차피 LLM기반 SQL2NL이면 GPT-5-mini로 고정하자]
~~: RAG Embedding Spider2.0 고려해서 feature 추가, BERT/BLEU/Time Graph, Table + Human based평가 제시~~
0-2. SQL2NL Rule based 정확도측정 다시 - GPT-5-mini [ NL2SQL을 이용한 SQL2NL 검증용 ]
~~: 내가 평가지표로 알아봤던 EX-hit ratio라는 개념 설명 꼼꼼하게 必~~

1. 그냥 Naive LLM으로 NL2SQL 정확도 측정해보기(BIRD_dev, Spider1.0, 가능하다면 Spider2.0) - 能
------------------> Huggingface에서 Llama3,2? Model 사용하기................

1-a . Naive LLM을 그냥 Dataset으로 파인튜닝해보기 ··· Model 'a' 저장
: NL2SQL 정확도 측정

1-b . ' a ' 에다가 위 0번으로 PETF 시도 ··· Model 'b' 저장 - 中 ( Hugging Face + Llama 빠른 적응 必 )
: NL2SQL 정확도 측정

1-c . ' a ' 에다가 위 0-2 번으로 PETF 시도 ··· Model 'c' 저장
: NL2SQL 정확도 측정 ··· 정확도 후질걸로 예상, 생각보다 후지면 논문에서 빼기

1-d . ' Naive LLM ' 에다가 위 0-2 번으로 PETF 시도 ··· Model 'd' 저장
: NL2SQL 정확도 측정 ··· 어떻게든 0-2번을 활용해보려고 시도, 생각보다 성능 후지면 논문에서 빼기

1-e . ' a ' 에다가 1-b에서 PEFT 한 만큼 추가 학습 Data를 추가해서 PEFT 시도 ··· Model 'e' 저장
: NL2SQL 정확도 측정 ··· 1-b 비교군

2. 결과정리 :
- 각 Try의 결과를 xlsx로 뽑고 Graph , Table 규격 통일해서 Overleaf 스타일로 쭉쭉 데이터 뽑기
- 위 결과에 따라 0번 0-2번이 모두 유효하면 둘 다 실험결과 Data를 제공, 0-2번은 NL2SQL Finetuning에 그닥 영향이 없다면 0-2번 활용안은 그냥 SQLCopilot, NL2SQL Benchmark audit 정도로 언급만 하기

SPIDER2.0 -> NL2SQL 응답을 위해 다른 외부 저장소에서 Hint ( md , txt file 등 ) 를 긁어와야 함. 너무 번거롭다 : 제외

BEAVER : 난이도가 너무 높다... 제외.. DataWarehouse data라 SQL이 너어어무 길다..

실험은 VScode 여러개 띄우고 병렬로 진행해야겠다.. 생각해보니 GPT 맥여서 하는 실험은 병렬로 진행이 가능허다.

0 번의 경우도 BIRD / Spider 각각 코드를 다르게 짜야해서.. 일단 BIRD만 새로이 짜봤다. 굳이 같은 실험을 많이 할 필요가 있는가

몰랐는데, Huggingface에서 API로 LLM 접근하려면 gated repository에 대해서 access 신청을 해야한다.

그냥 이름이랑 생년월일 학교 직업 정도의 정보를 제공했는데 언제쯤 Access해주려나~

Access는 완료됐다. 근데 생각보다 NL2SQL을 했을때, Model이 DB에서 돌아가는 SQL을 만들어내질 않는다.. 모델 Parameter가 3B로 작아서 그런가.. 당황스럽다 -_-

하 Llama는 또 GPU 환경 아니면 돌아가지 않는다. 일단 Google colab으로 급한 불 끄는중..ㅠㅠ

Colab으로 하는 것도 좀 느리고.. 무엇보다 중간에 튕기는 경우가 많아서 그냥 RunyourAI를 쓰기로 했다.

70b 이상의 High parameter model의 경우 모델 다운받는데만 시간이 너무 소요되기에 과감히 SKIP

이제는 진짜 논문 쓸 시간도 없다 ㅋ...

일단 여기서 중간과정 마무리

조졌다

[논문작업] SQL2NL for NL2SQL (1)

eatplaylove — Thu, 27 Nov 2025 20:22:56 +0900

너무 놀았다.. 이제는 피할 수가 없는 졸논작업

박사에 비하면 큰 관심이 없는 게 석사논문이기도 하고,,

사실 내가 경력채용으로 가려고 하는 분야와 크게 주제가 맞진 않지만

석사과정은 자고로 '연구하는 방법'을 익히는 시간이라고 하지 않던가!

너어무 놀았지만, 그래도 이러쿵 저러쿵 연구했던 지난 날의 흔적들을 다 모아보는 시간이라 자기만족을 위해서라도 좀 유의미하게 내용을 정리해야 한다.

일단, 초록발표 + 예비심사는 끝났고.. 그 때 발표했던 내용을 필두로 논문작업을 해야한다. 꽤나 내용이 많으니까 시간 있을 때 조금씩 적어놔야 나중에 덜 버벅거릴 거 같다. 엄청난 규모의 텀프로젝트라고 보면 된다.

1. 틀잡기

논문틀은 국룰이 있다. 기타 규격들이 다 반영된 #Overleaf Latex를 쓰는 것이 백 번 쉽다.. 그냥 워드/한글로 쓰는 것과는 비교가 불가할 정도로 편하다.

논문의 목차, Content는 아래와 같이 구성하며 기본적으로 English로 적는다. Global 시대에 맞게 ㅎ

- 표지 / 인준

- Abstract : 예비심사 때와 유사하게 쓰면 될 듯

- Contents (목차)

1. Introduction : 주절 주절 설명하면 됨
2. Background : NL2SQL , SQL2NL 동향을 쭉 쓰면 될 듯
3. Motivation : SQL2NL의 중요성, 가치가 올라간다.. 를 쓰면 될 듯
4. Methodology : 실험 Flow 등을 여기서부터 슬 Figure로 포함하면 될 듯. 실험 Evaluation이 관건인데 이걸 어떻게 할 지를 명확하게 써야 한다. Matrix를 쓴다면 어떤 친구를 쓸 지, 그리고 Human based 평가를 한다면 어떤 기준으로 Reviewer를 선정할지 등등
--> Fiinetuning까지 활용하냐? 이거 중요....

5. Experiments : 실험Setting과 결과에 대한 얘기니까, 사실 여긴 Figure / Table 외에는 내용적으론 들어갈 말이 없다.

6. Conclusion : 국룰! 좀 더 많은 Domain에서 실험이 필요하다. 다양한 LLM에서 실험이 필요하다 등등으로 마무리. 그리고 우리 연구의 장점/시사점을 언급하며 마무리

7. Appendix : 실험에 쓰인 Prompt, 실제 Gold / Pred Query 등등, Rule based 코드 등을 쓰면 될 듯

- Bibliography (출처)

- 국문초록

2. 내용구성

진짜 오랜만에 연구를 하려니까 내용을 좀 까먹었다..

다시 한 번 Remind 해보자... 얼른 실험같은 거 끝낼 거 끝내고, Data도 뽑을 거 다 뽑아놔야 맘편히 쉴 수 있다.

기본적으로 Table , Figure도 각 4~5개씩은 들어가야 할 것이고, 논문 설명용 그림도 PPT를 쓰든 뭘 쓰든 해서 적어야 하고,

Prompt 같은 것도 논문에 적합하게 다 Figure 형태로 써야 하는데 갑갑하기 그지 없다.

일단 내용구성부터..

Finetuning실제로 하냐 안 하냐가 차이가 크다...!

SQL2NL은 KDBC까지의 내용이 지금까지 달려온 부분이고, KSC에서 Rule-based SQL2NL 부분을 좀 추가하긴 했다.

예비심사 발표 기준으로, 나의 연구방향

여기서 1st step은 SQL2NL을 하는데, NL2SQL Task를 그대로 이용하는 것이다. 주로 Dataset은 BIRD / Spider를 이용했고 학위논문엔 Spider 2.0을 추가하는 것을 검토해보자.

그리고, 학위논문에 Step1 RAG부분은 넣고 싶다. Text2Vec을 처음 사용했다는 것은 좀 유의미하다고 판단해서 그렇다.

Text2Vec Embedding용 Function의 일부도 Appendix에 넣기..!

Step1의 내용은 사실 KDBC선에서 다 끝났고,

거기서 추가로 받은 예비심사 피드백이 요건데

이것을 반영한 Rule based Output을 만드는 놈은 KSC에서 논문을 썼다.

(진짜 무진장 놀았는데도, 중간에 할 건 했나보다 나란 사람도 ㅋ ;; )

KSC 에서도 내 기억이 맞다면 SQLGlot 기준으로 SQL->AST구조->Rule based parsing을 진행했었고, .Evaluation은 다른 Nl2SQL (그냥 Naive LLM 썻었음 귀찮아서 ;;) 을 이용해서 결과를 평가했었다.

어쨌든 결론적으로 Step1 과 예비심사요지에 대해선 KDBC / KSC 논문을 좀 다듬으면 Data좀 나올 거 같다.

++) 추가로 해야하는 건 Spider 2.0 Data추가하기 --> Dev set이든 뭐든 Data를 1K이상 구해서 Sampling 해놓자... 이것 때문에 논문이 너무 길어진다 싶으면 "Evaluating NL2SQL via SQL2NL" 논문을 참고해서 결과를 Appendix에다가 넣어도 될듯하다. 역시,, 잘 만들어진 top-tier 논문 하나만 잘 follow-up해도 학위논문 하나는 뚝딱 만들 수 있는 거 같다.

이제 문제는 Step2 Fine-tuning이다... 사실 지금껏 Fine-tuning을 해본적이 단 한 번도 없어서, 이번 분기 채용준비(이직ㅋ)를 하면서 동시에 모델링 작업하며 경험을 자소서나 Project 파일에 녹일려고 했는데, 전부 Cut당해서 의욕이 없었다.

그래도.. 명색이 Datascience를 공부하고, MLDL 강의를 수강했던 사람인데 Model finetuning 한 번 안 해보고 졸업하는 건 너무 짜친다. 그래서 시도는 해봐야 할듯

Step1에서 잘 만들어진 SQL2NL 모델을 NL2SQL Model 의 Data augmentation 용으로 사용해보자는 것이다.

실험할 건 많은데, 어떤 실험이 중요하며, 진짜 다 필요한 실험인가.. 와 내용구성을 어떻게 할 지 정해야겠다.

논문이 무슨 실험레포트도 아니고 중구난방으로 실험값만 늘여놓으면 의미가 너무 퇴색된다.

어떻게 해야 깔끔하게 논문을 쓸 수 있을 지좀 보자..

To-do list

1. Dataset 확보
기존 BIRD / Spider 1.0 Dev set 일부만 쓰던 것 -> Spider 2.0 Pair set 일부 추가 ( 1K 이상 )

2. 내가 실험적으로 보여줄 것

a. LLM을 통한 SQL2NL 최적화
: 기존 KDBC논문활용 + 내용추가 / SQL-to-Vec Embedding 개념 소개 -> Background 또는 Methology + Embedding function code는 Appendix에 후첨 / Schema Linking는 기본으로 깔고, Few-shot prompt를 RAG + 1:1 diff function(AST구조 설명도 추가) 하는 Hybrid방식 소개 / 이거 평가는 간단하게 BERT / BLEU Matrix 활용 기존처럼. 그리고 시간차이도 보여주기.(KDBC논문 적극참고) 다만, Figure는 GPT랑 쌔쌔쌔해서 잘 만든다쳐도, Table같은 경우는 Overleaf Template에 맞게 설정 잘 하기.

b. LLM없이 SQL Parsing Rule based SQL2NL 방식
: 기존 KSC 논문을 활용한다 + 내용추가 / Parsing 된 형태를 Figure로 제시(KSC논문 적극참고) / 이건 NL2SQL Model을 이용해서 정확도를 평가한 것... 요런 방식도 활용방안이 있으며 LLM call 없으니까 편하다고 제시,,

c. SQL-to-NL for NL-to-SQL(이게 관건!!) 위 a , b는 지금까지 SQL2NL에 대한 LLM이 있냐 없냐로 나눌 수 있는 서로 다른 모델을 제시한 것이다. 이제 이것들을 논문제목에 맞게 NL-to-SQL에 활용할 수 있어야 하는데.. 얼른 Fine tuning을 진행해야 한다.
PEFT 를 잘 공부해서 NL2SQL Model ( 그냥 SOTA Naive LLM 사용하자..) 이 틀린 문제에 대해서 SQL2NL을 이용해 Data augmentation을 하고 이놈을 PEFT로 추가 학습시키는 것.

C 中 '비교군'
1. Naive LLM ( Finetuning 자체가 효과가 있는지 없는지 비교하는 용도 ) --> 이것도 정확도 몇 개 뽑아놓자 아니면 Data massage
2. Naive LLM + 일반적인 Finetuning 1 cycle
3. Naive LLM + 틀린 문제를 a 기법으로 PEFT
4. Naive LLM + 틀린 문제를 b 기법으로 PEFT ( 예비심사요지 평가 반영 ) , 근데 이건 Rule based라
5. Naive LLM + 틀린 문제를 그냥 LLM에 '이와 유사한 문

b로 SQL2NL 때린 것을 LLM으로 사람의 언어와 비슷하게 NL생성해서 학습시키는 것..을 비교해보는 것도 고려할 것

3. Reference 정리 : GPT를 이용하든 배경지식을 이용하든 중간중간 Reference정리를 잘 할 것

위 2-b에 대한 내용을 정리하면서 겸사겸사 KSC 발표자료를 만드는 것도 포인트다.

시급하게 해야할 것 -> PEFT / 파인튜닝 방법 찾기(이거 Prompt를 써서 학습시키나..? 기본적인 Schema Linking은 제공되는 상태로 튜닝하는지 체크)

GPT로 Finetuning시키면 편하다고 했으니 가격 / 성능 모두를 고려해서 GPT - 5 mini 사용.

와.. 그리고 대대적인 Code작업도 필요할 거 같다.

Dataset 얼른 Json형태로 준비해서 NL2SQL 평가까지 가능하게(KSC에서 EX or EM 평가헀을 때 처럼) 전부 준비

--> Finetuning용 Dataset 다량과, Test용 Dataset 일부 분리해서 준비

a를 다시 깔끔하게 정리해서 보여주고 ---> 이번에야 말로 BERT, BLEU 말고 Human based 평가까지 넣기

b를 다시 깔끔하게 정리해서 보여주고 ---> NL2SQL을 사용한 평가이니까 EX hit ratio( 논문에 설명 必 ) 라는 개념으로 평가

a,b를 통해 SQL2NL Task를 보여주고,

이것을 NL2SQL Task에 적용하는 Fintuning (위 c 항목) 효과를 보여주기. 당연히 3,4가 1,2에 비해 학습을 더 많이 시킨건 맞지만, 1 < 2 << 3 , 4 이렇게 효과가 좀 Dramatic하게 나왔으면 좋겠다.

그냥 1 < 2 < 3, 4 꼴이면 비교군으로 3,4에서 추가 PEFT한 만큼 새로운 Dataset pair를 학습시키는 case를 추가하면 될듯

아니면 5번의 경우를 비교군으로 보여줘서 LLM한테 그냥 시키는 거보다 우리 SQL2NL 모델을 시키는 것이 낫다..는 것을 강조.

아니 근데 애매하다..

b의 경우 input SQL에 대해서 Rule based이기 때문에 NL을 단 하나 만들어 낼 수 있는 것이라 PEFT가 의미가 있나 싶다.

b를 어떻게든 살려야 KSC건 예비심사요지 반박이건 하는건데..

일단 a의 경우 finetuning 중 LLM이 틀린 문제에 대해서 일반 LLM한테 틀린 Gold NL을 넣어서..는 이미 Gold NL을 넣어서 틀린 SQL을 도출했으니까, Gold SQL을 갖고 NL을 3개 정도 만들어보라고 하고 / 우리의 a 모델에 Gold SQL을 갖고 NL을 3개 정도 만들어보라고 한 뒤 각각 PEFT로 학습시켜서 성능비교하는 것은 의미가 있겠다.

문제는 b를 건드는 것..

b로 만든 SQL2NL의 결과는 SQL의 해석이라 일반적인 NL2SQL에 쓰일 수가 없다.

수학성적 칼럼이 있고, 거기에 수학점수가 쫙 있는 DB가 있다고 했을 때 "가장 수학점수가 높은", "수학점수 1등", "수학점수 최상위" 등등의 NL을 SQL2NL b 모델로는 만들어 낼 수 없다. 그저 SQL을 그대로 해석한 것이라 the most, the biggest, No 1, top score 등등의 말을 알지를 못한다.

그럼 이건 PEFT가 아닌 아예 다른 종류의 학습을 Finetuning을 시켜야 할듯

b를 이용하려면, 일단, 우리가 Gold SQL / Gold NL가지고 Nl2SQL모델 Finetuning을 시킨다고 했을 때

Gold NL / Gold SQL / Gold SQL to NL 을 모두 학습시켜보는 건 어떠할까?

아.... 이 부분을 고민해봐야 할듯 b를 NL2SQL모델 강화를 위해 어떻게 써먹냐..................?

적당히 SHOW좀 하다가 쓸 데 없다는 엔딩으로 마무리 지어야 할 수도 있겠다 ㅠㅠ

a는 사용처가 명확한디....

오라클도 b의 case를 안 건드는데는 다 이유가 있지 않을꼬..

b 결과물을 다시 사람의 언어로 LLM을 통해 쓰는 건 의미가 있나 싶다.. LLM call 줄일려고 b를 쓰는건데

에효..

b의 활용처를 좀만 더 고민해보고 얼른 실험data 쌓고 논문 내용 채워나가기로..!!!

[KSC] SQL Parsing Rule base로 SQL2NL 하기

eatplaylove — Sun, 26 Oct 2025 22:40:21 +0900

지금껏 LLM base로 SQL2NL을 진행했다.

그러다보니 사실 NL2SQL과 유사하게 Task를 진행하느라 그닥 Novelty는 없었다.

그러다금껏 LLM base로 SQL2NL을 진행했다.

그러다보니 사실 NL2SQL과 유사하게 Task를 진행하느라 그닥 Novelty는 없었다.

그러다 SQL-to-Vector Embedding이라는 개념을 새로 도입해 Task를 실행했고 결과는 나쁘지 않았다.

https://eglife.tistory.com/370

[KDBC] SQL2NL 모델 발전시키

https://eglife.tistory.com/369 SQL2NL 모델을 NL2SQL에 적용시켜보기[3 - 잠정 stop]https://eglife.tistory.com/368 SQL2NL 모델을 NL2SQL에 적용시켜보기[2]https://eglife.tistory.com/367 SQL2NL 모델을 NL2SQL에 적용시켜보기[1]일

eglife.tistory.com

하지만, 他 교수님들의 Feedback을 분석해보면 일단 LLM 끼지 말고 SQL의 Syntax를 Parse하는 Rule을 기준으로 SQL을 Text로 표현하는 것이 어떻냐는 것이다.

이 고민을 하지 않은 것은 아니다. 다만, 이렇게 진행했을 때 문제점은 반환된 NL의 Semantic 특성은 없고 사람의 구어체와는 다른 형태로 어색한 NL이 나온다.

Select A from emp;

위와 같은 간단한 SQL도, 사실 그 의미는 'Employee A에 대한 정보를 추출하라' 이지만 SQL의 Parsing 기반을 거치면 'EMP table에서 A column을 추출하라' 이렇게 다소 딱딱하게 변한다.

그리고 이렇게 변환된 NL의 경우 그것이 정확하게 SQL을 대변했는지 판단하기가 어렵다.

LLM을 이용해서 SQL2NL을 했을 땐, Fewshot promting / Schema Linking 등을 통해 Gold NL과 유사한 형태로 Output NL을 만들기 때문에 결과물을 BERT, BLEU_4 와 같은 지표로 Evaluate할 수 있었다.

하지만,,, 여전히 SQL2NL에 LLM이 Main인 상황은 LLM call이 늘어나 cost issue가 있을 것이라는 교수님들의 의견을 반영하여.. 최대한 Without LLM으로 SQL2NL을 진행해보려 한다.

골자는 아래와 같다.

1. 이전에 PostgreSQL에서 SQL2NL을 했듯이(https://eglife.tistory.com/262) SQL Parsing Rule을 기준을 쓰던지 아니면 그냥 기존처럼 SQLGlot을 써서 SQL을 NL(다소 어색하지만, SQL 그 자체를 설명하는 듯한 느낌으로)로 표현한다. 이 때, Domain / SQL 난이도 상관 없이 모든 Select SQL문을 커버할 수 있도록 설게한다.

2. 논문을 쓰려면 해당 방법의 효용성을 따져봐야한다. 일단, 해당방법의 정확성을 따져보기 위해 해당기법을 평가(Evaluate)해봐야 한다. 그래야 실험을 하든 뭘 하든 하지.. 근데 앞서 언급했듯이 가장 쉬우면서도 간단한 BERT/BLEU를 이용한 평가는 어렵다. 그래서 이 때 일전에 생각헀던 NL2SQL 모델을 이용해 SQL2NL을 평가하는 방법을 써보려고 한다.

a) Gold SQL <-> Gold NL Pair를 준비
b) Gold SQL을 Rule Based SQL-to-NL Code에 넣는다. ( LLM이 없다!! )
c) 그러면 위 b)의 실행결과로 어떤 Output NL A를 얻고, 이것을 평가해야한다. 단, Output NL A의 경우 Table allign까지 있는 그대로 표현할 것이기에 이것을 평가하기 위해서 Schema Linking은 필수다.

c-1) 시중에 NL2SQL Model을 구해서, Gold NL을 넣었을 때와 Output NL A를 넣었을 때 실행결과가(Ex) 같은 지 확인한다.
위 에서도 언급했듯이, NL2SQL Model Prompt에 Gold SQL/NL과 관련된 Database의 Schema Linking은 필수고, Few-shot까지 적용시킨다. 어차피, 지금은 NL2SQL Model의 정확도를 체크하는 것이 아니라 Return 된 Output NL A의 타당성을 보는 것이기에 다른 요법들을 굳이 쓸 필요는 없을 것 같다.

c-2) 그냥 LLM에 생짜로 Output NL A를 던져서 Gold SQL을 NL로 잘 표현했는지 물어보는 것... 근데 좀 짜친다.
c-3) 이번 Case는 Human based 평가도 좀 짜친다..

d) 위 c-1에서 일치율이 90% 이상 나오면, 내가 만든 SQL2NL 기법도 효과적이라고 판단이 가능하다. 이것을 추후에 어떻게 쓸 것인가? 뭐.. NL2SQL 모델 평가용 or Benchmark로 쓰는 것인데.. 이건 기존 SQL2NL 연구의 목표와도 유사하니 나중에 생각하자

경험상, 실험은 최소 BIRD / SPIDER 이렇게 2개의 Dataset으로 진행하는 것이 맞다.

현재 준비된 것? a) -> 完 , b) -> Code 짜야함 , c) -> Basic NL2SQL Model 完

즉, 얼른 코드부터 짜자..

SQLGlot을 이용해 어떤 SQL문이든 아래 기준으로 Print가 가능하다. 코드도 GPT와 일단 구현 完

위 표에서 NL-ish skim을 사용하면 될 거 같다...

예시를 들어서, 위 표 내용을 다시 한 번 정리하자면

== Input ==
SELECT T1.element FROM atom AS T1 INNER JOIN molecule AS T2 ON T1.molecule_id = T2.molecule_id WHERE T1.atom_id = 
'TR004_7' AND T2.label = '-'
== Pretty SQL ==
SELECT
  T1.element
FROM atom AS T1
INNER JOIN molecule AS T2
  ON T1.molecule_id = T2.molecule_id
WHERE
  T1.atom_id = 'TR004_7' AND T2.label = '-'
== S-Expr ==
Select(
  kind=None,
  hint=None,
  distinct=None,
  expressions=[
    Column(
      this=Identifier(this=element, quoted=False, _type=None, _comments=None, _id=2590306768080),
      table=Identifier(this=T1, quoted=False, _type=None, _comments=None, _id=2590306767856),
      db=None,
      catalog=None,
      _type=None,
      _comments=None,
      _id=2590306768192)],
  limit=None,
  operation_modifiers=None,
  from=From(
    this=Table(
      this=Identifier(this=atom, quoted=False, _type=None, _comments=None, _id=2590306768304),
      db=None,
      catalog=None,
      alias=TableAlias(
        this=Identifier(this=T1, quoted=False, _type=None, _comments=None, _id=2590306768528),
        columns=None,
        _type=None,
        _comments=[],
        _id=2590306768640),
      _type=None,
      _comments=None,
      _id=2590306768416),
    _type=None,
    _comments=None,
    _id=2590306768752),
  joins=[
    Join(
      this=Table(
        this=Identifier(this=molecule, quoted=False, _type=None, _comments=None, _id=2590306768864),
        db=None,
        catalog=None,
        alias=TableAlias(
          this=Identifier(this=T2, quoted=False, _type=None, _comments=None, _id=2590280286016),
          columns=None,
          _type=None,
          _comments=[],
          _id=2590280282432),
        _type=None,
        _comments=None,
        _id=2590280285904),
      kind=INNER,
      on=EQ(
        this=Column(
          this=Identifier(this=molecule_id, quoted=False, _type=None, _comments=None, _id=2590280285568),
          table=Identifier(this=T1, quoted=False, _type=None, _comments=None, _id=2590280285792),
          db=None,
          catalog=None,
          _type=None,
          _comments=None,
          _id=2590280285232),
        expression=Column(
          this=Identifier(this=molecule_id, quoted=False, _type=None, _comments=None, _id=2590280285120),
          table=Identifier(this=T2, quoted=False, _type=None, _comments=None, _id=2590280285680),
          db=None,
          catalog=None,
          _type=None,
          _comments=None,
          _id=2590280282880),
        _type=None,
        _comments=None,
        _id=2590280285456),
      pivots=None,
      _type=None,
      _comments=None,
      _id=2590280282992)],
  where=Where(
    this=And(
      this=EQ(
        this=Column(
          this=Identifier(this=atom_id, quoted=False, _type=None, _comments=None, _id=2590306767296),
          table=Identifier(this=T1, quoted=False, _type=None, _comments=None, _id=2590280282656),
          db=None,
          catalog=None,
          _type=None,
          _comments=None,
          _id=2590306767408),
        expression=Literal(this='TR004_7', is_string=True, _type=None, _comments=None, _id=2590278853216),
        _type=None,
        _comments=None,
        _id=2590306766736),
      expression=EQ(
        this=Column(
          this=Identifier(this=label, quoted=False, _type=None, _comments=None, _id=2590306766848),
          table=Identifier(this=T2, quoted=False, _type=None, _comments=None, _id=2590306766624),
          db=None,
          catalog=None,
          _type=None,
          _comments=None,
          _id=2590306766176),
        expression=Literal(this='-', is_string=True, _type=None, _comments=None, _id=2590306766960),
        _type=None,
        _comments=None,
        _id=2590306766400),
      _type=None,
      _comments=None,
      _id=2590306765392),
    _type=None,
    _comments=None,
    _id=2590306765280),
  _type=None,
  _comments=[],
  _id=2590306767968)
== NL-ish skim (dynamic args-based) ==
- Select
  • expressions: [T1.element]
  • from: FROM atom AS T1
  • joins: [INNER JOIN molecule AS T2 ON T1.molecule_id = T2.molecule_id]
  • where: WHERE T1.atom_id = 'TR004_7' AND T2.label = '-'
  - Column
    • this: element
    • table: T1
    - Identifier
      • this: element
      • quoted: False
    - Identifier
      • this: T1
      • quoted: False
  - From
    • this: atom AS T1
    - Table
      • this: atom
      • alias: T1
      - Identifier
        • this: atom
        • quoted: False
      - TableAlias
        • this: T1
      - Identifier
        • this: T1
        • quoted: False
  - Join
    • this: molecule AS T2
    • kind: INNER
    • on: T1.molecule_id = T2.molecule_id
    - Table
      • this: molecule
      • alias: T2
      - Identifier
        • this: molecule
        • quoted: False
      - TableAlias
        • this: T2
      - Identifier
        • this: T2
        • quoted: False
    - EQ
      • this: T1.molecule_id
      • expression: T2.molecule_id
      - Column
        • this: molecule_id
        • table: T1
      - Identifier
        • this: molecule_id
        • quoted: False
      - Identifier
        • this: T1
        • quoted: False
      - Column
        • this: molecule_id
        • table: T2
      - Identifier
        • this: molecule_id
        • quoted: False
      - Identifier
        • this: T2
        • quoted: False
  - Where
    • this: T1.atom_id = 'TR004_7' AND T2.label = '-'
    - And
      • this: T1.atom_id = 'TR004_7'
      • expression: T2.label = '-'
      - EQ
        • this: T1.atom_id
        • expression: 'TR004_7'
      - Column
        • this: atom_id
        • table: T1
      - Identifier
        • this: atom_id
        • quoted: False
      - Identifier
        • this: T1
        • quoted: False
      - Literal
        • this: TR004_7
        • is_string: True
      - EQ
        • this: T2.label
        • expression: '-'
      - Column
        • this: label
        • table: T2
      - Identifier
        • this: label
        • quoted: False
      - Identifier
        • this: T2
        • quoted: False
      - Literal
        • this: -
        • is_string: True

1. Input의 경우, 말 그대로 Input SQL이다. 별 특이사항 음슴

2. Pretty SQL은, SQLGlot이 Parsing 후 다시 SQL 문자열로 재구성한 결과이다.

즉, 표준 SQL형태의 재구성 결과이며 문법적으로 동일하지만 형식이 다른 SQL도 같은 Pretty SQL을 얻는다.

3. S-Expr (Symbolic Expression Tree) 는 좀 복잡한데, SQLGlot의 내부 트리 구조 (AST)를 S-Expression (Lisp-style) 형태로 표시한 것이다. 즉 Parser가 SQL을 어떤 Tree형태로 이해하고 있는지 직관적으로 보여준다.

-> Why? 각 Clause와 연산자, 피연산자가 어떻게 Tree형태로 저장되어 있는지 시각화가이 위해서이다.

4. NL-ish Skim ( Dynamic Args-based) : 최종적으로 SQL2NL에 이걸 쓰면 될 거 같은데,, SQLGlot의 AST객체를 Dynamic 하게 순회하면서( walk() ) 각 노드의 클래스명( Select, Column, Join ... ) 과 그 노드가 가진 속성(Args)를 전부 풀어서 보여주는 출력이다. 이것으로 Syntax Structure를 직관적으로 파악할 수 있다.

두 쿼리의 AST가 동일하면 Pretty SQL, S-Expr, NL-ish Skim이 모두 동일하다.

그리고, SQL에서 Node type, args는 아래와 같이 구분하면 된다.

추가로, NL-ish 표현에서 quote은 ", ' 처럼 따옴표를 의미하는데, 따옴표를 체크하는 이유는 따옴표 안에 Node가 들어가면 그것은 Syntax가 아니고 args라는 것을 구분하기 위함이다. 또한, SQL은 원래 대소문자 구분이 없는데 quote을 쓰면 구분되니까 체크한다.

추가로 EQ는 말 그대로 '=' 연산자에 대한 설명이다.

지금 NL-ish는 너무 코드가 번잡스럽다. 좀 더럽다는 느낌이 들 정도...

그래서 하드코딩 없는 NL-ish를 보존하되 NL을 좀 사람 or LLM이 보기에 직관적으로 보이도록 다듬어보려고(?) 한다.

SQLGlot이 뿌리는(?) 구조들

대충, 글 줄이는건 이만하면 됐고 NL2SQL 이용해서 Evaluation이나 해보자.

연구실 NL2SQL 코드 이용하는 건 차치하고, BIRD에 있는 코드를 좀 긁어와서 활용할 순 없을 지 체크하자.

또, 드는 생각이 위 Pretty SQL을 쓰면 SQL2NL이 아니고, 그냥 SQL2SQL이다.

즉, NL2SQL을 이용한 평가가 무의미하다는 것..

Framework

위에서 Pred NL이 Gold SQL과 동치(Pretty SQL)면 의미가 없다는 것이다.

아.. 이 기술의 활용처가 계속 애매한데..

1) 고도의 SQL개발자가 자신이 NL2SQL한 결과를 보고 내 의도가 틀렸다는 것을 깨닫는 용도

2) NL2SQL Finetuning시, 오답문제에 대해서 Pred SQL을 Pred NL로 변환시.... 모르겄다.. 아오

일단, 바이브 코딩으로 SPIDER, BIRD에 한해서 어찌어찌 코딩작업을 실행중이긴 하다.

진짜 GPT 미쳤다.. 맨바닥에서 더 이상 코드작업 하는 사람은 필요가 없는 세상이다.. 무섭도다..!!

어찌어찌 결과는 만들어서 분석중....

지금까지의 연구/실험내용을 토대로 간단하게 논문을 적어보자.

근데,, 이 KSC학회에서 논문투고분야가 '인공지능응용'인데 LLM 없이 SQL2NL 하는 것을 어필해도 되는건가..ㅎ 싶긴하다.

늘 그렇듯 논문은 0.초록 / 1.Introduction / 2.연구관련개념설명 / 3.Experiment / 4.Conclusion / Reference 이렇게 구성하고자 한다.

대강의 내용구성은 아래와 같이 해보자.

제목은 : Rule-Based SQL2NL via Parser AST ( SQL 구문분석을 통한 규칙기반 SQL2NL )

0.초록

NL2SQL만큼 SQL2NL에 관한 연구도 중요하다. 그 활용처도 NL2SQL모델 파인튜닝 및 평가용, SQL 개발보조도구용, SQL 학습용 등 다양해지고 있다. NL2SQL과 달리 SQL2NL은 input으로 SQL data를 받고, SQL은 구조화된 언어로 Parsing rule이 엄연히 존재한다. 이 Rule을 기준으로 주어진 SQL을 NL로 표현하고 이것의 정확성을 체크해본다. 이 경우, NL2SQL과 EM matrix를 통해 SQL2NL모델이 SQL을 적절히 NL로 변환시켰는지 체크해볼 것이다. 최종적으로 해당 SQL2NL 모델 활용방안을 본 연구에서 논해보려고 한다.

1. Introduction

위 초록 내용에 이어서...그 동안 NL2SQL 연구에 비해 SQL2NL에 대한 연구는 잘 이루어지지 않았다. 많은 Database 응용분야, AI Agent에선 주로 NL2SQL Model을 다루기 때문이다. 하지만 이미 NL2SQL에 대한 연구는 임계점에 다달은 느낌이다. BIRD, Spider와 같은 저명한 Benchmark에서도 최신등록 Model의 성능이 기존 SOTA에 비해 뛰어나게 월등하지 않다. 그러던 중에 최근에는 그 반대인 SQL2NL 활용에 대한 연구가 이루어지고 있는 추세이다.( Ex) Evaluating NL2SQL via SQL2NL ) 그리고 SQL2NL 모델의 정확도를 향상시키기 위한 연구도 많이 진행되어 왔다. NL2SQL 모델과 다루는 데이터의 종류가 같다 보니 NL2SQL에서 많이 연구되던 Schema linking(Reference), Few-shot prompting(Reference) 기법을 SQL2NL에 적용해 정확도를 올리는 연구도 있었다.(나의 연구) 이 뿐만 아니라 SQL의 구조적 특성을 이용해 SQL embedding 및 RAG기법을 접목한 연구도 있었다.(나의 연구) 하지만, SQL2NL의 연구목표를 NL2SQL 모델발전에 기여한다는 것에 초점을 두자면, SQL2NL 역시 지금까지의 방법론을 봤을 땐 Task 수행을 위한 LLM call을 피할 수 없다. 우리는 SQL이 구조적인 언어이고, 어떤 SQL query든 Syntax Rule에 의해 Parsing될 수 있다는 점에 착안하여 LLM call 없이 SQL의 Parsing, Syntax AST구조를 기반으로 Input SQL을 NL로 설명하는 Cost efficient한 SQL2NL모델을 소개하고자 한다.

기존 SQL2NL Model의 경우 Output NL의 Semantic accuracy를 측정하기 위해 BERTScore나 BLEU_4 Score(Reference)가 많이 쓰였는데 우리 연구 SQL2NL모델의 경우 SQL을 구조적인 형태로 Translate한 것이기 때문에 Output NL이 사람친화적인 대화형 어구가 아니다. 그래서 기존 Matrix 대신 NL2SQL 모델을 빌려와 EM형태로 정확도를 측정하고자 한다.(Figure 1, Experiment flow). 그리고 NL2SQL에서 정확도 향상을 위해 가장 중요했던 Schema linking이 가장 중요한데(Evaluating NL2SQL via SQL2NL에 있는 Schema linking 관련 refer 논문 참고) 우리 연구의 경우 Gold SQL 자체를 그대로 구조적으로 번역한 것이다 보니 Schema error가 낮았다.( Evaluating NL2SQL via SQL2NL ) 그럼에도, 우리의 SQL2NL Model을 평가하는 색션에선 NL2SQL에 SQL2NL의 Output NL과 Database의 Metadata도 함께 주어서 좀 더 면밀하게 모델의 효용성을 평가하고자 하였다.

2. SQL Parser AST

SQL쿼리는 굉장히 정형화된 구조를 갖는다. 특유의 문법에 따라 Clause와 Indentifier, Table name 등이 위치한다. 이렇기 때문에 모든 SQL 쿼리는 그 문법(Rule based) 기준으로 파싱(Parsing)이 가능한데, 우리는 모든 SQL을 Abstract syntax tree(AST)형태로 표현하였다. Figure 2는 SQL을 AST로 표현한 예시이다. 우리는 SQLGlot 오픈소스 라이브러리를 이용해서 SQL2NL을 진행했다. 추가로 SQLGlot을 이용해 두 SQL을 AST로 분리하여 유사도까지 측정할 수도 있다.

3. Rule based SQL2NL

Figure 3(SQL이 SQLGlot+SQL2NL을 통해 변환된 예시_만들어야 함)를 참고하면 된다. 이렇게 되면 SQL이 내포하고 있는 Intention이 모두 Output NL에 반영이 되고, Syntatic / Semantic 사항을 모두 고려하였으며 LLM Cost가 발생하지 않는 SQL2NL모델을 만든 것이다. 초기 Output NL은 SQL Parser code 친화적으로 구성되어 좀 복잡한 형태였기 때문에 사람이 NL만 보고 SQL의 구조를 파악하기 어려웠다. 그러나 우리는 적절한 indexing을 통해 Output NL만 보고도 input SQL의 구성이 무엇이었는지 확인할 수 있게(Like figure 3) 코드 작업을 하였다. SQL개발자가 자신의 SQL code를 우리의 SQL2NL Model에 넣은 뒤 반환되는 NL을 검토하며 Error debugging작업을 진행하는 활용처도 생각해볼 수 있다.

4. Experiment

우리의 SQL2NL Model의 효용성을 측정해보기 위해 Figure1과 같이 실험구성을 하였다. Gold NL과 우리 SQL2NL을 거쳐서 나온 Pred NL을 LLM의 모호성을 방지하고자 한 질의 cycle 당 한 context에 담아서 SQL을 생성해냈고 각각의 SQL을 Gold SQL과 비교하여 EM을 측정했다. Pred NL과 Gold NL의 EX hit 여부가(1 또는 0) 일치하는 case가 많다면 Pred NL은 Gold NL과 구조적, 의미적으로 비슷하다고 판단할 수 있고 SQL2NL이 효과가 있다는 것을 보여준다.

4.1 Experimental Setup

NL2SQL Model로는 SOTA LLM인 gpt-5-mini를 사용했고 Dataset은 BIRD/SPIDER dev set 일부를 Random하게 Sampling하여 사용했다.(Benchmark Reference추가) 총 N회 실험을 내었고, 실험결과란에 Hit 여부 평균값을 적었다.

본래 Database 마다 benchmark score를 참고해 SOTA NL2SQL model을 사용해도 되지만, 본 실험에선 일단 SQL2NL의 성능을 평가하는 것이고, 무조건 EM이 높은 것이 좋은 게 아니고 Gold NL / Pred NL의 hit여부가 같은지 빈도수를 측정하는 것이라 Naive LLM을 NL2SQL모델로 사용했다.

4.2 Result & Analysis - TODO

BIRD/SPIDER N개씩 실험해서 hit 여부 어쩌고~ 근데 predNL은 EX 1인데 GOdl NL은 0인 경우도 있다.

BIRD / SPIDER1.0 dev set으로 각각 1534 / 1000 ea로 test 진행.

- BIRD의 Ex hit 일치는 80~86%, Spider의 Ex hit 일치는 88~92%, 약 5번의 trial을 꺾은선 그래프로 나타내기 각각(Figure 4)

-> Ex hit ratio가 높아야 우리의 Output NL이 GOld NL과 별 차이가 없는건데, LLM NL2SQL 성능때문에 100%까진 안 나오는듯

- EX hit = 0 인 case에선 Spider1.0에선 거의 100%, BIRD에선 98% ex_A만 1인 경우다. 즉 거의 대부분 ex_A = 1 , ex_B = 0 이어서 ex_hit이 0인 것이다.(그냥 글로 설명)

-> LLM이 우리의 구조화된 SQL2NL 결과물은 잘 해석하는데, 일반 Gold NL은 해석이 어렵다는 것.

- SPIDER 1.0에선 pred_sql_A(Ours) 의 ex_A는 100%에 가깝다. pred_sql_B(Original)는 약 88%

- BIRD 에선 pred_sql_A 가 69%, pred_sql_B가 58% (위 내용 전부 in Table1)

Analysis!!

-> Naive LLM model의 NL2SQL task수행능력 한계, Gold NL <-> Gold SQL 간 연결성 부족등의 이유로 오차가 좀 있지만 그래도 EX hit이 거의 90%에 육박하기에 위 SQL2NL task는 NL2SQL 모델평가에 충분히 사용될 수 있다.

-> BIRD의 경우 SPIDER1.0 보다 complex한 query로 구성되었기에 간혹 ex_A가 틀려도 ex_B는 맞는 경우가 생기긴 하지만 이조차 rare한 case다. 그리고 난이도 차이 때문에 ex_A / ex_B 모두 전체적으로 BIRD에서 낮다.

-> SPIDER1.0 과 같이 상대적으로 쉬운 쿼리를 다루는 DB에서 본 SQL2NL 모델은 NL2SQL 모델 평가용 Benchmark로 활용이 가능하다. (Ex_A의 정확도가 거의 100%에 육박하다)

-> BIRD의 경우, challenging 난이도 (Multi join / Sub queries / Group by / Order by) 쿼리의 경우 ex_A를 적용시켰는데도 예측력이 떨어진다. 이는 Parsing tree based NL을 LLM에 주어도 복잡한 구조에 대한 해석능력이 충분히 갖춰져있지 않기 때문으로 보인다. 이는, 복잡한 SQL을 우리의 SQL2NL task로 변환하여 여러 어려운 난이도의 data pair를 만든 뒤 LLM을 finetuning하는 방법으로 극복할 수 있을 것이다.

5. Conclusion

금번 실험은 BIRD/SPIDER 1.0 dataset으로만 실험을 진행해서 일반화에 한계점이 있다. SPIDER 2.0 등 좀 더 어려운 쿼리를 다루는 DB에서도 테스트를 진행해봐야 한다. 그리고 복잡한 SQL 구조는 우리의 연구기법으로 NL로 바꿔봤자 한 눈에 알아보기가 어려울 수 있다. SQL 개발자가 코드 디버깅을 쉽게 하려면 가시성이 중요한데, 이 복잡한 SQL 코드를 어떻게 사람, LLM 모두가 이해하기 쉽게 더 간단히 NL로 표현할 수 있을지도 고민해봐야 한다.

6. Reference

As you wish

각종 Feature / Table만 정리해서 복붙하고, 영어로 논문내용 정리하면 끝!

추가로 어제 집 가면서 생각한 위 SQL2NL Task의 활용처

SQL2NL 내 방법은 그냥
1.개발자들이 simultaneous하게 에라디텍팅
->깔끔한 prompt 보여주는 것에 초첨
2.벤치마크를 벤치마크(평가)하는 것으로 활용
gold NL/SQL 쭉 있을 때 gold SQL을 sql2nl에 넣은 결과와 gold NL결과 비교, 결과 다르면 벤치마크 sql-nl 결속이 없는것으로 간주
3. querySt NL을 사람의 NL로 바꿔주는 NL2NL 모델 파인튜잉. sql입력에 대해 바로 queryST NL로 바꾸고 그걸 사람의 언어로 바꿔서 sql의 의도가 이게 맞니? 라고 역제시 하는 sql copilot

[KDBC] SQL2NL 모델 발전시키

eatplaylove — Wed, 15 Oct 2025 13:27:02 +0900

https://eglife.tistory.com/369

SQL2NL 모델을 NL2SQL에 적용시켜보기[3 - 잠정 stop]

https://eglife.tistory.com/368 SQL2NL 모델을 NL2SQL에 적용시켜보기[2]https://eglife.tistory.com/367 SQL2NL 모델을 NL2SQL에 적용시켜보기[1]일단, 이번 글과 관련된 나의 고뇌는 아래와 같다. https://eglife.tistory.com/366

eglife.tistory.com

위 글.. 지난 시간 내용 요약은 아래박스와 같다.

KDBC용 평가 그래프를 다시 재적립 해보자.

논문에 쓰일 데이터 / 그래프는 최대한 Massage된 것을 쓰자.

지금처럼 가로축은 Case # , 새로축은 Matrix Value 유의미하다 좋다.

다만, Case를 좀 더 늘려야겠다. 이번엔 완벽한 SQL-to-NL Model을 제시하는 것이 목표임으로 Fully SQLGlot diff 가 정확도 측면에선 최고지만 RAG + Hybrid를 하는 것이 Time + 정확도 측면에서 합의점이다 라는 것을 제시하자.

그러기 위해선, 기존 Random / RAG / RAG_Hybrd 에서 Naive하게 Fully diff function을 돌리는 것을 추가하자.
그래서 4가지 case에 대해 정확도는 BERTRecall / BLEU-4를 비교하되 각 case의 Runtime 소요시간 측정도 하면 좋겠다.
Accuracy 평가는 BERT/BLEU 외에 일부 Human based 평가를 막대그래프 형태로 추가해서 신빙성을 좀 더 더한다.
-> Human based 평가의 경우 Datascience + DB분야 연구중인 대학원생(SQL 준전문가 이상급)을 대상으로 진행했다고 명시
( ★ 이와 관련된 논문 문구는 GPT에 쳐보장★ , LKS 대장님 Seminar 논문참고도 가능 )

원하는 결과는, 정확도가 Random < RAG < RAG_Hybrid ≈ Fully diff function이고
시간소요는 Random ≈ RAG ≈ RAG_Hybrid <<< Fully diff function 이다.

실험 Result는 총 4줄로 제시된다.

LLM은 GPT 5 - mini로 통일

First : BIRD - Accuracy ( BERT - 꺾은 선 , BLEU - 꺾은 선, Human Based - 막대그래프 )
Second: BIRD - Run Time
Third : SPIDER - Accuracy
Fourth : SPIDER - Run Time

K-DS에서 썼던 것에 어떤 점을 Develop 할 수 있을까..?
사실, 저건 그냥 연구발표회일뿐 학회가 아니라 그대로 써도 되긴 하는데,, 어딘가 짜쳐서 Develop좀 시키려고 한다.

-> Embedding 좀 더 추가하기, 현행 58 -> 58 + N ( 위 Evaluating NL2SQL via SQL2NL 읽고, 추가할 Sector를 더해본다.)
Evaluating NL2SQL via SQL2NL 추가로 얘는, Introduction에도 넣어야 겠다. SQL2NL을 활용한 사례가 많아지고 있다는 것 언급!

-> Prompt를 더 다듬기. SQL 쿼리와 스키마 정보를 기반으로 NL 생성 -> 스키마 링킹오류 방지 (위 E N v S 논문내용 참고)
지금은 Full Schema를 그냥 일괄적으로 LLM에 던졌는데,(build_schema_index 함수 분석해보자)

-> 그리고 뭐.. 실험 case 추가 및 Data-set(BIRD + SPIDER) 추가된 것이지.

이렇게 까지 하고 뭔가 RAG, Hybrid 어쩌고 SQL2NL model 제시..! 로 주제 잡고 던지면 될듯

1. Embedding function 손보기

현행 74개에서, Join복잡도(Join 개수) 및 중첩 쿼리(Sub query) 유무 내용을 포함해서 Embedding feature를 좀 늘려야겠다.

기존 Feature 74개에 대한 설명

보아하니, 이미 n_join_tables 로 join 개수는 tracking 하고 있으니 n_sub_table을 추가했다. SQL의 Syntax관련해서 더 추가할 수 있는 Feature 없는지 GPT한테 직접 물었다.

NOT, NOT IN, NOT Exist와 같은 패턴함수 유무와, ordery/group by 개수를 체크하는 Feature를 추가시켰다. 그리하야.. 아래와 같이 총 83차원의 Vector로 Embedding 하는 Feature Embedding Function 완성

꽤나 복잡하다

흠.. has_star_replace/exist는 좀 짜쳐서 내가 알아서 뺐다. 그리고 또 이것저것 수정해서 최종적으로 81차원 완성

이제 공포의 실험코드 작업할 차례..

GPT 5야 힘을 내줭!

내가 요구한 것은 아래 4가지다.

1. 결과 Evaluation matrix에 BART를 빼고, BLUE/BERTRecall 점수만 나왔으면 좋겠고
2. 기존엔 pick_random_5,pick_rag_top5,pick_rag100_diff5 이렇게 3개로만 카테고리를 나눴었는데 추가로 diff_similarity only로 fewshot을 5개 골라서 제시하는 카테고리도 하나 추가했으면 해.
3. 그리고 이번엔 test(100개 sample)를 돌릴 때 각 case별로 100개 sample fewshot 추출하는 시간을 체크하고 싶어. LLM에 input/output 넣고 응답 대기하는 시간 말고 순수하게 각 case별로 "fewshot 추출시간 총합"을 체크할 수 있게 코드를 바꿨으면 해
4. 마지막으로, 실험을 최초 한 번만 하는게 아니라, N개의 data를 갖고 있는 train json set을 random seed를 변경해가며 N-100개의 embedding용 set, 100개의 test set으로 설정해서 임베딩후 동일 실험 루프를 10번 정도 돌리고 싶어 -> 최종 결과 xlsx파일은 각 case별로 실험완료시 각각 나와야해서 최종적으로 10개의 실험case가 나와야 한다. data dir은 내가 입력할테니, 맨 아래 embedding 함수와 json파일 split하는 함수를 고려해서 코드를 제시해줘.

세세한 수정은 차라리 내가 하는 것이 빠르나,

뼈대 만드는 건 솔직히 전세계에서 아무리 뛰어난 엔지니어여도 GPT를 이길 수 없는 경지에 이르렀다.

진짜 바이브코딩이 너무 잘 된다. 약 7개의 Step으로 내 무지막지한 요청을 바로 알아먹어버렸다..;

어찌어찌 연구를 잘 매듭지어서 LLM을 활용한 복합적인 SQL2NL Task로 KDBC 논문제출 完!!

SQL2NL 모델을 NL2SQL에 적용시켜보기[3 - 잠정 stop]

eatplaylove — Thu, 25 Sep 2025 11:30:25 +0900

https://eglife.tistory.com/368

SQL2NL 모델을 NL2SQL에 적용시켜보기[2]

https://eglife.tistory.com/367 SQL2NL 모델을 NL2SQL에 적용시켜보기[1]일단, 이번 글과 관련된 나의 고뇌는 아래와 같다. https://eglife.tistory.com/366 SQL2NL 모델 추가 실험(VectorDB, Embedding)[4]https://eglife.tistory.com/3

eglife.tistory.com

얼른 접합시켜보자 이것들!!!!!!!!!!

그리고 평가 Data 걍 만들기. Human Based Survey 그냥 만들어서 랩실사람들한테 얼렁 평가받자!!

[ROW] case=0, strat=Random -> {'id': '0', 'db_id': 'student_club', 'Strategy': 'Random', 'GoldNL': 'Mention the total expense used on 8/20/2019.', 'GoldSQL': "SELECT SUM(cost) FROM expense WHERE expense_date = '2019-08-20'", 'Pred_SQL_A': "SELECT SUM(cost) AS total_expense FROM Expense WHERE expense_date = '2019-08-20'", 'Pred_NL_A': 'What was the total cost of all expenses on 2019-08-20?', 'Pred_SQL_B': "SELECT COALESCE(SUM(cost), 0) AS total_cost FROM Expense WHERE expense_date = '2019-08-20'", 'Ex_A_equal': 'False', 'Ex_A_reason': 'Different results', 'Ex_B_equal': 'False', 'Ex_B_reason': 'Different results', 'SQL2NL_Acc_Hit': 'True', 'BLEU_4': '0.04939382737115371', 'BERT_Recall': '0.888798713684082', 'err_nl2sql_a': None, 'err_sql2nl': None, 'err_nl2sql_b': None}
[ROW] case=0, strat=RAG -> {'id': '0', 'db_id': 'student_club', 'Strategy': 'RAG', 'GoldNL': 'Mention the total expense used on 8/20/2019.', 'GoldSQL': "SELECT SUM(cost) FROM expense WHERE expense_date = '2019-08-20'", 'Pred_SQL_A': "SELECT COALESCE(SUM(cost), 0) AS total_expense FROM Expense WHERE expense_date = '2019-08-20'", 'Pred_NL_A': 'What is the total cost of expenses on 2019-08-20, returning 0 if there are no expenses that day?', 'Pred_SQL_B': "SELECT COALESCE(SUM(cost), 0) AS total_cost FROM Expense WHERE expense_date = '2019-08-20'", 'Ex_A_equal': 'False', 'Ex_A_reason': 'Different results', 'Ex_B_equal': 'False', 'Ex_B_reason': 'Different results', 'SQL2NL_Acc_Hit': 'True', 'BLEU_4': '0.025281168697394947', 'BERT_Recall': '0.8880898952484131', 'err_nl2sql_a': None, 'err_sql2nl': None, 'err_nl2sql_b': None}
[ROW] case=0, strat=RAG_Hybrid -> {'id': '0', 'db_id': 'student_club', 'Strategy': 'RAG_Hybrid', 'GoldNL': 'Mention the total expense used on 8/20/2019.', 'GoldSQL': "SELECT SUM(cost) FROM expense WHERE expense_date = '2019-08-20'", 'Pred_SQL_A': "SELECT COALESCE(SUM(cost), 0) AS total_expense FROM Expense WHERE expense_date = '2019-08-20'", 'Pred_NL_A': 'What is the total cost of expenses on 2019-08-20, returning 0 if no expenses were recorded that day?', 'Pred_SQL_B': "SELECT COALESCE(SUM(cost), 0) AS total_cost FROM Expense WHERE expense_date = '2019-08-20'", 'Ex_A_equal': 'False', 'Ex_A_reason': 'Different results', 'Ex_B_equal': 'False', 'Ex_B_reason': 'Different results', 'SQL2NL_Acc_Hit': 'True', 'BLEU_4': '0.025281168697394947', 'BERT_Recall': '0.8848373293876648', 'err_nl2sql_a': None, 'err_sql2nl': None, 'err_nl2sql_b': None}

흠... Case 하나 돌려봤는데 이런식으로 나온다.. 디버깅은 내일 이어서...

일단 Proposal은 냈는데.. 충격적인게 SQL2NL을 이용해 NL2SQL을 평가하는 Benchmark 방법이 벌써 논문으로 나왔다.

분명 이 블로그만 보더라도 아이디어는 내가 더 먼저 냈을 터인데.. 밍기적 거리는틈에 누군가가 해치웠다.

심지어 Output NL에 대한 Evaluation도 BERT로 했더만;;;; 아오(https://www.arxiv.org/abs/2509.04657)

나는 Top-tier 논문에 관심이 없는 상태니까 얼른 내 논문작업이나 마무리혀야겄다.

(아깝긴 하다 아오 ㅠㅠ)

다시 정리해보면,

1. 일단 예비 Proposal -> "SQL - to - NL for NL - to - SQL" 完

2. Proposal 발표자료 - 10분 분량 - 중요도는 下 하지만 시급! 急!

3. 2025 KDBC 논문작성 必 : 완성도 있는 SQL-to-NL을 만들자가 목표

2,3번을 연계시켜서 얼른 Develop 하는 것이 급선무.

지금 위에서와 같이, NL2SQL Model (그냥 기본적인 Base Model) 을 이용해서 나의 SQL2NL Model 정확도를 측정하려고 한다.

Test data 1 건당 3가지 case(Random, RAG, RAG Hybrid)를 돌리다보니 시간이 꽤나 걸린다.

흠.. 일단 이거는 Ex_A(처음 NL2SQL), Ex_B(재생성된 NL2SQL) 값이 아래와 같이 True True / False False로 다른 Case가 있으니 일차적으로 동작은 잘 하는 거 같소만.. 뭔가 Error가 뜨는 걸로 봐서 문제가 좀 있는 거 같다.

그래도 Case 2부터 갑자기 RAG / RAG_Hybrid를 탐지하지 않는 Error만 잡으면 어느정도 써먹을 순 있을 코드 같다.

즉, 위 사항만 잘 Debugging하고 SQL2NL Model만 잘 만들어 놓으면 일단 SQL2NL for NL2SQL에서 Half는 완성한 것.

이제 해야할 것,

KDBC용 평가 그래프를 다시 재적립 해보자.

그리하여, 일단 NL2SQL 모델을 사용한 SQL2NL 모델 평가 Framework는 잠시 제껴두자.

저 위 matrix + 사람평가로 일단 내용은 충분하다.

NL2SQL 모델을 사용한 SQL2NL 모델 평가 Framework는 시간이 된다면 추석 전후로 KSC에 투고해보는 것으로 합시다.

(교수님과 상의 후에)

이건 이렇게 마무리하면 되고,

Proposal 발표자료는 제출한 Overleaf를 필두로 10분짜리 발표 PPT 후딱 만들자.

KDBC + KSC 논문이 졸업논문 실험 2가지 중 첫 번째 STEP이고,

두 번째 STEP이 바로 Finetuning인데, 이거 유의미하면 솔직히 Top-tier급이 아닌가 싶긴 하다 ㅋ;;

PEFT에 대해서 어느 정도 공부를 하고 Finetuning 들어가는 것으로 합시다. 이건 10월말~11월에 거쳐서 마무리 짓기!

Dataset 평가도 BIRD / SPIDER / BEAVER 전부 때려보자.

SQL2NL 모델을 NL2SQL에 적용시켜보기[2]

eatplaylove — Thu, 18 Sep 2025 17:30:04 +0900

https://eglife.tistory.com/367

SQL2NL 모델을 NL2SQL에 적용시켜보기[1]

일단, 이번 글과 관련된 나의 고뇌는 아래와 같다. https://eglife.tistory.com/366 SQL2NL 모델 추가 실험(VectorDB, Embedding)[4]https://eglife.tistory.com/364 SQL2NL 모델 추가 실험(VectorDB, Embedding)[3]https://eglife.tistory.co

eglife.tistory.com

위 글에서 Continue...

일단, Data Seed를 다르게 해서 좀 더 돌려봤다.

실험 한 번만 하고 데이터 비교하는 것은 좀 무리가 있으니..(그래봤자 2번 더 했다 ㅋ)

GPU 대여 서비스를 이용했더니 한 1시간? 정도에 2회 돌렸다. 즉 30분에 1회 돌릴 수 있고 회당 500~600원 정도로 보면 되겠다.

한 4회 하니까 요렇게 결과가 나온다.

BLEU는 진짜 틀린그림 찾기니까, 배제.. 해도 될 거 같고, 아니면 참고용으로만 쓰고!

BERTRecall기준으로, 역시나 RAG_Hybrid가 가장 Score가 높다. 신기하긴하다 ㅋㅋ 예상대로 되니까

이번엔 좀 HARD 난이도 도전,

NL2SQL Model을 이용해서!!

근데 환경변수?설정이 좀 빡세다...

일단 하고 있긴 한데..

1. OPEN API KEY를 다음과 같이 관리해야함..

2. main.py 파일 실행시 config를 더해줘야함..

물론 다 그런건 아닌데, 내가 공유받은 NL2SQL모델은 이런 환경에서 코드를 돌릴 수 있다.

역시,, SW 개발을 하면서 코드 공유할때 다른 사람의 환경까지 잘 COPY하는 게 중요하구만..

일단 NL2SQL 돌려보는 것 Step in Windows 환경!!!

1. 가상환경 Activate

nl2sql\Scripts\Activate.ps1

2. main.py 파일 실행하기 -> Output이 생성됨

python main.py --config "configs/bird_dev_config.yaml"

※ 여기서 주의할 건, data/bird에 있는 dev.json , dev_gold.sql 파일의 구성의 싱크만 맞춰준다면 내가 측정하고자 하는 SQL/NL Pair를 측정할 수 있다.

3. 위 2번의 결과로 아래와 같이 Ouput이 생성된다.

이제, 이 Output과 Gold SQL을 비교하며 Exact 한지 Evaluation을 진행한다.

그냥, 원작자가 Mac으로 이 프로그램과 Script를 짜서, windows + WSL에서 실험을 진행했다.

대충 Script 다 돌리면 실험결과는 아래와 같이 나온다.

{
  "accuracy": {
    "simple": 100.0,
    "moderate": 50.0,
    "challenging": 0.0,
    "total": 80.0
  },
  "counts": {
    "simple": 3,
    "moderate": 2,
    "challenging": 0,
    "total": 5
  }
}

그냥, 아래 README Linux환경을 따라가면 코드실행 + 평가까지 다 되긴 한다.

README.md

0.00MB

근데 문제는 그게 아니라, 이걸 이용해서 얼렁 나의 SQL2NL Task를 평가하는 것!!!

쩝, 얼른 실험 몇 개 설계하고 테스트 돌리고 결과 정리좀 해보자...!

실험 Dataset은 BIRD / SPIDER / BEAVER 면 되는 거 같고, BIRD로 먼저 해보자.

위 메커니즘을 다시 Following 하는 것이다..!

지금은 그나마 정상인 BIRD Dev set 약 1500개에서 100개씩 test data set으로 만들고 1400개를 pool로 보고있다.(Embedding 해서 SQL2NL Task의 Fewshot으로 사용)

그렇다면..

1. SQL-NL Data를 1400개 for Embedding , 100개 for Test로 나눈다.

2. Test 100개 Pair로만 가지고 NL2SQL - SQL2NL - NL2SQL 작업을 시작한다.

( 1 건당 총 3번의 LLM Call이 필요한 상황... )

3. 실험을 몇 번 반복해본다.

사실 코드만 잘 완성시켜놓으면 할만한 거 같기도 한데.. 이거 뭐 완전 Vibe Coding Only로 하고 있어서 GPT와 쳐절한 전투를 진행해야한다 ㅠㅠ

지금 ALl in one frame work 만드는 중... calculating......

GPT MS Thesis 최신글을 참고하라..

Pipeline은 확고한데,, 서로 다른 두 코드를 접합시키는 게 너무 빡세다.

SQL2NL / NL2SQL 코드를 만든 주체가 달라서 그런듯 -_-

어찌어찌 코드작업은 계속 하고 있는데, (With GPT) 해야 할 것을 정리해보자.

1. SQL2NL 평가를 위한 NL2SQL 파이프라인이 완성되면 얼른 BIRD / SPIDER / BEAVER dataset을 가지고 GPT 5 / mini / nano 이렇게 실험을 돌려서 SQL2NL의 Random fewshot / RAG fewshot / RAG + Hybrid fewshot에 대한 Accuracy를 측정한다.

2. 각 모델의 LLM 3종 , Dataset 3종, BERTRecall / BLEU_4 / NL2SQL평가 / Humanbased 평가 이렇게 데이터를 나눠서 정리한다. 얼른 뽑는 편이 낫다.

2.1 BERT/BLEU -> 아래와 같은 꺾은선 그래프(실험 횟수를 한 10번 정도 돌려보자)

2.2 NL2SQL 평가 -> n번 정도 돌리고 그냥 막대그래프

2.3 Humanbased 평가 -> 4분위 지점 찍히는 plot 그래프

이렇게 해서 SQL2NL 을 RAG + Hybrid 기법으로 정확도를 올릴 수 있다는 것을 보여주며 KDBC에 출간

(Future work에 SQL2NL Finetuning을 진행하면 정확도 더 올라갈 것이라고 기술, K-DS는 논문을 출간하진 않아서 ㄱㅊ을듯)

3. KDBC Paper를 얼른 쓰고, 이걸 필두로 졸논 Proposal을 쓴다.

   논문요지(Proposal) 발표
- 논문요지 제출:
  * 제출 시 표지와 본문을 하나의 PDF로 변환하여 담당자 이메일로 제출
  * 발표자는 심사용 논문요지(연구주제, 연구의 목적, 연구의 필요성, 관련 문헌 고찰, 연구방법, 기대효과, 참고문헌) 등을 A4용지, 표지를 포함하여 자유양식으로 10매 작성)
* 메일 제목: 석사학위 프로포절 자료 제출, 학번, 성명 / 파일명: 성명_학번_석사 프로포절
- 논문요지 발표 및 심사: 10~15분

연구주제/목적/필요성/관련문헌고찰/연구방법/기대효과/참고문헌 등이라... 전형적인 Structure긴 하다.

주제 : 위와 같다.
목적 : NL2SQL 모델개발, 기술발전
필요성 : NL2SQL 모델 연구기법의 획일화, 창의적인 시도 필요. NL2SQL의 중요성은 말해뭐해.
관련문헌 : 각종 NL2SQL 논문들
연구방법 : 지금껏 내가 만지작거린 SQL2NL 모델을 활용해 NL2SQL 파인튜닝 방법
기대효과 : Domain specific하면서 완성도 있는 NL2SQL 모델 개발 가능 per Company.
참고문헌 : 각종 NL2SQL 논문들

이런식으로 진행하고자 한다..

일단 얼른 NL2SQL , SQL2NL접합시키는 걸로 넘어가자.

글이 넘 길어져서 이만 줄이기

SQL2NL 모델을 NL2SQL에 적용시켜보기[1]

eatplaylove — Thu, 11 Sep 2025 19:37:03 +0900

일단, 이번 글과 관련된 나의 고뇌는 아래와 같다.

https://eglife.tistory.com/366

SQL2NL 모델 추가 실험(VectorDB, Embedding)[4]

https://eglife.tistory.com/364 SQL2NL 모델 추가 실험(VectorDB, Embedding)[3]https://eglife.tistory.com/363 SQL2NL 모델 추가 실험(VectorDB, Embedding)[2]https://eglife.tistory.com/362 SQL2NL 모델 추가 실험(VectorDB, Embedding)[1]https://eg

eglife.tistory.com

https://eglife.tistory.com/365

[Review]Is Long Context All You Need? Leveraging LLM's Extended Context for NL2SQL

https://arxiv.org/abs/2501.12372 Is Long Context All You Need? Leveraging LLM's Extended Context for NL2SQLLarge Language Models (LLMs) have demonstrated impressive capabilities across a range of natural language processing tasks. In particular, improvemen

eglife.tistory.com

항상 지속적으로 문제가 되고 있는 NL에 대한 정확도 평가 방법..

결론은, SQL2NL의 결과물인 NL에 대해선 평가수치를 내리는 것이 무의미하니,

해당 Model에 대해선 모델 이용 전에, NL을 1차적으로 BERT/BLEU Score로 검증해보고 그리고 Human based evaluation으로 추가 검증한다.

그 후, NL2SQL에 이용하는 Logic flow를 가져보기.

전체적인 골자는 아래와 같다.

-> 적어도 BIRD BenchMark에선 잘 동작하는(특정 Domain Specific한) SQL2NL 모델을 STEP 1에서 만든다.

-> STEP 1에서 해당 모델에 대해서 검증할땐 BERT,BLEU도 좋은데 걍 Human 평가까지 포함시켜서 BIRD 에서 위 기법이 잘 동작하는 것을 보여준다. => 이게 잘 되면, 어떤 Domain이든 이 기법을 이용해서 SQL2NL 모델을 만들 수 있다는 일반화로 넘어갈 수 있다.

-> 이제 STEP2로 넘어 간다.

-> 전반적인 NL2SQL 모델이 아닌, 특정 Domain Specific(Like BIRD)한 NL2SQL 모델이 Target이다.

ㄱ. BenchMark로서 SQL2NL 이용
NL2SQL ->SQL ouput 결과 A 저장 -> SQL2NL(여기서 나온 점수로 평가? 의미 없음 나올 수 있는 점수가 BLEU/BERT 이런 참고용일 뿐. 그냥 SQL2NL이 절대적인 BenchMark라고 가정을 찍어버려야 한다.) -> NL2SQL -> Output 결과 B를 결과 A와 비교해서
같으면 OK 다르면 NO

ㄴ. NL2SQL 모델 Finetuning / 강화학습 등등에 사용.. 이건 내가 논문으로 쓸 수 있을지 모르겠다. 강화학습개념도 잘 없고(물론 LLM과 함께하면 비벼지겠지만..) 무엇보다 실익이 있을지 의문이다..ㅎ 그래도 Logic을 생각해보자면,
NL A -> NL2SQL -> SQL2NL -> NL B -> NL A와 NL B가 맥락적으로 같아질 수 있도록 Finetuning or 강화학습 시작!(LLM한테 시켜야 겠지ㅎㅎ?) 이렇게 해서 만들어진 NL2SQL모델이 Naive Model보다 성능이 좋다고 여기면 된다..

위 ㄱ에 대해서 유효성을 보여주려면 어떤 실험을 진행해야 할까? 기존 코드를 잘 만지면 ㄱ을 이용하는 실험은 간단히 진행해볼 수 있을 거 같은데,, 그 효과를 어떻게 보여줄까?

(특정 Model이 맞췄던 문제 / 못 맞췄던 문제를 나누어서 나의 SQL2NL Model을 Benchmark로 활용했을때도 결과가 맞춤 or 못 맞춤으로 나오는지를 보면 되지 않을까?? 근데 아무래도 다른 NL을 input으로 넣는거라 결과가 같을 것이라고 예상하진 않는다..ㅠ)

ㄴ의 경우, 급하게 강화학습/파인튜닝 내용을 대충 찾아보고 NL2SQL Model을 하나 만들 수 있지 않을까 하는 생각이 든다.

일단 ㄴ은 차치하고, ㄱ부터 Develop 해보자.

내 SQL2NL Model의 Novelty는 SQL의 구조적 특성을 Parsing을 통해 이용한다는 것이다. 이 점이 기존 NL2SQL Task에 내 연구를 바로 넣을 수 없는 까닭이다.

Input이 NL이면 그와 유사한 Examplar는 그냥 Text embedding을 통해서만 불러올 수 있기 때문이다.

하지만, Input이 SQL인 SQL2NL Task에선 SQL의 구조적 특성을 통해 유사도가 높은 Examplar를 최대한 가깝게 가져올 수 있다.

즉, Input이 NL일때보다 SQL일때 Similarity가 더 높은 Examplar 추출이 가능하다고 가정!

그래서 위 내용을 바탕으로 NL2SQL Model 적절한 거 아무거나 가져와서 얘에 대한 Evaluation을 진행할 수 있다.

※ 갑자기 생각난 문제는, NL2SQL Model이 SQL을 Infer할 때 매번 같은 결과를 낼까?

뭔가 아닐거 같다..
a 라는 NL을 b라는 SQL로 잘 변환했다가도, 이게 LLM을 이용하는 Task이다보니 어떨 땐 같은 a라는 값에 대해서 b' 라는 다른 SQL을 변환할 수도 있다고 생각한다.
-> 써치해보니 그것은 보장되지 않는다고 한다.
LLM GPU의 Sampling기반 Decoding 과정에서 Sampling 경로가 달라질 수 있어서 같은 조건 + 같은 Input이어도 다른 Ouput이 나올 수 있다고 한다. 억지로 Deterministic mode를 쓰면 된다고 하지만, 일반적인 LLM사용 환경에선 그렇게 Setting하긴 어렵다.

즉, 다시 말해 NL2SQL의 정확도를 측정할 때 한 Flow에서 측정해야 한다.

여기서 한 Flow란 무엇일고..

일단 내가 NL2SQL Model A와(시중에 떠도는거 적당한 거 암거나) SQL2NL Model B를(Ours!!) 보유하고 있다고 가정하자.

이 때, BIRD Dataset을 쓰는데 최대한 정제된(Refined) Dataset을 쓰자. BIRD 자체에도 Error가 약 25% 있다는 것은 학계의 정설이다.

이게 반대로, Result 1 / Result 2 비교 정확도가 95%정도만 나와도 Error 5%에 대해선, 위 박스에서 언급했던

LLM의 비일관성(?)을 Error원인으로 적을 수도 있다.. 부디!! 내일 실험 한 번 돌려보고 정확도를 측정해보기.

슬 실험을 돌려야 한다 예엠병!

시간을 좀 보내고.. 조깅을 뛰면서 생각한건데, 위 Logic대로 잘 동작했다고 치자. 그럼 이 Framework의 효용성이 뭐냐? 무조건 각광받는 산업인 NL2SQL이 틀렸는지 맞았는지는 모범답안만 있다면 Result1만 봐도 알 수 있는거고 저렇게 Result1, Result2를 비교해서.. So.. What? 이라는 거다. BIRD / SPIDER 같은 Benchmark를 대체할 수 있는 근거가 없다..(어차피 Test data는 공개되지 않으니까)

되려, 저 그림은 SQL2NL Model의 정확도를 판단하는 지표로 쓰일 수는 있겠다라고 생각이 든다.

Result1 과 Result2가 일치하는 Case가 많을수록 Model B가 SQL을 NL로 적절히 바꿨다고 판단해볼 수 있다.

물론, LLM을 거치는만큼 일종의 Uncertainty가 올라가긴하지만, 이 정도는 어쩔 수 없다고 본다.

이제 SQL2NL Model은 BERTRecall , BLEU, (BART 제외), Human Based, NL2SQL Model을 이용한 평가로 그 정확도를 나타내볼 수가 있다.

근데 문제는,, 이건 Whole Framework에서 내가 그동안 ' SQL2NL Model은 무조건 정확하다고 가정하자! ' 의 영역이다. 주요 Point는 어떻게든 SQL2NL Model을 NL2SQL과 엮어야 Merit가 있는데...

나는 아무리 봐도 ' 모델학습 ' 에서 이것을 활용하는 것만이 떠오른다.

ㄴ. NL2SQL 모델 Finetuning / 강화학습 등등에 사용.. 이건 내가 논문으로 쓸 수 있을지 모르겠다. 강화학습개념도 잘 없고(물론 LLM과 함께하면 비벼지겠지만..) 무엇보다 실익이 있을지 의문이다..ㅎ 그래도 Logic을 생각해보자면,
NL A -> NL2SQL -> SQL2NL -> NL B -> NL A와 NL B가 맥락적으로 같아질 수 있도록 Finetuning or 강화학습 시작!(LLM한테 시켜야 겠지ㅎㅎ?) 이렇게 해서 만들어진 NL2SQL모델이 Naive Model보다 성능이 좋다고 여기면 된다..

위 강화학습은 너무 Rough하고, 조깅을 뛰면서 생각해본건

우리가 공부하듯이 모델도 학습시키는 것이다. 시험공부를 할 때, 맞은 문제는 넘어가고 틀린 문제에 대해선 해당 유형과 비슷한 문제를 많이 풀어본다. 이래야 틀린 유형에 대한 학습이 올라가는 것이 당연하다고 생각하기 때문이다.

그래서 생각한 것이, NL2SQL 모델을 Finetuning할 때 틀린 Data pair에 대해서 Gold SQL + SQL2NL 모델을 가지고 Gold SQL과 유사한 뜻을 가진 NL을 N개 만들어 이 Pair를 추가로 학습시키는 것이다.

근데,, 이 때 문제는

1. Train Data를 추가하면 일반적으로 전체 재훈련이 필요하다. -> Model이 데이터 분포 등도 반영시켜서 Train하기 때문
Solution? -> Incremental learning : 새로운 데이터만 추가로 학습하는 기법(Catastrophic forgetting 문제 해결 必)
LoRA/PEFT 방식(KTS 교수님 전문분야), Continual Learning, Data Mixing 등의 기법을 사용할 수 있다.

2. Model 틀린 문제에 대해서 유사한 데이터 Sampling / Augmentation을 이용해 학습강화하는 연구는 이미 되고 있다.
-> 찾아보면 됨

내 평소 연구랑 결이 확 달라진다. LLM Training / Deep Learning의 영역으로 넘어가는 느낌..

그래도 졸업하기 전에 LLM Finetuning과 Hugging Face이용을 한 번은 해보고 싶었는데 오히려 잘 됐나? 싶기도 하고..ㅎ

이건 KDBC처럼 모 학회가 있을 때 따로 체크해봐야 겠다.

다시 본론으로,

그러면 지금 SQL2NL Model을 다시 검증하는 것을 필두로 함 해보자.

BIRD Data를 좀 더 가공 및 Embedding 최적화하며 코딩을 좀 더 진행해보자.

현재 기준, 아래와 같다.

일차 목표는,

BIRD_Train, BIRD_Dev, 그리고 내가 Refine한 Dataset에서 모두 RAG_Hybrid가 가장 높고, 그다음 RAG 그 다음 Random 순인 Graph를 얻는 것.

이차 목표는,

Human Based Evaluation 과 NL2SQL Model을 이용한 Evaluation도 진행하는 것.

최종 목표는,

위에서 개발한 SQL2NL Model을 NL2SQL Model Finetuning에 활용해서 이득을 보는 것이다.

SQL2NL 모델 추가 실험(VectorDB, Embedding)[4]

eatplaylove — Thu, 4 Sep 2025 19:39:34 +0900

https://eglife.tistory.com/364

SQL2NL 모델 추가 실험(VectorDB, Embedding)[3]

https://eglife.tistory.com/363 SQL2NL 모델 추가 실험(VectorDB, Embedding)[2]https://eglife.tistory.com/362 SQL2NL 모델 추가 실험(VectorDB, Embedding)[1]https://eglife.tistory.com/361 SQL2NL 모델 실험진행(2)https://eglife.tistory.com/360 S

eglife.tistory.com

Data는 웬만큼 뽑았다.

이제 실험한 Data에서 유의미한 내용을 뽑고 잘 시각화하는 것이 중요할듯.

BAR / Line Graph로 각 Prompt Case (Random, RAG, RAG + SQLglot) 별로 Evaluation 결과 차이가 잘 보이게 세팅해야한다.

그렇게 세팅하고 나서,

Human based 평가 + NL2SQL Model을 써서 평가 하는 항목을 넣으면 되겠다.

Evaluation Matrix만 추가하는 것이라서 Graph/Chart 분석 Code만 제대로 닦아 놓으면 이것들 추가해서 분석하는 것은 일도 아니다.

근데 이 평가방식들을 왜 추가할까?

일단 지금까지는 SQL-to-NL(Natural Language) 의 Output Semantic 정확도를 측정하기 위해서 BLEU-4 / BERT Recall / BART Score을 사용했다. 이것들의 특징을 다시 한 번 Review하자면 다음과 같다.

1) BLEU‑4 (n‑gram 정밀도 + 길이 패널티)

무엇을 보나: 1~4‑gram **정밀도(precision)**의 기하평균에 brevity penalty(후보가 너무 짧으면 감점)를 곱한 값.
강점
- 참조 문장과의 표면적 유사도(어휘/구)를 잘 포착.
- 계산이 가볍고 재현성이 높음.
약점
- 동의어/패러프레이즈에 취약 → 같은 의미라도 표현이 다르면 낮게 나옴.
- 순서 민감(n‑gram 기반), 의미 보존 여부를 직접 보장하지 않음.
- SQL→NL처럼 문장이 짧은 과제에서는 4‑gram이 0이 되기 쉬워 스무딩 필요(예: Chen–Cherry method).
스케일/실무 팁
- 보통 0~~1(혹은 0~~100)로 보고, 짧은 문장 많으면 smoothing을 반드시 켜세요.
- 전처리(소문자화, 구둣점 정리, 토큰화 규칙 일관화)가 점수에 큰 영향.

2) BERTScore (Recall 선택)

무엇을 보나: 사전학습 언어모델(예: BERT/DeBERTa)의 컨텍스트 임베딩으로 토큰 간 최대 코사인 유사도 매칭을 수행해 P/R/F1 산출.
- Recall은 “참조에 있는 내용이 후보에 얼마나 ‘포함’되었나”에 초점(= 커버리지).
강점
- 동의어·패러프레이즈·어순 변화에 강함 → 의미 유사도를 잘 반영.
- IDF 가중치로 정보량 큰 단어의 기여를 키울 수 있음.
- SQL→NL 맥락에서 “핵심 정보가 빠지지 않았는가”를 보기에 특히 적합(= Recall 지표의 해석과 딱 맞음).
약점
- 기본 모델/토크나이저 선택, 대소문자, 특수문자 처리에 민감.
- 유창성(fluency) 자체를 직접 보진 않음(문법이 어색해도 의미만 맞으면 점수는 높을 수 있음).
- 드물지만 반복 토큰이나 불용어 처리에 따라 과대평가 가능.
스케일/실무 팁
- 일반적으로 0.8~0.99 사이에 분포(말뭉치/모델에 따라 다름).
- Recall을 공식 메트릭으로 두고(커버리지), 필요하면 Precision/F1도 보조지표로 병행.
- 도메인 용어(컬럼명, 함수명)는 토크나이저가 쪼개지지 않게 사전처리 규칙을 고정하세요.

3) BARTScore (조건부 생성 확률 기반)

무엇을 보나: 사전학습 BART로 로그 가능도를 계산(teacher forcing). 보통 **평균 로그확률(토큰당)**을 쓰며 음수로 나옴.
- 방향이 중요:
  - ref→cand: 참조를 조건으로 후보를 “얼마나 자연스럽게 생성할 수 있나”(faithfulness/fluency).
  - cand→ref: 후보를 조건으로 참조를 “얼마나 재현할 수 있나”(coverage에 더 민감).
  - 두 방향 양방향 평균을 쓰면 균형적.
강점
- 유창성, 문장 구조, 장거리 의존성을 반영(단순 표면 일치보다 풍부).
- 길이가 길어도 문맥 일관성 평가에 비교적 강함.
약점
- 모델 편향(사전학습 분포)에 영향: 흔한 표현/안전한 문장을 선호.
- 길이 민감성 존재(평균화로 완화되지만 완전 제거는 아님).
- 참조 없이도 그럴듯한(유창한) 환각을 높게 칠 수 있어, 방향 선택/병행 보고가 중요.
스케일/실무 팁
- 원점수는 보통 음수(예: −6 ~ −1). 실험 비교를 위해 문장길이 정규화, 이어서 min‑max 후 z‑정규화를 추천(지금 하시는 방식 OK).
- **방향(ref→cand, cand→ref)**을 명시해서 기록하세요.

좀 말이 어려워서 GPT5에게 비전공자도 잘 이해할 수 있게 쉽게 내용설명을 해달라고 하였다.

1) BLEU-4

문장 속 단어 조각(n-gram)이 얼마나 똑같이 들어맞는지 보는 지표

“n-gram”은 연속된 단어 묶음이에요.
- 1-gram: 한 단어씩 → "red", "apple"
- 2-gram: 두 단어 묶음 → "red apple"
- 3-gram: 세 단어 묶음 → "a red apple"
예시
- 정답: "The boy eats an apple"
- 예측: "The boy eats a red apple"
→ 단어가 거의 같지만, 예측엔 *“red”*라는 단어가 추가.
→ BLEU는 정답에 없는 단어 때문에 점수를 조금 깎아요.
장점: 단어가 정확히 똑같이 나오면 높은 점수를 줌.
단점: 말은 다르지만 뜻이 같은 경우는 잘 잡아내지 못함.
- 정답: “He ate an apple”
- 예측: “The boy eats an apple”
  → 의미는 비슷한데 단어가 다르니 점수가 낮음.

2) BERTScore (특히 Recall 기준)

단어가 다르게 써도 의미가 같으면 높은 점수를 주는 지표

이건 단어를 그냥 글자로 보지 않고, 컴퓨터가 “뜻”으로 바꿔서 비교해요. (BERT라는 언어 모델이 해줌)
Recall은 “정답 문장에 있는 뜻이 예측 문장에 빠짐없이 들어갔나?”를 확인하는 방식이에요.
예시
- 정답: “The boy eats an apple”
- 예측: “The child is eating an apple”
  → 단어는 boy vs child, eats vs is eating 으로 다르지만 뜻은 거의 같음.
  → BLEU는 낮게 나오지만, BERTScore는 높게 나옴.
장점: 동의어, 문장 구조 차이를 잘 이해함.
단점: 문법이 어색해도 뜻만 맞으면 점수가 높을 수 있음.

3) BARTScore

언어 모델(BART)이 ‘이 문장이 자연스러운가?’를 확률로 계산한 점수

문장을 “사람이 쓴 것처럼 매끄러운가?”로 판단한다고 생각하면 됨.
계산 방식은 예측 문장을 보고 정답 문장을 얼마나 쉽게 떠올릴 수 있나, 혹은 그 반대로 보기도 해요.
예시
- 정답: “The boy eats an apple”
- 예측1: “The boy eats apple” (문법 어색)
- 예측2: “A boy is eating an apple” (자연스러움)
  → BARTScore는 예측2에 더 높은 점수를 줌.
장점: 문장 유창성과 자연스러움을 잘 평가.
단점: 뜻은 틀렸는데도 자연스럽게만 말하면 점수가 높게 나올 수 있음.

정리: 세 지표의 차이

BLEU-4 → “단어 똑같이 썼나?” (형식 중심)
BERTScore (Recall) → “뜻이 빠짐없이 들어갔나?” (내용 중심)
BARTScore → “사람이 쓴 것처럼 자연스러운가?” (유창성 중심)

쉽게 말하면:

BLEU는 정답 문장과 얼마나 똑같은 단어를 썼는가
BERTScore는 정답 문장과 뜻이 얼마나 잘 맞는가
BARTScore는 말이 얼마나 매끄럽고 자연스러운가

BERTScore는 BERT모델을 통해, BARTScore는 BART라는 모델을 통해서 문장의 매끄러운 정도를 평가하고, 이 때문에 Semantic 측면에서 비교해보자면 BERT나 BART를 쓰는 것이 맞다. 사실 BLEU_4는 받아쓰기 맹키로 너무 투박한 비교방법이긴 하다.

BERT(Encoder Only) / BART(Encoder+Decoder)는 각각 Google / Meta에서 만든 사전학습(Pre-trained) 언어모델이다.

BERTScore의 경우 '정답'과 '예측' 문장을 BERT Embedding 시켜서 Vector Similarity를 계산한다.

요건 이해하기가 쉽다.

반면 BART의 경우 Train할 때 원래 문장을 일부러 망가뜨리고 다시 복원하는 법을 배운다. 망가뜨린다는 것은, 단어 몇 개를 가리거나, 문장의 순서를 섞는 것이다.

즉, 정답 문장을 만들기 위해서 예측 문장이 얼마나 많은 수고를 해야 하는지를 판단하는 것이다. 품이 많이 든다면 Score는 낮고, 품이 적게 든다면 Score는 높다.

GPT5 dev	GPT5 train
GPT5 mini dev	GPT5 mini train
GPT5 nano dev	GPT5 nano train

일단 마사지 하기 전, 데이터는 위와 같은데 dev / train set 모두 nano 모델에서 RAG Hybrid가 가장 성능이 좋다. 근데 생각보다 드라마틱한 성능향상은 없어서 좀 머쓱하긴 하다..

추가로 생각해보면,, BARTScore는 빼는게 낫지 싶다. NL의 유사도를 보는데 문장의 자연스러움?은 굳이 왜 보는가 하는 의구심이 들기 때문이다.

1. 두 문장이 단어겹치는게 많다면 유사하다 -> 합당한 논리 -> BLEU-4 Score

2. 두 문장의 BERT Embedding 후 유사도가 높다 -> 합당한 논리 -> BERTScore Recall

위 2개만 가져가고, 나머지 평가지표로 Text2SQL 모델을 합쳐서(?) 평가를 진행하고자 한다.

+ Human Based 평가까지! 이거는 연구실 사람들에게 Survey 방식으로 부탁을 좀 해야겠다.

이게 잘만 먹히면 진짜 좋은 Text2SQL 모델을 하나 만들 수 있는 것이다..!

근데 어떻게 잘 만들 수 있나?

기존에 NL2SQL은, Gold NL 넣고 Predicted SQL과 Gold SQL의 쿼리 실행결과를 비교해서 Execution Accuracy (EX) 를 측정한다.

이거 잘 할려고 NL Prompt에 Schema linking, Few-shot 등등 지금 SQL2NL에 적용시킨 모든 기법을 포함한 각종 기교를 부린다.

모델 Fine tuning도 물론 시키겠지..!

NL2SQL Frame work는 크게 두 가지 In-Context-Learning : Prompt Engineering , Model Finetuning 로 나뉜다.

위 Frame work에서 내 SQL2NL을 어디다가 사용할까...?

요즘엔 이 영역이 강화학습으로 넘어가서 Model Finetuning에 집중된다고 하는데(Prompt는 거의 포화상태 ;; ) 이 기법을 Model Tuning에 사용할 수 있으련지..

어쨌든 GPT랑 대화하며 내 것을 text-to-sql 파인튜닝에 쓸 수 있는 방안 마련중...

확실히 RAG이용 Few-shot은 괜찮을 듯 허다. Few-shot의 퀄리티가 아무래도 높으니..

BIRD제출할때 FAISS DB도 제출할 수 있나...? FAISS DB를 open Cloud에 올리고 그걸 코드에 넣어도 될듯?

메모장 내용이 좀 중구난방이라 새로운 글을 다시 파야겠다.

골자는, SQL2NL Model을 (미숙하지만) 잘 만들었다고 치고, 이걸 NL2SQL Model에 어떻게 적용시키냐이다..

- To Be Continued -

[Review]Is Long Context All You Need? Leveraging LLM's Extended Context for NL2SQL

eatplaylove — Fri, 29 Aug 2025 11:38:07 +0900

https://arxiv.org/abs/2501.12372

Is Long Context All You Need? Leveraging LLM's Extended Context for NL2SQL

Large Language Models (LLMs) have demonstrated impressive capabilities across a range of natural language processing tasks. In particular, improvements in reasoning abilities and the expansion of context windows have opened new avenues for leveraging these

arxiv.org

2025 VLDB에 개제된 Google에서 발표한 논문이다.

Google에서도 Text2SQL을 연구하는 팀이 있을텐데 그 팀에서 주기적으로 해당분야와 관련된 논문을 기재한다.

그 유명한 BIRD Benchmark에서 저기 3위에(2025.08.29 기준) 랭크되어 있는 팀이다.

본 논문의 골자는, 기존의 NL2SQL 방법을 전체적으로 소개하며 동시에 은근히 Google의 최신 LLM인 gemini-1.5-pro를 홍보하는 글로 보인다.

기존에는 LLM의 Context수용 한계로 어떻게든 LLM에 적절한 정보를 잘 추려서 전달하는 것이 중요했기에 Text Query와 Relevant한 Hint를 찾는 것에 사람들은 공을 많이 드렸다.

또는, LLM Call을 짧게 여러 번 해서 Agent AI의 느낌으로 NL2SQL Task를 수행하는 연구도 많았다.

(위 내용들 포함해서 다양한 기법들이 본 논문에 소개 됨)

Is Long Context All You Need_Leveraging LLM’s Extended Context for NL2SQL.pdf

0.81MB

저자는 그런 것들 필요 없이 gemini-1.5pro를 이용하면 한 Context에 약 1~10M의 Token을 담을 수 있기 때문에 Hint 추리지도 말고 그냥 통째로 넣으면 된다고 했다.

그러면 보통 LLM이 ' Lost in the middle ' 현상을 일으켜서 많은 Hint들 중에 진짜 필요한 것이 무엇인지 모르고 오답을 내놓는다고 했는데 Gemini 1.5는 정답을 곧 잘 찾아낸다는 것을 실험으로 보여주는 논문이다.

굳이, 자랑글 같은 이 논문을 왜 탐색해봤냐면 논문의 도입부부터 중간 중간 Reference들에 현재까지의 NL2SQL 동태가 잘 정리된 것들이 많이 보이기 때문에 그 점은 참고하기 좋을 거 같아서 논문을 읽어봤다.

즉, 논문에서 As is 와 To be를 비교할 때 사실 To be는 gemini 자랑밖에 없어서 굳이 안 읽어도 되지만 As is 부분을 잘 읽다보면 현재까지 NL2SQL 연구가 어찌 진행되어 왔는지 Summary로 찾아볼 수 있는 것이다.

나한테 있어서 이제 생각해볼 Topic은, 나의 SQL2NL 연구를 NL2SQL에 어떻게 접목시킬 수 있을까? 이다. 이 때문에 해당 논문을 보면서 NL2SQL 연구들 중에 SQL2NL이 비짚고 들어갈 틈이 있는지 보려했는데 잘 보이지 않는다. . ㅠ

그냥 SQL2NL은 SQL2NL로 따로 분류해서 논문쓰는 것으로 정리하고 NL2SQL영역은 다시 검토해야하나.. 싶다.

NL2SQL의 Output인 SQL가지고 다시 SQL2NL 결과를 통해 #강화학습 또는 BenchMark 평가로 이용할 수 있지 않을까..했는데 제일 문제는 내가 SQL2NL에 손을 대는 그 순간부터 의구심을 품었던..

도대체 SQL2NL에서 반환된 'NL'에 대해서 어떻게 정확도를 평가하겠다는 건가.. 이다.

매번 사람이 개입해서 평가할 순 없는 것 아닌가..? 그렇다고 BERTScore나 BLEU_4를 쓰자니 너무 단순한 Evaluation만 된다.

하.. 실익이 너무나도 없어보이지만 시간도 없고 무엇보다 의욕도 없어서 ㅋㅋㅋ 대충 주먹구구식으로 연구마무리를 해야겠다는 생각이 든다.

1) SQL2NL 그 자체로 실험결과 뽑아 놓았던 것들만 잘 정리하기

2) NL2SQL과 어떻게든 엮어보기

-> 적어도 BIRD BenchMark에선 잘 동작하는(특정 Domain Specific한) SQL2NL 모델을 STEP 1에서 만든다.

-> 이제 STEP2로 넘어 간다.

-> 전반적인 NL2SQL 모델이 아닌, 특정 Domain Specific(Like BIRD)한 NL2SQL 모델이 Target이다.

위 Logic대로 하면 꽤나 Fancy한 논문이 더러 나올 수 있다고 생각한다.

아 제발요옹~~