🤖 machine learning

SQLConductor: Search-to-Policy Learning for Step-wise Text-to-SQL Orchestration

이 논문은 SQLConductor를 소개하는데, 이는 중간 피드백을 바탕으로 SQL 하위 작업(subtask)을 동적으로 선택하도록 정책 모델을 학습시키기 위해 탐색-정책 학습(Search-to-Policy Learning)을 채택한 단계별 오케스트레이션 프레임워크로서, 이를 통해 고정된 파이프라인 및 직접적인 백본 학습과 비교하여 복잡한 Text-to-SQL 벤치마크에서 우수한 실행 정확도와 일반화 성능을 달성한다.

원저자: Yizhang Zhu, Zhangyang Peng, Boyan Li, Yuyu Luo

게시일 2026-06-23

📖 3 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Yizhang Zhu, Zhangyang Peng, Boyan Li, Yuyu Luo

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

당신이 거대하고 복잡한 정보의 창고(데이터베이스)에서 일상적인 영어로 질문을 던져 매우 구체적인 답을 얻으려고 노력하고 있다고 상상해 보십시오. 이것이 바로 "Text-to-SQL" 문제입니다. 즉, 인간의 질문을 컴퓨터가 이해할 수 있는 컴퓨터 명령어(SQL)로 바꾸는 과정입니다.

오랫동안 컴퓨터는 이 문제를 해결하기 위해 엄격하게 미리 작성된 레시피를 따르는 방식을 사용해 왔습니다. 어떤 질문을 하더라도 컴퓨터는 반드시 동일한 단계들을 거쳐야 했습니다: 1단계, 2단계, 3단계, 4단계. 만약 당신이 "프랑스의 수도는 어디인가요?"와 같은 간단한 질문을 하더라도, 컴퓨터는 여전히 네 단계를 모두 거쳐야 했기에 시간을 낭비했고 때로는 혼란에 빠지기도 했습니다. 만약 어려운 질문을 던졌는데 컴퓨터가 2단계에서 실수를 했다면, 컴퓨터는 그 실수를 안고 계속 앞으로 나아가 결국 틀린 답을 내놓게 되었습니다.

SQLConductor는 판도를 바꾸는 새로운 시스템입니다. 고정된 레시피를 따르는 대신, 이 시스템은 현재 일어나고 있는 상황에 따라 다음 움직임을 결정하는 스마트한 프로젝트 매니저나 **지휘자(Conductor)**처럼 행동합니다.

작동 원리는 다음과 같습니다 (쉬운 비유를 사용합니다):

1. 도구 상자 (액션 공간/Action Space)

컴퓨터가 다양한 특화 도구들이 담긴 도구 상자를 가지고 있다고 상상해 보십시오:

브레이커 (The Breaker): 큰 질문을 작은 부분들로 쪼갭니다.
파인더 (The Finder): 데이터베이스에서 특정 숫자나 이름을 찾아냅니다.
필터 (The Filter): 관련 없는 정보를 잘라냅니다.
라이터 (The Writer): 실제 컴퓨터 명령어를 작성합니다.
에디터 (The Editor): 명령어의 실수를 수정합니다.
피니셔 (The Finisher): "다 끝났습니다, 여기 답이 있습니다"라고 말합니다.

기존 시스템은 컴퓨터가 정해진 순서(예: 브레이커 $\to$ 파인더 $\to$ 라이터 $\to$ 피니셔)로 도구를 선택하도록 강제했습니다. 하지만 SQLConductor는 "지휘자"가 지금 당장 필요한 도구가 무엇인지 결정하여 선택하게 해줍니다. 만약 파인더가 더 많은 정보가 필요하다고 판단하면, 지휘자는 다시 브레이커를 호출할 수 있습니다. 만약 라이터가 실수를 하면, 지치자마자 즉시 에디터를 호출할 수 있습니다.

2. 훈련 캠프 (탐색-정책 학습/Search-to-Policy Learning)

지휘자는 어떻게 이러한 스마트한 결정을 내리는 법을 배울까요? 단순히 매뉴얼을 읽는 것이 아니라, **탐색-정책 학습(Search-to-Policy Learning)**이라는 혹독한 훈련 캠프를 거칩니다.

시뮬레이션 (MCTS): 체스 선수가 컴퓨터를 상대로 연습하는 장면을 상상해 보십시오. 컴퓨터는 어떤 경로(워크플로우)가 승리로 이어지는지 확인하기 위해 수천 가지의 서로 다른 게임 경로를 시도합니다. SQLConductor 역시 마찬가지입니다. 질문을 해결하기 위해 수백만 가지의 서로 다른 방법과 도구의 조합을 시뮬레이션하며 시도합니다.
안정성 체크 (The Stability Check): 어떤 경로가 한 번 성공했다고 해서 그것이 좋은 전략인 것은 아닙니다. 운이 좋았을 수도 있기 때문입니다. 시스템은 어떤 경로가 일관되게 작동하는지를 살펴봅니다. 이는 마치 코치가 "운 좋게 한 번 이겼던 그 방식 하나만 따라 하지 말고, 10번 중 9번을 이기는 전략을 배워라"라고 말하는 것과 같습니다.
"커리큘럼" (더 어려운 문제들): 지휘자가 쉬운 문제에 익숙해지면, 훈련 캠프는 더 어렵고 까다로운 질문들을 던집니다. 시스템은 자신이 주로 실패하는 어려운 사례들을 처리하는 방법을 집중적으로 학습합니다.

3. 결과: 유연하고 효율적인 일꾼

학습을 마친 SQLConductor는 실제 질문을 해결하기 위해 투입됩니다.

적응성 (Adaptability): 단순한 질문을 던지면, 지휘자는 "에디터나 브레이커는 필요 없어. 라이터와 피니셔만 쓰면 돼"라고 결정합니다. 이를 통해 시간을 절약합니다. 복잡한 질문을 던지면, 지휘자는 다시 루프를 돌며 증거를 수집하고 답을 정교하게 다듬는 법을 압니다.
효율성 (Efficiency): 실제로 필요한 도구만을 사용하기 때문에, 모든 질문을 긴 고정 파이프라인에 통과시켜야 하는 기존 시스템보다 컴퓨팅 자원을 적게 사용하며 비용도 저렴합니다.
정확도 (Accuracy): 테스트에서 이 시스템은 질문이 매우 어렵거나 데이터베이스가 지저분한 경우에도 이전 방식들보다 더 자주 정답을 맞혔습니다.

핵심 요약

기존의 Text-to-SQL 시스템을 공장의 컨베이어 벨트라고 생각하십시오. 물건이 필요하든 아니든 모든 품목이 똑같은 기계들을 통과해야 합니다. 만약 벨트 위의 부품 하나가 고장 나면, 전체 라인이 계속 돌아가며 불량품을 만들어내게 됩니다.

SQLConductor는 작업실에 있는 숙련된 장인과 같습니다. 그들은 물건(질문)을 보고, 어떤 도구를 잡을지 결정하며, 한 단계를 실행한 뒤 결과를 확인하고, 그다음에 무엇을 할지 결정합니다. 만약 실수를 하면 즉시 수정합니다. 일이 간단하면 빠르게 끝내고, 복잡하면 제대로 해내기 위해 시간을 들입니다.

이 논문은 컴퓨터에게 경직된 기계가 아닌 이렇게 숙련된 장인처럼 행동하도록 가르침으로써, 데이터베이스 질문을 더 정확하고, 효율적이며, 다양한 유형의 문제에 더 잘 적응하여 해결할 수 있다고 주장합니다.

기술 요약: SQLConductor

1. 문제 정의

실제 환경의 Text-to-SQL은 복잡하고 이질적인 데이터베이스 환경에 대한 조율된 추론(coordinated reasoning)의 필요성 때문에 여전히 도전적인 과제로 남아 있습니다. 기존 시스템은 일반적으로 다음 두 가지 범주로 나뉘며, 두 방식 모두 적응성 측면에서 한계를 보입니다:

고정된 파이프라인 (Fixed Pipelines): 정해진 경직된 단계 순서(예: 스키마 연결 $\to$ 값 추출 $\to$ 생성 $\to$ 수정)에 의존합니다. 구조화되어 있기는 하지만, 중간 피드백이나 실행 오류를 바탕으로 이전의 결정을 재고할 수 없으므로 오류 전파가 발생합니다.
계획 후 실행 오케스트레이션 (Plan-then-Execute Orchestration): 실행 전에 완전한 워크플로우 계획을 생성하는 방식입니다. 고정된 파이프라인보다는 유연하지만, 일단 실행이 시작되면 정적인 시퀀스에 고착되어, 해결 과정 중 발생하는 중간 산출물이나 실행 피드백에 적응하지 못합니다.

핵심 과제는 인간이 설계한 워크플로우 데이터에 의존하거나 추론 시 과도한 온라인 탐색 비용을 발생시키지 않으면서, 현재의 해결 컨텍스트와 중간 증거를 기반으로 다음 행동을 동적으로 선택할 수 있는 **단계별 오케스트레이션 정책(step-wise orchestration policy)**을 학습하는 것입니다.

2. 방법론: SQLConductor

SQLConductor는 프로세스 조직(오케스트레이션)과 하위 작업 실행(추론)을 분리하는 단계별 오케스트레이션 학습 프레임워크입니다. 이는 광범위한 오프라인 워크플로우 탐색을 효율적인 추론을 위한 배포 가능한 정책으로 변환하는 탐색-정책 학습(Search-to-Policy Learning) 패러다임을 채택합니다.

2.1 액션 공간 (Action Space)

시스템은 고정된 대규모 언어 모델(LLM)에 의해 호출되는 7개의 특화된 모듈로 구성된 모듈형 액션 공간 $\mathcal{A}$ 를 정의합니다:

질문 분해 ( $a_{dec}$ ): 복잡한 질문을 세밀한 요구사항으로 재작성합니다.
관련 값 추출 ( $a_{val}$ ): SQL 술어(predicate)를 위한 조건 값을 식별합니다.
연산 식별 ( $a_{op}$ ): 필요한 SQL 연산(예: 집계, 정렬)을 기록합니다.
스키마 프루닝 ( $a_{sch}$ ): 관련 테이블과 컬럼을 선택합니다.
SQL 쿼리 생성 ( $a_{gen}$ ): SQL 후보를 합성합니다.
SQL 쿼리 정제 ( $a_{ref}$ ): 구문 또는 실행 오류를 수정합니다.
종료 및 출력 ( $a_{term}$ ): 워크플로우를 종료하고 최종 SQL을 반환합니다.

2.2 탐색-정책 학습 (Search-to-Policy Learning)

학습 과정은 오프라인 단계와 온라인 배포 단계로 구성됩니다.

단계 1: 오프라인 탐색-정책 학습

MCTS 기반 워크플로우 탐색:
- 각 학습 인스턴스에 대해, SQLConductor는 액션 공간에 대해 몬테카를로 트리 탐색(MCTS)을 수행합니다.
- 노드는 오케스트레이션 상태를 나타내며, 엣지는 액션 선택을 나타냅니다.
- 탐색은 실행 일관성 보상(생성된 SQL이 여러 샘플에서 일관된 결과를 생성하는지 측정)에 의해 유도되어, 다양한 액션 조합과 깊이를 탐색합니다.
- 이를 통해 다양한 후보 궤적(trajectory) 집합 $\mathcal{X}(q, D)$ 를 생성합니다.
워크플로우 감독 큐레이션 (Workflow Supervision Curation):
- 스켈레톤 추출: 궤적들을 액션 시퀀스(워크플로우 스켈레톤)별로 그룹화합니다.
- 안정성 추정: 탐색 공간이 조합적이고 노이즈가 많기 때문에, SQLConductor는 라플라스의 승계 규칙(Laplace's rule of succession)을 사용하여 각 워크플로우의 안정성을 추정합니다: $\hat{p}_\tau = \frac{s_\tau + 1}{n_\tau + 2}$ (여기서 $s_\tau$ 는 성공적인 실행 횟수, $n_\tau$ 는 총 횟수).
- 선택: 가장 높은 안정성 점수를 가진 상위- $k$ 개의 워크플로우를 선택합니다. 각 그룹에서 하나의 성공적인 궤적을 대표값으로 샘플링합니다.
- 추론 증강: 배포된 LLM이 특정 액션이 현재 컨텍스트에서 왜 선택되었는지 설명하는 단계별 추론( $e_t$ )을 생성하여, 증강된 궤적 $\bar{\xi}$ 를 만듭니다.
안정성 가중치 지도 미세 조정 (Stability-weighted SFT):
- 정책 모델은 큐레이션된 증강 궤적을 바탕으로 학습됩니다.
- 마스킹: 손실 함수는 <results> 토큰(액션 출력)을 마스킹하여, 정책이 액션 출력을 예측하는 대신 오케스트레이션 결정에 집중하도록 합니다.
- 가중치 부여: 견고한 오케스트레이션 패턴을 우선시하면서 다양성을 유지하기 위해, 궤적에 안정성 점수( $\hat{p}_\tau$ )에 따른 가중치를 부여합니다.
커리큘럼 강화 학습 (Curriculum RL):
- 성공적인 궤적이 희소한 어려운 쿼리를 처리하기 위해, 시스템은 도전적인 인스턴스(낮은 MCTS 성공률)로 구성된 커리큘럼 세트를 구축합니다.
- 그룹 상대 정책 최적화(GRPO)를 사용하여, 정책은 이러한 어려운 케이스들에 대해 셀프 롤아웃(self-rollouts)을 수행합니다.
- 보상: 보상 함수는 실행 가능성(유효한 SQL)과 결과 품질(정답 대비 실행 F1 점수)을 결ло combine하여, 정책이 복잡한 케이스에 대한 복구 전략을 학습하도록 유도합니다.

단계 2: 온라인 배포

학습된 정책 모델은 고정된 액션 모듈들을 단계별로 조정합니다.
각 단계에서 정책은 추론을 생성하고, 현재 상태(축적된 증거 및 피드백)를 기반으로 다음 액션을 선택합니다.
워크플로우는 실행 중에 동적으로 구축되며, 쿼리의 특정 요구사항에 적응합니다.

3. 주요 기여

단계별 오케스트레이션 프레임워크: SQLConductor는 프로세스 조직과 하위 작업 실행을 분리하는 프레임워크를 도입하여, 고정된 파이프라인이나 계획 후 실행 방식과 달리 적응형 깊이와 모듈 조합을 가진 쿼리별 워크플로우를 가능하게 합니다.
탐색-정책 학습: 인간이 만든 워크플로우 데이터 없이도 적응형 오케스트레이션 정책을 학습하는 메커니즘을 제안합니다. MCTS를 통한 탐색, 안정성 추정을 통한 큐레이션, 그리고 안정성 가중치 SFT와 커리큘럼 RL의 결합을 활용합니다.
실증적 성능 및 일반화:
- BIRD-Dev: SQLConductor는 BIRD-Dev 벤치마크에서 **73.2%의 실행 정확도(EX)**를 달স্য하며, 유사하거나 더 큰 규모의 Text-to-SQL 백본을 직접 학습시킨 기존 방법들을 능가합니다.
- 매개변수 효율성: 이 모델은 고정된 더 큰 액션 모델(예: 32B)을 조정하기 위해 압축된 오케스트레이션 정책(예: 8B)만을 학습시킴으로써, 학습된 매개변수당 우수한 정확도를 달성합니다.
- 일반화: 데이터셋별 재학습 없이도 OOD(Out-of-Distribution) 데이터셋(Spider-Test, KaggleDBQA, ScienceBenchmark)에서 강력한 일반화 성능을 보여줍니다.
- 효율성: CHESS와 같은 베이스라인보다 높은 정확도를 유지하면서도 추론 시 토큰 사용량과 API 비용을 크게 절감합니다(약 8배 저렴).

4. 의의 및 주장

본 논문은 학습된 오케스트레이션이 단일 거대 Text-to-SQL 모델을 추가로 학습시키는 것보다 더 매개변수 효율적이고 효과적임을 주장합니다.

적응성 vs 브루트 포스 (Adaptivity vs. Brute Force): 결과는 성능 향상이 단순히 워크플로우 길이나 모델 크기를 늘리는 데서 오는 것이 아니라, 정책이 오케스트레이션 노력을 적응적으로 할당하는 능력에서 온다는 것을 입증합니다. 학습된 정책은 어려운 쿼리에는 더 많은 단계를 할당하고, 단순한 쿼리는 효율적으로 유지합니다.
견고성: 안정성 가중치 큐레이션은 정책이 우연한 성공이 아닌 견고한 패턴을 학습하도록 보장하며, 이를 통해 복잡하고 노이즈가 많으며 도메인 특화된 쿼리를 효과적으로 처리할 수 있게 합니다.
확장성: 오케스트레이션 정책을 액션 모듈과 분리함으로써, 전체 시스템을 재학습하지 않고도 더 크거나 특화된 액션 모델을 통합할 수 있는 확장 가능한 경로를 제공합니다.

요약하자면, SQLConductor는 중간 증거에 적응하는 동적인 단계별 오케스트레이션 정책을 학습함으로써 기존 Text-to-SQL 시스템의 경직성 문제를 해결하고, 훨씬 낮은 계산 비용으로 최첨단 성능을 달성합니다.