10. Spider 72%, 오답은 모델보다 데이터셋에서 갈렸다

9편에서 multi-candidate 실험 세 건이 모두 유의미한 결과를 내지 못했지만 Schema Binding Plan으로 넘어가기 전에 확인하고 싶은 것이 하나 더 있었습니다.

모델 성능이 병목의 원인일 수 있다는 가설을 검증했습니다. Gemini flash-lite 대신 Pro 모델을 쓰면 현재 56% 수준인 정확도를 개선할 수 있을 것이라 예상했습니다. 이 과정에서 오답 유형 분류와 Spider 실험도 함께 진행했습니다.

Pro 모델로 바꿨더니 오히려 정확도가 떨어졌다

모델만 교체하고 동일한 BIRD 50문항을 실행했습니다(프롬프트, 컨텍스트, 파이프라인은 그대로). 지표는 EX(Execution Accuracy)로, 생성된 SQL을 실제로 실행했을 때 정답과 같은 결과가 나오는지 확인하는 방식입니다.

Δ -8.0%p.

새로 맞춘 것은 3건에 그쳤고, 기존에 맞았던 7건은 오히려 오답으로 바뀌었습니다. 오답으로 바뀐 케이스 대부분이 Czech 금융 DB에서 나왔습니다. QID 168은 2개의 테이블을 JOIN하면 되는 질문인데 Pro가 4개 테이블을 조인하여 SQL을 만들었습니다. 더 정확한 경로를 찾으려는 의도였겠지만 정답과는 거리가 멀어졌습니다. QID 39에서는 SQL 생성 자체를 거부했습니다. 같은 질문에 flash-lite는 SQL을 생성했었습니다.

직접 만든 30문항에서는 Pro가 약간 나은 기록이 있습니다. Pro 모델 자체의 성능 문제라 보기는 어렵습니다. 다만 자체 문항은 익숙한 DB와 질문 패턴으로 구성되어 있어 처음 보는 DB 50개로 구성된 BIRD에서 나온 결과와는 직접 비교하기 어렵습니다. 일반화 성능 기준으로는 BIRD 쪽이 더 신뢰할 수 있습니다.

모델 체급이 이 파이프라인 병목의 직접적인 원인은 아니라고 판단했습니다.

오답 19건 유형 분류

9편에서 사용한 BIRD 벤치마크 50문항을 동일하게 실행했습니다. 27건이 오답이었고 이 중 4건은 채점기가 버전별로 다르게 판정하는 오류였습니다. 나머지 19건이 실제 파이프라인 문제입니다.

• COLUMN_BINDING: JOIN이나 SELECT에서 잘못된 컬럼을 선택한 경우입니다. “파란 여성 슈퍼히어로 비율"을 묻는 질문에서 LLM이 눈 색깔 컬럼(eye_colour_id)으로 JOIN을 걸었는데 정답 SQL은 피부 색깔(skin_colour_id)을 써야 했습니다. 두 컬럼 이름이 비슷하고 둘 다 colour 테이블을 참조하기 때문에 스키마만 봐서는 어느 쪽을 써야 하는지 알기 어렵습니다.

• VALUE_BINDING: WHERE 절에 들어갈 값 자체를 잘못 추정한 경우입니다. Czech 금융 DB에서 “현금 인출 내역"을 찾는 질문이 있었습니다. DB에는 거래 유형이 체코어로 저장되어 있어서 현금 인출은 VYBER라는 값으로 기록됩니다. LLM은 이 값을 모른 채 cash withdrawal로 WHERE 절을 만들었고 당연히 매칭되는 행이 없어서 빈 결과가 나왔습니다. DB에 어떤 값들이 실제로 저장되어 있는지 알지 못하면 생기는 오류입니다.

• DERIVED_METRIC: 값을 유도하는 전략 자체가 달라서 결과가 실제로 달라진 경우입니다. 두 패턴이 있습니다. 하나는 계산 전략 오류입니다. 정답 SQL이 INTERSECT로 교집합을 구하는데 LLM이 JOIN으로 접근하면 중복 처리 방식에 따라 다른 결과가 나옵니다. 다른 하나는 평가 에지 케이스입니다. SUM(CASE WHEN ...) vs COUNT(CASE WHEN ...) 처럼 대부분 같은 결과를 내지만 NULL이 있을 때만 갈리는 식인데 채점기가 실행 결과를 비교하더라도 데이터 특성에 따라 오답 판정이 나올 수 있습니다. Spider에서 이 유형이 늘어난 것은 INTERSECT/EXCEPT 기반 질문이 많기 때문입니다.

• HIDDEN_JOIN: 질문에 명시되지 않은 중간 테이블을 거쳐야만 원하는 테이블에 도달할 수 있는 케이스입니다. “A 테이블의 X와 C 테이블의 Z를 연결하려면 사실 중간에 B 테이블을 거쳐야 한다"는 식입니다. 이런 join path 문제를 그래프 탐색으로 해결하면 된다는 제안이 있어서 눈여겨봤는데 BIRD 19건에서는 한 건도 없었습니다. BIRD에서는 주된 오답 원인이 아닙니다.

• GENERATION_FAILURE: SQL 자체를 생성하지 않은 경우입니다. Pro tier 측정에서 처음 나왔고 flash-lite에서는 관찰되지 않았습니다. 더 신중한 모델일수록 불확실한 상황에서 SQL 생성을 거부하는 경향이 강해지는 것으로 보입니다.

• LEXICAL_NORMALIZATION: 질문 텍스트에 있던 소문자가 WHERE 절에 그대로 들어가 DB에 저장된 값과 대소문자가 달라지는 패턴입니다. 'active'로 쿼리했는데 DB에는 'Active'로 저장된 경우가 이 유형입니다.

오답의 63.2%가 바인딩(binding) 단계에 집중됐습니다. 스키마 대응(grounding) 계층 이 병목입니다. 자연어 질문의 개념을 실제 컬럼·값에 연결하는 단계입니다.

COLUMN_BINDING과 VALUE_BINDING, 두 유형 모두 SQL을 생성하기 전에 “어떤 컬럼을, 어떤 값으로” 쓸지 결정하는 단계에서 어긋납니다. SQL 문법 오류가 아니라 스키마를 제대로 이해하지 못해서 발생하는 오류입니다.

Spider에서 돌렸더니 분포가 달라졌다

Spider는 Yale NLP에서 공개한 Text-to-SQL 벤치마크로, BIRD보다 DB 구조가 단순하고 도메인이 일반적입니다. 같은 파이프라인을 Spider에 실행했습니다. 50건, SQLite, 20개 DB 기준입니다.

Spider EX: 72.0% (36/50)

BIRD보다 16%p 높습니다. 수치 차이보다 유형별 분포에서 더 흥미로운 점이 보였습니다.

• VALUE_BINDING이 Spider에서 완전히 사라졌습니다. BIRD의 Czech 금융 DB처럼 LLM이 추측하기 어려운 도메인 특수값이 Spider에는 거의 없기 때문입니다. Spider의 DB들은 대부분 영어권의 일반적인 데이터를 담고 있어서 값 추정이 상대적으로 쉽습니다.

• 반대로 DERIVED_METRIC은 크게 늘었습니다. Spider에는 두 집합의 차집합이나 교집합을 구하는 INTERSECT/EXCEPT 기반 질문이 많이 포함되어 있고 이 집합 연산을 정답 SQL과 같은 방식으로 표현하지 못하는 경우가 이 유형입니다.

Spider 14건은 모두 기존 분류 안에 들어왔습니다. 새로운 유형은 나오지 않았습니다. 분류 체계 자체는 두 데이터셋에서 유효합니다.

같은 파이프라인인데 어디서 틀리는지는 데이터셋에 따라 달랐습니다. BIRD에서 VALUE_BINDING이 많았던 것은 Czech 금융 도메인 때문이고 Spider에서 DERIVED_METRIC이 많은 것은 집합 연산 질문이 많기 때문입니다. 어떤 유형이 주로 나오는지는 모델보다 DB 특성에 더 의존합니다.

지난 2주간 검증한 것들

정확도 측정값을 시계열로 정리하면 다음과 같습니다.

앞 세 방향의 실험 과정과 실패 원인은 9편 에서 상세히 다뤘습니다. 공통 결론은 하나였습니다. SQL을 실행한 뒤 고르는 방식으로는 한계가 있고, 생성하기 전에 이미 올바른 컬럼과 값이 특정되어 있어야 한다는 것입니다.

Model scaling은 이번에 추가한 검증이었습니다. 모델을 바꿔도 같은 문제가 남았고 결과는 오히려 -8%p였습니다.

참고로, 이 과정 내내 온톨로지를 완전히 배제하고 실험한 것은 아니었습니다. 8편 시작 시점에 이미 Vanna에 DDL과 Glossary YAML(25개 비즈니스 용어)을 학습시킨 상태였고 66.67%가 그 조건의 첫 측정값입니다. 80%도 거기서 올린 수치입니다.

문제는 범위였습니다. 이 Glossary가 유통 도메인에 특화되어 있었습니다. BIRD는 Czech 금융 DB, 슈퍼히어로 DB 같은 11개 도메인을 섞어서 보는 벤치마크입니다. 처음 보는 도메인에서는 유통용 Glossary가 작동하지 않습니다. 사실상 효과를 내지 못합니다.

결국 BIRD 56%는 “온톨로지를 아직 안 넣어서 낮게 나온 숫자"가 아닙니다. 온톨로지가 있어도 학습되지 않은 도메인에서는 효과가 없다는 것을 확인한 수치입니다.

다음 작업인 Schema Grounding 재설계는 이 연장선입니다. YAML로 미리 정의해두는 방식은 처음 보는 DB에서 한계가 뚜렷합니다. 컬럼 선택 로직뿐 아니라 실제 저장값(value-level semantics)을 해석하는 레이어가 따로 필요합니다.

마무리

다음은 Schema Grounding 재설계입니다. 컬럼을 제대로 고르고 값을 올바르게 추정하는 단계를 개선하는 작업으로, 이제 구현 쪽으로 넘어갑니다.

BIRD 19건과 Spider 14건, 합산 33건의 오류 레이블 데이터셋이 남아 있습니다. 이 데이터셋은 다음 단계 우선순위 설계에 직접 활용합니다. COLUMN_BINDING과 DERIVED_METRIC은 “스키마를 더 잘 이해하면 고쳐진다"는 방향이 같습니다. 어떤 컬럼을 쓸지, 어떤 집합 연산을 쓸지는 모두 스키마 구조를 깊이 파악하면 해결할 수 있습니다. VALUE_BINDING은 결이 다릅니다. VYBER 같은 값은 스키마를 아무리 잘 읽어도 알 수 없고 DB에 실제로 어떤 값들이 저장되어 있는지를 별도로 파악해야 합니다. 지금 준비하는 Schema Grounding으로는 앞 두 유형을 먼저 잡고 VALUE_BINDING은 그다음 단계에서 다룹니다.

WikiSQL 같은 추가 데이터셋도 후보에 있지만 Phase 1 이후에 검토할 예정입니다.