OMNISQL :大规模天生高质量Text-to-SQL数据
Text-to-SQL（Text-to-SQL）任务是将自然语言标题转换为SQL查询，这对于非专业人员与数据库的交互至关重要。只管近来大型语言模型（LLMs）的发展显著提拔了Text-to-SQL的性能，现有方法在实际应用中仍面对明显范围性。基于提示的方法通常依赖于封闭源代码的LLMs，这不仅昂贵，还引发隐私标题且缺乏定制化。另一方面，微调方法由于公开可用训练数据的覆盖范围有限，在处置惩罚复杂标题或特定范畴数据库时表现不佳。为克服这些挑战，我们提出了一种新颖且可扩展的Text-to-SQL数据合成框架，用于自动天生大规模、高质量和多样化的数据集，无需大量人工干预。利用该框架，我们引入了 SynSQL-2.5M ，这是第一个百万规模的Text-to-SQL数据集，包含250万个样本，涵盖了超过16,000个合成数据库。每个样本包罗一个数据库、SQL查询、自然语言标题和链式思考（CoT）办理方案。通过利用 SynSQL-2.5M ，我们开发了 OmniSQL ，这是一个强盛的开源Text-to-SQL模型，提供三种参数规模：7B、14B和32B。广泛的评估表明， OmniSQL 在九个数据集上实现了开始进的性能，匹配或逾越了领先的封闭源代码和开源LLMs（如GPT-4o和DeepSeek-V3），只管其参数目较小。我们发布了所有代码、数据集和模型以支持进一步研究。Text-to-SQL将自然语言（NL）标题转换为可执行的SQL查询，使非专业人员能够有效与数据库互动 (Androutsopoulos, Ritchie, and Thanisch 1995) 。这种本领支持广泛的数据中心应用步伐，并吸引了自然语言处置惩罚（NLP）和数据库社区的大量研究爱好 (H. Li et al. 2023, 2024; Pourreza and Rafiei 2023; J. Li, Hui, Cheng, et al. 2023; D. Gao et al. 2024; Z. Gu et al. 2023; Fu et al. 2023) 。
最新进展：上风与范围。 比年来，大型语言模型（LLMs）的进展显著推动了Text-to-SQL范畴的发展。开始进的（SOTA）办理方案 (Y. Gao et al. 2024; Pourreza et al. 2024) 通常接纳多署理协作框架，其中专门的署理分别处置惩罚不同的子任务，如模式链接、Text-to-SQL天生、SQL细化和SQL选择。在这之中，Text-to-SQL天生仍然是核心组件。当前针对此组件的方法主要依赖于LLMs，可以大抵分为两种范式：基于提示和基于微调。
基于提示的方法通过精心计划的提示来利用强盛的LLMs，通常依赖于通过API访问的封闭源代码模型。相比之下，基于微调的方法专注于在现有的Text-to-SQL数据集（如Spider (Yu, Zhang, et al. 2018) 和 BIRD (J. Li, Hui, Qu, et al. 2023) ）上训练LLMs以适应任务。虽然这两种方法在基准测试中表现出色，但在实际应用中都存在显著范围性。基于提示的方法面对高利用成本、数据隐私标题以及由于依赖API调用而对模型举动的控制力有限。另一方面，基于微调的方法在处置惩罚复杂标题或特定范畴的数据库时每每难以推广，因为公开数据集提供的覆盖范围有限。例如，实验表明Qwen2.5-Coder-7B-Instruct (Hui et al. 2024) 在Spider和BIRD的训练集上微调后，在它们的开发集（与训练数据分布相似）上表现精良，但在跨域数据集ScienceBenchmark (Zhang et al. 2023) 和EHRSQL (G. Lee et al. 2022) 上的执行准确率仅为43.8%和31.4%。相比之下，零样本提示GPT-4-Turbo (OpenAI 2024a) 的执行准确率为59.2%和43.1%，突显了当前微调方法的推广性不足。
为办理这些范围性，通过大规模、多样化、高质量的训练数据加强开源LLMs的Text-to-SQL本领是一个有前景的方向。这些积极不仅可以提高性能和推广性，还可以使Text-to-SQL体系更具有成本效益、数据安全性和适应修改的本领，从而克服封闭源代码LLMs带来的挑战。然而，通过人工标注获取大规模数据通常是不可行的。为此，一些早期的数据加强方法 (W. Yang, Xu, and Cao 2021; Y. Hu et al. 2023; Bailin Wang et al. 2021; Wu et al. 2021) 被提出以扩显现有的Text-to-SQL数据集。 不幸的是，大多数这些方法侧重于天生符合现有数据集分布的数据样本，导致多样性、质量和可扩展性有限。别的，许多方法需要大量的人工积极来定义复杂的模板或语法，进一步限制了实在用性。
我们的提案。 为克服这些范围性，我们提出了一种新颖的Text-to-SQL数据合成框架，与现有数据加强方法相比，具有以下关键上风： (1) 自动化： 整个合成过程需要少少甚至无需人工干预。 (2) 可扩展性： 该框架可以天生大规模、多样且高质量的数据样本，确保涵盖广泛范畴。 (3) 现实性： 合成数据与现实用户需求和场景同等。
挑战与办理方案。 计划自动化、可扩展且现实的数据合成框架并非易事。主要挑战在于在保持天生数据质量和多样性的同时实现自动化和可扩展性。为应对这一挑战，我们引入了一个逐步管道，将合成过程分解为几个更简单、易于管理的步调。每个步调都通过LLMs举行自动化，只管减少人工干预。(1) 管道从网络表格开始，以合成现实的数据库。具体来说，给定一个网络表格，LLM被提示推断与表格相关联的合理业务场景并天生相应的数据库。这个合成数据库包含多个关系表，带有主键和外键关系。每个关系表包含元数据，如表名、描述、列名、数据范例、列描述和两个示例行。鉴于在线上有数以百万计的网络表格 (Eggert et al. 2023) ，这种方法确保了在广泛范畴中的可扩展性。(2) 接下来，我们根据合成的数据库天生有意义的SQL查询。(3) 然后，我们接纳反向翻译技术将这些SQL查询转换为语义等效的自然语言标题。这项技术在先前的研究中广泛应用 (Y. Hu et al. 2023; Awasthi, Sathe, and Sarawagi 2022; Guo et al. 2018; V. Zhong et al. 2020; Wu et al. 2021; Zhang et al. 2023; Bailin Wang et al. 2021) ，因为它可以保证合成的<标题，SQL查询>对的质量，因为将SQL查询转换为自然语言比反过来更准确且不那么暗昧。(4) 最后，为弥合标题和SQL查询之间的差距，我们鉴戒链式思考（CoT）推理 (Wei et al. 2022; Kojima et al. 2022) 。对于每个合成的Text-to-SQL数据，我们天生一个逐步的CoT办理方案，具体阐明从标题和数据库构建SQL查询所需的中间推理步调。这不仅加强了合成数据的可表明性，还为Text-to-SQL模型提供了高质量的训练信号。
第二个挑战是确保合成数据与现实用户的需要和场景同等。一个妥当的Text-to-SQL模型必须能够容纳从简单到高度复杂的各种SQL查询，反映基本数据检索和高级数据分析的需求。为满意这一需求，我们定义了四个SQL复杂度级别：简单、中等、复杂和非常复杂。在SQL合成过程中，我们选择一个复杂度级别，并指示LLM天生相应级别的SQL查询。别的，现实用户经常以不同语言风格表达标题，从正式和明确到暗昧和隐喻。为应对这种变革，我们辨认了九种常见的自然语言风格：正式、口语、命令式、疑问式、描述式、简洁、暗昧、隐喻和对话式。当将SQL查询转换为自然语言标题时，我们接纳特定风格并引导LLM天生与此风格同等的标题。这种方法确保合成数据能够准确捕捉用户在真实场景中大概表达标题的各种方式。
验证。 为验证所提框架的有效性，我们引入了 SynSQL-2.5M ，这是第一个百万规模的Text-to-SQL数据集。具体而言， SynSQL-2.5M 包含2,544,390个Text-to-SQL数据样本，每个样本表现为一个四元组<数据库，标题，SQL查询，CoT办理方案>，涵盖16,583个不同的合成数据库。广泛的统计数据表明， SynSQL-2.5M 与现有Text-to-SQL数据集相比，展示了更高的多样性和复杂性。我们进一步从四个方面评估其质量：数据库、标题、SQL查询和数据样本。与广泛接纳的人类标注数据集BIRD (J. Li, Hui, Qu, et al. 2023) 相比， SynSQL-2.5M 在险些所有标准上都表现更好，证明确我们数据合成管道的可靠性和有效性。
基于 SynSQL-2.5M ，我们开发了 OmniSQL ，这是一个强盛的开源Text-to-SQL模型，提供三种参数规模：7B、14B和32B。我们在九个数据集上广泛评估了 OmniSQL ，包罗三个标准数据集（Spider开发和测试集 (Yu, Zhang, et al. 2018) 和 BIRD开发集 (J. Li, Hui, Qu, et al. 2023) ）、三个特定范畴数据集（Spider2.0-SQLite (Lei et al. 2024) 、ScienceBenchmark (Zhang et al. 2023) 和 EHRSQL (G. Lee et al. 2022) ）和三个鲁棒性数据集（Spider-DK (Gan, Chen, and Purver 2021) 、Spider-Syn (Gan et al. 2021) 和 Spider-Realistic (Deng et al. 2021) ）。结果表明， OmniSQL 在这些数据集上实现了平均性能的新纪录，匹配或超过了领先的开源LLMs（如DeepSeek-V3 (DeepSeek-AI 2024b) 和 Qwen2.5-72B-Instruct (A. Yang et al. 2024) )和先进的封闭源代码模型（如GPT-4-Turbo (OpenAI 2024a) 和 GPT-4o (OpenAI 2024c) )，只管其模型尺寸较小。
我们的贡献总结如下：
[*]数据合成框架。 我们提出了一种自动化和可扩展的Text-to-SQL数据合成框架，办理了天生现实数据库、复杂度感知的SQL查询、风格化的自然语言标题和可靠的链式思考办理方案。
[*]合成数据集和多尺度微调模型。 我们引入了 SynSQL-2.5M ，这是第一个百万规模的Text-to-SQL数据集，包含2,544,390个多样且高质量的数据样本。利用 SynSQL-2.5M ，我们微调了 OmniSQL ，这是一种新的Text-to-SQL模型，提供三种规模：7B、14B和32B。
[*]新Text-to-SQL最佳性能。 广泛的实验表明， OmniSQL 在Text-to-SQL任务中实现了新的开始进性能，以远少的参数逾越了领先的开源和封闭源代码LLMs，突显了我们数据合成框架的有效性。我们已在GitHub上开源了我们的代码、数据集和模型 3 ，以促进Text-to-SQL的进一步研究。
2 相关工作
2.1 Text-to-SQL
在Text-to-SQL范畴，早期研究通常接纳显式的编码器-解码器架构。编码器对数据库模式和标题举行编码，解码器根据编码信息天生相应的SQL查询。一些研究通过引入图关系信息 (Bailin Wang et al. 2020; Cao et al. 2021; J. Li, Hui, Cheng, et al. 2023; Cai et al. 2021) 或利用预训练技术 (Yu et al. 2021; Yin et al. 2020; Deng et al. 2021) 来加强编码器。其他方法则通过引入语法约束来改进解码器，这有助于减少天生的SQL查询中的语法错误，从而提高模型的准确性 (Scholak, Schucher, and Bahdanau 2021; C. Wang et al. 2018) 。
随着序列到序列（seq2seq）模型的快速发展，Text-to-SQL任务已被转移到seq2seq建模任务。许多研究集中在微调T5 (Raffel et al. 2020) 以实现此目的 (H. Li et al. 2023; Scholak, Schucher, and Bahdanau 2021; J. Li, Hui, Cheng, et al. 2023; Rai et al. 2023; Qi et al. 2022) 。近来，随着大型语言模型（LLMs）如GPT-4 (OpenAI 2024c, 2023) 和Gemini (Anil et al. 2023; Reid et al. 2024) 的出现，Text-to-SQL范畴再次发生了变革。通过利用这些强盛的LLMs，研究人员可以将复杂的Text-to-SQL任务分解为更简单的子任务，包罗模式链接、Text-to-SQL天生、SQL细化和SQL选择 (Pourreza and Rafiei 2023; D. Gao et al. 2024; Pourreza et al. 2024; Y. Gao et al. 2024; Bing Wang et al. 2025) 。每个子任务可以通过提示工程或微调技术由基于LLM的署理管理。与之前计划复杂多署理框架的研究不同，本文重点是通过大规模合成数据改进这些框架的核心本领——Text-to-SQL天生。
2.2 Text-to-SQL的数据加强
为办理公开可用数据集覆盖范围有限的标题，许多研究提出了数据加强方法以天生额外的训练数据（即<标题，SQL查询>对），使其符合现有数据集的分布。许多方法 (Y. Hu et al. 2023; Guo et al. 2018; V. Zhong et al. 2020; Wu et al. 2021; Zhang et al. 2023; H. Li et al. 2024; Bailin Wang et al. 2021) 接纳“SQL到标题”管道，其中利用SQL模板或语法天生SQL查询，然后利用神经网络模型将其翻译为自然语言标题。这种方法确保了高质量的合成<标题，SQL>对，因为将SQL转换为自然语言通常更轻易，由于自然语言的灵活性。在这些方法中，SQL模板通常从现有数据集中提取 (Y. Hu et al. 2023; Guo et al. 2018; V. Zhong et al. 2020; H. Li et al. 2024) ，而抽象语法树语法通常需要专家计划 (Wu et al. 2021; Zhang et al. 2023; Bailin Wang et al. 2021) 。 然而，SQL模板限制了多样性，而基于语法的方法劳动密集，难以扩展。
另一种方法是接纳“标题到SQL”管道，首天赋生标题，然后利用现成的Text-to-SQL模型将其翻译为SQL查询 (W. Yang, Xu, and Cao 2021) 。然而，Text-to-SQL模型中的不准确性常导致数据噪声。其他方法利用标题到SQL模板对，无论是手工制作还是从数据集中提取，通过填充槽映射天生新样本 (Weir et al. 2020; Yu, Yasunaga, et al. 2018; Yu et al. 2021) 。只管有效，但这些方法在多样性方面受限，且天生的标题不够自然。
最密切相关的工作是Sense (J. Yang et al. 2024) ，它通过精心计划的提示直接利用GPT-4合成新数据样本。具体来说，Sense指示GPT-4首天赋生一个数据库，然后基于该数据库订定一个标题，最后为该标题天生相应的SQL查询。然而，Sense对昂贵的GPT-4的依赖限制了其可扩展性和成本效益。相比之下，我们的框架将合成过程分解为更简单、更可控的步调，允许利用较弱但开源的LLMs。因此，我们的方法在扩展到百万级或更大合成需求时具有高度的成本效益。别的，Sense的“标题到SQL”计划大概会为先前合成的标题天生不正确的SQL查询，而我们接纳的“SQL到标题”策略确保了更高品格的合成数据。除此之外，我们的方法还合成了CoT办理方案，进一步加强了天生数据的可表明性。
3 数据合成框架
3.1 概述
如图 所示，我们的数据合成框架接纳了一个逐步管道，包罗四个关键步调：基于网络表格的数据库合成、复杂度感知的SQL查询天生、风格化的自然语言标题合成和链式思考办理方案合成。每个步调联合大型语言模型（LLMs）和自动预处置惩罚及后处置惩罚策略，确保高质量和多样化的输出，大大减少了对大量人工干预的依赖。
该过程从网络表格开始，这些表格在网络上丰富，存储着广泛的真实世界范畴结构化数据。利用这些表格，我们合成模拟现实商业场景的数据库。接下来，基于合成的数据库，我们天生具有不同复杂度级别的SQL查询，并将它们回译为具有多种语言风格的自然语言（NL）标题。最后，对于每个合成的<数据库，标题，SQL查询>三元组，我们天生一个链式思考（CoT）办理方案，概述了从自然语言标题推导出SQL查询的逐步推理过程。
3.2 基于网络表格的数据库合成
开发健壮的Text-to-SQL模型需要在多样化的数据库上举行微调。然而，由于企业数据库通常包含敏感信息，互联网上的真实数据库稀缺。只管如此，我们观察到表格数据丰富 (Eggert et al. 2023; Bhagavatula, Noraset, and Downey 2015; Hulsebos, Demiralp, and Groth 2023) ，并且也反映了结构化数据存储的真实世界场景。这一丰富的表格数据为办理上述挑战提供了独特的机会。为此，我们提出了一种新的数据库合成方法，包罗两个关键步调：表格驱动的数据库天生和数据库加强。
表格驱动的数据库天生。 具体来说，给定一个网络表格，我们提示LLM首先创建隐藏在网络表格背后的真实业务场景，然后计划一个可以存储与此场景相关数据的关系型数据库。每个天生的数据库包含多个关系表，以及结构信息，如主键和外键。每个关系表由表名、描述、列名、列数据范例、列描述和两个示例行定义。
https://i-blog.csdnimg.cn/img_convert/ed64e4b2d23bb6ff87bee7f539007bef.webp?x-oss-process=image/format,png
数据库加强。 只管LLM可以通过遵照我们的指令天生有意义且现实的数据库，但我们观察到合成数据库存在两个实际标题：关系表过于简单（平均每张表有4列）和主键及外键关系不完整。我们将这些范围性归因于LLM中的捷径学习，即模型大概优先以最小积极满意用户指令，而不是实现最佳复杂度或完整性 (Du et al. 2022) 。为办理这些标题并确保合成数据库符合真实应用的复杂度要求，我们在初始天生后引入了数据库加强步调。
在此步调中，给定一个最初天生的数据库，我们提示LLM通过添加相关列来扩展每个关系表，并完成任何缺失的主键和外键关系。这种加强增加了每张表的平均列数，并提高了数据库的结构完整性。用于数据库加强的提示包罗以下组件： (1) 任务指令 ：指示LLM加强给定数据库的结构。 (2) 数据库信息 ：最初天生的数据库及其业务场景。
我们的数据库合成方法具有高度可扩展性，因为每个网络表格都可以转换为一个数据库，并且在线上有数以百万计的网络表格 (Eggert et al. 2023) 。别的，利用LLMs确保了合成数据库的质量，因为LLMs可以有效明确、表明并将网络表格扩展为精良的关系模式。相比之下，现有的大规模关系型数据库网络方法每每面对可扩展性或质量标题。例如，GitSchemas (Döhmen et al. 2022) 和 SchemaPile (Döhmen et al. 2024) 从GitHub上的SQL文件中提取数据库构建语句（如 CREATE TABLE 和 ALTER TABLE ）。然而，高质量SQL文件的可用性有限，限制了它们的可扩展性。WikiDBs (Vogel, Bodensohn, and Binnig 2024) 利用来自Wikidata的网络表格构建数据库。具体来说，它通过增加相关表格来逐步构建数据库。然而，这种方法大概会毗连不相关的表格，从而影响数据库的同等性。
3.3 复杂度感知的SQL查询天生
在天生数据库之后，下一步是合成SQL查询。本文利用LLMs举行SQL查询天生，因为它们的预训练使它们接触到广泛的SQL脚本和片段，非常适当此任务。然而，早期实验揭示了一个挑战：较小的LLMs倾向于天生过于简单的SQL查询，而较大的LLMs则常天生高度复杂的查询，导致查询复杂度不均衡。为办理这一标题并控制合成数据的复杂度分布，我们定义了四个复杂度级别——简单、中等、复杂和非常复杂，并指示LLM天生符合指定级别的SQL查询。别的，我们还提供高级SQL函数和采样数据库值，以确保天生的查询有意义且现实。由于许多现实世界的自然语言标题寻求特定项（如统计数据或人名），相应的SQL查询通常返回有限数目的列。为此，我们在SQL查询合成过程中施加了返回列数的约束。具体而言，SQL查询合成的提示包罗以下组件：
[*]任务指令 ：指示LLM天生符合现实数据分析需求的有意义SQL查询。
[*]数据库模式 ：包罗给定数据库中所有关系表的 CREATE TABLE 语句。
[*]高级SQL函数 ：随机采样数据库引擎支持的一些高级SQL函数，允许LLM在适当环境下将这些函数纳入查询中 4 。每个SQL函数都附带名称和具体描述，以资助LLM正确利用。
[*]数据库值 ：随机采样一些列及其存储值，以资助LLM天生有意义且上下文相关的谓词。
[*]SQL复杂度 ：从[“简单”，“中等”，“复杂”，“非常复杂”]中随机采样一个复杂度级别。每个级别由特定标准和示例SQL查询定义。
https://i-blog.csdnimg.cn/img_convert/93f6794d3edd560590306e872d1e0855.webp?x-oss-process=image/format,png
在后处置惩罚阶段，我们应用了几种质量控制步伐。首先，我们利用预定义规则过滤掉非SELECT查询，并在合成数据库上执行剩余的查询以消除语法错误或超时的查询。然后，为确保多样性，我们通过屏蔽SQL查询中的值来提取SQL模板，并仅保存每个模板的一个查询。
https://i-blog.csdnimg.cn/img_convert/9b9e3f96aff4859ba1ea38675a722c56.webp?x-oss-process=image/format,png
3.4 样式化的自然语言标题合成
在合成SQL查询之后，下一步是将其翻译成语义等效的自然语言（NL）标题。现有研究主要集中在通过引入各种新颖技术确保合成标题的语义准确性，如分层天生 (Wu et al. 2021) 、中间表现 (Y. Hu et al. 2023) 和指针解码器网络 (V. Zhong et al. 2020) 。在本研究中，我们以为语言多样性对于开发妥当的Text-to-SQL模型同样重要，因为现实用户用多种风格表达标题。这一点进一步得到了近来鲁棒性基准测试的支持 (Chang et al. 2023; Gan et al. 2021; Deng et al. 2021) ，这些基准测试显示许多Text-to-SQL模型难以应对语言扰动，如同义词更换或句子改写。因此，我们主张在标题合成过程中同时关注语义准确性和语言多样性。
为加强语言多样性，我们定义了九种常见的语言风格：正式、口语、命令式、疑问式、描述式、简洁、暗昧、隐喻和对话式。前六种风格（正式、口语、命令式、疑问式、描述式和简洁）反映了用户清晰表达意图但语气各异的情形。相比之下，暗昧和隐喻风格代表用户利用暗昧词汇或比喻语言的环境，通常需要外部知识举行表明。最后，对话式风格模拟多轮对话，用户逐步澄清意图。这种风格在现实应用中特别相关，因为用户大概不会直接表达需求，需要模型提出跟进标题。表 提供了不同语言风格的示例。
我们注意到DBPal (Weir et al. 2020) 在其标题合成过程中也思量了语言多样性。然而，它依赖于现成的同义词更换数据库 (Pavlick and Callison-Burch 2016) 来更换现有标题中的同义词，这限制了其覆盖用户常用的所有风格的本领。别的，这种简单的同义词更换机制大概导致不自然的标题，进一步凸显了实现语言多样性的必要性。
具体来说，用于合成自然语言标题的提示包罗以下组件：
[*]任务指令 ：指示LLM首天赋生对提供的SQL查询的表明，然后将其翻译成自然语言标题。
[*]SQL查询 ：要翻译的SQL查询。
[*]与SQL相关的列信息 ：包罗SQL查询中引用的列的名称和描述。这有助于LLM天生语义准确的标题，特别是在列名暗昧、缩写或编码的环境下。
[*]所需的语言风格 ：从九种预定义风格中随机采样的一种风格，每种风格附带描述和示例标题。对于正式、口语、命令式、疑问式、描述式和简洁风格，LLM直接天生样式化的标题。对于暗昧和隐喻风格，LLM还需提供标题背后的外部知识。对于对话式风格，LLM天生<用户>和<助手>之间的多轮对话。
对于每个合成的SQL查询，我们利用LLM天生多个候选标题。为了选择最语义准确的标题，我们引入了一个语义同等性选择模块，灵感来源于 (Zhang et al. 2023; Rossiello, Basile, and Semeraro 2017) 。具体来说，我们利用Sentence Transformers (Reimers and Gurevych 2019) 将候选标题嵌入向量表现 5 。对于每个候选标题，我们计算其与其他候选标题的平均余弦相似度。选择相似度最高的标题，因为它位于候选集语义中心附近。通过联合预定义的语言风格和语义同等性选择器，我们加强了合成标题的语言多样性和语义准确性。
3.5 链式思考办理方案合成
链式思考（CoT）推理已在各种具有挑战性的任务中表现出显著成功 (Wei et al. 2022; Kojima et al. 2022) 。通过将复杂标题分解为更小、更易管理的步调，这种方法使LLMs能够更有效地处置惩罚复杂任务，提高准确性和可表明性。基于此，我们通过天生CoT办理方案来加强合成的<数据库，标题，SQL查询>三元组，明确阐明从标题构造SQL查询的推理过程。CoT办理方案合成的提示包罗以下组件：
[*]任务指令 ：指示LLM利用提供的信息天生逐步的CoT办理方案。
[*]数据库模式 ：包罗数据库中所有关系表的 CREATE TABLE 语句。
[*]自然语言标题和SQL查询对 ：自然语言标题及其对应的SQL查询。
典范的CoT办理方案首先分析标题以辨认所需的关键信息。然后确定检索所需数据的相关表、列和筛选条件。最后，逐步构造SQL查询，联合必要的毗连、过滤、聚合、分组和其他操作，终极得出完整的SQL查询作为终极答案。
有趣的是，在开端实验中，我们观察到合成的CoT有时会天生与原始查询不同的SQL查询。仔细查抄后发现，CoT天生的SQL查询通常比原始查询更符合标题。这种改进源于原始<数据库，标题，SQL查询>三元组偶尔存在的小标题，如不必要的列选择和错误的毗连路径。CoT合成过程允许LLM在逐步推理过程中辨认并纠正这些标题，从而天生更准确和精细的SQL查询。这一观察结果与先前的研究同等，表明LLMs善于检测和办理预测SQL查询中的小错误 (Y. Gao et al. 2024; Pourreza et al. 2024; Talaei et al. 2024) 。因此，引入CoT不仅提供了具体的办理方案，还提高了合成数据的整体质量。
为了加强合成CoT办理方案的多样性和可靠性，我们为每个合成的<数据库，标题，SQL查询>三元组天生多个候选CoT办理方案。为了选择最可靠的CoT办理方案，我们从这些候选方案中提取SQL查询并举行多数投票。具体来说，我们根据候选方案SQL查询的执行结果举行分组。终极的CoT办理方案从获得最多票数的组中选择。
4 SynSQL-2.5M ：百万规模数据集
为了展示我们数据合成框架的有效性，我们引入了 SynSQL-2.5M ——第一个百万规模的Text-to-SQL数据集，完全由LLMs自动合成。 SynSQL-2.5M 包含2,544,390个高质量的Text-to-SQL样本，每个样本表现为一个四元组<数据库，标题，SQL查询，CoT办理方案>。该数据集涵盖了广泛的真实世界范畴，包罗交际媒体情感分析、产物库存管理、电影分析、星系形态分析等。
为了制止特定LLMs的习惯引入潜伏偏差，我们在数据合成过程中利用了多个LLMs，每个模型负责天生一部门数据。我们框架的一个关键上风是将Text-to-SQL数据合成任务分解为四个简单且易于管理的子任务。每个子任务可以由相对较小、开源的LLMs有效处置惩罚，这些模型可以当地摆设且成本效益高。这一计划消除了对昂贵封闭源代码LLMs的依赖，正如之前研究所见 (J. Yang et al. 2024) 。在实践中，我们利用了多个开源模型系列，包罗Llama3.1 (Dubey et al. 2024) (Meta-Llama-3.1-8B/70B-Instruct)，Deepseek Coder (Guo et al. 2024; DeepSeek-AI 2024a) (DeepSeek-Coder-6.7B/33B-Instruct， DeepSeek-Coder-V2-Lite-Instruct)，Qwen2.5 (A. Yang et al. 2024) (Qwen2.5-7B/14B/32B/72B-Instruct)，以及Qwen2.5 Coder (Hui et al. 2024) (Qwen2.5-Coder-7B/14B/32B-Instruct)。较大模型被分配更多的合成工作量以确保数据质量。
为了构建 SynSQL-2.5M , 我们从TabLib表格语料库 (Eggert et al. 2023) 中采样0.1%的数据，得到大约1,319,561个网络表格。由于这些表格来自网站，它们经常包含不完整、冗余或无关的内容，这大概影响合成数据库的质量。为办理此标题，我们计划了一个体系化的过滤管道，包罗以下步调：(1) 语言过滤：移除非英语表格以与英语基准保持同等。(2) 大小过滤：移除少于5列或5行的表格。(3) 去重：根据表头移除相似表格。(4) 语义评估：利用Qwen2.5-72B-Instruct (A. Yang et al. 2024) 评估并过滤掉语义丰富度不足的表格。经过过滤后，保存了19,935个高质量的网络表格。在数据库合成过程中，16,583个表格成功扩展为结构完整的数据库，只管遇到了LLM天生响应中的剖析错误和数据库创建失败。最初天生的数据库平均每库包含9.15个表和4.86列。加强后，平均增加到10.15个表和7.3列，形成了具有现实复杂度的数据库。所有数据库均利用SQLite托管和管理。在SQL合成阶段，我们为每个合成数据库天生300个SQL查询，共天生约500万个合成SQL查询。经过质量和多样性控制后，保存了约250万个查询。对于自然语言标题和CoT合成阶段，我们为每个输入提示从LLMs中采样8个响应，温度设置为0.8。
在本节中，我们通过对三个广泛利用的标准数据集（WikiSQL (V. Zhong, Xiong, and Socher 2017) 、Spider (Yu, Zhang, et al. 2018) 和BIRD (J. Li, Hui, Qu, et al. 2023) )和两个特定范畴数据集（ScienceBenchmark (Zhang et al. 2023) 和EHRSQL (G. Lee et al. 2022) )举行全面统计分析，突出 SynSQL-2.5M 的质量、多样性和复杂性。别的，我们利用“LLM-as-a-judger”方法评估 SynSQL-2.5M 的质量，进一步证明其整体高质量。
4.1 总体统计
表 提供了 SynSQL-2.5M 与其他Text-to-SQL数据集的比力概述。如统计数据显示， SynSQL-2.5M 是一个大规模、跨范畴的Text-to-SQL数据集，涵盖了多样化的独特SQL查询和数据库。与依赖大量人工标注的先前数据集不同， SynSQL-2.5M 完全由LLMs天生，展示了其高可扩展性和成本效益。别的， SynSQL-2.5M 在其标题中引入了多样化语言风格。对于暗昧或隐喻的标题，合成了外部知识以澄清其意图。值得注意的是，据我们所知， SynSQL-2.5M 是第一个提供逐步CoT办理方案的大规模数据集。
https://i-blog.csdnimg.cn/img_convert/a529018096579da0e29382225330a37d.webp?x-oss-process=image/format,png
https://i-blog.csdnimg.cn/img_convert/bede27e2d0129db26a739839bbc02494.webp?x-oss-process=image/format,png
6.1.5 基准模型
我们将 OmniSQL 与一系列LLMs举行比力，包罗封闭源代码模型如GPT-4o-mini (OpenAI 2024b) , GPT-4o (OpenAI 2024c) , 和 GPT-4-Turbo (OpenAI 2024a) 11 , 以及开源模型如DeepSeek-V3 (DeepSeek-AI 2024b) , DeepSeek Coder (Guo et al. 2024; DeepSeek-AI 2024a) , Qwen2.5 (A. Yang et al. 2024) , Qwen2.5 Coder (Hui et al. 2024) , LLama-3.1 (Dubey et al. 2024) , Granite (Mishra et al. 2024) , Mixtral (Jiang et al. 2024) , OpenCoder (Huang et al. 2024) , 和 Starcoder2 (Lozhkov et al. 2024) 。这些 模型涵盖了从封闭源代码到开源，从小规模（6.7B）到大规模（671B），从通用到特定于代码，从密集架构到专家混合（MoE）计划的广泛范围。对于未公开参数规模的封闭源代码LLMs，其性能仅作为参考而非在控制参数规模条件下的直接比力。别的，由于推理成本过高，像OpenAI o1 (Jaech et al. 2024) 和DeepSeek-R1 (DeepSeek-AI 2025) 等专注于推理的模型被排除在此评估之外。
6.1.6 推理策略
在LLM推理过程中，我们探索了贪心解码和采样。贪心解码利用温度为0，确保确定性响应。采样则在温度为0.8时引入创造性和多样性，天生每个样本的8个候选响应。然后，我们从这些候选中提取SQL查询，并基于执行结果举行多数投票。终极响应从获得最多票数的组中选择。
6.2 主要结果
评估结果如表 所示，其中“Gre” 和“Maj”分别表现贪心解码和多数投票结果。在每个模型规模下，我们将 OmniSQL 与相似或更大规模的开源LLMs举行比力。我们的发现如下：
合成数据显著加强了基础模型的Text-to-SQL本领。 比力Qwen2.5-Coder模型和 OmniSQL 显示，利用 SynSQL-2.5M 微调后，在大多数数据集上的性能有所提拔。具体来说，在贪心解码策略下， OmniSQL -7B在其基础模型Qwen2.5-Coder-7B-Instruct的基础上平均提拔了+8.4%（从52.8%提拔至61.2%）。类似地， OmniSQL -14B和 OmniSQL -32B在其基础模型Qwen2.5-Coder-14B-Instruct和Qwen2.5-Coder-32B-Instruct上分别平均提拔了2.9%（从59.3%提拔至62.2%）和2.4%（从60.8%提拔至63.2%）。值得注意的是， OmniSQL -7B在该范畴内为7B规模的LLMs树立了新的标准。别的， OmniSQL -14B和 OmniSQL -32B代表了最新的Text-to-SQL本领。
OmniSQL 在标准基准测试中始终表现出领先性能，包罗Spider（开发集）、Spider（测试集）和BIRD（开发集）。 特别是， OmniSQL -7B模型在Spider测试集上的准确率为87.9%（贪心解码），超过了Spider排行榜上最好的公开方法DAIL-SQL + GPT-4 + 自我同等性（86.6%） (D. Gao et al. 2024) ，提高了1.3%。别的，通过简单的多数投票策略， OmniSQL 在Spider测试集上的性能进一步提高到88.9%，88.3%，和89.8%，分别为7B、14B和32B模型规模。另外，我们观察到随着模型规模的增加，Spider上的性能提拔并不同等。这大概是由于Spider是一个相对简单的基准测试，在此环境下较小规模但强盛的模型已经靠近最优性能。相比之下，BIRD比Spider更具挑战性，因此我们可以看到随着 OmniSQL 规模的增加，性能有稍微提拔。值得注意的是， OmniSQL -32B在BIRD开发集上的多数投票准确率达到67.0%，使其与Distillery + GPT-4o（67.2%）相当，后者是在BIRD训练集上微调GPT-4o的结果。
OmniSQL 在特定范畴基准测试（包罗Spider2.0-SQLite、EHRSQL和ScienceBenchmark）中展示了出色的范畴泛化本领。 在最具挑战性的基准测试Spider2.0-SQLite上，只管模型参数有限， OmniSQL 仍然表现出与较大模型相当的准确性。特别是对于7B规模的基线LLMs，其准确率仅在0.7%到3.7%之间，而 OmniSQL -7B达到了10.4%（贪心解码）的准确率，突显了小型模型处置惩罚复杂Text-to-SQL标题的潜力。在EHRSQL和ScienceBenchmark上， OmniSQL 始终优于雷同规模的竞争者，并与领先的LLMs表现相当。特别是在涉及医疗范畴数据库的EHRSQL上， OmniSQL -32B取得了最佳性能，多数投票准确率为46.8%，超过了GPT-4o（多数投票准确率为45.5%）1.3%。这些结果表明， OmniSQL 能够在不举行大量范畴特定微调的环境下，有效地泛化到专业范畴的数据库。
有趣的是，一些开源LLMs（例如Qwen2.5-Coder-32B-Instruct和Meta-Llama-3.1-70B-Instruct） 在标准数据集上的表现显著优于封闭源代码LLMs。然而，它们在特定范畴数据集上的上风减弱。这大概是因为这些开源模型在预训练或微调过程中纳入了流行Text-to-SQL基准测试（例如Spider和BIRD）的训练集。虽然这使得它们在熟悉的数据集上表现出色，但在遇到跨域数据集时结果降落。相比之下， OmniSQL 表现出持续的强性能，无论是在标准还是特定范畴基准测试中都表现出色。
https://i-blog.csdnimg.cn/img_convert/4b62324aa0cf69a87a5cf7b93bf4b8e4.webp?x-oss-process=image/format,png
OmniSQL 在Spider-DK、Spider-Syn和Spider-Realistic上表现出强鲁棒性。 在Spider-Syn和Spider-Realistic上， OmniSQL 在大多数环境下优于基线LLMs，展示了对同义词更换的鲁棒性——这对于现实场景中用户大概利用相似术语指代表格或列的环境至关重要。然而，在Spider-DK上，我们注意到 OmniSQL -14B和 OmniSQL -32B的表现不如其基线模型（即Qwen2.5 Coder）在Spider-DK上好。我们以为这是由于Spider-DK要求Text-to-SQL模型对标题中的隐含知识（例如知识）有深刻明确。基线模型在大量语料库上训练，大概具有更强的知识基础，从而在Spider-DK上表现更好。这些发现为改进我们的数据合成框架提供了宝贵看法。例如，我们可以引入一种新的语言风格来引导LLM合成包含知识的标题。
最后，值得注意的是，通过集成额外的Text-to-SQL技术，如模式链接 (H. Li et al. 2023; Pourreza and Rafiei 2023) 、SQL修订 (Talaei et al. 2024; Y. Gao et al. 2024) 和SQL选择 (Pourreza et al. 2024; D. Lee et al. 2025) ， OmniSQL 在这些数据集上的表现可以进一步提拔。然而，本文的重点是改进LLMs的核心Text-to-SQL本领，这是构建高效且有效的Text-to-SQL体系的基础。因此，我们将探索这些互补技术留待将来工作，不在当前实验中纳入。
https://i-blog.csdnimg.cn/img_convert/263824fe10ce6cf7b9281f5ec857674d.webp?x-oss-process=image/format,png
随着训练数据量增加，性能变革。
6.3 溶解研究
6.3.1 合成数据溶解研究
为了评估合成数据的影响，我们举行了溶解研究，移除了 SynSQL-2.5M 并仅在CoT加强的Spider和BIRD训练集上微调Qwen2.5-Coder-7B-Instruct。如表 （“CoT加强的Spider + BIRD”）所示，移除 SynSQL-2.5M 导致在7个评估数据集上的性能降落，突显了合成数据集的有效性。值得注意的是，移除 SynSQL-2.5M 导致在BIRD上的性能降落4.3%。我们以为这是由于 SynSQL-2.5M 能够弥补人工标注者的空白。别的，对于三个特定范畴的数据集， SynSQL-2.5M 提供了涵盖广泛范畴的数据库，显著加强了 OmniSQL 对新和未见场景的泛化本领。
6.3.2 CoT合成溶解研究
接下来，我们举行了溶解研究以评估合成CoT办理方案（即管道的第四步）的影响。为了高效展示CoT的重要性，我们在原始的Spider和BIRD训练集上微调Qwen2.5-Coder-7B-Instruct，这些训练集仅提供黄金SQL查询作为标签。如表 所示，通过比力“CoT加强的Spider + BIRD”和“原始Spider + BIRD”行的结果，我们发现在大多数数据集（不包罗EHRSQL）上，当CoT办理方案被排除时，性能显著降落。我们以为CoT带来的性能提拔不仅在于其加强LLMs的推理本领，还在于在CoT合成过程中纠正Spider和BIRD中的误标记样本，从而提高整体数据质量。
6.3.3 训练数据规模溶解研究
我们进一步研究了训练数据规模对LLMsText-to-SQL本领的影响。具体而言，我们随机抽取20%、40%、60%、80%和100%的训练数据举行微调，只举行一个epoch，并在图 3 中展示了贪心解码的评估结果。结果表明，训练数据规模与模型性能呈正相关，突显了合成数据对模型Text-to-SQL本领的提拔。别的，纵然利用完整的训练集，这种上升趋势在大多数数据集上仍然持续，表明 OmniSQL 的性能可以通过更多合成数据进一步提拔。
https://i-blog.csdnimg.cn/img_convert/8ccff90750c2567dad9bced429f5eb38.webp?x-oss-process=image/format,png
6.4 与数据加强方法的比力
最后，我们将所提出的合成方法与三种近来且具代表性的数据加强方法举行了比力。为确保公平比力，我们关注合成数据带来的性能提拔而非绝对准确度，因为不同方法利用不同的基线模型。如表 2 所示，我们的方法在Spider和BIRD开发集上实现了显著的准确度提拔，远超现有数据加强方法。值得注意的是，只管Sense (J. Yang et al. 2024) 也利用LLMs举行数据合成，但在BIRD上的提拔仅为 modest (+1.3%)。这一范围主要源于其“标题到SQL”的计划，大概会导致较低质量的合成数据。相比之下，我们的方法在BIRD上实现了显著的+8.8%提拔，突显了其有效性。
7 结论
本文提出了一种新颖且可扩展的Text-to-SQL数据合成框架，将合成过程分解为四个次序、简单且可控的步调。利用该框架，我们引入了 SynSQL-2.5M ，这是一个新的Text-to-SQL数据集，包含约2.5百万个高质量和多样化的数据样本。通过对综合统计分析和质量评估，我们比力了 SynSQL-2.5M 与其他数据集，突出了其更高的质量和多样性。利用该数据集，我们微调了一个新的开源Text-to-SQL模型 OmniSQL 。广泛的评估表明， OmniSQL 在标准、特定范畴和鲁棒性基准测试中显著逾越了基线LLMs，并实现了与开始进LLMs相当的性能，只管其参数目远少。我们信任发布 SynSQL-2.5M 和 OmniSQL 将大大推动Text-to-SQL范畴的研究和发展
[*]本作品接纳Creative Commons BY-NC-ND 4.0国际许可证授权。访问 https://creativecommons.org/licenses/by-nc-nd/4.0/ 查察许可证副本。对于超出此许可证范围的任何用途，请发送邮件至 info@vldb.org 获取许可。版权所有归作者所有。出版权利授予VLDB基金会。
[*]https://github.com/RUCKBReasoning/OmniSQL ↩︎
[*]本文重点是SQLite引擎，因为许多Text-to-SQL基准测试基于它。SQLite支持的函数，包罗名称和描述，可以在官方文档中找到： https://www.sqlite.org/lang_corefunc.html 。 ↩︎
[*]我们利用“all-mpnet-base-v2”模型举行句子嵌入，因为它具有优越的嵌入质量。更多详情请参阅： https://sbert.net/docs/sentence_transformer/pretrained_models.html 。 ↩︎
[*]SQL查询根据空格举行分词。 ↩︎
[*]骨架通过屏蔽SQL查询中的所有表、列和值提取。 ↩︎
[*]我们提出的数据合成方法可以天生大多数主流SQL方言（如PostgreSQL、MySQL、SQL Server、BigQuery等）的数据，因为LLMs在其预训练语料库中大多接触过这些方言。我们选择SQLite作为默认选项，因为许多经典Text-to-SQL基准测试利用SQLite托管其数据库，简化了数据库摆设。 ↩︎
[*]ScienceBenchmark提供的数据库最初托管在PostgreSQL中。我们手动将其转换为SQLite以方便评估。 ↩︎
[*]EHRSQL中的许多自然语言标题无法回答，且一些SQL查询返回空的执行结果。我们从EHRSQL中移除了这些数据样本，以确保同等且可靠的评估。 ↩︎
[*]利用的具体API版本是 gpt-4o-mini-2024-07-18 、 gpt-4o-2024-11-20 和 gpt-4-turbo-2024-04-09 。 ↩︎
[*]Spider的排行榜可以在 https://yale-lily.github.io/spider 找到。排名最高的方法MiniSeek未包含在比力中，因为它不可公开获取。 ↩︎
原论文：https://arxiv.org/pdf/2503.0224
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]