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

https://eglife.tistory.com/364

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

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). 스케일/실무 팁 보통 01(혹은 0100)로 보고, 짧은 문장 많으면 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 -