-
Notifications
You must be signed in to change notification settings - Fork 4
Lang2SQL의 refined 된 질문에 대한 평가
이 문서는 Lang2SQL의 refined 된 질문에 대한 평가를 고민하며 작성한 내용입니다.
아직은 생각의 흐름을 정리한 초안 단계로, 제 생각을 공유드리고 싶어 문서를 작성하게 되었습니다.
이 문서에서는 이때까지 나왔던 SQL 쿼리 생성에 대한 전반적인 평가가 아닌, 자연어 질의 구체화(NL Question Refinement)에 초점을 맞추어 작성되었습니다.
한편으로는 평가지표를 직접 구현하는 작업이 현재 프로젝트의 본래 방향성과 다소 괴리가 있는 것이 아닐까 하는 고민도 들었습니다.
하지만 동시에, refined 된 질문을 적용했을 때 정량적으로 얼마나 개선되었는지를 판단할 수 없다는 점에서,
기능을 섣불리 추가하거나 개선 방향을 결정하는 것이 망설여지기도 했습니다.
그래서 현재는 다음과 같은 방식으로 접근해보는 것을 고민하고 있습니다.
Refined 된 질문을 평가하는 기능을 사용자에게 옵션으로 제공하고, 설정된 기준을 만족할 때까지 구체화 결과를 재생성하는 방향으로 시스템을 설계하는 것입니다.
Lang2SQL의 refined 된 질문은 사용자의 의도를 더욱 정확하게 반영하기 위해, 사용자의 모호한 질의를 refined 된 질문으로 변환합니다.
그러나 refined 된 질문이 정말 사용자의 의도를 정확하게 반영하는지에 대한 검증이 필요합니다.
우선 좋은 구체화란 무엇인지 생각해보아야 합니다.
좋은 refined 된 질문이란, 사용자의 원 질문이 담고 있는 의도를 왜곡하지 않으면서, SQL 생성을 위해 필요한 정보를 정확하고, 명확하며 불필요하지 않게 덧붙인 문장입니다.
Refined 된 질문이 좋은 구체화인지 판단하기 위해서는 다음과 같은 기준을 세울 수 있습니다.
- 목적 일치 : 원 질문의 의도를 해치지 않음
- 구체성 : 시간, 조건, 컬럼 등이 명시적으로 드러남
- 스키마 정렬 : DB 테이블/컬럼과 논리적으로 잘 매칭됨
- 정보 과잉 방지 : 불필요한 정보(테이블, 조건)가 포함되지 않음
- SQL 유도성 (SQL-ability) : SQL로 바꾸기 쉬운 구조
구체적인 질문을 생성할 때, 원 질문의 의도를 해치지 않는 것이 가장 중요합니다.
아래 평가에는 모두 원 질문과 refined 된 질문이 필요합니다.
평가 방법 | Input | Output | 필요 조건 |
---|---|---|---|
Semantic Similarity | 원 질문, refined 된 질문 | 의미적 유사도 점수 (0~1) | 임베딩 모델 |
Textual Entailment | 원 질문, refined 된 질문 | entailment 여부 확인 | LLM을 통한 비교 |
Back Translation | Refined 된 질문 | 복원된 질문 → 이후 원 질문과 비교 | LLM을 통한 비교 (질문 복원, 비교 관점에서 필요) |
평가 방법 :
-
Semantic similarity
Refined 된 질문과 원 질문의 의미적 유사성을 평가합니다.
Refined 된 질문과 원 질문간의 코사인 유사도를 계산하여 일정 임계값 이상일 때 의미 보존이 된 것으로 생각할 수 있습니다. -
Textual entailment
Refined 된 질문이 원 질문을 포함하는지 평가합니다.
GPT를 한번 더 거쳐 본래의 질문에서 크게 벗어났는지 평가할 수 있습니다. -
Back translation
Refined 된 질문을 다시 원 질문으로 변환했을 때 원 질문의 의도와 의미적으로 비슷한지 확인합니다.
textual entailment
와 마찬가지로 GPT를 사용해 검사할 수 있으며, 교차 검증하는 것도 생각해 볼 수 있습니다.
Back translation
과 Textual entailment
를 사용하여 대조적으로 얼마나 달라졌는지 유추할 수 있습니다.
예를 들어, Back translation
는 refined 된 질문을 다시 원 질문으로 복원하는데, 질문이 잘 구체화 되었을 경우에도
원 질문과 유사한 의미로 변환되지 않을 수 있습니다.
왜냐하면 refined 된 질문은 원 질문에 포함된 정보들이 나타나지 않을 수 있기 때문입니다.
그렇기에 Textual entailment
과정을 거쳐 refined된 질문이 원 질문을 포함하는지에 대한 여부를 확인할 수 있습니다.
Back translation
을 통해 refined 된 질문이 원 질문과 유사하면서 Textual entailment
과정을 통과한다면 의미가 왜곡된
질문으로 확장되지 않을 가능성이 있다고 판단할 수 있습니다.
추상적인 표현을 제거하고, SQL 생성에 필요한 요소를 명시해야 합니다.
이를 위해 먼저 특징 추출(Feature extraction
) 단계를 거쳐, 질문이 어떤 SQL 구조를 요구하는지 파악합니다.
Feature Extraction: Refined 된 질문으로부터 다음과 같은 특징을 추출합니다.
{
"is_timeseries": true, // 시계열 분석이 필요한 질문 여부
"is_aggregation": true, // 집계 함수(SUM, AVG 등)가 필요한지 여부
"has_filter": true, // 필터 조건(WHERE)이 필요한지 여부
"is_grouped": true, // 그룹화(GROUP BY)가 필요한지 여부
"has_ranking": true, // 순위 계산(TOP N, ORDER BY)이 필요한지 여부
"has_temporal_comparison": false, // 기간 간 비교(전월 대비 등)가 필요한지 여부
"intent_type": "trend" // 질문의 주요 의도 유형 (trend, lookup, comparison, distribution 등)
}
원 질문과 refined 된 질문 모두 Feature Extraction
단계를 거쳐, 구체화 수준의 변화를 확인할 수 있습니다.
항목 | 설명 |
---|---|
Input | 원 질문과 refined 된 질문 각각에 대해 Feature Extraction 수행 결과 |
Output | Feature 수 비율 (실수값) |
필요 조건 | LLM 파싱 모델을 통해 Feature Extraction을 수행 |
평가 방법 :
-
특징 수 증가 (Feature Gain)
Feature Extraction
결과에서 추출된 핵심 특성의 비율을 계산합니다.Feature Gain = Refined 된 문장의 Feature 개수 / 원 문장 Feature 개수
Feature Gain
을 측정했을 때, 아래와 같이 해석할 수 있습니다.
경우 | 해석 | 의미 |
---|---|---|
Feature Gain > 1 | Refined 된 질문에서 Feature가 더 많이 등장함 | 구체성이 증가했을 가능성 |
Feature Gain ≈ 1 | Feature 수가 거의 동일 | 구체화 과정이 거의 정보 확장을 안 했을 가능성 |
Feature Gain < 1 | Refined 된 질문에서 Feature가 오히려 줄어듦 | 구체화 과정에서 정보 손실이 발생했을 가능성 |
Refined 된 질문은 자연어 문장 안에 필요한 정보를 담는 것뿐만 아니라, 데이터베이스(DB) 테이블과 컬럼과 논리적으로 정확히 연결되어야 합니다. 특히 질문 표현이 DB 스키마와 일치하도록 보완합니다.
평가 방법 | Input | Output | 필요 조건 |
---|---|---|---|
Schema Match Score | Refined 된 질문 | 스키마 매칭 비율 (0~1) | 엔티티 추출 모델(GPT, BM25 등) + 실제 DB 스키마 정보 |
평가 방법 :
-
Schema Match Score
Refined 된 질문에 언급된 테이블/컬럼 중, 실제 DB 스키마에 존재하고 논리적으로 일치하는 비율을 계산합니다.항목 의미 논리적으로 매칭된 엔티티 수 - Refined 된 질문에 등장한 테이블명/컬럼명 중
- 실제 DB 스키마에 존재하는 엔티티 수Refined 된 질문에서 언급된 엔티티 수 - Refined 된 질문 문장 안에서
- 테이블명, 컬럼명으로 추정되는 표현들의 총 개수
(실제 DB에 존재하는지 여부는 아직 고려하지 않음)
Schema Match Score = 논리적으로 매칭된 엔티티 수 / Refined 된 질문에서 언급된 엔티티 수
엔티티 수는 GPT 또는 BM25를 활용해 추출할 수 있습니다.
Refined 된 질문이 필요한 정보들을 포함하지만 불필요한 테이블, 컬럼명, 조건등을 과도하게 추가하면 SQL 쿼리 성능이 나빠질 수 있습니다.
그렇기에 질문에 불필요한 정보가 포함되는지 확인하고 정보가 과잉되지 않도록 질문을 생성해야 합니다.
평가 방법 | Input | Output | 필요 조건 |
---|---|---|---|
Expansion Rate | 원 질문, refined 된 질문 | 토큰 수 비율 (실수값) | 질문 토큰화(Tokenization) 및 토큰 수 계산 |
Entity Gain | 원 질문, refined 된 질문 | 엔티티 수 비율 (실수값) | 엔티티 추출 모델(GPT, BM25 등) 및 엔티티 수 계산 |
평가 방법 :
-
Expansion Rate
원 질문과 refined 된 질문의 토큰 수를 비교합니다. 정보량이 얼만큼 증가했는지 바로 확인할 수 있습니다.
질문이 질적으로 개선되었는지 보다는 양적으로 정보량이 얼마나 증가했는지 평가합니다.Expansion Rate = Refined 된 질문 토큰 수 / 원 질문 토큰 수
-
Entity Gain
원 질문에서 사용되는 엔티티(테이블, 컬럼등)의 개수와 refined 된 질문에서의 엔티티 개수를 비교합니다.
질문이 얼만큼 질적으로 개선되었는지 평가할 수 있습니다.
또는,Entity Gain
을 기반으로 정보 과잉 여부도 판단할 수 있습니다.
엔티티 추출에는 GPT를 사용하거나 BM25를 활용하는 방법이 있습니다.Entity Gain = 구체화 후 엔티티 수 / 구체화 전 엔티티 수
Expansion Rate
가 큰데 Entity Gain
이 작다면, 문장은 길어졌지만 실질적인 정보(테이블/컬럼)는 적어 부실하게 구체화되었을 가능성이 있습니다.
반대로 Expansion Rate
가 작은데 Entity Gain
이 크다면, 짧은 문장 안에 필요한 구체적 정보가 효과적으로 담겼을 것으로 예측할 수 있습니다.
또한 Feature extraction
단계에서 나온 특징도 함께 확인하여 원 질문의 의도에 불필요한 정보가 포함되지 않았는지 확인할 수 있습니다.
이를 통해 refined 된 질문에서 정보가 과잉되었는지 판단합니다.
Refined 된 질문은 자연어로 읽기 쉬울 뿐만 아니라, SQL 쿼리로 변환하기 쉽게 구조화되어야 합니다.
이 과정은 refined 된 질문 평가뿐만 아니라, 실제 SQL 실행 가능성까지 일부 포함하고 있습니다.
평가 방법 | Input | Output | 필요 조건 |
---|---|---|---|
SQL Success Rate | Refined 된 질문 | 유효한 SQL 생성 성공 여부 (성공/실패) 또는 성공 비율 | SQL 자동 생성 모델 또는 파이프라인 |
Syntax Mapping Checklist | Refined 된 질문 | SQL 구문 요소(SELECT, WHERE, GROUP BY 등) 매핑 비율 | 구문 요소 체크리스트를 LLM으로 평가 |
Feature Extraction 기반 진단 | Refined 된 질문의 Feature Extraction 결과 | SQL 유도성에 대한 진단 결과 | Feature Extraction 결과를 기반으로 사람이 직접 또는 GPT를 통해 SQL 유도성 판단 |
평가 방법 :
-
SQL Success Rate
Refined 된 질문을 입력으로 SQL을 자동 생성할 때, 문법 오류 없이 유효한 SQL 쿼리를 생성할 수 있는 비율을 측정합니다.
실행 여부에는 호민님께서 제안주셨던 SQLGlot을 사용할 수도 있습니다.
그러나 평가를 정량적으로 평가할 데이터셋이 없기 때문에, 아래 방법들을 사용할 수 있습니다. -
Syntax Mapping Checklist
GPT를 거쳐 질문 문장에서 SELECT / WHERE / GROUP BY / ORDER BY 구문 요소로 자연스럽게 매핑할 수 있는 키워드 비율을 측정합니다.
평가 요소를 정리한 json 구조를 정의해서 사용할 수 있습니다. -
Feature Extraction 기반 진단
Refined 된 질문에서 추출된 시간 조건, 필터 조건, 집계 등 특성 정보를 활용하여 사람이 직접 SQL 생성 준비 상태를 진단합니다.
이렇게 산출된 각 평가 지표 점수를 바탕으로, 사용자는 생성된 쿼리의 품질을 평가하고 신뢰성을 부여할 수 있습니다.
또한, 각 평가 지표별로 사용자가 설정한 Threshold를 기준으로, 품질이 만족스러운 수준에 도달할 때까지 구체화 과정을 반복하거나 쿼리를 재생성하는 데 활용할 수 있습니다.