基于大型语言模型的自然语言到 SQL 转换研究综述：我们身处何处，又将前往何方？

摘要

论文：《A Survey of Text-to-SQL in the Era of LLMs:Where are we, and where are we going?》
将用户的自然语言查询（NL）转换为SQL查询（即Text-to-SQL，又称NL2SQL）可以显著降低访问关系数据库的障碍，并支持各种商业应用。Text-to-SQL的性能随着大型语言模型（LLM）的出现而大大提高。在本综述中，我们全面回顾了由LLM驱动的Text-to-SQL技术，涵盖了其整个生命周期的以下四个方面：

1. 模型：Text-to-SQL翻译技术，不仅解决了NL的歧义和欠规范问题，而且还正确地将NL与数据库模式和实例进行映射；
2. 数据：从训练数据的收集、由于训练数据稀缺而进行的数据合成，到Text-to-SQL基准；
3. 评估：从不同角度使用不同指标和粒度评估Text-to-SQL方法；
4. 错误分析：分析Text-to-SQL错误以找出根本原因并指导Text-to-SQL模型的发展。

一. 引言

自然语言到SQL（即Text-to-SQL），它将自然语言查询（NL）转换为SQL查询，是降低访问关系数据库障碍的关键技术。该技术支持各种应用，如商业智能和数据库的自然语言接口，使其成为数据科学民主化的关键一步。语言模型方面的最新进展已显著扩展了Text-to-SQL研究和应用的边界。同时，数据库供应商提供Text-to-SQL解决方案的趋势已从单纯的概念演变为必要的战略。因此，我们需要了解Text-to-SQL的基本原理、技术和挑战。

在本综述中，我们通过一个新的框架系统地回顾了最近的Text-to-SQL技术，如上图所示。

1.1 本综述的主要内容

• 基于语言模型的Text-to-SQL：我们首先从语言模型的角度回顾现有的Text-to-SQL解决方案，将它们分为四个主要类别（见图1(a)）。然后我们重点关注预训练语言模型（PLM）和大型语言模型（LLM）在Text-to-SQL方面的最新进展。

• 基准和训练数据合成：毫无疑问，基于PLM和LLM的Text-to-SQL模型的性能高度依赖于训练数据的数量和质量。因此，我们首先总结现有基准的特征，并详细分析其统计信息（如数据库复杂性）。然后我们讨论收集和合成高质量训练数据的方法，强调这是一个研究机会（见图1(b)）。

• 评估：全面评估Text-to-SQL模型对于优化和选择适用于不同使用场景的模型至关重要。我们将讨论Text-to-SQL任务的多角度评估和基于场景的评估（见图1©）。例如，我们可以通过基于SQL特征、NL变体、数据库领域等过滤基准来评估特定上下文中的Text-to-SQL模型。

• Text-to-SQL错误分析：错误分析在Text-to-SQL研究中对于识别局限性和提高模型鲁棒性至关重要。我们回顾现有的错误分类法，分析其局限性，并提出设计Text-to-SQL输出错误综合分类法的原则。使用这些原则，我们创建了一个两级错误分类法，并利用它来总结和分析Text-to-SQL输出错误（见图1(d)）。

除了上述内容，我们还将为开发Text-to-SQL解决方案提供实用指导，包括优化LLM用于Text-to-SQL任务的路线图和为各种Text-to-SQL场景选择Text-to-SQL模块的决策流程。最后，我们将讨论该领域的关键开放问题，如开放Text-to-SQL任务、使用LLM的成本效益Text-to-SQL以及可信赖的Text-to-SQL解决方案。

1.2 与现有综述的区别

我们的综述在五个方面与现有的Text-to-SQL综述和教程有所区别：

1. 全生命周期视角：我们系统地回顾了Text-to-SQL问题的整个生命周期，如图1所示。这个生命周期包括由语言模型驱动的各种Text-to-SQL翻译方法（图1(a)）、训练数据收集和合成方法（图1(b)）、多角度和基于场景的评估（图1©）以及Text-to-SQL错误分析技术（图1(d)）。

2. 详细的挑战分析：我们提供了Text-to-SQL中固有挑战的更详细和全面的总结。此外，我们分析了在为现实世界场景开发鲁棒Text-to-SQL解决方案时的技术挑战，这些在其他综述中经常被忽视。

3. LLM方法重点：我们特别关注基于LLM的Text-to-SQL方法的最新进展，总结关键模块并比较此范围内的不同策略。我们是第一个提供方法模块化总结并为每个关键模块（如数据库内容检索）提供详细分析的综述。

4. 多角度评估：我们强调以多角度方式评估Text-to-SQL方法的重要性，分析Text-to-SQL错误模式，并提供两级错误分类法。

5. 实践指导：我们为从业者提供了优化LLM到Text-to-SQL的路线图和为各种场景选择合适Text-to-SQL模块的决策流程。

1.2 贡献

我们做出以下贡献：

• 基于语言模型的Text-to-SQL：我们从生命周期角度全面回顾现有的Text-to-SQL技术（图1）。我们介绍Text-to-SQL任务定义，讨论挑战（图2），提供基于语言模型的Text-to-SQL解决方案分类法（图3），并总结语言模型驱动的Text-to-SQL解决方案的关键模块（图5和表I）。接下来，我们详细阐述语言模型驱动的Text-to-SQL方法的每个模块，包括预处理策略（第IV节）、Text-to-SQL翻译方法（第V节）和后处理技术（第VI节）。

• 基准和训练数据合成：我们根据现有Text-to-SQL基准的特征总结它们（图10）。我们深入分析每个基准并讨论其优缺点（表II）。（第VII节）

• 评估和错误分析：我们强调评估在开发实用Text-to-SQL解决方案中的重要性。我们回顾广泛使用的评估指标和评估Text-to-SQL解决方案的工具包。我们提供分类法来总结Text-to-SQL方法产生的典型错误。（第VIII节）

• 开发Text-to-SQL解决方案的实践指导：我们提供优化现有LLM用于Text-to-SQL任务的路线图（图11(a)）。此外，我们设计了一个决策流程来指导为不同场景选择适当的模块（图11(b)）。

• Text-to-SQL中的开放问题：我们分析基于LLM方法的局限性并讨论新的研究机会，包括开放世界Text-to-SQL问题和成本效益解决方案（第X节）。

• Text-to-SQL手册：我们维护一个在线手册（https://github.com/HKUSTDial/NL2SQL_Handbook）来帮助读者跟上Text-to-SQL的进展。

二. TEXT-TO-SQL问题和背景

2.1. 问题形式化

定义1（自然语言到SQL（Text-to-SQL））：自然语言到SQL（Text-to-SQL），也称为NL2SQL，是将自然语言查询（NL）转换为可在关系数据库（DB）上执行的相应SQL查询（SQL）的任务。具体来说，给定一个NL和一个DB，Text-to-SQL的目标是生成一个准确反映用户意图的SQL，并在数据库上执行时返回适当的结果。

讨论：在某些情况下，由于NL的歧义或欠规范，或数据库模式中的歧义，NL对应的SQL查询可能有多个。此外，即使NL、数据库模式和数据库内容都清晰具体，仍可能存在多个等价的SQL查询可以满足给定的NL问题。

2.2. Text-to-SQL人类工作流程

当专业用户（如数据库管理员DBA）执行Text-to-SQL任务时，他们首先解释NL问题，检查数据库模式和内容，然后基于他们的SQL专业知识构建相应的SQL。下面，我们详细概述这个过程，如图2(a)所示。

步骤1：理解自然语言查询：给定NL查询"找到在2023年劳动节恰好借阅了3种不同类型书籍的所有客户姓名"，DBA的首要任务是掌握用户意图并识别关键组件。关键要素包括：1）实体或属性：“姓名”、“客户”、“书籍"和"类型”；2）时间上下文：“2023年劳动节”；3）特定条件：“恰好3种不同类型”。然后，DBA可能会进一步理解NL查询的整体目的。在这种情况下，DBA应该基于特定日期的特定借阅行为检索客户姓名列表。

步骤2：找到相关表、列和单元格值：接下来，DBA检查数据库模式和内容，以识别构建SQL的相关表、列和单元格值。例如，DBA可能基于对NL的理解确定"Customer"和"Book"表是相关的（见图2(a)-①）。然后DBA决定应该提及哪些列。例如，关键词"类型"可以指"LiteraryGenre"或"SubjectGenre"（见图2(a)-②）。此外，DBA应该基于上下文解释"2023年劳动节"。在美国，“2023年劳动节"指"2023年9月4日”，而在中国，它指"2023年5月1日"。这种判断依赖于领域知识或可用的附加信息（见图2(a)-⑤）。

注意步骤2与最近由语言模型驱动的Text-to-SQL解决方案中的模式链接、数据库内容检索和附加信息获取概念一致（更多详情请参考图5）。

步骤3：基于NL和DB理解编写SQL：最后，DBA基于步骤1和步骤2中获得的见解编写相应的SQL。这个过程被称为"Text-to-SQL翻译"，严重依赖于DBA的SQL专业知识。然而，由于NL的歧义或数据库的复杂性，这个过程可能非常具有挑战性。例如，如图2(a)所示，尽管理解了需要链接Customer和Book表，但必须熟悉使用自然连接或子查询的用法和规范。此外，可能存在多个可能的SQL查询，因为"类型"可以指"LiteraryGenre"或"SubjectGenre"。

要点：从上述步骤中，我们直观地识别出Text-to-SQL任务中的三个固有挑战：自然语言的不确定性、数据库的复杂性，以及从"自由形式"自然语言查询到"受约束和正式"SQL查询的翻译。

2.3. Text-to-SQL任务挑战

在本节中，我们将首先讨论Text-to-SQL任务的基本挑战。然后我们将分析技术挑战，即在现实世界场景中开发强大Text-to-SQL解决方案时面临的挑战。

1：不确定的自然语言查询：自然语言查询由于歧义和欠规范经常包含不确定性。在Text-to-SQL任务中，与NL相关的挑战可以总结如下：

• 词汇歧义：当单个词有多个含义时发生。例如，单词"bat"可以指动物、棒球棒或挥击动作。
• 句法歧义：当句子可以用多种方式解析时发生。例如，在句子"Mary saw the man with the telescope"中，短语"with the telescope"可以意味着Mary使用望远镜看到了那个人，或者那个人有一个望远镜。
• 欠规范：当语言表达缺乏足够细节来清楚传达特定意图或含义时发生。例如，"2023年劳动节"在美国指9月4日，但在中国指5月1日。

2：复杂数据库和脏数据内容：Text-to-SQL任务需要深入理解数据库模式，包括表名、列、关系和数据属性。现代模式的复杂性和大数据量使这项任务特别具有挑战性。

• 表之间的复杂关系：数据库通常包含数百个具有复杂相互关系的表。Text-to-SQL解决方案在生成SQL时必须准确理解和利用这些关系。
• 属性和值的歧义：数据库中的歧义值和属性可能使Text-to-SQL系统识别正确上下文的能力复杂化。
• 领域特定的模式设计：不同领域通常有独特的数据库设计和模式模式。跨领域模式设计的变化使得开发一个适用于所有情况的Text-to-SQL模型变得困难。
• 大型和脏数据库值：有效处理大型数据库中的大量数据是关键的，因为将所有数据作为输入处理是不现实的。此外，脏数据，如缺失值、重复或不一致，如果不正确管理，可能导致错误的查询结果（例如，影响WHERE子句）。

3：Text-to-SQL翻译：Text-to-SQL任务不同于高级编程语言到低级机器语言的编译，因为它通常在输入NL、DB和输出SQL之间具有一对多映射。具体来说，Text-to-SQL任务面临几个独特的挑战：

• 自由形式NL vs. 受约束和正式SQL：自然语言是灵活的，而SQL查询必须遵守严格的语法。将NL翻译成SQL需要精确性以确保生成的查询是可执行的。
• 多个可能的SQL查询：单个NL查询可以对应多个满足查询意图的SQL查询，导致确定适当SQL翻译的歧义（见图2(a)中的示例）。
• 数据库模式依赖性：Text-to-SQL翻译高度依赖于底层数据库模式。如图2(a)和(b)所示，相同的NL可能基于模式变化产生不同的SQL查询。这要求Text-to-SQL模型弥合训练数据和现实世界模式差异之间的差距。

除了内在挑战之外，开发人员还必须克服几个技术障碍来构建可靠和高效的Text-to-SQL系统，如下所述。

4：开发Text-to-SQL解决方案的技术挑战：开发鲁棒的Text-to-SQL解决方案需要解决几个关键技术挑战，包括：

• 成本效益解决方案：部署Text-to-SQL模型，特别是使用大型语言模型的模型，需要大量资源，如硬件和/或API成本。在模型性能和成本效率之间实现最佳平衡仍然是一个关键挑战。
• 模型效率：模型大小和性能之间通常存在权衡，较大的模型通常产生更好的结果。在不损害准确性的情况下优化效率是必要的，特别是在需要低延迟的交互式查询场景中。
• SQL效率：Text-to-SQL模型生成的SQL必须既正确又针对性能进行优化。这包括优化连接操作、索引使用和查询结构。高效的查询减少数据库负载，提高系统响应性和吞吐量。
• 训练数据不足和噪声：高质量的Text-to-SQL训练数据很难获得。公共数据集通常有限，可能包含噪声注释，影响模型性能。注释需要数据库专业知识，增加成本，Text-to-SQL任务的复杂性经常导致错误。
• 可信度和可靠性：Text-to-SQL模型必须是可信和可靠的，在不同数据集和场景中始终产生准确结果。

2.4. 使用大型语言模型解决挑战

以下是翻译后的表格（保持原图形式 ）：

类型	级别	★	★★	★★★	★★★★	★★★★★
自然语言（NL）挑战		词元级识别	同义词识别	语义理解	领域知识查询识别	多轮对话
数据库（DB）挑战		单表查询	简单多表查询	复杂模式的多表查询	海量表与数值	真实世界数据库
文本转SQL挑战		单表SQL	多表SQL	高级SQL特性支持	适应模式变更	高效SQL生成

难度级别：我们将Text-to-SQL的难度分为五个级别，每个级别解决特定的障碍，如图3(a)所示。前三个级别涵盖已经或正在解决的挑战，突出了Text-to-SQL能力的逐步进展。第四个级别包括当前基于LLM解决方案关注的挑战，而第五个级别代表未来挑战，显示了我们对未来五年Text-to-SQL进展的愿景。

Text-to-SQL解决方案的演变：Text-to-SQL解决方案的发展，如图3(b)所示，经历了四个不同阶段：基于规则的阶段、基于神经网络的阶段、基于PLM的阶段和基于LLM的阶段。在每个阶段，我们分析目标用户的转变，即从专家到更广泛的用户群体，以及各种Text-to-SQL挑战被解决的程度。

1) 基于规则的阶段：在早期阶段，统计语言模型（如语义解析器）被用来解释NL查询并使用预定义规则将其转换为SQL查询。然而，基于规则的Text-to-SQL方法在适应性、可扩展性和泛化方面面临挑战。在这个阶段，自然语言理解仅限于词汇级别，研究主要集中在单表SQL查询上（见图3(b)-①）。

2) 基于神经网络的阶段：为了缓解基于规则方法的局限性，研究人员探索了用于Text-to-SQL任务的神经网络。这导致了基于序列到序列架构和图神经网络的模型的发展，增强了同义词处理和意图理解。因此，研究从单表场景推进到更复杂的多表场景（见图3(b)-②）。然而，这些方法的泛化能力仍然受到模型大小和充足训练数据可用性的限制。

3) 基于PLM的阶段：2018年引入BERT和T5等PLM导致基于PLM的Text-to-SQL方法取得重大进展，在各种基准上实现了竞争性能（见图3(b)-③）。在这个阶段，在大型语料库上训练的基于PLM的Text-to-SQL模型大大增强了自然语言理解，解决了Spider数据集中约80%的案例。然而，在Spider的超难案例上准确率下降到约50%。此外，这些模型在处理复杂模式方面仍面临挑战。

备注：PLM vs. LLM：图4显示了LLM和PLM之间的关键区别。LLM是PLM的子集，以其先进的语言理解和涌现能力而区别。涌现能力允许LLM直接使用提示执行Text-to-SQL任务。相比之下，PLM通常需要额外的预训练或微调才能获得可接受的Text-to-SQL性能。

4) 基于LLM的阶段：LLM展示了超越传统PLM在NLP任务中的独特涌现能力，标志着Text-to-SQL解决方案的新范式。这些基于LLM的Text-to-SQL方法已成为当前Text-to-SQL领域最具代表性的解决方案。当前研究专注于优化提示设计和微调LLM。例如，DAIL-SQL利用GPT-4和有效的提示工程技术，在Spider数据集上取得了强劲结果。同时，CodeS通过在大型Text-to-SQL相关语料库上预训练StarCoder，构建了专门用于Text-to-SQL任务的LLM，在BIRD等基准上显示了稳定的性能。在这个阶段，LLM的涌现能力显著改善了自然语言理解，将任务重点转向数据库特定挑战。像BIRD和BULL这样的新基准强调处理大量表和领域特定解决方案（见图3(b)-④）。

LLM时代的Text-to-SQL解决方案：广义上说，有两种主要方法来利用LLM的能力进行Text-to-SQL：1）上下文学习，2）为Text-to-SQL专门预训练/微调LLM。

Text-to-SQL的上下文学习：对于上下文学习方法，目标是优化提示函数P来指导LLM，可以表述如下：

$$F_{LLM}(P|NL,DB,K)\to SQL$$

其中K表示与NL或DB相关的附加信息或领域特定知识。P是一个提示函数，将输入(NL, DB, K)转换为适合LLM的文本提示。设计良好的P可以有效指导LLM更准确地执行Text-to-SQL任务。

为Text-to-SQL采用上下文学习策略将LLM视为现成工具，而不修改其参数。然而，如果用户有足够的训练数据或硬件资源，校准LLM的参数可以增强性能和准确性，使模型更紧密地适应特定的Text-to-SQL任务。

为Text-to-SQL预训练和微调LLM：完全优化LLM参数用于Text-to-SQL涉及两个关键阶段，预训练和微调，表述如下：

$$LL{M}^{\ast }=F_{fine-tune}(F_{pre-train}(LLM,D_p),D_f)$$

在预训练期间，LLM在大规模和多样化的数据集$D_p$上训练，包括广泛的语言模式和领域通用知识，使模型能够发展强大的理解能力。

在随后的微调阶段，预训练模型在更专业的数据集$D_f$上进一步调整，该数据集与Text-to-SQL任务密切相关。这种有针对性的训练完善了模型的能力，使其能够更有效地基于NL查询解释和生成SQL。

三. 语言模型驱动的TEXT-TO-SQL概述

虽然Text-to-SQL最初被设计为端到端任务，但最近的进展，特别是在LLM时代，已经转向模块化设计。如图5所示，现代基于PLM和LLM的解决方案通常将任务分解为三个阶段：预处理、翻译和后处理。每个阶段包含专门的模块，如模式链接、中间表示和执行引导校正。这种设计反映了Text-to-SQL日益增长的复杂性，并与多智能体或多模块协作的上升趋势一致。表I进一步比较了最近解决方案中的关键设计选择。

3.1 预处理方法

预处理增强输入并在改善Text-to-SQL解析中发挥重要作用。

• 模式链接：此模块从Text-to-SQL中识别最相关的表和列。
• 数据库内容检索：此关键模块访问制定SQL所需的适当数据库内容或单元格值。
• 附加信息获取：此关键模块通过整合领域特定知识来丰富上下文背景。

翻译方法

这是Text-to-SQL解决方案的核心，负责将输入NL查询转换为SQL。

• 编码策略：此关键模块将输入NL和数据库模式转换为内部表示，捕获输入数据的语义和结构信息（第V-A节）。
• 解码策略：此关键模块将内部表示转换为SQL查询（第V-B节）。
• 任务特定提示策略：此模块为Text-to-SQL模型提供定制指导，优化Text-to-SQL翻译工作流程（第V-C节）。
• 中间表示：此模块作为NL和SQL翻译之间的桥梁，提供结构化方法来抽象、对齐和优化NL理解，简化复杂推理，并指导准确SQL查询的生成（第V-D节）。

3.2 后处理方法

后处理是完善生成的SQL查询以获得更好准确性的关键步骤。

• SQL校正策略：旨在识别和纠正生成SQL中的语法错误（第VI-A节）。
• 输出一致性：此模块通过采样多个推理结果并选择最一致的结果来确保SQL的一致性（第VI-B节）。
• 执行引导策略：使用SQL的执行结果来指导后续改进（第VI-C节）。
• N-best排序器策略：旨在重新排序Text-to-SQL模型生成的top-k结果以增强查询准确性（第VI-D节）。

3.3 LLM时代Text-to-SQL的多智能体协作

基于模块化设计原则，最近的研究进一步引入了多智能体架构来处理Text-to-SQL任务。与传统的单体系统相比，多智能体框架为不同的智能体分配专门的责任，每个智能体专门处理特定的子任务。这种设计促进了增强的分工和组件之间更有效的协调。例如，MAC-SQL采用三智能体架构，分别有用于模式链接、查询分解和生成以及执行引导改进的智能体。类似地，CHASE-SQL采用分而治之的方法，在预处理期间选择相关数据库内容，通过多个思维链路径生成SQL查询，并通过自我校正和排序迭代改进输出。进一步推进边界，Alpha-SQL提出了一个以规划为中心的自主智能体框架，结合LLM和蒙特卡洛树搜索（MCTS）。该智能体基于上下文推理和基于执行的反馈动态选择和激活适当的模块，如模式链接和SQL生成。Alpha-SQL的策略驱动探索和自适应控制提供了强大的泛化能力，避免了基于管道方法的刚性。

四. TEXT-TO-SQL的预处理策略

预处理步骤在Text-to-SQL翻译过程中至关重要，因为它识别相关表和列（即模式链接）并检索必要的数据库内容或单元格值（即数据库内容检索）以支持SQL查询生成。此外，它通过整合领域特定知识（即附加信息获取）来丰富上下文，这可以改善对查询上下文的理解并纠正错误以防止其传播。

4.1. 模式链接

模式链接旨在识别与给定NL查询相关的表和列，确保在有限输入内准确映射和处理关键信息。这一步骤对于提高Text-to-SQL任务的性能至关重要。在LLM时代，由于LLM的输入长度限制，模式链接变得更加关键。

我们根据现有模式链接策略的特征将其分为三组：1）基于字符串匹配的模式链接，2）基于神经网络的模式链接，3）基于上下文学习的模式链接。

1) 基于字符串匹配的模式链接：早期研究主要关注用于模式链接的字符串匹配技术。这些方法使用NL查询和数据库模式之间的相似性度量来识别相关映射。IRNet采用精确匹配，当候选项相同或一个是另一个的子字符串时识别链接。虽然对简单情况有效，但由于共享词汇可能产生误报。为了处理拼写变化，ValueNet通过Damerau-Levenshtein距离应用近似匹配。

然而，这些方法在处理同义词方面存在困难，不够鲁棒以管理词汇变化，限制了它们在复杂Text-to-SQL任务中的有效性。

2) 基于神经网络的模式链接：为了缓解上述限制，研究人员采用深度神经网络来将数据库模式与自然语言查询对齐。这些方法可以更好地解析NL查询和数据库模式之间的复杂语义关系。DAE将模式链接框架化为序列标记问题，使用两阶段匿名化模型来捕获模式和NL之间的语义关系。SLSQL在Spider数据集中注释模式链接信息，实现系统的、数据驱动的研究。RESDSQL引入了用于模式链接的排序增强编码框架，使用交叉编码器基于分类概率优先考虑表和列。FinSQL使用并行交叉编码器检索相关模式元素，显著减少链接时间。

然而，基于神经网络的方法通常难以在具有不同模式或领域的数据库之间泛化，特别是当训练数据稀缺时。

3) 模式链接的上下文学习：随着GPT-4等LLM的进步，研究正在探索如何利用它们强大的推理能力进行模式链接，即直接从NL查询中识别和链接相关的数据库模式组件。一个关键技术是上下文学习（ICL）技术，它利用LLM理解数据模式内复杂语言模式和关系的能力，实现更动态和灵活的模式链接过程。

C3-SQL使用GPT-3.5的零样本提示，使用自一致性进行表和列链接。对于表链接，表按相关性排序并列出；对于列链接，列在相关表内排序并输出为字典，优先考虑与问题术语或外键的匹配。MAC-SQL提出了用于Text-to-SQL的多智能体协作框架，其中选择器智能体处理模式链接，仅在数据库模式提示超过指定长度时激活。CHESS利用GPT-4从NL和证据（来自BIRD的附加信息）中提取关键词，实施具有不同提示的三阶段模式修剪协议。

为模式链接采用ICL显示了有前景的性能。然而，LLM在可以处理的上下文量方面有固有限制，意味着具有许多表和列的复杂模式可能超过此限制。

4.2. 数据库内容检索

数据库内容检索专注于有效提取特定SQL子句（如WHERE）的单元格值。我们根据现有数据库内容检索策略的特征将其分为三组：1）基于字符串匹配的方法，2）基于神经网络的方法，3）数据库内容检索的索引策略。

1) 基于字符串匹配的方法：基于字符串匹配的方法通过字符串匹配识别和比较与NL查询相关的单元格值。IRNet使用n-gram，将引号之间的文本视为单元格值。BRIDGE通过锚文本匹配技术推进这一点，自动从NL中提取单元格值。使用启发式方法，它计算最大序列匹配来定义匹配边界，排除不相关的子字符串并调整准确性阈值。

然而，虽然字符串匹配方法有效，但它们在同义词方面存在困难，在处理大型数据库时可能在计算上昂贵。

2) 基于神经网络的方法：这些方法旨在通过非线性变换层捕获复杂的数据和语义特征，帮助解决同义词问题。TABERT使用称为数据库内容快照的方法为NL查询编码相关数据库内容，采用注意力机制来管理不同行中单元格值表示的信息。另一种方法利用图关系来表示数据库内容。IRNet使用知识图ConceptNet来查找和链接相关单元格值，基于精确或部分匹配分配类型。RAT-SQL通过建模单元格值和NL查询之间的关系进一步增强结构推理，识别查询值是列候选单元格值一部分的列-值关系。

虽然这些方法捕获语义特征，但它们可能在模糊或上下文相关的NL方面存在困难，导致不准确的单元格值检索。此外，神经网络的训练需要大量计算资源。

3) 数据库内容检索的索引策略：有效检索相关单元格值对于Text-to-SQL系统的性能至关重要，特别是对于大型数据集。索引是通过实现对相关单元格值的更快访问来提高检索效率的关键方法。

CHESS使用局部敏感哈希进行近似最近邻搜索，索引唯一单元格值以快速找到与NL查询相关的顶部匹配。这种方法加速了比较编辑距离和语义嵌入的过程。CodeS采用粗到细的匹配策略。它使用BM25构建粗粒度搜索的索引，识别候选值，然后通过应用最长公共子字符串算法来评估与NL的相似性进行细化，从而确定最相关的单元格值。

虽然索引显著提高了检索效率，但构建索引耗时，数据库内容的频繁更改需要持续更新，增加了开销。

4.3. 附加信息获取

附加信息，如领域知识，在增强Text-to-SQL模型对NL查询、模式链接和整体Text-to-SQL翻译的理解方面发挥关键作用。这些信息可以为Text-to-SQL骨干模型或特定模块提供演示示例、领域知识、公式证据和格式信息，从而提高生成结果的质量。我们将现有策略分为以下两组：1）基于样本的方法，2）基于检索的方法。

1) 基于样本的方法：随着LLM和上下文学习技术的进步，研究人员经常将附加信息与演示示例一起纳入文本输入（即提示）中。DIN-SQL通过多阶段的少样本学习整合附加信息。这帮助DIN-SQL处理复杂模式链接、多表连接和嵌套查询等挑战。在实践中，现实世界的数据库通常包含丰富的跨领域知识，可以作为支持查询生成的外部证据。例如，BIRD包含对各种Text-to-SQL工作至关重要的领域知识。最近的工作还将模式元数据（如数据类型）编码为自然语言以增强上下文理解。

2) 基于检索的方法：从广泛的领域知识库中提取相关知识和少样本示例可能增加令牌使用，影响效率和计算成本。为了提高准确性和效率，一些研究人员采用基于相似性的检索方法。例如，PET-SQL构建问题框架和问题-SQL对的池，选择与目标查询最相似的k个示例，然后在提示中使用。

当数据库缺乏基于文本的附加信息时，研究人员设计方法来检索和将外部知识转换为自然语言。例如，REGROUP创建跨领域（如金融、交通）的公式知识库，并使用密集段落检索器计算相似性分数，通过擦除-然后-唤醒模型将相关实体与NL和模式整合。ReBoost使用两阶段解释-压缩模式链接策略，首先向LLM呈现通用模式，然后应用有针对性的提示来提高查询到实体映射的准确性。

基于检索的方法提高了获取附加信息的有效性，但增加了计算成本。此外，当前研究主要依赖于领域特定文本，对结构化知识的使用有限。因此，整合多样化的信息源可以进一步增强Text-to-SQL性能，特别是对于领域特定的数据库。

五. TEXT-TO-SQL翻译方法

在本节中，我们详细阐述使用语言模型的Text-to-SQL翻译方法。如图6所示，我们将详细介绍它们的编码、解码和任务特定提示策略。此外，我们将讨论中间表示如何有益于Text-to-SQL翻译过程。

5.1. 编码策略

在Text-to-SQL任务中，编码是指将NL和数据库模式转换为适合语言模型处理的结构化格式。这一步骤对于将非结构化数据转换为可用于SQL生成的形式至关重要，捕获NL的语义和模式的结构，以帮助模型将用户意图映射到适当的SQL。

如图7所示，主要编码策略包括：1）序列编码，2）基于图的编码，3）分离编码。

1) 序列编码策略：序列编码是Text-to-SQL模型中的一种策略，其中NL和数据库模式都被视为令牌序列。如图7(a)所示，模型使用标准基于Transformer的架构将整个输入作为线性令牌序列处理。像T5这样的模型被用于在工作中顺序编码NL和数据库模式。BRIDGE通过

将匹配的数据库单元格值（称为锚文本）插入到相应字段旁边，将两者表示为标记序列，从而改善NL和数据库模式之间的对齐。RESDSQL使用排序增强编码器对模式项目进行排序和过滤，优先考虑最相关的项目并减少模式链接复杂性。虽然基于LLM的Text-to-SQL系统通常不明确定义输入编码策略，但它们通常通过连接查询和模式组件隐式采用序列形式。这些模型利用自注意力来建模整个序列的依赖关系。

虽然这允许灵活的上下文化，但这种方法可能难以捕获复杂的关系结构，限制了它们在深度嵌套SQL查询上的性能。

2) 基于图的编码策略：Text-to-SQL模型中基于图的编码将NL和数据库模式表示为相互连接的图，利用数据库的关系结构和输入数据中的相互依赖关系，如图7(b)所示。与序列编码不同，这种方法保留了模式的拓扑结构，为每个元素提供更丰富的上下文，增强了模型生成准确SQL查询的能力。

RAT-SQL引入了关系感知自注意力机制，明确使用图结构中的关系信息来联合编码问题和模式，增强模型对结构信息的理解。S2SQL在编码阶段使用ELECTRA模型注入句法结构信息，增强语义理解。G3R使用LGESQL编码器和图注意力网络（GAT）来捕获多源异构信息。Graphix-T5添加图感知层，将结构信息直接纳入编码过程，显著改善了多个基准上的SQL查询生成。

然而，这种策略通常涉及更复杂的图构建和处理算法。它还倾向于依赖大规模训练数据来实现最佳性能，这限制了其在低资源场景中的适用性。

3) 分离编码策略：Text-to-SQL中的分离编码策略是指独立编码输入的不同部分（通常是NL和数据库模式），而不是将它们组合成单个序列。这种策略随着时间的推移发生了显著演变，可以大致分为传统和现代形式。

在传统的分离编码中，像SQLNet和Seq2SQL这样的早期模型由于格式不匹配而分别处理NL和数据库模式。然而，两个组件之间缺乏交互阻碍了有效的模式链接，导致性能有限，使这种方法在最近的研究中不太常见。如图7©所示，现代分离编码策略通过将Text-to-SQL任务分解为子任务并分别编码不同方面，专注于模块化表示学习。TKK采用任务分解和多任务学习策略，将复杂的Text-to-SQL任务分解为子任务并逐步整合知识。类似地，SC-Prompt将文本编码分为两个阶段：结构和内容，每个阶段分别编码。

虽然分离编码由于多个处理步骤可能增加计算开销，但它允许对查询的不同方面有更精细的理解。这种模块化为模型提供了更大的灵活性来处理各种查询任务，从而增强整体性能。

5.2. 解码策略

解码是Text-to-SQL翻译中的关键步骤，将编码器生成的表示转换为SQL。有效的解码策略确保生成的SQL不仅在语法上正确，而且在语义上与NL查询对齐，同时优化SQL执行效率。图8介绍了几种关键解码策略。

1) 基于贪婪搜索的解码策略：基于贪婪搜索的解码策略是一种简单高效的方法，在每个解码步骤选择概率最高的令牌。如图8(a)所示，它通过做出一系列局部最优选择来构建输出序列，而不考虑未来的可能性。

由于GPT模型（如GPT-4）默认使用基于贪婪搜索的解码，许多使用GPT的Text-to-SQL解决方案都属于这一类别。基于DeepSeek的DTS-SQL使用相同的方法。像SQLNet和Seq2SQL这样的早期模型也依赖贪婪搜索进行SQL生成。

尽管效率很高，贪婪搜索有显著的局限性。通过只关注即时令牌概率，它无法考虑长期依赖关系或全局序列连贯性。因此，解码过程早期犯的错误可能传播并导致次优或不正确的SQL查询，特别是对于复杂或多步骤问题。

2) 基于束搜索的解码策略：束搜索是一种广泛使用的解码策略，与贪婪解码相比探索更广泛的搜索空间，通常导致更高质量的结果。它不是在每一步只选择顶部令牌，而是保留固定数量的顶级部分序列（称为束），并通过考虑top-k最可能的下一个令牌来扩展每个序列，如图8(b)所示。

鉴于其优势，几个Text-to-SQL模型采用束搜索。RAT-SQL结合关系感知图结构编码和束搜索来生成多个SQL候选，基于图结构信息重新排序它们。与RAT-SQL不同，EditSQL使用束搜索和对话历史来生成和改进候选SQL查询。SmBoP采用半自回归自底向上解码方法，通过并行化子树构建和评分来提高效率，具有对数时间复杂度。ZeroNL2SQL在SQL草图生成阶段保留top-k假设，然后为查询和谓词校准进行细化。

与贪婪解码相比，束搜索通过在每一步考虑多个假设，提高了生成语法和语义有效SQL查询的能力，特别是在复杂场景中。然而，这种好处是以增加计算复杂性和内存使用为代价的，可能减慢解码过程。

3) 约束感知增量解码策略：约束感知增量解码策略旨在通过在解码过程中应用显式约束来确保SQL查询的结构和语法有效性。如图8©所示，这些策略在每一步强制执行SQL语法约束的同时增量生成SQL。

一个代表性实现是PICARD（用于约束自回归解码的增量解析），它将SQL语法约束集成到解码循环中。它在每一步验证部分生成查询的语法有效性，确保每个令牌都遵守SQL语法。这显著减少了无效或不完整查询的生成。许多模型都采用了这种范式来提高性能。

除了语法级约束外，一些模型在解码期间还纳入模式级约束。BRIDGE引入模式一致性引导解码，通过验证生成的SQL查询与底层数据库模式之间的一致性并相应调整解码路径来强制对齐。

虽然这种策略由于每令牌约束评估引入了额外的计算开销，但它提供了语法正确性的强保证，对于生成结构复杂的SQL查询特别有效。

5.3. 任务特定提示策略

在LLM时代，提示工程已成为利用LLM在各种任务中能力的强大方法。在Text-to-SQL中，任务特定提示被精心设计来指导LLM优化Text-to-SQL翻译，提高将复杂NL查询翻译成精确SQL查询的准确性。广义上说，有两种主要类型的任务特定提示策略：1）思维链提示，2）分解策略。

1) 思维链（CoT）提示：以其有效性而闻名的CoT提示展示了LLM的推理过程，提高了生成结果的准确性和可解释性。在Text-to-SQL中，CoT增强了模型性能，确保生成的SQL语句更符合人类期望。

CHESS通过利用LLM和CoT的简化管道将NL转换为SQL语句。这个过程包括实体和上下文检索、模式选择、SQL生成和修订。此外，CoT与其他技术的集成可以增强Text-to-SQL模型的性能。这些技术包括上下文学习、逻辑合成、提示校准和多智能体系统。具体来说，上下文学习和逻辑合成通过嵌入更深层的语言理解来丰富CoT，实现对SQL构造的精确语义映射。提示校准微调模型响应，使其与NL细微差别紧密对齐，以实现准确的意图翻译。此外，将多智能体框架与CoT集成促进了协作方法，专门的智能体处理模式链接和SQL生成等任务，这加速了推理并增强了适应性。

总的来说，这些技术创建了一个更强大的Text-to-SQL框架，在将复杂NL查询翻译成准确SQL语句方面提供了更好的精度和可靠性。然而，CoT提示可能引入更长的推理链和延迟，其有效性可能对提示设计和任务复杂性敏感。

2) 分解策略：分解策略将Text-to-SQL任务分为顺序子任务，允许每个子模块专注于特定的生成步骤，从而增强准确性、质量和可解释性。

不同方法在子任务分解粒度上有所不同。TKK通过将Text-to-SQL解析分解为将NL映射到SELECT、FROM和WHERE子句等子任务来应用更细粒度的分解。这种方法帮助模型专注于每个子句，增强对问题、模式和SQL对齐的理解。G3R和DEA-SQL使用类似策略。此外，分解还减少了模型复杂性。例如，MAC-SQL引入分解器智能体将用户查询分解为子问题，使每个部分的SQL生成更易管理。

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

5.4. Text-to-SQL翻译的中间表示

Text-to-SQL具有挑战性，因为NL查询的复杂性和歧义性，加上SQL的语法约束性质。为了简化这个过程，研究人员开发了无语法的中间表示（IR）来桥接"自由形式"NL问题和"受约束和正式"SQL。这种IR提供了结构化但灵活的格式，捕获NL查询中的基本组件和关系，而没有SQL的严格语法要求。图9显示了两种类型的IR策略，讨论如下。

1) 类SQL语法语言：如图9(a)所示，类SQL语法语言是一种简化的类SQL结构。早期方法使用信息检索技术将原始问题和模式数据映射到这种语法中。后续研究工作专注于整合或消除SQL查询中的部分子句或操作，以简化类SQL语法语言。SyntaxSQLNet通过删除FROM和JOIN子句的部分来简化语法语言。SemQL删除整个FROM、JOIN、ON和GROUP BY子句，并进一步将WHERE和HAVING条件合并为统一的过滤表示。最近的研究专注于简化语法语言以提高解析效率。NatSQL是一种广泛使用的类SQL语法语言，消除了不常见的SQL操作符和关键词，通过最小化必要的模式项目来简化模式链接。与PLM结合，NatSQL在各种基准上取得了强劲结果。

类SQL语法语言在桥接用户查询和数据库方面展示了潜力。然而，以前的研究由于高复杂性和对数据库结构的有限覆盖而面临挑战。随着数据库在规模和领域特异性方面的增长，保持类SQL语法语言的简单性变得越来越困难。此外，其中一些语言需要手动构建和调整，增加了部署成本和复杂性。

2) 类SQL草图结构：利用SQL的结构特征，研究人员开发了镜像SQL结构的类SQL草图用于解析，使多样化的NL查询能够映射到特定的草图空间中，如图9(b)所示。这种方法减少了解析复杂性。

早期工作应用固定草图规则和神经网络将NL映射到类SQL草图结构中。SyntaxSQLNet使用语法树和相应的解码器，将解码分为九个子模块，分别预测操作符、关键词和实体，然后将它们组合生成最终SQL。近年来，语言模型的发展允许研究人员为解析设计更精细的类SQL草图结构。CatSQL构建了一个更通用的模板草图，槽位作为初始占位符。其基础模型专注于解析NL来填充这些占位符，从而降低计算成本。此外，几个最近的工作涵盖了类SQL语法语言和类SQL草图转换方法。例如，RESDSQL引入了排序增强编码和骨架感知解码框架。在解码阶段，其解码器首先生成SQL骨架，然后将其转换为实际SQL查询。当与NatSQL结合时，RESDSQL展示了进一步增强SQL查询生成质量的能力。

一般来说，类SQL草图结构可以更容易地与其他策略结合，如分解策略或类SQL语法语言策略。此外，它可以更充分地利用现有LLM的理解和完形填空能力，减少对专业人员的依赖。

六. TEXT-TO-SQL的后处理策略

在Text-to-SQL模型生成SQL后，后处理可以改进它以更好地满足用户期望。这一步涉及利用附加信息或模型来增强SQL，重点关注SQL校正、确保输出一致性和执行引导检查。

6.1. SQL校正策略

Text-to-SQL模型生成的SQL可能包含语法错误。DIN-SQL引入了一个在零样本设置下运行的自校正模块，其中模型只接收错误的SQL并尝试纠正它。使用两个提示：CodeX的通用提示，直接要求错误识别和纠正，以及GPT-4的温和提示，寻求潜在问题而不假设错误。为了处理谓词预测中的错误，如不正确的列或值，ZeroNL2SQL采用多级匹配方法。这种方法逐步扩展跨列、表和数据库的匹配，允许匹配的值返回给LLM以生成与数据库内容一致的SQL查询。

虽然这些方法专注于修复语法错误，但它们经常忽略语义错误，如不正确的表连接、错位的条件或不准确的聚合，这些对于提高准确性至关重要。

6.2. 输出一致性

为了增强输出一致性，引入了自一致性，基于复杂推理任务可能有多个有效路径到单一正确答案的想法。这种方法采样各种推理路径并选择最一致的答案来提高输出质量。

DAIL-SQL集成自一致性，比没有它的配置实现了0.4%的性能改进。为了减少LLM随机性，Fin-SQL并行生成n个候选SQL查询，基于关键词一致性对它们进行聚类，并从最大聚类中选择查询。自一致性策略通过增加温度和通过多数投票选择最终结果来增强LLM输出多样性。然而，最近的研究表明，依赖单一模型可能仍然产生有限的多样性。为了克服这一限制，PET-SQL引入了交叉一致性策略，其中多个LLM在较低温度下生成SQL并基于执行结果投票。

虽然这些方法通过在多次执行中强制一致性来提高准确性，但它们显著增加了推理成本和时间。

6.3. 执行引导策略

在Text-to-SQL任务中，SQL查询的执行结果为Text-to-SQL翻译准确性提供了关键反馈。例如，执行结果中的错误或NULL值可以表明SQL查询的潜在问题。

为了反映人类编写复杂SQL查询的行为，CHESS为LLM提供数据库模式、问题、候选SQL查询及其执行结果。CHESS从草稿查询开始，基于执行反馈进行改进，根据需要调整语法错误。另一方面，CodeS通过束搜索生成完整的SQL语句，产生四个SQL候选并选择第一个可执行的作为最终结果。

执行引导策略基于执行结果改进SQL，确保查询正确检索数据。然而，这种方法可能显著增加SQL生成时间，特别是对于大型数据库。

6.4. N-best排序器策略

在Text-to-SQL任务中，特别是在跨领域场景中，生成的SQL查询在结构和语义上可能有细微变化。N-best重新排序重新排序top-N模型输出，通常利用更大的模型或附加知识源。例如，在Spider数据集上微调基于BERT的重新排序器，如Bertrand-dr所示，有效改善了几个Text-to-SQL模型的性能。

然而，Bertrand-dr重新排序的有效性可能不稳定且对阈值设置敏感，有时甚至产生负面效果。为了解决这些限制，G3R引入了使用基于PLM的混合提示调优的特征增强重新排序器，在没有额外参数的情况下桥接领域差距。对比学习然后锐化候选查询之间的区别。类似地，RefSQL检索检索器和生成器模块中最相关的结果以提高最终答案质量。

虽然N-best重新排序在基于PLM的方法中广泛用于改进SQL候选，但在基于LLM的方法中不太常见，后者通常具有更强的推理能力。

七. TEXT-TO-SQL数据集

在本节中，我们将首先详细阐述不同类型的Text-to-SQL数据集，突出它们的特征，如图10所示。然后我们将对现有数据集进行深入分析。

7.1. Text-to-SQL基准概述

随着Text-to-SQL的进步，各种数据集已经出现来解决不断发展的挑战，如图10所示。这些范围从具有简单查询的单领域数据库到跨领域、多轮、多语言和领域特定场景，反映了Text-to-SQL解决方案的进展和新挑战的出现。

单领域Text-to-SQL数据集：早期Text-to-SQL数据集专注于具有相对简单SQL查询的特定领域，如用于航班信息的ATIS和用于美国地理事实的GeoQuery。最近，引入了更大的单领域数据集，具有更复杂的数据库和针对特定场景定制的SQL查询。这种转变反映了对评估Text-to-SQL系统在特定领域内的性能和实用性的日益重视。

跨领域Text-to-SQL数据集：在早期单领域数据集开发之后，Text-to-SQL领域转向跨领域数据集，以测试系统在各种SQL查询和数据库上的泛化能力。WikiSQL是第一个跨领域数据集，从Wikipedia中提取表格。

Spider随后被引入，包含具有多个表的更复杂关系数据库。最近，BIRD通过包含Spider中不存在的SQL函数和操作进一步提高了复杂性，为Text-to-SQL提供了更大的挑战。

多轮Text-to-SQL数据集：随着Text-to-SQL的进步，开发了多轮数据集来支持交互式对话。SParC是一个跨领域和多轮数据集，包含约4.3K个NL问题，总计超过12K个(NL, SQL)对，每个NL问题都需要跨轮次的上下文理解。CoSQL使用Wizard-of-Oz设置收集，包含超过30K轮，并引入了无法回答的问题等额外挑战，进一步测试上下文理解。

具有鲁棒性测试的Text-to-SQL数据集：在现实世界应用中，Text-to-SQL系统必须处理多样化的用户群体和数据库，强调鲁棒性。Spider-Syn通过在NL问题中使用同义词来模拟用户对模式的不熟悉，而Dr.Spider对数据库、NL问题和SQL查询应用17种类型的扰动进行全面的鲁棒性评估。

具有SQL效率测试的Text-to-SQL数据集：现实世界的数据库通常包含大量数据，单个NL可能对应多个具有不同执行效率的SQL查询。BIRD引入了一个用于评估SQL执行效率的指标，称为有效效率分数（VES），这将在第VIII节进一步讨论。

知识增强的Text-to-SQL数据集：领域特定知识对于Text-to-SQL系统在现实世界应用中表现良好至关重要。KaggleDBQA包括数据库文档，如列和表描述。类似地，Spider-DK通过向NL问题添加五种类型的领域知识来扩展Spider开发集，测试系统使用这些信息的能力。

具有模糊问题的Text-to-SQL数据集：在现实世界的Text-to-SQL任务中，经常出现歧义，如NL中的语义歧义和重叠的数据库模式，使得以歧义为重点的评估变得越来越重要。AmbiQT是第一个设计用于评估歧义覆盖的数据集，包含四种歧义类型。每个NL问题映射到两个有效的SQL查询，反映特定的歧义。

合成Text-to-SQL数据集：MIMICSQL采用基于模板的方法生成初始模板问题和相应的SQL查询，尽管需要手动改进以使问题更自然。ScienceBenchmark也使用模板进行初始SQL生成，但利用GPT-3进行SQL到NL的翻译。

7.2. 现有Text-to-SQL数据集的深入分析

为了分析和比较Text-to-SQL数据集的复杂性，我们使用NL2SQL360系统进行统计评估，如表II所示。我们测量冗余度，包括NL问题数量、SQL查询数量及其比率。数据库复杂性涵盖总数据库数、总表数、每个数据库的平均表数、每个表的平均列数和每个数据库的平均记录数。查询复杂性测量每个SQL查询中表的平均数量、SELECT关键词、聚合函数、标量函数和数学计算。对于没有公共开发/测试分割的数据集，如CHASE，仅报告公共分割的统计信息。对于没有公开可用数据的数据集，如knowSQL，表II中的值标记为"–"。

从冗余度测量的角度来看，我们观察到从早期数据集到最近数据集的趋势，即数据集规模不断增长。具体来说，MT-TEQL以最高的NL问题数量和最大的NL问题与SQL查询比率脱颖而出，这是由于其自动转换NL问题，生成大量变体。

在数据库复杂性方面，每个数据集内的数据库和表数量与其预期任务一致。单领域数据集，如BookSQL，通常包含较少的数据库，而那些旨在进行鲁棒性评估的数据集，如Dr.Spider和MT-TEQL，包含更多的数据库。

关于查询复杂性，像FIBEN和SEDE这样的数据集具有包含多个表和聚合函数的SQL查询，反映了现实世界金融领域和Stack Exchange站点的复杂性。最近的数据集还强调标量函数和数学计算，增加了结构挑战。

讨论：尽管Text-to-SQL社区提出的数据集数量不断增加，但与现实世界场景相比，SQL复杂性仍存在差距。当前数据集通常具有较少的SELECT关键词，表明缺乏嵌套查询和复杂的集合操作。此外，涉及标量函数和数学计算的挑战需要进一步关注。我们鼓励社区提出解决这些复杂性的数据集。

八. 评估和错误分析

在本节中，我们介绍Text-to-SQL解决方案的关键评估指标，回顾用于低成本和全面评估的工具包，并提供用于分析Text-to-SQL过程中SQL错误的错误分类法。

8.1. 评估指标

评估指标对于测量Text-to-SQL性能至关重要。我们定义N为数据集大小，$Q_i$为第i个示例的NL问题，$Y_i$为第i个示例的真实SQL查询，${\hat{Y}}_i$为Text-to-SQL解决方案生成的SQL查询，$V_i$和${\hat{V}}_i$为SQL查询$Y_i$和${\hat{Y}}_i$的执行结果集。

执行准确率（EX）：此指标通过比较真实SQL查询和预测SQL查询的执行结果集是否相同来评估Text-to-SQL系统的性能。可以通过以下方式计算：

$$EX=\frac{{\sum }_{i=1}^{N}1(V_i={\hat{V}}_i)}{N}$$

其中$1(\cdot )$是指示函数，如果内部条件满足则等于1，否则为0。注意可能出现假阴性，因为对应于语义不同NL查询的不同SQL查询可能产生相同的执行结果集。

字符串匹配准确率（SM）：此指标，也称为逻辑形式准确率，简单比较真实SQL查询和预测SQL查询作为字符串是否相同。它可能惩罚产生正确执行结果集但与真实SQL查询没有精确字符串匹配的SQL查询。可以计算如下：

$$SM=\frac{{\sum }_{i=1}^{N}1(Y_i={\hat{Y}}_i)}{N}$$

组件匹配准确率（CM）：此指标通过测量真实SQL查询和预测SQL查询之间不同SQL组件（如SELECT、WHERE等）的精确匹配来评估Text-to-SQL系统的详细性能。对于特定SQL组件C，计算可以形式化如下：

$$C{M}_C=\frac{{\sum }_{i=1}^{N}1(Y_i^C={\hat{Y}}_i^C)}{N}$$

其中$Y_i^C$是SQL查询$Y_i$的组件。为了正确确定SQL组件是否匹配，某些SQL组件（如WHERE）不考虑顺序约束。

精确匹配准确率（EM）：此指标基于组件匹配准确率（CM），测量预测SQL查询的所有SQL组件C={Ck}C=\{C_k\}C={Ck​}是否与真实SQL查询匹配。可以计算如下：

$$EM=\frac{{\sum }_{i=1}^{N}1({\bigwedge }_{C_k\in C}{Y}_i^{C_k}={\hat{Y}}_i^{C_k})}{N}$$

有效效率分数（VES）：此指标测量有效SQL查询的执行效率。它考虑SQL执行的准确性和效率，可以计算如下：

$$VES=\frac{{\sum }_{i=1}^{N}1(V_i={\hat{V}}_i)\cdot R(Y_i,{\hat{Y}}_i)}{N},R(Y_i,{\hat{Y}}_i)=\sqrt{\frac{E(Y_i)}{E({\hat{Y}}_i)}}$$

其中$R(\cdot )$测量预测SQL查询相对于真实SQL查询的相对执行效率，消除由于机器状态造成的不确定性。$E(\cdot )$测量特定SQL查询的效率，可以指执行时间、内存使用等。

查询变化测试（QVT）：此指标测量Text-to-SQL系统在处理NL查询变化方面的鲁棒性。对于给定的SQL查询$Y_i$，通常有多个对应的NL查询，表示为对$\{(Q_1,Y_i),(Q_2,Y_i),...,(Q_m,Y_i)\}$。QVT指标计算如下：

$$QVT=\frac{1}{N}\sum _{i=1}^N\left(\frac{{\sum }_{j=1}^{m_i}1(F(Q_{ij})=Y_i)}{m_i}\right)$$

其中$m_i$是SQL查询$Y_i$的不同NL变化数量，$F(Q_{ij})$是$Y_i$的第j个NL变化的预测SQL查询。

8.2. Text-to-SQL评估工具包

最近的Text-to-SQL解决方案在各种Text-to-SQL基准上取得了显著性能。然而，在现实世界应用中，NL查询风格、数据库模式和跨领域SQL查询特征的变化使得仅使用标准基准指标难以全面评估系统鲁棒性。为了解决这个问题，最近开发了工具包来在实际场景中提供Text-to-SQL系统的更全面评估。

MT-TEQL是一个统一框架，用于评估Text-to-SQL系统在处理现实世界NL查询和数据库模式变化方面的性能。它基于变形测试方法，实施NL查询和数据库模式的语义保持变换，自动生成它们的变体而无需手动努力。它包括四种类型的NL查询变换（如前缀插入）和八种类型的数据库模式变换（如表洗牌）。

NL2SQL360是一个多角度评估框架，在不同场景下提供Text-to-SQL系统的细粒度评估（图1©）。与MT-TEQL不同，它强调不同应用中多样化的SQL查询特征，如商业智能场景中典型的聚合函数、嵌套查询或top-k查询。包含六个核心组件：数据集、模型库、指标、数据集过滤器、评估器和分析，NL2SQL360为系统评估提供统一的、模型无关的接口。用户可以应用公共和私有数据集，为特定场景定制指标，并分析具有场景特定SQL特征的子集性能，为跨应用的Text-to-SQL系统有效性提供有价值的见解。

8.3. Text-to-SQL错误分析分类法

错误分析涉及检查模型错误以识别限制并指导改进性能的纠正行动。在本节中，我们首先回顾现有的Text-to-SQL错误分类法。然后我们提出设计原则并介绍两级Text-to-SQL错误分类法。

现有的Text-to-SQL错误分析分类法：最近的Text-to-SQL研究越来越多地纳入错误分析，提出各种错误分类法。Ning等人基于两个维度引入了详细的错误分类法：(1)语法维度识别错误发生的特定SQL部分，按WHERE和JOIN等关键词组织。(2)语义维度表示对自然语言描述的误解，如理解表名的错误。SQL-PaLM将错误分为五种类型：(1)模式链接，不相关或缺失的表/列选择；(2)数据库内容，误解数据值；(3)知识证据，未能利用外部提示；(4)推理，缺乏中间逻辑步骤；(5)语法，无效SQL格式。NL2SQL-BUGs专注于语义错误分析，将其组织为9个主要类别和31个子类别。它进一步提出了一个新的基准来评估模型的错误检测能力，推进Text-to-SQL中的自动错误分析。

Text-to-SQL错误分析的分类法原则：当前Text-to-SQL中的错误分类法通常特定于特定数据集，限制了它们的一般适用性。为了解决这些问题，标准化和有效的分类法是必要的。我们提出以下原则来指导Text-to-SQL错误分类法的开发：

• 全面性：分类法应涵盖Text-to-SQL翻译过程中所有可能的错误类型。
• 互斥性：每种错误类型应该清楚地区分以避免分类歧义。
• 可扩展性：分类法应该适应包含随着Text-to-SQL发展而出现的新错误类型。
• 实用性：它应该是实用的，使用户能够在现实世界场景中诊断和解决错误。

我们的Text-to-SQL错误分析分类法：遵循这些原则，我们开发了两级Text-to-SQL错误分析分类法：

• 错误定位：第一级识别错误发生的特定SQL组件，如SELECT或WHERE子句。确定错误位置能够进行有针对性的调整并提高纠正效率。
• 错误原因：第二级专注于错误的根本原因。例如，WHERE子句值中的错误可能表明模型在数据库内容检索或解释方面的限制。

讨论两级错误分类法的应用：我们使用我们提出的分类法收集并分类了DIN-SQL在Spider上的错误。如图1(d)所示，只有1.8%的错误属于其他类别，表明我们的分类法是实用和有效的。尽管如此，我们认识到开发完整和普遍适用的Text-to-SQL错误分类法本质上是迭代的。我们鼓励社区继续努力随着时间的推移改进和扩展这个分类法。

九. TEXT-TO-SQL的实用指导

在本节中，我们为开发Text-to-SQL解决方案提供实用指导，考虑关键因素和场景。

9.1. Text-to-SQL的数据驱动路线图

在图11(a)中，我们概述了一个战略路线图，旨在基于数据隐私和数据量优化LLM用于Text-to-SQL任务。数据隐私影响开源和闭源LLM的选择，而数据量影响训练和推理优化策略。

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

条件2：数据量：对于开源LLM，在训练和推理阶段都可以进行优化，而闭源LLM由于访问受限只允许推理阶段优化。对于大量Text-to-SQL数据，预训练增强性能；微调适用于具有数百到数千个(NL, SQL)对的数据集。在低数据场景中，推荐少样本学习，而当没有标注数据时，零样本方法至关重要。硬件资源和API成本也是选择最佳优化策略时的重要考虑因素。

9.2. 选择Text-to-SQL模块的决策流程

在图11(b)中，我们基于特定场景提出选择Text-to-SQL模块的建议，突出好处和权衡。下面，我们概述两个例子。

场景1：具有众多表和列的复杂数据库模式：在这种情况下，建议使用模式链接策略。这减少了令牌成本并最小化来自不相关模式元素的噪声，提高效率。然而，它也产生额外的时间成本。

场景2：可以访问执行结果：在这里，推荐执行引导策略，因为它们通过过滤掉不可执行的SQL查询来提高系统性能。缺点是查询执行所需的时间增加，对于大型数据库可能很大。

总之，虽然每个模块为特定的Text-to-SQL场景提供独特优势，但在系统设计中平衡这些好处与潜在缺点是必要的。

十. 限制和开放问题

我们分析基于LLM方法的限制并提出相应的开放问题，突出未解决的挑战并建议未来研究方向。

当前基于LLM解决方案的限制：尽管最近基于LLM的Text-to-SQL方法取得了显著进展，但在处理现实世界场景中的复杂查询时仍面临几个挑战。首先，现有方法通常在单个固定数据库上训练和执行，这限制了它们处理需要跨数据库查询和多源数据聚合的开放环境的能力。其次，虽然LLM具有强大的自然语言理解能力，但它们在推理期间产生高令牌消耗，导致高成本和低效率。此外，大多数Text-to-SQL方法缺乏可解释性和调试机制，使用户难以理解模型如何生成SQL或检测和修复潜在的语义错误。最后，当前方法显示对新领域的适应性有限，严重依赖高质量训练数据；如何基于模型反馈自动生成有针对性的训练样本仍然是一个开放问题。这些限制揭示了跨数据库可扩展性、推理效率、系统可靠性和数据适应性方面的不足，突出了对更高效、可信和可扩展的Text-to-SQL解决方案的需求。

开放领域Text-to-SQL问题：在现实世界场景中，如政府开放数据平台，公民可能提出需要查询多个数据库并聚合结果的问题。例如，回答"过去五年税务申报的平均处理时间是多少？"需要从多个数据库（如税务记录、处理日志和统计报告）检索表并在其上生成多个SQL查询。与传统Text-to-SQL不同，用户指定单个目标数据库，开放Text-to-SQL可能需要为单个NL生成访问不同数据库的多个SQL查询。

因此，开放Text-to-SQL问题引入了独特的挑战，包括：(1)数据库检索：从大量数据源中准确识别和检索相关数据库；(2)处理异构模式：整合具有不同结构和术语的数据，需要高级模式匹配和链接技术；(3)答案聚合：从跨数据库的多个SQL查询推断最终答案，这需要规划查询顺序、解决冲突和确保一致性的方法；(4)领域适应：跨领域泛化模型以解决术语和结构差异；(5)可扩展性和效率：在保持性能的同时管理大数据量；(6)评估和基准测试：开发准确反映开放Text-to-SQL解决方案现实世界复杂性的指标和数据集。

开发成本效益的Text-to-SQL方法：基于LLM的Text-to-SQL方法显示出巨大潜力，但受到高令牌消耗的限制，导致成本增加和推理时间变慢。相比之下，基于PLM的Text-to-SQL方法擅长处理复杂SQL查询和准确解释数据库模式。一个有前景的方法是结合两者的优势，开发模块化Text-to-SQL解决方案或使用多智能体框架将LLM和PLM集成用于Text-to-SQL任务（如表III所示）。同时，努力旨在提高基于LLM的效率。EllieSQL采用复杂性感知路由通过将查询分配给合适的基于LLM的生成器来增强成本效率。

因此，一个有趣的研究问题是基于模型性能自动和增量生成(NL, SQL)对。具体来说，通过纳入评估指标和评估结果的见解，我们可以识别模型的特定弱点。使用这些信息，我们可以合成训练数据，在LLM的帮助下不断发展以覆盖更广泛的领域。

使Text-to-SQL解决方案可信：确保Text-to-SQL解决方案可信对于生成准确可靠的SQL、减轻风险和减少手动干预的需要至关重要。主题包括以下内容：

解释Text-to-SQL解决方案：理解Text-to-SQL模型性能背后的推理增强了对其可靠性的信心。可解释AI技术，如代理模型和显著性图，旨在揭示模型决策。然而，它们在Text-to-SQL上下文中的有效性，特别是与组合LLM和PLM，仍然是一个开放问题。此外，多智能体LLM框架通过将Text-to-SQL分解为专门的子任务来提高可靠性。虽然这种方法提高了鲁棒性，但协调智能体以确保一致和优化的性能仍然是一个主要挑战。

Text-to-SQL调试工具：受编译器设计启发，Text-to-SQL的调试器可以通过测量生成SQL查询中的语义和语法错误来提高准确性和可靠性。这样的工具将检测潜在错误，使用户能够检查SQL生成过程并识别不匹配。然而，实现这个目标面临重大挑战。传统代码编译器主要捕获语法错误，而Text-to-SQL调试必须还解决语义错误，即确保生成的SQL查询准确反映NL查询的意图。

交互式Text-to-SQL工具：这些工具对于赋能专业用户（如DBA）创建跨多个数据库的复杂SQL查询至关重要，通常超过50行代码。一个关键特征是模型将复杂查询分解为可管理的子查询的能力，减少认知负荷并使DBA能够在重新组装之前专注于每个部分。支持自底向上和自顶向下工作流程，这样的工具使用户能够迭代改进输出，将SQL生成与意图对齐，并将模型辅助与领域专业知识集成。

自适应训练数据合成：基于学习的Text-to-SQL模型经常无法泛化到未见领域，部分原因是训练数据覆盖、质量和多样性有限。因此，一个有趣的研究问题是基于模型性能自动和增量生成(NL, SQL)对。具体来说，通过纳入评估指标和评估结果的见解，我们可以识别模型的特定弱点。使用这些信息，我们可以合成训练数据，在LLM的帮助下不断发展以覆盖更广泛的领域。

XI. 结论

在本文中，我们从LLM时代的生命周期角度全面回顾了Text-to-SQL技术。我们正式定义了Text-to-SQL任务，讨论了关键挑战，并提出了基于底层语言模型的分类法。我们总结了语言模型驱动方法的关键模块，包括预处理、翻译和后处理策略。此外，我们分析了基准和评估指标，突出了它们的特征和常见错误。我们还为将LLM适应Text-to-SQL任务提供了实用路线图，并维护了一个包含最新进展的在线手册，讨论了持续的挑战和开放问题。