Li, Boyan, et al. "Alpha-sql: Zero-shot text-to-sql using monte carlo tree search." arXiv preprint arXiv:2502.17248 (2025).

Alpha-SQL: Zero-Shot Text-to-SQL using Monte Carlo Tree Search

Boyan Li ${ }^{1}$ Jiayi Zhang ${1}$ Ju Fan ${2}$ Yanwei Xu ${3}$ Chong Chen ${3}$ Nan Tang ${1}$ Yuyu Luo ${1}$

Abstract

Text-to-SQL은 자연어 기반의 데이터베이스 상호작용을 가능하게 하여 다양한 산업 분야에서 핵심적인 방법으로 활용되고 있다. 몇 달마다 새롭고 더욱 강력한 **Large Language Model (LLM)**이 등장하면서, fine-tuning은 엄청나게 비용이 많이 들고, 노동 집약적이며, 오류 발생 가능성이 높아졌다. 대안으로, task-specific fine-tuning 없이 LLM에 내재된 지식과 추론 능력을 활용하는 zero-shot Text-to-SQL은 유망하면서도 더 도전적인 방향을 제시한다.

이러한 도전을 해결하기 위해 우리는 Alpha-SQL을 제안한다. Alpha-SQL은 Monte Carlo Tree Search (MCTS) 프레임워크를 활용하여 부분적인 추론 상태(partial reasoning states)를 기반으로 SQL 구성 액션(SQL construction actions)을 반복적으로 추론하는 새로운 접근 방식이다. 프레임워크의 추론 능력을 향상시키기 위해, 우리는 LLM-as-Action-Model을 도입하여 MCTS 과정 중에 SQL 구성 액션을 동적으로 생성함으로써, 더 유망한 SQL 쿼리 방향으로 탐색을 유도한다. 또한, Alpha-SQL은 후보 SQL 쿼리의 품질을 평가하기 위해 self-supervised reward function을 사용하여 더 정확하고 효율적인 쿼리 생성을 보장한다.

실험 결과에 따르면, Alpha-SQL은 fine-tuning 없이 32B 오픈소스 LLM을 사용하여 BIRD 개발 세트에서 69.7%의 실행 정확도를 달성한다. Alpha-SQL은 GPT4o 기반의 이전 최고의 zero-shot 접근 방식보다 BIRD 개발 세트에서 2.5% 더 높은 성능을 보인다. 코드는 https://github.com/HKUSTDial/Alpha-SQL에서 확인할 수 있다.

1. Introduction

Text-to-SQL (NL2SQL이라고도 함)은 자연어 쿼리를 SQL로 변환하여 관계형 데이터베이스에 대한 접근을 단순화하고, 일반 사용자 및 전문가 모두가 효과적으로 인사이트를 얻을 수 있도록 돕는다 (Liu et al., 2024; Luo et al., 2018a;b; 2022b; 2021; 2022a; 2025; Liu et al., 2025b; Luo et al., 2023). **대규모 언어 모델(LLM)**의 발전과 함께, CHASE-SQL (Pourreza et al., 2025)과 같은 방법들은 BIRD (Li et al., 2023c)와 같은 벤치마크에서 경쟁력 있는 결과를 달성했다. 일반적으로 이러한 LLM 기반 Text-to-SQL 방법은 **학습 기반(trained methods)**과 **zero-shot 기반(zero-shot methods)**의 두 가지 범주로 나뉜다.

Text-to-SQL을 위한 LLM 학습. LLM을 task-specific 데이터셋으로 사전학습(pre-training)하거나 fine-tuning하는 것은 Text-to-SQL 성능을 향상시키는 일반적인 접근 방식이다 (Li et al., 2024b; Gao et al., 2024b; Talaei et al., 2024; Li et al., 2024a; Zhu et al., 2025). 이 방법은 효과적이지만, 방대한 양의 labeled 데이터셋과 모델 학습을 위한 상당한 계산 자원을 필요로 한다 (Lin et al., 2025). 더욱이, 새롭고 더 강력한 LLM이 등장함에 따라, 경쟁력 있는 성능을 유지하기 위해 학습 과정을 반복해야 하므로 비용과 노력이 더욱 증가한다 (Wu et al., 2025).

Text-to-SQL을 위한 Zero-Shot LLM. 대안으로, DAIL-SQL (Gao et al., 2024a) 및 C3 (Dong et al., 2023)와 같은 zero-shot Text-to-SQL 방법은 LLM에 인코딩된 일반 지식을 활용하여 task-specific fine-tuning 없이 SQL 쿼리를 생성한다. 이는 labeled 데이터셋과 계산 집약적인 학습에 대한 의존성을 제거한다. 이 접근 방식은 실용적이고 비용 효율적인 솔루션을 제공하지만, 근본적인 문제에 직면한다.

zero-shot Text-to-SQL의 핵심 과제는 사전학습된 LLM의 지식을 자연어 쿼리와 데이터베이스 스키마를 기반으로 하는 SQL 생성이라는 특정 task로 fine-tuning 없이 전이하고 일반화하는 데 어려움이 있다는 것이다. 이러한 한계로 인해 모델은 자연어 쿼리와 다양한 데이터베이스 스키마 간의 복잡한 매핑을 처리하기 어렵고, 스키마 관계를 정확하게 해석하고, 복잡한 SQL 쿼리를 구성하며, 다양한 컨텍스트에서 견고성을 유지하는 능력이 저해된다.

우리의 방법론 및 기여. 위에서 언급한 과제들을 해결하기 위해, 우리는 Alpha-SQL을 제안한다. Alpha-SQL은 zero-shot Text-to-SQL을 점진적인 SQL 구성 과정으로 가능하게 하는 새로운 접근 방식으로, 쿼리가 단계별로 점진적으로 구축된다. Alpha-SQL의 핵심 아이디어는 task를 더 작고 관리하기 쉬운 하위 task로 분해하고, 각 하위 task에 **맥락적 지침(contextual guidance)**을 제공하여 모델이 각 단계에서 복잡성을 더 쉽게 처리할 수 있도록 하는 것이다. 이를 달성하기 위해 우리는 점진적인 구성 과정을 트리 구조 공간에 대한 탐색 문제로 모델링한다. 여기서 노드는 부분적인 추론 상태를 나타내고, 엣지는 SQL 구성 동작(예: 테이블 선택 또는 SQL 절 수정)을 나타낸다. 루트에서 리프 노드로 엣지(동작)를 반복적으로 선택함으로써, Alpha-SQL은 유효한 SQL 쿼리를 점진적으로 구성한다.

Figure 1. Alpha-SQL: 소규모 오픈소스 LLM을 강화하는 플러그인 프레임워크. 우리의 방법은 fine-tuning 없이도 Qwen2.5의 성능을 다양한 모델 크기(7B-32B)에서 15%~20% 향상시키며, BIRD (Dev) 데이터셋에서 GPT-4o 기반 zero-shot Text-to-SQL SOTA (RSL-SQL)를 능가한다.

이 아이디어를 바탕으로, Alpha-SQL은 Monte Carlo Tree Search (MCTS) 프레임워크 (Coulom, 2006; Xie et al., 2024)를 활용하여 SQL 구성 동작을 동적으로 생성하고 탐색한다. MCTS 프레임워크 내에서 효율적이고 효과적인 탐색을 촉진하기 위해 우리는 다음과 같은 새로운 기술을 도입한다.

첫째, 탐색 과정에서 추론 능력을 향상시키기 위해 LLM-as-Action-Model을 제안한다. 이는 MCTS 프레임워크에서 LLM을 추론 동작 모델로 호출하여 각 동작이 수행된 후 단계별 추론(즉, Chain-of-Thought)을 생성한다. 이 추론은 부분 상태와 함께 각 노드에 저장되어 Alpha-SQL이 SQL 구성 과정 전반에 걸쳐 맥락을 유지하고 LLM의 사고 과정을 추적할 수 있도록 한다. 이는 각 SQL 구성 동작이 맥락을 인지하고 전체 추론 경로와 일치하도록 보장하여, 더 유망한 SQL 쿼리 방향으로 탐색을 안내할 수 있다.

둘째, MCTS 탐색 과정에서 정확하고 효율적인 쿼리 생성을 보장하기 위해 후보 SQL 쿼리의 품질을 평가하는 self-supervised reward function을 도입한다. 구체적으로, 각 추론 경로에 대해 Alpha-SQL은 **높은 온도 샘플링(high-temperature sampling)**을 사용하여 여러 후보 SQL 쿼리를 생성하고, 유효하지 않은 쿼리를 필터링한 다음, 샘플링된 쿼리의 실행 결과와 예측된 SQL의 실행 결과를 비교하여 self-consistency score를 계산한다. 이는 유망한 경로의 우선순위를 정하고 탐색 과정을 개선하는 데 도움이 된다. 마지막으로, Alpha-SQL은 모든 후보 SQL 쿼리의 self-consistency score를 계산하고 가장 높은 점수를 가진 SQL을 최종 출력으로 선택한다.

요약하자면, Alpha-SQL은 fine-tuning이 필요 없는 플러그 앤 플레이(plug-and-play) Text-to-SQL 프레임워크로, Text-to-SQL task를 위해 소규모 오픈소스 LLM을 강화한다. Figure 1에서 보듯이, Text-to-SQL 데이터셋에 대한 fine-tuning 없이도 기존 LLM을 통합하고 성능을 향상시킬 수 있다. 광범위한 실험 결과, Alpha-SQL은 BIRD 개발 세트에서 69.7%의 실행 정확도를 달성하여 기존 zero-shot 방법들을 크게 능가하는 강력한 성능을 보여준다. Ablation study는 우리의 추론 동작의 효과를 확인하며, MCTS 롤아웃(rollout) 횟수가 많아질수록 성능이 향상됨을 입증한다.

2. Related Work

Text-to-SQL. Natural Language to SQL (Text-to-SQL, 일명 NL2SQL) task는 자연어 질문을 SQL 쿼리로 변환하는 것을 포함한다. T5 (Raffel et al., 2020)와 같은 Pre-trained Language Model (PLM)의 등장은 이후 Text-to-SQL task의 성능을 향상시켰다 (Scholak et al., 2021; Li et al., 2023a;b; Gu et al., 2023). 최근에는 LLM의 발전이 Text-to-SQL 능력을 더욱 진보시켰다. 그러나 schema alignment, 복잡한 쿼리 생성 등의 문제로 인해 LLM을 직접 적용하는 것은 여전히 어렵다 (Liu et al., 2024). 이를 해결하기 위해 최근 연구들 (Pourreza et al., 2025; Talaei et al., 2024; Li et al., 2024a; Cao et al., 2024; Liu et al., 2025a; Fan et al., 2024)은 Text-to-SQL을 후보 SQL 생성, 개선, 선택과 같은 하위 task로 분해하는 방식을 탐구해왔다. 예를 들어, CHASESQL (Pourreza et al., 2025)은 다단계 파이프라인을 사용하여 SQL 후보를 생성하고 검증함으로써 직접 생성으로 인해 발생하는 오류를 완화한다.

이러한 방향을 기반으로, 우리는 동적 쿼리 생성을 위해 MCTS를 사용하는 점진적 SQL 구성 프레임워크인 Alpha-SQL을 제안한다. 정적 파이프라인이나 fine-tuning에 의존하는 이전 방법들과 달리, Alpha-SQL은 LLM을 action model로 활용하여 context-aware 방식으로 탐색을 안내하고, task-specific labeled data 없이도 효율적인 탐색과 향상된 정확도를 가능하게 한다.

Test-time Computation. 최근 test-time computation의 발전 (Snell et al., 2024; Liu et al., 2025a)은 모델 파라미터를 수정하지 않고도 LLM 성능을 크게 향상시켰다. 추론(inference) 중 계획(planning), 탐색(search), 검증(verification)과 같은 기술은 다양한 task에서 추론 능력을 강화했다 (Wei et al., 2022; Yao et al., 2023; Qiu et al., 2024; Hao et al., 2023; Zhang et al., 2025; Teng et al., 2025; Zhu et al., 2024; Zhang et al., 2024b). tree-based search (Yao et al., 2023) 및 Best-of-N sampling (Qiu et al., 2024)을 포함한 최근 방법들은 구조화된 탐색을 통해 추론을 더욱 최적화했다. 최근 연구에서는 LLM의 능력을 향상시키기 위해 MCTS 기반 추론도 탐구되었다 (Qi et al., 2024). 이러한 방법들은 일반적인 추론 task에서는 효과적이지만, schema 이해, 의미적으로 정확한 SQL 생성, 실행 피드백 기반 출력 개선과 같은 Text-to-SQL의 고유한 과제를 완전히 해결하지는 못한다.

Alpha-SQL은 zero-shot Text-to-SQL을 위해 설계된 search-based SQL 생성 프레임워크로 test-time computation 원칙을 기반으로 한다. 이전 연구와 달리, Alpha-SQL은 LLM 기반 추론을 MCTS 프로세스에 통합하여 점진적인 SQL 쿼리 구성을 수행하고, action space를 최적화하며 데이터베이스 피드백을 통합하여 정확도를 향상시킨다.

3. Alpha-SQL

3.1. Zero-shot Text-to-SQL

Text-to-SQL Task
관계형 데이터베이스를 $\mathcal{D}=(\mathcal{T}, \mathcal{C}, \mathcal{R})$로 표현하자. 여기서 $\mathcal{T}$는 테이블 집합, $\mathcal{C}$는 해당 테이블들의 컬럼 집합, $\mathcal{R}$은 테이블 간의 관계(예: primary key-foreign key 제약 조건)를 나타낸다. $\mathcal{Q}$는 $\mathcal{D}$에 대한 모든 잘 정의된 자연어 질문을, $\mathcal{Y}$는 $\mathcal{D}$에 대한 모든 유효한 SQL 쿼리를 나타낸다.

목표는 주어진 질문 $q \in \mathcal{Q}$에 대해, $f(q, \mathcal{D})$가 구문적으로나 의미적으로 올바른 SQL 쿼리 $y \in \mathcal{Y}$를 생성하는 매핑 함수 $f$를 찾는 것이다.

zero-shot 설정에서 핵심 과제는 task-specific labeled data 없이 매핑 함수 $f$를 구축하는 것이다. 이는 모델이 사전학습된 지식과 제공된 데이터베이스 스키마에만 의존하여, 이전에 본 적 없는 SQL 쿼리와 데이터베이스에 대해 일반화할 수 있어야 함을 의미한다.

Text-to-SQL을 탐색 문제로 공식화
우리는 Text-to-SQL task를 잠재적인 SQL 쿼리들의 방대한 공간에 대한 탐색 문제로 정의한다. 여기서 탐색 공간 $\mathcal{S}$는 주어진 데이터베이스 $\mathcal{D}$와 질문 $q$에 대한 모든 유효한 SQL 쿼리로 구성된다. 이 공간을 구조화하기 위해 $\mathcal{S}$를 트리 $\Psi=(V, E)$로 표현하며, 여기서:
(1) 노드 ($V$): 각 노드 $v \in V$는 쿼리 구성 과정의 특정 단계에서 부분적인 추론 상태를 나타낸다. Figure 2에서 보듯이, 루트 노드 $v_0$는 초기 빈 쿼리를 나타내며, 입력 질문 $q$와 데이터베이스 스키마 $\mathcal{D}$를 포함한다. 중간 노드는 컬럼 값 식별, 함수 선택, SQL 절 구성과 같은 점진적인 추론 단계를 저장한다. **리프 노드(leaf node) 또는 종료 노드(termination node) $v_t$**는 완전히 구성된 SQL 쿼리 또는 종료 액션이 적용된 상태를 나타낸다.
(2) 엣지 ($E$): 각 엣지 $e \in E$는 쿼리 구성 과정의 액션에 해당한다. 예를 들어, 테이블 선택, 조건 추가, 집계 함수 적용 등이 있다. 이러한 액션들은 탐색 트리에서 중간 쿼리 상태 간의 전환을 모델링한다.
(3) 루트에서 리프 노드까지의 경로 (후보 SQL): 루트 노드 $v_0$에서 리프 노드 $v_t$까지의 경로는 SQL 구성 액션들의 시퀀스에 해당하며, 이들이 결합될 때 완전한 SQL 쿼리 $y \in \mathcal{S}$를 형성한다. SQL 쿼리 $y$는 다음과 같이 표현될 수 있다: $y=v_{0} \oplus v_{1} \oplus \cdots \oplus v_{t}$, 여기서 $\oplus$는 경로를 따라 노드들이 나타내는 액션들의 연결 또는 조합을 의미한다.

Figure 2. Text-to-SQL에 대한 탐색 트리 공식화 예시.

우리의 목표는 주어진 자연어 질문 $q$와 데이터베이스 스키마 $\mathcal{D}$에 대해 정확한 SQL 쿼리를 구성하는 최적의 추론 경로를 탐색 트리에서 식별하는 것이다.

탐색 공간의 복잡성
Text-to-SQL 생성을 위한 탐색 공간 $\mathcal{S}$를 효율적으로 탐색하는 것은 조합론적 특성으로 인해 상당한 도전 과제이다. $\mathcal{S}$의 크기, 즉 $|\mathcal{S}|$는 데이터베이스 스키마 $\mathcal{D}$와 질문 $q$의 복잡성에 따라 기하급수적으로 증가한다. 예를 들어, 테이블, 컬럼, 가능한 join 조건, 중첩된 subquery의 수가 증가함에 따라 잠재적인 쿼리의 수는 기하급수적으로 늘어난다. 이로 인해 전체 탐색은 사실상 불가능하며, 따라서 이 방대한 공간을 효과적으로 탐색하고 올바른 SQL 쿼리를 식별하기 위해서는 효율적인 탐색 전략이 사용되어야 한다.

3.2. An Overview of Alpha-SQL

기하급수적으로 증가하는 탐색 공간 $\mathcal{S}$를 탐색하고, 자연어 질문 $q$로부터 고품질의 SQL 쿼리를 생성하는 문제를 해결하기 위해, 우리는 **Monte Carlo Tree Search (MCTS)**를 활용하는 새로운 프레임워크인 AlphaSQL을 제안한다.

LLM-as-Action-Model을 활용한 MCTS 기반 탐색
Section 3.1의 탐색 문제 정식화를 바탕으로, AlphaSQL은 MCTS를 사용하여 탐색 트리 $\Psi=(V, E)$를 구축하고 탐색한다. 입력 질문 $q$, 데이터베이스 $\mathcal{D}$, 그리고 LLM $M$이 주어지면, MCTS 프로세스는 $\Psi$를 반복적으로 구축한다. 루트 노드 $v_0 \in V$는 빈 SQL 쿼리로 초기 상태를 나타낸다. 엣지 $e \in E$는 액션 $a$를 나타내며, Figure 2에서 보여주듯이 LLM $M$을 호출하여 스키마 선택 또는 컬럼 값 식별과 같은 SQL 구성 액션을 선택한다. MCTS 프로세스는 탐색 중에 액션을 적용하기 위해 $M$을 반복적으로 호출하여 다양한 경로를 탐색한다. 각 노드 $v_i \in V$는 일련의 액션을 적용한 후의 부분적인 추론 상태를 나타낸다. 루트에서 종료(리프) 노드까지의 완전한 경로는 후보 SQL 쿼리에 해당하는 추론 궤적을 형성한다. MCTS 프로세스는 이러한 궤적을 여러 개 생성하여, 후보 SQL 쿼리 집합 $T = \{\tau_1, \tau_2, \ldots, \tau_n\}$을 형성한다. 따라서 AlphaSQL은 문제 정식화에서 정의된 방대한 탐색 공간 $\mathcal{S}$를 효율적으로 탐색할 수 있다.

Figure 3. AlphaSQL 개요.

Self-Supervised Rewards
보상 함수는 각 액션의 유용성을 평가하여 MCTS 프로세스에서 중요한 역할을 하며, 더 유망한 SQL 쿼리 방향으로 탐색을 안내한다. Outcome Reward Models (Zelikman et al., 2022) 및 Progress Reward Models (Uesato et al., 2022)와 같은 전통적인 방법은 학습을 위해 도메인별 레이블링된 데이터가 필요하여, 다양한 데이터셋에 걸쳐 일반화하기 어렵다 (Zhang et al., 2024a).

인간의 추론에서 영감을 받아, 우리는 자신의 답변에 확신을 가진 사람들은 여러 번 시도해도 일관되게 동일한 응답을 제공하는 경향이 있음을 관찰했다. 이는 해결책에 대한 높은 확신을 나타낸다. 반대로, 응답이 다양하게 나타날 때는 낮은 확신을 시사하며, 이는 불확실성과 낮은 신뢰도를 의미한다 (Qi et al., 2024). 이러한 근본적인 직관은 우리의 혁신적인 self-consistency 기반 보상 함수의 개념적 토대를 직접적으로 형성한다. 이 함수 내에서, 후보 SQL 쿼리의 인지된 확신 또는 정확성은 다양한 샘플링된 쿼리 집합에서 얻은 실행 결과와 비교했을 때의 일관성으로 정량적으로 결정된다. 보상은 다음과 같이 계산된다:

$$R(y, q, \mathcal{D})=\frac{1}{N} \sum_{i=1}^{N} \mathbb{1}\left[\operatorname{Execute}(y, \mathcal{D})=\operatorname{Execute}\left(y_{i}, \mathcal{D}\right)\right]$$

여기서 $y_i$는 샘플링된 SQL 쿼리이고, $N$은 샘플 수이다. 이 정식화는 일관되게 안정적인 실행 결과를 산출하는 SQL 쿼리를 강화하여, AlphaSQL이 주석된 데이터 없이도 신뢰할 수 있는 추론 궤적을 우선시할 수 있도록 한다.

4. The Design Details of Alpha-SQL

4.1. LLM-as-Action-Model

zero-shot Text-to-SQL에서 핵심적인 과제는 사전학습된 language model의 일반 지식을 SQL 생성이라는 특정 task로 이전하는 데 어려움이 있다는 점이다.

프레임워크의 추론 능력을 향상시키기 위해, 우리는 LLM-as-Action-Model을 제안한다. 이 모델은 LLM을 활용하여 문제의 현재 context에 기반하여 추론 action(즉, CoT Thoughts)을 동적으로 생성한다. Figure 3에서 보듯이, LLM-as-Action-Model은 질문, 데이터베이스 스키마, 그리고 현재 부분적인 추론 상태(이전 action 포함)에 기반하여 LLM이 적절한 action 출력을 생성하도록 지원하며, 이를 통해 모델이 단계별로 유효한 SQL 쿼리를 구축할 수 있게 한다.

정식으로, 추론 과정의 $i$번째 단계 $\left(v_{i}\right)$에서 MCTS는 action space에서 SQL 구성 action $a_{i}$를 선택한다 (action space는 나중에 정의된다). 추론 궤적 $v_{0} \oplus \cdots \oplus v_{i}$에 기반하여, LLM은 $a_{i}$를 실행하고 다음 상태 $v_{i+1}$을 생성하도록 prompt된다:

$$v_{i+1}=\operatorname{LLM}\left(q, \mathcal{D}, \operatorname{Actions}\left(v_{0}, \cdots, v_{i}\right), \operatorname{Prompt}\left(a_{i}\right)\right),$$

여기서 $\operatorname{Actions}(\cdot)$는 궤적의 모든 이전 추론 단계를 의미하며, $\operatorname{Prompt}(\cdot)$는 특정 action에 대한 prompt 지시를 나타낸다.

SQL 구성 추론 Action Space
action space는 LLM이 Text-to-SQL 문제를 분해하고 해결하기 위해 취할 수 있는 잠재적인 추론 단계의 집합을 정의한다. LLM-as-Action Model이 각 단계에서 가능한 action을 지정함으로써 SQL 쿼리의 점진적인 구성을 안내하는 것은 매우 중요하다. 이전 연구들 (Pourreza et al., 2025; Talaei et al., 2024; Gao et al., 2024b)은 제한된 action과 고정된 파이프라인을 사용하여, 모델이 잠재적인 솔루션의 전체 공간을 탐색하는 능력을 제한했다.

어떤 사람은 바로 답으로 넘어가는 반면, 어떤 사람은 먼저 질문을 명확히 하고 하위 task로 나누는 인간의 사고방식에서 영감을 받아, 우리는 기존 action과 함께 질문 재작성(question rewriting)과 같은 새로운 추론 action (Qi et al., 2024)을 도입한다. 총 7가지의 명확한 추론 action을 정의한다. 각 action에 대한 구체적인 prompt는 Appendix A.2에 설명되어 있다.

$A_{1}$ : Question Rephrasing. Text-to-SQL 시스템은 다양한 사용자 그룹의 질문 스타일과 모호성을 처리해야 한다 (Liu et al., 2024). NL-Rewriter (Ma et al., 2024)는 경험 기반 질문 재작성을 통해 이를 해결하지만, 학습 데이터가 없는 zero-shot 시나리오에서는 어려움을 겪는다. rStar (Qi et al., 2024)를 기반으로, 우리는 few-shot prompting을 사용하여 질문을 구조화된 (조건 목록, 질문) 형식으로 분해한다.

$A_{2}$ : Schema Selection. 데이터베이스는 종종 복잡한 스키마를 포함하지만, 개별 SQL 쿼리는 일반적으로 사용 가능한 요소의 작은 하위 집합만 사용한다. 이러한 불일치는 정확한 SQL 생성에 어려움을 초래한다 (Liu et al., 2024). 이전 연구들은 스키마 선택이 SQL 생성의 중요한 구성 요소임을 확립했다 (Cao et al., 2024; Pourreza et al., 2025; Talaei et al., 2024). (Talaei et al., 2024)를 따라, 우리는 Chain-of-Thought (CoT) prompting을 사용하여 각 사용자 질문에 대한 관련 스키마 하위 집합을 식별하고, 이는 후속 쿼리 생성을 안내한다.

$\underline{A_{3}}$ : Column Value Identification. Text-to-SQL 시스템은 사용자 질문에서 필터링 조건을 정확하게 식별해야 한다. 예를 들어, "Bob의 축구 경기 최고 순위는 무엇인가?"라는 질문은 이름("Bob")과 경기 유형("축구") 모두에 대한 필터링을 필요로 한다 (예: WHERE name = 'Bob' AND match_type = 'football'). CHESSSQL (Talaei et0 al., 2024)은 BIRD 개발 세트에서 오류의 20%가 잘못된 필터링 컬럼 또는 값 선택에서 비롯된다는 것을 발견했다. 이를 해결하기 위해, 우리는 SQL 생성 전에 잠재적인 필터링 값을 평가하는 컬럼 값 식별 action을 도입한다.

$A_{4}$ : Column Function Identification. 복잡한 SQL 쿼리는 종종 집계 함수 (예: COUNT) 및 스칼라 함수 (예: STRFTIME)를 필요로 한다. 예를 들어, "2024년에 태어난 사람은 몇 명인가?"라는 질문은 **날짜 조작 (STRFTIME('%Y', people.date_of_birth) = '2024')과 집계 (COUNT(people.id))**를 모두 필요로 한다. CHASESQL (Pourreza et al., 2025)의 분석에 따르면, BIRD 개발 세트에서 오류의 19%가 함수 관련 실수에서 비롯된다. 함수 처리 능력을 향상시키기 위해, 우리는 추론 중에 컬럼 함수 식별 action을 도입한다.

Table 1. Action Space와 순서.

$A_{5}$ : SQL Generation. SQL 생성은 Text-to-SQL 시스템의 핵심 구성 요소이다. CHASE-SQL (Pourreza et al., 2025)은 복잡한 쿼리를 여러 하위 task로 분해하고, 독립적으로 해결한 다음, 솔루션을 결합하는 Divide-and-Conquer CoT 전략을 도입했다. 이 방법은 특히 중첩 쿼리 처리에 탁월하다. 우리는 이 전략을 추론 action space에 통합한다.

$A_{6}$ : SQL Revision. LLM은 복잡한 시나리오에서 구문적으로 유효하지 않은 SQL 쿼리를 생성할 수 있다 (Wang et al., 2025; Pourreza et al., 2025). 인간의 디버깅 관행에서 영감을 받아, 우리는 실행 기반 수정 메커니즘을 구현한다. 우리의 접근 방식은 사용자 질문, 스키마, 잘못된 SQL, 그리고 실행 결과를 LLM에 제공하여 쿼리 수정을 안내한다. 시스템은 유효한 SQL 쿼리를 얻거나 최대 시도 횟수 $N_{\text {revision }}$에 도달할 때까지 여러 차례 수정을 수행한다.

$A_{7}$ : Termination. 종료 action은 추론 과정이 최종 예측 SQL을 생성하여 추론 궤적의 결론을 나타낼 때 호출된다. 우리는 종료 action이 SQL Generation 또는 SQL Revision action 다음에 발생해야 한다고 명시한다.

Action 순서 및 제약 조건
각 추론 궤적은 논리적 일관성을 보장하는 구조화된 순서를 따른다. 예를 들어, SQL Revision과 같은 일부 action은 SQL Generation 이후에만 발생해야 한다. Table 1은 action 간의 유효한 전환을 정의한다. 또한, 무한 루프의 가능성을 방지하고 추론 궤적의 전진을 보장하기 위해, 우리는 각 정의된 action이 단일 쿼리 구성 프로세스 내에서 한 번만 나타나도록 제한하는 제약 조건을 부과한다.

4.2. MCTS for Candidate SQL Generation

MCTS Rollout을 통한 Candidate SQL 생성. 우리는 여러 MCTS rollout을 통해 Candidate SQL을 생성한다.

구체적으로, 각 rollout은 네 가지의 뚜렷한 단계로 구성된다: Selection, Expansion, Simulation, Backpropagation. (1) Selection. 이 단계에서는 루트 노드($v_0$)에서부터 확장되지 않은 리프 노드(unexpanded leaf) 또는 종료 노드(termination node)까지 탐색하여 확장할 유망한 노드를 식별한다. 노드 선택 시 탐색(exploration)과 활용(exploitation)의 균형을 맞추기 위해 Upper Confidence Bound applied to Trees (UCT) (Kocsis & Szepesvári, 2006)를 사용한다: $UCT(v, a)=\frac{Q(v, a)}{N(v, a)}+c \sqrt{\frac{\ln N(v)}{N(v, a)}}$. 여기서 $N(v, a)$는 노드 $v$에서 액션 $a$로의 방문 횟수를 세고, $N(v)$는 노드 $v$의 총 방문 횟수를 추적한다. $Q(v, a)$는 노드 $v$에서 액션 $a$에 대한 예상 보상(reward)이며, backpropagation을 통해 업데이트된다. 우리는 가장 높은 UCT 점수를 가진 액션을 선택하고 결과 자식 노드로 이동한다. 특히, 방문하지 않은 자식 노드(즉, $N(v, a)=0$)가 존재하는 경우, UCT 선택보다 이러한 노드의 선택을 우선시한다. (2) Expansion. 확장 단계는 선택된 노드로부터 자식 노드를 생성한다. 유효한 액션은 노드 유형(Table 1)에 따라 결정되며, LLM prompting을 통해 실행된다. 각 액션은 temperature $T_{\text {expansion }}$으로 $N_{\text {expansion }}$번 샘플링되어 $N_{\text {expansion }} \times\left|E_{\text {valid }}\right|$개의 자식 노드를 생성한다. 여기서 $\left|E_{\text {valid }}\right|$는 유효한 액션의 수를 나타낸다. 이러한 샘플링 접근 방식은 추론 다양성(reasoning diversity)을 향상시킨다. (3) Simulation. 완전한 simulation 프로세스는 종료 노드에 도달할 때까지 반복적인 노드 선택 및 확장으로 구성된다. simulation 프로세스 전반에 걸쳐 새롭게 확장된 모든 자식 노드는 트리 구조 내에 영구적으로 유지된다. (4) Backpropagation. 종료 노드($v_t$)에서 backpropagation은 Section 3.2의 self-supervised reward function을 사용하여 예측된 SQL을 평가하는 것으로 시작된다. 최종 SQL을 생성한 액션($A_5$ 또는 $A_6$)을 식별한 다음, 다양성을 보장하기 위해 temperature $T_{\text {reward }}$로 $N_{\text {reward }}$개의 SQL 쿼리를 샘플링한다. 보상 값 $r$은 샘플링된 SQL과 예측된 SQL의 실행 결과 간의 self-consistency 점수로부터 계산된다. 그런 다음 프로세스는 $v_t$에서 루트 노드로 역추적하여, 경로 $v_0 \oplus \cdots \oplus v_t$를 따라 모든 노드의 $Q(v, a)$ 및 $N(v)$ 값을 다음을 사용하여 업데이트한다: $Q(v, a)=Q(v, a)+r, N(v)=N(v)+1$. 이러한 업데이트된 값은 후속 rollout에서 UCT 공식을 통해 미래 검색 방향을 안내한다.

$N_{\text {rollout }}$번의 rollout 후, 우리는 종료 노드에 도달하는 모든 완전한 궤적을 수집하여, 후보 SQL 추론 궤적 집합 $T=\left\{\tau_{1}, \tau_{2}, \ldots, \tau_{n}\right\}$을 형성한다.

최종 SQL 선택. $T$에서 최적의 궤적과 SQL 쿼리를 선택하기 위해, 우리는 Text-to-SQL의 수렴적 특성을 활용한다: 즉, 주어진 질문에 대해 다른 추론 경로가 동일한 SQL 쿼리를 생성할 수 있다. 우리는 예측된 모든 SQL 쿼리를 실행하고, 가장 높은 실행 결과 일관성(execution result consistency)을 가진 쿼리를 최종 예측으로 선택한다. 이 접근 방식은 Gemini-1.5-Flash와 같은 fine-tuned proprietary 모델에 의존하는 CHASE-SQL (Pourreza et al., 2025)과 같은 이전 방법과 다르며, CHASE-SQL은 광범위한 도메인별 데이터를 필요로 한다.

Alpha-SQL의 pseudo-code는 Appendix A.1에 제시되어 있다. 가지치기 전략 (Pruning Strategies). Alpha-SQL은 유효하지 않은 경로를 조기에 가지치기하기 위해 스키마 제약 조건(schema constraints)과 의미론적 규칙(semantic rules)을 검색 프로세스에 통합한다. 우리의 가지치기 전략의 핵심 측면은 중복 노드의 제거이다. 예를 들어, Schema Selection 액션을 수행할 때 LLM $M$을 여러 번(예: 3번) 샘플링할 수 있다. $M$에 의해 생성된 Chain-of-Thought 내용은 각 샘플마다 다를 수 있지만, 최종적으로 선택된 스키마 서브셋이 동일하다면, 우리는 세 개의 중복 노드 대신 하나의 자식 노드만 생성한다. 이러한 중복 제거는 정보 손실 없이 검색 트리의 분기 계수(branching factor)를 크게 줄인다.

4.3. Database Value Retrieval

사용자의 자연어 질문과 관련된 데이터베이스 값을 효율적이고 정확하게 검색하는 것은 Text-to-SQL 생성에 매우 중요하다 (Liu et al., 2024). SQL 쿼리는 일반적으로 잠재적으로 방대한 데이터베이스에서 추출된 제한된 수의 컬럼 값들을 참조하며, 주로 WHERE 절과 같은 필터링 조건 내에서 활용된다. 그러나 사용자가 쿼리를 표현하는 방식과 데이터베이스에 값이 저장되는 방식 사이에 발생할 수 있는 의미론적 불일치(semantic discrepancies) (예: 사용자는 "America"라고 말하지만 데이터베이스에는 "United States"로 저장될 수 있음)는 중요한 도전 과제로 작용한다. Talaei et al. (2024)에 따라, 우리는 **오프라인 전처리(offline pre-processing)**와 **온라인 검색(online retrieval)**을 포함하는 2단계 접근 방식을 사용한다.

오프라인 전처리 (Offline Pre-processing)
오프라인 단계에서는 온라인 단계에서 빠르고 정확한 검색을 용이하게 하기 위해 데이터베이스 값 전처리에 중점을 둔다. 이 과정은 특히 TEXT 타입 컬럼 값을 대상으로 하는데, 이 값들이 사용자 쿼리에서 모호성과 변형에 가장 취약하기 때문이다. 이렇게 선택된 텍스트 컬럼 값에 대해 우리는 MinHash (Datar et al., 2004) 기술을 적용하여 **압축된 시그니처(compact signatures)**를 생성한다. 이 MinHash 시그니처는 로컬에 저장되어, 모호성 해소(disambiguation)가 가장 필요할 가능성이 있는 데이터베이스 값들의 색인화되고 최적화된 표현을 생성한다.

온라인 검색 (Online Retrieval)
온라인 단계에서는 사용자가 자연어 질문을 제출할 때, 먼저 질문에서 관련 키워드를 추출한다. 이 과정은 few-shot prompt (Appendix A.3)를 통해 안내될 수 있다. 키워드가 식별되면, Locality Sensitive Hashing (LSH) (Datar et al., 2004)가 로컬에 저장된 사전 계산된 MinHash 시그니처와 함께 활용된다. 이 LSH 기반 검색은 추출된 키워드와 의미론적으로 유사한 데이터베이스 값을 효율적으로 검색할 수 있게 한다. 검색된 값들은 미리 정의된 편집 유사도(editing similarity) 및 의미론적 유사도(semantic similarity) 임계값($\epsilon_{\text {edit }}, \epsilon_{\text {semantic }}$)을 기반으로 추가 필터링된다. 의미론적 매칭에는 OpenAI의 text-embedding-3-large 모델이 사용된다. 최종적으로 선택된 관련 데이터베이스 값들은 LLM-as-Action-Model에 제공되는 데이터베이스 스키마 prompt에 통합되어, SQL 생성 프로세스를 위한 context를 풍부하게 한다.

5. Experiments

5.1. Experimental Setup

데이터셋 (Datasets)
우리는 평가를 위해 Spider (Yu et al., 2018)와 BIRD (Li et al., 2023c) 개발 세트를 활용한다. Spider는 1034개의 (NL, SQL) 쌍을 포함하며, BIRD는 1534개의 쌍을 포함한다. BIRD 쿼리는 더 복잡하며 CASE, IIF와 같은 domain-specific 키워드를 포함한다.
연산 비용을 줄이면서 더 많은 비교 실험을 용이하게 하기 위해 (Sections 5.3 ~ 5.5), 우리는 CHESSSQL (Talaei et al., 2024)을 따라 **BIRD 개발 세트의 각 데이터베이스에서 10%를 샘플링한 Subsampled Development Set (SDS)**을 활용한다. SDS는 147개의 샘플로 구성되며, 이 중 81개는 간단한 질문, 54개는 보통 질문, 12개는 어려운 질문이다.

평가 지표 (Metrics)
이전 연구 (Pourreza et al., 2025)에 따라, 우리는 **Execution Accuracy (EX)**를 지표로 사용한다. EX는 예측된 SQL 쿼리가 ground-truth 쿼리와 동일한 실행 결과를 생성하는 비율로 정의된다.

하드웨어 (Hardware)
모든 실험은 **512GB RAM과 듀얼 40코어 Intel(R) Xeon(R) Platinum 8383C CPU (@ 2.70GHz)**를 갖춘 Ubuntu 22.04.3 LTS 서버에서 실행된다. 오픈 소스 LLM은 각각 80GB 메모리와 BF16 정밀도에서 312 TFLOPS 성능을 가진 8개의 GPU를 사용하여 로컬에 배포된다.

5.2. Main Results on BIRD and Spider Datasets

설정 (Settings)
우리는 Alpha-SQL의 추론 모델로 Qwen2.5-Coder 계열의 오픈소스 모델인 7B, 14B, 32B 모델 (Yang et al., 2024)을 사용했다. 관련 하이퍼파라미터는 다음과 같이 설정되었다:

• 오프라인 데이터베이스 값 검색의 경우, 편집 유사도(editing similarity) $\epsilon_{\text {edit }}$는 0.3, 의미 유사도(semantic similarity) $\epsilon_{\text {semantic }}$는 0.6으로 설정했다.
• MCTS rollout 프로세스의 경우, rollout 횟수 $N_{\text {rollout }}$는 24로 설정했다.
• 노드 확장(node expansion) 시, 각 액션은 **샘플링 온도(sampling temperature) $T_{\text {expansion }}=0.8$**로 $N_{\text {expansion }}=3$번 샘플링되었다.
• self-supervised reward 계산 시, SQL 샘플링 파라미터는 $N_{\text {reward }}=5$번 반복하고 **온도 $T_{\text {reward }}=1.0$**으로 설정했다.
• **SQL Revision 액션($A_6$)**의 경우, 다중 라운드 수정 프로세스에 대한 최대 반복 제한 $N_{\text {revision }}$는 10으로 설정했다.

BIRD 데이터셋 성능 (Performance on BIRD Dataset)
Table 2에서 볼 수 있듯이, 우리는 Alpha-SQL과 현재 state-of-the-art 접근 방식들을 zero-shot 능력을 기준으로 분류하여 포괄적으로 비교했다.
Alpha-SQL은 상대적으로 경량 모델인 Qwen2.5-Coder-7B를 활용하여 **평균 정확도 66.8%**를 달성했으며, 이는 독점 모델인 GPT-4o에 의존하는 RSL-SQL (Cao et al., 2024)의 성능과 유사하다. 특히, 이 성능은 데이터 fine-tuning이 필요한 많은 방법들을 능가한다.
추론 모델을 32B 파라미터로 확장했을 때, Alpha-SQL은 zero-shot 시나리오에서 69.7%의 평균 정확도로 우수한 성능을 보였다. 심지어 domain 데이터 fine-tuning을 수행한 방법들과 비교했을 때도, Alpha-SQL의 성능은 독점 모델인 Gemini-1.5-Flash를 fine-tuning해야 하는 CHASE-SQL (Pourreza et al., 2025)과 알 수 없는 모델을 fine-tuning하는 XiYan-SQL (Gao et al., 2024b)에 의해서만 능가된다. 이러한 결과는 Alpha-SQL이 fine-tuning 없이도 경쟁력 있는 성능을 제공하는 plug-and-play 프레임워크임을 입증한다.

Figure 4. BIRD dev. 데이터셋에서 성능 대 모델 크기. GPT-4, GPT-4o, Gemini-1.5-pro의 경우, (Abacha et al., 2024)의 파라미터 설명을 참조하여 그래프를 그렸다.

Spider 데이터셋 성능 (Performance on Spider Dataset)
우리는 또한 Spider 개발 데이터셋에서 Alpha-SQL을 평가했다. Table 3에서 볼 수 있듯이, Qwen2.5-Coder-14B를 사용한 Alpha-SQL은 기존 방법들을 능가한다. 특히, Spider 데이터셋에 특화되어 fine-tuning된 SFT CodeS-15B (Li et al., 2024b)보다 2.1% 향상된 성능을 달성했다. 이는 Alpha-SQL이 데이터셋별 fine-tuning 없이도 강력한 일반화 성능을 달성할 수 있는 능력을 보여준다.

성능-규모 트레이드오프 분석 (Performance-Scale Trade-off Analysis)
더 작은 오픈소스 LLM의 성능 잠재력을 탐색하기 위해, 우리는 Alpha-SQL이 비용 효율성을 유지하면서 더 작은 모델의 잠재력을 최대한 발휘할 수 있음을 보여주기 위한 실험을 수행했다. Figure 4는 Alpha-SQL이 파레토 프론티어(Pareto frontier)에서 더 큰 모델들을 크게 능가하며, 7B 및 14B 버전과 같은 더 작은 모델들이 GPT-4o 기반 접근 방식을 포함한 훨씬 더 큰 모델들과 유사하거나 그 이상의 정확도를 달성할 수 있도록 한다는 것을 보여준다. 이는 우리 프레임워크가 다양한 모델 규모에서 Text-to-SQL 성능을 최적화할 수 있는 능력을 입증한다.

Table 2. BIRD 개발 데이터셋의 실행 정확도.

Table 3. Spider 개발 데이터셋의 실행 정확도.

Figure 5. 정확도 대 MCTS Rollouts.

5.3. Impact of MCTS Rollouts on Performance

MCTS가 대규모 탐색 공간을 탐색하는 효율성은 Alpha-SQL의 핵심 특징이다. Table 1을 기반으로 계산한 결과, 각 text-to-SQL task에 대해 3000개 이상의 가능한 추론 경로가 존재한다. 놀랍게도 Alpha-SQL은 단 24번의 MCTS rollout만으로 상당한 성능 향상을 달성했으며, 이는 Alpha-SQL이 훨씬 더 큰 탐색 공간을 효율적으로 탐색할 수 있음을 시사한다.

이러한 효율성을 추가적으로 조사하고 MCTS rollout 횟수가 성능에 미치는 영향을 이해하기 위해 심층 분석을 수행했다. 우리는 Qwen2.5-Coder-7B 모델을 사용하여 SDS 데이터셋에 대한 실험을 수행했으며, rollout 횟수($N_{\text{rollout}}$)를 제외한 모든 하이퍼파라미터를 Section 5.2와 동일하게 유지했다. 우리는 상한 정확도(upper bound accuracy)와 최종 정확도(final accuracy)를 모두 보고한다. CHASE-SQL (Pourreza et al., 2025)과 유사하게, 상한 정확도는 최종 SQL 선택 전에 후보 SQL 세트에 올바른 SQL 쿼리가 포함된 샘플의 비율을 나타낸다. 우리는 MCTS rollout 횟수와 상한 정확도 및 최종 정확도 지표 사이에 양의 상관관계가 있음을 관찰했다. 이는 Alpha-SQL이 더 많은 MCTS 탐색을 통해 Text-to-SQL task 성능을 향상시킬 수 있는 능력을 보여준다.

5.4. Comparison with Baseline LLMs

이 섹션에서는 SDS 데이터셋에 Text-to-SQL task를 직접 적용했을 때, 다양한 LLM들의 baseline 성능 특성을 평가한다. 이 LLM들은 두 가지 그룹으로 분류되었다: GPT-4o와 같은 일반 LLM과 DeepSeek-R1과 같이 추론 task에 특화된 LLM이다. 공정한 비교를 위해, 모든 baseline LLM들은 Appendix A.4에 자세히 설명된 표준화된 Text-to-SQL prompt를 사용하여 프롬프트되었다.

Table 4. SDS 데이터셋에서 Baseline LLM과의 비교.

Table 5. Action Space에 대한 Ablation Study.

Table 4에서 볼 수 있듯이, 7B 파라미터 모델을 활용하는 우리의 Alpha-SQL은 모든 baseline 모델의 성능을 능가한다. 특히, Alpha-SQL은 더 약한 모델을 사용했음에도 불구하고, 정교한 추론 최적화 모델인 Gemini-2.0-Flash-Thinking-Exp보다 뛰어난 성능을 보인다. 이는 Text-to-SQL task가 Alpha-SQL 프레임워크의 강점인 표적화된 추론 최적화를 필요로 함을 보여준다. 또한, Alpha-SQL의 플러그 앤 플레이(plug-and-play) 이점을 검증하기 위해, Phi-4 (Abdin et al., 2024) 및 Qwen2.5-Coder-7B를 추론 모델로 사용하여 추가 실험을 수행했다. 이들 LLM에 직접 프롬프트하는 것과 비교하여, Alpha-SQL은 Qwen2.5-Coder-7B에서 17.0%, Phi-4에서 **16.5%**의 상당한 정확도 향상을 달성했다. 이러한 결과는 Alpha-SQL의 다양한 추론 모델에 대한 일반화 가능성과 효과를 입증한다.

5.5. Ablation Study of Action Space

본 ablation study의 목적은 우리가 제안하는 Text-to-SQL reasoning action space와 LLM-as-Action-Model 접근 방식의 효과를 검증하는 것이다. 이를 위해 우리는 SDS 데이터셋에 대해 실험을 수행했으며, Section 5.2의 파라미터 설정을 유지하면서 원래 action space에서 개별 action들을 체계적으로 제거하였다. Table 5는 이러한 실험 결과를 보여준다.

Table 5는 원래 action space에서 어떤 action이라도 제거하면 성능에 부정적인 영향을 미친다는 것을 보여준다. 특히 SQL Revision action은 그 중요성이 두드러지는데, 이 action은 데이터베이스 상호작용을 활용하여 LLM에 피드백을 제공하고 SQL을 수정한다. 이는 Text-to-SQL task에서 데이터베이스 실행 피드백의 중요성을 강조한다.

6. Conclusion

본 논문에서는 SQL 생성을 **구조화된 탐색 문제(structured search problem)**로 정의하는 zero-shot Text-to-SQL 프레임워크인 Alpha-SQL을 제안한다. Alpha-SQL은 **Monte Carlo Tree Search (MCTS)**와 LLM-as-Action-Model을 결합하여, LLM을 fine-tuning하지 않고도 SQL 쿼리 공간을 효율적으로 탐색한다. 실험 결과, BIRD 개발 세트에서 69.7%의 경쟁력 있는 성능을 보여주었다. Ablation study를 통해 우리의 reasoning action의 효과를 검증했으며, MCTS rollouts 횟수가 증가할수록 성능이 향상됨을 확인했다.

Acknowledgements

본 논문은 중국 국가자연과학기금(NSF of China) (62402409, 62436010, 62441230), 광둥성 프로젝트 2023CX10X008, 광둥성 기초 및 응용 기초 연구 기금(Guangdong Basic and Applied Basic Research Foundation) (2023A1515110 545), 광저우 기초 및 응용 기초 연구 기금(Guangzhou Basic and Applied Basic Research Foundation) (2025A04J3935), 그리고 광저우-홍콩과학기술대학교(광저우) 공동 기금 프로그램(Guangzhou-HKUST(GZ) Joint Funding Program) (2025A03J3714)의 지원을 받았다.

Impact Statement

본 논문은 머신러닝 분야의 발전을 목표로 하는 연구를 제시한다. 우리의 연구에는 여러 잠재적인 사회적 영향이 있을 수 있으나, 본문에서 특별히 강조해야 할 내용은 없다고 판단한다.

A. Appendix

A.1. Alpha-SQL Algorithm

Algorithm 1에 설명된 Alpha-SQL 알고리즘은 Selection, Expansion, Simulation, Backpropagation의 여러 단계로 작동한다. 사용자 쿼리 $q$와 해당 데이터베이스 스키마 $\mathcal{D}$가 주어지면, 알고리즘은 초기 상태를 나타내는 루트 노드 $v_0$로 빈 검색 트리 $\Psi=(V, E)$를 초기화하는 것으로 시작한다 (3-4행). 그런 다음 프로세스는 $N_{\text{rollout}}$번의 MCTS rollout을 반복하며 (6행), 각 rollout은 검색 공간에서 높은 가치의 추론 경로를 탐색한다.

Selection 단계 (7-12행)에서는 루트 노드부터 시작하여, Alpha-SQL은 확장되지 않은 노드에 도달할 때까지 검색 트리를 재귀적으로 탐색한다. 다음 액션 $a$는 UCT(Upper Confidence Bound for Trees) 공식에 따라 선택되는데, 이 공식은 예상 보상과 액션의 방문 횟수를 모두 고려하여 탐색(exploration)과 활용(exploitation)의 균형을 맞춘다 (10행). 이 과정은 터미널 노드를 찾거나 노드의 모든 자식이 확장될 때까지 계속된다.

Expansion 단계 (13-23행)에서는 현재 노드의 유형에 따라 유효한 다음 액션 $A_{\text{valid}}$이 결정된다. 알고리즘은 LLM-as-Action-Model을 호출하여 각 액션을 실행함으로써 새로운 상태를 생성하고, 검색 트리에 새로운 자식 노드를 만든다 (15-21행). 이 확장 프로세스는 새로운 추론 경로를 도입하여 후속 rollout을 위한 검색 공간을 풍부하게 한다. Simulation 단계 (24-30행)는 탐색되지 않은 자식 노드를 무작위로 선택하고 해당 액션을 실행하여 rollout을 수행한다. 이 단계는 터미널 노드에 도달할 때까지 계속되며, 이 시점에서 최종 SQL 쿼리가 궤적(trajectory)에서 추출된다.

마지막으로, Backpropagation 단계 (32-40행)는 터미널 노드에서 루트까지의 경로를 따라 노드의 값을 업데이트한다. 보상은 여러 SQL 쿼리를 샘플링하고 실행 결과를 기반으로 self-consistency 점수를 계산하여 산출된다. 노드 $N(u)$와 $Q(u, a_u)$의 값은 미래 검색을 안내하기 위해 보상 $r$에 따라 업데이트된다.

rollout이 끝날 때, 알고리즘은 43행에 명시된 대로 검색 중에 생성된 후보 쿼리 세트에서 가장 높은 self-consistency를 가진 SQL 쿼리를 선택한다. 이 절차를 통해 Alpha-SQL은 SQL 쿼리의 검색 공간을 효율적으로 탐색하고, 탐색과 정확성의 균형을 맞추며, zero-shot Text-to-SQL task에 대한 확장 가능하고 fine-tuning이 필요 없는 솔루션을 제공한다.

Algorithm 1 Alpha-SQL: Monte Carlo Tree Search를 사용한 Zero-Shot Text-to-SQL
    입력: 질문 \(q\), 데이터베이스 스키마 \(D\), LLM \(M\), 롤아웃 횟수 \(N_{\text {rollout }}\)
    출력: SQL 쿼리 \(y\)
    빈 검색 트리 \(\Psi=(V, E)\)를 루트 노드 \(v_{0}\)로 초기화
    루트 노드 \(v_{0} \in V\)를 \((q, D)\)로 초기화
    \(T \leftarrow \emptyset\)
    for \(i=1\) to \(N_{\text {rollout }}\) do
        // Selection 단계
        \(v \leftarrow v_{0}\)
        while \(v\)가 터미널이 아니고 \(v\)가 완전히 확장된 경우 do
            \(a \leftarrow \operatorname{argmax}_{a \in A(v)}\{Q(v, a) / N(v, a)+c \sqrt{\ln N(v) / N(v, a)}\}\)
            \(v \leftarrow\) 액션 \(a\)에 의해 도달한 \(v\)의 자식
        end while
        // Expansion 단계
        if \(v\)가 터미널이 아닌 경우 then
            \(A_{\text {valid }} \leftarrow\) Table 1에서 GetValidActions \((v)\)
            for \(a \in A_{\text {valid }}\) do
                for \(j=1\) to \(N_{\text {expansion }}\) do
                    \(v_{\text {new }} \leftarrow \mathrm{M}\left(q, D, \operatorname{Actions}\left(v_{0}, \ldots, v\right), \operatorname{Prompt}(a)\right)\)
                    \(\Psi\)에 \(v_{\text {new }}\)를 \(v\)의 자식으로 추가
                end for
            end for
            \(v \leftarrow\) \(v\)의 무작위로 탐색되지 않은 자식
        end if
        // Simulation 단계
        while \(v\)가 터미널이 아닌 경우 do
            \(A_{\text {valid }} \leftarrow\) GetValidActions \((v)\)
            \(A_{\text {valid }}\)로 \(v\)를 확장하고 액션 \(a\)를 무작위로 선택
            \(v_{\text {new }} \leftarrow \mathrm{M}\left(q, D\right.\), Actions \(\left.\left(v_{0}, \ldots, v\right), \operatorname{Prompt}(a)\right)\)
            \(v \leftarrow v_{\text {next }}\)
        end while
        \(v\)에서 최종 SQL \(y\) 추출
        // Backpropagation 단계
        온도 \(T_{\text {reward }}\)로 \(N_{\text {reward }}\)개의 SQL 쿼리 \(\left\{y_{1}, \ldots, y_{N_{\text {reward }}}\right\}\) 샘플링
        \(r \leftarrow \frac{1}{N_{\text {reward }}} \sum_{i=1}^{N_{\text {reward }}} \mathbb{1}\left[\operatorname{Execute}(y, D)=\operatorname{Execute}\left(y_{i}, D\right)\right]\)
        \(\tau \leftarrow\) \(v_{0}\)에서 \(v\)까지의 경로
        for 각 노드 \(u\) in \(\tau\) do
            \(N(u) \leftarrow N(u)+1\)
            \(Q\left(u, a_{u}\right) \leftarrow Q\left(u, a_{u}\right)+r\) (여기서 \(a_{u}\)는 \(u\)에서 취한 액션)
            \(N\left(u, a_{u}\right) \leftarrow N\left(u, a_{u}\right)+1\)
        end for
        \(T \leftarrow T \cup\{\tau\}\)
    end for
    return \(\operatorname{argmax}_{y \in Y}\{\operatorname{Self-consistency}(y)\}\) (여기서 \(Y\)는 \(T\)의 고유 SQL)

A.2. Prompt Template for Actions

이 섹션에서는 Section 4.1에서 정의된 action에 대한 prompt template을 제공한다.

Rephrase Question Action Prompt

[Korean Translation] 당신은 질문의 맥락을 조건으로 분리하여 질문을 재구성하는 데 도움을 주는 AI 어시스턴트입니다. 재구성된 질문에서는 원래 질문의 정보를 완전히 표현해야 합니다.

예시 1: 원본 질문: 1945년에 개봉된 영화 제목을 알려주세요. 영화 인기도를 기준으로 내림차순으로 정렬해주세요. 힌트: released in the year 1945는 movie_release_year = 1945를 의미합니다. 재구성된 질문: 조건 목록이 주어졌을 때, 질문에 답해주세요. 조건 1: 영화는 1945년에 개봉되었습니다. 조건 2: 영화는 인기도를 기준으로 내림차순으로 정렬됩니다. 조건 3: 영화 제목을 반환합니다. 질문: 1945년에 개봉된 영화 제목은 무엇이며, 영화 인기도를 기준으로 내림차순으로 정렬된 결과는 무엇입니까?

예시 2: 원본 질문: Cindy Stewart가 남부 슈퍼스토어에서 주문한 사무용품 주문은 몇 건입니까? 힌트: office supply는 Category = 'Office Supplies'를 의미합니다. 재구성된 질문: 조건 목록이 주어졌을 때, 질문에 답해주세요. 조건 1: 주문은 Cindy Stewart가 했습니다. 조건 2: 주문은 사무용품이며, Category = 'Office Supplies'를 의미합니다. 조건 3: 주문 수를 반환합니다. 질문: Cindy Stewart가 남부 슈퍼스토어에서 주문한 사무용품 주문은 몇 건입니까?

예시 3: 원본 질문: 2018년 8월 12일 마이애미 공항에 일찍 착륙한 항공편 수를 알려주세요. 힌트: landed on은 DEST를 의미합니다; landed earlier는 ARR_DELAY $<0$를 의미합니다; Miami Airport는 DEST = 'MIA'를 의미합니다; on 2018/8/12는 FL_DATE = '2018/8/12'를 의미합니다; 재구성된 질문: 조건 목록이 주어졌을 때, 질문에 답해주세요. 조건 1: 항공편은 2018년 8월 12일 마이애미 공항에 착륙했습니다. 이는 DEST = 'MIA' 및 FL_DATE = '2018/8/12'를 의미합니다. 조건 2: 항공편은 일찍 착륙했습니다. 이는 ARR_DELAY $<0$를 의미합니다. 조건 3: 항공편 수를 반환합니다. 질문: 2018년 8월 12일 마이애미 공항에 일찍 착륙한 항공편 수는 몇 건입니까?

다음 질문에 답해주세요: 원본 질문: {QUESTION} 힌트: {HINT} 재구성된 질문:

Figure 6. 질문 재구성 액션 프롬프트.

Schema Selection Action Prompt

{
 "chain_of_thought_reasoning": "The user is asking to identify the columns necessary to answer a question based on a database schema and a hint. I need to carefully read the question and the hint, then examine the schema to find the tables and columns that directly relate to the question's requirements. The question asks for the names of all employees who are 'Sales Representative' or 'Sales Manager'. The hint explicitly points to the 'Title' column in the 'Employee' table for filtering by 'Sales Representative' and 'Sales Manager', and the 'FirstName' and 'LastName' columns in the 'Employee' table for retrieving the employee names. Therefore, the 'Employee' table and its 'FirstName', 'LastName', and 'Title' columns are essential.",
 "Employee": [
  "FirstName",
  "LastName",
  "Title"
 ]
}

Column Value Identification Action Prompt

데이터베이스 스키마 정보와 힌트를 바탕으로, 질문에 답하기 위해 'generalinfo' 테이블의 'food_type' = 'thai'와 'location' 테이블의 'street_name' = 'san pablo ave' 그리고 'generalinfo' 테이블의 'city' = 'albany'를 사용해야 한다.

Column Function Identification Action Prompt

당신은 질문에 답하는 데 필수적인 잠재적인 열 함수(SQL 쿼리에서 사용해야 하는 경우)를 식별하는 데 도움을 주는 AI 어시스턴트입니다. 다음은 예시입니다: 데이터베이스 스키마: CREATE TABLE businesses ( 'business_id' INTEGER NOT NULL, 'name' TEXT NOT NULL, -- 열 설명: 식당 이름 PRIMARY KEY ('business_id') ); CREATE TABLE inspections ( 'business_id' INTEGER NOT NULL, -- 열 설명: 사업체의 고유 ID 'score' INTEGER DEFAULT NULL, -- 열 설명: 검사 점수 'date' TEXT NOT NULL, -- 값 예시: '2014-01-24' FOREIGN KEY ('business_id') REFERENCES 'businesses' ('business_id') ); 질문: 2012년 5월에 조건부 통과한 사업체의 이름은 무엇인가요? 힌트: 사업체 이름은 dba_name을 참조합니다; 조건부 통과는 results = 'Pass w/ Conditions'를 참조합니다; 2012년 5월은 inspection_date like '2012-05%'를 참조합니다. 답변: 2012년 5월에 조건부 통과한 사업체이므로, 'inspections'.'date' 열을 필터링하기 위해 날짜 관련 함수를 고려해야 합니다. 해당 열이 TEXT 타입이므로, strftime('%Y-%m', 'inspections'.'date') = '2012-05'를 사용하여 날짜를 필터링할 수 있습니다.

---

이제 실제 질문에 답하고, 위 예시의 답변 스타일(두 문장으로 답변)을 따라야 합니다. 데이터베이스 스키마: CREATE TABLE businesses ( 'business_id' INTEGER NOT NULL, 'name' TEXT NOT NULL, PRIMARY KEY ('business_id') ); CREATE TABLE inspections ( 'business_id' INTEGER NOT NULL, 'score' INTEGER DEFAULT NULL, 'date' TEXT NOT NULL, FOREIGN KEY ('business_id') REFERENCES 'businesses' ('business_id') ); 질문: 2012년 5월에 조건부 통과한 사업체의 이름은 무엇인가요? 힌트: 사업체 이름은 dba_name을 참조합니다; 조건부 통과는 results = 'Pass w/ Conditions'를 참조합니다; 2012년 5월은 inspection_date like '2012-05%'를 참조합니다. 답변: 2012년 5월에 조건부 통과한 사업체이므로, 'inspections'.'date' 열을 필터링하기 위해 날짜 관련 함수를 고려해야 합니다. 해당 열이 TEXT 타입이므로, strftime('%Y-%m', 'inspections'.'date') = '2012-05'를 사용하여 날짜를 필터링할 수 있습니다.

Figure 9. Column Function Identification Action Prompt.

SQL Generation Action Prompt

{
 "chain_of_thought_reasoning": "새로운 task에 대해 소수의 annotated example만으로도 빠르게 적응할 수 있는 모델을 구축하는 것은 멀티모달 머신러닝 연구에서 여전히 해결되지 않은 도전 과제이다. 우리는 이러한 능력을 갖춘 Visual Language Model(VLM) 계열인 **Flamingo**를 소개한다. 우리는 다음과 같은 주요 아키텍처 혁신을 제안한다:\n(i) 강력한 사전학습된 vision-only 모델과 language-only 모델을 연결하는 구조,\n(ii) 시각 및 텍스트 데이터가 임의로 섞여 있는 시퀀스를 처리할 수 있는 구조,\n(iii) 이미지 또는 비디오를 입력으로 자연스럽게 수용할 수 있는 구조.\n\n이러한 유연성 덕분에 Flamingo 모델은 텍스트와 이미지가 임의로 섞여 있는 대규모 멀티모달 웹 코퍼스를 학습에 활용할 수 있으며, 이는 **in-context few-shot learning** 능력을 갖추는 데 핵심적인 요소이다.  \n우리는 다양한 이미지 및 비디오 task에 대한 Flamingo 모델의 빠른 적응 능력을 탐구하고 측정하며, 철저한 평가를 수행한다. 여기에는 다음과 같은 open-ended task가 포함된다:\n\n* **Visual Question Answering (VQA)**: 모델이 질문을 받고 그에 대한 답을 생성해야 하는 task,\n* **Captioning**: 장면이나 이벤트를 설명하는 능력을 평가하는 task.\n\n또한 다음과 같은 close-ended task도 포함된다:\n\n* **Multiple-choice VQA**: 여러 선택지 중 정답을 고르는 형식의 task.\n\n이 스펙트럼 어디에 위치한 task든지, 단일 Flamingo 모델은 **task-specific 예시를 prompt로 주는 것만으로 few-shot learning 방식으로 새로운 state-of-the-art 성능을 달성**할 수 있다. 많은 벤치마크에서 Flamingo는 수천 배 더 많은 task-specific 데이터로 fine-tuning된 모델보다 더 나은 성능을 보여준다。\n\n\n\n![](https://cdn.mathpix.com/cropped/2025_07_26_7c316185968e7585aacbg-02.jpg?height=2242&width=1403&top_left_y=180&top_left_x=361)\n\nFigure 1: Flamingo-80B로부터 얻은 입력과 출력의 선택된 예시. Flamingo는 **few-shot prompting**만으로 다양한 이미지/비디오 이해 task에 빠르게 적응할 수 있다 (상단). 또한 Flamingo는 **별도의 fine-tuning 없이도 multi-image visual dialogue**를 수행할 수 있는 능력을 갖추고 있다 (하단). 더 많은 예시는 Appendix C에 제시되어 있다.\n\n![](https://cdn.mathpix.com/cropped/2025_07_26_7c316185968e7585aacbg-03.jpg?height=475&width=1378&top_left_y=245&top_left_x=371)\n\nFigure 2: Flamingo 결과 개요.\n**왼쪽**: 우리의 가장 큰 모델인 Flamingo는 **fine-tuning 없이도** 우리가 다룬 16개의 task 중 6개에서 **state-of-the-art로 fine-tuned된 모델보다 더 뛰어난 성능**을 보인다. 또한, **few-shot 결과가 공개된 9개의 task에서는 Flamingo가 새로운 few-shot state-of-the-art 성능을 기록**한다. 참고로, 16번째 벤치마크인 **RareAct**는 비교할 수 있는 fine-tuned 결과가 없는 zero-shot 벤치마크이므로 생략하였다.\n**오른쪽**: Flamingo의 성능은 **모델 크기와 few-shot 예시의 개수가 많아질수록 향상**된다.",
 "sql_query": "```sql\nSELECT T1.Name, T1.Country, T1.City FROM singer AS T1 JOIN concert AS T2 ON T1.Singer_ID  =  T2.Singer_ID WHERE T2.Year  =  2014 GROUP BY T1.Singer_ID ORDER BY count(*) DESC LIMIT 1\n```"
}

SQL Revision Action Prompt

{
"chain_of_thought_reasoning": "The user wants to retrieve the name of the album that has the maximum number of tracks. I need to join the `album` and `track` tables on `albumid`. Then, I will group the results by album name and count the tracks for each album. Finally, I will order the results in descending order of track count and limit to 1 to get the album with the maximum tracks.",
"sql_query": "SELECT T1.Title FROM album AS T1 JOIN track AS T2 ON T1.AlbumId = T2.AlbumId GROUP BY T1.Title ORDER BY COUNT(T2.TrackId) DESC LIMIT 1"
}

A.3. Prompt Template for Question Keywords Extraction

이 섹션에서는 Section 4.3의 질문 키워드 추출을 위한 prompt template을 제공한다.

Question Keywords Extraction Prompt

목표: 주어진 질문과 힌트를 분석하여 **키워드, 핵심 구문(keyphrases), 그리고 고유 명사(named entities)**를 식별하고 추출한다. 이러한 요소들은 질문의 핵심 구성 요소와 제공된 지침을 이해하는 데 매우 중요하다. 이 과정은 제시된 질문과 관련된 검색 또는 쿼리를 구성하는 데 중요한 역할을 할 수 있는 핵심 용어와 구문을 인식하고 분리하는 것을 포함한다.

지침:

• 질문을 주의 깊게 읽기: 질문의 주요 초점과 구체적인 세부 사항을 이해한다. 고유 명사(예: 조직, 위치 등), 기술 용어, 그리고 질문의 중요한 측면을 요약하는 기타 구문을 찾는다.
• 힌트 분석: 힌트는 질문에 답하는 데 관련된 특정 요소에 주의를 기울이도록 설계되었다. 답변을 구성하는 데 추가적인 명확성이나 방향을 제공할 수 있는 키워드, 구문 또는 고유 명사를 추출한다.
• 핵심 구문 및 고유 명사 목록화: 질문과 힌트에서 찾은 내용을 단일 Python 리스트로 결합한다. 이 리스트에는 다음이 포함되어야 한다:
  • 키워드: 질문이나 힌트의 필수적인 측면을 포착하는 단일 단어.
  • 핵심 구문: 특정 개념, 위치, 조직 또는 기타 중요한 세부 사항을 나타내는 짧은 구문 또는 고유 명사.

질문과 힌트에서 사용된 원래의 구문이나 용어를 유지해야 한다.

Example 1:

질문: "2022년 Acme Corp의 미국 내 연간 수익은 얼마입니까?" 힌트: "2022 회계연도의 재무 보고서와 미국 시장 성과에 집중하세요." ["annual revenue", "Acme Corp", "United States", "2022", "financial reports", "U.S. market performance", "fiscal year"]

Example 2:

Question: "1988년 동계 올림픽과 하계 올림픽에서 가장 많은 참가자 수를 기록한 경기는 무엇인가? 두 경기 간의 참가자 수 차이를 구하시오." Hint: "가장 많은 참가자 수는 MAX(COUNT(person_id))를 참조한다; SUBTRACT(COUNT(person_id where games_name = '1988 Summer'), COUNT(person_id where games_name = '1988 Winter'))를 사용한다;" ["Winter Olympics", "Summer Olympics", "1988", "1988 Summer", "Summer", "1988 Winter", "Winter", "number of competitors", "difference", "MAX(COUNT(person_id))", "games_name", "person_id"]

Example 3:

질문: "Ian James Thorpe는 남자 200m 자유형 종목에 몇 번 출전했습니까?" 힌트: "남자 200m 자유형 종목은 event_name = 'Swimming Men's 200 metres Freestyle'을 의미합니다. 출전한 종목은 event_id를 의미합니다." ["Swimming Men's 200 metres Freestyle", "Ian James Thorpe", "Ian", "James", "Thorpe", "compete in", "event_name", "event_id"]

Task: 주어진 질문과 힌트를 바탕으로 모든 관련 키워드, 키프레이즈, 고유 명사를 식별하여 나열하십시오. 질문: {QUESTION} 힌트: {HINT} 식별된 용어와 구문을 통해 질문과 힌트의 본질을 포착하여 Python 리스트로 결과를 제공하십시오. 설명 없이 Python 리스트만 출력하십시오.

Figure 12. 질문 키워드 추출 프롬프트.

A.4. Prompt Template for Baseline LLMs

이 섹션에서는 Section 5.4에서 baseline LLM을 직접 호출하기 위한 prompt template을 제공한다.

Baseline Text-to-SQL Prompt

<think> The user wants me to act as an experienced database expert and generate a SQL query. I need to follow the provided output format: first a `<think>` block for my thinking process, and then a `</sql>` block for the final SQL query. I must use the provided table schemas, question, and hint to generate the SQL query. I also need to remember the specific translation rules: 1. Translate the main content into professional, natural-sounding Korean. 2. **Crucially, do not translate technical English terms.** Keep terms like 'Transformer', 'DETR', 'cross attention', 'encoder', 'decoder', etc., in their original English form. 3. **Ensure that figure links are preserved.** Do not omit any figure URLs or accompanying descriptions. 4. **Include references formatted as [1], but when encountering footnote markers like [^1], remove only the [^1] marker while keeping the adjacent explanation text intact.** 5. **Use the provided examples as a reference for tone, translation style, and formatting.** This includes matching whitespace, line breaks, and paragraph divisions exactly as shown. 6. **Do not create any new titles or headings; translate only the content you’ve been given.** 7. **Enhance readability by using bold formatting for important terms or key phrases, as in the examples.**

The current input is a template for a Text-to-SQL prompt, not an actual academic paper text. The request is to translate the description of the task itself, not to perform the Text-to-SQL task. So, I need to translate the following: "You are an experienced database expert. Now you need to generate a SQL query given the database information, a question and some additional information.

The database structure is defined by the following table schemas (comments after '-' provide additional column descriptions). Note that the "Value Examples" are actual values from the column. Some column might contain the values that are directly related to the question. Use it to help you justify which columns to use.

Given the table schema information description, the 'Question' and 'Hint', you need to generate a SQL query that answers the question. Please respond the final sql query in the end of response.

---

Table creation statements: {SCHEMA_CONTEXT}

---

Question: {QUESTION} Hint: {HINT}

---

Output Format: <think> Your thinking process. </think> <sql> The final SQL query. </sql>

Figure 13. Baseline Text-to-SQL Prompt."

I will translate this descriptive text into Korean, keeping the placeholders like {SCHEMA_CONTEXT}, {QUESTION}, {HINT} and the <think> / <sql> tags as they are, as they are part of the output format description. The phrase "Figure 13. Baseline Text-to-SQL Prompt." should also be translated and formatted correctly. </think> <sql> 당신은 숙련된 데이터베이스 전문가입니다. 이제 데이터베이스 정보, 질문 및 일부 추가 정보가 주어졌을 때 SQL 쿼리를 생성해야 합니다.

데이터베이스 구조는 다음 테이블 스키마로 정의됩니다 (주석 '-' 뒤에는 추가 열 설명이 제공됩니다). "Value Examples"는 해당 열의 실제 값입니다. 일부 열에는 질문과 직접적으로 관련된 값이 포함될 수 있습니다. 이를 활용하여 어떤 열을 사용할지 정당화하는 데 도움을 받으십시오.

테이블 스키마 정보 설명, 'Question' 및 'Hint'가 주어졌을 때, 질문에 답하는 SQL 쿼리를 생성해야 합니다. 최종 SQL 쿼리는 응답의 마지막에 제시해 주십시오.

---

Table creation statements: {SCHEMA_CONTEXT}

---

Question: {QUESTION} Hint: {HINT}

---

Output Format: <think> Your thinking process. </think> <sql> The final SQL query. </sql>

Figure 13. Baseline Text-to-SQL Prompt. </sql>