Text2SQL综述学习

论文名称：A Survey of NL2SQL with Large Language Models

总结

(a) NL2SQL模型演化流图

从2004年开始，NL2SQL 的解决方案经历了多个发展阶段，包括基于规则的方法、神经网络基础方法、预训练语言模型（PLM）基础方法和大型语言模型（LLM）基础方法。

图片上方列出了各个阶段的重要模型，如PRECISE、BELA、ATHENA、SQLizer、Spider、SParC、ChatGPT等。下方列出了NL2SQL任务的数据集，如WikiSQL、Spider、SParC等

NL2SQL任务的输入：自然语言查询（NL Query）和数据库（Database）。
NL2SQL任务的输出：SQL查询（SQL Query）。

(b) Benchmarks 和训练数据合成

训练数据构建方法：从数据库开始，通过不同的方法生成自然语言查询，然后转换为SQL查询。主要有以下三种方法：

人工标注
基于规则生成
用大模型生成（LLMs）

(c) NL2SQL评估

整个NL2SQL生命周期是一个循环过程，从数据集开始（如Spider、BIRD、Dr.Spider、WikiSQL等）-> 到使用模型生成SQL（如DAIL-SQL、DINSQL等模型）-> 评估（Execution Accuracy 执行准确率、Exact-Match 完全匹配准确率）-> Filter（SQL的复杂性/特征、数据领域）-> 评估（定量评估/定性评估）-> Analysis（可视化分析/可视化仪表板）

(d) NL2SQL错误分析

错误类型：图中展示了SQL查询中常见的错误类型及其比例，如SELECT（25.5%）、WHERE（15.2%）、FROM（15.3%）、GROUP BY（16.6%）等。

论文对基于大模型的NL2SQL做了全面回顾，涵盖了NL2SQL任务的整个生命周期，从以下四个方面进行：

（1）模型：NL2SQL转换技术不仅解决了自然语言的歧义和不明确性问题，而且还正确地将自然语言与数据库模式和实例映射；

（2）数据：从训练数据的收集，由于训练数据稀缺导致的数据合成，到NL2SQL基准测试；

（3）评估：使用不同的指标和粒度从多个角度评估NL2SQL方法；

（4）错误分析：分析NL2SQL错误以找到根本原因，并指导NL2SQL模型的发展。此外，我们还提供了开发NL2SQL解决方案的经验法则。最后，我们讨论了LLMs时代NL2SQL的研究挑战和开放性问题。

挑战

C1：不确定的自然语言查询。自然语言查询由于歧义和不明确性常常包含不确定性。在NL2SQL任务中，与自然语言相关的挑战可以总结如下：

词汇歧义：当一个单词有多种含义时就会发生这种情况。例如，“bat”这个词可以指代一种动物，也可以指棒球棒（名词），或者指挥动的动作（动词）。
句法歧义：当一个句子可以有多种解析方式时就会发生这种情况。例如，在句子“玛丽用望远镜看到了那个男人”中，短语“with the telescope”可以表示玛丽使用望远镜看到了那个男人，或者那个男人拥有望远镜。
不明确性：当语言表达缺乏足够的细节来清晰地传达特定的意图或含义时就会发生这种情况。例如，“2023年劳动节”在美国指的是9月4日，但在中国指的是5月1日。

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

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

C3：NL2SQL翻译。NL2SQL任务与将高级编程语言编译为低级机器语言不同，因为它通常在输入的自然语言和输出的SQL查询之间存在多对一的映射。具体来说，NL2SQL任务面临几个独特的挑战：

自由形式的自然语言与受限和正式的SQL：自然语言是灵活的，而SQL查询必须遵循严格的语法。将自然语言翻译成SQL需要精确性以确保生成的查询是可执行的。
多种可能的SQL查询：单个自然语言查询可以对应多个满足查询意图的SQL查询，这导致在确定适当的SQL翻译时存在歧义（参见图2(a)中的例子）。
数据库模式依赖性：NL2SQL翻译高度依赖于底层数据库模式。如图2(a)和(b)所示，相同的自然语言可能会根据模式变化产生不同的SQL查询。这要求NL2SQL模型在训练数据和现实世界模式差异之间架起桥梁。

除了NL2SQL任务的内在挑战外，开发者还必须克服几个技术障碍，以构建可靠和高效的NL2SQL系统，如下所述。

C4：开发NL2SQL解决方案中的技术挑战。开发强大的NL2SQL解决方案需要解决几个关键的技术挑战，包括：

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

LLMs时代的NL2SQL解决方案

一般来说，利用LLMs（大型语言模型）的能力进行NL2SQL（自然语言到SQL）有两种主要方法：1）上下文学习，2）为NL2SQL专门预训练/微调LLMs。

NL2SQL的上下文学习（in-context learning,）：对于NL2SQL的上下文学习方法，目标是优化提示函数P以引导LLMs，可以公式化如下：

$F_{LLM}(P|NL,DB,K) -> SQL$

其中K表示与NL或DB相关的附加信息或特定领域的知识。P是一个提示函数，将输入（NL, DB, K）转换为LLMs的合适文本提示。适当设计的P可以有效地引导LLMs更准确地执行NL2SQL任务。

在NL2SQL中采用上下文学习策略将LLMs视为现成的工具，无需修改其参数。然而，如果用户有足够的训练数据或硬件资源，校准LLMs的参数可以提高性能和准确性，使模型更紧密地适应特定的NL2SQL任务。

为NL2SQL预训练和微调LLMs：为NL2SQL完全优化LLMs的参数涉及两个关键阶段：

预训练和微调，可以公式化为如下：

$LLM^* = F_{fine-tune}(F_{pre-train}(LLM,D_P), D_f)$

在预训练期间，LLM在包括广泛语言模式和领域通用知识的大规模和多样化数据集 Dp

在随后的微调阶段，预训练模型在与NL2SQL任务更紧密对齐的更专业数据集 Df 上进一步调整。这种针对性训练细化了模型的能力，使其能够更有效地基于自然语言查询解释和生成SQL。

语言模型驱动的NL2SQL概述

预处理方法：预处理作为模型在NL2SQL解析过程中的输入增强。虽然不是严格必需的，但预处理显著有助于改进NL2SQL解析[52]。

Schema Linking 模式链接：此关键模块从NL2SQL中识别最相关的表和列。基于大模型的解决方案有：

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

Database Content Retrieval 数据库内容检索：此关键模块访问制定SQL所需的适当数据库内容或单元格值。

- CHESS[53]使用局部敏感哈希[89]进行近似最近邻域搜索，索引唯一单元格值以快速找到与自然语言查询最相关的匹配项。简单来说就是把高维的向量映射到低维哈希空间，在查询时，只需在与查询点哈希值相同或相近的哈希桶中寻找近似最近邻，大大提高了搜索效率。

Additional Inormation Acquisition 附加信息获取：此关键模块通过整合特定领域的知识丰富上下文背景。
Additional Information Acquisitio：整合特定领域的知识丰富上下文背景。

- 基于示例： DIN-SQL 在选表、查询分类、任务分解，自我纠正等多个模块构建prompt的时候，来整合额外信息；BIRD 也包含对各种NL2SQL的领域知识
- 基于检索：例如，PET-SQL构建问题框架和问题-SQL对的池，选择与目标查询最相似的k个示例，然后用于提示。

NL2SQL翻译方法：这是NL2SQL解决方案的核心，负责将输入的NL查询转换为SQL。

编码策略：此关键模块将输入的NL和数据库模式转换为内部表示，捕获输入数据的语义和结构信息，包括序列编码和图编码和分离编码策略。

解码策略：此关键模块将内部表示转换为SQL查询。包括贪婪搜索（GPT4）、束搜索和约束感知增量解码策略。

特定任务提示策略：此模块为NL2SQL模型提供定制指导，优化NL2SQL翻译工作流程，包括思维链（COT）和分解策略。

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

分解策略将NL2SQL任务分解为顺序子任务，允许每个子模块专注于特定的生成步骤，从而提高准确性、质量和可解释性。

中间表示：此模块作为NL和SQL翻译之间的桥梁，提供结构化的方法来抽象、对齐和优化NL理解，简化复杂推理，并指导生成准确的SQL查询。

NL2SQL任务由于自然语言查询的复杂性和歧义性，加上SQL的语法约束特性，使得任务变得具有挑战性。为了简化这一过程，研究人员开发了一种无语法限制的中间表示（IR），以桥接“自由形式”的自然语言问题和“受限且正式”的SQL。这种IR提供了一种结构化但灵活的格式，捕捉自然语言查询中的基本组成部分和关系，而无需遵循SQL的严格语法要求。

后处理方法：后处理是优化生成的SQL查询以提高准确性的关键步骤。

SQL校正策略：旨在识别和纠正生成的SQL中的语法错误。

- NL2SQL模型生成的SQL可能包含语法错误或不必要的关键字，如DESC、DISTINCT和聚合函数。DIN-SQL[5]引入了一个自我修正模块，该模块在零样本设置中运行，模型仅接收错误的SQL并尝试修正它。使用了两个提示：一个用于CodeX的通用提示，直接要求识别和修正错误；一个用于GPT-4的温和提示，寻求潜在问题而不预设错误。为了处理谓词预测中的错误，如错误的列或值，ZeroNL2SQL[43]采用了多级匹配方法。这种方法逐步扩展列、表和数据库之间的匹配，允许将匹配的值返回给LLMs，以生成与数据库内容一致的SQL查询。