自然语言到SQL翻译的螺母与螺栓：模型流水线优化方法及其交互的系统性分析

# 自然语言到SQL翻译的细节：模型流水线优化方法及其交互的系统性分析
**来源：** https://arxiv.org/html/2607.10911

Vasudevan Nedumpozhimana  
ADAPT Research Centre  
Trinity College Dublin  
Dublin, Ireland  
[email protected]

Sneha Rautmare  
ADAPT Research Centre  
Trinity College Dublin  
Dublin, Ireland  
[email protected]

Bora Caglayan  
Huawei Ireland Research Centre  
Dublin, Ireland  
[email protected]

Mingxue Wang  
Huawei Ireland Research Centre  
Dublin, Ireland  
[email protected]

John D. Kelleher  
ADAPT Research Centre  
Trinity College Dublin  
Dublin, Ireland  
[email protected]

###### 摘要

在大语言模型时代，自然语言到SQL（NL2SQL）翻译仍是一个具有许多有用应用场景的开放问题。我们探讨了多种NL2SQL流水线扩展之间的交互，以启发更轻量级模型的开发。具体而言，我们整合了NatSQL中间表示、基于合成数据的预处理步骤和微调步骤，并开发了一种新颖的重排序模型，用于在最终束搜索中改进SQL选择。我们进行了消融研究，并通过Shapley分析补充了这些不同组件与两种骨干架构（SmBoP和RASAT）集成的效果。我们发现，简单地将所有组件组合在一起并不能带来最佳结果，它们的影响取决于与基线系统以及彼此之间的交互。

*关键词：* NL2SQL\\cdot SQL\\cdot 重排序器\\cdot Spider\\cdot 生成模型\\cdot 数据增强\\cdot 优化方法\\cdot 模型架构\\cdot 代码生成

## 1 引言

自然语言到SQL翻译（NL2SQL）是语义解析这一更广泛问题的子任务，其定义为理解自然语言话语的含义并将其映射为可执行的有意义查询。解决NL2SQL问题具有实际应用价值，例如允许将自然语言接口集成到关系数据库管理系统中，从而增强可访问性并改善用户体验。在NL2SQL场景中，给定一个关系数据库和一个自然语言问题（NLQ），目标是找到一个等价的SQL查询，执行该查询后将回答该NLQ。核心挑战在于理解NLQ的含义和意图——由于自然语言的高度复杂性和表现力，NLQ可以通过多种方式表达——并将其翻译成SQL查询，而SQL查询的范围相对较窄，遵循更简单且严格定义的语法和语义规则。因此，NL2SQL仍被认为是一个开放问题。

参见图注

图1：NL2SQL流水线中的优化点。

随着LLM变得越来越大、能力越来越强，将其应用于任何给定任务变得越来越有吸引力。然而，在许多实际应用或生产环境中，这并不总是必要、可行或负责任的，因为模型要么太大、太昂贵，要么功耗太高，无法实际部署。我们认为，领域对齐的、专门的NL2SQL系统尚未达到平台期，我们探索了提高更轻量级模型性能的方法。为此，我们对几种已被证明能提高性能的NL2SQL流水线扩展进行了系统性分析，以了解它们的相对收益以及组合它们的收益。每个扩展都被选为代表NL2SQL流水线不同阶段的最新干预措施，如图1所示。我们研究了以下扩展：使用中间表示、合成数据创建、数据预处理，以及应用最终束搜索重排序器来选出最可能的SQL候选。这些方法已分别被研究过，但从未组合在一起——通过这样做，我们发现了有趣的交互作用，对整体模型性能既有正面也有负面影响，并识别出能带来最大性能提升的组合。

本文的主要贡献是：(a) 对SotA NL2SQL扩展之间交互的系统性研究；(b) 开发了一种新颖的NL2SQL最终束搜索重排序器；(c) 将NatSQL与RASAT和SmBoP集成；(d) 通过Shapley分析量化单个组件在组合中的贡献。我们发现最强的贡献者是NatSQL和我们自己的最终束搜索重排序器，并表明正确的方法组合可以显著提高基线系统的性能上限。

## 2 相关工作

自然语言到SQL翻译研究有着悠久的历史（Kim et al., 2021），从基于规则的方法开始（Zelle and Mooney, 1996）。早期的基于规则的方法使用模板在狭窄定义的应用场景中生成SQL查询，存在可扩展性和泛化性的缺点（Saha et al., 2016）。后来基于序列到序列架构的方法探索了各种技术，例如：基于草图的解码器（Dong and Lapata, 2016; Zhong et al., 2017; Xu et al., 2017）、指针生成解码器（See et al., 2017; Hwang et al., 2019; Lin et al., 2020; Hui et al., 2021）、图神经网络（Wang et al., 2020; Cao et al., 2021）、微调预训练语言模型（Raffel et al., 2020; Scholak et al., 2021; Li et al., 2023），以及最近的大语言模型（Gao et al., 2023; Pourreza and Rafiei, 2023; Dong et al., 2023; Sun et al., 2023; Liu et al., 2023; Wang et al., 2025; Heidari et al., 2025）。虽然最近基于LLM的系统越来越依赖模块化和代理化流水线来将任务分解为多个阶段（Heidari et al., 2025），但我们的工作展示了在非LLM设置中类似分解导向范式的有效性。具体来说，我们将NL2SQL表述为一个包含预处理、合成数据生成、候选生成和重排序阶段的流水线，并表明对这些组件的系统优化比当代非LLM基线带来了实质性改进。

### 2.1 我们的基线模型

从相关工作中，我们选择了两个NL2SQL模型作为实验的基线：RASAT（Qi et al., 2022）和SmBoP（Rubin and Berant, 2021）。我们选择它们的原因是，与今天的LLM相比，它们都更轻量级，但彼此之间在模型架构和大小上非常不同，这可能会揭示与所研究扩展的有趣交互。RASAT利用了T5架构（Raffel et al., 2020）：它是一个变压器序列到序列模型，在编码器中增强了关系感知自注意力，可以利用多种关系结构，同时有效地继承了T5模型的预训练参数。它可以将模式编码、模式链接和问题的句法依赖等关系整合到统一的关系表示中。SmBoP使用GraPPa嵌入（Yu et al., 2020）、RAT-SQL编码器（Wang et al., 2020）以及一种新颖的解码器，该解码器使用关系代数作为中间表示。它是一种半自回归的由下而上解析器，在解码步骤 t 时构造高度 ≤ t 的 top-K 子树。与自上而下的自回归解析相比，由下而上的SmBoP更高效，因为它可以并行解码所有特定高度的子树。此外，它在每一步学习有意义的语义子程序的表示，使其始终能生成有效且可执行的SQL。相比之下，RASAT在解码步骤具有无约束的搜索空间，因此常常生成无效表达式。为了缓解这个问题，RASAT使用了过滤或重排序机制（PICARD, Scholak et al., 2021），有助于确保生成有效的SQL。然而，由于我们正在开发自己的重排序器模块，我们将PICARD从架构中移除，仅与基线RASAT模型进行比较。

## 3 组件集成与评估

我们将不同的扩展视为模块化组件，可以添加到基线NL2SQL系统中或从中移除，从而开发了多种模型架构。我们使用两个基线——SmBoP和RASAT——进行实验，并分别集成每个组件，以及在可能的情况下组合它们，产生了数百种组件组合¹¹。在本节（§3）中，我们简要介绍三个组件的集成和评估：NatSQL中间表示、GAZP数据合成过程以及NL2SQL令牌预处理方法。我们将这些系统作为构建块，开发了一种新颖的重排序器模型，在第4节中介绍。最后，在第5节中，我们结合第3节的系统组件对重排序器模型进行外部评估，以及使用Shapley分析来识别性能最佳的组件。

我们在所有实验中使用Spider NL2SQL数据集（Yu et al., 2018）作为核心数据集，并使用Spider评估脚本²²进行系统评估。该脚本计算两个评估指标来评估SQL输出：精确匹配（EM）和执行准确率（EX）。EM衡量预测查询是否整体与黄金查询等价，只有当所有组件都正确时才被视为正确。EX可以被视为替代指标，因为Spider中的所有数据库都有可执行的SQLite文件，意味着我们可以执行查询并比较输出，而不是比较查询本身。我们在评估结果中同时呈现EM和EX。

### 3.1 NatSQL中间表示

我们将NatSQL中间表示（Gan et al., 2021）与SmBoP和RASAT一起使用，据我们所知，这两者组合在文献中尚未被尝试过。为了训练原始RASAT模型预测NatSQL格式的查询，对于Spider训练集中的每个查询，我们使用Gan等人提供的NatSQL查询作为RASAT模型训练的目标标签。在推理步骤中，我们首先通过训练好的RASAT模型从NLQ预测NatSQL查询，然后使用提供的转换脚本³³将其转换为SQL格式。然而，将NatSQL与SmBoP集成带来了重大挑战。由于SmBoP使用SQL语法生成SQL查询，并且在训练时解析目标SQL查询以计算损失函数，将NatSQL与SmBoP结合需要以所需格式编写NatSQL语法规则，并使用该语法开发NatSQL解析器。我们还探索了将NatSQL与SmBoP集成的不同方式，并开发了三个修改后的SmBoP模型版本，我们称之为NatSmBoP。有关这项开发工作的详细信息包含在附录A中。

文献表明，利用NatSQL的模型始终表现出性能改进，可能是因为NatSQL比原始SQL更简单的表示，因此更容易学习和预测。因此，我们期望在将NatSQL与RASAT和SmBoP结合时观察到相同的行为。我们的结果表明，将NatSQL与RASAT一起使用显著提高了性能（EX提升0.9%，EM提升1%），但令人惊讶的是，将其与SmBoP一起使用相对于其原始基线显著降低了性能（EX下降3.7%，EM下降1.7%；完整结果表见附录E）。将RASAT与NatSQL结合带来的改进表明，对于正确的模型来说，它可以是一个有价值的补充。为了简化论文并一定程度上减少可能的评估数量，我们对上述确定的最佳系统进行进一步实验，即原始SmBoP和集成了NatSQL的RASAT（我们将其称为NatRASAT）。

### 3.2 GAZP合成数据微调

我们实现了一个称为GAZP（Grounded Adaptation for Zero-shot Executable Semantic Parsing，基于基础的零样本可执行语义解析自适应）的合成数据生成示例（Zhong et al., 2020）。它能够仅基于给定的数据库和模式生成领域内的合成NLQ-SQL对。为了为Spider生成合成数据，我们首先遵循Zhang等人（2019）的步骤对SQL逻辑形式进行预处理，并使用作者提供的GAZP代码⁴⁴。我们使用GAZP生成了40,875个合成NLQ-SQL对，但发现其中18,458个是重复的（45.16%），并且随着生成样本数量的增加，重复率急剧上升。去除重复样本以过滤掉冗余样本是改进合成数据质量的直接方法（Lee et al., 2022; Almazrouei et al., 2023），因此我们移除了所有重复条目。为了从剩余的合成数据中获得最大收益，我们探索了两个变量：在不同合成数据集大小和不同SQL难度分布上进行训练。经过一些实验，我们发现使用最大量的合成数据可提供最佳性能（附录B中的数据）。因此，在我们的评估中，我们使用了所有去重后的GAZP数据，即22,417个唯一合成样本。然后，我们通过首先在所有可用的去重合成数据上训练基线模型，然后在人工生成的黄金标准Spider数据上对该模型进行微调，将合成GAZP数据集成到模型中。这使我们能够在有些噪声的合成样本上训练更强的基线，然后通过在黄金标准Spider数据上进行微调来将后续推理引导到正确的方向。我们观察到，相对于原始SmBoP（EX提升1.7%，EM提升1.5%）和NatRASAT（EX提升2.5%，EM提升2.3%），均有显著改进；完整结果见附录E）。

### 3.3 预处理

最终NL2