【NL2SQL】Xiyan - SQL:一个用于文本到 SQL 的多生成器集成框架

Xiyan - SQL:一个用于文本到 SQL 的多生成器集成框架

阿里巴巴集团

Github：https://github.com/XGenerationLab/XiYan

论文：https://arxiv.org/abs/2411.08599

摘要

为应对自然语言到SQL任务中大型语言模型性能方面的挑战，我们推出了“XiYan - SQL”(XiYan - SQL)这一创新框架，该框架采用多生成器集成策略来改进候选生成。我们引入了M - 模式(M - Schema)，这是一种半结构化的模式表示方法，旨在增强对数据库结构的理解。为提高生成的候选SQL查询的质量和多样性，“XiYan - SQL”将上下文学习(ICL)的巨大潜力与有监督微调的精确控制相结合。一方面，我们提出了一系列训练策略来微调模型，以生成具有不同偏好的高质量候选。另一方面，我们采用基于命名实体识别的示例选择方法来实施上下文学习方法，以防止对实体的过度强调。优化器通过纠正逻辑或语法错误来优化每个候选。为应对识别最佳候选的挑战，我们微调了一个选择模型，以区分候选SQL查询的细微差别。在多个方言数据集上的实验结果表明，“XiYan - SQL”在应对不同场景的挑战时具有鲁棒性。总体而言，我们提出的“XiYan - SQL”在Bird基准测试中实现了75.63%的最先进执行准确率，在Spider测试集上达到了89.65%，在SQL - Eval上达到了69.86%，在NL2GQL上达到了41.20%。所提出的框架不仅提高了SQL查询的质量和多样性，而且优于以往的方法。

关键词 大语言模型(LLM)、文本转SQL、自然语言转SQL(NL2SQL)

1 引言

通过自然语言转SQL(NL2SQL)技术将自然语言查询转换为结构化查询语言(SQL)的能力，是使复杂数据集更易于访问的一项重大进展。它极大地帮助了非专业用户和高级用户从大量数据存储库中提取有价值的信息 [2, 15, 24, 27.6, 10.13, 29.20, 19.23, 22]。大语言模型(LLM)的最新进展显著提高了NL2SQL应用程序的效率和准确性。

基于大语言模型(LLMs)的自然语言到结构化查询语言(NL2SQL)解决方案通常有两种方法:提示工程[3, 5, 17, 18]和有监督微调(SFT)[9]。提示工程通过优化提示来利用模型的内在能力，以生成多样化的SQL查询。提示工程在使用零样本[3]或少样本提示[28, 5, 18]的NL2SQL任务中已取得了有前景的成果。这类方法通常采用具有大量参数的闭源模型，如GPT - 4[1]和Gemini 1.5[26]，这些模型展现出巨大的潜力和强大的泛化能力。然而，大多数方法依赖多路径生成并利用自一致性选择最佳选项，这导致了显著的推理开销。基于有监督微调的方法试图在NL2SQL任务上对参数规模小得多的模型进行微调，以生成更可控的SQL查询，如CodeS[9]。不过，由于参数有限，这些方法难以进行复杂的NL2SQL推理，也难以迁移到新领域的数据库中。

在本技术报告中，我们提出了“XiYan - SQL”(XiYan - SQL)，这是一种新颖的自然语言到 SQL(NL2SQL)框架，采用多生成器集成策略来增强候选生成能力。“XiYan - SQL”结合了提示工程和有监督微调(SFT)方法，以生成高质量且多样化的候选 SQL 查询。为了提高质量，我们利用 SFT 的高可控性，并采用一系列训练策略来专门微调模型，以生成具有不同偏好的候选查询。我们引入了一种两阶段多任务训练方法，该方法首先激活模型的基本 SQL 生成能力，随后过渡到具有增强语义理解和多样化风格偏好的模型。为了提高生成候选查询的多样性和生成复杂 SQL 查询的能力，我们利用上下文学习来提示大语言模型(LLMs)。我们建议通过用常见特殊标记掩盖命名实体来提取问题的骨架，并使用骨架相似度来选择和组织有用的示例。然后，每个生成器后面都跟着一个优化器，用于根据执行结果或错误信息纠正逻辑或语法错误。最后，需要一个选择代理来选择最佳选项。大多数现有工作使用自一致性，但最一致的结果并不总是正确的。因此，我们建议微调一个模型，以理解和识别候选查询之间的细微差异并选择最终响应。

此外，为了增强大语言模型(LLMs)对数据库模式的理解能力，我们提出了一种名为M-Schema的新模式表示方法。受MAC-SQL模式 [28] 的启发，M-Schema以半结构化形式呈现数据库、表和列之间的层次结构。我们通过添加数据类型对MAC-SQL模式进行了修订，从而得到了一种更紧凑、更清晰的格式。我们进行了实验，以比较不同模式表示对自然语言到SQL(NL2SQL)性能的影响。与数据定义语言(DDL)模式和MAC-SQL模式相比，使用M-Schema的大语言模型表现出更优的性能。

图1:所提出的夕颜SQL(XiYan-SQL)工作流程概述，该流程由三个代理组成:1) 模式链接，用于检索并选择最合适的数据库模式；2) 候选生成，使用上下文学习(ICL)和监督微调(SFT)生成器生成高质量的候选SQL查询；3) 候选选择，从生成的候选查询中挑选最终响应。M-Schema用作模式表示并提供给大语言模型。

我们对关系型和非关系型数据库进行了全面评估，特别关注了SQLite、PostgreSQL和nGQL等知名系统。XiYanSQL(XiYan - SQL)在一系列基准测试中表现出色，在Spider [32]、SQL - Eval和NL2GQL [33]数据集上分别以 $89.65\%,69.86\%$ 和 $41.20\%$ 的执行准确率达到了当前最优性能。在更具挑战性的Bird [10]基准测试中，XiYanSQL(XiYan - SQL)也达到了75.63%的最高准确率。在各种具有挑战性的自然语言到SQL(NL2SQL)基准测试中取得的优异结果，不仅验证了我们方法的有效性，还展示了其在自然语言到SQL(NL2SQL)翻译任务中更广泛应用的巨大潜力。可以从https://bailian.console.aliyun.com/xiyan访问XiYanSQL(XiYan - SQL)。我们还在https://github.com/XGenerationLab/M - Schema发布了用于连接数据库和构建M - Schema的源代码。

2 总体框架

本节概述了所提出的西研 - SQL(XiYan - SQL)框架，该框架由三个主要组件组成:1) 模式链接；2) 候选生成；3) 候选选择。模式链接用于从大型数据库模式中选择相关列并检索值，有助于减少无关信息，专注于相关数据。然后，将这些上下文信息组织成 M - 模式，并输入到候选生成模块中，以生成潜在的候选 SQL 查询。这些候选查询通过自我优化过程进行细化。最后，候选选择代理会比较所有候选查询，以确定最终的 SQL 查询。该流程如图 1 所示。

3 M - 模式

需要在提示中提供数据库模式，以便大语言模型(LLM)理解数据库结构。我们提出了一种名为M-Schema的新型表示方法。M-Schema以半结构化格式展示了数据库、表和列之间的层次关系，并使用特定的标记进行标识:“ [DB_ID] ”标记数据库，“# 表”表示表，“ [外键] ”表示外键。对于每个表，我们会给出表名和表描述，其中表描述可以省略。表中的信息会转换为一个列表，列表中的每个元素是一个元组，代表列的详细信息。每列包括列名、数据类型、列描述、主键标识符和示例值。此外，由于外键很重要，需要将其列出。

图2展示了在数据定义语言(DDL)模式、MAC - SQL [28]模式和M模式中表示数据库的示例。数据定义语言(Data Definition Language，DDL)模式是最常用的表示方式。然而，它缺乏必要的表和列描述以及示例值。因此，大语言模型(LLMs)难以区分相似的列。M模式源自MAC - SQL模式，是一种更紧凑的表示方式。它与MAC - SQL模式的主要区别在于列的表示，具体如下:

• 数据类型。数据类型确保数据被正确地结构化和处理。MAC - SQL模式缺乏数据类型规范，这可能导致生成的SQL查询在执行时产生错误结果。

• 主键标记。我们引入主键标记来维护关系型数据库中表之间的关系。

图2:在DDL模式、MAC - SQL模式和M模式中表示数据库模式的示例。红色文本突出显示了M模式和MAC - SQL模式之间的差异。M模式添加了数据类型、主键标记，并更改了显示示例值的规则。

• 列描述。在MAC - SQL模式中，列描述从列名派生而来，而M模式连接到数据库以获取更详细的描述。

• 值示例:我们将“值示例(Value examples)”标记简化为“示例(Examples)”以减少冗余。我们还为值建立了新的显示规则，如字符串长度和示例数量。

此外，MAC - SQL模式(MAC - SQL Schema)中每列表示的前导空格已被去除。我们在https://github.com/XGenerationLab/ M - Schema上发布了如何连接数据库引擎和构建M - 模式(M - Schema)表示的方法，并支持MySQL和PostgreSQL等常用数据库。

4 模式链接

模式链接将自然语言查询中的引用与数据库模式内的元素(包括表、列和值)进行关联。我们的模式链接流程包括一个检索模块和一个列选择器。

检索模块 为了在数据库中搜索相似的值和列，与文献[17]中的方法类似，我们首先用小样本示例提示模型，以识别问题中的关键词和实体。然后，我们使用列检索器来检索相关列。基于关键词和列描述之间的语义相似度，我们为每个关键词检索前 k 列。为了提高效率，值检索器采用基于局部敏感哈希(Locality Sensitive Hashing，LSH)和语义相似度的两阶段检索策略，以识别数据库中的相似值。最终选择的模式是列检索器和值检索器的并集。

列选择器 列选择器旨在将表和列减少到用于 SQL 生成的最小必要模式。上一步检索到的模式被组织为 M - 模式，并呈现给大语言模型(LLMs)。然后，我们采用小样本方式提示语言模型评估每列与用户查询的相关性，仅选择那些必要的列。

5 候选生成

在候选生成方面，我们采用各种生成器来生成高质量且多样化的SQL候选语句。一方面，我们运用一系列训练策略对生成模型进行针对性微调，旨在生成具有不同句法风格的高精度SQL候选语句。另一方面，我们还引入了上下文学习(ICL)方法来增强SQL候选语句的多样性。我们的优化器进一步改进生成的SQL查询。在接下来的章节中，我们将对每个部分进行简要概述。

图3:微调SQL生成器的两阶段多任务训练流程。

5.1 微调SQL生成器

核心目标是生成高精度且多样化的SQL候选语句。为此，我们利用微调模型在特定任务上的高可控性，构建一系列具有不同偏好的高精度模型。如图3所示，我们采用两阶段多任务训练方法对模型进行微调，包括基本语法训练和生成增强训练。通过这种训练方法，我们流程的中间结果和最终结果是一组各有优势的模型。

基础语法训练 基础语法训练侧重于使用基本的单一SQL模式和语法对预训练模型进行微调。在这个阶段，用于训练的数据与SQL方言无关，非常全面地涵盖了基础语法，总共有数万个样本。训练目标是开发一个能够激活SQL生成能力的基础模型，该模型可以作为向不同专业SQL任务过渡的桥梁。

生成增强训练 在第一阶段训练之后，我们转向生成增强训练，旨在增强模型在语法方面的语义理解和风格偏好。在这个阶段，我们可以结合各种多任务数据和句法偏好数据来获得一个增强的模型。该模型可以从多任务数据中受益，以更好地理解问题与SQL查询之间的映射关系。具体而言，除了将问题转换为SQL查询的标准任务之外，我们还进一步设计了将SQL转换为问题的任务，其目的是根据提供的上下文信息和SQL查询推断潜在的问题。我们定义了从SQL到证据的任务，该任务旨在根据上下文和SQL从一组候选证据中选择最相关的证据。此外，我们还引入了SQL判别和再生任务，旨在根据执行反馈进行SQL优化，以及其他相关任务。这一系列专门的任务有效地增强了SQL与上下文信息之间的联系，从而提高了整体生成能力。该模型可以从各种风格的模式和句法特征中受益，以更好地生成更多样化的SQL候选方案。我们利用不同的大语言模型(LLMs)以多种方式改写原始查询，同时不改变其原意。这种方法有效地将样本数据扩展为不同的句法风格，从而在训练阶段让模型从这种数据形式中学习。

由于SQL查询存在多种方言，在此阶段，我们可以按照既定的流程分别处理每种方言。随后，我们可以选择为每种方言训练单独的模型，或者联合训练一个多方言模型。在实际应用中，我们可以根据需求选择多任务和偏好数据的子集来微调目标模型，从而生成高质量的SQL候选语句。

5.2 基于上下文学习(ICL)的SQL生成器

基于上下文学习(ICL)的自然语言到SQL(NL2SQL)生成的性能不仅取决于模型的固有能力，还取决于所提供的示例。已经提出了几种检索有用示例的方法，例如掩码问题相似度和查询相似度 [5]。尽管掩码问题相似度排除了表名和列名的影响，但它仍然对实体敏感。基于查询相似度的方法需要一个初步模型来生成近似的SQL，因此初步模型的能力直接影响最终结果。

西研 - SQL(XiYan - SQL)采用了一种基于用户问题与训练集中问题骨架相似度的示例选择策略。首先使用自然语言工具包(NLTK)的工具识别问题中的所有命名实体，然后将相同类型的命名实体替换为特殊标记。例如，“中国”(China)和“美国”(America)都被识别为国家，因此它们都被替换为“<国家>”()。其他实体，如枚举值，则被替换为列名。这种方法避免了过度关注实体，同时保留了实体的语义。然后，我们计算训练集和测试集中修改后问题的嵌入表示，并从训练集中选择与目标问题最匹配的前 K 个示例。此外，我们注意到，仅对一个表进行操作的 SQL 示例对于涉及多表的 SQL 生成帮助有限。在选择 SQL 示例时，对于通过模式链接选择两个或更多表的问题，我们只选择涉及多表操作的 SQL 查询。根据表的数量和相似度阈值，每个问题最多使用 5 个示例。

表 1:我们实验中使用的数据集详情。

数据集	方言	#问题	#数据库
蜘蛛(Spider)	SQLite数据库(SQLite)	1981	39
鸟	SQLite数据库(SQLite)	1534	11
SQL评估(SQL-Eval)	PostgreSQL数据库(PostgresQL)	304	11
自然语言到图查询语言转换(NL2GQL)	图查询语言(nGQL)	288	3

对于像Bird和Spider(SPIDER)这样的基准测试，训练集和测试集的数据库不会重复，因此在提示中展示示例的模式有助于模型更好地理解模式与SQL查询之间的关系。为了减少令牌消耗和冗余列的干扰，为每个选定的SQL示例仅提供最小列集。

5.3 SQL优化器

生成的候选SQL查询不可避免地包含逻辑或语法错误[17, 25]。通过利用这些SQL查询缺陷的线索，我们可以在一定程度上进行修正。为此，我们采用一个SQL优化器来优化生成的SQL。在实践中，基于与模式相关的上下文、生成的SQL查询和执行结果(包括潜在的错误信息)，我们让模型进行第二轮的修正生成。原始SQL和重新生成的SQL可以进一步通过一个选择模型(如第6节所述)进行最优选择，并且这个过程可以迭代执行。

6 候选选择

基于模式链接和各种候选生成器，我们可以为给定的问题生成一组候选查询。从候选查询池中选择正确合理的SQL查询这一挑战仍有待解决。大多数方法[7, 25]采用自一致性[30]来选择在多个候选样本中出现最一致的SQL查询。然而，这种方法存在局限性:它无法处理所有查询都不一致的情况，而且即使是最一致的结果也并非总是正确的。

为此，我们采用一个选择模型来进行判断。我们衡量SQL执行结果的一致性以对它们进行分组，这样我们就能从每个组中识别出不一致的样本，从而形成一个候选集。然后，我们利用选择模型根据提供的上下文信息和候选集来选择最合理的候选查询。我们没有采用基于大语言模型(LLM)的提示方法，而是专门微调了一个模型作为选择模型，以便更好地区分候选SQL查询的细微差别。为了适应SQL候选查询不同的句法偏好，我们还特意对选择模型的训练数据进行了改述。

7 实验

7.1 实验设置

为评估所提出的惜言 - SQL(XiYan - SQL)框架的通用性，我们在关系型和非关系型图数据库上以端到端的方式对其进行评估。Spider [32] 和 Bird [10] 是广泛认可的使用 SQLite 的跨领域数据集。由于 BIRD 基准测试的测试集不可用，我们在开发集上进行实验和性能评估。SQL - Eval ${}^3$ 是 Defog 发布的一个开源 PostgreSQL 评估数据集，它基于 Spider 构建。基于图数据库构建的 NL2GQL [33] 也参与了我们的实验。数据集的详细信息如表 1 所示。我们使用执行准确率(EX)来评估生成的 SQL 查询的有效性。EX 比较预测的 SQL 查询和在特定数据库实例上执行的参考 SQL 查询的结果。

— ${}^3$ https://github.com/defog-ai/sql-eval

---

表 2:不同 NL2SQL 方法在 Bird 基准测试中的性能比较。

方法	EX(开发)	EX(测试)
CHASE - SQL + 双子星模型[17]	74.46	74.79
DSAIR + GPT - 4o	74.32	74.12
ExSL + granite - 34b代码模型	72.43	73.17
AskData + GPT - 4o	72.03	72.39
开源搜索结构化查询语言(OpenSearch - SQL)，v2 + GPT - 4o	69.30	72.28
蒸馏器(Distillery) + GPT - 4o [16]	67.21	71.83
国际象棋算法(CHESS) [25]	68.31	71.10
洞察人工智能(Insights AI)	72.16	70.26
紫色(PURPLE) + 红色(RED) + GPT - 4o	68.12	70.21
多条件搜索结构化查询语言(MCS - SQL)[25]	63.36	65.45
超级结构化查询语言(SuperSQL)[8]	58.50	62.66
软微调代码模型SFT CodeS - 15B [9]	58.47	60.37
生成式预训练变换器4优化版(GPT - 4o)	57.95	-
任务自适应结构化查询语言+生成式预训练变换器4(TA - SQL + GPT - 4)[21]	56.19	59.14
对话式自适应交互式学习结构化查询语言(DAIL - SQL)[5]	54.76	57.41
熙研 SQL(XiYan-SQL)	73.34	75.63

表3:不同自然语言转SQL(NL2SQL)方法在Spider测试基准上的性能比较。

方法	准确率(%)
MCS - SQL + GPT - 4 [7]	89.6
CHASE - SQL + Gemini 1.5 [17]	87.6
PET - SQL [11]	87.6
SuperSQL [8]	87.0
DAIL - SQL + GPT - 4 [5]	86.6
DPG - SQL + GPT - 4	85.6
Tool - SQL + GPT - 4 [31]	85.6
DIN - SQL + GPT - 4 [18]	85.3
GPT - 4o	83.54
C3 + ChatGPT + 零样本学习 [3]	82.3
熙研 - SQL	89.65

表4:不同方法在SQL-Eval基准测试上的性能比较。

方法	准确率(%)
SQL编码器-8B(SQL-Coder-8B)	60.20
深度求索(DeepSeek)	65.36
GPT - 4o	64.64
克劳德3.5十四行诗(Claude 3.5 Sonnet)	51.43
双子座1.5专业版(Gemini 1.5 Pro)	67.86
曦言SQL(XiYan-SQL)	69.86

表5:不同方法在自然语言到图查询语言(NL2GQL)基准测试中的性能比较。

方法	准确率(%)
深度求索(DeepSeek)	18.06
GPT - 4o	4.86
克劳德3.5十四行诗(Claude 3.5 Sonnet)	3.12
双子星1.5专业版(Gemini 1.5 Pro)	6.60
熙研 SQL(XiYan-SQL)	41.20

7.2 BIRD基准测试结果

我们在表2中比较了不同自然语言转SQL(NL2SQL)方法在BIRD(Bird)基准测试中的性能。XiYanSQL(XiYan - SQL)以75.63%的准确率位居BIRD排行榜榜首，比第二名高出0.84%。CHASE - SQL [17]框架采用多种思维链提示技术生成候选方案，随后在21个候选方案中实施二元投票机制，准确率达到74.70%。XiYanSQL仅在5个候选方案中进行投票，就取得了具有竞争力的性能。

我们还观察到，BIRD排行榜上的许多领先方法都基于提示工程技术。这表明大规模模型具有巨大潜力，以及精心设计的提示在优化模型性能方面的重要性。基于监督微调(SFT)的方法ExSL + Granite - 34B - 代码(ExSL + Granite - 34B - Code)以73.17%的准确率位居第四。这一显著表现表明，通过先进的训练技术，较小规模的模型确实能够有效地生成复杂的SQL查询。XiYanSQL整合了监督微调(SFT)和上下文学习(ICL)的方法，以平衡系统的测试时间和整体性能。

7.3 SPIDER(Spider)基准测试结果

为了证明我们方法的通用性，我们还在Spider数据集上对XiYanSQL(XiYan - SQL)进行了评估。如表3所示，基础骨干模型能力的提升显著改善了性能指标。具体而言，GPT - 4o达到了83.54%的惊人准确率。此外，XiYanSQL(XiYan - SQL)刷新了 $89.65\%$ 的最优执行准确率，仅比之前的领先模型高出0.05%。

表6:不同模式表示的消融实验。

模型	EX(数据定义语言模式，%)	EX(MAC - SQL模式，%)	EX(M模式，%)
GPT - 40	55.67	57.30	57.95
深度求索(DeepSeek)	53.52	55.28	55.15
克劳德3.5十四行诗(Claude 3.5 Sonnet)	49.74	50.26	51.04
双子座1.5专业版(Gemini 1.5 Pro)	49.22	52.41	52.15

7.4 SQL评估结果

表4展示了在SQL评估(SQL-Eval)数据集上的结果。SQL评估提供了多个参考SQL查询，我们选择第一个选项作为计算指标的真实值。XiYanSQL(XiYan-SQL)在SQL评估上报告的得分最高，达到69.86%。我们的模型大幅领先于在LLaMA - 3 [4]上微调的SQL编码器8B(SQL - Coder - 8B) ${}^4$ 8.59%，并且比闭源骨干模型领先 $2\sim 5$ 个百分点。这证明了XiYanSQL在为PostgreSQL进行SQL生成方面的泛化能力。

7.5 自然语言到图查询语言(NL2GQL)结果

为评估犀言 - SQL(XiYan - SQL)在非关系图数据集上的有效性，我们从自然语言到图查询语言(NL2GQL)[33]数据集中总共抽取了288个示例，这些示例此前曾在多模态查询模型(MoMQ)[12]中使用。如表5所示，GPT - 4o、深度求索(DeepSeek)、双子星1.5专业版(Gemini 1.5 Pro)和克劳德3.5十四行诗(Claude 3.5 Sonnet)在NL2GQL数据集上的整体执行准确率有限。犀言 - SQL的执行准确率达到41.20%，大幅超越它们，总体表现最佳。

7.6 消融实验

为进一步研究我们框架中各组件的有效性，我们在BIRD开发基准测试上进行了消融实验，因为该测试具有挑战性，且更能反映现实场景。

7.6.1 多模态模式(M - Schema)

我们在Bird开发基准上进行了消融研究，以展示不同模式表示对端到端SQL生成性能的影响。为了证明我们提出的M-Schema(多模态模式)的泛化能力，我们使用了四个强大的大语言模型作为自然语言到SQL(NL2SQL)的生成器，分别是DeepSeek [14]、Claude 3.5 Sonnet 5、Gemini 1.5 Pro和GPT-4o [1]。如表6所示，与使用数据定义语言模式(DDL Schema)相比，使用M-Schema作为数据库模式的表示时，这四个模型的性能均有所提升，平均提升了 $2.03\%$ 。尽管M-Schema在结构上与MAC-SQL模式(MAC-SQL Schema)相似，但GPT-4o和Claude 3.5 Sonnet的性能分别提升了0.65%和0.78%，而DeepSeek和Gemini 1.5的准确率则略有下降，分别下降了0.13%和0.26%。实验结果表明，M-Schema是一种比DDL Schema和MAC-SQL Schema更好的表示方式，并且具有强大的泛化能力。

7.6.2 模式链接

我们进行消融实验以评估模式链接(schema linking)的有效性。我们利用召回率和精确率指标，基于修正后的SQL查询(作为真实标签)来评估所选列的正确性。我们使用GPT - 4o作为自然语言到SQL(NL2SQL)生成器，以分析模式链接对端到端EX指标的影响。结果如表7所示。在不使用模式链接的情况下，我们将所有表、列和随机采样的示例值提供给大语言模型(LLM)。其精确率为 $10.14\%$ ，EX指标为 $57.95\%$ 。本报告中的模式链接方法实现了74.74%的高精确率，同时仅略微降低了召回率。通过向模型提供最相关的信息，执行准确率提高了2.15%，这证明了模式链接的有效性。

7.6.3 候选生成与选择

为了评估候选生成与选择的有效性和影响，我们对夕颜SQL(XiYan - SQL)进行了各种消融实验。表8展示了夕颜SQL在去除某些组件时的性能，凸显了这些组件对于实现高质量性能的重要性。“夕颜SQL全组件”方法的准确率达到了

— ${}^4$ https://huggingface.co/defog/llama-3-sqlcoder-8b ${}^5$ https://www.anthropic.com/news/claude-3-5-sonnet

---

表7:模式链接的消融研究。

方法	精确率(%)	召回率(%)	EX(%)
基线	10.14	100.00	57.95
+ 模式链接	74.74	95.47	60.10

表8:候选生成与选择对“XiYan - SQL”(XiYan - SQL)在Bird开发基准测试中性能的消融研究。

方法	提取率(%)	$\Delta$ 提取率(%)
夕颜 SQL 全量版	71.58	-
夕颜 SQL 无微调生成器版	68.67	-2.91
夕颜 SQL 无示例学习生成器版	70.27	-1.31
无精炼器的惜言 - SQL(XiYan - SQL w/o Refiner)	71.03	-0.55
无选择模型的惜言 - SQL(XiYan - SQL w/o Selection model)	68.84	-2.74
惜言 - SQL 全量(五个候选)(XiYan - SQL All (five candidates))	73.34	-

通过使用三个候选查询，准确率达到71.51%。其中两个候选查询由两个不同的微调SQL生成器生成(如5.1节所述)，而另一个由使用GPT - 4o的上下文学习(ICL)SQL生成器生成(如5.2节所述)。对于候选查询生成器而言，当移除微调后的候选查询生成器时，“XiYan - SQL”(XiYan - SQL)的性能显著下降，这进一步表明我们的生成器能够生成高质量且多样化的候选SQL查询。同样，移除上下文学习生成器和优化器也会导致性能下降。此外，在候选查询选择方面，我们发现当不使用选择模型，仅依靠自一致性进行候选查询选择时，“XiYan - SQL”的性能下降约3个百分点。这一发现凸显了我们所提出方法的有效性。最后，当SQL候选查询数量增加到五个时，“XiYan - SQL”的准确率可进一步达到73.34%。

8 结论

在本技术报告中，我们提出了一种用于自然语言到结构化查询语言(NL2SQL)的多生成器集成框架，名为“XiYan - SQL”(XiYan - SQL)。该框架利用监督微调(SFT)方法的优势来增强可控性，同时集成上下文学习(ICL)方法，以最大程度地生成高质量且多样化的SQL候选语句。我们提出了一种两阶段多任务训练方法，用于训练一系列具有不同偏好的模型，并提出了一种候选语句选择策略，以挑选出最合理的候选语句。“XiYan - SQL”在包括Spider和SQL - Eval在内的公开关系型数据库，以及非关系型数据库的自然语言到图查询语言(NL2GQL)任务中均展现出了最先进的性能。这凸显了“XiYan - SQL”在处理来自不同分布的未见样本时，进行高质量NL2SQL生成的巨大潜力。