NL2SQL与大型语言模型的综述：我们身处何方，又将去向何处？

将用户的自然语言查询（NL）转换为SQL查询（即NL2SQL，也称为Text-to-SQL）可以显著降低访问关系数据库的障碍，并支持各种商业应用。随着大型语言模型（LLMs）的出现，NL2SQL的性能得到了极大提升。在本综述中，我们从以下四个方面全面回顾了由LLMs驱动的NL2SQL技术：（1） 模型： 解决自然语言歧义和不明确性，同时正确映射自然语言与数据库模式和实例的NL2SQL翻译技术；（2） 数据： 从训练数据的收集、由于训练数据稀缺而进行的数据合成到NL2SQL基准测试；（3） 评估： 使用不同指标和粒度从多个角度评估NL2SQL方法；（4） 错误分析： 分析NL2SQL错误以找到根本原因并指导NL2SQL模型的发展。此外，我们提供了开发NL2SQL解决方案的经验法则。最后，我们讨论了LLMs时代NL2SQL的研究挑战和开放问题。

自然语言转SQL，文本转SQL，数据库接口，大型语言模型。

1 引言

语言转SQL（即 nl2sql ，也称为Text-to-SQL），将自然语言查询（ nl ) 转换为可以在关系数据库上执行的SQL查询（ sql )，是降低访问关系数据库门槛的关键技术 (Gu et al. 2023a; Z. Chen et al. 2023; L. Wang 和 al. 2022; A. Liu et al. 2022; Pourreza 和 Rafiei 2024a; D. Gao et al. 2024; H. Li et al. 2023) 。该技术支持多种重要应用，如商业智能和数据库的自然语言接口，使其成为普及数据科学的关键一步 (N. Tang 等人 2024; Ye 等人 2024; Y. Zhu 等人 2024; Yupeng Xie 等人 2023; Shen 等人 2023; Luo, Qin, 等人 2022; Luo, Tang, 等人 2022, 2021; J. Tang 等人 2022; Qin 等人 2020; Luo, Qin, Tang, 和 al. 2018; Luo, Qin, Tang, Li, 等人 2018) 。近年来，语言模型的进步显著扩展了 nl2sql 研究和应用的前沿。与此同时，数据库厂商提供 nl2sql 解决方案的趋势已从概念演变为必要策略 (Zhou, Sun, 和 Li 2024; Amer-Yahia 和 al. 2023) 。因此，我们需要理解 nl2sql 的基础知识、技术和挑战。

在本次调查中，我们将通过一个新的框架系统地回顾最近的 nl2sql 技术，如图 [fig:overview] 所示。

• 基于语言模型的NL2SQL。 我们将首先从语言模型的角度回顾现有的 nl2sql 解决方案，将其分类为四大类（见图 [fig:overview] (a)）。然后，我们将重点关注预训练语言模型（PLMs）和大型语言模型（LLMs）在 nl2sql 中的最新进展。
• 基准和训练数据合成 。毫无疑问，PLM 和 LLM 基础的 nl2sql 模型的性能高度依赖于训练数据的数量和质量。因此，我们将首先总结现有基准的特征并详细分析其统计信息（例如，数据库和查询复杂性）。然后，我们将讨论收集和合成高质量训练数据的方法，强调这是一个研究机会（见图 [fig:overview] (b))。
• 评估。 全面评估 nl2sql 模型对于优化和选择适用于不同使用场景的模型至关重要。我们将讨论多角度评估和基于场景的评估（见图 [fig:overview] (c)）。例如，我们可以通过过滤基准来评估特定上下文中的 nl2sql 模型，例如根据 SQL 特征、 nl 变体、数据库领域等。
• NL2SQL 错误分析。 错误分析在 nl2sql 研究中至关重要，用于识别局限性和提高模型鲁棒性。我们回顾了现有的错误分类法，分析了它们的局限性，并提出了设计综合的 nl2sql 输出错误分类法的原则。利用这些原则，我们创建了一个两级错误分类法，并用它来总结和分析 nl2sql 输出错误（见图 [fig:overview] (d))。
  除了上述内容外，我们还将提供开发 nl2sql 解决方案的实际指导，包括优化LLMs以适应 nl2sql 任务的路线图和针对不同 nl2sql 场景选择模块的决策流程。最后，我们将讨论该领域的关键开放问题，如开放 nl2sql 任务、成本效益的 nl2sql 与LLMs结合以及可信的 nl2sql 解决方案。
  我们的综述与现有的 nl2sql 综述 (W. Zhang 等人 2024; Katsogiannis-Meimarakis 和 Koutrika 2023; Deng, Chen, 和 Zhang 2022; Kim 等人 2020; Shi 等人 2024; Mohammadjafari, Maida, 和 Gottumukkala 2024; X. Zhu 等人 2024; Hong 等人 2024) 和教程 (Őzcan 等人 2020; Y. Li 和 Rafiei 2017; Katsogiannis-Meimarakis 和 al. 2023) 在五个方面有所区别。
• 我们系统地回顾了 nl2sql 问题的整个生命周期，如图 [fig:overview] 所示。该生命周期包括由语言模型驱动的各种 nl2sql 翻译方法（图 [fig:overview] (a)）、训练数据收集和合成方法（图 [fig:overview] (b)）、多角度和场景评估（图 [fig:overview] (c)）和 nl2sql 输出错误分析技术（图 [fig:overview] (d)）。
• 我们更详细和全面地总结了 nl2sql 中的固有挑战。此外，我们分析了开发面向真实场景的稳健 nl2sql 解决方案时的技术挑战，这在其他综述中常被忽视。
• 我们特别关注最近的基于LLM的 nl2sql 方法，总结关键模块并比较此范围内的不同策略。 我们是第一个提供模块化总结并为每个关键模块提供详细分析的综述（例如，数据库内容检索）。
• 我们强调了 nl2sql 方法多角度评估的重要性，分析了关键的 nl2sql 错误模式，并提供了一个两级错误分类法。
• 我们为从业者提供了优化LLMs以完成 nl2sql 任务的路线图，以及为不同使用场景选择合适的 nl2sql 模块的决策流程。
  我们做出了以下贡献。
• 基于语言模型的NL2SQL。 我们从生命周期的角度全面回顾了现有的 nl2sql 技术（图 [fig:overview] )。我们介绍了 nl2sql 任务定义，讨论了挑战（图 1 )，根据语言模型对 nl2sql 解决方案进行了分类（图 [fig:evoluation_process] )，并总结了基于语言模型的 nl2sql 解决方案的关键模块（图 3 和表 [tab:Methods] )。接下来，我们详细介绍了基于语言模型的 nl2sql 方法的各个模块，包括预处理策略（第 4 节）、 nl2sql 翻译方法（第 5 节）和后处理技术（第 6 节）。
• 基准和训练数据合成。 我们根据其特征总结了现有的 nl2sql 基准（图 [fig:dataset_timeline] )。我们深入分析了每个基准的优缺点（表 [tab:datasets] )。（第 7 节）
• 评估和错误分析。 我们强调了评估在开发实用 nl2sql 解决方案中的重要性。我们回顾了广泛使用的评估指标和工具包，以评估 nl2sql 解决方案。我们提供了一个分类法，以总结 nl2sql 方法产生的典型错误。（第 8 节）
• 开发NL2SQL解决方案的实践指导。 我们提供了优化现有LLMs以完成 nl2sql 任务的路线图（图 [fig:NL2SQL_Guidance] (a)）。此外，我们设计了一种决策流程，以指导不同场景下适当 nl2sql 模块的选择（图 [fig:NL2SQL_Guidance] (b)）。
• NL2SQL中的开放问题。 最后，我们讨论了新的研究机遇，包括开放世界的 nl2sql 问题和成本效益的 nl2sql 解决方案（第 10 节）。
• NL2SQL手册。 我们维护了一份在线手册（ https://github.com/HKUSTDial/NL2SQL_Handbook )，以帮助读者了解 nl2sql 的最新进展。
  2 NL2SQL问题及背景
  在本节中，我们首先形式化定义了 nl2sql 任务（第 2.1 节）。然后介绍人类执行 nl2sql 任务的工作流程（第 2.2 节）并讨论关键挑战（第 2.3 节）。最后，我们描述了基于语言模型发展的 nl2sql 解决方案的演变（第 2.4 节）。
  2.1 问题公式化
  定义 1 ( 自然语言到SQL (NL2SQL) )。自然语言到SQL（ nl2sql )，也称为文本到SQL，是将自然语言查询（ nl ) 转换为可以在关系数据库（ db ) 上执行的相应SQL查询（ sql ) 的任务。具体来说，给定一个 nl 和一个 db , nl2sql 的目标是生成一个能够准确反映用户意图并在数据库上执行时返回适当结果的 sql 。
  在某些情况下，由于 nl 的歧义或不明确性，或者数据库模式的歧义，对应于一个 nl 的 sql 查询可能有多个。此外，即使 nl 、数据库模式和数据库内容清晰具体，也可能存在多个等效的 sql 查询可以满足给定的 nl 问题。

nl2sql 任务及其挑战的例子。
2.2 NL2SQL人工工作流
当专业用户（例如DBA）执行 nl2sql 任务时，他们首先解释 nl 问题，检查数据库模式和内容，然后根据他们的SQL专业知识构建相应的 sql 。下面，我们将详细说明这个过程，如图 1 (a)所示。
给出 nl 查询“ 找出2023年劳动节恰好借阅了3种不同类型的书籍的所有客户的姓名 ”，DBA的第一个任务是掌握用户意图并识别关键组件。关键元素包括：1) 实体或属性 ：“姓名”、“客户”、“书籍”和“类型”；2) 时间背景 ：“2023年劳动节”；3) 具体条件 ：“恰好3种不同类型的书籍”。然后，DBA可能会进一步理解整个 nl 查询的目的。在这种情况下，DBA应根据特定日期的特定借阅行为检索客户姓名列表。
接下来，DBA检查数据库模式和内容，以识别构建 sql 所需的表格、列和单元格值。例如，DBA可以根据对 nl 的理解确定“客户”和“书籍”表相关（参见图 1 (a)-）。DBA然后决定应该提到哪些列。例如，关键字“类型”可以指代“LiteraryGenre”或“SubjectGenre”（参见图 1 (a)-）。此外，DBA应根据上下文解释“2023年劳动节”。在美国，“2023年劳动节”指的是“2023年9月4日”，而在在中国，则指的是“2023年5月1日”。这种判断依赖于领域知识或可用的额外信息（参见图 1 (a)-）。
注意，步骤2与最近基于语言模型的 nl2sql 解决方案中的 模式链接 、 数据库内容检索 和 附加信息获取 的概念相一致（请参阅图 3 了解更多细节）。
最后，DBA根据前两步获得的见解编写相应的 sql 。这个过程被称为“ nl2sql 翻译”，严重依赖DBA的SQL专业知识。然而，由于 nl 的歧义或数据库的复杂性，这一过程可能非常具有挑战性。例如，如图 1 (a)所示，尽管理解需要连接“客户”和“书籍”表，但必须熟悉使用自然连接或子查询。
从以上步骤中，我们可以直观地识别出 nl2sql 任务中的三个内在挑战：自然语言的不确定性、数据库的复杂性以及从“自由形式”的自然语言查询到“受约束且正式”的 sql 查询的翻译。
2.3 NL2SQL任务挑战
在本节中，我们将首先讨论 nl2sql 任务的基本挑战。然后分析开发强大的 nl2sql 解决方案在现实世界场景中面临的 技术 挑战。
自然语言查询通常包含由于歧义和不明确性引起的不确定性 (Katsogiannis-Meimarakis 和 Koutrika 2021) 。 nl2sql 任务中与 nl 相关的挑战可概括如下：

• 词汇歧义 ：当一个单词有多个含义时发生。例如，“bat”这个词可以指动物或名词“棒球棍”或动词“挥动”。
• 句法歧义 ：当一个句子可以有多种解析方式时发生。例如，在句子“Mary用望远镜看到了那个男人”中，“用望远镜”可以表示Mary用望远镜看到男人，也可以表示男人带着望远镜。
• 不明确性 ：当语言表达缺乏足够的细节来清楚传达特定意图或含义时发生。例如，“2023年的劳动节”在美国指的是“2023年9月4日”，在中国则指的是“2023年5月1日”。
  nl2sql 任务要求对数据库模式有深刻理解，包括表名、列、关系和数据属性。现代模式的复杂性和大量数据使这项任务尤为困难。
• 表间复杂关系 ：数据库经常包含数百个表，表间关系复杂。 nl2sql 解决方案必须准确理解并利用这些关系，以生成 sql 查询。
• 属性和值的歧义 ： nl2sql 系统难以正确识别模糊值和属性。
• 领域特定的模式设计 ：不同领域通常有不同的数据库设计和模式模式。跨领域的模式设计差异使得很难开发出通用的 nl2sql 解决方案。
• 大且脏的数据库值 ：高效处理大型数据库中的大量数据非常重要，因为将所有数据作为输入进行处理是不切实际的。此外，脏数据（如缺失值、重复项或不一致）如果管理不当，可能导致错误的查询结果（例如，影响 WHERE 子句）。
  nl2sql 任务不同于高级编程语言编译为低级机器语言，因为它通常在输入 nl 和输出 sql 查询之间具有一对多的映射。具体而言， nl2sql 任务面临以下几个独特挑战：
• 自由形式的 nl vs. 受约束且正式的 sql ：自然语言灵活，而 sql 查询必须遵循严格的语法。将 nl 转换为 sql 需要精确性以确保生成的查询可执行。
• 多个可能的 sql 查询 ：单个 nl 查询可能对应多个满足查询意图的 sql 查询，导致难以确定适当的 sql 翻译（参见图 1 (a)中的示例）。
• 依赖数据库模式 ： nl2sql 翻译高度依赖底层数据库模式。如图 1 (a) 和(b)所示，相同的 nl 可能根据模式变化产生不同的 sql 查询。这要求 nl2sql 模型弥合训练数据和现实世界模式差异之间的差距。
  超越 nl2sql 任务的内在挑战，开发者还必须克服几个技术障碍，以构建可靠高效的 nl2sql 系统，如下所述。
  开发稳健的 nl2sql 解决方案需要应对以下几个关键技术挑战：
• 成本效益解决方案 ：部署 nl2sql 模型，尤其是使用大型语言模型的模型，需要大量的资源，如硬件和/或API成本。实现模型性能和成本效率之间的最佳平衡仍然是一个关键挑战。
• 模型效率 ：通常存在模型大小与性能之间的权衡，较大的模型一般会产生更好的结果。在交互式查询场景中，优化效率而不损害准确性尤为重要，需要低延迟。
• SQL效率 ： nl2sql 模型生成的 sql 必须既正确又经过优化以提高性能。这包括优化联接操作、索引使用和查询结构。有效的查询减少了数据库负载，提高了系统响应速度和吞吐量。
• 不足且嘈杂的训练数据 ：获得高质量的 nl2sql 训练数据非常困难。公共数据集往往有限，可能包含噪声标注，影响模型性能。注释需要数据库专业知识，增加了成本，而 nl2sql 任务的复杂性常常导致错误。
• 可信度和可靠性 ： nl2sql 模型必须可信且可靠，能够在多样化的数据集和场景中始终如一地生成准确的结果。可信度要求透明性，让用户能够理解和验证生成的 sql 。
  2.4 使用大型语言模型解决挑战
  我们将 nl2sql 的难度分为五个级别，每个级别解决特定的障碍，如图 [fig:evoluation_process] (a)所示。前三个级别涵盖了已经解决或将要解决的挑战，突显了 nl2sql 能力的逐步进步。第四个级别包括当前基于LLM的解决方案所面临的挑战，第五个级别代表未来挑战，展示了我们对未来五年内 nl2sql 发展的愿景。
  nl2sql 解决方案的发展，如图 [fig:evoluation_process] (b)所示，经历了四个阶段：基于规则的阶段、基于神经网络的阶段、基于PLM的阶段和基于LLM的阶段。在每个阶段，我们分析了目标用户的变化，即从专家到更广泛的用户群体，以及各种 nl2sql 挑战的解决程度。

PLM和LLM在NL2SQL中的分类。
2.4.1 基于规则的阶段
在早期阶段，统计语言模型（例如语义解析器）被用于解释 nl 查询并使用预定义规则将其转换为 sql 查询 (Rajkumar 和 al. 2022; F. Li 和 Jagadish 2014b; Katsogiannis-Meimarakis 和 Koutrika 2021; Yu 等人 2021) 。然而，基于规则的 nl2sql 方法在适应性、可扩展性和泛化方面面临挑战。在此阶段，自然语言理解仅限于标记级别，研究主要集中在单表 sql 查询（参见图 [fig:evoluation_process] (b)-）。
2.4.2 基于神经网络的阶段
为了缓解基于规则方法的局限性，研究人员探索了神经网络在 nl2sql 任务中的应用。这导致了基于序列到序列架构和图神经网络的模型的发展 (Xiao, Dymetman, 和 Gardent 2016; K. Lin 等人 2019; Bogin, Gardner, 和 al. 2019) ，增强了同义词处理和意图理解的能力。因此，研究从单表场景发展到更复杂的多表场景（参见图 [fig:evoluation_process] (b)-）。然而，这些方法的泛化能力仍受限于模型规模和足够训练数据的可用性。
2.4.3 基于PLM的阶段
2018年引入的PLMs如BERT (Devlin 等人 2019) 和T5 (Raffel 等人 2020) 显著推动了基于PLMs的 nl2sql 方法的发展 (J. Li 等人 2023; H. Li 等人 2023; Gu 等人 2023b) ，在各种基准测试中表现出色（参见图 [fig:evoluation_process] (b)-）。在此阶段，基于大规模语料库训练的PLMs极大地提升了自然语言理解能力，解决了Spider数据集中约80%的案例 (Yu, Zhang, 等人 2018) 。然而，在Spider数据集的额外难题案例中，准确率下降到约50% (B. Li 等人 2024) 。此外，这些模型在处理复杂模式方面仍面临挑战。
图 2 显示了PLMs和LLMs之间的关键区别。LLMs是PLMs的一个子集，以其先进的语言理解能力和新兴能力著称 (W. X. Zhao 等人 2023; Minaee 等人 2024) 。这些新兴能力使LLMs能够直接通过提示执行 nl2sql 任务。相比之下，PLMs通常需要额外的预训练或微调以达到可接受的 nl2sql 性能。
2.4.4 基于LLM的阶段
LLMs展示了超越传统PLMs的独特新兴能力，标志着 nl2sql 解决方案的新范式。这些基于LLM的 nl2sql 方法已成为当前 nl2sql 领域的代表性解决方案 (Pourreza 和 Rafiei 2024a; H. Li 等人 2024; D. Gao 等人 2024; C. Zhang 和 al. 2024) 。当前研究的重点是优化提示设计 (D. Gao 等人 2024) 和微调LLMs (H. Li 等人 2024) 。例如，DAIL-SQL (D. Gao 等人 2024) 利用GPT-4与有效的提示工程技术，在Spider数据集上取得了强大的结果 (Yu, Zhang, 等人 2018) 。与此同时，CodeS (H. Li 等人 2024) 通过在大型 nl2sql 相关语料库上预训练StarCoder (R. Li 等人 2023) ，专门为 nl2sql 任务构建了一个LLM，表现出色于如BIRD等基准测试 (J. Li 等人 2023) 。在此阶段，LLMs的新兴能力显著提升了自然语言理解水平，使任务重点转向数据库特定挑战。新基准如BIRD (J. Li 等人 2023) 和BULL (C. Zhang 和 al. 2024) 强调处理大规模表和领域特定解决方案（参见图 [fig:evoluation_process] (b)-）。
总的来说，有两大类方法可以利用LLMs的能力进行 nl2sql ：1) 上下文学习，2) 预训练/微调专门用于 nl2sql 的LLMs。

采用上下文学习策略进行 nl2sql 将LLMs视为 现成工具 , 不修改其参数。然而，如果用户有足够的训练数据或硬件资源，调整LLMs的参数可以提高性能和准确性，使模型更贴近具体的 nl2sql 任务。

3 基于语言模型的 nl2sql 概述

NL2SQL模块在LLM时代的概览。
在本节中，我们首先总结了基于PLM和LLM的 nl2sql 解决方案的关键模块，如图 3 所示。接下来，我们在表 [tab:Methods] 中比较了现有 nl2sql 解决方案模块之间的主要差异。
预处理步骤增强了 nl2sql 解析过程中的模型输入。虽然不是严格必要，但预处理显著改进了 nl2sql 解析 (Lei 等人 2020) 。

• 模式链接：此关键模块从 nl2sql 中识别最相关的表格和列（第 4.1 节）。
• 数据库内容检索：此关键模块访问生成 sql 所需的适当数据库内容或单元格值（第 4.2 节）。
• 附加信息获取：此关键模块通过集成领域特定知识来丰富背景（第 4.3 节）。
  这是 nl2sql 解决方案的核心，负责将输入的 nl 查询转换为 sql 。
• 编码策略：此重要模块将输入的 nl 和数据库模式转换为内部表示形式，捕捉输入数据的语义和结构信息（第 5.1 节）。
• 解码策略：此关键模块将内部表示形式转换为 sql 查询（第 5.2 节）。
• 任务特定提示策略：此模块为 nl2sql 模型提供定制化指导，优化 nl2sql 翻译流程（第 5.3 节）。
• 中间表示：此模块作为 nl 到 sql 翻译的桥梁，提供了抽象、对齐和优化 nl 理解的结构化方法，简化复杂推理并指导准确生成 sql 查询（第 5.4 节）。
  后处理是精炼生成的 sql 查询以提高准确性的关键步骤。
• SQL修正策略：旨在识别并修正生成的 sql 中的语法错误（第 6.1 节）。
• 输出一致性：此模块通过采样多个推理结果并选择最一致的结果确保 sql 的一致性（第 6.2 节）。
• 执行导向策略：它使用 sql 的执行结果指导后续改进（第 6.3 节）。

4 NL2SQL的预处理策略
预处理步骤在 nl2sql 翻译过程中至关重要，因为它识别相关表格和列（即模式链接）并检索必要的数据库内容或单元格值（即数据库内容检索），以支持 sql 查询生成。此外，它通过整合领域特定知识（即附加信息获取）丰富了上下文，这可以改进查询上下文的理解并防止错误传播。
4.1 模式链接
模式链接旨在识别与给定 nl 查询相关的表格和列，确保关键信息的准确映射和处理。此步骤对于改进 nl2sql 任务的性能至关重要。在LLM时代，由于LLM的输入长度限制，模式链接变得更加重要。
我们将现有的模式链接策略根据其特征分为三组： 1) 基于字符串匹配的模式链接 , 2) 基于神经网络的模式链接 , 和 3) 基于上下文学习的模式链接 。
4.1.1 基于字符串匹配的模式链接
早期研究 (Guo 等人 2019; Yu, Li, 等人 2018; K. Lin 等人 2019) 主要集中在基于字符串匹配技术的模式链接。这些方法使用 nl 查询和模式之间的相似度度量来识别相关映射。常用的匹配技术包括 精确匹配 和 近似匹配 。
精确匹配，如IRNet所使用的 (Guo 等人 2019) ，当候选对象相同或一个为另一个的子串时识别匹配。尽管这种方法可以检测简单的链接，但如果候选对象共享常见词汇，则可能导致误报。近似字符串匹配技术，如ValueNet中使用的Damerau–Levenshtein距离 (Damerau 1964) 帮助识别尽管存在拼写变化或错误的匹配。
然而，这些方法难以处理同义词，并且不够稳健以应对词汇变化，限制了它们在复杂的 nl2sql 任务中的有效性。
4.1.2 基于神经网络的模式链接
为了缓解上述局限性，研究人员采用了深度神经网络对自然语言查询和数据库结构之间的复杂语义关系进行解析 (Z. Dong 等人 2019; Lei 等人 2020; Bailin Wang 等人 2020; H. Li 等人 2023) 。这些方法能更好地解析复杂的语义关系。DAE (Z. Dong 等人 2019) 将模式链接建模为序列标注问题，使用两阶段匿名化模型捕捉模式和 nl 之间的语义关系。然而，没有注释语料库，DAE无法评估模式链接对 nl2sql 性能的影响。为了解决这一问题，SLSQL (Lei 等人 2020) 在Spider数据集中注释了模式链接信息 (Yu, Zhang, 等人 2018) , 实现了系统、数据驱动的研究。RESDSQL (H. Li 等人 2023) 引入了一种基于排名增强编码的框架用于模式链接，使用交叉编码器根据分类概率优先考虑表格和列。FinSQL (C. Zhang 等人 2024) 使用并行交叉编码器检索相关模式元素，显著减少了链接时间。
然而，基于神经网络的方法在面对具有不同模式或领域的多样化数据库时，尤其是在训练数据稀缺的情况下，往往难以泛化。
4.1.3 基于上下文学习的模式链接
随着像GPT-4这样的LLMs的发展，研究开始探索如何利用其强大的推理能力来进行模式链接，即直接从 nl 查询中识别和链接相关的数据库模式组件。一种关键技术是上下文学习（ICL）技术 (Brown 等人 2020) , 利用LLMs理解复杂语言模式和数据模式中关系的能力，实现更加动态灵活的模式链接过程 (Pourreza 和 Rafiei 2024a; X. Dong 等人 2023; D. Lee 等人 2024; Bing Wang 等人 2023; Talaei 等人 2024) 。
C3-SQL (X. Dong 等人 2023) 使用零样本提示与GPT-3.5结合自洽性进行表和列链接。对于表链接，表按相关性排序并列出；对于列链接，列在相关表内排序并以字典格式输出，优先匹配问题术语或外键。MAC-SQL (Bing Wang 等人 2023) 提出了一个多代理协作框架用于 nl2sql , 其中“选择器”代理处理模式链接，仅在数据库模式提示超过指定长度时激活。CHESS (Talaei 等人 2024) 使用GPT-4从 nl 和证据（来自BIRD的附加信息 (J. Li 等人 2023) ）中提取关键词，实施一个三阶段模式修剪协议，使用不同的提示。
采用ICL进行模式链接已显示出良好的性能。然而，LLMs在处理大量上下文方面有固有限制，意味着复杂模式中包含许多表和列可能超出此限制。
4.2 数据库内容检索
数据库内容检索专注于高效提取特定 sql 子句（如 WHERE )所需的单元格值。我们根据其特征将现有的数据库内容检索策略分为三组： 1) 基于字符串匹配的方法 , 2) 基于神经网络的方法 , 和 3) 数据库内容检索的索引策略 。
4.2.1 基于字符串匹配的方法
基于字符串匹配的方法通过字符串匹配识别并比较与 nl 查询相关的单元格值 (Guo 等人 2019; Brunner 和 Stockinger 2021; H. Li 等人 2023; J. Li 等人 2023; Scholak 和 al. 2021; X. V. Lin 和 al. 2020) 。
IRNet (Guo 等人 2019) 使用n-grams，将引号内的文本视为单元格值。RESDSQL (H. Li 等人 2023) 使用最长公共子串算法 (Aho 和 Corasick 1975) 查找字符串之间最长的共同序列。BRIDGE (X. V. Lin 和 al. 2020) 通过锚文本匹配技术自动从 nl 中提取单元格值。使用启发式算法，计算最大序列匹配以定义匹配边界，排除无关子串并调整阈值以提高准确性。
然而，虽然字符串匹配方法有效，但它们难以处理同义词，并且在处理大型数据库时可能会带来高昂的计算成本。
4.2.2 基于神经网络的方法
这些方法旨在通过多层非线性变换捕捉复杂的数据和语义特征，帮助解决同义词问题。
TABERT (Yin 等人 2020) 使用称为“数据库内容快照”的方法对 nl 查询的相关数据库内容进行编码，通过注意力机制管理不同行的单元格值表示信息。另一种方法是使用图关系表示数据库内容。例如，IRNet (Guo 等人 2019) 使用知识图ConceptNet (Speer, Havasi, 等人 2012) 查找并链接相关单元格值，根据精确或部分匹配分配类型。RAT-SQL (Bailin Wang 等人 2020) 通过建模查询值与列候选单元格值之间的关系，进一步增强了结构化推理，识别查询值是否为列的候选单元格值的一部分。
虽然这些方法捕捉到了语义特征，但它们可能难以处理上下文依赖的 nl , 导致单元格值检索不准确。此外，神经网络的训练需要大量的计算资源。
4.2.3 数据库内容检索的索引策略
高效检索相关单元格值对于 nl2sql 系统的性能至关重要，特别是在处理大数据集时。索引是一种关键方法，通过快速访问相关单元格值提高检索效率 (Talaei 等人 2024; H. Li 等人 2024) 。
CHESS (Talaei 等人 2024) 使用局部敏感哈希 (Indyk 和 Motwani 1998) 进行近似最近邻搜索，索引唯一单元格值以快速找到与 nl 查询最相关的顶级匹配项。该方法加快了编辑距离和语义嵌入的比较。CodeS (H. Li 等人 2024) 采用粗略到精细的匹配策略。它使用BM25 (Robertson, Zaragoza, 等人 2009) 建立索引以进行粗略搜索，识别候选值，然后应用最长公共子串算法 (Aho 和 Corasick 1975) 评估与 nl 查询的相似性，从而精确定位最相关的单元格值。
虽然索引显著提高了检索效率，但构建索引耗时较长，频繁更改数据库内容需要持续更新，增加了开销。
4.3 附加信息获取
附加信息（如领域知识）在增强 nl2sql 模型对 nl 查询、模式链接和整体 nl2sql 翻译的理解中起着至关重要的作用。这些信息可以为 nl2sql 主干模型或特定模块提供示例、领域知识、公式证据和格式信息，从而提高生成结果的质量。我们将现有策略分为以下两类： 1) 示例方法 , 和 2) 检索方法 。
4.3.1 示例方法
随着LLMs和上下文学习技术的进步，研究人员经常将附加信息与文本输入（即提示）一起纳入，以提供示例。DIN-SQL (Pourreza 和 Rafiei 2024a) 通过跨多个阶段的少量学习（few-shot learning）整合附加信息，如模式链接、查询分类、任务分解和自我纠正。这使得DIN-SQL能够处理复杂的模式链接、多表联接和嵌套查询。其他工作 (Chang 和 Fosler-Lussier 2023; H. Li 等人 2024; Talaei 等人 2024) 也采用了类似的策略。在实际数据库中，跨域知识或证据通常可用。例如，BIRD (J. Li 等人 2023) 包含的领域知识对各种 nl2sql 工作至关重要 (D. Gao 等人 2024; Pourreza 和 Rafiei 2024b; Talaei 等人 2024; H. Li 等人 2024; B. Li 等人 2024) 。
= [矩形, draw=hidden-draw, rounded corners, align=left, text opacity=1, minimum height=1.3em, minimum width=5em, inner sep=2pt, fill opacity=.8, line width=0.6pt, ]
= [my-box, minimum height=1.3em, draw=grey!80, fill=grey!15, text=black, font=, inner xsep=1pt, inner ysep=2pt, line width=0.6pt, align=center, ]
= [my-box, minimum height=1.3em, draw=red!80, fill=red!15, text=black, font=, inner xsep=1pt, inner ysep=2pt, line width=0.6pt, align=center, ] = [my-box, minimum height=1.3em, draw=orange!70, fill=orange!15, text=black, font=, inner xsep=1pt, inner ysep=2pt, line width=0.6pt, align=center, ]
= [my-box, minimum height=1.3em, draw=green!80, fill=green!15, text=black, font=, inner xsep=1pt, inner ysep=2pt, line width=0.6pt, align=center, ] = [my-box, minimum height=1.3em, draw=cyan!80, fill=cyan!15, text=black, font=, inner xsep=1pt, inner ysep=2pt, line width=0.6pt, align=center, ]
= [my-box, minimum height=1.3em, draw=red!100, fill=white, text=black, font=, inner xsep=1pt, inner ysep=2pt, line width=0.6pt, ]
= [my-box, minimum height=1.3em, draw=orange!100, fill=white, text=black, font=, inner xsep=1pt, inner ysep=2pt, line width=0.6pt, ]
= [my-box, minimum height=1.3em, draw=green!100, fill=white, text=black, font=, inner xsep=1pt, inner ysep=2pt, line width=0.6pt, ] = [my-box, minimum height=1.3em, draw=cyan!100, fill=white, text=black, font=, inner xsep=1pt, inner ysep=2pt, line width=0.6pt, ]
4.3.2 检索方法

当数据库缺乏文本形式的附加信息时，研究人员开发了从外部知识库检索并转换为自然语言的方法。例如，REGROUP (Dou 等人 2022) 创建了跨领域的公式知识库（如金融、交通），并使用密集段落检索器 (Karpukhin 等人 2020) 计算相似度得分，通过擦除-唤醒模型将相关实体与 nl 和模式集成 (Q. Liu 等人 2021) 。ReBoost (Sui 等人 2023) 使用两阶段解释-压缩模式链接策略，首先向LLMs呈现通用模式，然后应用针对性提示以提高查询到实体映射的准确性。
尽管这些方法通过单个或多个LLMs在多次运行中提高了一致性，减少了模型随机性并增强了准确性，但它们显著增加了推理成本和时间。
5 NL2SQL翻译方法
在本节中，我们将详细说明基于语言模型的 nl2sql 翻译方法。如图 [fig:taxonomy] 所示，我们将详细介绍其编码（第 5.1 节）、解码（第 5.2 节）和任务特定提示策略（第 5.3 节）。此外，我们将讨论中间表示如何有利于 nl2sql 翻译过程（第 5.4 节）。
5.1 编码策略
在 nl2sql 任务中，编码是指将 nl 和数据库模式转换为适合语言模型处理的结构化格式。此步骤对于将非结构化数据转换为可用于 sql 生成的形式至关重要，捕捉 nl 的语义和模式的结构，帮助模型将用户意图映射到适当的 sql 。如图 4 所示，主要编码策略包括 1) 序列编码 , 2) 图编码 , 和 3) 分离编码 。

编码策略的概览。
5.1.1 序列编码策略
序列编码是 nl2sql 模型中的一种策略，其中 nl 和数据库模式都被视为令牌序列。核心思想是对输入数据进行线性化，使基于序列的模型能够有效地捕捉语义和句法信息，如图 4 (a)所示。例如，T5模型 (Raffel 等人 2020) 被用于将 nl 和数据库模式顺序编码的工作中 (Rai 等 2023; Scholak 和 al. 2021) 。BRIDGE (X. V.Lin 和 al. 2020) 通过表示 nl 和数据库模式为带标签的序列，并在相应字段旁边插入匹配的数据库单元格值（称为锚文本）来改进 nl 和数据库模式之间的对齐。类似地，N-best List Rerankers (Zeng, Parthasarathi, 和 Hakkani-Tur 2023) 将数据库内容附加到列名之后。RESDSQL (H. Li 等人 2023) 使用排名增强编码器对模式项进行排序和过滤，优先选择最相关的项并减少模式链接复杂性。CatSQL (Fu 等人 2023) 利用预训练的GraPPa编码网络 (Yu 等人 2021) 将 nl 、模式和附加信息连接成输入序列。
尽管基于LLM的 nl2sql 方法没有显式定义输入编码策略，但大多数依赖于使用自注意力机制处理输入序列。该机制类似于编码过程，根据序列中的前置词预测下一个词。
虽然序列编码简单直观，但它可能难以捕捉数据库模式与 nl 查询之间的复杂关系，从而限制模型理解和生成更复杂的 sql 的能力。
5.1.2 图编码策略
nl2sql 模型中的图编码将 nl 和数据库模式表示为互连的图，利用数据库的关系结构和输入数据中的相互依赖性，如图 4 (b)所示 (Bailin Wang 等人 2020; Rubin 和 Berant 2020; Yu 等人 2021; Huang 等人 2021; Hui 和 al. 2022; Qi 等人 2022; Hu 等人 2023; Bazaga, Liò, 和 al. 2023; J. Li 和 al. 2023) 。与序列编码不同，这种方法保留了模式的拓扑结构，为每个元素提供更丰富的上下文，增强了模型生成准确 sql 查询的能力。

图编码有效地捕捉了输入数据之间的复杂关系，使模型能够生成包含多个关系和条件的更准确的 sql 查询。然而，它需要更复杂的图构建和处理算法，并且其全部潜力可能只有在拥有大量训练数据的情况下才能实现，因此不太适合数据有限的场景。
5.1.3 分离编码策略
分离编码策略是 nl2sql 模型中的一种方法，其中将 nl 的不同部分（如子句和条件）分别编码，然后组合形成最终的 sql , 如图 4 (c)所示。
早期模型，如SQLNet (Xu 和 al. 2017) 和Seq2SQL (Zhong 和 al. 2017) , 由于格式不匹配，通常对 nl 和数据库模式进行分离编码。然而，这种方法阻碍了模式链接，现在较少使用。尽管如此，分离编码允许对不同类型的数据进行有针对性的处理，利用各种编码技术的优势。TKK (C. Gao 等人 2022) 采用任务分解和多任务学习策略，通过逐步集成知识来解决复杂的 nl2sql 任务。SC-Prompt (Gu 等人 2023a) 将文本编码分为两个阶段：结构和内容，分别进行编码。
虽然分离编码策略需要多次处理输入数据，可能会延长模型的训练和推理时间，但它允许对查询的不同方面进行更精细的处理和理解。这为模型提供了处理各种查询任务的灵活性，从而提高整体性能。
5.2 解码策略
解码是 nl2sql 翻译的关键步骤，将编码器生成的表示转换为 sql 。有效的解码策略确保生成的 sql 不仅在语法上正确，而且在语义上与 nl 查询一致，并优化 sql 执行效率。图 5 介绍了几种关键解码策略，如下所述。

解码策略的概览。
5.2.1 贪婪搜索解码策略
贪婪搜索解码策略简单快速，在每一步解码时选择概率最高的标记。此策略通过连续选择局部最优解来构建最终输出序列，如图 5 (a)所示。
由于GPT模型（例如GPT-4）默认采用贪婪搜索解码，许多使用GPT的 nl2sql 解决方案属于此类。DTS-SQL (Pourreza 和 Rafiei 2024b) 基于DeepSeek LLM (Bi 等人 2024) 也采用了相同的方法。早期模型如SQLNet (Xu 和 al. 2017) 和Seq2SQL (Zhong 和 al. 2017) 也依赖贪婪搜索生成 sql 。
贪婪搜索因其快速解码速度和简单性而受欢迎。然而，它只考虑局部最优解，可能忽略长期依赖和全局优化。这会导致次优的 sql 查询，特别是在复杂查询中，早期错误可能在整个解码过程中传播和累积。
5.2.2 波束搜索解码策略

与贪婪搜索相比，波束搜索保留了多个候选序列，这增加了内存和计算需求，减慢了解码速度。然而，通过在每一步考虑多个候选，波束搜索探索了更广泛的搜索空间，从而更有可能生成准确和复杂的 sql 查询。
5.2.3 约束感知增量解码策略
PICARD（解析增量约束自回归解码） (Scholak 和 al. 2021) 引入的约束感知增量解码策略旨在通过在解码过程中加入约束来确保生成语法正确的 sql 查询，如图 5 (c)所示。
简而言之，使用此策略的 nl2sql 模型通过增量方式生成 sql 查询，在每一步应用 sql 语法规则。当模型预测下一个标记时，它还检查部分查询的语法正确性，以确保每个标记符合所需的语法，从而减少生成无效或不完整的 sql 查询的可能性，提高翻译的整体准确性和可靠性。PICARD (Scholak 和 al. 2021) 确保每个添加的标记都符合正确的 sql 语法，显著减少了错误和不完整的查询。许多模型 (C. Gao 等人 2022; Qi 等人 2022; Scholak 和 al. 2021; Hu 等人 2023; Zeng, Parthasarathi, 和 Hakkani-Tur 2023; J. Li 和 al. 2023) 通过使用PICARD的解码策略展示了更好的性能。
虽然这种策略由于增量解码和约束应用需要更多的计算资源和处理时间，但它有效地确保了语法正确性，使其适用于生成结构复杂且最小化错误的 sql 查询。
5.2.4 其他解码策略
除了三种常见的解码策略外，一些模型引入了专门的方法以提高解码准确性。例如，BRIDGE (X. V. Lin 和 al. 2020) 引入了模式一致性引导解码，确保生成的 sql 查询与数据库模式一致。它通过在解码过程中持续验证查询与模式的匹配情况，并根据结果调整解码路径来实现这一点。
5.3 任务特定提示策略
在LLMs时代，提示工程已成为利用LLMs能力跨多种任务的强大方法 (X. Liu 等人 2023) 。 nl2sql 的任务特定提示旨在指导LLMs优化 nl2sql 翻译，增强将复杂的 nl 查询准确转换为精确的 sql 查询的能力。大致来说，有两种主要的任务特定提示策略： 1) 链式思考提示 , 和 2) 分解策略 。
5.3.1 链式思考（CoT）提示
链式思考提示 (Wei 等人 2022) , 以其有效性著称，展示了LLMs的推理过程，提高了生成结果的准确性和可解释性。在 nl2sql 任务中，CoT增强了模型性能，并确保生成的 sql 语句更符合人类期望 (Tai 等人 2023) 。例如，CHESS (Talaei 等人 2024) 通过简化流程将 nl 转换为 sql 语句，该过程包括实体和上下文检索、模式选择、 sql 生成和修订。
此外，将CoT与其他技术相结合可以进一步提升 nl2sql 模型的性能。这些技术包括上下文学习 (H. Zhang 等人 2023, 2024) 、逻辑合成 (Qu 等人 2024) 、提示校准 (X. Dong 等人 2023; Xiang 等人 2023) 以及多代理系统 (Bing Wang 等人 2023) 。具体来说，上下文学习和逻辑合成通过嵌入更深的语言理解，使CoT更加精准地映射到 sql 结构 (H. Zhang 等人 2023, 2024) 。提示校准通过微调模型响应，使其更紧密地符合 nl 的细微差别，以实现准确的意图转换 (X. Dong 等人 2023; Xiang 等人 2023) 。此外，将多代理框架与CoT结合，促进了协作方法，其中专门的代理处理诸如模式链接和 sql 生成等任务，加快了推理速度并增强了适应性 (Bing Wang 等人 2023) 。
总体而言，这些技术创建了一个更稳健的 nl2sql 框架，提供了更高的精度和可靠性，将复杂的 nl 查询准确转换为 sql 语句。
5.3.2 分解策略
分解策略将 nl2sql 任务分解为顺序子任务，使每个子模块能够专注于特定的生成步骤，从而提高准确性、质量和可解释性。

总的来说，分解策略将 nl2sql 翻译任务分解为多个子任务，使每个子模块能够专注于增强其特定输出。然而，这种方法也增加了计算成本，使模型训练和部署更加复杂和资源密集。

中间表示的例子。
5.4 NL2SQL翻译的中间表示
由于 nl 查询的复杂性和歧义性，加上 sql 的语法约束， nl2sql 任务具有挑战性。为了简化这一过程，研究人员开发了 无语法 中间表示（IR），以桥接“自由形式”的 nl 问题和“受约束且正式”的 sql 。该IR提供了一种结构化但灵活的格式，捕捉 nl 查询中的基本组件和关系，而不必遵循严格的 sql 语法要求。图 6 显示了两种类型的IR策略，如下所述。
5.4.1 类SQL语法语言
如图 6 (a)所示，类SQL语法语言是一种简化的SQL结构。早期方法使用信息检索技术将原始问题和模式数据映射为此语法 (F. Li 和 al. 2014; F. Li 和 Jagadish 2014a) 。后续研究致力于整合或消除SQL查询中的部分子句或操作，以简化类SQL语法语言 (J.-O. Lee 和 Baik 1999; Yu 和 al. 2018) 。例如，EditSQL (R. Zhang 和 al. 2019) 添加了 WHERE 和 HAVING 条件。最近的研究集中在简化语法语言以提高解析效率 (Eyal 等人 2023) 。NatSQL（自然SQL） (Gan 和 al. 2021) , 一种广泛使用的类SQL语法语言，消除了不常见的 sql 操作符和关键字，通过最小化必要的模式项简化了模式链接。结合PLMs，NatSQL在各种基准测试中表现出色 (H. Li 等人 2023; Rai 等人 2023) 。此外，问题分解意义表示 (Wolfson 等人 2021; Wolfson 等人 2020) 将原始 nl 分解为原子问题，每个问题作为中间表示，转换为小的正式操作，如选择实体、检索属性或聚合数据。
类SQL语法语言在桥接用户查询和数据库方面显示出潜力。然而，先前的研究由于高复杂性和有限的数据库结构覆盖范围面临挑战 (Gan 和 al. 2021) 。随着数据库规模和领域特异性增加，保持类SQL语法语言的简洁性变得越来越困难。此外，某些语言需要手动构建和调整，增加了部署成本和复杂性。
5.4.2 类SQL草图结构
利用 sql 的结构特征，研究人员开发了类SQL草图，用于解析并映射多样化的 nl 查询到特定的草图空间，如图 6 (b)所示。这种方法减少了解析复杂性。
早期工作应用了固定的草图规则和神经网络，将 nl 映射到类SQL草图结构 (D. Lee 2019; Yu 和 al. 2018) 。例如，SyntaxSQLNet (Yu 和 al. 2018) 使用语法树和相应的解码器，将解码分为九个子模块，分别预测操作符、关键字和实体，然后再组合生成最终的 sql 。近年来，随着语言模型的发展，研究人员设计了更复杂的类SQL草图结构用于解析 (Gu 等人 2023a, 2023b; Fu 等人 2023; Qu 等人 2024) 。CatSQL (Fu 等人 2023) 构建了一个更通用的模板草图，其中插槽作为初始占位符。其基础模型专注于解析 nl 以填充这些占位符，从而降低计算成本。此外，最近的一些工作涵盖了类SQL语法语言和类SQL草图过渡方法。例如，RESDSQL (H. Li 等人 2023) 引入了排名增强编码和骨架感知解码框架。在解码阶段，其解码器首先生成 sql 骨架，然后将其转换为实际的 sql 查询。当与NatSQL结合时，RESDSQL进一步提高了 sql 查询生成的质量。
一般来说，类SQL草图结构可以更轻松地与其他策略结合，如分解策略或类SQL语法语言策略。此外，它可以更充分地利用现有LLMs的理解和完形填空能力，并减少对专业人员的依赖。
6 NL2SQL的后处理策略
在 nl2sql 模型生成 sql 之后，后处理可以精炼生成的 sql 以更好地满足用户期望。这一步涉及利用额外的信息或模型来增强 sql , 主要关注 sql 修正、确保输出一致性以及执行导向检查。
6.1 SQL修正策略
nl2sql 模型生成的 sql 可能包含语法错误或不必要的关键字，如 DESC , DISTINCT 和 Aggregate 函数。DIN-SQL (Pourreza 和 Rafiei 2024a) 引入了一个零样本设置下的自我修正模块，该模块仅接收有误的 sql 并尝试修正它。使用了两种提示：针对CodeX的一般提示，直接请求错误识别和修正；针对GPT-4的温和提示，寻求潜在问题但不假定错误。为了处理谓词预测中的错误，如错误的列或值，ZeroNL2SQL (Gu 等人 2023b) 采用多层次匹配方法。此方法逐步扩展跨列、表和数据库的匹配，允许匹配的值返回给LLMs以生成与数据库内容一致的 sql 查询。
虽然这些方法专注于修正语法错误，但它们通常忽略了语义错误，如错误的表联接、错位条件或不准确的聚合，这对于提高准确性至关重要。
6.2 输出一致性
为了增强输出一致性，引入了自洽性 (X. Wang 和 al. 2022) , 基于复杂推理任务可能有多条通向单一正确答案的有效路径这一想法。此方法采样各种推理路径并选择最一致的答案以提高输出质量。

然而，最近的研究 (Renze 和 Guven 2024) 表明，单个模型可能无法提供足够的多样性。为了解决这个问题，PET-SQL (Z. Li 和 al. 2024) 引入了跨一致性策略，其中多个LLMs在较低温度下生成 sql , 并根据执行结果进行投票。
虽然这些方法通过单个或多个LLMs在多次运行中提高了输出一致性，减少了模型随机性并增强了准确性，但它们显著增加了推理成本和时间。
6.3 执行导向策略
在 nl2sql 任务中， sql 查询的执行结果提供了关于 nl2sql 翻译准确性的关键反馈。例如，执行结果中的错误或 NULL 值可以指示 sql 查询的潜在问题。
为了反映人类编写复杂 sql 查询的行为，CHESS (Talaei 等人 2024) 为LLMs提供了数据库模式、问题、候选 sql 查询及其执行结果。CHESS从草稿查询开始，并根据执行反馈进行细化，必要时调整语法错误。CodeS (H. Li 等人 2024) 则通过波束搜索生成完整的 sql 语句，产生四个 sql 候选，并选择第一个可执行的结果作为最终结果。
执行导向策略根据执行结果精炼 sql , 确保查询能正确检索数据。然而，这种方法会显著增加 sql 生成时间，尤其是在大型数据库中。
6.4 N-best重排序策略

尽管N-best重排序在PLM基方法中广泛用于精炼 sql 候选，但在LLM基方法中较少见，因为后者通常具有更强的推理能力。
7 NL2SQL基准测试
在本节中，我们将首先详细阐述不同类型的 nl2sql 数据集及其特征，如图 [fig:dataset_timeline] 所示（第 7.1 节）。然后，我们将对现有的 nl2sql 数据集进行深入分析（第 7.2 节）。
7.1 NL2SQL基准概览
随着 nl2sql 的发展，各种数据集应运而生以应对不断变化的挑战，如图 [fig:dataset_timeline] 所示。这些数据集从特定领域的简单查询到跨领域、多轮对话、多语言和领域特定场景，反映了 nl2sql 解决方案的进步和新挑战。
早期的 nl2sql 数据集专注于特定领域且包含相对简单的 sql 查询，例如ATIS (Dahl 等人 1994) 针对航班信息，GeoQuery (Zelle 和 Mooney 1996) 针对美国地理事实。最近，引入了更大规模的单域数据集 (P. Wang, Shi 和 Reddy 2020; Sen 等人 2020; Hazoom 等人 2021; Y. Zhang 等人 2023; C. Zhang 等人 2024; Kumar 等人 2024) , 特征是更复杂的数据库和针对特定场景的 sql 查询。这种转变反映了对评估 nl2sql 系统在特定领域内的性能和实用性的重视。
在早期单域数据集之后， nl2sql 领域转向跨域数据集，以测试系统在不同 sql 查询和数据库上的泛化能力。WikiSQL (Zhong 等人 2017) 是第一个跨域数据集，从维基百科的各个领域抽取表格。随后，Spider (Yu, Zhang, 等人 2018) 被引入，包含多个表的复杂关系数据库。最近，BIRD (J. Li 等人 2023) 进一步提升了复杂性，包含了Spider中不存在的SQL函数和操作，为 nl2sql 带来了更大的挑战。

在现实世界应用中， nl2sql 系统必须处理多样化的用户群体和数据库，强调稳健性。Spider-Syn (Gan 等人 2021) 通过在 nl 问题中使用同义词模拟用户对模式的不熟悉，而Dr.Spider (Chang 等人 2023) 对数据库、 nl 问题和 sql 查询应用了17种扰动，进行全面的稳健性评估。
现实世界的数据库通常包含大量数据，且单个用户问题可能有多个对应的 sql 查询，每个查询的执行效率各不相同。BIRD (J. Li 等人 2023) 引入了一个评估SQL执行效率的指标，称为有效率评分（VES），这将在第 8 节进一步讨论。
领域特定知识对于 nl2sql 系统在实际应用中的表现至关重要。KaggleDBQA (C.-H. Lee, Polozov, 和 Richardson 2021) 包含数据库文档，如列和表描述。类似地，Spider-DK (Gan, Chen, 和 Purver 2021) 扩展了Spider开发集，向 nl 问题添加五种类型的知识，测试系统理解和使用这些信息的能力。
在现实世界中的 nl2sql 任务中，模糊性经常出现，例如 nl 的语义模糊性和重叠的数据库模式，使得模糊性评估变得越来越重要。AmbiQT (Bhaskar 等人 2023) 是第一个旨在评估模糊覆盖的数据集，包含四种模糊类型。每个 nl 问题映射到两个有效的 sql 查询，反映具体的模糊性。
MIMICSQL (P. Wang, Shi, 和 Reddy 2020) 采用模板方法生成初始模板问题和相应的 sql 查询，尽管需要手动调整以使问题更加自然。ScienceBenchmark (Y. Zhang 等人 2023) 也使用模板进行初始 sql 生成，但利用GPT-3进行 sql -to- nl 翻译。
7.2 现有NL2SQL数据集的深入分析
为了分析和比较 nl2sql 数据集的复杂性，我们使用NL2SQL360系统进行统计评估，如表 [tab:datasets] 所示。我们测量了 冗余度 , 包括 nl 问题数量、 sql 查询数量及其比率。数据库复杂性涵盖了总数据库数量、总表数量、每库平均表数、每表平均列数以及每库平均记录数。 sql 查询复杂性衡量了每个 sql 查询中的平均表数、 SELECT 关键字、聚合函数、标量函数和数学计算的数量。对于没有公开开发/测试拆分的数据集，如CHASE (Guo 等人 2021) , 只报告公共拆分的统计信息。对于没有公开数据的数据集，如knowSQL (Dou 等人 2022) , 表 [tab:datasets] 中的值标记为“–”。
从冗余度的角度来看，我们观察到从早期数据集到最近数据集的趋势是数据集规模的增长。具体来说，MT-TEQL (Ma 和 Wang 2021) 因自动化转换 nl 问题而脱颖而出，生成了大量的变体，因此其 nl 问题数量最多，且 nl 问题与 sql 查询的比例最大。
就数据库复杂性而言，每个数据集中数据库和表的数量与其预期任务一致。单域数据集，如BookSQL (Kumar 等人 2024) , 通常包含较少的数据库，而旨在评估稳健性的数据集，如Dr.Spider (Chang 等人 2023) 和MT-TEQL (Ma 和 Wang 2021) , 则包含更多的数据库。
关于查询复杂性，数据集如FIBEN (Sen 等人 2020) 和SEDE (Hazoom 等人 2021) 包含多个表和聚合函数的 sql 查询，反映了真实世界金融领域和Stack Exchange站点的复杂性。最近的数据集还强调了标量函数和数学计算，增加了结构挑战。
尽管 nl2sql 社区提出了越来越多的数据集，但与现实世界场景相比，当前数据集在 sql 复杂性方面仍存在差距。当前数据集通常包含较少的 SELECT 关键字，表明缺乏嵌套查询和复杂的集合操作。此外，涉及标量函数和数学计算的挑战需要进一步关注。我们鼓励社区提出能够解决这些复杂性的数据集。
8 评估和错误分析
在本节中，我们介绍关键的 nl2sql 评估指标（第 8.1 节），回顾低成本和全面评估的工具包（第 8.2 节），并提供一个分类法来分析 sql 错误（第 8.3 节）。
8.1 评估指标

该指标通过测量真实 sql 查询和预测 sql 查询之间的不同 sql 组件（如 SELECT , WHERE 等）的确切匹配来评估 nl2sql 系统的详细性能。对于特定的 sql 组件 \(C\) , 计算公式可以形式化为：

该指标衡量有效 sql 查询的执行效率。它同时考虑了 sql 执行的准确性和效率，计算公式如下：

8.2 NL2SQL评估工具包
近年来的 nl2sql 解决方案在各种 nl2sql 基准测试中表现出色。然而，在实际应用中，不同领域的 nl 查询风格、数据库模式和 sql 查询特性的变化使得仅使用标准基准指标难以全面评估系统鲁棒性。为此，近期工具包 (Ma 和 Wang 2021; B. Li 等人 2024) 已被开发，以在实际场景中提供更全面的 nl2sql 系统评估。
MT-TEQL (Ma 和 Wang 2021) 是一个统一框架，用于评估 nl2sql 系统在处理现实世界中 nl 查询和数据库模式变化时的性能。它基于形态测试方法，自动实现 nl 查询和数据库模式的语义保留变换，无需人工努力自动生成它们的变体。它包括四种类型的 nl 查询变换（如 前缀插入 ) 和八种类型的数据库模式变换（如 表重排 )。

8.3 NL2SQL错误分类法
错误分析涉及检查模型错误以识别局限性并指导改进措施以提高性能。在本节中，我们首先回顾现有的 nl2sql 错误分类法。然后提出设计原则并介绍两级 nl2sql 错误分类法。
近年来的 nl2sql 研究 (Narechania 等人 2021; Ning 等人 2023; Talaei 等人 2024; Pourreza 和 Rafiei 2024a; Sun 等人 2023) 越来越多地纳入错误分析，提出了各种错误分类法。
Ning 等人 (Ning 等人 2023) 引入了一个详细的错误分类法，基于两个维度：（1） 语法维度 识别发生错误的具体 sql 部分，按关键词如 WHERE 和 JOIN 组织。（2） 语义维度 指自然语言描述的误读，如错误理解表名。SQL-PaLM (Sun 等人 2023) 将错误分为五类：（1） 模式链接 , 模型未能选择所需的表；（2） 误解数据库内容 , 模型无法准确解释表内的数据；（3） 误解证据知识 , 模型未能使用或忽略了人类标注的证据；（4） 推理 , 包括对问题理解不足，导致缺少必要的推理步骤以生成正确结果；（5） 语法相关错误 , 生成的 sql 包含语法错误。
当前的 nl2sql 错误分类法通常特定于特定数据集，限制了其通用适用性。为了应对这些问题，标准化且有效的分类法至关重要。我们提出以下原则以指导 nl2sql 错误分类法的开发：

• 全面性 : 它应涵盖 nl2sql 翻译过程中所有可能的错误类型。
• 互斥性 : 每个错误类型应清晰区分，以避免分类模糊。
• 可扩展性 : 分类法应适应性强，以包括随 nl2sql 发展的新兴错误类型。
• 实用性 : 它应实用，使用户能够在实际场景中诊断和解决错误。
  遵循这些原则，我们开发了一个两级 nl2sql 错误分析分类法：
• 错误定位 : 第一级确定发生错误的具体 sql 组件，如 SELECT 或 WHERE 子句。准确定位错误位置有助于针对性调整并提高修正效率。
• 错误原因 : 第二级关注错误的根本原因。例如， WHERE 子句值的错误可能表明模型在数据库内容检索或解释方面的局限性。

我们使用提出的分类法收集并分类了DIN-SQL (Pourreza 和 Rafiei 2024a) 在Spider (Yu, Zhang, 等人 2018) 上的错误。如图 [fig:overview] (d)所示，结果显示该分类法有效。然而，我们承认要实现全面的 nl2sql 错误分类法需要持续改进。我们邀请研究社区为该分类法的不断完善做出贡献。

9 实践指导

在本节中，我们提供开发 nl2sql 解决方案的实践指导，考虑关键因素和场景。

9.1 数据驱动的优化LLMs用于NL2SQL的路线图

在图 [fig:NL2SQL_Guidance] (a)中，我们概述了一条战略路线图，旨在根据数据隐私和数据量优化LLMs用于 nl2sql 任务。数据隐私影响开放源代码和封闭源代码LLMs的选择，而数据量影响训练和推理阶段的优化策略。

对于敏感数据，开放源代码LLMs是首选，因为封闭源代码模型通常使用外部API，可能会将数据暴露给外部服务器。开放源代码模型允许对本地训练和推理进行完全控制，提供更强的数据隐私保护。

对于开放源代码LLMs，可以在训练和推理阶段进行优化，而封闭源代码LLMs由于访问受限，只能在推理阶段进行优化。拥有大量的 nl2sql 数据时，预训练可以提高性能；对于包含数百至数千个（ nl , sql )对的数据集，微调是合适的。在低数据量场景下，推荐使用少量学习，而在无标签数据时，零样本方法是必不可少的。硬件资源和API成本也是选择最佳优化策略的重要考虑因素。

9.2 选择NL2SQL模块的决策流程

在图 [fig:NL2SQL_Guidance] (b)中，我们根据具体场景推荐选择 nl2sql 模块，突出显示利弊。下面，我们概述两个例子。

复杂数据库模式，包含众多表和列。 在这种情况下，建议使用模式链接策略。这减少了标记成本并最小化来自无关模式元素的噪声，提高了效率。然而，这也增加了额外的时间成本。

可以访问执行结果。 这里，建议使用执行导向策略，因为它通过过滤掉不可执行的 sql 查询来提高系统性能。缺点是查询执行所需的时间会增加，这对于大型数据库来说可能是显著的。

总之，虽然每个模块在特定的 nl2sql 场景中提供了独特的优势，但在系统设计中平衡这些优势与潜在的弊端是至关重要的。

10 开放问题

在政府开放数据平台等现实世界场景中，公民可能会询问需要查询多个数据库并汇总结果的问题。例如，公民可能会问：“过去五年内税单的平均处理时间是多少？”回答这个问题需要从不同数据库中检索相关表，如税务记录、处理日志和统计报告，然后生成多个 sql 查询。

开放 nl2sql 问题要求将 nl 查询转换为不仅访问单个固定数据库，还能识别大规模DBMS中相关数据库（或表）的 sql 查询。与传统 nl2sql 不同，用户指定单个目标数据库，开放 nl2sql 可能需要为单个用户问题生成多个访问不同数据库的 sql 查询。因此，开放 nl2sql 问题引入了独特的挑战，包括：（1） 数据库检索 : 准确识别并检索相关数据库；（2） 处理异构模式 : 整合不同结构和术语的数据，需要高级模式匹配和链接技术；（3） 答案汇总 : 从多个数据库的 sql 查询中推断最终答案，需要规划查询顺序、解决冲突并确保一致性；（4） 领域适应 : 跨领域泛化模型以应对术语和结构的差异；（5） 可扩展性和效率 : 管理大数据量的同时保持性能；（6） 评估和基准测试 : 开发能够准确反映开放 nl2sql 解决方案的真实复杂性的指标和数据集。

基于LLM的 nl2sql 方法展示了巨大潜力，但受到高标记消耗的限制，导致成本增加和推理时间变慢。相比之下，基于PLM的 nl2sql 方法在处理复杂 sql 查询和准确解释数据库模式方面表现出色。一种有前景的方法是结合两者的优势，开发模块化的 nl2sql 解决方案或使用多代理框架集成LLMs和PLMs用于 nl2sql 任务。这种混合策略可以管理复杂查询，同时节省标记并降低成本。然而，有效平衡LLM和PLM的使用以优化性能和资源效率仍然是一个开放挑战。

确保 nl2sql 解决方案的可信度对于生成准确可靠的 sql 至关重要，可以降低风险并减少手动干预的需求。主要话题包括以下几点：

解释NL2SQL解决方案。 理解 nl2sql 模型性能背后的原因增强了对其可靠性的信心。可解释AI技术，如代理模型 (Ali 等人 2023; H. Zhao 等人 2024) , 如代理模型 (Y. Chen 等人 2023) 和显著图 (Shrikumar, Greenside, 和 Kundaje 2017) , 可以帮助揭示模型内部的决策过程。然而，其在 nl2sql 上下文中的有效性，特别是结合LLM和PLM的情况下，仍然是一个开放问题。此外，使用LLMs的多代理框架 (J. Zhang 等人 2024) 可以通过将 nl2sql 任务分解为专门的子任务来提高可靠性，每个子任务由一个针对特定功能优化的代理处理。这种方法利用多个代理的优势来增强整体鲁棒性和准确性。然而，有效协调这些代理以和谐工作并优化其综合性能在 nl2sql 上下文中提出了重大挑战。

NL2SQL调试工具。 受代码编译器逐步调试功能的启发，一个可视化的NL2SQL调试工具可以通过检测生成的 sql 查询中的语义和语法错误来提高准确性和可靠性。这样的工具可以检测潜在错误，使用户能够检查 sql 生成过程，识别不匹配并理解生成 sql 背后的逻辑。然而，传统的编译器捕捉语法错误，而NL2SQL调试工具还需要解决语义错误，即确保生成的 sql 符合原始 nl 查询的意图。

交互式NL2SQL工具。 这些工具对于专业用户（如DBAs）创建跨越多个数据库的复杂 sql 查询非常重要，通常超过50行代码。关键功能是模型将复杂查询分解为可管理的子查询，减少认知负荷并使DBAs能够专注于每个部分然后再重新组合。支持自底向上和自顶向下的方法，这些工具允许DBAs根据自己的工作流偏好构建查询，并根据需要纠正和细化生成的 sql 。这种协作过程使复杂的 sql 输出与用户意图对齐，结合模型的能力和DBA的专业知识。

当前基于学习的 nl2sql 方法难以适应新的、未见过的领域，突显了跨数据领域泛化性的差距。此外，这些方法的性能严重依赖于训练数据的质量、覆盖率、多样性和数量。因此，一个有趣的研究问题是根据模型性能自动和增量地生成（ nl , sql )对。关键是通过利用来自 nl2sql 评估结果的反馈动态合成或增强训练数据。具体来说，通过结合评估指标和评估结果的见解，我们可以识别模型的具体弱点。利用这些信息，我们可以合成不断演化的训练数据，以涵盖更广泛的场景和领域。通过这种方式，我们可以生成更多样化和针对性的训练样本，从而逐步提升模型在不同场景和领域中的表现。例如，针对特定类型的错误，我们可以创建专门的训练数据来强化模型对该类问题的理解和处理能力。此外，我

们还可以利用用户反馈和实际应用场景中的查询日志，进一步丰富训练数据集，确保模型能够适应不断变化的需求和环境。

这种方法不仅有助于解决现有数据集覆盖不足的问题，还能有效应对新出现的任务和挑战，使 nl2sql 系统更加智能和灵活。动态合成的训练数据可以包括更复杂的查询结构、更多的领域特定术语以及更广泛的自然语言表达方式，从而全面提升模型的泛化能力和准确性。

总之，自动和增量地生成（ nl , sql )对是提高 nl2sql 系统性能和适应性的关键。通过持续优化训练数据，我们可以不断改进模型的表现，使其更好地服务于多样化的应用场景。

原论文：https://arxiv.org/pdf/2408.05109 NL2SQL Handbook : https://github.com/HKUSTDial/NL2SQL_Handbook