OlaChat AI数智助手万字长文深度解析，带你了解Text-to-SQL技术的前世今生。

论文地址：Next-Generation Database Interfaces: A Survey of LLM-based Text-to-SQL

从自然语言问题（文本到SQL）生成准确的SQL是一个长期以来的挑战，因为用户问题理解、数据库模式理解和SQL生成中的复杂性。传统的文本到SQL系统，包括人工工程和深度神经网络，已经取得了实质性进展。随后，预训练的语言模型（PLMs）已被开发并用于文本到SQL任务，取得了有希望的性能。随着现代数据库变得越来越复杂，相应的用户问题也变得更加具有挑战性，导致参数受限的PLMs（预训练模型）产生错误的SQL。这就需要更复杂的定制优化方法，这反过来又限制了基于PLM的系统应用。

最近，大型语言模型（LLMs）在自然语言理解方面展示了显著的能力，因为模型规模的增长。因此，集成基于LLM的实现可以为文本到SQL研究带来独特的机会、改进和解决方案。在这项调查中，本文全面回顾了基于LLM的文本到SQL。具体来说，作者提出对文本到SQL的技术挑战和进化过程的一个简要概述。然后，作者们提供了详细介绍旨在评估文本到SQL系统的数据集和评价指标。之后，本文系统地分析了基于LLM的文本到SQL的最新进展。最后，讨论了该领域剩余的挑战，并提出了未来研究方向的期望。

文中”[xx]”具体指代的论文，可以查阅论文原文的参考文献部分。

引言

Text-To-SQL 是自然语言处理研究中的一项长期任务。它旨在将自然语言问题转换（翻译）为数据库可执行的 SQL 查询。图 1 提供了一个基于大型语言模型（基于 LLM）的文本到 SQL 系统的示例。给定一个用户问题，例如“您能告诉我历史上比赛次数最多的 5 个联赛的名称以及该联赛进行了多少场比赛吗？”，LLM将问题及其相应的数据库模式作为输入并进行分析。然后生成 SQL 查询作为输出。可以在数据库中执行此 SQL 查询来检索相关内容来回答用户的问题。上述系统使用LLM构建了数据库（NLIDB）的自然语言接口。

由于 SQL 仍然是使用最广泛的编程语言之一，一半 (51.52%) 的专业开发人员在工作中使用 SQL，值得注意的是，只有大约三分之一 (35.29%) 的开发人员接受过系统培训，NLIDB 使非熟练用户能够像专业数据库工程师一样访问结构化数据库 [1 ，2]并且还加速了人机交互[3]。此外，在LLM的研究热点中，文本到SQL可以通过结合数据库中的真实内容来填补LLM的知识空白，为普遍存在的幻觉[4, 5]问题提供潜在的解决方案[6]。文本转 SQL 的巨大价值和潜力引发了一系列关于其与LLM集成和优化的研究 [7-10]；因此，基于 LLM 的文本到 SQL 仍然是 NLP 和数据库社区中备受讨论的研究领域。

以往的研究在实现文本到 SQL 方面取得了显著进展，并经历了一个漫长的演变过程。早期的研究大多基于精心设计的规则和模板[11]，特别适用于简单的数据库场景。近年来，随着基于规则的方法带来的高昂人工成本[12]和数据库环境的日益复杂[13 - 15]，为每种场景设计规则或模板变得越来越困难和不切实际。深度神经网络的发展推动了文本到 SQL 的进步[16, 17]，它可以自动学习从用户问题到相应 SQL 的映射[18, 19]。随后，具有强大语义解析能力的预训练语言模型（PLM）成为文本到 SQL 系统的新范例[20]，将其性能提升到了一个新水平[21 - 23]。对基于 PLM 的优化（如表内容编码 [ 19 , 24 , 25 ]和预训练 [ 20 , 26 ]）的逐步研究进一步推动了这一领域的发展。最近，基于 LLM 的方法通过上下文学习（ICL）[8] 和微调（FT）[10] 范式实现了文本到 SQL 的转换，凭借精心设计的框架和比 PLM 更强的理解能力，达到了最先进的准确性。

基于 LLM 的文本到 SQL 的总体实现细节可分为三个方面：

1）问题理解：NL 问题是用户意图的语义表示，相应生成的 SQL 查询应与之保持一致；

2）模式理解：模式提供了数据库的表和列结构，文本到 SQL 系统需要识别与用户问题相匹配的目标组件；

3）SQL 生成：这包括结合上述解析，然后预测正确的语法，生成可执行的 SQL 查询，以检索所需的答案。事实证明，LLMs 可以很好地实现text-to-SQL 功能[7, 27]，这得益于更丰富的训练语料库所带来的更强大的语义解析能力[28, 29]。关于增强 LLMs 的问题理解[8, 9]、模式理解[30, 31]和 SQL 生成[32]等方面的进一步研究正日益增多。

尽管文本到 SQL 的研究取得了重大进展，但仍存在一些挑战，阻碍了稳健、通用的文本到 SQL 系统的开发 [ 73 ]。近年来的相关研究对深度学习方法中的文本到 SQL 系统进行了调查，并对之前的深度学习方法和基于 PLM 的研究提出了见解。在本调查报告中旨在追赶最新进展，并对基于 LLM 的文本到 SQL 的当前最新模型和方法进行全面回顾。首先介绍了与文本到 SQL 相关的基本概念和挑战，强调了这项任务在各个领域的重要性。然后，深入探讨文本到 SQL 系统实施范例的演变，讨论该领域的主要进展和突破。概述之后，将详细介绍和分析集成 LLM 的文本到 SQL 的最新进展。具体来说，本文调查报告涵盖了与基于 LLM 的文本到 SQL 相关的一系列内容，包括：

● 数据集和基准：详细介绍了用于评估基于 LLM 的文本到 SQL 系统的常用数据集和基准。本文讨论了它们的特点、复杂性以及它们对文本到 SQL 的开发和评估带来的挑战。

● 评估指标：将介绍用于评估基于 LLM 的文本到 SQL 系统性能的评估指标，包括基于内容匹配和基于执行的范例。然后简要介绍了每个指标的特点。

● 方法和模型：本文对基于 LLM 的文本到 SQL 所采用的不同方法和模型进行了系统分析，包括基于上下文学习和微调的范例。从不同的实施角度讨论了它们的实施细节、优势以及针对文本到 SQL 任务的适应性。

● 期望和未来方向：本文讨论了基于 LLM 的文本到 SQL 的其余挑战和局限性，如现实世界的鲁棒性、计算效率、数据隐私和扩展。还概述了潜在的未来研究方向以及改进和优化的机会。

概述

Text-to-SQL 是一项旨在将自然语言问题转换为可以在关系数据库中执行的相应 SQL 查询的任务。形式上，给定一个用户问题 Q（也称为用户查询、自然语言问题等）和数据库模式 S，任务的目标是生成 SQL 查询 Y，从数据库检索所需内容以回答用户问题。文本到 SQL 允许用户使用自然语言与数据库交互，而不需要 SQL 编程的专业知识，从而有可能实现数据访问的民主化 [75]。通过使非熟练用户能够轻松地从数据库中检索目标内容并促进更有效的数据分析，这可以使商业智能、客户支持和科学研究等各个领域受益。

A.Text-to-SQL中的挑战

文本到 SQL 实现的技术挑战可以概括如下：

1）语言复杂性和歧义性：自然语言问题通常包含复杂的语言表示，例如嵌套子句、共指和省略号，这使得将它们准确地映射到 SQL 查询的相应部分是很有挑战性的[41]。此外，自然语言本质上是不明确的，对于给定的用户问题有多种可能的表示[76, 77]。解决这些歧义并理解用户问题背后的意图需要深入的自然语言理解以及整合上下文和领域知识的能力[33]。

2）模式理解和表示：为了生成准确的SQL查询，文本转SQL系统需要对数据库模式有全面的理解，包括表名、列名以及各个表之间的关系。然而，数据库模式可能很复杂，并且在不同领域之间差异很大[13]。以文本到 SQL 模型可以有效利用的方式表示和编码模式信息是一项具有挑战性的任务。

3）罕见和复杂的SQL操作：一些SQL查询在具有挑战性的场景中涉及罕见或复杂的操作和语法，例如嵌套子查询、外连接和窗口函数。这些操作在训练数据中不太常见，对文本到 SQL 系统的准确生成提出了挑战。设计可推广到各种 SQL 操作（包括罕见和复杂场景）的模型是一个重要的考虑因素。

4）跨域泛化：文本到 SQL 系统通常很难跨各种数据库场景和域进行泛化。由于词汇、数据库模式结构和问题模式的多样性，在特定领域训练的模型可能无法很好地处理其他领域提出的问题。开发能够使用最少的特定领域训练数据或微调适应有效推广到新领域的系统是一项重大挑战[78]。

B.进化过程

多年来，文本到 SQL 的研究领域在 NLP 界取得了长足的进步，从基于规则的方法发展到基于深度学习的方法，最近又发展到集成预训练语言模型 (PLM) 和大型语言模型 (LLM)，其演化过程简图如图 2 所示。

1) 基于规则的方法：早期的文本到 SQL 系统在很大程度上依赖于基于规则的方法 [11, 12, 26]，即使用人工制定的规则和启发式方法将自然语言问题映射到 SQL 查询。这些方法通常涉及大量的特征工程和特定领域知识。虽然基于规则的方法在特定的简单领域取得了成功，但它们缺乏处理各种复杂问题所需的灵活性和泛化能力。

2) 基于深度学习的方法：随着深度神经网络的兴起，序列到序列模型和编码器-解码器结构（如 LSTM [ 79] 和转换器 [ 17 ]）被用于从自然语言输入生成 SQL 查询 [ 19 , 80 ]。通常，RYANSQL [19] 引入了中间表示法和基于草图的槽填充等技术，以处理复杂问题并提高跨领域通用性。最近，研究人员利用模式依赖图捕捉数据库元素之间的关系，为文本到 SQL 任务引入了图神经网络 (GNN)[18,81]。

3) 基于 PLM 的实施：预训练语言模型（PLM）利用预训练过程中获取的大量语言知识和语义理解，已成为文本到 SQL 的强大解决方案。PLM 在文本到 SQL 中的早期应用主要集中于在标准文本到 SQL 数据集上微调现成的 PLM，如 BERT [24] 和 RoBERTa [82][13，14]。这些 PLM 在大量的训练语料库上进行了预训练，捕获了丰富的语义表征和语言理解能力。通过在文本到 SQL 任务中对它们进行微调，研究人员旨在利用 PLM 的语义和语言理解能力生成准确的 SQL 查询 [ 20, 80, 83]。另一个研究方向是将模式信息纳入 PLM，以改进这些系统可以帮助用户理解数据库结构，并生成可执行性更强的 SQL 查询。模式感知 PLM 设计用于捕捉数据库结构中存在的关系和约束[21]。

4) 基于 LLM 的实现：大型语言模型（LLMs），如 GPT 系列 [ 84 -86 ]，因其生成连贯流畅文本的能力而在近几年备受关注。研究人员已经开始利用 LLMs 广泛的知识储备和卓越的生成能力，探索文本到 SQL 的潜力[7, 9]。这些方法通常涉及在 SQL 生成过程中指导专有 LLM 的提示工程[47]，或在文本到 SQL 数据集上微调开源 LLM[9]。

在文本到 SQL 中整合 LLM 仍然是一个新兴的研究领域，具有进一步探索和改进的巨大潜力。研究人员正在研究如何更好地利用 LLM 的知识和推理能力、结合特定领域的知识 [31, 33 ]，以及开发更高效的微调策略 [ 10 ]。随着该领域的不断发展，预计将开发出更先进、更优秀的基于 LLM 的实现，从而将文本到 SQL 的性能和泛化能力提升到新的高度。

基准与评估

在本节中，本文将介绍文本转 SQL 的基准，包括众所周知的数据集和评估指标。

A.数据集

如表 I 所示，将数据集分为 “原始数据集 ”和 “注释后数据集”。根据数据集是与原始数据集和数据库一起发布的，还是通过对现有数据集和数据库进行特殊设置而创建的，将数据集分为 “原始数据集 ”和 “注释后数据集”。对于原始数据集，提供了详细分析，包括示例数量、数据库数量、每个数据库的表数量以及每个数据库的行数量。对于经过标注的数据集，确定了它们的源数据集，并描述了对它们应用的特殊设置。为了说明每个数据集的潜在机会，根据其特点对其进行了注释。注释列于表 I 的最右侧。下面将详细讨论。

1）跨领域数据集：指不同数据库的背景信息来自不同领域的数据集。由于现实世界的文本到 SQL 应用程序通常涉及来自多个领域的数据库，因此大多数原始文本到 SQL 数据集 [13,14,33 – 36] 和后注释数据集 [37 –43] 处于交叉状态- 域名设置，很好的契合跨域应用的需求。

2) 知识增强数据集：近年来，将特定领域知识纳入文本到 SQL 任务的兴趣显著增加。BIRD [ 33 ] 利用人类数据库专家为每个文本到 SQL 样本注释外部知识，这些知识分为数字推理知识、领域知识、同义词知识和价值说明。类似地，Spider-DK [ 39] 为人工编辑版本的Spider数据集[13]：SELECT列被省略，需要简单的推理，单元格值词中的同义词替换，一个非单元格值词生成一个条件，并且容易与其他域冲突。两项研究都发现，人工注释的知识显着提高了需要外部领域知识的样本的 SQL 生成性能。此外，SQUALL [44] 手动注释 NL 问题中的单词与 SQL 中的实体之间的对齐，提供比其他数据集更细粒度的监督。

3）上下文相关的数据集：SParC [43]和CoSQL [35]通过构建会话数据库查询系统来探索上下文相关的SQL生成。与传统的文本到 SQL 数据集只有一个示例的单个问题 SQL 对不同，SParC 将 Spider 数据集中的问题 SQL 示例分解为多个子问题 SQL 对，以构建模拟且有意义的交互，包括有助于 SQL 生成的相互关联的子问题，以及增强数据多样性的不相关的子问题。相比之下，CoSQL 涉及自然语言的对话交互，模拟现实世界的场景以增加复杂性和多样性。此外，Spider-SS&CG[38]将Spider数据集[13]中的NL问题拆分为多个子问题和子SQL，证明对这些子示例进行训练可以提高文本到SQL系统的泛化能力分布样本。

4) 稳健性数据集：在数据库内容（如模式和表）受到污染或扰乱的情况下评估文本到 SQL 系统的准确性对于评估鲁棒性至关重要。Spider-Realistic [ 41] 从 NL 问题中删除了明确的模式相关词汇，而 Spider-SYN [ 40] 则用人工选择的同义词替换了这些词汇。ADVETA [ 37 ] 引入了对抗性表扰动（adversarial table perturbation，ATP），通过用误导性替代词替换原始列名，并插入语义关联度高但语义等价性低的新列来扰动表。这些扰动会导致准确率大幅下降，因为鲁棒性较低的文本到 SQL 系统可能会被 NL 问题中的标记与数据库实体之间的错误匹配所误导。

5) 跨语言数据集：SQL 关键字、函数名、表名和列名通常以英文书写，这给其他语言的应用带来了挑战。CSpider [ 42 ] 将 Spider 数据集翻译成中文，发现了单词分割和中文问题与英文数据库内容之间跨语言匹配的新挑战。DuSQL [34] 引入了一个实用的文本到 SQL 数据集，其中包含中文问题和中英文数据库内容。

B.评测指标

为文本到 SQL 任务介绍了以下四种广泛使用的评估指标：基于 SQL 内容匹配的 “组件匹配 ”和 “精确匹配”，以及基于执行结果的 “执行准确性 ”和 “有效效率分数”。

1) 基于内容匹配的指标：SQL 内容匹配度量主要是根据预测的 SQL 查询与基本真实 SQL 查询在结构和语法上的相似性进行比较。

组件匹配（CM）[13] 通过使用 F1 分数测量预测 SQL 组件（SELECT、WHERE、GROUP BY、ORDER BY 和 KEYWORDS）与真实 SQL 组件（GROUP BY、ORDER BY 和 KEYWORDS）之间的精确匹配，评估文本到 SQL 系统的性能。每个组件被分解为若干子组件集，并在考虑无顺序限制的 SQL 组件的情况下，比较是否完全匹配。

精确匹配（EM）[ 13] 测量的是预测 SQL 查询与地面实况 SQL 查询完全相同的示例百分比。预测的 SQL 查询只有在其所有组成部分（如 CM 中所述）与地面实况查询的组成部分完全匹配时，才被认为是正确的。

2）基于执行的指标：执行结果指标通过比较在目标数据库上执行查询所获得的结果与预期结果，来评估生成的 SQL 查询的正确性。

执行准确度（EX）[13] 通过在相应数据库中执行预测的 SQL 查询，并将执行结果与基本真实查询所获结果进行比较，来衡量该查询的正确性。

有效效率分数（VES）[33] 的定义是测量有效 SQL 查询的效率。有效 SQL 查询是指执行结果与基本真实结果完全一致的预测 SQL 查询。具体来说，VES 同时评估预测 SQL 查询的效率和准确性。对于包含 N 个示例的文本数据集，VES 的计算公式为：

R（Y_n, Y_n）表示预测的 SQL 查询与真实查询相比的相对执行效率。

最近大多数基于 LLM 的文本到 SQL 研究都集中在这四个数据集：Spider [13]、Spider-Realistic [41]、Spider-SYN [40] 和 BIRD [33]；而这三种评估方法：EM、EX、VES，在下面的分析中将重点关注这三种评估方法。

方法

当前基于LLM的应用程序的实现主要依赖于上下文学习（ICL）（即时工程）[87-89]和微调（FT）[90,91]范式，因为强大的专有模型和架构良好的开源模型正在大量发布[45,86,92-95]。基于 LLM 的文本到 SQL 系统遵循这些范例进行实现。在本次调查中，将相应地讨论它们。

A. 上下文学习

通过广泛和公认的研究，提示工程已被证明对 LLM 的性能起着决定性作用 [28 , 96 ]，同时也影响着不同提示风格下的 SQL 生成 [9 , 46]。因此，在上下文学习（ICL）范例中开发文本到 SQL 方法对于实现有希望的改进非常有价值。生成可执行 SQL 查询 Y 的基于 LLM 的文本到 SQL 过程的实现可表述为：

在上下文学习（ICL）范式中，利用现成的文本到 SQL 模型（即模型的参数 θ 被冻结）来生成预测的 SQL 查询。基于 LLM 的文本到 SQL 任务采用了 ICL 范式中各种精心设计的方法。将它们分为 C0:4 五类，包括 C0-简单提示、C1-分解、C2-提示优化、C3-推理增强和 C4-执行细化。表 II 列出了各类方法的代表。

C0-Trivial Prompt：通过海量数据的训练，LLM 在不同的下游任务中对零样本和少量的提示具有很强的整体熟练度 [90 , 97, 98 ]，这在实际应用中得到了广泛的认可和应用。在调查中，将上述没有精心设计框架的提示方法归类为琐碎提示（虚假提示工程）。如上文所述，式 3 描述了基于 LLM 的文本到 SQL 的过程，它也可以表示零样本提示。通过连接 I、S 和 Q，可以得到整体输入 P0：

为了规范提示过程，OpenAI demo2 被设置为文本转 SQL 的标准（简单）提示 [30]。

零样本：许多研究工作[7,27,46]利用零样本提示，主要研究提示构造风格和各种LLM对文本到SQL的零样本性能的影响。作为一项实证评估，[7] 评估了不同早期开发的 LLM [85、99、100] 的基线文本到 SQL 功能以及不同提示风格的性能。结果表明，即时设计对于性能至关重要，通过错误分析，[7]提出更多的数据库内容会损害整体准确性。由于 ChatGPT 在对话场景和代码生成方面具有令人印象深刻的功能 [101]，[27] 评估了其文本到 SQL 的性能。通过零样本设置，结果表明，与最先进的基于 PLM 的系统相比，ChatGPT 具有令人鼓舞的文本到 SQL 性能。为了公平可比性，[47]揭示了基于LLM的文本到SQL的有效提示构造；他们研究了不同风格的提示构造，并根据比较得出了零样本提示设计的结论。

主键和外键携带不同表的连续知识。[49]研究了它们的影响，将这些键纳入不同数据库内容的各种提示样式中，分析零样本提示结果。一项基准评估[9]也研究了外键的影响，其中有五种不同的提示表示风格，每种风格都可视为指令、规则含义和外键的排列组合。除了外键之外，本研究还探索了零样本提示与 “无解释 ”规则暗示相结合的方式，以收集简洁的输出。在人类专家外部知识注释的支持下，[33 ]沿用了标准提示，并通过结合所提供的注释甲骨文知识实现了改进。

随着开源 LLM 的爆炸式增长，根据类似的评估结果，这些模型也能够胜任零样本文本到 SQL 的任务[45, 46, 50]，尤其是代码生成模型[46, 48]。对于零样本提示优化，[46] 提出了为 LLMs 设计有效提示模板的挑战；以前的提示构造缺乏结构统一性，这使得很难找出提示构造模板中影响 LLMs 性能的具体元素。为了解决这一难题，他们研究了一系列更加统一的提示模板，并用不同的前缀、后缀和前后缀进行调整。

少量提示：少量提示技术在实际应用和精心设计的研究中都得到了广泛应用，它已被证明能有效地提高 LLM 的性能 [ 28 , 102 ]。基于 LLM 的文本到 SQL 的少量提示方法的整体输入提示可表述为公式 3 的扩展：

作为实证研究，针对文本到 SQL 的少数几次提示在多个数据集和各种 LLM 中进行了评估 [8 , 32]，在与零样本提示的比较中表现出了良好的性能。[33] 提供了一个单次触发文本到 SQL 模型以生成准确 SQL 的详细示例。[55] 研究了少量示例数量的影响。[52] 通过研究不同示例之间的相似性和多样性，将随机抽样设为基准，并评估不同的策略 8 及其组合进行比较，重点关注抽样策略。此外，在基于相似性的选择之上，[9]评估了掩蔽问题相似性选择和具有各种数量的少样本示例的相似性方法的上限。困难级别样本选择的研究 [51] 将小样本 Codex [100] 的性能与难度分类数据集 [13, 41] 上的小样本实例的随机选择和基于难度的选择进行了比较。根据不同难度级别的所选样本数量，设计了三种基于难度的选择策略。[49]利用混合策略来选择样本，该策略结合了静态示例和基于相似性的动态示例来进行少量提示。在他们的设置中，他们还评估不同输入模式样式以及各种静态和动态样本数的影响。

跨域少量示例的影响也在研究之中 [54 ]。当纳入不同数量的域内和域外示例时，域内示例的表现优于零次示例和域外示例，随着示例数量的增加，域内示例的表现也会更好。为了探索输入提示的详细构造，[53] 比较了简洁提示和冗长提示的设计方法。前者将模式、列名、主键和外键按条拆分，后者则将其组织为自然语言描述。

C1-Decomposition：作为一种直观的解决方案，将具有挑战性的用户问题分解为更简单的子问题或使用多组件来实现，可以降低整个文本到 SQL 任务的复杂性 [8，51]。处理复杂度较低的问题，LLM 有可能生成更准确的 SQL。基于 LLM 的文本到 SQL 的分解方法分为两种范式：(1) 子任务分解，通过将整个文本到 SQL 任务分解为更易于管理的有效子任务（如模式链接 [71 ]、域分类 [54 ]），提供额外的解析以协助最终 SQL 生成。(2) 子问题分解：将用户问题分解为子问题，以降低问题的复杂度和难度，然后通过解决这些问题生成子 SQL，从而推导出最终的 SQL 查询。

DIN-SQL[8]提出了一种分解式上下文学习方法，包括四个模块：模式链接、分类与分解、SQL生成和自我修正。DIN-SQL 首先生成用户问题与目标数据库之间的模式链接；随后的模块将用户问题分解为相关的子问题，并进行难度分类。根据上述信息，SQL 生成模块生成相应的 SQL，自校正模块识别并纠正预测 SQL 中的潜在错误。这种方法将子问题分解视为子任务分解的一个模块。Coder-Reviewer[56]框架提出了一种重新排序方法，将生成指令的Coder模型和评估指令可能性的Reviewer模型结合起来。

参考Chain-of-Thought[103]和Least-to-Most提示[104]，QDecomp[51]引入了问题分解提示，它遵循从least-to-most提示中的问题还原阶段，并指示LLM进行分解原始复杂问题作为中间推理步骤

C3 [ 30 ] 由三个关键部分组成：清晰的提示、校准偏差提示和一致性；这些部分通过为 ChatGPT 分配不同的任务来实现。首先，清晰提示组件生成模式链接和经过提炼的问题相关模式作为清晰提示。然后，利用有关文本到 SQL 提示的多轮对话作为校准偏差提示，与清晰提示相结合，指导 SQL 生成。生成的 SQL 查询通过一致性和基于执行的投票进行筛选，以获得最终的 SQL。

MAC-SQL[57]提出了一个多代理协作框架；文本到 SQL 的过程是在选择器、分解器和精炼器等代理的协作下完成的。选择器为用户问题保留相关表格；分解器将用户问题分解为子问题并提供解决方案；最后，Refiner 验证并优化有缺陷的 SQL。

DEA- SQL [58] 引入了一种工作流程范式，旨在通过分解提高基于 LLM 的文本到 SQL 的注意力和问题解决范围。该方法对整体任务进行分解，使 SQL 生成模块具有相应的前提（信息确定、问题分类）和后续（自我修正、主动学习）子任务。工作流范式使 LLM 能够生成更准确的 SQL 查询

SGU-SQL [ 32 ] 是一个结构到 SQL 框架，利用固有的结构信息协助 SQL 生成。具体来说，该框架分别为用户问题和相应数据库构建图结构，然后使用编码图构建结构链接 [105 , 106]。元运算符用语法树分解用户问题，最后用 SQL 中的元运算符设计输入提示。

MetaSQL [ 59 ] 为 SQL 生成引入了三阶段方法：分解、生成和排序。分解阶段使用语义分解和元数据组合来处理用户问题。将先前处理过的数据作为输入，使用元数据条件生成的文本到 SQL 模型生成一些候选 SQL 查询。最后，应用两阶段排序管道得到全局最优 SQL 查询。

PET-SQL [ 60 ] 提出了一个提示增强型两阶段框架。首先，精心设计的提示指示 LLM 生成初步 SQL（PreSQL），其中根据相似性选择一些少量演示。然后，根据 PreSQL 找到模式链接，并将其结合起来，以提示 LLM 生成最终 SQL (FinSQL)。最后，利用多个 LLM 生成 FinSQL，根据执行结果确保一致性。

C2-Prompt Optimization：正如之前所介绍的，用于提示 LLM 的少数几次学习已被广泛研究[85]。对于基于 LLM 的文本到 SQL（text-to-SQL）和上下文学习，微不足道的少次元方法取得了可喜的成果[8, 9, 33]，进一步优化少次元提示有可能获得更好的性能。由于在现成的 LLM 中生成 SQL 的准确性在很大程度上取决于相应输入提示的质量[107]，因此影响提示质量的许多决定性因素成为当前研究的重点[9]（例如，少量提示组织的质量和数量、用户 9 问题与少量提示实例之间的相似性、外部知识/提示）。

DESEM [ 62 ] 是一个具有去语义化和骨架检索功能的提示工程框架。该框架首先采用特定领域的词语屏蔽模块，去除用户问题中保留意图的语义标记。然后，它利用一个可调整的提示模块，检索与问题意图相同的少量示例，并结合模式相关性过滤来指导 LLM 的 SQL 生成。

QDecomp [ 51 ] 框架引入了 InterCOL 机制，以增量方式将分解的子问题与相关的表和列名称结合起来。通过基于难度的选择，QDecomp 的少量示例都是经过难度抽样的。除了相似性-多样性抽样，[ 52 ]还提出了 SD+SA+投票（相似性-多样性+模式增强+投票）抽样策略。他们首先利用语义相似性和 k-Means 聚类多样性对少量示例进行采样，然后利用模式知识（语义或结构增强）对提示进行增强。

C3 [ 30 ] 框架由一个清晰提示组件和一个提供提示的校准组件组成，前者将问题和模式作为 LLMs 的输入，后者生成一个清晰提示，其中包括一个去除与用户问题无关的冗余信息的模式和一个模式链接。LLM 将其组成作为用于 SQL 生成的上下文增强提示。检索增强框架引入了样本感知提示[64]，该框架简化了原始问题，并从简化的问题中提取问题骨架，然后根据骨架的相似性在存储库中完成样本检索。检索到的样本与原始问题相结合，进行少量提示。

ODIS [54]引入了使用域外演示和域内合成数据的样本选择，它从混合来源检索少量演示，以增强提示表征

DAIL- SQL[9]提出了一种新方法来解决少量示例的采样和组织问题，在少量示例的质量和数量之间实现了更好的平衡。DAIL Selection 首先屏蔽了用户和少量示例问题中的特定领域词汇，然后根据嵌入的欧氏距离对候选示例进行排序。同时，计算预预测 SQL 查询之间的相似度。最后，选择机制会根据预先设定的标准获得按相似度排序的候选例子。通过这种方法，可确保少量实例与问题和 SQL 查询都具有良好的相似性。

ACT-SQL[49]提出了根据相似度得分选择的动态示例。

FUSED[65]提出通过免人工的多次迭代合成来建立一个高多样性的演示库，以提高少拍演示的多样性。FUSED 的管道通过聚类对需要融合的演示进行采样，然后对采样的演示进行融合以构建演示池，从而提高少数几次学习的效果。

Knowledge-to-SQL [31] 框架旨在构建数据专家 LLM（DELLM），为 SQL 生成提供知识。

DELLM 是通过使用人类专家注释进行有监督的微调[33]来训练的，并根据数据库的反馈通过偏好学习进一步完善。DELLM 生成四类知识，设计良好的方法（如 DAIL-SQL [9]、MAC-SQL [ 57 ]）结合生成的知识，通过上下文学习为基于 LLM 的文本到 SQL 实现更好的性能。

C3-Reasoning Enhancement：LLMs 在涉及常识推理、符号推理和算术推理的任务中表现出了良好的能力[108]。在文本到 SQL 的任务中，数字推理和同义词推理经常出现在现实场景中 [ 33 , 41 ]。LLMs 推理的提示策略有可能提高 SQL 生成能力。最近的研究主要集中在整合设计良好的推理增强方法用于文本到 SQL 的适应，改进 LLMs 以应对需要复杂推理的复杂问题的挑战3 以及 SQL 生成的自一致性。

思维链（Chain-of-Thoughts，CoT）提示技术[103]包含一个全面的推理过程，可以引导 LLM 进行精确推理，激发 LLM 的推理能力。基于 LLM 文本到 SQL 的研究利用 CoT 提示作为规则暗示[9]，在提示构建中设置了 “让我们一步步思考 ”的指令[9, 32, 33, 51]。然而，直截了当的（原始）CoT 策略在文本到 SQL 任务中并没有表现出在其他推理任务中的潜力；对 CoT 的适应性研究仍在进行中[51]。由于 CoT 提示总是使用带有人工注释的静态示例进行演示，这就需要通过经验判断来有效选择少量的示例，而人工注释也是必不可少的。

作为一种解决方案，ACT-SQL [ 49] 提出了一种自动生成 CoT 示例的方法。具体来说，ACT-SQL 给定一个问题，截断问题的片段集，然后枚举相应 SQL 查询中出现的每一列。每一列都将通过相似性函数与其最相关的切片联系起来，并附加到 CoT 提示中。

QDecomp [51] 通过对结合 CoT 提示增强 LLMs SQL 生成的系统性研究，提出了一个新颖的框架，以解决 CoT 如何提出预测 SQL 查询的推理步骤这一难题。该框架利用 SQL 查询的每个片段来构建 CoT 推理的逻辑步骤，然后使用自然语言模板来阐述 SQL 查询的每个片段，并将它们按逻辑执行顺序排列。

Least-to-Most [ 104 ] 是另一种提示技术，它将问题分解成子问题，然后按顺序解决。作为迭代提示，试点实验[51]表明，文本到 SQL 解析可能不需要这种方法。使用详细的推理步骤往往会产生更多的错误传播问题。

作为 CoT 的一种变体，Program-of-Thoughts（PoT）提示策略[109] 被提出来增强 LLM 的算术推理能力。

通过评估[55]，PoT增强了SQL生成的LLM，特别是在复杂的数据集中[33]。

SQL-CRAFT [ 55 ] 被提出来增强基于 LLM 的 SQL 生成，它结合了用于 Python 增强推理的 PoT 提示。PoT 策略要求模型同时生成 Python 代码和 SQL 查询，强制模型将 Python 代码纳入其推理过程。

Self-Consistency[110] 是一种提高 LLM 推理能力的提示策略，它利用了这样一种直觉，即一个复杂的推理问题通常允许多种不同的思维方式，从而得出唯一的正确答案。在文本到 SQL 任务中，自一致性适用于对一组不同的 SQL 进行采样，并通过执行反馈对一致的 SQL 进行投票 [30 , 53 ]。

同样，SD+SA+Voting [52] 框架会剔除那些由确定性数据库管理系统（DBMS）识别出的执行错误，并选择获得多数票的预测。

此外，在最近关于利用工具扩展 LLM 功能的研究的推动下，FUXI [66] 被提出通过有效调用精心设计的工具来增强 LLM 的 SQL 生成。

C4-Execution Refinement：在设计准确生成 SQL 的标准时，优先考虑的始终是生成的 SQL 能否成功执行并检索到内容，从而正确回答用户问题 [ 13 ]。作为一项复杂的编程任务，一次性生成正确的 SQL 非常具有挑战性。直观地说，在 SQL 生成过程中考虑执行反馈/结果有助于与相应的数据库环境保持一致，从而允许 LLM 收集潜在的执行错误和结果，以完善生成的 SQL 或进行多数表决[30]。文本到 SQL 中的执行感知方法主要通过两种方式纳入执行反馈：

1) 通过第二轮提示重新生成反馈，对于初始响应中生成的每个 SQL 查询，都将在相应的数据库中执行，从而获得数据库的反馈。这些反馈可能是错误，也可能是结果，这些结果将被附加到第二轮提示中。通过在上下文中学习这些反馈，LLM 能够完善或重新生成原始 SQL，从而提高准确性。

2) 对生成的 SQL 使用基于执行的选择策略，从 LLM 中抽样多个生成的 SQL 查询，并在数据库中执行每个查询。根据每个 SQL 查询的执行结果，使用选择策略（如自一致性、多数票[60]）从 SQL 集中定义一个满足条件的 SQL 查询，作为最终预测的 SQL。

MRC-EXEC [ 67 ] 提出了一种带有执行功能的自然语言到代码（NL2Code）翻译框架，该框架对每个采样 SQL 查询进行排序，并根据贝叶斯风险（Bayes risk）选择执行结果最小的示例 [111]。LEVER [68] 提出了一种通过执行验证 NL2Code 的方法，利用生成和执行模块分别收集 SQL 集样本及其执行结果，然后使用学习验证器输出正确性概率。

与此类似，SELF-DEBUGGING [ 48] 框架也是通过少量演示来教 LLM 调试其预测的 SQL。该模型能够通过调查执行结果并用自然语言解释生成的 SQL 来修正错误，无需人工干预。

如前所述，为了将精心设计的框架与执行反馈结合起来，广泛使用了两阶段含义：1. 对一组 SQL 查询进行采样。2. 多数表决（自洽）。具体来说，C3[30]框架消除了错误并识别出最一致的SQL；检索增强框架[64]引入了动态修订链，将细粒度的执行消息与数据库内容相结合，以提示法学硕士将生成的SQL查询转换为自然语言解释；要求法学硕士找出语义差距并修改他们自己生成的 SQL。尽管模式过滤方法增强了 SQL 生成，但生成的 SQL 可能无法执行。DESEM [62] 合并了一个后备修订版来解决该问题；它根据不同类型的错误修改并重新生成SQL库，并设置终止条件以避免循环。DIN-SQL [8] 在其自我修正模块中设计了通用且温和的提示；通用提示要求法学硕士识别并纠正错误，温和提示要求模型检查潜在问题。

多代理框架MAC-SQL[57]包括一个精炼代理，它能够检测并自动纠正SQL错误，采用SQLite错误和异常类来重新生成固定的SQL。由于不同的问题可能需要不同数量的修订，SQL-CRAFT [55]框架引入了交互式校正和自动控制确定过程，以避免校正过度或校正不足。 FUXI [66]考虑了基于工具的 SQL 生成推理中的错误反馈。 Knowledge-to-SQL [31] 引入了一个偏好学习框架，将数据库执行反馈与直接偏好优化 [112] 相结合，以改进所提出的 DELLM。PET-SQL[60]提出了交叉一致性，它包括两种变体：1）朴素投票：指示多个LLM生成SQL查询，然后根据不同的执行结果利用多数票决定最终的SQL；2）细粒度投票：根据难度级别细化朴素投票，以减轻投票偏差。。

B. Fine-tuning

由于监督微调（SFT）是 LLMs 训练的主流方法[29, 91]，对于开源 LLMs（如 LLaMA-2 [94 ], Gemma [113]）而言，使模型快速适应特定领域的最直接方法是使用收集的领域标签对模型执行 SFT。SFT 阶段通常是精心设计的训练框架的初始阶段[112, 114]，也是文本到 SQL 的微调阶段。SQL 查询 Y 的自动回归生成过程可表述如下：

SFT 方法也是文本到 SQL 的虚构微调方法，在文本到 SQL 的研究中已被各种开源 LLM 广泛采用 [9, 10 , 46 ]。与上下文学习（ICL）方法相比，微调范式更倾向于基于 LLM 的文本到 SQL 的起点。目前，已经发布了几项探索更好的微调方法的研究。将设计良好的微调方法按其机制分为不同的组，如表 IV所示：

增强型架构：广泛使用的生成式预训练变换器（GPT）框架利用仅解码器的变换器架构和传统的自动回归去编码来生成文本。最近对 LLM 效率的研究揭示了一个共同的挑战：在使用自动回归模式生成长序列时，由于需要加入注意力机制，LLM 的延迟很高 [115 , 116 ]。在基于 LLM 的文本到 SQL 中，生成 SQL 查询的速度与传统语言建模相比明显较慢 [21 , 28 ]，这成为构建高效本地 NLIDB 的挑战。作为解决方案之一，CLLM [ 69 ]旨在通过增强的模型架构应对上述挑战，并加快 SQL 生成速度。

数据增强：在微调过程中，影响模型性能的最直接因素是训练标签的质量[117]。低质量或缺乏训练标签下的微调是“巧妇难为无米之炊”，使用高质量或增强数据进行微调总是超越在低质量或原始数据上精心设计的微调方法[29, 74]。文本到 SQL 的数据增强微调取得了实质性进展，重点是提高 SFT 过程中的数据质量。

[117] “Learning from noisy labels with deep neural networks: A survey,”

[74] Recent advances in text-to-SQL: A survey of what we have and what we expect

[29] “A survey of large language models”

DAIL-SQL [9] 被设计为上下文学习框架，利用采样策略来获得更好的少样本实例。将采样实例纳入 SFT 流程可提高开源 LLM 的性能。Symbol-LLM [50]提出了数据增强指令调整的注入和注入阶段。CodeS [10] 在 ChatGPT 的帮助下通过双向生成增强了训练数据。StructLM [70]接受多种结构知识任务的训练，以提高整体能力。

预训练：预训练是整个微调过程的基础阶段，旨在通过在大量数据上进行自动回归训练来获得文本生成能力[118]。传统上，目前功能强大的专有 LLM（如 ChatGPT [119]、GPT-4 [86]、Claude [120]）都是在混合语料库上进行预训练的，而混合语料库主要受益于显示文本生成能力的对话场景 [85]。针对特定代码的 LLM（如 CodeLLaMA [ 121 ]、StarCoder [ 122 ]）是在代码数据上预先训练的[100 ]，各种编程语言的混合使 LLM 能够生成符合用户指令的代码[123 ]。作为代码生成的子任务，针对 SQL 的预训练技术面临的主要挑战是，SQL/数据库相关内容只占整个预训练语料的一小部分。

因此，综合能力相对有限的开源 LLM（与 ChatGPT、GPT-4 相比）在预训练过程中无法很好地理解如何将 NL 问题转换为 SQL。CodeS [10] 模型的预训练阶段包括三个阶段的增量预训练。从基本的特定代码 LLM [122 ] 开始，CodeS 在混合训练语料库（包括 SQL 相关数据、NL-to-Code 数据和 NL 相关数据）上进行增量预训练。文本到 SQL 的理解能力和性能得到了显著提高。

分解：将任务分解为多个步骤或使用多个模型来解决任务是解决复杂场景的直观解决方案，正如之前在第 IV-A 章中介绍的 ICL 范式。基于 ICL 的方法中使用的专有模型有大量参数，与微调方法中使用的开源模型的参数级别不同。这些模型本身就有能力很好地完成分配的子任务（通过少样本学习等机制）[30, 57]。因此，要在 ICL 方法中复制这种范式的成功，就必须合理地为开源模型分配相应的子任务（如生成外部知识、模式链接和提炼模式），以便针对特定子任务进行微调，并构建相应的数据用于微调，从而协助最终 SQL 的生成。

DTS-SQL [71] 提出了一个两阶段分解的文本到 SQL 微调框架，并在最终 SQL 生成之前设计了一个模式链接 12 预生成任务。

期望

尽管文本到 SQL 研究取得了重大进展，但仍然存在一些需要解决的挑战。在本节中，将讨论期望在未来工作中克服的剩余挑战。

A.实际应用中的稳健性

由 LLMs 实现的文本到 SQL，有望在现实世界的复杂应用场景中实现通用性和鲁棒性。尽管最近在鲁棒性特定数据集方面取得了实质性进展[ 37 , 41]，但其性能仍然无法满足实际应用的需要[ 33]。在未来的研究中，仍有一些挑战需要克服。从用户方面来看，存在这样一种现象，即用户并不总是一个明确的问题提出者，这意味着用户的问题可能不具有准确的数据库值，也可能与标准数据集不同，同义词、错别字和模糊表达都可能被包含在内[40]。

例如，在微调范例中，模型是在具有具体表达的明确指示性问题上进行训练的。由于模型没有学习现实问题与相应数据库的映射，因此在应用于真实世界场景时会出现知识缺口[33]。正如对带有同义词和不完整指令的数据集进行的相应评估所报告的那样[7 , 51]，由 ChatGPT 生成的 SQL 查询包含约 40% 的错误执行，比原始评估低 10%[51]。同时，使用本地文本到 SQL 数据集进行的微调可能包含非标准化的样本和标签。例如，表或列的名称并不总是其内容的准确表述，这就导致了训练数据构造中的不一致性。

B.计算效率

计算效率由推理速度和计算资源成本决定，这在应用和研究工作中都值得考虑[49, 69]。随着最新的文本到 SQL 基准测试中数据库的复杂性不断增加 [15, 33]，数据库将承载更多信息（包括更多的表和列），数据库schema的token长度也会相应增加，带来一系列的挑战。在处理超复杂数据库时，将相应的模式作为输入可能会遇到这样的挑战，即调用专有 LLM 的成本将显著增加，有可能超过模型的最大标记长度，尤其是在实现上下文长度较短的开源模型时。

同时，另一个明显的挑战是，大多数研究都使用完整的模式作为模型输入，这就带来了大量冗余[57]。直接从用户端为 LLM 提供与问题相关的精确过滤模式以降低成本和冗余是提高计算效率的潜在解决方案[30]。设计一种精确的模式过滤方法仍是未来的发展方向。虽然上下文学习范式取得了可喜的准确性，但从计算效率的角度来看，设计良好的多阶段框架或扩展上下文方法增加了 API 调用的数量，从而提高了性能，但同时也导致了成本的大幅上升[8]。

在相关方法中[49]，应该仔细考虑性能和计算效率之间的权衡，设计一种具有较低应用程序接口成本的可比（甚至更好）上下文学习方法将是一种实际的实现方法，目前仍在探索之中。与基于 PLM 的方法相比，基于 LLM 的方法的推理速度明显较慢 [ 21, 28]。通过缩短输入长度和减少实现过程中的阶段数来加快推理速度，对于上下文学习范式来说是很直观的。对于局部 LLM，从起点出发[69]，可以研究更多的加速策略，在未来的探索中增强模型的架构。

为了应对这一挑战，根据意图偏差调整 LLM，并针对噪声场景设计训练策略，将有利于最近取得的进展。同时，现实应用中的数据量相对小于研究型基准。由于通过人工标注来扩展大量数据会产生高昂的人力成本，因此设计数据扩充方法以获得更多的问题-SQL 对将会在数据稀缺的情况下为 LLM 提供支持。此外，微调开源 LLM 对本地小规模数据集的适应性研究也有潜在益处。此外，在未来的研究中还应全面研究多语言[ 42 , 124 ]和多模式场景[ 125 ]的扩展，这将使更多语言群体受益，并有助于构建更通用的数据库接口。

C.数据隐私和可解释性

作为 LLM 研究的一部分，基于 LLM 的文本到 SQL 还面临着 LLM 研究中存在的一些普遍挑战 [4 , 126 , 127 ]。从文本到 SQL 的角度来看，这些挑战也会带来潜在的改进，从而对 LLM 的研究大有裨益。如前文第 IV-A 章所述，在最近的研究中，上下文学习范例在数量和性能上都占主导地位，大多数工作都使用专有模型来实现[8, 9]。在数据隐私方面提出了一个直接的挑战，因为调用专有应用程序接口来处理本地数据库的保密性可能会带来数据泄露的风险。使用局部微调范式可以部分解决这一问题。

尽管如此，目前 vanilla 微调的性能并不理想[9]，高级微调框架可能依赖于专有的 LLM 来进行数据扩充[10]。基于目前的现状，在文本到 SQL 的局部微调范式中，更多量身定制的框架值得广泛关注。总体而言，深度学习的发展始终面临着可解释性方面的挑战 [127 , 128 ]。

作为一项长期存在的挑战，为解决这一问题已经开展了大量研究 [ 129 , 130 ]。然而，在文本到SQL的研究中，基于LLM的实现的可解释性仍然没有被讨论，无论是在上下文学习中或微调范式。具有分解阶段的方法从逐步生成的角度解释了文本到 SQL 的实现过程[8, 51]。在此基础上，结合可解释性方面的高级研究[131, 132]来提高文本到 SQL 的性能，以及从数据库知识方面解释本地模型架构，仍然是未来的发展方向。

D.扩展

作为 LLM 和自然语言理解研究的一个子领域，这些领域的许多研究已被用于文本到 SQL 任务，推动了其发展 [103 , 110 ]。不过，文本到 SQL 的研究同时也可以扩展到这些领域的更大范围研究。例如，SQL 生成是代码生成的一部分。设计良好的代码生成方法在文本到 SQL 的过程中也能获得良好的性能[48, 68]，并能在各种编程语言中进行泛化。还可以讨论将一些定制的文本到 SQL 框架扩展到 NL 到代码研究的可能性。

例如，在 NL-to-code 中集成执行输出的框架也能在 SQL 生成中实现出色的性能[8]。将文本到 SQL 中的执行感知方法与其他推进模块[30, 31]扩展到代码生成中的尝试值得讨论。从另一个角度看，之前讨论过文本到 SQL 可以通过提供事实信息来增强基于 LLM 的问题解答（QA）。数据库可以存储作为结构信息的关系知识，基于结构的 QA 有可能从文本到 SQL 中受益（例如，基于知识的问题解答，KBQA [ 133 , 134 ]）。利用数据库结构构建事实知识，然后结合文本到 SQL 系统实现信息检索，这有可能帮助进一步的质量保证获得更准确的事实知识 [ 135 ]。预计在未来的工作中将会有更多文本到 SQL 的扩展研究。

OlaChat数智助手产品介绍

OlaChat数智助手是腾讯PCG大数据平台部利用大模型在数据分析领域内落地实践中推出的全新智能数据分析产品，目前已集成至DataTalk、OlaIDE等腾讯内部主流数据平台，为数据分析全流程场景提供智能支持。包含了text2sql、指标分析、SQL智能优化等一系列能力，从数据分析（拖拽分析、SQL 查询）、数据可视化，到结果解读与归因，OlaChat全面助力，让数据分析工作变得更加简单高效！