将用户的自然语言问题转换为SQL查询（即NL2SQL）显著降低了访问关系型数据库的门槛。大型语言模型的出现为NL2SQL任务引入了新范式，大幅提升了相关能力。然而，这引发了一个关键问题：我们是否已完全准备好将NL2SQL模型部署到生产环境中？为解决上述问题，本文提出了一个多角度的NL2SQL评估框架NL2SQL360，以帮助设计和测试新的NL2SQL方法。本文通过NL2SQL360对主流NL2SQL方法在多种应用场景下进行了详细比较，为针对特定需求选择最合适的NL2SQL方法提供了有价值的见解。此外，本文还探索了NL2SQL的设计空间，利用NL2SQL360自动识别了一种有效的NL2SQL方法SuperSQL，该方法在Spider数据集上使用执行准确率指标表现突出，性能颇具竞争力。

1. 研究背景与动机

1.1 NL2SQL的兴起和局限性

一种自然语言到SQL（NL2SQL）的能力，即将自然语言查询转换为SQL查询，能显著降低普通用户和专业用户访问海量数据集并获取洞察的门槛。特别是在最近大型语言模型取得进展的推动下，NL2SQL解决方案的性能得到了显著提升。尽管数据库厂商在解决NL2SQL问题上付出了诸多努力，但仍存在许多重要问题，本文将系统地审视并回答了这些问题：

● 问题1：NL2SQL现在处于什么阶段？

NL2SQL方法概览

过去二十年NL2SQL方法的演进如上图所示，从基于规则的方法、基于深度神经网络的方法、可微调的预训练语言模型（PLM），到大型语言模型（LLM），同时还有Spider、BIRD等基准的发展。与PLM（如GPT-2、BART）相比，LLM（如GPT-4、Llama2）具有先进的语言理解能力和涌现能力。将PLM用于NL2SQL任务需要在特定任务数据集上进行微调，而利用LLM完成该任务可以通过提示（上下文学习）对LLM进行微调（即指令跟随）。两种方法均取得了最先进的（SOTA）结果。

基于PLM和LLM的NL2SQL方法的演变

上图比较了基于PLM基于LLM的NL2SQL模型在Spider上的准确率。2023年2月起，基于LLM的NL2SQL模型的准确率与基于PLM的模型相当。随着LLM的快速发展，基于LLM和基于PLM的模型之间的性能差距不断扩大，突显了基于LLM方法的优势。

● 问题2：基于LLM的模型是最好的方法吗？

选择排行榜上排名靠前的模型是否总是最佳策略？正确回答这个问题对于帮助研究人员和从业者为不同需求设计和选择合适的模型至关重要。本文将考虑以下经典的商业智能（BI）的应用案例：

1. 各种数据领域：像Tableau这样的平台通常有不同的数据库领域（如电影和体育），具有独特的模式和术语。NL2SQL模型必须在这些不同领域中具有泛化能力，适应每个特定领域以有效满足需求。

2. 复杂SQL操作：现实应用通常需要执行复杂的SQL查询，涉及高级操作，如多表JOIN、嵌套查询和聚合函数。准确生成复杂查询的能力是评估NL2SQL模型的重要标准。

3. 新的语言现象：对于相同的查询意图，不同的用户可能会用不同的缩写、同义词和提问风格来提出NL问题。因此，NL2SQL模型理解和准确解释各种NL查询变体的能力变得重要。

不同NL2SQL模型之间的比较

4. 各种数据领域：通过上述(a)图比较模型显示，基于微调的LLM/PLM方法优于所有基于提示的LLM方法,表明微调是增强NL2SQL模型领域适应能力的关键策略。

5. 复杂SQL操作：通过比较了仅包含带JOIN操作符的SQL查询用例的不同模型（图(b)）显示，基于PLM的方法RESDSQL-3B+NatSQL排名第一，优于所有基于LLM的方法。但是，当在仅包含嵌套SQL查询的用例上比较不同方法时，图(c)所示，基于LLM的方法通常优于基于PLM的方法。

6. 新的语言现象：通过比较这些方法在不同语言现象上的平均准确率，图(d)显示，尽管这两种类型的方法表现都很好，但针对NL2SQL微调的LLM和PLM优于针对NL2SQL的提示LLM。这主要是因为微调后的模型能更好地将不同的查询变体与数据库模式对齐。

● 问题3：能否结合两者的优势，设计一个超级NL2SQL模型？

如果在不同场景中没有单一的胜者，能否设计一个超级NL2SQL模型，能够结合PLM和LLM的优点，并在不同场景中都具有鲁棒性？

1.2 提出NL2SQL360的动机

本文从不同角度在不同基准上系统评估了不同的基于PLM和基于LLM的NL2SQL模型。在这些广泛的实验中，作者构建了一个测试平台，可以帮助研究人员和从业者在特定场景下更好地评估NL2SQL模型，观察到有用的实验发现，并设计了一个比SOTA解决方案更鲁棒的超级NL2SQL模型：

1. NL2SQL360：多角度NL2SQL评估：本文设计了一个测试平台NL2SQL360，用于对NL2SQL解决方案进行细粒度评估。用户可以利用NL2SQL360根据既定基准评估不同的NL2SQL方法。这种灵活性允许在特定数据领域测试解决方案或分析不同SQL查询特征的性能。

2 新的实验发现：实验在Spider和BIRD数据集上测试了13种基于LLM和7种基于PLM的NL2SQL解决方案，改变不同的设置，以分析它们在各种使用场景中的性能。实验发现发现：

● 准确性：微调对于提高性能至关重要。经过微调的基于LLM的方法在EX指标上表现出色，基于PLM的方法在EM指标上领先。

● NL查询变体：为了从不同的NL查询生成相同的目标SQL，在特定场景数据上微调的LLM和PLM表现出更强的稳定性。

● 领域适应：对于跨不同领域的NL2SQL任务，基于LLM/PLM的方法之间没有明确的胜者。微调过程中的领域内数据对模型在特定领域的性能至关重要。

● 预训练中语料库的影响：实验表明，经过微调后，在特定代码数据集上预训练的LLM在NL2SQL任务中优于在通用文本上训练的Llama2-7B。这凸显了LLM的预训练数据领域或其内在的代码能力对其在NL2SQL等专业任务中的性能的重大影响。

3. SuperSQL：一种鲁棒的NL2SQL模型：实验系统地对基于LLM和PLM的最具代表性的NL2SQL模块进行了分类和分析，突出了它们的共性和独特特征。在此探索的基础上，本文提出了SuperSQL，它在Spider测试集上实现了87%的具有竞争力的执行准确率，在BIRD测试集上实现了62.66%的执行准确率。

(4) 确定研究机会：首先，增强NL2SQL方法的可信度，包括处理模糊的NL查询、诊断NL查询与预测SQL之间的匹配以及将查询结果解释回NL查询。其次，开发具有成本效益的NL2SQL解决方案；最后，基于评估结果自动自适应地生成训练数据。

2. 自然语言到SQL

2.1 相关工作：概览

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

NL2SQL方法概览

1. 基于规则的方法：早期工作主要基于预定义规则或语义解析器。例如NaLIR使用句法解析器理解NL查询并链接到数据库元素，然后依靠手工规则生成SQL查询。然而，这些方法在适应性、可扩展性和泛化能力方面表现出显著局限性。

2. 基于神经网络的方法：为了克服这些限制，研究者使用神经网络来学习从NL查询到SQL查询的转换，并发布了许多大规模基准数据集，包括WikiSQL、Spider等。在这一研究方向中，开发了基于序列到序列的NL2SQL方法，并在当时达到了新的水平：IRNet使用编码器对NL查询和数据库模式进行编码，然后使用解码器网络生成SQL查询。

3. 基于PLM的方法：随着Transformer和Spider数据集的引入，基于神经网络的方法开始出现，迅速成为主流方法。BERT和T5等模型的出现标志着基于预训练语言模型的方法的兴起，这些方法在基准数据集上取得了有竞争力的结果，比如RESDSQL使用两阶段框架进行NL2SQL。首先，它直接从自然语言查询中识别相关的模式元素，如表名和列名。然后，它使用这些元素构建SQL查询。

4. 基于LLM的方法：ChatGPT和GPT-4等巨型大型语言模型的出现引发了新的解决方案浪潮。这些基于LLM的NL2SQL方法已成为当前最突出和最具代表性的解决方案：DAIL-SQL通过有效的提示工程方法利用GPT-4，在Spider数据集上取得了有竞争力的结果。

未来，基于LLM/PLM的NL2SQL方法在未来几年将继续主导该领域。本文充分分析了这些NL2SQL方法的能力、局限性和潜在改进：

基于LLM/PLM的NL2SQL方法比较

NL2SQL系统中的关键模块。最近的方法采用语言模型作为NL2SQL翻译的主干，使用像GPT-4这样的巨型和基于API的大型语言模型，或者像T5和LLaMA这样的可微调语言模型。同时，模式链接模块是大多数方法的组成部分，突显了其在NL2SQL过程中的关键作用。此外，所有基于PLM的方法都将数据库内容纳入其中，这表明其对提高生成的SQL查询的准确性和相关性的重要贡献。在SQL生成步骤中，所有基于PLM的方法都采用类似波束搜索的策略，以在SQL语法规则的约束下识别最佳输出标记。相反，基于LLM的方法依赖于基于贪心的策略来生成SQL。在后处理步骤中，大多数基于LLM的方法结合了启发式提示策略，以优化初始输出，确保它们更符合预期的SQL查询。

2.2 现有实验及其局限性

有一些与我们的研究相关的实验研究：

● Gao等人通过提示工程评估了开源LLM在NL2SQL任务中的潜力。

● Rajkumar等人探索了Codex语言模型在零样本和少样本设置下处理NL2SQL任务的能力。

● Gkini等人对基于解析和基于关键字的NL2SQL进行了深入评估。

前两项研究主要关注评估基于LLM的NL2SQL解决方案，但第三项研究调查了基于解析的NL2SQL方法。现有实验有几个局限性：

1. 忽视使用场景：现有评估通常报告整个基准数据集的总体结果。虽然这提供了广泛的概述，但未能提供跨数据特定子集的详细比较。若根据不同的SQL特征或数据库领域过滤评估的数据集，这可以为不同NL2SQL模型对特定SQL查询类型或特定领域场景的相对有效性提供有价值的见解。

2. 缺乏直接和全面的比较：许多最近的NL2SQL解决方案，特别是那些基于LLM和PLM的解决方案，尚未在完善的基准和定制数据集上进行系统比较。

3. NL2SQL设计空间的探索有限：当前在NL2SQL研究和实践中，对基于LLM和PLM方法的NL2SQL框架的设计空间探索仍然有限。这限制了研究者们对如何协同整合来自LLM和PLM的不同架构和功能模块以增强NL2SQL系统的理解。

3.NL2SQL360：NL2SQL的测试平台

NL2SQL360框架概览

本文设计了一个测试平台NL2SQL360，用于评估和分析NL2SQL解决方案。NL2SQL360可以帮助研究人员了解NL2SQL系统中的设计选择，并以较少的开发工作比较SOTA模型，并为从业者提供不同类型模型在特定场景中的实验发现，以促进实际应用。NL2SQL360测试平台框架包括六个核心组件：数据集存储库、模型库、数据集过滤器、评估指标、NL2SQL评估器和分析模块。

1. 基准数据集：该模块维护广泛使用的基准，如Spider、BIR、Spider-Realistic、Dr.Spider、KaggleDBQA、WikiSQL等。

2. 模型库：该模块托管了在Spider和BIRD上的具有竞争力的开源NL2SQL模型的集合。它主要包括基于LLM和基于PLM的方法。

3. 数据集过滤器：为了针对不同场景定制评估，本文选择基准的特定子集，包括特定的数据库、NL和SQL查询。这些子集突出了独特的特征，如查询复杂性、数据库模式多样性和独特的SQL特征，在NL2SQL360中引入了数据集过滤机制。这允许根据各种标准将测试数据集分解为更集中的子集：

● 场景1：SQL复杂性。此场景按复杂性区分SQL查询，从简单到具有多个子句和条件的复杂查询。分类遵循Spider建立的标准，旨在评估NL2SQL方法处理不同级别SQL难度的程度。

● 场景2：SQL特性。它检查主要利用特定功能的SQL查询，如JOIN操作、子查询或聚合函数。通过根据这些特性对查询进行分类，来评估NL2SQL系统管理不同SQL功能的能力。

● 场景3：数据领域。此场景探索系统在各种数据领域（如金融、医疗和零售）的性能。通过根据数据领域对NL2SQL数据库进行分类，提供了一个结构化框架来评估特定领域的能力和潜在限制。

● 场景4：查询变体测试。它评估NL2SQL系统在处理自然语言查询变体时的鲁棒性和灵活性，以及系统对不同措辞和结构的响应，来衡量用户友好性和对不同语言风格的适应性。实验使用来自NL2SQL数据集的各种自然语言查询作为测试样本。

4. 评估指标：实验采用执行准确率（EX）和精确匹配准确率（EM）来评估生成的SQL查询的有效性，使用有效效率得分（VES）来衡量生成有效SQL查询的效率。为了进一步评估NL2SQL解决方案在处理自然语言查询变体时的鲁棒性和灵活性，本文提出了一个新的指标，称为查询变体测试（QVT），以评估模型适应不同形式的NL查询的程度。给定一个SQL查询，通常存在多个对应的NL查询，表示为对。在评估NL2SQL模型时，只有当模型准确处理其中至少一对时，这些NL和SQL查询对才会被纳入测试集。计算QVT准确率的公式定义为：

其中：

● M是测试集中SQL查询的总数。

●  是对应于SQL查询的自然语言查询变体的数量。

● 表示NL2SQL模型为的第个自然语言查询变体生成的SQL查询。

● 是指示函数，如果内部查询结果相等则返回1，否则返回0。

5. 执行器和日志：用户可以定制NL2SQL模型的评估工作流程，设置超参数和指标等参数。然后测试平台会自动在基准和自定义子集上运行这些模型，并记录每个结果。日志提供了每个模型性能的详细见解，作为模型分析的资源。

6. 评估器：评估器利用日志中的数据，自动生成以表格或排行榜等易于解释的格式呈现的定量评估。测试平台提供可视化工具和仪表板用于交互式分析，允许用户跨数据库领域和SQL特性等维度比较NL2SQL解决方案。

4. 实验

4.1 实验设置

1. 数据集：本文使用Spider和BIRD的开发集作为实验数据集，分别包含1034和1534个（NL,SQL）样本。BIRD数据集的SQL结构更复杂，包含一些Spider未涵盖的关键字,对模型的NL2SQL能力提出了挑战。此外，BIRD中的数据库比Spider中的更复杂，如表 2 所示。

Spider和BIRD数据集对比

2. 方法：基于提示的LLM，比较了4种基于提示的方法：

● DINSQL：将SQL查询的生成分解为不同的子问题，并为每个子问题设计不同的提示，以指示GPT-4生成最终的SQL查询。

● DAILSQL：以SQL代码风格对问题和数据库模式进行编码。它根据结构相似性和查询相似性选择少样本示例。这些元素被组合成一个有效的提示来引导GPT-4。

● DAILSQL(SC)：是DAILSQL的版本，带有用于后处理的自我一致性（SC）策略。

● C3SQL：使用模式链接过滤和为GPT-3.5定制的校准偏差提示来生成SQL查询，并结合自我一致性策略进行后处理。

基于微调的LLM，评估了9种基于微调的方法：

● SFT CodeS(1B/3B/7B/15B)：CodeS基于StarCoder使用大型SQL相关语料库进行增量预训练，实验中使用在Spider或BIRD数据集上微调的SFT CodeS，有4个版本。

● Llama2-7B：使用优化的Transformer作为自回归语言模型，由Meta在庞大的语料库上预训练。

● Llama3-8B：在超过15T词元的数据上训练。

● StarCoder-7B：是一个Code LLM，已在来自GitHub的许可数据上训练。

● CodeLlama-7B：是Llama2的增强变体，通过在代码存储库数据集上的额外训练进行了改进。

● Deepseek-Coder-7B：在项目级代码语料库和填空任务上训练，以提高代码完成能力。

基于PLM的NL2SQL，评估了7种最先进的方法：

● Graphix-3B+PICARD：将预训练的T5-3B转换器与图感知增强功能集成用于NL2SQL任务，利用PICARD来提高性能。

● RESDSQL(Base/Large/3B)：引入了排名增强编码和骨架感知解码，以将模式链接与骨架解析分离。

● RESDSQL(Base/Large/3B)+NatSQL：结合了NatSQL以获得更好性能的版本。

3. 指标：实验在精确匹配准确率（EM）、执行准确率（EX）、查询变体测试（QVT）、有效效率得分（VES）、词元效率和延迟指标上评估不同的方法。

4. 硬件和平台：所有实验都在配备512GB RAM和两个40核Intel (R) Xeon (R) Platinum 8383C CPU@2.70GHz的Ubuntu22.04.3 LTS服务器上进行。对于LLM实验的监督微调使用8个NVIDIA A800（80GB）GPU来微调模型。

4.2 评估准确性的实验

4.2.1 实验1：基准上的总体准确性

实验评估了基于LLM和基于PLM的方法在不同复杂性的SQL查询上的性能，在Spider和BIRD开发集上运行所有方法，并计算它们的执行准确率（EX）和精确匹配准确率（EM）指标。

在Spider上的总体准确性

在BIRD上的总体准确性

● 基于EX指标：实验发现在不同难度的子集中，基于LLM的方法的EX超过了基于PLM的方法。特别是DAILSQL(SC)在子集上优于基于LLM的SOTA方法（SFT CodeS-15B），这可能受益于GPT-4更强的推理能力。

● 基于EM指标：实验发现经过监督微调的基于LLM的方法通常比基于提示的LLM方法具有更高的EM性能。微调后，基于LLM和基于PLM的模型的输出更接近特定数据集的数据分布，导致其预测与该数据集中的SQL结构相似。

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

4.2.2 实验2：准确性与SQL特性的关系

实验评估了NL2SQL模型准确生成具有不同特性的SQL查询的能力。为此，本文根据四个标准对SQL查询进行分类：是否存在子查询；逻辑连接器的数量；是否使用ORDER BY，以及JOIN的数量。实验进一步将基于LLM的方法分为基于提示和基于微调的LLM。

模型在Spider和BIRD数据集不同子集上的EX性能分布

模型在Spider数据集不同子集上的性能详细结果

模型在BIRD数据集不同子集上的性能详细结果

1. 实验2.1：子查询数量：实验表明，所有方法在有子查询的情况下表现最差，表明通过子查询进行推理是一项具有挑战性的任务。在没有子查询的场景中，基于LLM的方法在Spider上略优于基于PLM的方法，而在BIRD上平均显著优于基于PLM的方法。总体而言，在有子查询的场景中，基于LLM的方法在两个数据集上都表现出色。对于生成带有子查询的SQL需要模型首先考虑子查询，然后生成整个SQL，这需要很强的推理能力。实验发现所有基于LLM的方法，尤其是那些由GPT-4提示的方法，在子查询方面表现更好，超过了经过微调的基于LLM的方法和基于PLM的方法。这表明模型的固有推理能力对于处理带有子查询的SQL至关重要。

● 发现2：在涉及子查询的场景中，基于LLM的方法总体上优于基于PLM的方法，使用基于提示的LLM的方法表现尤其更好。这些模型的固有推理能力可能是成功预测子查询的关键。

2. 实验2.2：逻辑连接器数量：逻辑连接器用于链接条件、过滤查询结果和执行其他操作。在没有逻辑连接器的场景中，基于LLM的方法在Spider数据集上与基于PLM的方法相比没有显著优势。然而，在BIRD数据集上，基于LLM的方法优于基于PLM的方法，这可能是由于BIRD数据集的更高复杂性。在需要逻辑连接器的场景中，基于LLM的方法在两个数据集上始终优于基于PLM的方法。

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

3. 实验2.3：JOIN数量：在许多使用场景中需要生成跨多个表的带有JOIN的SQL查询。

● 在没有JOIN操作的场景中，基于LLM和基于PLM的方法在Spider和BIRD上表现没有明显的胜者。

● 然而，在需要JOIN操作的场景中，基于LLM的方法在两个数据集上都优于基于PLM的方法。这可能是由于JOIN操作需要理解复杂的数据库模式，而LLM其卓越的上下文理解能力通常在这方面表现出色。

● 对于有JOIN的SQL查询，DINSQL在基于提示的方法中表现最好，而RESDSQL-3B+NatSQL是基于PLM的方法中最好的。两者都利用NatSQL作为中间表示，在JOIN场景中简化了SQL预测。

● 发现4：在涉及JOIN操作的场景中，基于LLM的方法优于基于PLM的方法。将 NatSQL作为中间表示可降低预测JOIN操作的复杂性，并有可能提高模型性能。

4. 实验2.4：ORDER BY数量：实验观察到在没有ORDER BY子句的情况下，基于LLM的方法在Spider和BIRD数据集上都优于基于PLM的方法。然而，在有ORDER BY子句的情况下，基于LLM的方法在Spider数据集上的表现不如基于PLM的方法，而在BIRD数据集上则优于基于PLM的方法。这可能是因为BIRD数据集比Spider数据集更复杂。

● 发现5：在包含ORDER BY子句的场景中，基于LLM和基于PLM的方法的性能因数据集而异。一般来说，基于LLM的方法表现出更强的泛化能力。

4.2.3 实验3：查询变体测试

实验评估了NL2SQL系统对各种自然语言措辞和结构的适应性，反映实际应用中预期的多样性。

QVT vs EX结果

实验表明，在QVT方面，基于LLM的方法和基于PLM的方法之间没有明显的胜者。然而，经过微调的LLMs通常比提示LLMs表现出更高的QVT。这可能是由于微调后模型输入与特定数据分布的对齐，减少了NL变化对性能的影响。尽管Graphix+PICARD方法在总体EX上比所有基于提示的方法表现更差，但在QVT上却超过了它们。

● 发现6：在QVT方面，基于LLM的方法和基于PLM的方法之间没有明显的胜者。而使用特定任务数据集对模型进行微调，可能有助于稳定其针对NL变体的性能。

4.2.4 实验4：数据库领域适应

在实际的NL2SQL应用中，场景通常涉及特定领域的数据库，如电影或体育，每个都有独特的模式设计和术语。评估方法在不同领域的详细性能对于有效的模型应用至关重要。

Spider数据集中不同数据库领域的EX性能

根据图(a)，实验发现不同的NL2SQL方法对不同领域表现出不同的偏好，基于LLM和基于PLM的方法之间没有明显的胜者。然而，在图(b)中，实验观察到基于微调的方法在有更多训练数据库的领域（学院、竞赛、交通）中表现更好。相反，在训练数据库较少的领域中，基于提示的方法表现出色。

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

4.2.5 实验5：基于LLM方法的监督微调

实验研究了开源LLMs对NL2SQL任务的监督微调（SFT）。鉴于NL2SQL是一项与代码相关的任务，本文选择了五种具有不同代码能力的开源LLMs，使用 HumanEval（Pass@1）指标进行评估。为了确保公平比较并考虑硬件限制，所有选择的LLMs都有相似的参数。对于实验设置中介绍的基于微调的LLMs，使用指令微调方法，即Alpaca，使用Adam优化器，学习率为1e-5，不进行权重衰减。SFT后，使用EX指标在SpiderDev集上评估LLM。

监督微调的效果

实验表明，SFT后，模型性能（EX）有所提升，但不同基础模型之间差异显著。这些性能差异与模型在SFT前的内在编码能力（HumanEval）之间存在正相关。这表明，选择具有高级编码能力的基础LLM有助于适应NL2SQL任务。

● 发现8：对开源LLM进行NL2SQL任务的监督微调（SFT）后，发现SFT后的性能与模型微调前的内在编码能力呈正相关。这表明具有高级编码能力的基础LLM对适应NL2SQL任务很重要。

4.3 评估效率的实验

4.3.1 实验6：基于LLM方法的经济性

在本实验中，根据Spider和BIRD的开发集，为每种基于提示的方法计算了多个指标，包括每个NL2SQL任务的词元数量和成本（以美元为单位），同时还计算了EX与平均成本的比率，这在一定程度上表明了NL2SQL方法的成本效益。

基于LLM方法在两个数据集上的经济性结果

实验发现，尽管C3SQL在两个数据集上的EX得分最低，但其EX与平均成本的比率最高，这得益于GPT-3.5-turbo接口相比GPT-4更低的成本。在使用GPT-4的方法中，DINSQL的成本效益最低。DAILSQL成为最具成本效益的方法。而即使DAILSQL(SC)在两个数据集上的表现优于DAILSQL，但它引入了更高的成本。

● 发现9：基于每个NL2SQL任务的执行准确率（EX）与平均成本的比率，调用GPT-3.5-turbo的基于提示的LLM方法具有更高的成本效益。

4.3.2 实验7：基于PLM方法的效率

根据可用的硬件资源和延迟要求选择合适的NL2SQL方法是一个常见的挑战。实验评估了六个模型的三个指标：RESDSQL-Base/Large/3B和RESDSQL-Base/Large/3B+NatSQL，重点关注执行准确率（EX）、每个样本的延迟和使用的GPU内存，使用Spider开发集进行评估。

基于PLM方法在Spider数据集上的效率结果

实验表明，对于相同的方法，随着模型参数规模的增加，所需的GPU内存和延迟也会增加。然而，参数为220M的RESDSQL-Base+NatSQL和参数为770M的RESDSQL-Large实现了相似的EX分数，前者每个样本的延迟更低，所需的GPU内存更少。这说明尽管不同的模型可能有相似的EX分数，但它们在延迟和硬件要求上可能有很大差异。在实际场景中，应根据延迟要求和可用硬件资源选择合适的模型。

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

4.3.3 实验8：SQL效率-有效效率得分

在实际场景中，不仅要关注模型生成的SQL查询的正确性，还要关注其执行效率。BIRD引入了有效效率得分（VES）来评估正确生成的SQL查询的执行效率。VES由真实SQL查询的执行时间除以预测SQL查询的执行时间确定。实验使用VES指标在Spider和BIRD的开发集上评估不同的方法，以比较不同方法生成的SQL的执行效率。

在两个数据集上的VES得分

表中最高的VES分数以橙色突出显示。实验表明，不同难度子集上VES最佳的方法并不一致，基于LLM和基于PLM的方法之间没有明显的胜者。对于相同的方法，在更困难的子集上往往具有更低的VES，这可能是由于SQL的复杂性增加以及相关的预测挑战和执行时间所致。

● 发现11：基于VES指标，基于LLM和基于PLM的方法之间没有明显的胜者。对于相同的方法，在更困难的子集上往往具有更低的 VES。

4.3.4 实验9：训练样本数量的影响

在现实场景中，有限的领域内数据通常会影响性能。实验在Spider子集上训练不同的方法，并在Spider上评估它们的EX性能。

训练样本数量影响结果

实验表明，基于PLM和基于微调的LLM方法都随着NL2SQL训练数据的增加而改进，并且在4000个训练样本时达到可接受的性能。然而，随着数据集规模的增加，EX性能的提升会减小。如果存在数据隐私问题或没有足够的标记数据，微调LLM/PLM是有效的。

● 发现12：基于PLM和基于LLM的方法都随着更多的NL2SQL训练数据而改进。然而，随着数据集规模的增加，EX性能的提升会减小。

5. 结合两者的优势

5.1 设计空间探索

本文探索了由语言模型驱动的NL2SQL解决方案的设计空间，有如下部分：

NL2SQL解决方案的设计空间

1. 预处理：预处理模块包括模式链接和数据库内容。模式链接将NL查询引用映射到数据库模式元素（表、列），增强跨领域的泛化能力和复杂查询的生成。这种方法被基于LLM和基于PLM的方法广泛采用。此外，数据库内容模块将查询条件与数据库内容对齐，通常通过字符串匹配来丰富列细节。虽然在基于PLM的方法中很普遍，但在基于LLM的方法中很少使用。

2． 提示策略：提示策略分为零样本（模型输入中不包含NL2SQL示例）和少样本（包含此类示例）。基于PLM的方法通常使用零样本，而基于LLM的方法则有所不同：C3SQL使用零样本，而DAILSQL和DINSQL使用少样本。

3. SQL生成策略：语言模型采用各种策略生成SQL，分为三个关键方面：多步、解码策略和中间表示。

● 多步：类似于思维链（COT）过程，涉及分阶段生成SQL查询，特别适用于复杂查询，包括两种类型的多步策略：RESDSQL的“SQL骨架-SQL”和DINSQL的“子查询-SQL”。

● 解码策略：涉及模型的解码过程，以确保输出有效性。基于PLM的PICARD在其输出中强制SQL语法合规，而基于LLM的方法利用OpenAI的API，缺乏这种解码级别的限制。

● 中间表示：该策略探索模型是否采用中间查询形式来解决自然语言到SQL翻译的不匹配问题，其中SQL对关系数据库的设计与自然语言语义不直接相关。目前已经引入了各种解决方案，如NatSQL。

4. 后处理：主要有以下策略：

● 自我纠正：如在DINSQL中提出。它将生成的SQL提供给模型以修复潜在问题。

● 自我一致性：涉及为单个NL查询执行各种有效SQL查询，使用结果的投票机制来确定最一致的SQL作为最终选择。

● 执行引导的SQL选择器：这个模块按顺序执行模型生成的SQL查询，将第一个无错误执行的查询识别为有效SQL。

● N-best重排序器：对多个候选SQL查询进行排序，以选择最可能的一个作为最终查询。

5.2 NL2SQL360促进更好的NL2SQL

在将不同方法分类到统一的模块化框架中后，出现了一个问题：是否可以通过组合来自不同NL2SQL系统的不同模块来实现更强的性能？

为了解决这个问题，受神经架构搜索（NAS）算法的启发，本文在NL2SQL360框架内设计了一个NL2SQL自动架构搜索算法（NL2SQL360-AAS）。NL2SQL360-AAS可以自动探索NL2SQL解决方案的预定义设计空间。与NL2SQL360-AAS相关的概念如下：

搜索空间：包括NL2SQL中使用的各种模块，比如SQL生成策略、后处理模块和提示技术。

个体：指搜索空间中不同模块的有效组合，即有效的NL2SQL解决方案即为一个个体。

目标指标：目标是根据指定数据集上的目标指标，如执行准确率（EX）、精确匹配准确率（EM）和有效效率得分（VES），以选择更好的个体。

NL2SQL360-AAS算法概述

NL2SQL360-AAS算法包括四个主要步骤，即初始化、个体选择、NL2SQL模块交换和NL2SQL模块突变。其中是第t代种群中的第i个个体。

1. 步骤1：初始化：初始化个随机化的NL2SQL系统个体，这些个体由随机模块组成，生成第0代种群。

2. 步骤2：个体选择：使用目标指标在指定数据集上评估N个个体的种群。通过俄罗斯轮盘赌过程进行个体选择：该过程根据个体的目标指标分布概率性地采样个体，确保目标指标较高的个体有更大的被选中的可能性，同时持续淘汰表现最差的个体。

3. 步骤3：NL2SQL模块交换：从先前步骤中选择的两个个体将根据模块交换概率交换它们的NL2SQL模块。模块交换后的个体分别标记为和。

4. 步骤4：NL2SQL模块突变：接下来，个体将根据模块突变概率在每一层（如预处理层）进行模块突变。如果的预处理层不使用数据库内容模块，成功的突变将导致包含该模块。突变后，个体标记为，并进入下一代种群。

重复步骤2、3和4，直到获得完整的下一代种群，标志着一次完整的种群迭代。

5.3 NL2SQL360-AAS的案例研究

实验验证NL2SQL360-AAS算法的有效性。为了简化，本文在提示策略中仅利DAILSQL的少样本模块，解码策略中仅使用贪心搜索。实验使用Spider开发集作为目标数据集，执行准确率（EX）作为目标NL2SQL指标。种群大小N设置为 10，种群数T为20，和分别设置为0.5和0.2，使用GPT-3.5-turbo作为主干模型。

1. SuperSQL：实验从算法生成的最后一代中选择执行准确率最高的个体作为最终搜索的NL2SQL解决方案，即SuperSQL。SuperSQL的组成如下：

● 在预处理层，它利用来自RESDSQL的模式链接模块和来自BRIDGE v2的数据库内容模块。

● 在提示层，它使用DAILSQL的少样本模块，该模块基于相似性动态选择上下文示例。

● 在SQL生成层，它使用OpenAI的默认贪心解码策略，不包括多步或 NatSQL中间表示。

● 在后处理层，它结合了来自DAILSQL的自我一致性模块。

一个使用数据库内容提示清除架构的例子

在这种组合下，基于DAILSQL提示，RESDSQL模式链接模块用于过滤掉不相关的模式项。此外，它结合了来自BRIDGE v2方法的数据库内容模块，使用字符串匹配算法将NL查询与数据库中的内容匹配。相关内容随后作为注释添加到提示中相应列的后面，从而丰富了列的信息。将主干模型替换为GPT-4，也能获得更强的性能。

2. SuperSQL的有效性：实验在Spider上评估SuperSQL，实现了在测试集上87.0%的EX，优于其他竞争方法。对于不同难度的SQL查询，SuperSQL在中等、困难和额外困难级别的子集上取得了最佳结果，证明了其有效性。此外，在BIRD上，SuperSQL也表现出有竞争力的性能。这主要归功于NL2SQL360-AAS，它基于设计空间中的不同基线有效地搜索更好的模块组合。

SuperSQL在两个数据集上的总体准确性

3. SuperSQL的效率：通过计算VES指标以评估Spider和BIRD上的SQL效率表明，SuperSQL分别获得了测试集上99.18和61.99的总体VES分数，优于其他方法。

SuperSQL在两个数据集上的VES得分

4. SuperSQL的经济性：此外，与其他基于GPT-4的方法相比，SuperSQL使用更少的词元和更低的成本，同时实现更高的EX。

SuperSQL在连个数据集上的经济性结果

6. 研究机会

基于实验发现，本文讨论未来的研究机会：

1. 使NL2SQL方法值得信赖：当前方法可能生成不正确的SQL结果，这可归因于以下因素：模糊和不明确的NL查询；模糊的数据库模式和脏内容；以及模式链接能力不足。

● 对于处理模糊和不明确的NL查询，可以探索以下策略来缓解这些问题：查询重写器旨在自动完善给定的NL查询并确保其清晰度；查询自动完成建议与数据库良好对齐的候选标记，来帮助制定用户查询。

● 对于解释NL2SQL的解决方案，NL2SQL调试器可以检测不正确的SQL查询，允许用户逐步完成SQL生成过程，识别错误或不匹配，并理解生成的SQL背后的逻辑。SQL和查询结果解释则帮助用户了解生成的SQL和查询结果是否满足他们的要求。

2. 开发具有成本效益的NL2SQL方法：基于LLM的NL2SQL方法很有前途，但词元消耗成本较高，影响成本和推理时间。探索在最小化词元使用的同时提高准确性的方法至关重要。模块化NL2SQL解决方案和多智能体框架可以将LLM与这些方法结合有可能优化准确性和效率，特别是对于复杂查询，同时节省词元。

3. 自适应训练数据生成：NL2SQL方法的有效性在很大程度上取决于训练数据的质量和覆盖范围。这些方法通常难以适应未见的数据库。一个研究方向是基于模型评估反馈自动生成（NL,SQL）对。关键思想是动态合成（NL,SQL）对，通过利用从NL2SQL性能评估中获得的见解解决领域适应挑战和对高质量、多样化训练数据的需求。

7. 结论

本文提出了一个名为NL2SQL360的多角度测试平台，用于从不同视角（如处理各种SQL特性和数据库领域的能力）对NL2SQL方法进行细粒度评估，利用NL2SQL360在2个广泛使用的基准上评估了13种基于LLM和7种基于PLM的NL2SQL方法，并得出了一系列新发现。此外，本文利用NL2SQL360分析了NL2SQL解决方案的设计空间，并搜索出最适合用户特定需求的最佳解决方案SuperSQL。SuperSQL融合了基于LLM和基于PLM的模块，在Spider和BIRD测试集上分别实现了87%和62.66%的执行准确率。

论文解读联系人：

刘思源

13691032906（微信同号）

liusiyuan@caict.ac.cn