自然语言到SQL（NL2SQL）任务在大型语言模型（LLMs）的帮助下取得了显著进展。然而，这些模型通常依赖于闭源系统和高计算资源，这在数据隐私和部署方面带来了挑战。相比之下，小型语言模型（SLMs）在NL2SQL任务中表现不佳，性能较差且与现有框架不兼容。

为了解决这些问题，我们引入了 Feather-SQL ，这是一种专为SLMs设计的新轻量级框架。Feather-SQL通过以下方法提高了SQL可执行性和准确性：1）模式修剪和链接；2）多路径和多候选生成。此外，我们提出了 1+1模型协作范式，将一个强大的通用聊天模型与一个微调后的SQL专家模型配对，结合了强大的分析推理能力和高精度的SQL生成能力。实验结果表明，Feather-SQL在BIRD数据集上提高了SLMs的NL2SQL性能，对于未微调的模型，性能提升了约10%。所提出的范式将SLMs的准确率上限提高到了54.76%，证明了其有效性。

表1：BIRD DEV数据集上的NL2SQL性能表现。EXE（可执行性）衡量查询成功执行的情况，而ACC（准确性）衡量结果匹配正确的程度。

自然语言到SQL（NL2SQL）的任务是将自然语言问题转换为相应的SQL查询，使用户无需精通SQL语言即可从数据库中检索结构化数据。近年来，随着GPT-4等大型语言模型（LLMs）的出现，该领域取得了显著进展，例如CHASE-SQL和XiYan-SQL等框架实现了最先进的（SOTA）性能。然而，两个限制阻碍了它们的实际应用。首先，主流方法依赖于闭源模型，对外部API的依赖在医疗和金融等敏感领域引入了数据隐私风险。其次，大多数开源研究集中在7B–30B参数的模型上，而4B或更少参数的小型语言模型（SLMs）相对较少被探索。同时，许多关系型数据库部署在高性能系统上，但GPU资源有限。通过高效推理框架（如Intel IPEX-LLM）或量化技术，SLMs可以帮助推动NL2SQL在实际场景中的广泛应用，同时保护数据隐私。

图1：在NL2SQL场景下，小型语言模型（SLMs）产生的典型语法错误示例。

本文聚焦于使用SLMs增强NL2SQL性能。如图 1所示，SLMs面临两个关键挑战：(1) 一个关键问题是其可执行性急剧下降 。与能够有效处理长上下文依赖的LLMs不同，SLMs在处理复杂数据库模式和冗长提示时容易产生混淆或幻觉输出；(2) 现有的适用于LLMs的NL2SQL框架与SLMs不兼容 ，因为它们依赖于强大的指令遵循能力来生成中间结果，这是SLMs缺乏的。如图2 所示，SLMs的输出经常违反施加的要求：它们往往不符合JSON或数组规范，也不满足预定义的约束条件。直接将这些框架应用于SLMs可能会进一步降低可执行性。

图2：在CHESS提供的BIRD子集上进行的模式链接实验。要求模型输出JSON格式的响应，其中包含不超过五个与问题相关的字段，且不生成任何无关内容。

为了解决这些挑战，我们提出了 Feather-SQL，这是一种专为SLMs设计的轻量级框架，旨在提升NL2SQL任务中的可执行性和准确性。Feather-SQL包含六个关键组件：模式修剪、模式链接、多路径生成、多候选生成、校正和选择。专门为SLMs设计的模式修剪通过丢弃无关表来简化输入处理，使模型能够专注于关键数据库元素。模式链接通过语义分析改进了问题与数据库模式之间的对齐，确保列选择的准确性。为了减轻链接和修剪错误的影响，多路径生成探索了多样化的查询公式策略，增强了鲁棒性。多候选生成通过增加生成SQL查询的多样性进一步提高了模型的可执行性和准确性，从而增加了生成正确候选的可能性。最佳候选通过执行验证和排名进行选择。作为补充，我们引入了提取和简化提示策略。提取有选择地检索关键信息，而简化则通过去除多余的提示细节来降低计算开销。通过整合这些技术，Feather-SQL使SLMs能够在固有局限下更可靠地生成SQL查询。

一种常见的增强SLMs的方法是微调。然而，虽然针对SQL生成任务微调的SLMs（如Prem-SQL、CodeS）在核心NL2SQL任务上优于通用聊天模型，但在辅助任务上却遭受了灾难性遗忘的问题，其中特定任务的微调侵蚀了它们的基础推理能力。为了解决这一问题，我们提出了 1+1模型协作范式 ，其中通用聊天模型负责处理推理密集型辅助任务（如模式链接和候选选择），而微调后的SQL专家则专注于查询生成。这种协作利用了两种模型的优势：通用模型提供广泛的推理能力，而专家模型则提供领域特定的精确性。实验确认该范式提高了整体性能。我们的主要贡献如下：

1. 我们引入了Feather-SQL，这是一个专为SLMs设计的NL2SQL框架，解决了其可执行性低和与现有基于LLMs的框架不兼容的独特挑战。

2. 我们提出了一种新的1+1模型协作范式，通过将推理密集型任务委派给通用聊天模型，缓解了微调后SLMs的灾难性遗忘问题。

3. 在Spider和BIRD数据集上的广泛实验表明，Feather-SQL与各种SLMs配合使用时表现出色，当与该范式结合时，在SLMs范围内达到了BIRD上的最新结果。

最近，LLMs的出现标志着一个分水岭时刻。基于LLM的NL2SQL方法已经成为领先的解决方案。例如，DIN-SQL将NL2SQL任务分解为子任务，如模式链接、难度分类和SQL生成，从而简化决策并实现更准确的查询输出。CHESS采用多代理框架，每个代理分配一个特定模型和少量示例提示策略来处理不同的子任务。尽管这些方法表现出色，但它们引入了安全风险并导致计算成本大幅增加。

使用SLMs解决NL2SQL任务有潜力缓解上述挑战。CodeS通过增量预训练和双向数据增强微调了一系列模型（1B、3B、7B和15B参数）。专门微调用于NL2SQL任务的模型，如premSQL和SQLCoder，也展示了显著的成功。然而，这些模型仍然容易受到灾难性遗忘的影响，这削弱了它们在更广泛的NL2SQL工作流中执行一般推理任务（如模式链接）的能力。

图3：面向小型语言模型（SLMs）的Feather-SQL框架在NL2SQL任务中的整体架构。该流程包含六个核心模块——模式剪枝（schema pruning）、模式链接（schema linking）、多路径生成（multi-path generation）、多候选生成（multi-candidate generation）、校正（correction）与选择（selection），通过协同工作显著提升查询可执行性与准确率。框架采用"1+1模型协作范式"，将通用对话模型（负责辅助推理）与SQL微调模型（负责查询生成）配对使用，兼顾广泛语境理解能力与领域专用精度。

如图 3所示，我们提出了Feather-SQL以增强SLMs在NL2SQL中的性能。该框架包括几个组件，如模式修剪、多路径和多候选生成，这些组件专门设计用于应对SLMs的挑战。我们将在以下部分详细说明这些组件。

模式修剪。 此步骤通过识别和过滤掉无关表动态减少模式复杂度。给定所有表的完整DDL语句集合，模型分析语义相关性以确定哪些表与问题相关。只有这些相关表的DDL保留在后续处理管道中。这种选择性保留机制防止SLMs处理长输入，从而减轻其处理长文本的局限性，同时保留关键信息。

模式链接。 此步骤通过语义分析识别相关列，将问题与数据库模式对齐。作为一种常用实践，模式链接根据给定问题从完整模式中提取相关列，促进下游处理。通过在自然语言表达和数据库元素之间建立精确映射，此过程显著提高了SQL生成的准确性。

多路径生成。 此步骤采用四种不同的提示类型：（1）同时使用模式链接和修剪，（2）仅链接，（3）仅修剪，（4）不进行任何操作。多路径设计减轻了修剪错误导致的信息损失风险，并减少了链接不准确引起的潜在误解。

多候选生成。 此步骤并行生成多个SQL查询，以增加生成正确结果的可能性。为确保多样性，采用了 波束搜索 ，并仔细调整了温度和top-p参数。每条路径始终生成固定数量的候选查询，保持对可能解决方案的平衡探索。值得注意的是，虽然LLMs通常在第一次尝试时就能生成可执行答案，额外候选对准确性的改善有限，而SLMs则从多候选生成中显著受益，这提高了可执行性和准确性（附录 6 ）。

校正。 此步骤执行每个生成的查询，并根据结果进行处理。如果查询成功执行，则直接添加到可执行SQL查询数组中。对于失败的查询，通过自校正方法使用错误反馈生成两个新候选查询。如果这些修订后的查询中有任何可执行的，则也会存储在可执行SQL查询数组中。

选择。 此步骤采用 选择排名 方法，根据预期答案的对齐情况评估所有可执行查询。如果查询产生的结果数量有限，则评估考虑查询及其执行结果。相反，评估仅关注查询本身。选择过程重复三次，返回排名的众数作为最终结果。

提示策略

提取。 如第 1 节所述，SLMs难以满足结构性约束，因此我们提出了一种提取策略，通过允许SLMs自由生成响应来避免刚性结构输出。这种方法通过绕过语法约束提高了推理任务的准确性。我们有两种方法来实现这一点： (1) 词法匹配： 该方法通过匹配自然语言响应中明确提到的表/列名与数据库模式来识别有效的模式元素。例如，当SLM输出“所需表包括客户和订单”时，系统仅验证并提取客户/订单，前提是它们存在于模式中。 (2) 模式匹配： 该方法通过识别模型输出中的预定义模式（如“答案是”或“Answer:”）提取最终答案。例如，如果模型生成“答案是128”，框架检测该模式并提取“128”作为最终结果。

简化。 简化策略通过最小化提示冗余来减少计算开销。在Feather-SQL中，我们通过去除多余细节并使用最少有效示例的简洁指令来实现这一点（附录 7 ）。这种方法通过消除不必要的复杂性来优化输入，避免SLMs处理长输入，同时保持任务清晰。

1+1协作范式

我们的范式将NL2SQL流水线任务分为两类：推理密集型任务和SQL生成任务。推理任务（如模式链接和候选评估）需要强大的上下文理解和适应性，而SQL生成则要求精确的查询合成。为了优化性能，我们使用两个专用模型：通用聊天模型用于推理任务，SQL微调模型用于SQL生成。通过利用它们的互补优势，我们的方法提高了整体NL2SQL的准确性和鲁棒性。

通用聊天模型。 该模型专为推理密集型任务设计，利用广泛的语言和上下文理解能力，而不进行领域特定的微调，这有助于防止灾难性遗忘。与SQL专家模型相比，它在模式链接和评估SQL候选方面更为有效，确保SQL生成过程由准确且结构良好的上下文信息引导。

SQL微调模型。 该模型专为SQL生成优化，经过大规模NL2SQL数据集的广泛训练，能够在SQL特定任务上实现卓越性能。其专注的训练减少了幻觉现象，提高了查询的可执行性和准确性。

表2：不同方法在Spider TEST数据集上的执行准确率（EX）与执行比例（EP）对比。执行准确率的最优和次优结果分别用粗体和_下划线_标出，带∗号表示采用抽取策略的结果。

表3：各方法在BIRD DEV数据集上的执行准确率(EX)与执行比例(EP)对比。最优和次优结果分别用加粗和下划线标出，带*号表示采用抽取策略的结果。

主要结果

为了验证Feather-SQL对SLMs的一般有效性，我们在两个数据集上对一系列模型进行了实验（此处所有结果均使用统一模型获得，未采用协作范式）。

BIRD 结果。如表3 所示，Feather-SQL在所有通用聊天模型中表现出优越性能，在EX和EP两项指标上均取得最高分，与FEQ相比，EX平均提升约10%，EP超过20%。对于SQL微调模型，Feather-SQL与CodeS结合在EX和EP上均实现显著提升，而Prem-SQL在EP方面表现尤为突出，与FEQ相比平均提升约5%。

此外，我们观察到CHESS和MAC-SQL在SLMs上效果不佳，它们在Qwen2.5和Yi-Coder上的EX和EP得分甚至低于DR。它们的表现也落后于FEQ。

Spider 结果。同样，表2展示了SPIDER TEST数据集上的结果，进一步证实我们的框架一致且显著提升了SLMs的NL2SQL性能。

尽管MAC-SQL和CHESS在不同模型上的表现不一致，MAC-SQL总体表现较好。值得注意的是，应用提取后，SQL微调模型在EX上表现最佳，突显了该步骤对SLMs的重要性。这可能是由于MAC-SQL的选择机制也采用了模式修剪。与我们的表修剪方法不同，MAC-SQL采用列修剪，这在SPIDER相对简单的模式结构中可能更为有效。

如表3所示，虽然Feather-SQL提高了Prem-SQL的EP，但其EX比FEQ下降了2%。这一下降主要是由于Prem-SQL无法处理辅助推理任务。为了解决这一限制，我们提出任务分工，让通用聊天模型处理辅助推理，而SQL微调模型专注于SQL生成。

表4：FeatherSQL框架在BIRD DEV数据集上的范式性能表现。当未指定对话模型时，SQL模型将同时兼任对话模型功能。

如表4所示，我们的1+1协作范式在Feather-SQL下使Prem-SQL和CodeS的EX提高了3-6%，其中Prem-SQL在现有SLMs中达到 SOTA 性能（附录9）。然而，我们观察到EP在搭配聊天模型时有所下降。这是因为当SQL模型在模式修剪期间也被用作聊天模型时，它返回了一个查询而不是预期的答案。但我们的提取策略仍能从输出中检索表名，通常会导致过度修剪的模式——只包含一两个表。虽然简化模式偶尔可以提高EP，但它通常会降低整体EX。

表5：CHESS框架在BIRD DEV数据集上的范式性能对比。若未指定专用对话模型，系统将自动复用SQL模型作为对话模型使用。

此外，表5显示，我们的范式在CHESS中提高了Prem-SQL和CodeS的性能，EX增加了约20%，EP增加了超过35%（针对Prem-SQL），而CodeS则有较小但一致的EX增益，EP没有明显趋势。

然而，这两种模型因处理辅助任务的方式不同而受益不同。Prem-SQL试图回答链接问题但经常出错，而CodeS由于严重的灾难性遗忘无法提供有效响应。因此，CHESS默认使用原始模式与CodeS配合，减少链接错误。

此外，由于CHESS构建了长提示而没有进行模式修剪，引入聊天模型增加了输入长度和复杂性。虽然这提高了推理能力，但并未完全抵消CodeS处理扩展输入的局限性，限制了其EX的提升。

参考：https://arxiv.org/pdf/2503.1781