CHASE-SQL：别只生成一个 SQL
CHASE-SQL：别只生成一个 SQL
这篇论文的核心很直观：复杂数据库问题里，LLM 第一次写出的 SQL 不一定最好。CHASE-SQL 让模型从多条思路生成候选 SQL，再用训练过的选择器两两比较，挑出最可能正确的一条。
CHASE-SQL 做的不是“更会写一次 SQL”，而是“多写几种，再认真挑”。
传统 Text-to-SQL 常常让 LLM 生成一条 SQL，或者采样多条后用 self-consistency 选出现次数最多的执行结果。CHASE-SQL 认为这不够：最常见的答案不一定正确，尤其是复杂查询里，少数候选反而可能是对的。
多路径生成
用三种不同策略生成候选 SQL：Divide-and-Conquer CoT、Query Plan CoT、Online Synthetic Examples。
修复候选
对语法错误、空结果等候选 SQL 做 LLM-based query fixer，最多迭代修复三次。
偏好选择
不用简单多数投票，而是训练 binary selection model，两两比较候选 SQL，累计得分最高者胜出。
为什么不能只用 self-consistency？因为“多数一致”不等于“正确”。
论文在 BIRD dev 上展示：单条生成是 63.01% EX，self-consistency 提到 68.84%，但如果能从候选池里总是选中正确 SQL，上界能到 82.79%。这个巨大差距说明：候选池里常常已经有正确答案，真正难的是把它挑出来。
只生成一条 SQL 的基线。
按执行结果聚类，选择最大簇。
如果选择器足够强，理论提升空间很大。
完整流程可以看成四步：找值、生成、修复、选择。
Value retrieval
先从问题里抽关键词，再用 LSH、embedding similarity 和 edit distance 找数据库中的相关值。
Candidate generators
三条不同推理路径生成候选 SQL，增加“至少有一条正确”的概率。
Query fixer
用错误信息、空结果等反馈反思并修复候选 SQL。
Selection agent
训练过的选择器两两比较候选，最终选累计得分最高的 SQL。
CHASE-SQL(question, database): values = retrieve_values(question, database) candidates = [] candidates += divide_and_conquer_cot(question, schema, values) candidates += query_plan_cot(question, schema, values) candidates += online_synthetic_examples(question, schema, values) fixed = query_fixer(candidates) final_sql = pairwise_selection_agent(fixed) return final_sql
三条生成路径各有擅长，不是简单重复采样。
CHASE-SQL 的关键不是“同一个 prompt 多采几次”，而是从不同思考方式出发，让候选 SQL 真正多样化，同时保持质量。
1. Divide-and-Conquer CoT
先把复杂问题拆成子问题，为每个子问题生成 partial SQL，再 assemble 成最终 SQL，并做优化。
适合：嵌套查询、复杂 WHERE/HAVING、多步骤数学计算。
2. Query Plan CoT
让推理过程模仿数据库执行计划：先找相关表，再说明 join/filter/count/match，最后选择返回列。
适合：需要理解表关系、join 路径和过滤操作的问题。
3. Online Synthetic Examples
针对当前问题和数据库，在线生成大量 question-SQL 示例，作为 many-shot context 帮模型理解 schema 和 SQL 结构。
适合：为当前数据库补充定制 few-shot 示例，提升候选多样性。
选择器不是排序所有候选，而是两两比较。
如果一次让模型比较很多候选，它很难稳定判断。CHASE-SQL 把问题改成二分类：给定用户问题、两个候选 SQL 和它们使用的 schema union，让模型判断哪个更可能正确。所有候选两两比较后，累计分最高的 SQL 被选中。
其中 \(r_i\) 是候选 SQL 在两两比较中累计赢得的分数。
| 选择方式 | 直观含义 | 论文观察 |
|---|---|---|
| Self-consistency | 选执行结果最多的一簇。 | 比单条生成好，但会被“多数错答案”误导。 |
| Ranker agent | 一次性把所有候选给模型排序。 | 不如 binary selection，候选太相似时更难判断。 |
| Binary selection agent | 两两比较候选并累计得分。 | CHASE-SQL 的核心优势，显著超过 self-consistency。 |
实验结果：BIRD 上达到 73.0%，Spider 上无需专门调参也有强泛化。
论文报告 CHASE-SQL + Gemini 1.5 Pro 在 BIRD test 上达到 73.0%。
dev 上也达到 73.01%，论文提交时位居 BIRD leaderboard 顶部。
没有使用 Spider 分布专门训练选择器或改 few-shot，仍有很强结果。
| 组件移除 | BIRD dev EX | 下降 | 说明 |
|---|---|---|---|
| CHASE-SQL All | 73.01 | - | 完整系统。 |
| with self-consistency | 68.84 | -4.17 | 多数投票明显不如选择器。 |
| with ranker agent | 65.51 | -7.50 | 一次性排序不如两两比较。 |
| without LSH | 70.09 | -2.92 | 值检索很重要。 |
| without Query Fixer | 69.23 | -3.78 | 修复循环贡献明显。 |
| without DC / OS / QP | 71.77-72.36 | -0.65 到 -1.24 | 三条生成路径都有互补贡献。 |
对你的 skill + MCP 项目，CHASE-SQL 提供的是“候选查询编排 + 验证选择”思路。
AutoLink 和 schema linking 论文关注“先找对字段”；CHASE-SQL 更进一步：字段上下文准备好以后，不要只生成一个查询行为，而是生成多条候选查询计划/SQL，通过执行反馈修复，再让选择器挑最可信的一条。
recommended MCP-style workflow:
1. schema_link(question) # 来自 AutoLink / schema linking 层
2. retrieve_values(question, linked_schema)
3. generate_candidate("divide_conquer")
4. generate_candidate("query_plan")
5. generate_candidate("synthetic_examples")
6. dry_run_and_fix(candidates)
7. pairwise_compare(question, candidate_i, candidate_j)
8. choose_final_query()
9. execute_final_query()
适合做成 MCP tools
`retrieve_values`、`dry_run_sql`、`explain_query`、`fix_sql_with_error`、`execute_limited` 都非常适合由 MCP 连接数据库执行。
适合放在 skill/agent 里
问题拆解、候选生成策略选择、候选比较、最终解释和置信度说明，更适合由 skill 管理上下文和决策。
一句话评价：这是一篇把“多试几条 SQL”做成系统工程的论文。
强项
候选生成路径真的互补，选择器也不是简单投票。论文清楚证明了候选池上界和选择器能力之间的差距。
创新点
把 Text-to-SQL 的 test-time compute 系统化：多路径 reasoning、online synthetic examples、query fixer、pairwise selection agent。
局限
代价较高，需要多次 LLM 调用、候选执行和选择器训练。真实产品要按查询难度动态启用。
和前两篇的关系
AutoLink/Schema Linking Analysis 解决“字段找全”；CHASE-SQL 解决“候选 SQL 生成和选择”。三者组合起来，就是一个更完整的智能问询 pipeline。