XiYan-SQL 全解析：多生成器集成框架如何刷新 Text-to-SQL 准确率
XiYan-SQL 全解析：多生成器集成框架如何刷新 Text-to-SQL 准确率
本文导读：本文以阿里团队提出的 XiYan-SQL 框架为核心，系统拆解其在自然语言转 SQL（NL2SQL/Text-to-SQL）任务上的三大核心组件——Schema Linking、Candidate Generation 与 Candidate Selection，并完整梳理 M-Schema 表示方法、四大数据集上的实验结果与消融验证。读完本文，你将掌握"多生成器 + 选择模型"这一集成式 Text-to-SQL 框架的设计思路、各模块的实现细节，以及它相比纯提示词工程与纯 SFT 方法的差异化优势，可直接用于指导后续 Text-to-SQL 系统的方案选型与架构设计。
XiYan-SQL（论文作者 Yingqi Gao、Yifu Liu 等，来自 Alibaba Group 等）是一个面向 Text-to-SQL 的多生成器集成框架。其核心思想是：结合提示词工程（ICL）的潜力与有监督微调（SFT）的可控性，通过多路生成高质量、多样化的候选 SQL，再由专用选择模型挑选最终答案。在 Bird 开发集、Spider、SQL-Eval、NL2GQL 四类评测基准上，XiYan-SQL 均取得显著领先的准确率，并展现出对关系型与非关系型（图）数据库的通用性。
一、研究背景：为什么现有 NL2SQL 方案仍有短板
将自然语言查询自动转换为结构化查询语言（SQL）的能力，是数据库访问领域的重要进步，它让非专家用户与高级用户都能从大规模数据存储中获得数据洞察。大语言模型（LLM）的进步显著提升了 NL2SQL 的效力与准确性，但现有方案仍面临两类典型挑战：
| 方案路线 | 典型做法 | 主要瓶颈 |
|---|---|---|
| 提示词工程（Prompt Engineering） | 利用模型内在能力，优化提示词生成多样化 SQL | 依赖多路径生成与 self-consistency，推理开销巨大 |
| 有监督微调（SFT） | 在 NL2SQL 任务上微调较小参数的模型，生成更可控的 SQL | 参数量有限，复杂 NL2SQL 推理与跨领域数据库迁移表现不佳 |
XiYan-SQL 的动机正是在于兼取两者之长：用 ICL 释放大模型的生成潜力，用 SFT 保证输出的可控性，从而提升候选 SQL 的质量与多样性。围绕这一目标，论文从四个维度切入：
- 增强对数据库结构的理解：提出 M-Schema——一种半结构化的数据库 schema 表示方法；
- 提升候选 SQL 的质量与多样性：结合 ICL 与 SFT，提出一系列训练策略，微调模型生成高质量且具有不同偏好的候选；
- 优化生成的 SQL：通过 Refiner 纠正候选中的逻辑或语法错误；
- 识别最佳候选：微调一个选择模型，区分候选之间的细微差别，选出最终 SQL。
背景延伸：Text-to-SQL 是检索增强生成（RAG）与大模型应用章节的重要实践方向。本仓库《大模型基础》教材的 第 6 章 检索增强生成 与 第 3 章 Prompt 工程 分别覆盖了知识检索与上下文学习等基础，而 大模型经典论文列表 中亦收录了与 Text-to-SQL 直接相关的经典工作，如跨域数据集 Spider（EMNLP 2018）、基于 ChatGPT 的零样本 Text-to-SQL 方案 C3、面向金融分析的 FinSQL（SIGMOD），以及 XiYan-SQL 中用于候选投票的 Self-Consistency（ICLR 2023）——阅读本文时可对照这些材料补全背景。
二、框架总览：三大组件构成"检索—生成—选择"流水线
XiYan-SQL 由三个主要组件组成，每个组件都有独特的方法与策略，共同保证生成的 SQL 查询既高质量又多样化：
- Schema Linking（模式链接）：将自然语言查询关联到数据库中的表、列与值，为后续生成提供精准、精简的数据库结构上下文；
- Candidate Generation（候选生成）：通过微调生成器与 ICL 生成器生成多路候选 SQL，并由 Refiner 优化；
- Candidate Selection（候选选择）：基于执行结果一致性分组，用微调的选择模型从候选池中挑选最合理的 SQL。
整体上，该流水线先"瘦身"数据库结构、再"广撒网"生成候选、最后"精挑细选"出最终答案，架构上与业界常见的"检索增强 + 多路生成 + 投票/选择"范式一致，但每一步都做了专门的工程化设计。
三、Schema Linking：为生成器提供精准的数据库上下文
Schema Linking 的目的是将自然语言查询关联到数据库中的元素（表、列、值），由检索模块和列选择器两个主要模块组成。
3.1 检索模块
检索模块负责从完整数据库中初步召回与问题相关的结构元素，包含三个子步骤：
- 关键词与实体识别：首先通过 few-shot 的方式提示 LLM，识别用户问题中的关键词以及实体；
- 列检索器：基于关键词与列描述之间的语义相似度排序，为每个关键词检索出 Top-K 的列；
- 值检索器：采用局部敏感哈希（LSH）+ 语义相似性的两阶段检索策略，识别数据库中的相似值（例如用户问题中出现的具体数值、地名等字面量，需要映射到表中实际存储的值）。
3.2 列选择器
- 组织与评估：将上一步检索到的 schema 组织为 M-Schema 的样式提供给 LLM，然后采用 few-shot 方式提示 LLM 评估每个列与用户查询之间的相关性；
- 选择必要列：仅选择必要的列供生成器使用，最小化 SQL 生成所需的表与列数量，降低生成难度与幻觉风险。
3.3 消融验证：Schema Linking 的价值
论文使用 GPT-4o 作为 NL2SQL 生成器，以校正后的 SQL 查询为真实值，评估模式链接对列选择正确性与端到端性能的影响：
| 配置 | 精确率（Precision） | 执行准确率（EX） |
|---|---|---|
| 不使用模式链接 | 10.14% | 57.95% |
| 采用模式链接 | 74.74% | 提升 2.15 个百分点 |
可见，不经过模式链接直接生成时列选择的精确率极低（仅 10.14%），而模式链接将精确率提升至 74.74%（召回率略有下降），并带来 2.15 个百分点的端到端 EX 提升，证明了模式链接模块的有效性。
四、M-Schema：半结构化的数据库结构表示
M-Schema 是 XiYan-SQL 提出的半结构化数据库 schema 表示方法，是连接 Schema Linking 与候选生成的关键"接口格式"。与传统的 DDL Schema（直接罗列建表语句）和 MAC-SQL Schema 相比，M-Schema 通过更结构化的方式组织表、列、类型、约束与值信息，帮助模型更快定位与问题相关的结构要素。
在 Bird 开发集上的消融实验（使用 DeepSeek、Claude 3.5 Sonnet、Gemini 1.5 Pro、GPT-4o 四个强大 LLM 作为 NL2SQL 生成器）显示：与 DDL Schema 相比，使用 M-Schema 时四个模型的性能均有提升，平均提高 2.03%。进一步细分：
| 骨干模型 | 相对 MAC-SQL Schema 的性能变化 |
|---|---|
| GPT-4o | +0.65% |
| Claude 3.5 Sonnet | +0.78% |
| DeepSeek | -0.13% |
| Gemini 1.5 Pro | -0.26% |
尽管 M-Schema 与 MAC-SQL Schema 结构相似，但 GPT-4o 与 Claude 3.5 Sonnet 分别有 0.65% 和 0.78% 的提升，而 DeepSeek 与 Gemini 1.5 Pro 出现轻微下降。整体结论是：M-Schema 是比 DDL Schema 和 MAC-SQL Schema 更好的表示方法，且具有跨模型较强的通用性。
五、Candidate Generation：多生成器协同产出高质量候选
候选生成采用多生成器策略，生成高质量且多样化的候选 SQL，分为微调 SQL 生成器与 ICL SQL 生成器两大部分，另配 SQL Refiner 进行纠错优化。
5.1 微调 SQL 生成器
采用两阶段多任务训练策略，兼顾语法能力与任务泛化：
- 第一阶段：基本语法训练。使用基础、较为单一的 SQL 模式和语法微调预训练模型。训练目标是开发一个基础模型，激活 SQL 生成能力，并使其能够过渡到不同的 SQL 任务；
- 第二阶段：生成增强训练。在第一阶段训练基础上，结合各种多任务数据和语法偏好数据获得增强模型。具体任务包括：
- 将问题转换为 SQL 查询；
- 将 SQL 转换为问题；
- 从 SQL 到参考信息（evidence）的任务；
- SQL 判别与再生成任务等。
此外，为了提升候选的多样性，XiYan-SQL 还引入多样化的语法风格：利用不同的 LLM 以多种方式改写原始查询，并在训练阶段指导模型学习这些数据形式，使微调模型具备"不同偏好"的输出风格，从而在候选池中形成互补。
5.2 ICL SQL 生成器
ICL 生成器不经过微调，直接发挥大模型的上下文学习能力，其关键在示例选择：
- 骨架相似性选择示例：使用 NLTK 工具识别问题中的所有命名实体，并将相同类型的命名实体替换为统一的特殊标记；根据修改后的问题计算 embedding，选择与目标问题最相似的前 K 个训练集样本作为示例；
- 示例选择策略：对于涉及多个表操作的问题，仅选择同样涉及多表操作的 SQL 查询作为示例；每个问题在生成 SQL 时最多使用 5 个示例。
这种"骨架相似 + 任务复杂度匹配"的选例策略，保证了 ICL 示例与目标问题在结构层面高度对齐。
5.3 SQL Refiner：候选纠错与迭代优化
Refiner 基于以下上下文进行第二轮纠正生成：
- 与 schema 相关的上下文；
- 生成的 SQL 查询；
- SQL 的执行结果（包括潜在错误信息）。
原始 SQL 与再生成的 SQL 可以通过选择模型进行最优选择，并且该过程可以迭代执行，持续逼近正确结果。
六、Candidate Selection：从候选池中选出最终 SQL
候选选择模块从候选池中挑选正确且合理的 SQL 查询。流程上，先计算各 SQL 执行结果的一致性并据此分组，再利用选择模型结合提供的上下文信息和候选集，选择最合理的候选。
- 微调选择模型：专门微调一个模型作为 SQL 选择器，以更好地区分候选 SQL 查询之间的细微差别（例如两个 SQL 均能正确执行，但语义或效率不同）；
- 训练数据增广：对选择模型的训练数据进行特定增广，使其与候选 SQL 的不同语法风格偏好保持一致，避免因风格差异导致误判。
6.1 消融验证：选择模型的价值
论文针对候选生成与选择进行了多组消融实验，关键结论如下：
- 去除微调生成器后，XiYan-SQL 性能显著下降，说明微调生成器是高质量、多样候选的主要来源；
- 移除 ICL 生成器和优化器（Refiner）同样导致性能下降，证明多路生成与纠错环节缺一不可；
- 在候选选择方面，不使用选择模型而仅依赖自一致性（self-consistency）进行候选选择时，性能降低约三个百分点，突出了专门选择模型的有效性；
- 当 SQL 候选数量增加到五个时，XiYan-SQL 的准确率进一步提高到 72.23%，说明"候选越多、选择空间越大"的收益仍然存在。
七、实验与评估：四大基准全面领先
7.1 实验设置
XiYan-SQL 在四个数据集上评估，覆盖关系型与非关系型数据库：
| 数据集 | 规模 | 数据库类型 | 说明 |
|---|---|---|---|
| Spider | 1981 个问题，39 个数据库 | SQLite | 广泛认可的跨域数据集 |
| Bird | 1534 个问题，11 个数据库 | SQLite | 测试集不可用，在开发集上实验 |
| SQL-Eval | 304 个问题，11 个数据库 | PostgreSQL | 由 Defog 发布、基于 Spider 构建的开源评估集 |
| NL2GQL | 288 个问题，3 个数据库 | 图数据库 | 评估在非关系型数据集上的有效性 |
评估指标采用执行准确率（Execution Accuracy, EX）：通过比较预测 SQL 与参考 SQL 在特定数据库实例上的执行结果（而非字符串文本）是否一致来判定正确性。在 SQL-Eval 上，由于提供多个参考 SQL 查询，XiYan-SQL 选择第一个作为计算指标的真实值。
7.2 Bird 开发集结果
| 方法 | 准确率 |
|---|---|
| XiYan-SQL（5 候选投票） | 72.23% |
| ExSL + Granite-34B-Code（SFT 路线第二名） | 72.43% |
| CHASE-SQL（多链思维 + 二进制投票） | 73.14% |
| GPT-4o | 57.95% |
XiYan-SQL 在 Bird 开发集上达到 72.23%，显著高于 GPT-4o 的 57.95%。与 CHASE-SQL（采用多链思维提示技术与二进制投票机制，73.14%）相比，XiYan-SQL 在 5 个候选中投票取得了有竞争力的性能。基于 SFT 的 ExSL + Granite-34B-Code 以 72.43% 位居第二，说明小模型通过先进训练技术也能有效生成复杂 SQL；而 XiYan-SQL 通过结合 SFT 与 ICL，在测试时间与系统整体性能之间取得了更优平衡。
7.3 Spider 数据集结果
在 Spider 上，GPT-4o 准确率为 83.54%，XiYan-SQL 刷新了当时的 SOTA 执行准确率，达到 89.65%。相比之前领先模型仅 0.05% 的边际优势，这一结果也表明：底层骨干模型能力的提升对最终性能有显著贡献（框架的性能上限与骨干模型强相关）。
7.4 SQL-Eval 数据集结果
在 PostgreSQL 的 SQL-Eval 数据集上，XiYan-SQL 获得 69.86% 的最高得分，大幅领先于 SQL-Coder-8B 的 60.20%，且比闭源骨干模型高出 2～5 个百分点，体现了 XiYan-SQL 在 PostgreSQL 上 SQL 生成的通用性与跨方言能力。
7.5 NL2GQL（图数据）结果
为验证在非关系型图数据集上的有效性，论文从 NL2GQL 中抽取 288 个示例进行评测，XiYan-SQL 达到 41.20% 的执行准确率，远超其他闭源模型：
| 模型 | 执行准确率 |
|---|---|
| XiYan-SQL | 41.20% |
| DeepSeek | 18.06% |
| Gemini 1.5 Pro | 6.60% |
| GPT-4o | 4.86% |
| Claude 3.5 Sonnet | 3.12% |
该结果表明 XiYan-SQL 的框架设计（schema 表示、多生成器、选择模型）并不绑定于关系型数据库，对图数据库等非关系型场景同样具备显著优势。
八、方法论总结与工程启示
综合全文，XiYan-SQL 可以概括为一条可复用的 Text-to-SQL 工程范式：
- 先检索、再生成、后选择：用 Schema Linking 精准压缩数据库结构上下文，用多生成器扩大候选覆盖，用专用选择模型替代朴素投票；
- SFT 与 ICL 互补：微调生成器保证可控性与语法质量，ICL 生成器利用大模型泛化能力补充多样性，二者缺失任何一个都会导致明显性能回退；
- 表示为王：M-Schema 这类半结构化 schema 表示能普遍提升不同骨干模型的端到端准确率（平均 +2.03%）；
- 选择模型是"临门一脚"：仅依赖 self-consistency 会让性能降低约 3 个百分点，专门微调的选择模型 + 执行结果一致性分组才是正确解法；
- 候选数量可扩展：从更少候选增加到 5 个候选时准确率继续提升至 72.23%，说明在推理预算允许范围内增大候选池仍有收益。
延伸阅读：若希望系统补全本框架背后的基础知识，可结合本仓库《大模型基础》教材的 第 3 章 Prompt 工程（理解 few-shot、上下文学习与示例构造）与 第 6 章 检索增强生成（理解检索模块设计）进行对照学习；相关经典论文（Spider、C3、FinSQL、Self-Consistency 等）均可从 大模型经典论文列表 的"检索增强生成"与"Prompt 工程"章节中找到。教材完整版见 《大模型基础》完整版 PDF。
说明：本文基于 Arxiv 一周进展报告（大模型方向）中的 XiYan-SQL 进展报告 整理扩充而成，所有数据均来自论文原文（arXiv: 2411.08599）的报告内容。