Pourreza, Mohammadreza, et al. "Chase-sql: Multi-path reasoning and preference optimized candidate selection in text-to-sql." arXiv preprint arXiv:2410.01943 (2024).

CHASE-SQL: Multi-Path Reasoning and Preference Optimized Candidate Selection in Text-to-SQL

Mohammadreza Pourreza ${ }^{1 *}$, Hailong Li ${ }^{1 *}$, Ruoxi Sun ${1}$, Yeounoh Chung ${1}$, Shayan Talaei ${2}$, Gaurav Tarlok Kakkar ${1}$, Yu Gan ${1}$, Amin Saberi ${2}$, Fatma Özcan ${1}$, Sercan Ö. Arık ${1}$<br>${ }^{1}$ Google Cloud, Sunnyvale, CA, USA<br>${ }^{2}$ Stanford University, Stanford, CA, USA<br>{pourreza, hailongli, ruoxis, yeounoh}@google.com<br>{gkakkar, gany, fozcan, soarik}@google.com<br>{stalaei, saberi}@stanford.edu<br>*동일 기여 (Equal contribution)

2024년 10월 4일

Abstract

Text-to-SQL task에서 대규모 언어 모델(LLM) 성능의 한계점을 해결하기 위해, 우리는 CHASE-SQL이라는 새로운 프레임워크를 소개한다. 이 프레임워크는 multi-agent modeling에서 test-time compute를 활용하여 후보 생성 및 선택을 개선하는 혁신적인 전략을 사용한다.
CHASE-SQL은 LLM의 **내재된 지식(intrinsic knowledge)**을 활용하여 다양하고 고품질의 SQL 후보를 생성하며, 이를 위해 다양한 LLM generator를 사용한다. 이 generator들은 다음 세 가지 기법을 포함한다:

1. divide-and-conquer 방식: 단일 LLM 호출 내에서 복잡한 쿼리를 관리 가능한 하위 쿼리로 분해한다.
2. query execution plan 기반의 chain-of-thought reasoning: 데이터베이스 엔진이 쿼리 실행 시 따르는 단계를 반영한다.
3. 고유한 instance-aware synthetic example generation 기술: 테스트 질문에 맞춰진 특정 few-shot demonstration을 제공한다.

최고의 후보를 식별하기 위해 **선택 에이전트(selection agent)**가 사용된다. 이 에이전트는 fine-tuning된 binary-candidates selection LLM을 사용하여 쌍별 비교(pairwise comparisons)를 통해 후보들의 순위를 매긴다. 이 선택 접근 방식은 다른 대안들보다 **더 강력함(robust)**이 입증되었다.
제안된 generator-selector 프레임워크는 SQL 쿼리의 품질과 다양성을 향상시킬 뿐만 아니라, 기존 방법들을 능가하는 성능을 보여준다.
전반적으로, 우리가 제안하는 CHASE-SQL은 주목할 만한 BIRD Text-to-SQL 데이터셋 벤치마크의 테스트 세트와 개발 세트에서 각각 73.0% 및 73.01%의 state-of-the-art 실행 정확도를 달성하여, CHASE-SQL을 리더보드의 최고 제출작(논문 제출 시점 기준)으로 만들었다.

1 Introduction

Text-to-SQL은 인간의 언어와 기계가 읽을 수 있는 구조화된 쿼리 언어 사이의 다리 역할을 하며, 자연어 질문을 실행 가능한 SQL 명령으로 변환하는 데 많은 use case에서 매우 중요하다 (Androutsopoulos et al., 1995; Li & Jagadish, 2014; Li et al., 2024c; Yu et al., 2018; ?). Text-to-SQL은 사용자가 SQL 전문 지식 없이도 복잡한 데이터베이스 시스템과 상호 작용할 수 있도록 함으로써, 귀중한 통찰력을 추출하고, 간소화된 데이터 탐색을 수행하며, 정보에 입각한 의사 결정을 내리고, 데이터 기반 보고서를 생성하며, 머신러닝을 위한 더 나은 feature를 발굴할 수 있도록 지원한다 (Chen et al., 2023; Pérez-Mercado et al., 2023; Pourreza & Rafiei, 2024a; Pourreza et al., 2024; Sun et al., 2023; Wang et al., 2019; Xie et al., 2023). 또한, Text-to-SQL 시스템은 복잡한 추론을 통한 데이터 분석 자동화 및 대화형 에이전트(conversational agents) 구동에 중추적인 역할을 하여, 전통적인 데이터 검색을 넘어 그 응용 분야를 확장하고 있다 (Sun et al., 2023; Xie et al., 2023). 데이터가 기하급수적으로 증가함에 따라, 광범위한 SQL 지식 없이도 데이터베이스를 효율적으로 쿼리하는 능력은 다양한 애플리케이션에 점점 더 중요해지고 있다.

Text-to-SQL은 **코드 생성(code generation)**의 특수한 형태로 간주될 수 있으며, 이때 contextual information에는 데이터베이스 스키마, 메타데이터 및 값들이 포함될 수 있다. 더 넓은 코드 생성 도메인에서, LLM을 활용하여 다양하고 폭넓은 후보들을 생성하고 그 중 최적의 것을 선택하는 방식은 효과적임이 입증되었다 (Chen et al., 2021; Li et al., 2022; Ni et al., 2023). 그러나 무엇이 가장 효과적인 후보 제안(candidate proposal) 및 최종 선택(winner selector) 메커니즘으로 이어지는지는 명확하지 않다. 간단하면서도 효과적인 접근 방식은 zero-/few-shot 또는 open-ended prompting을 사용하여 후보들을 생성한 다음, self-consistency (Wang et al., 2022)를 활용하여 최적의 옵션을 선택하는 것이다. 이는 실행 결과(execution outputs)를 기반으로 후보들을 클러스터링하는 것을 포함한다. 이 접근 방식은 여러 연구에서 유망한 결과를 보여주었다 (Lee et al., 2024; Maamari et al., 2024; Talaei et al., 2024; Wang et al., 2023). 하지만 단일 prompt design이 LLM의 광범위한 Text-to-SQL 지식을 완전히 발휘하지 못할 수 있으며, self-consistency 방법이 항상 효과적이지 않을 수도 있다. 실제로 Table 1에서 보듯이, 가장 일관된 답변이 항상 정답인 것은 아니며, self-consistency를 통해 달성된 성능보다 **14% 더 높은 상한 성능(upper-bound performance)**을 보인다. 이 상당한 격차는 후보 쿼리 풀에서 최적의 답변을 식별하기 위한 더 효과적인 선택 방법을 구현함으로써 상당한 개선 가능성이 있음을 강조한다.

이전 섹션에서 설명된 도전 과제들을 바탕으로, 우리는 agentic framework에서 신중하게 설계된 test-time computation을 활용하여 Text-to-SQL에 대한 LLM 성능을 향상시키기 위한 새로운 접근 방식을 제안한다. Table 1의 상한선이 나타내듯이, LLM의 내재적 지식을 활용하는 것은 상당한 개선 잠재력을 제공한다. 우리는 다양하고 고품질의 후보 응답 세트를 생성하고, 최적의 답변을 식별하기 위한 선택 메커니즘을 적용하는 방법을 제안한다. 고품질과 다양성을 모두 갖춘 후보 응답을 달성하는 것은 scoring 기반 선택 방법의 성공에 매우 중요하다. 다양성이 낮으면 개선 잠재력이 제한되고 self-consistency와 scoring 기반 접근 방식 간의 차이가 줄어든다. temperature를 높이거나 prompt 내용을 재정렬하는 기술은 다양성을 높일 수 있지만, 종종 후보의 품질을 저하시킨다. 이를 해결하기 위해 우리는 **고품질 출력을 유지하면서 다양성을 향상시키도록 설계된 효과적인 후보 생성기(candidate generators)**를 도입한다. 구체적으로, 우리는 각각 고품질 응답을 생성할 수 있는 세 가지 고유한 후보 생성 접근 방식을 제안한다. 첫 번째는 복잡한 문제를 더 작고 관리하기 쉬운 부분으로 분해하여 어려운 쿼리를 처리하는 divide-and-conquer 알고리즘에서 영감을 받았다. 두 번째는 쿼리 실행 계획 기반의 chain-of-thought 전략을 사용하는데, 여기서 추론 과정은 데이터베이스 엔진이 쿼리 실행 중에 취하는 단계를 반영한다. 마지막으로, 우리는 모델이 테스트 데이터베이스의 기본 데이터 스키마를 더 잘 이해하도록 돕는 새로운 온라인 합성 예시 생성 방법을 도입한다. 이러한 방법들은 독립적으로 사용될 때 매우 정확한 SQL 출력을 생성할 수 있다. 후보들 중에서 최적의 답변을 효과적으로 선택하기 위해, 우리는 **분류 목적(classification objective)으로 학습된 선택 에이전트(selection agent)**를 도입한다. 이 에이전트는 후보 쿼리 간의 쌍별 비교(pairwise comparisons)를 기반으로 점수를 할당한다. 이 에이전트를 사용하여 모든 후보에 대한 **비교 행렬(comparison matrix)**을 구성하고, 가장 높은 누적 점수(cumulative score)를 기반으로 최종 응답을 선택한다. 이러한 후보 생성 방법들을 제안된 scoring model과 결합함으로써, 우리는 각 전략의 강점을 활용하여 전반적인 성능을 크게 향상시키는 **앙상블 접근 방식(ensemble approach)**을 만든다.

Table 1: BIRD dev set에서 Gemini 1.5 Pro를 사용한 Text-to-SQL에 대한 단일 쿼리 생성(single-query generation)과 self-consistency 앙상블 방법 및 달성 가능한 상한선(upper bound) 평가. EX는 execution accuracy를 나타낸다.

우리는 CHASE-SQL의 제안된 방법론의 효능에 대한 포괄적인 평가를 제시한다. 우리의 혁신적인 후보 생성 접근 방식은 전통적인 일반 CoT prompt에 비해 우수한 성능을 보여주며, LLM이 복잡한 문제를 관리 가능한 중간 단계로 분해하도록 안내하는 능력을 입증한다. 또한, 제안된 선택 에이전트는 기존의 consistency 기반 방법을 크게 능가하여 state-of-the-art 결과에 기여한다. 특히, CHASE-SQL은 도전적인 BIRD Text-to-SQL 데이터셋의 개발 세트에서 73.01%, 테스트 세트에서 73.0%의 execution accuracy를 달성하며, 이 벤치마크에서 공개되었거나 공개되지 않은 모든 방법들을 큰 차이로 능가한다.

2 Related Work

초기 Text-to-SQL 방법들은 주로 sequence-to-sequence 아키텍처를 활용했으며, Graph Neural Network (GNN), Recurrent Neural Network (RNN), Long Short-Term Memory (LSTM) 네트워크, 사전학습된 Transformer encoder와 같은 모델을 사용하여 사용자 쿼리와 데이터베이스 스키마를 인코딩했다 (Cai et al., 2021; Cao et al., 2021; Hwang et al., 2019). 디코딩 측면에서는 이러한 시스템들이 slot-filling 또는 auto-regressive 모델링 접근 방식을 사용하여 인코딩된 입력으로부터 최종 SQL 쿼리를 구성했다 (Choi et al., 2021; Wang et al., 2019). 또한, TaBERT (Yin et al., 2020), TaPas (Herzig et al., 2020), Grappa (Yu et al., 2020)와 같은 tabular language model들이 테이블과 텍스트 데이터를 모두 효과적으로 인코딩하기 위해 개발되었다.

그러나 LLM의 광범위한 사용으로 인해 상황이 변화했으며, LLM은 우수한 성능으로 인해 이전 방법들을 대부분 대체했다 (Katsogiannis-Meimarakis & Koutrika, 2023; Quamar et al., 2022). 초기에는 이러한 LLM을 위한 prompt 디자인 최적화에 노력이 집중되었다 (Dong et al., 2023; Gao et al., 2023; Pourreza & Rafiei, 2024a). 이후의 발전은 schema linking (Li et al., 2024b; Pourreza & Rafiei, 2024a,b; Talaei et al., 2024), self-correction 또는 self-debugging (Chen et al., 2023; Talaei et al., 2024; Wang et al., 2023), 그리고 self-consistency 기법 (Lee et al., 2024; Maamari et al., 2024; Sun et al., 2023; Talaei et al., 2024)을 포함한 더 복잡한 방법론들을 도입하여, 복잡한 LLM 기반 파이프라인을 제안함으로써 성능을 더욱 향상시켰다.

3 Methods

3.1 Overall Framework

이 섹션에서는 제안하는 CHASE-SQL 프레임워크를 설명한다. 이 프레임워크는 네 가지 주요 구성 요소로 이루어져 있다:

1. Value retrieval
2. Candidate generator
3. Query fixer
4. Selection agent

Fig. 1에 나타난 바와 같이, 제안하는 프레임워크는 먼저 관련 데이터베이스 값(relevant database values)을 검색하는 것으로 시작한다. 이어서, 검색된 값을 포함한 모든 문맥 정보(contextual information), 즉 **데이터베이스 메타데이터(database metadata)와 스키마(schema)**가 LLM에 제공되어 후보 쿼리(candidate queries)를 생성한다. 이 후보 쿼리들은 fixing loop를 거친 후, 최종적으로 학습된 selection agent를 사용하여 모든 후보들을 쌍별(pairwise)로 비교하여 정확한 답변을 선택한다. 다음 섹션들에서는 각 구성 요소에 대한 세부 사항을 다룬다.

Figure 1: 제안하는 CHASE-SQL 프레임워크의 개요. 이 프레임워크는 Text-to-SQL을 위한 것으로, value retrieval을 포함하며, 생성된 후보들 중에서 답변 선택을 개선하기 위한 selection agent와 출력 개선을 위한 피드백을 제공하는 fixer를 사용한다.

3.2 Value Retrieval

데이터베이스에는 매우 많은 수의 행이 포함될 수 있으며, 종종 그중 소수만이 쿼리와 관련이 있다. 관련성 있는 값을 검색하는 것은 'WHERE' 및 'HAVING'과 같은 다양한 SQL 절에서 사용될 수 있으므로 매우 중요하다. (Talaei et al., 2024)의 접근 방식과 유사하게, 우리는 few-shot 예시로 prompt된 LLM을 사용하여 주어진 질문에서 키워드를 추출하는 것으로 시작한다. 각 키워드에 대해, 우리는 locality-sensitive hashing (LSH) (Datar et al., 2004)를 사용하여 가장 구문적으로 유사한 단어를 검색하고, **embedding 기반 유사도와 edit distance를 기반으로 재순위화(re-rank)**한다. 이 접근 방식은 질문의 오타에 강건하며, 검색 시 키워드의 의미론을 고려한다.

3.3 Multi-path Candidate Generation

Table 1에서 보여주듯이, 응답 간의 일관성에만 의존하는 것은 최적 이하의 성능으로 이어질 수 있다. 따라서 우리는 최소한 하나의 올바른 답변을 생성할 가능성을 높이기 위해 여러 응답 후보 생성 시 다양성을 우선한다. 후보 생성기(candidate generator)에 의해 생성된 다양한 응답들 중에서, 우리는 후보들을 쌍으로 비교하는 선택 에이전트(selection agent)를 사용하여 최종 응답을 하나 선택한다. 다양한 응답을 생성하기 위해, 우리는 다음 토큰 샘플링 온도(next token sampling temperature)를 높이고, 프롬프트 내의 열(column)과 테이블의 순서를 섞는다.

Chain-of-Thought (CoT) prompting (Wei et al., 2022)은 단계별 추론 과정에 최종 응답을 조건화하여 LLM의 추론 능력을 향상시키기 위해 제안되었다. 대부분의 CoT prompting 접근 방식은 프롬프트 내의 few-shot 예시에 의존하여 LLM이 단계별로 사고하도록 안내하며, 그 형식은 $M=\left(q_{\mathrm{i}}, r_{\mathrm{i}}, s_{\mathrm{i}}\right)$이다. 여기서 $\mathrm{q}_{\mathrm{i}}$는 예시 질문, $\mathrm{r}_{\mathrm{i}}$는 추론 경로, $\mathrm{s}_{\mathrm{i}}$는 $\mathrm{q}_{\mathrm{i}}$에 대한 ground truth SQL 쿼리이다. 우리는 두 가지 고유한 추론 방법과 온라인 합성 예시 생성 접근 방식을 사용한다. Fig. 3a에서 보여주듯이, 다른 생성기는 다른 출력을 생성할 수 있으며, 이는 특정 질문과 데이터베이스에 대한 그들의 효과를 나타낸다.

Divide and Conquer CoT: Divide-and-conquer 관점은 복잡한 문제를 더 작은 하위 문제로 분해하고, 각 문제를 개별적으로 해결한 다음, 해결책을 결합하여 최종 답변을 얻는 것을 의미한다. 이러한 맥락에서, 우리는 주어진 질문을 pseudo-SQL 쿼리를 사용하여 더 작은 하위 문제로 먼저 분해하는 CoT prompting 접근 방식을 제안한다. 'conquer' 단계에서는 이러한 하위 문제의 해결책이 집계되어 최종 답변을 구성한다. 마지막으로, 구성된 쿼리에 최적화 단계를 적용하여 불필요한 절(clause)과 조건(condition)을 제거한다. 이 접근 방식은 중첩 쿼리(nested queries), 예를 들어 복잡한 WHERE 또는 HAVING 조건, 그리고 고급 수학 연산을 요구하는 쿼리와 같은 복잡한 시나리오를 처리하는 데 특히 강력하다. Appendix Fig. 17에서는 이 생성기를 사용하여 성공적으로 해결된 질문과 해당 SQL 쿼리의 예시를 보여준다. 이는 본 논문에서 고려된 다른 방법들이 쿼리의 복잡한 조건과 SQL 절 때문에 해결할 수 없었던 시나리오이다. divide-and-conquer 프롬프트에 대한 더 자세한 내용은 Appendix Fig. 16을 참조하라. 또한, Alg. 1은 단일 LLM 호출을 사용하여 최종 SQL 출력을 생성하는 이 전략의 단계별 프로세스를 설명한다.

Algorithm 1 Divide and Conquer Chain-of-Thought (CoT) Strategy for Text-to-SQL.
Input: Set of human-annotated few-shot examples \(M\), user question \(Q_{u}\), target database \(D\) associated with the
    question, and a large language model (LLM) \(\theta\).
    Divide:
    \(S_{q} \leftarrow \theta\left(M, D, Q_{u}\right) / /\) Decompose the original question \(Q_{u}\) into a set of sub-questions \(S_{q}\)
    \(S_{\text {sql }} \leftarrow \emptyset / /\) Initialize an empty set \(S_{\text {sql }}\) to store partial \(S Q L\) queries for each sub-question
    Conquer:
    for each sub-question \(q_{i}\) in \(S_{q}\) do
        // Generate a partial SQL query for each sub-question \(q_{i}\)
        \(S_{s q l} \leftarrow S_{s q l} \cup\left\{\theta\left(M, D, Q_{u}, q_{1}, \ldots, q_{i}, s q l_{1}, \ldots, s q l_{i-1}\right)\right\}\)
    end for
    Assemble:
    \(S_{f} \leftarrow \theta\left(M, D, Q_{u}, S_{q}, S_{\text {sql }}\right) / /\) Assemble the final \(S Q L\) query \(S_{f}\) from all sub-queries in \(S_{\text {sql }}\)
    return \(S_{f}\)

Query Plan CoT: **쿼리 (실행) 계획(query (execution) plan)**은 데이터베이스 엔진이 SQL 명령으로 설명된 데이터에 접근하거나 수정하기 위해 따르는 일련의 단계이다. SQL 쿼리가 실행될 때, 데이터베이스 관리 시스템의 쿼리 최적화기(query optimizer)는 SQL 텍스트를 데이터베이스 엔진이 실행할 수 있는 쿼리 계획으로 변환한다. 이 계획은 테이블이 어떻게 접근되고, 어떻게 조인되며, 데이터에 대해 어떤 특정 작업이 수행되는지를 설명한다 (예시는 Appendix Fig. 19 참조). 데이터베이스 엔진이 SQL 쿼리를 실행하는 단계별 프로세스에서 영감을 받아, 우리는 최종 SQL 출력을 구성하기 위한 추론 전략을 제안한다. 주어진 SQL 쿼리에 대한 쿼리 계획은 "EXPLAIN" 명령을 사용하여 얻을 수 있으며, 이는 실행 단계에 대한 자세한 분석을 제공한다. 그러나 이 출력은 종종 LLM이 해석하기 어려운 형식(예: SQLite)으로 제공된다. 이를 해결하기 위해, 우리는 "EXPLAIN" 명령의 출력을 LLM의 사전학습 데이터와 더 밀접하게 일치하는 사람이 읽을 수 있는 텍스트 형식으로 변환한다. 쿼리 계획의 사람이 읽을 수 있는 버전은 세 가지 주요 단계로 구성된다: (1) 질문에 대한 관련 테이블 식별 및 위치 파악, (2) 테이블 간의 카운팅, 필터링 또는 매칭과 같은 작업 수행, (3) 반환할 적절한 열을 선택하여 최종 결과 제공. 이 추론 방법은 divide-and-conquer CoT 전략을 보완한다. divide-and-conquer 접근 방식이 복잡한 질문을 분해하는 데 더 적합한 반면, 쿼리 계획 접근 방식은 질문이 질문의 다른 부분과 데이터베이스 스키마 간의 관계에 대한 더 많은 추론을 요구할 때 탁월하다. 이는 어떤 테이블을 스캔하고, 열을 어떻게 매칭하며, 필터를 어떻게 적용할지를 체계적으로 설명한다. Appendix Fig. 20은 이 방법으로만 올바르게 답변된 질문의 예시를 보여준다. Appendix Fig. 18은 이 추론 전략에 사용된 프롬프트를 제공한다.

Online Synthetic Example Generation: few-shot in-context learning을 위해 $M$개의 demonstration을 사용하는 것은 다양한 관련 task에서 유망한 결과를 보여주었다 (Pourreza & Rafiei, 2024a). task를 지정하고 출력을 도출하는 단계별 프로세스를 설명하는 데 도움이 될 뿐만 아니라, 관련 테이블과 열을 사용하여 구성된 demonstration은 모델이 기본 데이터 스키마를 이해하는 데도 도움이 될 수 있다. 이러한 통찰력을 바탕으로, 우리는 Text-to-SQL을 위한 합성 demonstration 생성 전략을 제안한다. 이는 사용자 질문 $Q_{u}$, 대상 데이터베이스 $D$, 그리고 선택된 열 $t_{i}$ (Talaei et al., 2024와 유사한 열 선택 접근 방식 사용)가 주어졌을 때 작동한다.

Algorithm 2 Online Synthetic example generation strategy for Text-to-SQL.
Input: User question \(Q_{u}\), additional user hint \(H_{u}\), target database \(D\) and filtered relevant table columns \(t\) associated
    with the question, LLM \(\theta\), guidelines \(R_{f}\) for generating examples by SQL features, guidelines \(R_{t}\) for generating
    examples with filtered schema, and the numbers of examples to generate \(n_{f}, n_{t}\) respectively
    \(P \leftarrow \emptyset / /\left\{\left(q_{i}, s_{i}\right) \mid q_{i}, s_{i} \in \Sigma^{*}\right\}\), where \(q_{i}\) is input question, \(s_{i}\) is output \(S Q L\) for the \(i\)-th example
    \(P \leftarrow P \cup\left\{\theta\left(D, R_{f}, n_{f}\right)\right\} / /\) Generate \(n\) examples with entire database by common \(S Q L\) features
    \(P \leftarrow P \cup\left\{\theta\left(t, R_{t}, n_{t}\right)\right\} / /\) Generate examples with filtered columns to highlight correct schema usage
    return \(P\)

Algorithm 2는 두 단계의 LLM 생성 과정을 포함하는 온라인 합성 예시 생성 접근 방식을 설명한다. 첫 번째 단계는 가이드라인 $R_{f}$에 설명된 일반적인 SQL feature를 사용하여 설명적인 예시를 생성하는 데 중점을 둔다. SQL feature에는 동등 및 비동등 조건자(equality and non-equality predicates), 단일 테이블 및 다중 테이블 JOIN, 중첩 JOIN, ORDER BY 및 LIMIT, GROUP BY 및 HAVING, 다양한 집계 함수가 포함된다. 이들은 널리 적용 가능한 SQL 절 및 함수이며, 이러한 feature를 통합한 생성된 예시 SQL 쿼리는 BIRD SQL feature 분포를 따른다 (Appendix Fig 23a). 두 번째 단계는 기본 데이터 스키마의 올바른 해석을 강조하는 예시를 생성하는 데 중점을 둔다. 모델 $\theta$는 $t_{i}$를 사용하여 $R_{t}$에 설명된 예시와 유사한 예시를 생성하도록 요청받는다. Appendix A.10은 예시 생성에 사용된 프롬프트를 제공한다.

관련 예시(예: 여러 테이블을 포함하는 중첩 JOIN 쿼리를 보여주는 예시)는 복잡한 JOIN 쿼리를 요구하는 질문에 도움이 될 수 있지만, LLM이 과도하게 사용하도록 오도할 수도 있다 (예: 간단한 단일 테이블 쿼리로 충분할 때). 이러한 점과 관련성에 따라 예시를 도출하는 자연어 쿼리 $q_{i}$의 본질적인 모호성 때문에 예시 선택은 어렵다. 따라서 우리는 $q_{i}$당 온라인으로 예시를 생성하고 프롬프트에 주입한다. 우리는 LLM에게 in-context learning을 위해 많은 입력-출력 쌍을 생성하도록 요청한다. $q_{i}$에 대한 최종 합성 예시 세트에는 $R_{f}$와 $R_{t}$ 모두로 생성된 예시가 포함된다. 이는 예시 세트가 SQL feature/절 및 사용된 관련 테이블/열 선택 모두에서 다양하도록 보장한다. 예시 세트의 다양성은 출력이 특정 패턴에 과적합되는 것을 방지하는 데 바람직하다 (예: 모델이 주로 JOIN 예시를 본 경우 항상 JOIN이 포함된 SQL을 작성하는 경우). 다양한 SQL feature 및 데이터베이스 테이블에 대해 열 필터링 유무에 관계없이 다양한 예시를 혼합하는 것은 전반적으로 더 나은 생성 품질을 가져오는 것으로 관찰되었다 (Appendix Table 8 참조).

3.4 Query Fixer

어떤 경우에는 LLM이 구문적으로 올바르지 않은(syntactically incorrect) 쿼리를 생성할 수 있다. 이러한 쿼리들은 올바른 답변을 제공하지 못하므로, 수정이 필요한 명확한 대상이 된다. 이 문제를 해결하기 위해 우리는 self-reflection (Shinn et al., 2024) 방법을 활용하는 **LLM 기반 쿼리 수정기(query fixer)**를 적용한다. 이 수정기는 이전에 생성된 쿼리에 대해 구문 오류 세부 정보나 빈 결과 집합과 같은 피드백을 사용하여 수정 프로세스를 안내한다. 우리는 이러한 반복적인 수정 접근 방식을 **지정된 시도 횟수 $\beta$ (본 논문에서는 3으로 설정)**까지 계속한다. Appendix Fig. 21은 이 쿼리 수정 단계에 사용된 prompt를 보여준다.

3.5 Selection Agent

SQL 쿼리를 생성하는 세 가지 다른 방법을 사용하여, 주어진 질문에 대한 후보 쿼리(candidate queries) 집합을 생성할 수 있다. 이 단계의 핵심 과제는 이러한 후보 풀에서 올바른 SQL 쿼리를 선택하는 것이다.
단순한 접근 방식은 후보 쿼리들을 실행하여 일관성을 측정하고, 실행 결과에 따라 그룹화한 다음, 가장 큰 그룹에서 쿼리를 선택하여 가장 가능성 있는 정답으로 삼는 것이다. 그러나 이 방식은 가장 일관된 답변이 항상 최선이라는 가정을 전제하는데, 이는 항상 사실이 아니다.
대신, 우리는 선택 에이전트(selection agent)에 의존하는 보다 정교한 선택 전략인 Algorithm 3을 제안한다.
주어진 후보 SQL 쿼리 집합 $C=\left\{c_{1}, c_{2}, \ldots, c_{n}\right\}$에서, 최종 응답은 선택 모델(selection model)이 할당한 가장 높은 점수를 가진 후보를 찾아 선택된다. 이 모델 $\theta_{p}$는 $k$개의 후보를 입력받아, 각 후보가 주어진 질문에 얼마나 정확하게 답하는지에 따라 순위를 매길 수 있다. 구체적으로, 우리는 최종 응답의 선택을 다음과 같이 공식화한다:

$$c_{f}=\arg \max _{c \in C}\left(\sum_{i=1}^{\binom{n}{k}} \theta_{p}\left(c_{i_{1}}, \ldots, c_{i_{k}} \mid Q_{u}, H_{u}, D\right)\right),$$

여기서 $Q_{u}$는 사용자의 질문, $H_{u}$는 제공된 힌트, $D$는 질문이 주어지는 대상 데이터베이스를 나타낸다. Eq. 1에서 우리는 $k$개의 후보를 선택 모델에 전달하여 순위를 매기며, $k$는 1에서 $n$ 사이의 값이다.
$k=1$인 극단적인 경우, 모델은 후보들 간의 비교를 할 수 없어 모델의 평가 프로세스가 복잡해진다.
$k$가 증가할수록, 더 많은 후보를 비교해야 하므로 모델이 여러 측면을 동시에 고려해야 하여 프로세스가 더욱 어려워진다.
결과적으로, 우리는 $k=2$로 설정하고, 한 번에 두 개의 후보만 비교하는 분류 목적(classification objective)을 가진 모델을 학습시킨다.

고품질의 다양한 후보 집합이 있을 때, 가장 간단한 해결책은 기성 LLM을 사용하여 쌍별 선택(pairwise selection)을 수행하는 것이다. 그러나 Gemini-1.5-pro를 사용한 실험 결과, fine-tuning 없이 LLM을 사용했을 때는 이진 분류 정확도가 58.01%에 불과했다. 이는 주로 후보들이 서로 매우 유사하여, 미묘한 차이를 학습하고 더 정확한 결정을 내리기 위해 fine-tuned 모델이 필요하기 때문이다.
선택 에이전트를 학습시키기 위해, 우리는 먼저 학습 세트(Text-to-SQL 벤치마크)에서 후보 SQL 쿼리를 생성하고, 실행 결과에 따라 클러스터로 그룹화한다.
적어도 하나의 클러스터에 올바른 쿼리가 포함되고 다른 클러스터에 잘못된 쿼리가 포함된 경우, 우리는 다음과 같은 형식의 학습 예시 튜플을 생성한다: $\left(Q_{u}, C_{i}, C_{j}, D_{i j}, y_{i j}\right)$.
여기서 $Q_{u}$는 사용자의 질문, $C_{i}$와 $C_{j}$는 비교되는 두 후보 쿼리, $D_{i j}$는 두 후보가 사용하는 데이터베이스 스키마, 그리고 $y_{i j} \in 0,1$은 $C_{i}$ 또는 $C_{j}$ 중 어느 것이 올바른 쿼리인지를 나타내는 레이블이다.
학습 중 순서 편향(order bias)을 피하기 위해, 각 쌍에서 올바른 쿼리와 잘못된 쿼리의 순서를 무작위로 섞는다.
올바른 후보와 잘못된 후보가 모두 존재하는 경우는 제한적이므로, 올바른 후보가 없는 인스턴스의 경우, ground truth SQL 쿼리를 힌트로 prompt에 포함하여 모델이 올바른 후보를 생성하도록 유도한다.

Algorithm 3 후보 풀에서 최종 SQL 쿼리 선택.
입력: 후보 SQL 쿼리 집합 \(C=\left\{c_{1}, c_{2}, \ldots, c_{n}\right\}\), 사용자 질문 \(Q_{u}\), 힌트 \(H_{u}\), 대상 데이터베이스 \(D\),
    선택 모델 \(\theta_{p}\), \(\operatorname{er}\left(c_{i}, D\right)\)는 \(D\)에서 \(c_{i}\)의 실행 결과
    \(r_{i} \leftarrow 0\) for all \(c_{i} \in C / /\) 각 후보 쿼리의 점수 \(r_{i}\)를 0으로 초기화
    for each distinct pair ( \(c_{i}, c_{j}\) ) where \(i \neq j\) do
        if \(\operatorname{er}\left(c_{i}, D\right)=\operatorname{er}\left(c_{j}, D\right)\) then
            \(w \leftarrow i / /\) 실행 결과가 일치하면 \(c_{i}\)가 승자
        else
            \(S_{i, j} \leftarrow\) schema_union \(\left(c_{i}, c_{j}, D\right) / /\) \(c_{i}\)와 \(c_{j}\)에서 사용된 스키마의 합집합 구성
            \(w \leftarrow \theta_{p}\left(S_{i, j}, Q_{u}, H_{u}, c_{i}, c_{j}\right) w \in\{i, j\} / /\) 이진 분류기 \(\theta_{p}\)를 사용하여 승자 \(w \in\{i, j\}\) 선택
        end if
        \(r_{w} \leftarrow r_{w}+1 / /\) 승자 \(c_{w}\)의 점수 1 증가
    end for
    \(c_{f} \leftarrow \arg \max _{c_{i} \in C} r_{i} / /\) 가장 높은 점수를 가진 후보를 최종 SQL 쿼리 \(c_{f}\)로 선택
    return \(c_{f}\)

Algorithm 3의 pseudo-code에서, 우리는 각 후보 쿼리의 점수를 0으로 초기화하는 것으로 시작한다. 그런 다음, 모든 고유한 쿼리 쌍 ($c_{i}, c_{j}$)에 대해, 순서 편향을 완화하기 위해 ($c_{i}, c_{j}$)와 ($c_{j}, c_{i}$)를 모두 비교하여, 쌍의 두 후보가 공정하게 평가되도록 한다.
만약 두 쿼리가 데이터베이스에서 동일한 실행 결과를 생성하면, 이러한 결과가 일관성을 시사하므로 하나를 승자로 표시하고 점수를 증가시킨다.
만약 실행 결과가 다르면, 두 쿼리가 사용하는 스키마의 합집합을 생성하고, 이진 분류기(binary classifier)를 사용하여 어떤 쿼리가 더 정확할 가능성이 높은지 결정한다. 분류기는 질문, 두 후보 쿼리, 그리고 결합된 스키마를 고려하여 결정을 내린다. 그런 다음 승자의 점수가 그에 따라 업데이트된다.
모든 비교가 완료된 후, 가장 높은 점수를 가진 후보가 최종 쿼리로 선택된다. 최종 점수가 동점인 드문 경우에는, 임의로 후보 중 하나를 선택하여 동점을 해소한다.

4 Experiments

4.1 Datasets and Models

우리는 제안하는 CHASE-SQL 프레임워크의 성능을 널리 알려진 두 가지 cross-domain 데이터셋인 **BIRD (Li et al., 2024c)**와 **Spider (Yu et al., 2018)**를 통해 평가한다.
BIRD는 95개의 대규모 데이터베이스에서 추출된 12,751개 이상의 고유한 질문-SQL 쌍을 포함하며, 37개 이상의 전문 도메인에 걸쳐 있다. 이 데이터베이스들은 실제 시나리오를 모방하여 정제되지 않은 데이터 행(messy data rows)과 복잡한 스키마를 특징으로 한다.
Spider는 200개의 데이터베이스에 걸쳐 10,181개의 질문과 5,693개의 고유한 복잡한 SQL 쿼리를 포함하며, 138개의 도메인을 다룬다. Spider 데이터셋은 BIRD와 유사하게 중복되지 않는 훈련, 개발, 테스트 세트로 나뉘어 있다.
두 데이터셋 모두에서 우리는 **실행 정확도(EX, execution accuracy)**를 주요 평가 지표로 사용하여 방법론들을 비교한다. EX는 각 데이터셋의 공식 리더보드에서 사용되는 지표이다. 모델 및 하이퍼파라미터에 대한 자세한 내용은 Appendix A.2 섹션에 제공되어 있다.

4.2 BIRD results

우리는 제안된 CHASE-SQL 프레임워크의 end-to-end Text-to-SQL 성능을 Claude-3.5-sonnet 및 Gemini 1.5 pro를 사용하여 BIRD 개발 세트에서, 그리고 Gemini 1.5 pro를 사용하여 BIRD 테스트 세트에서 제시한다. 우리는 **공개된 방법(코드베이스 및/또는 논문이 있는 경우)**과 비공개 방법 모두와 비교한다. Gemini 1.5 pro와의 공정한 비교를 위해, Claude-3.5-sonnet 설정에서는 선택 모델(selection model)을 제외한 모든 LLM 호출이 Claude-3.5-sonnet을 사용하여 이루어진다 (이전에 학습된 선택 모델은 재사용된다). Table 2에서 보듯이, Gemini 1.5 pro를 사용한 CHASE-SQL은 BIRD 개발 세트에서 73.01%의 정확도를, BIRD holdout 테스트 세트에서 73.0%의 정확도를 달성하여, 모든 이전 연구를 능가하고 새로운 state-of-the-art 성능을 수립한다.

Table 2: BIRD 벤치마크에서 다양한 Text-to-SQL 방법의 성능 비교. Table 3: Spider 테스트 세트에서 다양한 Text-to-SQL 방법의 성능 비교.

4.3 Spider results

우리는 제안된 CHASE-SQL의 일반화 능력을 평가하기 위해, prompt 내 few-shot 샘플을 수정하거나 새로운 selection model을 학습시키지 않고, 즉 target distribution의 데이터를 전혀 사용하지 않고 Spider test set에서 end-to-end 방식으로 평가를 수행했다. 이 접근 방식을 통해 우리는 학습 분포의 데이터와는 다른, 이전에 보지 못한 쿼리 및 데이터베이스 분포에 대한 CHASE-SQL의 성능을 테스트할 수 있었다.
Table 3는 CHASE-SQL이 Spider test set에서 87.6%의 실행 정확도(execution accuracy)를 달성했음을 보여주며, 이는 Spider 데이터셋에 대해 특정 학습 또는 prompt 최적화를 거친 방법들 중 두 번째로 높은 순위이다. 이는 CHASE-SQL의 강력한 일반화 능력과, 매우 다른 분포 및 고유한 도전 과제를 가진 미지의 샘플에 대해 고품질의 Text-to-SQL을 생성할 수 있는 잠재력을 강조한다.

4.4 Generator and selection performance

Generator + Fixer: Generator의 성능을 파악하기 위해, 우리는 query fixer를 적용하기 전과 후의 각 후보 생성 방법의 성능을 평가하는 ablation study를 수행했다. 우리는 제안된 generator들이 단일 후보 쿼리를 생성하는 성능을, BIRD prompt (Li et al., 2024c)에 zero-shot CoT reasoning (Kojima et al., 2022)을 추가하여 prompt 품질 평가의 baseline으로 사용한 것과 비교했다. Table 4에 제시된 결과는 제안된 방법들이 naive baseline에 비해 SQL 생성 성능을 크게 향상시키며, 다양성을 유지하면서 고품질 후보를 생성하는 목표에 부합함을 보여준다. 후보 generator 중 online synthetic data generation 접근 방식은 68.02%라는 인상적인 성능을 보여주었으며, 이는 test-time compute를 활용하여 LLM 성능을 향상시키는 데 효과적임을 입증한다.

Table 4: Gemini 1.5 pro를 사용하여 BIRD dev set에서 original BIRD prompt + zero-shot CoT와 비교한 후보 generator의 단일 후보 생성 성능에 대한 ablation study. Selector는 모든 generator에서 생성된 21개의 후보에 selection agent를 적용한 최종 성능이다.

고품질의 synthetic example을 생성함으로써 LLM 성능을 향상시킨다. 또한, query fixer는 후보 풀의 품질을 높이고 모든 후보 generator에서 성능을 거의 2% 향상시키는 데 결정적인 역할을 했다.

Selection: 우리는 selection agent의 이진 선택 정확도에 대한 분석을 수행했다. 이는 쌍대 비교에서 한 후보는 올바르고 다른 후보는 올바르지 않은 경우에 해당한다. 두 후보가 모두 올바르거나 올바르지 않은 경우는 제외했는데, 이는 두 후보가 동일한 레이블을 가지므로 선택이 결과에 영향을 미치지 않기 때문이다. 우리는 Claude-3.5-sonnet과 Gemini-1.5-pro (둘 다 fine-tuning 없이 바로 사용)의 성능을 두 개의 fine-tuned 모델과 비교했다: 1) Gemma 2 9B 및 2) Gemini-1.5-flash. Table 5에서 볼 수 있듯이, 두 fine-tuned 모델 모두 fine-tuning되지 않은 모델보다 더 높은 정확도를 달성하며, 이는 모델에 특정 선호도를 가르치는 fine-tuning의 중요성을 보여준다.

Table 5: 다양한 selection model의 이진 선택 정확도 평가.

Candidate Generation Analysis: 우리는 각 후보 generator 방법의 성능을 개별적으로 분석한다. 후보 풀에서 올바른 SQL query를 효과적으로 선택할 때의 성능 잠재력을 더 잘 이해하기 위해, BIRD development set의 모든 샘플에 대해 각 generator 방법에서 7개의 후보 SQL query를 생성한다 (총 21개의 후보). 우리는 후보 풀을 20개 이상으로 늘려도 Fig. 2d에서 볼 수 있듯이 유의미한 개선이 없다는 관찰을 바탕으로 이 후보 수를 결정했다. 항상 7개의 후보 중에서 올바른 SQL query를 선택하는 oracle selection model에 접근할 수 있다고 가정하여, 각 generator가 달성할 수 있는 **상한 성능(upper-bound performance)**을 계산한다. 반대로, 항상 잘못된 SQL query를 선택하는 adversarial selection model을 가정하여 **하한 성능(lower-bound performance)**을 결정한다. Fig. 2는 세 가지 방법 모두에 대한 상한 및 하한 성능과 selection agent의 성능을 보여준다. 보시다시피, 두 가지 다른 CoT 방법의 상한 성능은 일반적으로 다른 수의 후보에 대해 synthetic example generation 방법보다 높다. 그러나 그들의 하한 성능 또한 synthetic 방법보다 낮다. 하한 정확도는 모든 후보가 올바른 경우를 반영하며, 어떤 후보를 선택하든 상관없으므로 선택 과정의 노이즈를 줄여주기 때문에 더 높은 하한이 선호된다. 이는 selection agent의 성능에서 분명하게 나타나는데, 하한의 하락은 상한을 증가시켜도 수익이 감소하여 selection agent의 성능이 정체된다. 또한, 세 가지 방법을 모두 결합한 상한 성능은 82.79%에 도달하여, 더 나은 후보 선택 방법을 통해 상당한 개선의 여지가 있음을 강조한다. 이는 LLM의 parametric knowledge가 이미 대부분의 질문을 해결하는 데 필요한 정보를 포함하고 있음을 보여주며, 이 지식을 효과적으로 추출하고 활용하기 위한 앙상블 접근 방식의 필요성를 강조한다.

Figure 2: 다양한 후보 generator의 상한 및 하한 성능 비교.

또한, 우리는 BIRD development set의 simple, moderate, challenging 난이도 수준에 걸쳐 세 가지 후보 생성 방법에서 모든 후보를 결합하여 상한 성능을 평가한다. 이러한 난이도 범주는 BIRD development set 생성 시 인간 전문가에 의해 할당된다. Fig. 2d는 예상대로 모든 난이도 수준에서 후보 수가 증가함에 따라 상한 성능이 증가함을 보여준다. 그러나 challenging 및 moderate 클래스의 경우, simple 클래스보다 개선이 더 일찍 정체되어, 더 많은 샘플을 생성해도 이 두 난이도 수준에 대한 상한 성능이 더 이상 향상되지 않음을 시사한다.

Fig. 2는 세 가지 생성 방법인 Query Plan, Divide and Conquer, Synthetic Examples의 성능을 보여주는 벤 다이어그램을 제시한다. 교차하는 영역 내의 숫자는 여러 방법이 최소한 하나의 올바른 후보를 생성한 인스턴스를 나타낸다. 이 다이어그램은 각 방법의 고유한 기여를 시각적으로 강조하며, 이는 세 가지 generator 모두를 사용할 필요성을 나타낸다. 또한, Fig. 3b에서는 다른 generator에 의해 올바르지 않은, 각 SQL generation 방법에 의해 생성된 올바른 쿼리 수를 비교한다. divide-and-conquer 접근 방식은 challenging 질문에서 다른 방법보다 우수하며, query plan 방법은 중간 난이도 쿼리에서 탁월하다. 다양한 도메인과 다양한 수의 열 및 테이블에 걸쳐 generator의 성능을 추가로 분석하기 위해, Appendix Fig. 4에 표시된 대로 각 데이터베이스에 대해 생성된 올바른 쿼리 수를 비교한다. 보시다시피, 두 CoT 방법은 일반적으로 데이터베이스 전반에 걸쳐 유사하게 수행되는 반면, online synthetic example generation 방법은 다양성을 크게 증가시켜 다양한 데이터베이스에서 전반적으로 더 많은 올바른 답변을 제공한다.

Selection Agent Analysis: 우리는 selection agent의 query-picking 성능을 self-consistency 방법 (다수결 투표 사용) (Wang et al., 2022), oracle model (상한), adversarial model (하한)과 비교하여 평가한다. 평가를 수행하기 위해, 두 가지 다른 sampling temperature (0.5 및 1.8)를 사용하여 각 후보 생성 방법에서 10개의 샘플을 생성한다. Table 6에 제시된 결과는 selection agent가 self-consistency 방법보다 약 6% 크게 우수함을 보여준다. 예상대로 sampling temperature를 높이면 상한은 증가하지만 하한은 감소한다. 이 효과는 두 CoT 방법에 비해 synthetic data generation 방법에서 더 두드러지는데, 이는 주로 LLM이 최종 SQL query를 생성하기 전에 추론 단계를 생성하여 높은 temperature sampling으로 인한 무작위성을 완화하는 데 도움이 되기 때문이다. self-consistency 방법의 성능은 temperature가 증가함에 따라 일반적으로 감소하는데, 이는 더 많은 무작위 쿼리로 인해 다수 클러스터가 작아지기 때문이다. 그러나 제안된 trained selection agent는 temperature scaling에 덜 영향을 받으며, 두 가지 경우에는 더 다양한 샘플 풀로 성능이 향상되기도 했다.

(a) 각 방법(Query Plan, Synthetic Example, Divide and Conquer)이 최소한 하나의 올바른 후보를 생성한 인스턴스 수를 보여주는 벤 다이어그램. 겹치는 영역은 여러 방법이 올바른 후보를 생성한 경우를 나타낸다.

Figure 3: SQL generation 방법 비교: 고유하고 겹치는 올바른 답변을 보여주는 벤 다이어그램 (왼쪽) 및 다양한 복잡도 수준에 따른 성능 (오른쪽).

Table 6: BIRD development set에서 두 가지 다른 temperature로 후보 generator가 생성한 후보에 대한 다양한 picking 방법의 성능 비교. QP는 query plan CoT를, DC는 divide and conquer CoT를, OS는 online synthetic example generation 방법을 나타낸다.

4.5 Ablation Studies

이전 섹션에서는 **선택 에이전트(selection agent)**와 각 **후보 생성 방법(candidate generation method)**의 중요성을 평가했다. 다음으로, 우리는 CHASE-SQL의 나머지 구성 요소인 값 검색을 위한 LSH, 쿼리 fixer, 그리고 세 가지 추론 전략(QP, OS, DC) 분석에 초점을 맞춘다. Table 7은 이러한 각 단계가 없을 때의 CHASE-SQL 성능을 보여주며, 더 높은 품질의 성능을 달성하는 데 있어 이들의 중요성을 강조한다. 결과는 각 구성 요소의 기여도를 입증하는데, LSH, 쿼리 fixer, 또는 어떤 후보 생성기라도 제거하면 실행 정확도(execution accuracy)가 감소하여, CHASE-SQL의 이러한 구성 요소들이 중요함을 다시 한번 확인시켜준다. 또한, 이 표는 우리의 이진 선택 에이전트(binary selection agent) 성능을 **두 가지 다른 선택 방법(self-consistency (Wang et al., 2022) 및 ranker agent)**과 비교한다. ranker agent는 우리의 세 가지 후보 생성기가 생성한 모든 후보들을 단일 prompt로 입력받아 비교하고, 각각에 대한 순위(ranking)를 생성한다. ranker agent의 경우, 우리는 가장 낮은 순위의 쿼리를 최적의 답변으로 선택한다. 이진 선택 에이전트는 self-consistency 및 ranker agent 모두를 크게 능가하며, 제안된 방법의 효과를 입증한다.

5 Conclusion

우리는 **테스트 시점 연산(test-time compute)**을 활용하여 다양하고 고품질의 SQL 쿼리를 생성하고 정확한 쿼리를 선택하는 새로운 에이전트 프레임워크인 CHASE-SQL을 소개한다. 우리는 다양한 chain-of-thought prompting 방법과 온라인 합성 예시 생성 기법, 그리고 쌍별 비교(pairwise comparison)를 기반으로 후보 쿼리에 점수를 매기는 쿼리 선택 메커니즘을 제안한다.
우리의 프레임워크인 CHASE-SQL은 (제출 당시) 주목할 만한 공개 Text-to-SQL 리더보드에서 새로운 state-of-the-art를 달성하며, 다양한 쿼리 생성과 가장 정확한 응답 선택 모두에서 테스트 시점 연산의 효과를 입증한다. CHASE-SQL은 쿼리 다양성 및 선택 최적화와 같은 주요 문제들을 해결하여, 실제 Text-to-SQL 과제에서 발생하는 복잡한 추론 task의 추가적인 개선을 위한 길을 열어준다.

Table 7: 쿼리 fixer, LSH for value retrieval, 그리고 추론 전략(QP, OS, DC)을 제거한 후 CHASE-SQL 성능에 대한 ablation study.

Acknowledgments

Per Jacobsson, Raj Sinha, Zeke Miller, Reza Sherkat, James Su, Zhixian Yan, David Culler, Xiance Si에게 본 논문에 대한 귀중한 의견과 피드백을 주신 것에 대해 감사드린다. 또한 BIRD test set 평가에 귀중한 도움을 주신 BIRD 팀에게도 감사드린다.

A Appendix

A. 1 Related works

이전에 논의했듯이, Text-to-SQL 성능을 향상시키는 한 가지 접근 방식은 **LLM 응답의 일관성(consistency)**에 기반한다. Wang et al. (2022)이 제안한 self-consistency 접근 방식은 LLM으로부터 여러 응답을 샘플링하고 **다수결 투표(majority vote)**를 기반으로 가장 일관된 답변을 선택하는 것을 포함한다. Text-to-SQL 맥락에서 이 기술은 주어진 질문에 대해 여러 SQL 쿼리를 생성하고, 이 쿼리들을 **실행 결과(execution results)**에 따라 그룹화한 다음, 가장 큰 클러스터에서 쿼리를 선택하여 가장 일관된 답변으로 간주하는 방식으로 확장된다 (Gao et al., 2023; Sun et al., 2023; Talaei et al., 2024). 그러나 최근 연구들은 이 방법이 정답을 안정적으로 식별하는 데 한계가 있음을 지적했다. 이에 대응하여, MCS-SQL (Lee et al., 2024)은 단순한 다수결 투표를 넘어 LLM을 활용하여 가장 일관된 답변을 재순위화(rerank)하는 접근 방식을 도입했다. 이러한 발전에도 불구하고, 일관성에 대한 의존이 필터링 메커니즘으로 작용할 경우, 생성된 후보들 중에서 덜 빈번하게 나타나는 올바른 쿼리를 의도치 않게 제외할 수 있다는 점이 중요한 병목 현상으로 지적된다.

A. 2 Models

모든 실험은 긴 문맥 정보를 처리하는 능력으로 알려진 Gemini 및 Claude 모델을 사용하여 수행되었다 (Maamari et al., 2024). 이러한 능력은 대규모 데이터베이스 쿼리를 포함하는 Text-to-SQL task에 매우 중요하다.
candidate generation, online synthetic example generation, query fixing, column filtering, keyword extraction에 대해서는 Gemini 1.5 Pro와 Claude-3.5-Sonnet 모델의 성능을 보고하였다.
query-picking 모델의 경우, BIRD 학습 데이터셋에 대해 candidate generator를 실행하여 생성된 3.8K 샘플 데이터셋으로 Gemini 1.5 Flash 모델을 학습시켰다 (이 모델은 Gemini 1.5 Pro 모델보다 훨씬 낮은 latency를 가진다). Gemini 1.5 Flash 모델은 Vertex AI tuning API를 사용하여 **LoRA adapter(rank 16)**로 10 epoch 동안 학습되었다.

A. 3 Performance Based On Database

이 섹션에서는 BIRD 개발 세트 데이터베이스에서 각 후보 generator 방법의 성능에 대한 상세한 분석을 제공한다.

Figure 4: BIRD 개발 세트의 다양한 데이터베이스에서 각 방법에 따른 올바른 쿼리 수.

A. 4 Error Analysis

Figure 5: 최종 답변 정확도를 기반으로 한 시스템 성능 분포. 이 차트는 올바른 최종 답변의 비율, 후보군에 존재하지만 선택되지 않은 올바른 쿼리(잘못된 선택), 올바른 후보가 없는 경우, 그리고 golden SQL 쿼리가 잘못된 경우를 보여준다.

Figure 5는 시스템 성능을 네 가지 범주로 분류한 원형 차트를 제공한다:

• 올바른 최종 답변 (72.9%)
• 후보군에 올바른 쿼리가 존재하지만 선택되지 않은 경우 (10.4%)
• 잘못된 생성 또는 올바른 후보가 없는 경우 (6.7%)
• golden 쿼리가 잘못된 경우 (10.0%)

대부분의 응답은 올바른 최종 답변이지만, 상당 부분은 올바른 답변이 시스템에 의해 선택되지 않은 경우에 해당한다. 이러한 분류는 시스템이 뛰어난 부분과 개선이 필요한 부분을 이해하는 데 도움이 된다.

Figure 6: 두 가지 지표에 따른 시스템의 데이터베이스별 정확도 비교: (1) 올바른 쿼리가 후보군에 존재하는 비율, (2) 올바른 쿼리가 선택 에이전트에 의해 선택된 비율.

Figure 6은 여러 데이터베이스에 걸친 시스템 정확도에 대한 비교 분석을 제시한다. x축은 California Schools, Formula 1, Superhero와 같은 다양한 데이터베이스 또는 카테고리를 나열하고, y축은 백분율 성능을 나타낸다. 두 가지 주요 지표가 시각화되어 있다:

• 첫 번째는 올바른 답변이 후보군에 존재하는 비율 (각 카테고리당 하나의 막대로 표시됨)
• 두 번째는 올바른 답변이 선택 시스템에 의해 선택된 비율 (각 카테고리당 두 번째 막대로 표시됨)

A.4.1 Selection Agent Error Analysis

이 섹션에서는 세 가지 generator 중 적어도 하나가 생성한 후보 SQL 쿼리가 ground truth 답변과 일치했지만, selection agent가 다른 잘못된 후보에 가장 높은 점수를 할당한 경우를 살펴본다. 우리는 이러한 오류를 네 가지 그룹으로 분류했다: (1) 모호한 질문 (Vague questions), (2) 잘못된 선택 (Wrong picking), (3) 데이터 무결성 오류 (Data Integrity Error), (4) 잘못된 gold 쿼리 (Incorrect gold query). Fig. 7은 샘플 쿼리들 사이에서 각 카테고리의 분포를 보여준다. 다음 섹션에서는 이들 각 카테고리에 대해 더 자세히 논의할 것이다.

Figure 7: selection agent가 후보들 중 올바른 SQL 쿼리를 선택하지 못한 경우에 대한 오류 분석.

잘못된 선택 오류 (Wrong Picking Errors): 오류의 가장 큰 부분은 selection agent로부터 가장 높은 점수를 받은 후보가 필수적인 column, table 또는 SQL clause를 누락한 경우에 발생한다. 우리의 분석에서, 모델의 실수에서 특정 유형의 패턴을 식별할 수 없었는데, 이는 이러한 실수들이 거의 모든 인스턴스에서 다양한 유형의 오류를 포함하기 때문이다. Fig. 8은 선택된 SQL 쿼리가 ground truth 답변에서 지정된 대로 id만 반환하는 대신, 모든 column을 반환하기 위해 *를 잘못 사용하는 예시를 제공한다.

Question: List all patients who were followed up at the outpatient clinic
who underwent a laboratory test in October 1991 and had a total blood
bilirubin level within the normal range.
Evidence: followed up at the outpatient clinic refers to Admission = '-';
laboratory test in April 1981 refers to Date like '1991-10%'; blood bilirubin
level within the normal range refers to T-BIL < 2.0;
Gold SQL: SELECT DISTINCT T1.ID FROM Patient AS T1 INNER JOIN Laboratory
AS T2 ON T1.ID = T2.ID WHERE T1.Admission = '-' AND T2.'T-BIL` < 2.0 AND
T2.Date LIKE '1991-10-%'
Picked SQL: SELECT DISTINCT T1.* FROM Patient AS T1 INNER JOIN
Laboratory AS T2 ON T1.ID = T2.ID WHERE T1.Admission = '-' AND T2.'T-BIL`<
2.0 AND T2.Date LIKE '1991-10%'

Figure 8: selection agent가 선호했지만 잘못된 SQL 쿼리의 예시.

잘못된 Golden Query 오류 (Wrong Golden Query Error): 오류의 두 번째로 큰 부분은 ground truth SQL 쿼리가 잘못되었고, 우리 모델이 생성한 후보 쿼리 중 하나가 동일한 실수를 반복하는 경우에 발생한다. 그러나 selection agent는 궁극적으로 질문에 올바르게 답변하는 다른 후보를 선택한다. Fig. 9는 이러한 경우의 예시를 제공하는데, ground truth 쿼리가 질문에 지정되지 않은 추가 molecule_ID column을 SELECT clause에 포함하고 있다.

Question: What are the labels for TROOO, TROO1 and TROO2?
Evidence: TROOO, TR001 and TR002 are molecule id; label = '+' mean
molecules are carcinogenic; label = '-' means molecules are non-
carcinogenic
Gold SQL: SELECT molecule_id, T.label FROM molecule AS T WHERE
T.molecule_id IN ('TROOO', 'TROO1', 'TROO2')
Picked SQL: SELECT label FROM molecule WHERE molecule_id IN ('TROOO',
'TR001', 'TR002')

Figure 9: selection agent가 올바른 SQL 쿼리를 선택했지만 gold 쿼리가 잘못된 오류 사례의 예시.

모호한 질문 (Vague Question): 또 다른 상당 부분의 오류는 질문이 반환하거나 필터링에 사용할 column을 지정하지 않고, 여러 column이 쿼리를 만족시킬 수 있는 경우에 발생한다. 이러한 경우, 후보 중 하나가 올바른 SQL 쿼리였음에도 불구하고, selection model은 역시 올바르다고 간주될 수 있는 다른 응답을 선호했다. Fig. 10은 "Fresno"가 도시 또는 카운티를 지칭할 수 있지만, 질문이 어느 것을 반환해야 하는지 지정하지 않는 경우를 보여준다. selection model은 "city"를 사용한 쿼리를 선택하고 "county"를 사용한 후보를 선택하지 않았다.

Question: How many schools in Fresno (directly funded) have number of
test takers not more than 250?
Evidence:
Gold SQL: SELECT COUNT(T1.CDSCode) FROM frpm AS T1 INNER JOIN
satscores AS T2 ON T1.CDSCode = T2.cds WHERE T1.'Charter Funding Type` =
'Directly funded' AND T1. County Name = 'Fresno' AND T2.NumTstTakr <=
2 5 0
Picked SQL: SELECT COUNT(T1.CDSCode) FROM schools AS T1 INNER JOIN
satscores AS T2 ON T1.CDSCode = T2.cds WHERE T1.City = 'Fresno' AND
T1.FundingType = 'Directly funded' AND T2.NumTstTakr <= 250

Figure 10: 질문이 모호하여 selection model이 올바르다고 간주될 수 있는 쿼리를 선택한 오류 사례의 예시.

데이터 무결성 오류 (Data Integrity Error): 마지막으로, 가장 작은 오류 범주는 두 개 이상의 column이 일관된 값을 가져야 하지만, 하나 이상의 column에 누락된 값이 포함된 경우이다. 예를 들어, Fig. 11은 "School" 및 "School Name" column이 모두 학교 이름을 포함해야 하지만, 한 column에 누락된 값이 있는 경우를 보여준다.

A.4.2 Error Analyses

우리는 생성된 후보 쿼리 중 올바른 것이 하나도 없는 경우의 3분의 1에 대해 수동 오류 분석을 수행했다. 이 오류들을 다섯 가지 주요 유형으로 분류했다: (1) Schema linking errors, (2) Incorrect logic, (3) SQL function errors, (4) JOIN issues, (5) Ignoring evidence. Figure 12는 이러한 오류 범주의 분포를 보여준다. 보시다시피, 가장 흔한 오류는 질문에 답하는 데 필요한 컬럼이나 테이블을 후보 쿼리 중 어느 것도 올바르게 사용하지 못했을 때 발생한다. 다음 섹션에서는 각 범주에 속하는 특정 오류 유형을 설명한다.

Figure 11: 선택 에이전트가 올바른 후보를 선택했지만, 데이터 불일치로 인해 해당 후보의 실행 정확도가 0이 된 오류 사례의 예시.

Figure 12: 모든 후보 생성기가 단 하나의 올바른 답도 생성하지 못한 경우에 대한 오류 분석.

Schema Linking Errors: Schema linking errors 범주에는 생성된 후보 SQL 쿼리 중 어느 것도 질문에 답하는 데 필요한 컬럼을 올바르게 사용하지 못한 경우가 포함된다. 이러한 오류는 종종 컬럼 이름이 모호하거나 모델에게 혼란스러운 데이터베이스에서 발생한다. Figure 13은 LLM이 예상되는 올바른 컬럼을 반환하기 위해 평균을 올바르게 계산하지 못한 예시를 보여준다.

Figure 13: Schema linking error 범주의 예시.

Wrong Logic Error: 오류의 두 번째로 큰 부분을 차지하는 이 범주에는 생성된 후보 쿼리의 논리가 잘못된 경우가 포함된다. 이러한 오류에는 DISTINCT 키워드, NOT NULL 조건, SELECT 절의 누락된 컬럼, 또는 WHERE나 HAVING 절의 잘못되거나 누락된 조건과 같은 요소들이 포함된다. Figure 14에 예시가 나와 있는데, LLM이 평균 총 가격을 계산하는 논리가 잘못되어 평균 총 가격을 올바르게 계산하지 못한 경우를 보여준다.

Question: 체코 공화국의 주유소에서 발생한 거래의 평균 총 가격은 얼마입니까?
Evidence: 체코 공화국의 주유소는 Country = 'CZE'를 의미합니다.
Gold SQL: SELECT AVG(T1.Price) FROM transactions_1k AS T1 INNER JOIN
gasstations AS T2 ON T1.GasStationID = T2.GasStationID WHERE T2.Country
= 'CZE'
Random Candidate SQL: SELECT AVG(T1.Amount * T1.Price) FROM
transactions_1k AS T1 INNER JOIN gasstations AS T2 ON T1.GasStationID =
T2.GasStationID WHERE T2.Country = 'CZE'

Figure 14: Wrong logic error 범주의 예시.

SQL Functions Error: 세 번째로 큰 오류 원인인 이 범주에는 COUNT(), CAST(), AVG(), ROUND() 등과 같은 SQL 함수를 잘못 사용하거나 포함하지 않아 발생하는 오류 쿼리가 포함된다. Figure 15는 후보 쿼리 중 어느 것도 질문에서 요구하는 ROUND() 함수를 사용하지 못한 경우를 보여준다.

Joins Error: 이 범주는 오류 사례 중 작은 부분을 차지하며, 예측된 SQL 쿼리의 JOIN 절에 하나 이상의 테이블이 누락되어 오류가 발생하는 경우이다.

Ignoring Evidence Error: 이 범주는 오류 사례 중 가장 작은 부분을 차지하며, 제공된 evidence에 올바른 컬럼이나 테이블이 명시적으로 언급되어 있음에도 불구하고 LLM이 이를 무시하고 자체적인 선택을 사용한 경우이다.

A. 5 Divide and Conquer Prompt

이 섹션에서는 divide-and-conquer prompt의 예시를 제공하여, few-shot in-context learning 시연 중 하나에서 분해(decomposition) 및 통합(aggregation) 단계를 설명한다.

Figure 15: SQL 함수 오용 오류 범주의 예시.

divide-and-conquer CoT 접근 방식만이 문제를 해결한 질문/SQL 쌍의 예시이다.

Database Info {DATABASE_SCHEMA}

---

Question Question: What is the gender of the youngest client who opened account in the lowest average salary branch? Hint: Given that Later birthdate refers to younger age; A11 refers to average salary

---

1. Divide and Conquer:

• Main Question: 가장 낮은 평균 급여 지점에서 계좌를 개설한 가장 어린 고객의 성별은 무엇인가?
• Analysis: 'gender'에 대한 질문이며, 'client' 테이블에 나타난다. 가장 낮은 평균 급여 지점의 가장 어린 고객으로부터 이를 출력 컬럼으로 선택할 것이다.
• Pseudo SQL: SELECT 'T1'.'gender' FROM 'client' AS 'T1' WHERE 가장 낮은 평균 급여 지점의 가장 어린 고객
• Sub-question 1: 가장 낮은 평균 급여 지점의 가장 어린 고객
• Analysis: 힌트에 따르면, 급여 정보를 얻기 위해 'district' 테이블의 'A11'을 사용해야 하며, 가장 어린 고객은 'client' 테이블의 'birth_date' 컬럼을 사용하여 얻을 수 있다. 이 두 테이블 간의 항목은 'district_id'를 사용하여 INNER JOIN할 수 있다.
• Pseudo SQL: SELECT 'T1'.'client_id' FROM 'client' AS 'T1' INNER JOIN 'district' AS 'T2' ON 'T1'.'district_id' = 'T2'.'district_id' WHERE 가장 낮은 평균 급여 지점 ORDER BY 'T1'.'birth_date' DESC NULLS LAST LIMIT 1
• Sub-question 1.1: 가장 낮은 평균 급여 지점
• Analysis: 'A11'을 ASC로 정렬하고 상위 1개를 선택하여 가장 낮은 평균 급여 지점을 얻을 수 있다. 'A11' 컬럼은 NULLABLE이 아니므로 "IS NOT NULL" 필터를 추가할 필요가 없다.
• Pseudo SQL: SELECT 'district_id' FROM 'district' ORDER BY 'A11' ASC LIMIT 1 2. Assembling SQL:
• Sub-question 1.1 (가장 낮은 평균 급여 지점):
• SQL: SELECT 'district_id' FROM 'district' ORDER BY 'A11' ASC LIMIT 1
• Sub-question 1 (가장 낮은 평균 급여 지점의 가장 어린 고객):
• SQL: SELECT 'T1'.'client_id' FROM 'client' AS 'T1' INNER JOIN 'district' AS 'T2' ON 'T1'.'district_id' = 'T2'.'district_id' WHERE 'T2'.'district_id' IN (SELECT 'district_id' FROM 'district' ORDER BY 'A11' ASC LIMIT 1) ORDER BY 'T1'.'birth_date' DESC NULLS LAST LIMIT 1
• Main Question (고객의 성별):
• SQL: SELECT 'T1'.'gender' FROM 'client' AS 'T1' WHERE 'T1'.'client_id' = (SELECT 'T1'.'client_id' FROM 'client' AS 'T1' INNER JOIN 'district' AS 'T2' ON 'T1'.'district_id' = 'T2'. 'district_id' WHERE 'T2'.'district_id' IN (SELECT 'district_id' FROM 'district' ORDER BY 'A11' ASC LIMIT 1) ORDER BY 'T1'.'birth_date' DESC NULLS LAST LIMIT 1) 3. Simplification and Optimization:
• 중첩된 쿼리는 단일 'INNER JOIN'을 사용하여 결합할 수 있으며, 필터링은 단일 'ORDER BY' 절 내에서 수행할 수 있다. Final Optimized SQL Query: SELECT 'T1'.'gender' FROM 'client' AS 'T1' INNER JOIN 'district' AS 'T2' ON 'T1'.'district_id' = 'T2'.'district_id' ORDER BY 'T2'.'A11' ASC, 'T1'.'birth_date' DESC NULLS LAST LIMIT 1

Figure 16: divide and conquer CoT 방식의 예시.

Question: How much faster in percentage is the champion than the driver
who finished the race last in the 2008 Australian Grand Prix?
Query:
WITH time_in_seconds AS (
    SELECT
        T1.positionOrder,
            CASE
                WHEN T1.positionOrder = 1 THEN
                    (CAST(SUBSTR(T1.time, 1, 1) AS REAL) * 3600) +
                    (CAST(SUBSTR(T1.time, 3, 2) AS REAL) * 60) *
                    CAST(SUBSTR(T1.time, 6) AS REAL)
                ELSE
                        CAST(SUBSTR(T1.time, 2) AS REAL)
            END AS time_seconds
        FROM
            ROM
            results AS T1
        INNER JOIN
                races AS T2
                ON T1.raceld = T2.raceld
        WHERE
                T2.name = 'Australian Grand Prix'
                AND T1.time IS NOT NULL
                    AND T2.year = 2008
),
ampion_time AS (
        SELECT time_seconds
        FROM time_in_seconds
        WHERE positionOrder = 1
),
last_driver_incremental AS (
        SELECT time_seconds
        FROM time_in_seconds
        WHERE positionOrder = (
        WHERE positionOrder = (
            SELECT MAX(positionOrder)
            FROM time_in_seconds
    )
)
SELECT
    (CAST((SELECT time_seconds FROM last_driver_incremental) AS REAL) *
100) /
    (SELECT time_seconds +
            (SELECT time_seconds FROM last_driver_incremental)
        FROM champion_time);

Figure 17: divide and conquer CoT 방식으로만 해결된 쿼리의 예시.

A. 6 Query Plan Prompt

이 섹션에서는 단계를 설명하기 위해 few-shot in-context learning demonstration 중 하나에서 사용된 쿼리(실행) 계획 prompt 예시를 제공한다.

Figure 18: 쿼리 계획 CoT(Chain-of-Thought) 방식의 예시

Figure 19는 EXPLAIN 명령어를 사용하여 생성된 쿼리 계획의 예시를 제공한다.

Figure 19: EXPLAIN 명령어를 사용하여 생성된 SQLite 쿼리 계획의 예시.

또한 Figure 20은 쿼리 계획 기반 CoT 전략을 사용하여 해결된 질문의 예시를 제공한다.

Figure 20: 쿼리 계획 CoT 방식으로만 해결된 쿼리의 예시.

A. 7 Query Fixing Prompt

이 섹션에서는 SQL 쿼리 수정 단계에 사용되는 prompt template을 제공한다.

Task Description:
당신은 SQL 데이터베이스 전문가로서 SQL 쿼리를 수정하는 임무를 맡았다. 이전에 실행된 쿼리가 실행 오류로 인해, 또는 반환된 결과가 비어 있거나 예상과 달라서 올바른 결과를 내지 못했다. 당신의 역할은 제공된 데이터베이스 스키마와 실패한 실행의 세부 정보를 바탕으로 오류를 분석하고, 수정된 SQL 쿼리 버전을 제공하는 것이다.

Procedure:

1. 데이터베이스 스키마 검토:

   • 테이블 생성 구문을 검토하여 데이터베이스 구조를 이해한다.

2. 쿼리 요구사항 분석:

   • 원래 질문(Original Question): 쿼리가 어떤 정보를 검색해야 하는지 고려한다.
   • 힌트(Hint): 쿼리와 관련된 관계 및 조건을 이해하기 위해 제공된 힌트를 사용한다.
   • 실행된 SQL 쿼리(Executed SQL Query): 이전에 실행되어 오류나 잘못된 결과를 초래한 SQL 쿼리를 검토한다.
   • 실행 결과(Execution Result): 실행된 쿼리의 결과를 분석하여 실패 원인(예: 구문 오류, 잘못된 열 참조, 논리적 오류)을 식별한다.

3. 쿼리 수정:

   • 식별된 문제를 해결하기 위해 SQL 쿼리를 수정하고, 데이터베이스 스키마 및 쿼리 요구사항에 따라 요청된 데이터를 올바르게 가져오는지 확인한다.

Output Format:
수정된 쿼리를 Final Answer 뒤에 단일 SQL 코드 라인으로 제시한다. 쿼리 내에 줄 바꿈이 없도록 한다.

다음은 몇 가지 예시이다:
{EXAMPLES}
======= Your task ========
***************************
Table creation statements
{DATABASE_SCHEMA}
***************************
The original question is:
Question:
{QUESTION}
Evidence:
{HINT}
The SQL query executed was:
{QUERY}
The execution result:
{RESULT}
***************************
Based on the question, table schema and the previous query, analyze the result try to fix the query.

Figure 21: 쿼리 수정 단계에 사용된 prompt template

A. 8 Selection Agent Prompt

이 섹션에서는 학습된 selection agent가 학습 시 및 테스트 시 쿼리 선택에 사용하는 prompt template을 제공한다. 이 단계에서 사용되는 데이터베이스 스키마는 데이터베이스의 모든 테이블에 대한 전체 스키마를 사용하는 대신, 두 후보 쿼리에 의해 사용되는 컬럼과 테이블의 합집합이라는 점에 유의하라.

Instruction:
Given the DB info and question, there are two candidate queries. There is correct one and incorrect one,
compare the two candidate answers, analyze the differences of the query and the result. Based on the
original question and the provided database info, choose the correct one.
****************************
Database Schema
{DATABASE_SCHEMA}
***************************
Question:
{QUESTION}
Evidence:
{HINT}
***************************
Candidate A
{CANDIDATE_A_QUERY}
Execution result
{CANDIDATE_A_RESULT}
****************************
Candidate B
{CANDIDATE_B_QUERY}
Execution result
{CANDIDATE_B_RESULT}
Just output the correct answer "A" or "B".

Figure 22: 쿼리 수정(query fixing)에 사용된 prompt template

A. 9 Generated Synthetic Examples Analysis

(a) 다양한 특성에서 합성 예시(synthetic examples)와 실제 예시(ground truth examples)의 분포(정규화됨). 예시들은 BIRD-Bench dev 데이터셋의 질문과 스키마를 기반으로 생성되었다.

Question: Alameda County에 있는 학교의 K-12 학생들을 위한 가장 높은 적격 무료 급식률은 얼마입니까? SQL: SELECT Free Meal Count (K-12)/‘Enrollment (K-12) FROM frpm County Name' = 'Alameda' DEER BY (CAST('Free Meal Count (K-12) AS REAL) / 'Enrollment (K-12)') DESC LIMIT 1

Common SQL feature 예시: input: 평균 SAT 수학 점수가 600점 이상인 학군의 학교들의 총 등록 학생 수는 얼마입니까? output: SELECT SUM(T2.'Enrollment(K-12)`) FROM satscores AS T1 INNER JOIN frpm AS T2 ON T1.cds = T2.CDSCode WHERE T1.AvgScrMath > $\mathbf{600}$

필터링된 컬럼을 사용한 간단한 예시: input: Alameda County에 있는 학교들의 'Enrollment (K-12)' 평균은 얼마입니까? output: SELECT AVG('Enrollment(K-12)') FROM frpm WHERE 'County Name' = 'Alameda' input: Alameda County에 있는 학교 중 'Free Meal Count (K-12)'가 가장 높은 학교는 어디입니까? output: SELECT School FROM schools AS T1 INNER JOIN frpm AS T2 ON T1.CDSCode = T2.CDSCode WHERE T1.County = 'Alameda' ORDER BY T2.'Free Meal Count (K-12) DESC LIMIT 1 (b) 'california_schools' 데이터베이스 질문에 대해 common SQL feature 및 filtered columns에 대한 다양한 가이드라인으로 생성된 합성 예시.

Fig. 23a는 BIRD dev 데이터셋에 대해 생성된 합성 예시의 SQL feature 분포를 보여주며, 이는 CASE statement를 제외하고 실제 SQL feature 분포와 매우 유사하다. 우리는 CASE statement 예시를 생략했는데, 이는 실제 ground-truth SQL 쿼리가 CASE statement를 사용하지 않는 한, CASE statement 예시를 보여주는 것이 생성에 도움이 되지 않았기 때문이다. Fig. 23b는 BIRD dev 데이터셋의 질문 $q_i$와 그에 연결된 데이터베이스에 대해 생성된 입력 질문 및 출력 SQL 쿼리 쌍 예시를 보여준다.

Table 8: 합성 예시 생성 가이드라인에 대한 Ablation study. $R_f$는 common SQL feature를, $R_t$는 filtered schema를 사용한다. Baseline은 BIRD prompt Zero-shot CoT with Gemini 1.5 pro on the BIRD dev set이다. 각 예시 세트($R_f$, $R_t$) 및 혼합($R_f+R_t$)에 대해 총 75개의 예시가 생성되었다.

Table 8은 다양한 가이드라인과 그에 따라 생성된 예시 세트를 사용한 ablation study를 보여준다. Baseline(예시 없음)과 비교했을 때, 사용자 질문과 관련된 데이터 스키마를 대상으로 하는 합성 예시가 도움이 될 수 있음을 알 수 있다. 우리는 출력이 특정 패턴에 과적합되는 것을 방지하기 위해(예: 대부분 JOIN 예시를 보여주면 모델이 항상 JOIN이 포함된 SQL을 작성하는 경우) 예시의 다양성을 촉진하려고 노력한다.

A. 10 Synthetic Example Generation Prompts

이 섹션에서는 온라인 합성 예시 생성 단계에 사용된 prompt 템플릿을 제공한다.

당신은 SQLite SQL 전문가이다. 당신의 임무는 $\{\mathrm{k}\}$개의 예시를 생성하는 것이며, 각 예시는 질문과 해당 질문에 대한 데이터를 가져오는 SQL 쿼리로 구성된다. 각 예시는 다음과 같은 질문 입력 및 SQL 출력 쌍의 형태를 가져야 한다: "input": "아루바의 시리즈 코드 SM.POP.TOTL에 대한 설명은 무엇인가요? (힌트: 아루바는 ShortName = 'Aruba'인 국가의 이름입니다)" "output": "SELECT T2.Description FROM Country AS T1 INNER JOIN CountryNotes AS T2 ON T1.CountryCode = T2.Countrycode WHERE T1.ShortName = 'Aruba' AND T2.Seriescode = 'SM.POP.TOTL'" 당신은 "Table creation statements"에 설명된 다음 테이블 스키마의 다양한 측면과 관계를 조사하고 보여주는 예시를 생성해야 한다. 데이터베이스 테이블과 그 관계를 이해하고, 흥미로운 예시를 구성하기 위해 열(column)과 그 유형 및 의미를 이해해야 한다. 다음과 같은 SQL 예시들을 혼합하여 생성하라:

• JOIN이 없는 간단한 SQL 쿼리 예시
• COUNT와 같은 집계 함수를 포함하는 SQL 쿼리 예시
• JOIN이 있는 간단한 SQL 쿼리 예시
• 중첩 JOIN이 있는 복잡한 SQL 쿼리 예시

---

테이블 생성 구문 {TARGET_DATABASE_SCHEMA}

---

총 $\{\mathrm{k}\}$개의 예시를 생성하라. 예시(질문 입력 및 SQL 출력 쌍)만 출력하고, 각 예시는 새 줄로 구분될 수 있다.

Figure 24: 일반적인 SQL 기능 예시 생성을 위해 사용된 합성 예시 생성 prompt. TARGET_DATABASE_SCHEMA는 대상 데이터베이스의 모든 테이블을 포함한다.

당신은 SQLite SQL 전문가이다. 당신의 임무는 예시 세트를 생성하는 것이며, 각 예시는 질문과 해당 질문에 대한 데이터를 가져오는 SQL 쿼리로 구성된다. 당신은 다음 테이블 스키마의 다양한 측면과 관계를 조사하고 보여주는 예시를 생성해야 한다. 데이터베이스 테이블과 그 관계를 이해하고, 흥미로운 예시를 구성하기 위해 열(column)과 그 유형 및 의미를 이해해야 한다. 또한, 다른 데이터베이스와 그 테이블 스키마에 대해 생성된 여러 예시를 보여줄 것이므로, 주어진 데이터베이스에 대해 어떤 종류의 예시를 생성할 수 있는지 확인할 수 있다.

---

###다른 데이터베이스의 예시### 다음은 다른 데이터베이스의 테이블 스키마 및 열 예시이다: 데이터베이스 ($\tilde{\{ }$ TRAIN_DATABASE_NAME $\}$ ) 구조는 다음 테이블 스키마에 의해 정의된다 (주석 '-' 뒤는 추가 열 설명). {TRAIN_DATABASE_SCHEMA}

다음은 위 데이터베이스 스키마에 대해 생성된 예시이다: 예시 1) "input": "부채가 많은 빈곤국 그룹에 속하는 국가들 중, 국제 개발 협회(International Development Associations)의 대출 범주에 속하는 국가는 몇 개인가요? (힌트: 부채가 많은 빈곤국 그룹은 OtherGroups = 'HIPC'; 국제 개발 협회는 lendingcategory = 'IDA'를 의미합니다)" "output": "SELECT COUNT(CountryCode) FROM Country WHERE LendingCategory = 'IDA' AND OtherGroups = 'HIPC'" ... 예시 10) "input": "1990년 아루바의 시리즈 코드 AG.LND.FRST.K2에 대한 각주 설명은 무엇인가요? (힌트: 연도 = 1990; 아루바는 ShortName = 'Aruba'인 국가의 이름입니다)" "output": "SELECT T2.Description FROM Country AS T1 INNER JOIN FootNotes AS T2 ON T1.CountryCode = T2.Countrycode WHERE T1.ShortName = 'Aruba' AND T2.Seriescode = 'AG.LND.FRST.K2' AND T2.Year = 'YR1990'" 이제 유사하게, 아래 "Table creation statements"에 정의된 테이블 스키마에 대한 예시(질문 입력 및 SQL 출력 쌍)를 생성하라.

---

###테이블 생성 구문### TARGET_DATABASE_SCHEMA

---

예시(질문 입력 및 SQL 출력 쌍)만 출력하고, 각 예시는 새 줄로 구분될 수 있다.

Figure 25: 합성 예시 생성 prompt. 이는 열 선택 결과로 필터링된 TARGET_DATABASE_SCHEMA를 사용하며, 모델은 훈련 데이터셋(테스트 또는 개발 데이터셋과 별개)에서 가져온 것과 유사한 간단한 예시를 생성하도록 요청받는다.