🤖 AI

SIRIUS-SQL: Anchoring Multi-Candidate Text-to-SQL in Execution Feedback

SIRIUS-SQL은 다양한 생성을 위한 난이도 평활화 RL 학습 전략, 표적 오류 수정을 위한 실행 기반 라이프사이클, 그리고 신뢰도 게이트형 하이브리드 선택기를 통해 기존 멀티 후보 시스템의 한계를 해결함으로써 복잡한 스키마에서의 정확도를 향상시킨 혁신적인 Text-to-SQL 프레임워크로, BIRD 및 SPIDER 벤치마크에서 최첨단 성능을 달성했습니다.

원저자: Leo Luo, Haining Xie, Siqi Shen, Zhipeng Ma, Rui Ling, Hang Xu, Hefeng Jiang, Dingwei Chen, Yang Li, Peng Chen, Jie Jiang

게시일 2026-06-02

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Leo Luo, Haining Xie, Siqi Shen, Zhipeng Ma, Rui Ling, Hang Xu, Hefeng Jiang, Dingwei Chen, Yang Li, Peng Chen, Jie Jiang

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신이 로봇 요리사(AI)에게 아주 구체적이고 복잡한 지시를 내려 요리를 하게 하려고 한다고 상상해 보세요(SQL 쿼리를 작성하는 것). 이 요리는 거대하고 엉망진창인 레시피 북(데이터베이스)을 바탕으로 합니다.

만약 당신이 로봇에게 딱 한 번만 요리를 해달라고 요청한다면, 레시피 북이 혼란스럽거나, 재료 이름이 이상하거나, 혹은 지침이 모호하기 때문에 종종 실수를 저지르게 됩니다.

기존 방식: "다수결"의 문제점
최근 다른 시스템들은 이 문제를 해결하기 위해 로봇에게 요리를 한 번이 아니라 16번 하게 시도했습니다. 그러고 나서 16개의 요리 중 사람들이 가장 많이 동의한 것을 고르는 방식(다수결)을 사용했습니다.

이 논문의 저자들인 SIRIUS-SQL은 이 "다수결" 방식에 세 가지 큰 문제가 있다고 말합니다:

에코 체임버(Echo Chamber, 메아리 방): 만약 동일한 로봇에게 16번 요리를 시킨다면, 그 로봇은 계속해서 똑같은 실수 16번을 반복할 것입니다. 이는 마치 한 사람에게 비밀번호를 16번 추측해 보라고 하는 것과 같습니다. 그 사람은 아마 똑같은 오답을 16번 내놓을 것입니다.
"일률적인" 해결책: 요리가 잘못 나왔을 때, 기존 시스템들은 단순히 "아, 망했네, 다시 해봐"라고 말할 뿐, 어떻게 망했는지는 살펴보지 않습니다. 냄비가 탔나요? 소금을 넣는 걸 깜빡했나요? 아니면 잘못된 팬을 사용했나요? 이 모든 것은 서로 다른 해결책이 필요하지만, 기존 시스템은 이를 모두 똑같이 취급합니다.
잘못된 승자: 때로는 16개의 요리 더미 속에 정답인 요리가 놓여 있음에도 불구하고, 사람들이 엉뚱한 것(예: 맛 대신 재료 목록만 보는 경우)을 보고 다수결로 잘못된 승자를 뽑기도 합니다.

SIRIUS-SQL의 솔루션: 마스터 셰프와 제너럴리스트
SIRIUS-SQL은 세 가지 전략으로 이 문제들을 해결합니다:

1. "전문가"와 "제너럴리스트" (에코 체임버 해결)

한 명의 로봇에게 16번 요리를 시키는 대신, 두 명의 서로 다른 셰프를 사용합니다:

전문가 (SIRIUS-32B): 이 로봇은 요리(SQL)에 특화되어 훈련되었습니다. 이 로봇은 요리가 실제로 성공했을 때만 보상을 받는 특별한 "보상 시스템"(강화 학습)을 통해 학습되었습니다. 이 로봇은 단순히 똑같은 실수를 반복하는 것이 아니라, 정답인 요리의 다양한 버전들을 만들어내는 법을 배웁니다.
제너럴리스트 (Generalist): 이 로봇은 까다로운 언어나 이상한 지시사항을 잘 이해하는 매우 똑똑하고 다재다능한 범용 로봇(유명한 AI 모델 같은 존재)입니다.
결과: 전문가의 깊은 지식과 제너럴리스트의 폭넓은 이해력을 결합함으로써, 이들은 훨씬 더 다양한 시도를 얻어냅니다. 이는 마치 숙련된 스시 셰프와 창의적인 프랑스 요리사가 함께 협력하는 것과 같습니다. 그러면 그중 한 명은 반드시 레시피를 완벽하게 해낼 확률이 높아집니다.

2. "트리아지 간호사" 시스템 (일률적인 해결책 해결)

요리가 잘못되었을 때, SIRIUS-SQL은 단순히 "다시 해봐"라고 하지 않습니다. 마치 병원의 트리아지(응급 분류) 간호사처럼 정확히 무엇이 잘못되었는지 진단합니다:

런타임 에러 (냄비가 탄 경우): 로봇이 존재하지 않는 도구를 사용하려고 했습니다. 시스템은 즉시 구문(syntax)을 수정합니다.
타임아웃 (가스레인지가 너무 느린 경우): 레시피가 너무 복잡하여 시간이 너무 오래 걸립니다. 시스템은 맛을 바꾸지 않으면서도 더 효율적으로 작동하도록 레시피를 다시 작성합니다.
빈 결과값 (팬이 비어 있는 경우): 로봇이 레시피를 완벽하게 따랐지만, 엉뚱한 재료를 찾았기 때문에 결과가 비어 있는 상태입니다. 시스템은 올바른 재료를 찾기 위해 특정 "구조적" 수정을 시도합니다.

이러한 특정 수정 과정을 거친 후에야 비로소 다시 시도할 기회를 얻습니다. 이는 시스템이 불가능한 해결책에 헛된 노력을 낭비하는 것을 방지하여 시간을 절약해 줍니다.

3. "스마트 판사" (잘못된 승자 해결)

마지막으로, 요리 더미에서 최고의 요리를 고를 때, 시스템은 두 단계의 투표 과정을 사용합니다:

1단계: 맛 테스트: 실제 결과물을 확인합니다. 만약 10개의 요리 맛이 같다면, 높은 점수를 부여합니다.
2단계: 타이 브레이커 (결정적 한 방): 만약 두 그룹의 요리가 동일한 맛 점수를 가진다면, 시스템은 그냥 추측하지 않습니다. 레시피의 *설계도(구조)*를 살펴봅니다. 시스템은 다음과 같이 질문합니다: "서로 다른 여러 명의 셰프(전문가와 제너럴리스트)가 독립적으로 동일한 설계도를 만들어냈는가?" 만약 그렇다면, 그 설계도가 진정한 승자일 가능성이 높습니다.

결과
이 "전문가 + 제너럴리스트" 팀, "트리아지 간호사" 수리 시스템, 그리고 "스마트 판사"를 사용함으로써, SIRIX-SQL은 자신의 직무에서 최고의 성능을 보여주었습니다.

BIRD 테스트 (실제 세상의 지저분한 데이터를 다루는 어려운 테스트)에서 **75.88%**의 정확도를 기록하며 이전 최고 기록을 경신했습니다.
SPIDER 테스트 (표준 테스트)에서는 **91.20%**의 정확도를 기록했습니다.

요약하자면, SIRIUS-SQL은 단 한 명의 로봇이 16번 추측하는 것에 의존하는 것을 멈췄습니다. 대신, 서로 다른 전문가 팀을 활용하고, 오류를 정확히 진단하여 적절히 수정하며, 스마트한 다단계 투표 시스템을 사용하여 단 하나의 진정한 정답을 찾아냅니다.

기술 요약: SIRIUS-SQL

문제 정의

Text-to-SQL 시스템은 실제 데이터베이스의 복잡한 스키마를 다룰 때 어려움을 겪습니다. 스키마의 이질성, 암시적 제약 조건, 모호한 값 참조로 인해 단일 패스(single-pass) 생성은 실패하는 경우가 많습니다. 최근의 접근 방식들은 여러 개의 SQL 후보를 생성하고 투표를 통해 오류를 필터링함으로써 이를 완화하려 하지만, 본 논문은 기존의 멀티-후보 파이프라인에서 발생하는 세 가지 결합된 구조적 약점을 식별했습니다:

수익 체감형 샘플링 (L1): 단일 생성기에서 더 많은 후보를 샘플링하는 것은 생성기의 분포가 훈련에 의해 고정되어 있기 때문에 점점 더 중복된 출력만을 낳습니다. 단순히 샘플 예산( $k$ )을 늘리는 것만으로는 생성기가 선호하는 영역 밖의 새로운 정답 가설을 신뢰성 있게 찾아낼 수 없습니다.
실행 신호의 낭비 (L2): 기존 파이프라인은 모든 비정상 실행 결과에 대해 단일하고 일반적인 교정 전략을 적용합니다. 그러나 서로 다른 실패 모드—런타임 오류(구문/타입 불일치), 타임아웃(비효식적인 플랜), 빈 결과값(의미론적 표류)—는 정답과의 거리가 다르며 각각 별도의 복구 전략을 필요로 합니다.
투표-오라클 간극 (L3): 후보 풀 내에 정답 SQL이 존재하더라도 다수결 투표가 이를 선택하지 못하는 경우가 있습니다. 이는 선택 과정이 두 가지 공간에서의 공동 판단을 요구하기 때문입니다: 결과 공간(서로 다른 SQL이 동일한 출력을 낼 수 있는 곳)과 로직 공간(동일한 의도가 다양한 형태를 가질 수 있는 곳). 기존의 선택기들은 대개 이 중 한 가지 공간에서만 작동합니다.

방법론: SIRIUS-SQL

SIRIUS-SQL은 파이프라인의 모든 단계를 실행 피드백에 고정함으로써 이러한 한계점들을 해결합니다. 이 시스템은 세 가지 핵심 구성 요소로 이루어져 있습니다:

1. 소스 보완적 후보 구축 (Source-Complementary Candidate Construction)

수익 체감을 극복하기 위해, 시스템은 두 가지 상호 보완적인 소스로부터 초기 후보 풀을 구축합니다:

전문가 ( $G_{sp}$ ): **검증 가능한 실행 보상 기반 강화 학습(RLVR)**으로 훈련된 태스크 특화 모델(SIRIUS-32B)입니다. 이 모델의 훈련에는 정책이 개선될 수 있는 인스턴스에 집중하는 난이도 평활화 데이터 합성(difficulty-smoothed data synthesis) 전략과, 엔트로피 붕괴를 방지하면서도 다양하고 실행 가능한 후보를 유지하기 위한 임계값 게이트 엔트로피 정규화가 적용된 2단계 DAPO 스케줄이 사용됩니다.
일반인 ( $G_{ge}$ ): 전문가가 놓칠 수 있는 롱테일 구문이나 암시적 제약 조건을 커버하기 위해 퓨샷(few-shot) 데모로 프롬프팅된 범용 강력 LLM(예: Qwen3-235B, Gemini-3.1)입니다.
이 두 소스의 결합은 후보들이 서로 다른 실패 모드를 노출하도록 보장하여 오류 상관관계를 줄입니다.

2. 실행 기반 후보 라이프사이클 (Execution-Grounded Candidate Lifecycle)

실행을 단순한 최종 이진 체크로 취급하는 대신, 시스템은 실행 결과를 동적인 복구 루프를 구동하는 데 사용합니다 (L2):

실행 전 스크리닝: 실행 예산을 절약하기 위해 결정론적인 규칙 기반 필터를 사용하여 잘못된 형식의 SQL(예: 구문 오류, 스키마 불일치)을 사전에 제거합니다.
진단 및 타이핑: 살아남은 후보들은 실행된 후 네 가지 카테고리로 분류됩니다: clean(정상), runtime error(런타임 오류), timeout(타임아웃), empty result(빈 결과).
타입별 복구:
- 런타임 오류: 엔진의 예외 텍스트가 교정기에 그대로 전달됩니다.
- 타임아웃: 의도는 유지하되 효율성을 높이기 위해 조인 순서나 서브쿼리 형태를 재구성합니다.
- 빈 결과값: 2단계 접근법이 사용됩니다. 먼저, 고정밀 구조적 연산자(예: 리터럴 재바인딩, 술어 조정)를 통해 국소적 복구를 시도합니다. 이것이 실패할 경우, 진단 조건부 LLM 폴백(fallback)이 트리거됩니다.
풀 통합: 복구된 후보들은 재실행되어 풀에 다시 합류합니다. 만약 풀이 붕괴될 경우, 응축된 부정적 피드백을 사용하여 후보를 재생성하는 복구 생성기가 사용됩니다.

3. 신뢰도 게이트 하이브리드 선택 (Confidence-Gated Hybrid Selection)

투표-오라클 간극을 메우기 위해, 시스템은 결과 수준과 로직 수준의 신호를 결합한 2단계 선택기를 채택합니다:

1단계 (결과 수준 스코어러): 다음 항목들을 합산하여 거친 점수( $S_{coarse}$ $S_{co a r se}$ )를 계산합니다:
- 튜플 수준 합의 ( $S_{maj}$ ): 후보 집합 전체에 걸친 셀 단위 트리플(triple)의 빈도.
- 위치 편향이 제거된 쌍별 선호도 ( $S_{rm}$ ): LLM 판별기가 결과 시그니처 동등 클래스의 대표들을 비교하여 로직 품질을 순위 매깁니다.
2단계 (구조적 지원 재순위 지정): 신뢰도 게이트 메커니즘입니다. 모든 신호에서 상위 후보들이 동률일 경우(낮은 마진), 결정론적이고 LLM이 필요 없는 재순위 지정기가 개입합니다. 이 단계는 AST 수준의 구조적 시그니처(테이블, 프로젝션, 집계)를 분석하고, 가장 많은 별개의 프로비넌스 그룹(교차 생성기 합의)에 의해 지지되는 후보를 선택합니다. 이는 비용이 들지 않는 타이브레이커(tie-breaker) 역할을 합니다.

주요 기여

난이도 평활화 RL 레시피: 넓으면서도 보상으로 검증된 후보 분포를 생성하여 샘플링에서의 수익 체감을 효과적으로 완화하는 SIRIUS-32B를 위한 훈련 방법론입니다.
실행 기반 라이프사이클: 실행 결과를 분류하고, 특정 오류 유형(런타임, 타임아웃, 빈 결과)에 따른 타겟팅된 복구를 적용하여 후보를 재합류시키는 복구 프레임워크로, 실행 신호의 효용을 극대화합니다.
신뢰도 게이트 하이브리드 선택기: 튜플 수준의 합의와 쌍별 SQL 선호도를 융합하고, 모호한 경우에만 결정론적 구조 체크로 격상시켜 과도한 계산 비용 없이 투표-오라클 간극을 해결하는 선택 메커즘입니다.

결과

SIRIUS-SQL은 표준 벤치마크에서 최첨단 성능을 달달성했습니다:

BIRD Dev: 75.88% 실행 정확도(SIRIUS-32B + Gemini-3.1 Pro 사용)를 기록하여, 가장 강력한 기존 멀티-후보 시스템인 Agentar-Scale-SQL(74.90%)을 0.98%p 차이로 앞질렀습니다. 또한 단일 패스 베이스라인(예: Qwen3-Coder) 대비 상당한 이득(+11.54%)을 보여주었습니다.
SPIDER Test: 91.20% 실행 정확도를 달성하여, 태스크별 재조정 없이도 강력한 일반화 능력을 입증했습니다.
절제 연구 (Ablation Studies):
- 난이도 평활화 데이터 합성이 훈련 중 BIRD에서 1.8pp, SPIDER에서 0.5pp의 검증 보상을 개선했습니다.
- 상호 보완적 후보 구축(Specialist + Generalist)이 단일 소스 스케일링보다 우수한 성능을 보여, 단순한 샘플 수 증가보다 다양한 실패 모드가 더 가치 있음을 증명했습니다.
- 타입별 라이프사이클이 통합 교정 전략보다 0.13~0.71pp 더 높은 성능을 보였습니다.
- 하이브리드 선택기(병합 + 게이트)는 주로 낮은 마진의 동률 상황을 해결함으로써 단일 신호 선택기보다 0.20pp의 이득을 제공했습니다.

의의

본 논문은 멀티-후보 Text-to-SQL의 주요 병목 현상이 더 많은 후보를 생성하는 것이 아니라, 훈련, 복구, 선택 과정 전반에서 실행 신호를 체계적으로 활용하지 못하는 데 있다고 주장합니다. 훈련 단계에서 다양한 실행 가능 후보를 생성하도록 전문가를 훈련시키고, 특정 오류 유형에 따라 실패를 복구하며, 결과 합의와 구조적 로직의 하이브리드로 선택함으로써 실행에 기반한 정교화를 수행하는 SIRIUS-SQL은, 실행 피드백에 기반한 정교화가 복잡한 스키마에 대한 신뢰성을 향상시키는 데 결정적인 레버임을 입증합니다. 세 가지 일반인 페어링 모두에서 강력한 베이스라인을 능가하는 시스템의 능력은, 고도의 신뢰성이 요구되는 Text-to-SQL 애플리케이션을 위한 견고하고 파트너 불가지론적인(partner-agnostic) 아키텍처를 제시합니다.