自然语言到SQL的曙光：我们准备好了吗？

原论文：https://arxiv.org/pdf2406.01265

Boyan Li, Yuyu Luo*, Chengliang Chai, Guoliang Li , Nan Tang

摘要

将用户的自然语言问题转换为SQL查询（即nl2sql）显著降低了访问关系数据库的门槛。大型语言模型的出现引入了nl2sql任务的新范式，大幅提升了能力。然而，这引发了一个关键问题： 我们是否已准备好在生产环境中部署nl2sql模型？

为了解决这些问题，我们提出了一个多角度的nl2sql评估框架， NL2SQL360 , 以帮助研究人员设计和测试新的nl2sql方法。通过 NL2SQL360 , 我们对领先的nl2sql方法进行了详细比较，涵盖了不同的应用场景，如不同的数据域和sql特性，为选择最适合特定需求的nl2sql方法提供了宝贵的见解。此外，我们探讨了nl2sql的设计空间，利用 NL2SQL360 自动化识别最优的nl2sql解决方案，以满足用户的具体需求。具体而言， NL2SQL360 识别出一个有效的nl2sql方法, SuperSQL , 在Spider数据集上使用执行准确率指标表现优异。 值得注意的是， SuperSQL 在Spider和BIRD测试集上的执行准确率分别达到了 87% 和 62.66% 。

PVLDB参考格式：
Boyan Li, Yuyu Luo, Chengliang Chai, Guoliang Li, Nan Tang. PVLDB, 17(11): 3318 - 3331, 2024.
doi:10.14778/3681954.3682003 1

1 引言

Nl2sql方法概述。

基于PLM和LLM的nl2sql模型的发展。

Natural Language to SQL (nl2sql)，即将自然语言查询（nl）转换为SQL查询（sql），可以显著降低普通用户和专家用户访问大规模数据集并从中获取洞察的障碍 (Gu et al. 2023; Z. Chen et al. 2023; L. Wang et al. 2022; A. Liu et al. 2022; Pourreza and Rafiei 2023; Gao et al. 2024; H. Li et al. 2023; Luo, Qin, Tang, Li, and Wang 2018; Luo, Qin, Tang, and Li 2018; Luo et al. 2021; Luo, Tang, et al. 2022; J. Tang et al. 2022; Y. Xie et al. 2024; Luo, Qin, et al. 2022; Shen et al. 2021; X. Liu et al. 2024) . 尤其是由于最近大型语言模型的进步，nl2sql解决方案的性能得到了显著提升。提供nl2sql解决方案的趋势已经从神话变成了必须。

尽管在解决nl2sql方面做出了许多努力，但仍有许多重要问题需要解决，例如我们现在处于什么位置，接下来研究人员应研究哪些nl2sql主题，以及实践者应将哪种方法应用于特定应用——本文系统地考察并回答了这些问题。

图 1 显示了过去二十年nl2sql方法的演变，从基于规则的方法、基于深度神经网络的方法、可调预训练语言模型（PLMs），到巨型大型语言模型（LLMs），伴随着像Spider (Yu et al. 2018) 和 BIRD (J. Li, Hui, Qu, et al. 2023) 等基准的发展。请注意，LLMs（例如，GPT-4 (OpenAI 2023) 和 Llama2 (Touvron et al. 2023) ) 相比于PLMs（例如，GPT-2 (Radford et al. 2019) 和 BART (Lewis et al. 2020) ) 更大，并表现出更高级的语言理解和新兴能力 (Minaee et al. 2024; N. Tang et al. 2024; Ye et al. 2024; Zhu et al. 2024) 。将PLMs用于nl2sql任务需要在特定任务数据集上进行微调，而使用LLMs则可以通过提示（上下文学习）或对于开源LLMs进行微调（即指令跟随）来实现 (Zhao et al. 2023) 。

图 2 比较了基于PLM（蓝点）和基于LLM（绿点）的nl2sql模型在Spider排行榜上的准确性 (Yu et al. 2018) 。它显示，基于LLM的nl2sql模型始于2023年2月（DIN-SQL + CodeX），其准确性与基于PLM的模型相当。然而，随着LLM的快速发展，基于LLM和基于PLM的模型之间的性能差距正在扩大，突显了基于LLM方法的优势。

基于图 2 , 我们可以得出结论，基于LLM的模型是任何nl2sql应用的“首选”吗？ 换句话说，选择排行榜上排名最高的模型总是最佳策略吗？

正确回答这个问题对于帮助 研究人员 和 实践者 根据不同需求设计和选择正确的模型至关重要。让我们考虑经典的商业智能（BI）用例。

[ 各种数据域。 ] BI平台如Tableau ( “ TABLEAU SOFTWARE, LLC, A SALESFORCE COMPANY ” 2024) 经常具有各种数据库域（例如，电影和体育）的独特模式和术语。理想的nl2sql模型必须能够跨这些不同领域进行泛化，同时适应每个特定领域以有效满足临时需求。

[ 复杂的SQL操作。 ] 现实世界的应用程序通常需要执行涉及高级操作的复杂sql查询，如多个 JOIN 、嵌套查询和聚合函数。准确生成复杂查询的能力是评估nl2sql模型的重要标准。

[ 新的语言现象。 ] 对于相同的查询意图，不同用户可能会提出带有不同缩写、同义词和问题风格的nl查询。因此，nl2sql模型准确解释各种nl查询变体的能力至关重要。

示例1 . 图 [fig:leaderboard] 从不同角度比较了Spider开发数据集上的最先进PLM和LLM模型的执行准确性。

\([\) 各种数据域 \(]\) 图 [fig:leaderboard] (a) 比较了不同模型在 竞赛 域中的表现。 结果显示，基于微调的LLM/PLM方法优于所有基于提示的LLM方法。特别是，最佳的PLM方法RESDSQL-3B \(+\) NatSQL (H. Li et al. 2023) 实现了 \(83.9\%\) 的执行准确性，比最佳的基于提示的LLM方法DAILSQL（使用GPT-4） (Gao et al. 2024) 高出了 \(3.3\%\) 。上述观察表明，微调是增强nl2sql模型领域适应能力的关键策略。

\([\) 复杂的SQL操作 \(]\)

图 [fig:leaderboard] (b) 比较了仅包含 sql 查询中 JOIN 操作的不同模型。结果显示，基于PLM的方法RESDSQL-3B \(+\) NatSQL (H. Li et al. 2023) 位居榜首，优于所有基于LLM的方法。

然而，当我们比较仅包含嵌套 sql 查询的不同方法时，如图 [fig:leaderboard] (c) 所示，我们发现基于LLM的方法通常优于基于PLM的方法。

\([\) 新的语言现象 \(]\) 我们还计算了不同语言现象（例如，“ 返回总消费大于1000的所有客户 ” vs. “ 花费超过1,000的客户列表是什么？ ”）的平均准确性。 图 [fig:leaderboard] (d) 显示，尽管两种类型的方法都表现良好，但针对nl2sql微调的LLM和PLM优于用于nl2sql的提示LLM。这主要是因为微调后的模型能更好地将不同的查询变体与数据库模式对齐。 \(\Box\)

示例 1 显示 一种尺寸并不适合所有情况 ; 即使由目前最强大的LLM GPT-4支持，也没有一种nl2sql模型能在不同使用场景中成为明显的赢家。事实上，现实世界的场景远比公共nl2sql基准测试（如Spider和BIRD）所能检验的复杂得多。 因此，迫切需要工具来帮助从不同角度系统地评估给定基准测试中的nl2sql模型。

在 Q1 和 Q2 之后的问题是：如果在不同场景中没有单一的胜利者，我们能否设计一个结合PLMs和LLMs优点并在不同场景中稳健的超级nl2sql模型？

在本文中，我们提出了 NL2SQL360 , 一个用于系统评估基于PLM和LLM的nl2sql模型的测试平台。 NL2SQL360 可以帮助研究人员和实践者在其特定场景中更好地评估nl2sql模型，揭示有见地的实验结果，并设计一个比现有解决方案更稳健的nl2sql模型。我们的贡献如下。

我们设计了一个测试平台 NL2SQL360 , 用于细粒度评估nl2sql解决方案。 NL2SQL360 可以评估不同nl2sql方法在既定基准或根据特定标准（例如，不同的数据域或sql特征）定制其评估中的表现。（第 3 节）

我们在Spider和BIRD数据集上测试了13种基于LLM和7种基于PLM的nl2sql解决方案，在15种不同设置下分析它们在各种使用场景中的性能（第 4 节）。主要发现如下：

1. 准确性。 微调对于提高性能至关重要。具体来说，基于LLM的方法在EX指标上表现更好，而基于PLM的方法在EM指标上表现更好。此外，基于PLM/LLM的方法可以在具有特定特征的子集中脱颖而出。例如，使用GPT-4的方法在子查询上表现尤为出色。
2. 自然语言查询变化。 对于从不同nl查询生成相同目标sql，经过特定场景数据微调的LLMs和PLMs表现出更强的稳定性。
3. 领域适应性。 对于不同领域的nl2sql任务，基于LLM和基于PLM的方法之间没有明确的胜者。 但是，微调过程中使用领域内数据对于特定领域的模型性能至关重要。
4. 预训练语料库的影响。 实验表明，经过微调后，基于代码特定数据集预训练的LLMs（如CodeLlama-7B、StarCoder-7B和Deepseek-Coder-7B）在nl2sql任务中优于基于一般文本训练的Llama2-7B。这突显了LLM预训练数据域或其内在编码能力对其在专门任务（如nl2sql）性能的显著影响。

我们系统地分类和分析了基于LLMs和PLMs最具代表性的nl2sql模块，强调它们的共同点和独特特征。在此基础上，我们提出了 SuperSQL , 其在Spider测试集上的执行准确率为 87% , 在BIRD测试集上的执行准确率为 62.66% 。（第 5 节）

基于我们的实验结果、设计空间探索以及 SuperSQL 的实现和测试，我们确定了三个未来的研究机会：i) 增强nl2sql方法的可信度，包括处理模糊的nl查询、诊断nl查询与预测sql的匹配情况，并将查询结果解释回nl查询；ii) 开发成本效益高的nl2sql解决方案；iii) 根据评估结果自动自适应地生成训练数据（nl，sql）。 （第 6 节）

2 自然语言到SQL

接下来，我们将通过分类最近基于LLM/PLM的nl2sql解决方案来描述相关工作，并在本节末尾讨论现有工作的局限性。

2.1 相关工作：鸟瞰图

图 1 展示了nl2sql技术的进化树，分为四个主要分支：基于规则的方法、基于神经网络的方法、基于PLM的方法和基于LLM的方法。

早期的工作依赖于预定义的规则或语义解析器 (Rajkumar, Li, and Bahdanau 2022; F. Li and Jagadish 2014; Katsogiannis-Meimarakis 和 Koutrika 2023, 2021) 。例如，NaLIR (F. Li and Jagadish 2014) 使用语法解析器和手工编写的规则将nl查询转换为sql查询。然而，这些方法在适应性、可扩展性和泛化方面有限。

为了解决这些局限性，研究人员开始使用神经网络将nl查询转换为sql查询。发布了几个大型基准数据集，如WikiSQL (Zhong, Xiong, and Socher 2017) 和 Spider (Yu et al. 2018) 。序列到序列nl2sql方法如IRNet (J. Guo et al. 2019) 被开发出来。IRNet使用编码器对nl查询和数据库模式进行编码，并使用解码器生成sql查询。

大约在2017年，Transformer (Vaswani et al. 2017) 和 Spider 数据集的引入导致了基于神经网络的方法的兴起，很快主导了该领域。像BERT (Devlin et al. 2019) 和 T5 (Raffel et al. 2020) 这样的模型在基准数据集上取得了顶级结果 (J. Li, Hui, Cheng, et al. 2023; H. Li et al. 2023; Scholak, Schucher, and Bahdanau 2021) 。例如，Spider排行榜上的顶尖选手RESDSQL (H. Li et al. 2023) 采用了一个两阶段框架：首先从nl查询中识别相关的模式元素，然后构建sql查询。

像ChatGPT和GPT-4 (OpenAI 2023) 这样的大型语言模型的出现彻底改变了nl2sql解决方案。基于LLM的方法现在主导了nl2sql领域 (Pourreza 和 Rafiei 2023; Gao et al. 2024; Dong et al. 2023; H. Li et al. 2024; B. Wang et al. 2023) 。例如，DAIL-SQL (Gao et al. 2024) 使用GPT-4进行提示工程，在Spider数据集上取得了竞争性结果。

鉴于nl2sql进化树中观察到的增长趋势，我们预计基于LLM/PLM的nl2sql方法在未来几年将继续主导该领域。因此，充分理解这些nl2sql方法的能力、局限性和潜在改进非常重要。

表 [tab:taxonomy] 根据骨干模型和几个关键组件对最先进的nl2sql方法进行了分类。简而言之，最近的竞争性方法采用语言模型作为nl2sql翻译的骨干，要么使用像GPT-4这样的大型API基础大型语言模型，要么使用像T5和Llama这样的可调语言模型。

模式链接模块对于nl2sql过程至关重要，因为它通过结合数据库内容增强了生成的sql查询的准确性和相关性。这强调了理解数据库模式和内容对于nl2sql任务的重要性。在sql生成过程中，基于PLM的方法使用类似束搜索的策略（例如，PICARD (Scholak, Schucher, and Bahdanau 2021) ) 来在sql语法约束内找到最佳标记，而基于LLM的方法使用贪婪策略。对于后处理，基于LLM的方法采用启发式提示策略，如自我纠正和一致性验证，以优化输出，使其更好地匹配预期的sql查询。

2.2 现有的实验及其局限性

有几个与我们的研究相关的实验研究。例如，Gao等人 (Gao et al. 2024) 通过提示工程评估了开源LLMs在nl2sql任务中的潜力。Rajkumar等人 (Rajkumar, Li, and Bahdanau 2022) 探讨了Codex语言模型在零样本和少样本设置下处理nl2sql任务的能力。Gkini等人 (Gkini et al. 2021) 深入评估了基于解析和基于关键词的nl2sql。前两项研究主要集中在评估基于LLM的nl2sql解决方案，而第三项研究调查了基于解析的nl2sql方法。

现有实验有几个局限性。

1. 忽视使用场景。 现有的评估通常报告整个基准数据集（例如，Spider）上的整体结果。虽然这提供了广泛的概览，但在特定子集的数据上提供详细比较有所不足（参见图 [fig:leaderboard] )。例如，我们可以根据不同的sql特征或数据库域过滤评估数据集，这可能为不同nl2sql模型在特定sql查询类型或领域特定场景中的相对有效性提供有价值的见解。
2. 缺乏直接和全面的比较。 一个主要的局限性是许多最近的nl2sql解决方案，尤其是基于LLM和PLM的解决方案，尚未在公认的基准和定制数据集上进行系统的比较。
3. 对nl2sql设计空间的探索有限。 当前的nl2sql研究和实践中对nl2sql框架设计空间的探索有限，限制了我们对来自LLM和PLM的不同架构和功能模块如何协同增强nl2sql解决方案的理解。

3 NL2SQL360: 用于NL2SQL的测试平台

图 3 显示了我们测试平台 NL2SQL360 的框架，包括以下六个核心组件，如下所述。

NL2SQL360概述。

此模块维护广泛使用的基准：Spider (Yu et al. 2018) , BIRD (J. Li, Hui, Qu, et al. 2023) , Spider-Realistic (Deng et al. 2021) , Dr.Spider (Chang et al. 2023) , KaggleDBQA (Lee, Polozov, and Richardson 2021) , WikiSQL (Zhong, Xiong, and Socher 2017) 等。

此模块托管了一系列在Spider和BIRD排行榜上表现优异且开源的nl2sql模型。主要包括基于LLM和PLM的方法。

传统的评估方法，即在整个基准数据集上平均性能，忽略了不同场景下nl2sql的细微见解（第 1 节）。为了解决这个问题，我们选择特定的基准子集，包括特定数据库、nl和sql查询，突出显示独特的特征，如查询复杂性、数据库模式多样性以及sql特性（例如 JOIN 操作或嵌套查询）。

因此，我们在 NL2SQL360 中引入了一个数据集过滤机制。这允许根据各种标准将测试数据集分割成更集中的子集：

1. 场景-1：SQL复杂度 。该场景根据复杂度区分sql查询，从简单到涉及多个子句和条件的复杂查询。分类遵循Spider (Yu et al. 2018) 建立的标准，旨在评估nl2sql方法处理不同难度sql查询的能力。
2. 场景-2：SQL特性 。它检查主要使用特定功能的sql查询，例如 JOIN 操作、子查询或聚合函数。通过根据这些特性对查询进行分类，我们可以评估nl2sql系统处理不同sql功能的能力。 例如，商业智能平台通常处理带有嵌套子查询的分析查询。
3. 场景-3：数据域 。此场景探索系统在不同数据域（如金融、医疗保健和零售）上的表现。通过根据其数据域对nl2sql数据库进行分类，我们提供了一个结构化的框架，用于评估特定领域的功能和潜在局限。
4. 场景-4：查询变体测试 。它评估nl2sql系统在处理自然语言查询变化时的稳健性和灵活性。它测试nl2sql系统对不同表达方式和结构的响应，衡量用户友好性和适应不同语言风格的能力。我们使用来自nl2sql数据集的各种自然语言查询作为测试样本。

我们支持一系列广泛接受的指标。具体来说，我们采用 执行准确性 （EX）和 精确匹配准确性 （EM） (Yu et al. 2018) 来评估生成的SQL查询的有效性。此外，我们使用 有效性效率得分 （VES） (J. Li, Hui, Qu, et al. 2023) 来衡量生成有效sql查询的效率。

为了进一步评估nl2sql解决方案在处理自然语言查询变化方面的稳健性和灵活性，我们提出了一种新的指标，称为 查询变体测试 。该指标评估模型适应不同形式nl查询的能力。

计算 QVT 准确性的公式定义如下：

其中：

用户可以自定义nl2sql模型的评估工作流，设置超参数和指标。测试平台会自动在基准（例如，Spider）和自定义子集（例如，嵌套查询）上运行这些模型，并记录每次的结果。这些日志提供了有关每个模型性能的详细见解，作为模型分析的资源。

利用日志数据， Evaluator 会自动生成易于解释的定量评估，以表格或排行榜的形式呈现。此外，我们的测试平台还提供可视化工具和仪表板，供用户交互式分析，允许跨数据库域和sql特性维度比较nl2sql解决方案。

4 实验

4.1 实验设置

我们使用Spider (Yu et al. 2018) 和 BIRD (J. Li, Hui, Qu, et al. 2023) 的开发集作为实验数据集，它们分别包含1034和1534个（nl，sql）样本。BIRD数据集中的sql结构比Spider更复杂，并包含一些Spider未涵盖的关键字，如 CASE 、 IIF 等。这种额外的复杂性对模型的nl2sql能力提出了挑战。此外，BIRD中的数据库比Spider更复杂，如表 [tab:dataset_compare] 所示。

我们评估最先进的开源LLM和PLM基础的nl2sql方法。

我们比较了4种基于提示的方法 ：

(1) DINSQL (Pourreza and Rafiei 2023) 将sql查询的生成分解为不同的子问题，并为每个子问题设计不同的提示，以指导GPT-4生成最终的sql查询。

(2) DAILSQL (Gao et al. 2024) 将问题和数据库模式编码为sql代码风格。它根据结构相似性和查询相似性选择少量示例。这些元素被组合成一个高效的提示，以指导GPT-4。

(3) DAILSQL(SC) (Gao et al. 2024) 是DAILSQL的版本，采用自我一致性（SC）策略进行后处理。

(4) C3SQL (Dong et al. 2023) 使用模式链接过滤和定制校准偏差提示与GPT-3.5一起生成sql查询，并结合自我一致性策略进行后处理。

我们评估了9种基于微调的方法。

(5-8) SFT CodeS (1B/3B/7B/15B) (H. Li et al. 2024) : CodeS是基于StarCoder (R. Li et al. 2023) 增量预训练的，使用大量与SQL相关的语料库，已经在许多具有挑战性的nl2sql基准上表现出色。在以下实验中，我们使用的是在Spider或BIRD数据集上微调后的SFT CodeS。有 4 个版本的SFT CodeS系列模型参与实验。

(9) Llama2-7B (Touvron et al. 2023) 使用Meta优化的Transformer作为自回归语言模型，预先训练在一个庞大的语料库上。

(10) Llama3-8B (AI@Meta 2024) 在超过15T标记的数据集上训练——其训练数据集是用于Llama 2的7倍大，其中包括4倍多的代码。

(11) StarCoder-7B (R. Li et al. 2023) 是一个基于GitHub许可数据训练的代码LLM。数据涵盖了广泛的内容，包括来自80多种编程语言的代码、Git提交、GitHub问题和Jupyter笔记本。

(12) CodeLlama-7B (Rozière et al. 2023) 是Llama2的一个增强版本，通过在代码仓库数据集上进行额外训练而改进。

(13) Deepseek-Coder-7B (D. Guo et al. 2024) 是在一个项目级别的代码语料库和填空任务上训练的，以提高代码补全能力。

我们评估了7种最先进的方法：

(1) Graphix-3B+PICARD (J. Li, Hui, Cheng, et al. 2023) 将预训练的T5-3B转换器与图感知增强相结合，用于nl2sql任务，并利用PICARD (Scholak, Schucher, and Bahdanau 2021) 提升性能。

(2-4) RESDSQL(Base/Large/3B) (H. Li et al. 2023) 引入了排名增强编码和骨架感知解码，以分离模式链接和骨架解析。

我们在执行准确性（EX）、精确匹配准确性（EM）、查询变体测试（QVT）、有效性效率评分（VES）、标记效率和延迟指标上评估不同方法。

所有实验均在配备512GB RAM和两颗40核Intel(R) Xeon(R) Platinum 8383C CPU @ 2.70GHz的Ubuntu 22.04.3 LTS服务器上进行。对于监督微调LLM实验，我们使用8块NVIDIA A800（80GB）GPU进行模型微调。

4.2 准确性评估实验

我们在Spider和BIRD开发集上通过改变sql复杂度来评估所有方法。我们计算了执行准确性（ EX )和精确匹配准确性（ EM )指标。 注意，我们重新训练了RESDSQL并仅在BIRD训练集上进行了训练，但没有包括NatSQL，因为缺少代码。此外，由于GPT资源限制，我们省略了DINSQL。

表 [tab:overall_spider] 和 表 [tab:overall_bird] 报告了结果。特定SQL复杂度下的最高状态（SOTA） EX 和 EM 分别用 橙色 和 蓝色 标记。

如表 [tab:overall_spider] 和 表 [tab:overall_bird] 所示，我们发现基于LLM的方法在不同难度子集上的EX超过了基于PLM的方法。特别是在表 [tab:overall_bird] 中，DAILSQL(SC) 在“挑战”子集上优于LLM基础的最佳方法SFT CodeS-15B，这可能得益于GPT-4更强的推理能力。

在表 [tab:overall_spider] 中，我们发现经过监督微调的LLM方法通常在EM性能上高于基于提示的LLM方法。微调后，LLM和PLM基础模型的输出更接近特定数据集的数据分布，从而预测出类似于此数据集中的sql结构。

发现1. 微调是提高性能的重要策略。具体而言，经过微调的LLM方法在EX指标上取得了最佳整体结果，而PLM方法在EM指标上总体表现最佳。

现实世界的应用程序经常需要生成涉及高级操作的sql查询，如子查询、逻辑连接符、 ORDER BY 和多个 JOIN 。因此，我们将评估nl2sql模型准确生成具有不同特征的sql查询的能力。

为此，我们根据四个标准对sql查询进行分类：(1) 是否存在子查询，(2) 逻辑连接符的数量，(3) 使用 ORDER BY ，(4) JOIN 的数量。请注意，我们的 NL2SQL360 支持根据单独的sql子句、它们的组合或用户定义的条件对sql查询进行过滤。然而，由于篇幅限制，我们只展示了四个代表性方面。我们在这些sql查询的四个子集上运行所有方法，并计算其EX指标。

我们根据LLM方法分为基于提示和基于微调两类。图 [fig:ex_boxplot] 显示了Spider和BIRD数据集子集上的EX性能分布。图 [fig:heatmap_spider] 和 [fig:heatmap_bird] 提供了详细结果。条形图显示了每种方法的整体EX，方法位于x轴，子集位于y轴。

Exp-2.1: #-子查询。

如图 [fig:heatmap_spider] 和 图 [fig:heatmap_bird] 所示，所有方法在子查询情况下表现最差，表明通过子查询进行推理是一项艰巨的任务。图 [fig:ex_boxplot] 显示，在没有子查询的情况下，基于LLM的方法在Spider上略微优于基于PLM的方法，而在BIRD上则显著优于PLM方法。在涉及子查询的情况下，基于LLM的方法在两个数据集上都表现出色。

这是因为生成带子查询的sql需要模型首先考虑子查询，然后生成整个sql，这需要强大的推理能力。我们发现所有基于LLM的方法，尤其是由GPT-4提示的方法，在子查询上表现更好，超越了微调后的LLM方法和PLM方法。这表明模型的内在推理能力对于处理带子查询的sql至关重要。

发现2. 在涉及子查询的场景中，基于LLM的方法总体上优于基于PLM的方法，特别是使用GPT-4（即基于提示的LLM）的方法表现尤为出色。模型的内在推理能力可能是成功预测子查询的关键。

Exp-2.2: #-逻辑连接符。 逻辑连接符（例如， AND , OR )用于连接条件、筛选查询结果和其他操作，因此理解模型在这方面的表现非常重要。

在没有逻辑连接符的情况下（图 [fig:ex_boxplot] ），基于LLM的方法在Spider数据集上并不优于基于PLM的方法。然而，在更复杂的BIRD数据集（表 [tab:dataset_compare] )上，基于LLM的方法表现出色。当需要逻辑连接符时，基于LLM的方法在两个数据集上始终优于基于PLM的方法。

发现3. 在需要逻辑连接符的场景中，基于LLM的方法优于基于PLM的方法。

Exp-2.3: #-JOIN。 在许多使用场景中，我们需要生成跨越多个表的sql查询。这挑战了模型正确理解复杂数据库模式的能力。

如图 [fig:ex_boxplot] 所示，在不涉及 JOIN 操作的情况下，基于LLM和基于PLM的方法在Spider和BIRD上的表现参差不齐，没有明显的胜者。图 [fig:heatmap_spider] 和 图 [fig:heatmap_bird] 提供了类似的见解。

然而，对于需要 JOIN 操作的场景，基于LLM的方法在两个数据集上都优于基于PLM的方法。这可能是由于 JOIN 操作需要理解复杂的数据库模式，而LLMs通常在这方面表现出色，因为它们具有更好的上下文理解能力。

在图 [fig:heatmap_spider] 中，对于带有 JOIN 的sql查询，DINSQL在基于提示的方法中表现最佳，而RESDSQL-3B+NatSQL在基于PLM的方法中表现最佳。两者都使用NatSQL (Gan et al. 2021) 作为中间表示，可能受益于其简化形式，省略了 JOIN 关键字并减少了模式项预测，从而简化了 JOIN 场景中的sql预测。

发现4. 在涉及 JOIN 操作的场景中，基于LLM的方法优于基于PLM的方法。采用NatSQL作为中间表示可以减少预测JOIN操作的复杂性，从而可能提高模型性能。

Exp-2.4: #-ORDER BY。 如图 [fig:ex_boxplot] 所示，我们观察到在没有 ORDER BY 子句的情况下，基于LLM的方法在Spider和BIRD数据集上均优于基于PLM的方法。然而，在带有 ORDER BY 子句的情况下，基于LLM的方法在Spider数据集上的表现不如基于PLM的方法，但在BIRD数据集上则优于PLM方法。这种差异可能是因为BIRD数据集比Spider数据集更复杂。

发现5. 在涉及 ORDER BY 子句的场景中，基于PLM/LLM的方法在不同数据集上的表现各异。总体而言，基于LLM的方法表现出更强的泛化能力。

QVT vs. 执行准确性（EX）。

EX vs. 不同领域在Spider上的表现。

我们评估了nl2sql系统对多样化自然语言措辞和结构的适应性，反映了实际应用中的多样性。 注意，BIRD数据集中很少有多个对应nl查询的sql查询。因此，我们使用Spider Dev集构建QVT数据集，因为它包含469个对应于两个以上不同nl查询的sqls，符合QVT的目的。我们根据公式 [eq:qvt] 计算QVT分数。

如图 4 所示，基于LLM的方法和基于PLM的方法在QVT方面没有明确的胜者。然而，微调后的LLM通常表现出更高的QVT，这可能是由于微调后模型输入与特定数据分布的对齐，减少了nl变化对性能的影响。值得注意的是，尽管Graphix+PICARD方法在整体EX上不如所有基于提示的方法，但在QVT上却超过了它们。

发现6. 在QVT方面，基于LLM的方法和基于PLM的方法之间没有明确的胜者。使用特定数据集微调模型可能有助于稳定其对nl变化的性能。

在实际的nl2sql应用中，场景通常涉及特定领域的数据库，如电影或体育，每个领域都有独特的模式设计和术语。评估不同方法在不同领域上的详细性能对于有效应用模型至关重要。我们将Spider训练集中的140个数据库和开发集中的20个数据库分类为33个领域。所有微调的LLM和PLM都使用训练集进行调整。 图 5 (a) 显示了Spider数据集中不同数据库领域上的EX性能。图 5 (b) 显示了整体性能。

如图 5 (a) 所示，我们发现不同的nl2sql方法对不同领域表现出不同的偏好，LLM和PLM方法之间没有明确的胜者。

然而，在图 5 (b) 中，我们观察到在具有更多训练数据库的领域（如学院、竞赛、交通）中，微调后的基于LLM的方法表现更好。相反，在具有较少训练数据库的领域中，基于提示的方法表现更好。这表明在微调过程中使用领域内训练数据对于提高特定领域的模型性能至关重要。

发现7. 不同的方法对不同领域表现出不同的偏好，LLM和PLM方法之间没有明确的胜者。然而，在微调过程中使用领域内训练数据对于特定领域的模型性能至关重要。

SQL风格提示示例。

EX / HumanEval vs. 基础模型。

我们研究了开源LLM的监督微调（SFT）对nl2sql任务的影响。DAILSQL (Gao et al. 2024) 考察了SFT期间不同shot和提示表示形式的影响，但并未解决 哪种开源LLM最适合nl2sql任务的SFT 。DAILSQL发现SQL风格的提示是有益的，因此我们在零样本设置中采用了类似的提示方法，如图 6 所示。鉴于nl2sql是一个与代码相关的任务，我们选择了五个具有不同代码能力的开源LLM，使用HumanEval（Pass@1）指标 (M. Chen et al. 2021) 进行评估。为了确保公平比较并考虑硬件限制，所有选定的LLM具有相似的参数量。模型名称中的后缀，如 7B ，表示模型有70亿参数。

我们比较了第 4.1 节介绍的5种基于微调的LLM。我们使用指令微调方法，即Alpaca (Taori et al. 2023) 。 我们使用Adam优化器，学习率为1e-5，无权重衰减。学习率按余弦衰减至零。我们使用全局批量大小为16进行单次迭代以减轻过拟合风险。 微调后，LLM在Spider开发集上使用EX指标进行评估。

如图 7 所示，微调后LLM的性能（EX）有所提高，但在不同基础模型上的增益差异显著。重要的是，我们观察到这些性能差异与这些模型在微调前的固有编码能力（HumanEval）之间存在正相关。这表明 选择具有先进编码能力的基础LLM对适应nl2sql任务是有利的 。

发现8. 在开源LLM的nl2sql任务监督微调（SFT）后，我们发现微调后的性能与SFT前模型的固有编码能力之间存在正相关。这表明，具有先进编码能力的基础LLM对适应nl2sql任务很重要。

4.3 效率评估实验

基于提示的LLM方法 利用商业GPT API接口完成nl2sql任务。截至2024年6月，与GPT-3.5-turbo相比，GPT-4的API接口在输入标记上的成本高60倍，在输出标记上的成本高40倍。在实际应用中，除了nl2sql方法的性能外，成本也是一个重要的考虑因素。 在本实验中，我们基于Spider和BIRD开发集计算了几种指标。 这些包括标记数量和每次nl2sql任务的成本（美元）。如表 [tab:llm-economy] 所示，我们还计算了EX与平均成本的比率，这在某种程度上反映了nl2sql方法的成本效益。

尽管C3SQL在两个数据集上的EX最低，但其EX与平均成本比率最高，主要是因为使用GPT-3.5-turbo接口的成本较低。在使用GPT-4的方法中，DINSQL的成本效益最低，而DAILSQL则是最具成本效益的。虽然DAILSQL(SC)在Spider和BIRD数据集上超过了DAILSQL，但它引入了更高的成本，降低了其成本效益。

发现9. 基于EX与平均成本比率，我们发现基于提示的LLM方法在使用GPT-3.5-turbo时具有更高的成本效益。 虽然DAILSQL(SC)在Spider和BIRD数据集上的EX有所提高，但它引入了更高的成本，降低了其成本效益。

在实际应用中，同时考虑nl2sql方法的性能和效率至关重要，尤其是每个样本的延迟。不同方法有不同的GPU内存需求，随着模型规模的增加而增加。根据可用硬件和延迟要求选择适当的方法是一个常见挑战。我们在六个模型上评估了三个指标：RESDSQL-Base/Large/3B和RESDSQL-Base/Large/3B + NatSQL，重点关注执行准确性（EX）、每个样本的延迟和GPU内存使用情况，使用Spider开发集。模型效率与数据集无关，因此我们省略了BIRD数据集以节省空间。

表 [tab:plm_efficiency] 显示，随着模型参数的增加，GPU内存和延迟也随之增加。然而，RESDSQL-Base+NatSQL（2.2亿参数）和RESDSQL-Large（7.7亿参数）在EX上表现相似（分别为80.2%和80.1%），但前者延迟更低，内存使用更少。同样，RESDSQL-Large+NatSQL和RESDSQL-3B在EX上表现相似，但在延迟和硬件需求上有差异。因此，选择模型时应考虑延迟和硬件资源。

发现10. 对于相同的方法，随着模型参数的增加，延迟和硬件资源需求也会相应增加。 此外，性能相似的模型在延迟和硬件资源需求上可能存在差异。

在实际场景中，不仅要关注模型生成的sql查询的正确性，还要关注其执行效率。BIRD (J. Li, Hui, Qu, et al. 2023) 引入了有效率评分（VES）来评估正确生成的sql查询的执行效率。VES得分是通过将真实sql查询的执行时间除以预测sql查询的执行时间得出的。 我们在Spider和BIRD开发集上评估不同方法的VES指标，以比较由不同方法生成的sql查询的执行效率。

表 [tab:sql-ves] 报告了实验结果。最高的VES得分在表中用 橙色 突出显示。在不同难度子集上的方法中获得最高VES的方法不一致，LLM基础方法和PLM基础方法之间没有明显优势。一般来说，对于同一方法，在更难的子集上其VES得分较低，这可能是由于复杂性增加导致执行时间变长。

发现11. 基于VES指标，LLM基础方法和PLM基础方法之间没有明确的胜者。对于同一方法，在更难的子集上其VES得分往往较低。

EX vs. 训练样本数量在Spider上的表现。

在实际场景中，有限的领域内数据常常阻碍性能。我们在Spider训练集上进行实验，以1000个样本为增量进行采样，并包括一个较小的500个样本的子集。我们在这些子集上训练各种方法，并评估它们在Spider开发集上的EX性能。RESDSQL-3B和RESDSQL-3B+NatSQL的训练超参数与 (H. Li et al. 2023) 中的设置相同，而其他方法遵循 Exp-5.

图 8 的结果显示，无论是基于PLM还是微调后的LLM方法，随着nl2sql训练数据的增加，性能都有所提升，并且在4000个训练样本时达到了可接受的性能水平。然而，随着数据集规模的增加，EX性能增益逐渐减少。

发现12. 无论是基于PLM还是LLM的方法，随着nl2sql训练数据的增加，性能都会有所提升。然而，随着数据集规模的增加，EX性能增益逐渐减少。如果数据隐私是一个问题或有足够的标记数据，微调LLM/PLM是有前途的。

5 结合两者之长

5.1 设计空间探索

NL2SQL解决方案的设计空间。

我们探索了由语言模型支持的nl2sql解决方案的设计空间，如图 9 所示。

(1) 预处理 ：预处理模块包括模式链接和数据库内容。模式链接将nl查询引用映射到数据库模式元素（表、列），增强了跨域泛化能力和复杂查询生成 (Lei et al. 2020) 。这种方法被领先的LLM基础 (Dong et al. 2023; Pourreza and Rafiei 2023) 和 PLM基础方法 (H. Li et al. 2023; J. Li, Hui, Cheng, et al. 2023) 采用。此外，数据库内容模块通过字符串匹配对齐查询条件与数据库内容，通常用于丰富列细节 (Lin, Socher, and Xiong 2020) 。如表 [tab:taxonomy] 所示，虽然这种模块在PLM基础方法中很常见，但在LLM基础方法中很少使用。

(2) 提示策略 ：提示策略分为零样本，即模型输入中不包含任何nl2sql示例，以及少样本，即包含少量示例，记为“3-shot”，“5-shot”等，具体取决于使用的示例数量。表 [tab:taxonomy] 显示，PLM基础方法通常使用零样本，而LLM基础方法则有所不同：C3SQL (Dong et al. 2023) 使用零样本，而DAILSQL (Gao et al. 2024) 和 DINSQL (Pourreza and Rafiei 2023) 使用少样本。

DINSQL的少样本是手动设计并固定的，而DAILSQL的少样本则是根据目标问题与训练集示例之间的相似性动态选择的。

(3) SQL生成策略 ：语言模型采用多种策略生成sql，主要分为三个方面：多步骤、解码策略和中间表示。

(a) 多步骤 类似于链式思考（COT）过程，涉及分阶段生成sql查询，特别适用于复杂查询 (Wei et al. 2022) 。 我们包括两种多步策略：“sql骨架 - sql”来自PLM基础的RESDSQL (H. Li et al. 2023) 和 “子查询 - sql” 来自DINSQL (Pourreza and Rafiei 2023) 。

(b) 解码策略 涉及模型的解码过程，以确保输出的有效性。PLM基础的PICARD (Scholak, Schucher, and Bahdanau 2021) 在其输出中强制遵守sql语法，而LLM基础方法利用OpenAI的API，缺乏解码级别的限制。

(c) 中间表示 策略探讨了模型是否采用中间查询形式来解决nl到sql翻译中的 不匹配问题 ，即sql设计用于关系数据库，与自然语言语义不完全对齐。已经提出了多种解决方案，如 (J. Guo et al. 2019) 和 NatSQL (Gan et al. 2021) 。LLM基础的DINSQL (Pourreza and Rafiei 2023) 和几种PLM基础方法 (H. Li et al. 2023; Rai et al. 2023; Gan et al. 2021) 采用了NatSQL。 在我们的设置中，为了简化，我们只包括NatSQL。

(4) 后处理 ：我们考虑以下策略。

(a) 自我纠正 是由DINSQL (Pourreza and Rafiei 2023) 提出的。它将生成的sql提供给模型以修正潜在的问题。

(b) 一致性验证 包括为单个nl查询执行多个有效的sql查询，并使用投票机制确定最一致的sql作为最终选择。该方法被C3SQL (Dong et al. 2023) 和 DAILSQL (Gao et al. 2024) 所采用。

(c) 执行引导的SQL选择器 是一个模块 (H. Li et al. 2023) ，它依次执行模型生成的SQL查询，识别第一个无错误执行的SQL作为有效SQL。

(d) N最佳重排序器 对多个候选sql查询进行排名，选择最有可能的一个作为最终查询 (Zeng, Parthasarathi, and Hakkani-Tur 2022) 。

5.2 NL2SQL360促进更好的NL2SQL

在将不同的LLM和PLM方法分类为统一的模块框架后，出现了一个问题： 自动探索和组合不同nl2sql解决方案中的不同模块是否可以实现更强的性能？

为了解决这个问题，受神经架构搜索（NAS）算法 (L. Xie and Yuille 2017) 的启发，我们在NL2SQL360框架内设计了一种nl2sql自动化架构搜索算法（ NL2SQL360-AAS )。其关键直觉是在nl2sql解决方案中自动探索预定义的设计空间（即预定义的搜索空间）。因此，我们采用标准遗传算法（GA） (Alam et al. 2020) 来实现这一目标。

有一些与我们的 NL2SQL360 -AAS 相关的关键概念。

(1) 搜索空间。 这包括nl2sql中使用的各种模块，如sql生成策略、后处理模块和提示技术，如图 9 所示。

(2) 个体 . 搜索空间中不同模块的有效组合，即一个有效的nl2sql解决方案，称为 个体 。

(3) 目标指标。 我们旨在根据指定数据集（例如Spider）上的目标指标（例如EX）选择更好的个体。

NL2SQL360-AAS算法概述。

如图 10 所示，我们的算法包括四个主要步骤，即初始化、个体选择、nl2sql模块交换和nl2sql模块变异。注意， \(M_{t,i}\) 是第 \(t\) 代群体中的第 \(i\) 个个体。

我们初始化 \(N\) 个随机化的nl2sql系统个体 \(\{M_{0, n}\}^N_{n=1}\) , 它们由图 9 中所示的随机模块组成，形成第 \(0\) 代群体。

我们在指定的数据集（例如Spider）上评估 \(N\) 个个体的群体，使用目标指标（例如EX）。我们实现了 轮盘赌选择过程 (L. Xie and Yuille 2017) , 根据目标指标分布概率选择个体，确保高目标指标的个体有更大的被选中几率，同时持续淘汰表现最差的个体。

从上一步中选择的两个个体将根据模块交换概率 \(p_s\) 交换其nl2sql模块。例如，如果个体 \(M_{t,i}\) 在后处理层中有自我纠正模块，而个体 \(M_{t,j}\) 有自我一致性模块，则这些模块可能会被交换。在图 10 中，交换模块后的个体分别标记为 \(M^{s}_{t,i}\) 和 \(M^{s}_{t,j}\) 。

5.3 SuperSQL：由NL2SQL360-AAS建议的卓越NL2SQL解决方案

清晰模式与数据库内容提示。

我们从NL2SQL360-AAS生成的最终一代中选择执行准确性最高的个体作为最终的nl2sql解决方案，即 SuperSQL 。

SuperSQL的组成如下：(1) 预处理：来自RESDSQL的模式链接和来自BRIDGE v2的数据库内容；(2) 提示：DAILSQL的少样本模块通过相似性选择上下文示例；(3) SQL生成：使用OpenAI的贪婪解码策略，不包括多步骤或NatSQL；(4) 后处理：来自DAILSQL的自我一致性。我们探索了此组合的提示组织方式，如图 11 所示。在此组合下，RESDSQL模式链接模块用于过滤无关的模式项。此外，它结合了来自BRIDGE v2方法的相关内容，作为提示中的列注释，增强了列信息。然后我们将骨干模型替换为GPT-4以提高性能。

我们在Spider开发集上评估了 SuperSQL , 达到了87.0%的EX，优于其他方法（表 [tab:overall_spider] )。 SuperSQL 在中等、困难和额外子集上表现出色，证明了其有效性。在BIRD开发集上， SuperSQL 也展示了竞争力（表 [tab:overall_bird] )。

我们还在Spider和BIRD测试集上评估了 SuperSQL , 达到了Spider上87.0% EX（第二名）和BIRD上62.66% EX（第九名）。请注意， SuperSQL 超越了其设计空间内的所有基线。特别是， SuperSQL 在BIRD测试集上超越了最强的基线——DAILSQL(SC）——提高了5.25%。这一改进主要归功于我们的 NL2SQL360-AAS , 它能够有效地在设计空间中搜索出优越的模块组合。加入更多强大的基线有望进一步通过 NL2SQL360-AAS 提高 SuperSQL 的性能。

我们计算VES指标以评估sql效率，在Spider和BIRD开发集上。根据表 [tab:sql-ves] , SuperSQL 在整体VES得分分别为99.18和61.99，优于其他方法。

此外，我们还考虑了我们的方法的经济性，结果如表 [tab:llm-economy] 所示。与其他基于GPT-4的方法相比，我们的方法使用的标记较少，成本更低，同时在EX指标上表现更好。

6 研究机会

我们根据实验结果讨论研究机会。

当前方法可能会生成不正确的sql结果，这可以归因于：1) 模糊和未充分指定的nl查询，2) 模糊的数据库模式和脏数据，3) 模式链接能力不足。

我们可以探索以下策略来缓解这些问题。 (i) 查询改写器 旨在自动优化给定的nl查询并确保其清晰度。 (ii) 查询自动补全 通过建议与数据库高度匹配的候选标记来帮助用户构建查询。

(i) NL2SQL调试器 检测不正确的sql查询，使用户能够逐步跟踪sql生成过程，并帮助识别错误或不匹配。 (ii) SQL和查询结果解释方法 帮助用户评估生成的sql和查询结果是否符合其需求。

基于LLM的nl2sql方法具有前景但消耗大量标记，影响成本和推理时间。探索在提高准确性的同时最小化标记使用量的方法至关重要。特别是模块化nl2sql解决方案和多代理框架的潜在优势越来越明显。将LLM与这些方法结合，可以在保持标记节约的同时优化准确性和效率，特别是在处理复杂查询时。

nl2sql方法的效果很大程度上依赖于训练数据的质量和覆盖范围。这些方法在适应未见过的数据库方面往往存在困难。一个有前途的研究方向是利用模型评估反馈动态生成（nl，sql）对。这种方法通过利用nl2sql性能的见解来确保多样化和高质量的训练数据，从而解决领域适应问题。

7 结论

我们提出了一个多角度测试平台，名为 NL2SQL360 , 用于从不同角度评估nl2sql方法，如处理sql和数据库域的各种特征的能力，进行细粒度评估。 我们使用 NL2SQL360 评估了13种基于LLM和7种基于PLM的nl2sql方法在两个广泛使用的基准数据集上，变化了15种设置，得出了新的发现。 此外，我们使用 NL2SQL360 分析nl2sql解决方案的设计空间，并自动搜索一种最适合特定用户需求的最佳解决方案，命名为 SuperSQL 。我们的新 SuperSQL , 交错使用LLM和PLM模块，在Spider和BIRD测试集上分别实现了 87% 和 62.66% 的执行准确性。

这项工作得到了广东省基础与应用基础研究基金（2023A1515110545）、国家重点研发计划（2023YFB4503600）、国家自然科学基金（61925205, 62232009, 62102215）、中关村实验室、华为、好未来教育、北京信息科学与技术国家研究中心（BNRist）、CCF-华为普罗米修斯基金（CCF-HuaweiDB202306）和中央高校基本科研业务费的支持。

1. *Yuyu Luo是通讯作者。
   本作品采用Creative Commons BY-NC-ND 4.0国际许可证授权。访问 https://creativecommons.org/licenses/by-nc-nd/4.0/ 查看许可证副本。对于超出此许可证涵盖范围的任何用途，请发送邮件至 info@vldb.org 获取许可。版权由所有者/作者持有。出版权授予VLDB基金会。

• 《VLDB会刊》，Vol. 17, No. 11 ISSN 2150-8097。
  doi:10.14778/3681954.3682003
  ↩︎