Text2SQL论文笔记 A Survey on Employing Large Language Models for Text-to-SQL Tasks

摘要

存储在关系数据库中的数据量不断增加，导致在各个领域中需要高效地查询和利用这些数据。然而，编写SQL查询需要专业知识，这对非专业用户来说是一个挑战，他们试图访问和查询数据库。文本到SQL解析通过将自然语言查询转换为SQL查询，解决了这一问题，从而使数据库访问对非专业用户更加友好。为了利用大型语言模型（LLMs）的最新进展，一系列新方法应运而生，主要集中在提示工程和微调上。本调查提供了LLMs在文本到SQL任务中的全面概述，讨论了基准数据集、提示工程、微调方法以及未来的研究方向。我们希望这篇综述能够帮助读者更广泛地理解该领域的最新进展，并提供一些关于其未来发展方向的见解。

介绍

在大数据时代，很大一部分数据存储在关系数据库中，这些数据库是各种组织数据管理系统的核心。随着数据量的不断增加，高效查询和利用这些数据的能力已成为提升各行业竞争力的关键因素。关系数据库需要使用SQL进行查询，但编写SQL需要专业知识，这为非专业用户查询和访问数据库设置了障碍。

文本到SQL解析是自然语言处理（NLP）领域中的一项成熟任务，其目的是将自然语言查询转换为SQL查询，从而弥合非专业用户与数据库访问之间的差距。例如，假设有一个名为cities的表，包含三列：city_name（类型：字符串）、population（类型：整数）和country（类型：字符串）。如果我们得到自然语言查询“查找美国人口超过100万的城市”，文本到SQL解析技术应自动生成正确的SQL查询。

SELECT city_name FROM cities WHERE population > 1000000 AND country = ’United States’.

研究人员在这一领域取得了显著进展。最初，基于模板(template-based)和基于规则(rule-based)的方法被采用，这些方法涉及为各种场景创建SQL模板。虽然基于模板的方法显示出潜力，但它们需要大量的手动工作。随着深度学习的快速发展，Seq2Seq方法已成为主流。Seq2Seq模型提供了一种端到端的解决方案，直接将自然语言输入映射到SQL输出，从而消除了语义解析或基于规则系统等中间步骤的需要。

在Seq2Seq方法中，预训练语言模型（PLMs），作为大型语言模型（LLMs）的前身，在文本到SQL任务中显示出潜力。得益于大规模语料库中的丰富语言知识，PLMs在那个时期成为最先进的解决方案。

随着模型规模和训练数据的不断增长，预训练语言模型自然演变为大型语言模型（LLMs），展现出更强大的能力。由于规模法则和其涌现能力，LLMs在聊天机器人、软件工程和代理等多个领域做出了重大贡献。LLMs的显著能力促使研究人员探索其在文本到SQL任务中的应用。图2展示了文本到SQL领域主流方法的演变，由SPIDER测试数据集中的执行准确性表示。当前文献主要关注LLMs的两种主要方法：提示工程和微调。提示工程利用RAG、少样本学习和推理等方法，而微调涉及在任务特定数据上训练LLM。提示工程和微调之间存在权衡，通常提示工程需要较少的数据，但可能导致次优结果，而微调可以提高性能，但需要更大的训练数据集。

本文旨在全面调查LLMs在文本到SQL任务中的应用。我们概述了LLMs的特性和相对于传统模型的优势，并在以下方面介绍了基于LLM的Text2SQL：

1. 文本到SQL基准数据集：我们强调，尽管之前的基准数据集在测试LLM能力方面仍有一定价值，但我们需要更具挑战性和现实性的基准数据集。我们总结了两个值得注意的基准数据集，即BIRD和Dr.Spider，它们在LLM广泛使用后创建，提供了大规模表模式和多样化扰动的新挑战。

2. 提示工程方法：在全面调查相关论文后，我们将文本到SQL的提示工程方法分为三个阶段：预处理、推理和后处理。预处理将处理问题和表模式的格式和布局。我们还特别介绍了预处理阶段的模式链接技术。在推理阶段，我们解释了基于LLM的文本到SQL方法如何在提供用户问题和相应数据库模式时生成相应的SQL查询。在最终的后处理阶段，我们介绍了如何在生成SQL查询后提高基于LLM的文本到SQL方法的性能和稳定性。

3. 微调方法：我们强调了微调方法对文本到SQL的重要性，并根据一般的微调过程将其分解为四个主要组成部分：数据准备、预训练模型选择、模型微调和模型评估。值得一提的是，除了对微调方法进行全面分析外，我们还强调了在数据准备和模型评估中利用LLM的潜力。

未来方向：我们讨论了在文本到SQL任务中应用LLMs的可能未来方向，如隐私问题、自主代理、复杂模式、基准测试和领域知识。

我们的目的是，这篇综述将成为该领域新人的宝贵资源，并为研究人员提供有价值的见解。

研究现状

大模型和基于大模型的Text2SQL

大型语言模型（LLMs）已成为自然语言处理和机器学习的里程碑。LLMs的概念源于不断扩大预训练语言模型（PLMs）的参数规模和训练数据量，从而产生了令人惊讶的能力，称为涌现能力，这些能力在小规模的PLMs中并不存在。一个涌现能力的例子是少样本学习，这意味着LLMs可以通过在提示中提供几个适当的任务演示来完成下游任务，而无需进一步训练。另一个例子是遵循指令的能力，LLMs已被证明能够对描述未见任务的指令做出适当响应。

由于LLMs的涌现能力和LLMs的基本操作原理，即根据输入提示逐步生成概率最高的下一个词，提示工程成为将LLMs应用于下游任务的两个主要流派之一。提示工程的代表方法包括检索增强生成（RAG）、少样本学习和推理。另一个流派是微调，它遵循PLMs的“预训练和微调”学习范式，旨在提升特定领域的性能并解决隐私问题。微调的一般过程主要包括数据准备、预训练模型选择、模型微调和模型评估。

文本到SQL是自然语言处理（NLP）和数据库社区中的一项具有挑战性的任务，涉及将给定关系数据库上的自然语言问题映射为SQL查询，这一任务也因LLMs的出现而发生了变革。我们在图1中总结了基于LLM的文本到SQL系统的通用框架。基于LLM应用的两个主要流派，我们将基于LLM的文本到SQL方法分为两类：提示工程和微调。对于提示工程方法，我们通常设计一个包含任务描述、表模式、问题和额外知识的结构化提示，并同时利用上下文学习和推理方法。对于微调方法，我们通常生成或收集文本到SQL数据集，选择合适的预训练LLMs和微调方法（如LORA），并比较微调前后的测试结果，以了解模型性能的变化。

传统方法和基于大模型的Text2SQL的方法对比

在LLMs广泛应用之前，文本到SQL方法主要有两种流派。一种流派是利用序列到序列（Seq2Seq）模型，其中编码器设计用于捕捉自然语言（NL）问题和相应表模式的语义，解码器则基于编码的问题表示逐个生成SQL查询令牌。这种方法中的一些著名方法包括IRNet、SQLNet、Seq2SQL、HydraNet、Ryansql、Resdsql和ISESL-SQL。另一种流派涉及微调预训练语言模型（如BERT），这些模型利用大规模文本集合中的广泛知识，并已被证明在提升下游文本到SQL解析任务的性能方面有效。

我们认为，传统文本到SQL方法与基于LLM的方法之间有两个显著的区别：

1. 新范式：传统文本到SQL方法需要训练，而LLMs通常可以绕过这一要求。利用LLMs的指令遵循能力，LLMs可以通过适当的指令和信息完成文本到SQL任务。

2. 统一架构：根据之前的调查，传统方法中的编码器和解码器可以使用多种架构设计，如LSTM、Transformer，甚至GNNs。相比之下，LLMs采用统一的基于Transformer的架构，这不仅便于扩展，还简化了实现过程。

为什么使用基于大模型的Text2SQL

近年来，用于文本到SQL任务的LLMs数量急剧增加。在对近期论文进行全面调查后，我们确定了这一趋势的几个关键原因，总结如下：

1. 性能提升：图2展示了文本到SQL领域主流方法的进展，由SPIDER测试数据集中的执行准确性表示。可以看到，基于LLM的方法显著提升了最先进（SOTA）性能，展示了基于LLM方法的显著能力。列出的参考文献支持这一观察。

2. 泛化能力和适应性：如上所述，LLMs引入了一种新范式，即提示工程，得益于其遵循指令的能力，使LLMs可以轻松转移到不同设置中，而无需额外训练。此外，LLMs的上下文学习能力进一步增强了其泛化和适应性，因为它们可以从提供的示例中学习，无缝适应各种设置。

3. 未来改进：基于LLM的方法具有令人期待的改进前景。由于全球社区优先考虑LLMs的增强，努力和资源集中在支持LLMs的研究上。这包括扩展LLMs、创建新的提示方法、生成高质量和广泛的数据集，以及在各种任务中微调LLMs。LLM社区的进展无疑将继续推动基于LLM的文本到SQL方法达到新的SOTA。

行业基准

高质量的数据集在文本到SQL任务的训练和测试中起着至关重要的作用。之前的基准数据集，如[17, 25–27, 62, 67, 86, 102–104, 113]，对文本到SQL领域的研究进展做出了重要贡献，尤其是在ChatGPT和GPT-4出现之前。然而，随着ChatGPT和GPT-4的引入，LLM开始广泛用于文本到SQL任务，从而不断提升了这些任务的最先进（SOTA）水平。例如，Spider数据集的SOTA（执行结果的准确性）从大约73%提高到了91.2%。

这些数据集不仅为研究人员提供了评估模型性能的标准，还推动了文本到SQL技术的不断进步。通过在高质量数据集上进行训练和测试，模型能够更好地理解和生成SQL查询，从而在实际应用中表现更出色。

在此，我们总结了两个在LLM广泛使用后诞生的值得注意的基准数据集：

BIRD：这是一个包含大规模表模式和多样化扰动的新基准数据集。BIRD旨在提供更具挑战性的任务，以评估模型在复杂和多样化环境中的性能。

Dr.Spider：这是另一个在LLM广泛使用后创建的新基准数据集，提供了新的挑战。Dr.Spider通过引入更复杂的查询和数据库模式，进一步推动了文本到SQL技术的发展。

这些新的基准数据集不仅为研究人员提供了更严格的测试标准，还帮助推动了文本到SQL领域的技术进步，确保模型在实际应用中能够高效、准确地执行任务。

BIRD

大多数数据集[17, 25–27, 62, 67, 86, 102–104, 113]专注于具有少量数据库值的数据库模式，这导致了学术研究与实际应用之间的差距。为了解决这一差距，[49]引入了BIRD数据集。BIRD数据集包含12,751个文本到SQL对和95个数据库，总大小为33.4 GB，涵盖37个专业领域。它还强调了新的挑战，包括脏数据和噪声数据库值、自然语言（NL）问题与数据库值之间的外部知识关联，以及SQL效率，特别是在大规模数据库的背景下。实验结果表明，即使是最有效的文本到SQL模型，如GPT-4，在执行准确性上也仅达到54.89%，远低于人类结果的92.96%，这证明挑战依然存在。

Dr.Spider

[9]指出，文本到SQL模型对任务特定的扰动很脆弱，但之前精心设计的鲁棒性测试集通常只关注个别现象。为了弥合这一差距，[9]引入了Dr.Spider数据集。基于Spider数据集，Dr.Spider设计了17种对数据库、自然语言问题和SQL查询的扰动，从多个角度衡量鲁棒性。为了收集更多样化的自然问题扰动，[9]利用大型预训练语言模型（PLMs）以少样本方式模拟人类在创建自然问题时的行为。实验结果表明，即使是最鲁棒的模型，整体性能也下降了14.0%，在最具有挑战性的扰动上性能下降了50.7%。

提示词工程

提示工程（Prompt Engineering），有时也称为上下文学习（In-Context Learning），是指构建LLM能够理解的指令。从开发者的角度来看，这意味着在与LLM交互时，通过设计提示词来定制LLM在特定任务上的输出。由于自回归解码特性，大多数LLM根据当前可见的所有前置文本（也称为上下文）来预测后续文本。我们将自回归解码描述为方程1，其中$y_t$表示LLM将输出的下一个令牌，$x$表示用户提供的提示令牌。提示词作为上下文的设计将影响所有即将到来的令牌的概率分布，从而影响最终的生成结果。
$$y_t=argmaxP(y_t|y_{1:t-1},x)$$
在对相关论文进行全面调查后，我们将文本到SQL的提示工程方法分为以下三个阶段：

• 预训练

在实际场景中，从事Text2SQL的专家经常被问题描述的不清晰和数据库模式的模糊性所困扰。这种情况同样适用于LLMs，并促使对Text2SQL问题进行预处理。我们的提示工程方法的预训练部分将包括三个部分：

1. 问题描述的抽象表示：将自然语言问题转换为更结构化和抽象的表示，以便LLM更好地理解。
2. 数据库模式的选择性链接：将问题中的实体与数据库模式中的表和列进行链接，以帮助LLM理解问题与数据库之间的关系。
3. 引入额外的SQL知识或外部知识：在提示中包含与问题相关的SQL知识或外部知识，以增强LLM生成正确SQL查询的能力。

• 推理阶段

所谓的推理阶段是指在提供用户问题和相应数据库模式时生成相应的SQL查询。这一阶段可以逻辑上分为两个部分：工作流程设计和演示使用。从预处理到SQL生成，大多数工作将设计其推理工作流程，要么采用自定义方式，要么基于推理模式，并决定是否使用演示。我们将从介绍文本到SQL的工作流程设计开始，包括著名的推理模式，如思维链（Chain-of-Thought）、从少到多（Least-to-Most）和分解（Decomposition）。之后，我们将介绍演示方法，包括零样本方法和少样本方法。在少样本部分，我们将强调演示风格和选择的重要性。

• 后处理

为了增强基于LLM的文本到SQL方法的性能和稳定性，可以选择在推理后进一步优化生成的结果。我们将这些操作称为后处理。常见的Text2SQL后处理方法包括自我修正（Self-Correction）和一致性方法（也称为自我一致性（Self-Consistency）和交叉一致性（Cross-Consistency））。

$$pred\_SQL=Post\_process(LLM(QuestionRepresentation,Demonstration,Reasoning))$$

预训练

在处理Text2SQL任务的初期，明确且全面地描述解决问题所需的所有信息至关重要。这些信息主要包含问题的表述格式、数据库模式以及一些与任务相关的知识。在预处理阶段，我们将对上述每个信息部分进行介绍。

问题表示(Question Representation)

在Text2SQL任务中的“问题”包含两个部分：自然语言的问题陈述和相关数据库的必要信息。最近的研究[3, 71]探讨了常见的问题表示方法和数据库结构。我们总结了这些表示的一些典型特征，并在下面进行描述。

布局(Layout)。一个特征是问题本身的书写风格和数据库结构，我们称之为问题的“布局”。两种著名的布局是Openai模板布局和“Create Table”布局，图4给出了它们的概览。

• Openai模板布局。一些研究[3, 21, 32, 51, 54, 57, 71, 80, 87]使用了Codex官方API文档中提供的Text2SQL任务的Openai提示模板。每个表的描述以SQLite的注释符号开头，后面跟着表的形式（列1，列2，…）。在完成表的描述后，最后一行提供SELECT关键字。示例格式如图左侧所示。

• “Create Table”布局。研究[10, 11, 29, 49, 63, 71]将数据库组织的提示词表示为CREATE TABLE创建语句，这在图的右侧进行了解释。在语句中明确包含每个列的数据类型以及可能的主键和外键关系，将使数据格式对齐，并在LLM生成SQL时执行多表连接。其他研究[12, 80, 94]使用了CREATE TABLE语句和部分数据来构建提示词，这更符合数据工程师编写SQL的实际情况。

样本数据。除了布局之外，来自真实数据库内容的样本数据也对问题表示有益。研究[71]将提示表示为“SELECT * FROM Table LIMIT X”语句及其执行结果，其中X是一个整数，通常根据经验取3。一些研究[3, 10, 11, 77, 94, 107]甚至直接将样本数据放入提示词中。目的是使LLM能够理解数据库中的样本数据，并在生成SQL时符合数据的格式。[8]修改了样本数据的格式，以列出按列的数据，以明确列举分类值。

混合方法。一些研究将布局设计和样本数据结合起来，以获得两者的优势。通用提示[3]将Openai模板和样本数据的提示词连接起来。LTMP-DA-GP[4]在CREATE TABLE语句后添加了分类列的随机抽样和数值列的范围信息。此外，[110]在提示中添加了一对多关系（一个表中的单条记录与另一个表中的多条记录相关联）和枚举值；[33, 45, 68, 78, 84]使用Table.Column的形式列出数据库模式；一些研究[10, 21, 29, 51, 63, 78, 94, 95, 107]也强调了主键或外键的描述，试图增加LLM对表之间关系的关注。

观察与启示。根据[3, 21, 29, 71, 80, 107, 110]中的实验，我们将讨论不同问题表示的性能观察，并分享一些启示。

• 布局。从布局的角度来看，[21]显示当从清晰和结构化的模式转变为非结构化的模式时，性能显著下降。当比较Openai模板和“Create Table”模板时，[29]声称前者略优于后者，而[80]则认为它们不相上下。

• 样本数据。[3, 71]提供了每种布局的性能统计数据，表明样本数据是可插拔的，并对其他布局有益。此外，[107]指出，更多的样本并不总是更好。

• 主键和外键。许多研究显示了主键和外键在问题表示中的重要性。[51, 95, 107]中的消融研究表明，移除外键会显著降低性能。SQLfuse[110]也将主键作为准确性提升的第二大贡献者。在DAIL-SQL[29]中，一些LLM在添加外键后表现出提升，而其他LLM则看到性能下降。

基于上述讨论，我们准备给出一些关于选择问题表示方法的启示：

• 结构化布局（如Openai模板和“Create Table”模板）优于非结构化布局，而不同的结构化布局在性能上相当。
• 样本数据是有效的、可插拔的，并且在上下文长度足够时值得考虑。
• 主键和外键具有显著影响，在复杂场景中是关键且适用的。

Schema Linking(模式链接)

“Schema Linking”更准确的翻译应该是“模式链接”或“模式关联”。这是因为“Schema Linking”指的是在自然语言处理任务中，特别是在从自然语言查询生成SQL语句的过程中，识别并建立自然语言中的实体与数据库模式（包括表和列）之间的对应关系。这个过程并不是指两个或多个表之间的连接操作（如SQL中的JOIN操作），而是指确定哪些数据库表和列与用户提出的自然语言查询相关联的过程。

在处理文本到SQL转换的问题时，经常会遇到涉及多个表中的多列的情况，但是每个表只使用特定的几列。然而，冗余或不相关的模式项可能会干扰大型语言模型（LLM）识别正确的项目，因此需要进行模式链接。模式链接是文本到SQL过程中的一个子任务，旨在指定数据库中与给定查询短语相对应的表和列。这一步骤对于基于LLM的文本到SQL管道来说至关重要，原因有两个。首先，它能减少输入的标记长度。一方面，对于大型数据库，将所有表的描述都作为提示输入给LLM是不切实际的。另一方面，通过缩短表模式的长度，我们可以潜在地提高LLM的注意力集中度和效率。其次，研究表明，基于LLM的文本到SQL转换失败的许多案例源于无法正确识别列名、表名或问题中提到的实体。通过利用模式链接技术，我们可以提高性能，甚至促进跨域泛化和复杂查询的合成。

在对近期基于LLM的文本到SQL论文中采用的模式链接技术进行了全面调查后，我们将这些技术分为两大类，即基于LLM的模式链接方法和传统模式链接方法。图5展示了我们调查的模式链接方法概览。

基于LLM的模式链接方法是指利用LLM执行模式链接任务的方法。主要有三种途径：虽然原文没有具体列出这三种途径，但根据上下文，可以推测它们可能包括直接使用预训练的LLM来匹配文本与数据库模式、通过微调LLM使其专门适应于模式链接任务、以及结合其他机器学习技术与LLM共同完成模式链接等方法。

• 针对模式链接设计特定步骤来提示LLMs。最简单的方法是直接提示LLMs执行模式链接，正如Divide-and-Prompt和Open-SQL所做的那样。为了进一步提高这种方式的性能，一些研究设计了更为复杂的路径，通过特定步骤来提示LLMs。C3将模式链接分解为两个步骤，首先是指示ChatGPT回忆出相关的表，然后在候选表中检索列。Reboost采用了与C3相同的方法，但通过包含查询描述和列解释来丰富表和列的选择。DEA-SQL探索了首先在查询中识别元素，然后利用这些元素过滤模式的方法。相反，CHESS遵循了一个“列过滤、表选择、最终列过滤”的三步范式。PET-SQL强调，相较于模式链接子任务，LLMs在编写SQL方面表现得更好，因此提出首先组成相应的SQL查询，然后再从这些查询中提取表和列。

简而言之，这些研究通过不同的方法来优化模式链接过程，有的通过简化提示，有的通过增加额外的信息帮助LLMs更好地理解任务需求，还有的则通过将任务分解为多个步骤来逐步引导LLMs完成模式链接。这些方法的共同目标都是提高LLMs在文本到SQL转换任务中的准确性和效率。

• 通过利用通用的LLM技术来增强基于LLM的模式链接性能。由于基于LLM的模式链接方法是由LLM驱动的，几项研究[21, 68, 80, 107, 110]探讨了通过利用诸如少样本学习（few-shot learning）、链式思维推理（chain-of-thought reasoning）、自我一致性投票（self-consistency voting）和微调（fine-tuning）等通用LLM技术来提升模式链接性能的方法。

  • DIN-SQL[68]随机选取一些示例来指导模式链接，并利用“让我们一步一步思考”来进一步提高性能。
  • C3[21]采用自我一致性（self-consistency）[88]技术来增强性能的稳定性。
  • QDecomp[80]和ACT-SQL[107]也使用少样本学习来指导模式链接，但更加注重示例构建。具体来说，给定一个子问题及其对应的SQL，他们会标注SQL中提到的所有表-列对作为真实标签。此外，ACT-SQL[107]还使用嵌入模型来识别短语与模式之间的关系，这些关系随后用于以链式思维风格构建示例。
  • 除了上述提示方法外，SQLfuse[110]采用微调技术来增强LLM的模式链接性能。

这些方法通过不同的技术手段来优化基于LLM的模式链接，旨在提高模式链接的准确性、稳定性和效率。无论是通过示例引导、思维链路、自我一致性检查还是模型微调，其核心目的都是让LLM能够更准确地理解自然语言查询与数据库模式之间的对应关系，从而生成更准确的SQL查询。

• 将LLM集成到传统的模式链接方法中。除了上述方法之外，还有另一种选择，即将LLM与传统的模式链接方法相结合。一个这样的例子是CRUSH4SQL[45]，该方法利用了LLM的幻觉能力。它首先根据给定的查询通过幻觉生成一个数据库模式，然后使用基于相似性的检索方法，以生成的模式作为参考来选择相关的模式。

具体来说，CRUSH4SQL的工作流程如下：

1. 幻觉生成阶段：基于给定的自然语言查询，LLM会“想象”或生成一个可能的数据库模式。这个阶段利用了LLM强大的生成能力和创造性，即使提供的信息有限，也能生成合理的假设模式。
2. 相似性检索阶段：生成的模式被用作参考，通过计算与现有数据库模式的相似度，来筛选出最相关的模式。这一阶段依赖于算法来评估不同模式之间的相似性，从而选择最符合查询要求的模式。

这种方法的优势在于，它结合了LLM的生成能力和传统模式链接方法的精确性，既能够利用LLM处理模糊或不完整信息的能力，又能够确保最终选择的模式具有较高的准确性。这种结合不仅提高了模式链接的灵活性和鲁棒性，也为解决复杂查询提供了新的思路。

• 传统模式链接方法指的是不依赖于LLM的模式链接技术。我们的深入分析显示，基于LLM的文本到SQL的研究论文主要利用了两种传统模式链接方法：

1. 相似性方法：

   • 相似性方法的基本思想是确定查询与模式信息之间的相似度，从而检索出最相似的模式。例如，De-semanticization[33]通过识别问题中每个词与模式中每个项目的直接匹配，以及识别问题词汇与特定数据库值之间的对应关系来计算相似度。

2. 连通性方法：

   • 除了相似性，连通性是另一个重要的考虑因素，因为使用的表和列之间应该存在某种关系或连接。一些最近的研究工作，如DBCopilot[87]、PURPLE[72]和SGU-SQL[109]，通过使用基于图的方法探索了这一概念。
     • DBCopilot[87] 首先构建一个图来表示所有数据库及其表的底层模式结构，然后训练一个Seq2Seq模型作为路由器，遍历大量数据库以获取一组模式。
     • PURPLE[72] 通过基于外键-主键连接创建图来增强检索到的相关模式的互连性。
     • SGU-SQL[109] 通过结合查询结构和数据库结构，基于查询中的主题概念、查询中的预定义关系、数据库模式以及模式中存在的表/列名称，构建查询-模式图。然后训练一个模型将查询节点与相应的模式节点绑定在一起。

这些方法各有优势，相似性方法适用于处理自然语言查询与数据库模式之间的直接匹配问题，而连通性方法则更侧重于捕捉表和列之间的关系，确保生成的SQL查询逻辑上的一致性和正确性。通过结合这两种方法，可以更有效地解决文本到SQL转换中的模式链接问题。

• 关键要点总结
  • 链式思维或分解推理是主流工作流程：
    大多数研究倾向于使用链式思维（Chain-of-Thought）或分解推理（decomposition reasoning）作为基础工作流程。这些方法通过将复杂任务分解为一系列更简单的子任务，逐步引导模型完成模式链接，从而提高准确性和可解释性。
  • 基于LLM的模式链接方法：
    主流的基于LLM的模式链接方法包括：
    特定步骤提示：通过设计特定的步骤来提示LLM，逐步引导其完成模式链接任务。例如，C3将模式链接分解为两个步骤，先回忆表再检索列；CHESS则采用“列过滤、表选择、最终列过滤”的三步范式。
  1. 利用通用LLM技术增强性能：通过使用少样本学习（few-shot learning）、链式思维推理（chain-of-thought reasoning）、自我一致性投票（self-consistency voting）和微调（finetuning）等通用LLM技术来提高模式链接的性能。例如，DIN-SQL通过随机选择示例和逐步思考来改进性能；C3使用自我一致性技术来增强性能稳定性；SQLfuse通过微调来提升LLM的模式链接性能。
  • 相似性和连通性都是值得考虑的因素：
  1. 相似性方法：通过计算查询与模式信息之间的相似度来检索相关模式。例如，De-semanticization通过识别问题词与模式项的直接匹配及问题词汇与数据库值之间的对应关系来计算相似度。
  2. 连通性方法：除了相似性，连通性也是重要的考虑因素，因为使用的表和列之间应该存在某种关系或连接。例如，DBCopilot通过构建图来表示数据库结构并训练模型进行路由；PURPLE通过基于外键-主键连接创建图来增强互连性；SGU-SQL通过结合查询结构和数据库结构来构建查询-模式图，并训练模型将查询节点与模式节点绑定。

4.1.3 知识库

除了问题表示和模式链接方法之外，为具有通用能力的LLM提供相关知识也是非常有益的。添加到提示中的知识可以被视为对当前任务描述的校准，为后续的SQL生成铺平道路。我们将知识分为两类：一类与SQL相关，另一类与问题本身和数据相关。

4.1.3 知识

SQL相关知识

SQL相关知识主要包括SQL关键字、SQL语法和常见的SQL编写习惯。向通用LLM的提示中添加SQL相关知识，就像为初级DBA提供了一本经验手册，可以避免语义错误。具体来说：

• C3[21] 特别校准了模型在SQL风格上的偏差，并在提示中添加了以下指令：

  • 只在特定情况下使用 COUNT(*)。
  • 避免使用 LEFT JOIN、IN 和 OR。
  • 使用 JOIN 和 INTERSECT 代替。
  • 推荐使用 DISTINCT 和 LIMIT 关键字。

• DIN-SQL[68] 和 DEA-SQL[95] 注意到一些关键字如 JOIN、INTERSECT 和 IN 表示SQL查询的难度，因此他们根据判断设计了不同的规范和提示，以反映当前问题的难度水平。

• Meta-SQL[22] 设计了三种查询元数据，以充分表达查询的高层次语义。这些元数据类型包括操作符标签、难度值和正确性指标。

• SQLfuse[110] 进一步补充了校准提示，列举了常见的错误。这些提示预先解决了潜在的失误，增强了模型生成优质SQL查询的能力。

外部知识

外部环境中的杂项知识也可能对Text2SQL任务有所帮助，特别是对于一些行话或领域特定的词汇，没有解释很难理解。具体来说：

• Open-SQL[11] 利用了BIRD数据集[49]提供的伴随每个查询的附加描述信息，充当人类理解与数据库结构之间的桥梁。

• CHESS[81] 使用上下文检索方法提取数据库目录、表和列的描述和缩写，以提高性能。

• SQLfuse[110] 特别设计了一个“SQL Critic”模块，用于确定最优的候选SQL查询。该模块从GitHub中的一系列复杂的SQL语句和模式构建了一个外部SQL知识库，以便更好地提取外部环境中的知识。

通过将SQL相关知识和外部知识整合到提示中，可以显著提高LLM在文本到SQL转换任务中的性能。SQL相关知识帮助LLM避免语义错误，生成更准确和高效的SQL查询。外部知识则帮助LLM更好地理解查询的上下文和特定领域的术语，从而生成更符合实际需求的SQL查询。这些方法不仅提高了模型的准确性和可靠性，还增强了其在复杂查询任务中的表现。

4.2 推理

在给定问题和模式的特定形式后，下一步是生成潜在的答案。考虑到Text2SQL任务的复杂性和对准确性的高要求，仅让LLM直接生成SQL响应通常是难以获得满意结果的。我们对相关工作进行了全面调查，发现有两种技术可以帮助生成正确且高质量的SQL查询：工作流程（workflow）和示范（demonstrations）。

4.2.1 工作流

最简单的流程是从构造的问题和模式直接生成SQL。然而，这种方法在某种程度上高估了通用LLM在专业领域的能力。就像人们倾向于将复杂任务分解为几个简单的子任务或步骤一样，基于提示工程的方法通常会设计特定的推理工作流程来生成使用LLM的查询响应。Text2SQL任务中的工作流程可以根据不同的推理模式进行分类。

• 链式思维（Chain-of-Thought, CoT）
  链式思维（CoT）是最著名的推理风格之一，涉及一系列中间推理步骤，通常以“让我们一步一步思考”开始，以激发链式思维。这种方法特别适合处理复杂的逻辑任务，如Text2SQL。以下是几种应用CoT的具体方法：

  • DIN-SQL[68]：对于复杂类别的问题，DIN-SQL采用由人类设计的CoT步骤。对于非嵌套的复杂问题，CoT步骤包括模式链接和单一的中间表示。而对于嵌套的复杂问题，CoT步骤涵盖多个子问题及其对应的子查询。
  • Divide-and-Prompt[57]：通过逐条生成SQL子句，这是一种CoT模式的变体。
  • CoE-SQL[108]：提出了CoT的一个变体，称为链式编辑（Chain-of-Edition），描述了14种SQL语句的编辑规则，如编辑“select”项、编辑“where”逻辑运算符等。
  • ACT-SQL[107]：提出了自动CoT（Auto-CoT）方法，自动生成CoT示例，解决了手动标注CoT提示的高成本问题。
  • Open-SQL[11]：设计了CoT模板，使用基于骨架的查询框架作为中间表示。
  • SQLfuse[110]：组织其SQL生成提示，采用CoT模式，结合先前的模式信息，并在单个提示中迭代执行SQL检查和错误纠正。

• 最小到最大（Least-to-Most）
  最小到最大（Least-to-Most）是一种广泛应用于Text2SQL工作流程设计的推理风格，它在一个与LLM的交互中将复杂问题分解为一系列更简单的子问题。LTMP-DA-GP[4] 是这一类方法的一个例子。该论文采用最小到最大的方法，分解自然语言查询，将NatSQL[28]映射到分解结果，并从NatSQL生成SQL。

• 分解（Decomposition）
  除了上述推理方法，还有一种简单而有效的工作流程，主要是将生成任务分解为与LLM的定制交互，采用各种技术来解决每个阶段的挑战[44]。QDecomp[80] 首次提出这一类别，建议使用分解提示方法。QDecomp不是使用CoT或最小到最大，而是指示LLM以减少和迭代的方式分解原始的复杂问题为推理步骤。SQL生成任务的分解可以是并行的或顺序的。

  • 并行分解：从SQL语句的错误分析开始，DIN-SQL[68] 将SQL分为三个复杂度级别：简单、嵌套复杂和非嵌套复杂。
    顺序分解：MAC-SQL[84] 引入了一个多代理框架，包括选择器、分解器和优化器。分解器代理生成一系列中间步骤（即子问题和SQL），然后预测最终的SQL。
  • DEA-SQL[95]：遵循全局分解步骤，包括信息确定、分类与提示、SQL生成、自我纠正和主动学习。

• 还有一些专门设计的工作流程：

  • BINDER[12]：首先利用LLM生成其特定领域的语言BINDER-SQL，该语言与SQL语言一致，但某些列名和值被替换为API表达式，对应于子问题和原始表中的某些信息。然后，BINDER再次利用LLM将BINDER-SQL转换为SQL，基于API调用解决的子问题。
  • R3[93]：提出了一种基于共识的多代理系统，用于Text2SQL任务。该系统包括一个SQL写作者代理和多个不同角色的评审代理。经过几轮SQL写作者和评审者之间的“协商”后，达成共识，并决定最终答案。

• 总结

  • 可供选择的模式可供探索。
  • 大多数作品更喜欢思维链或分解推理作为基本工作流程。
  • 建议在原有CoT的基础上设计定制的CoT变体。
  • 分解可以以顺序或并行的方式有利于SQL生成。

4.2.2 示例

在基于LLM的文本到SQL方法的工作流程中，示范经常被用来通过纳入几个示范来提高SQL生成的性能。根据是否附带示范，这些方法可以分为两类：零样本方法（zero-shot methods）和少样本方法（few-shot methods）。

• 零样本方法（Zero-Shot Methods）

零样本方法不依赖于任何示例，直接使用LLM生成SQL查询。这类方法的优点是节省了LLM的令牌数，但文本到SQL是一个复杂的任务，从模型的角度来看可能相对陌生。仅仅修改指令无法有效解决这个复杂任务。零样本方法的例子包括：

• C3[21]

• ReBoost[77]

• DBCopilot[87]

• Generic[3]

• SGU-SQL[109]

• SQLfuse[110]

• 少样本方法（Few-Shot Methods）

少样本方法通过提供几个示例来帮助LLM学习任务的模式，不完全依赖于模型的预训练知识。这一特性增强了LLM的性能和适应性。通过对近期基于LLM的文本到SQL论文中使用的示范进行综合调查，我们将示范的功能分为两类：

1. 示例引导（Example Guidance）：

   • 定义：通过提供几个正确的示例，帮助LLM理解任务的要求和正确的SQL生成方式。
   • 优点：提高了生成SQL的准确性和可解释性，适合处理复杂的查询任务。
   • 示例：
     • DIN-SQL[68]：随机选择一些示例来指导模式链接，并使用“让我们一步一步思考”来进一步提高性能。
     • DEA-SQL[95]：通过提供示例来指导模式链接，特别是在处理复杂查询时。

2. 错误示范和修正（Error Demonstration and Correction）：

   • 定义：通过提供错误示例及其修正方法，帮助LLM识别和避免常见的错误。
   • 优点：预先解决了潜在的失误，增强了模型生成高质量SQL的能力。
   • 示例：
     • SQLfuse[110]：补充了校准提示，列举了常见的错误，预先解决了潜在的失误。
     • ACT-SQL[107]：通过自动CoT（Auto-CoT）方法生成CoT示例，解决了手动标注CoT提示的高成本问题。

通过使用示范，可以显著提高基于LLM的文本到SQL任务的性能。零样本方法虽然节省了LLM的令牌数，但在处理复杂任务时可能不够有效。相比之下，少样本方法通过提供示例来帮助LLM学习任务的模式，增强了模型的性能和适应性。示范的功能可以分为示例引导和错误示范及修正，这两类方法分别通过提供正确的示例和错误示例及其修正方法，帮助LLM更好地理解和生成SQL查询。这些方法不仅提高了生成SQL的准确性，还增强了模型在处理复杂查询任务中的表现。

• 替换任务描述

为了处理复杂的文本到SQL任务，研究探索了多种包含特定步骤或涉及新定义的子任务的工作流程。这些方法通过具体的步骤或子任务，使LLM能够更好地理解和生成SQL查询。以下是几个典型例子：

1. DIN-SQL[68]：

   • 工作流程：DIN-SQL采用链式思维（Chain of Thought）风格的工作流程，设计了精细的步骤。具体步骤如下：
     1. 生成中间表示：首先生成与问题对应的NatSQL[28]作为中间表示。
     2. 生成最终结果：基于生成的NatSQL[28]生成最终的SQL查询。
   • 挑战：这些精细设计的步骤对于模型来说是不熟悉的，难以通过人类语言提示来描述。因此，DIN-SQL利用了LLM的上下文学习能力，提供了几个示例，显著简化了提示中的指令设计。

2. BINDER[12]：

   • 工作流程：BINDER通过增强编程语言（如SQL）的语言模型API调用功能，使用大型语言模型将自然语言查询翻译成扩展的SQL语言。
   • 挑战：同样，这种翻译对于模型来说是不熟悉的，难以通过人类语言提示来描述。因此，BINDER也利用了LLM的上下文学习能力，提供了几个示例，简化了提示中的指令设计。

• 增强LLM的SQL编码能力

适当的示范可以显著提高LLM的性能。实验发现，LLM对样本选择非常敏感，选择不适当的样本甚至可能产生负面影响。为了最大化性能，多项研究探讨了如何选择适当的示范。以下是一些主要方法：

1. 基于语义相似性的检索：

   • 简单方法：最简单的方法是检索那些问题具有相似语义意义的示例。然而，即使问题的底层意图相似，不同数据库模式的问题也可能差异很大，对应的SQL查询可能也有所不同[33]。
   • De-semanticization[33]：通过屏蔽原始问题中的领域特定词汇，获取查询的骨架，然后检索问题骨架语义相似的示例。
   • Retrieval & Revision[31]：通过提示LLM简化自然语言问题，然后利用原始问题和简化问题检索示例，避免了不寻常的提问风格，增强了存储库中的语法和词汇多样性。
   • DAIL-SQL[29]：利用自然语言问题和对应的SQL查询检索示例。
   • Open-SQL[11]：利用自然语言问题、数据库模式和对应的SQL查询检索示例。

2. 多级抽象：

   • PURPLE[72]：设计了四个级别的SQL骨架抽象，专注于更粗粒度的检索。

3. 多样化的示例：

   • ACT-SQL[107]：利用随机选择的示例以及与当前问题相似的示例，提高生成SQL的多样性和质量。

• 示例选择与令牌成本

1. 示例选择：
   • DAIL-SQL[29]：考虑了准确性和令牌成本之间的权衡，提供了三种示例样式：
     • 组合查询、模式和对应的SQL：提供最完整的信息，但令牌长度较长。
     • 组合查询和对应的SQL：减少令牌长度，但仍提供足够的信息。
     • 仅SQL：令牌长度最短，但信息较少。
   • 选择：DAIL-SQL选择了组合查询和对应的SQL，以减少示例的令牌长度，同时保持足够的信息量。

通过利用示范进行任务描述，可以显著提高基于LLM的文本到SQL任务的性能，尤其是对于复杂的工作流程。问题骨架比原始问题更能捕捉问题的意图，通过屏蔽领域特定词汇，保留核心语义结构。在设计提示时，需要在准确性和令牌成本之间进行权衡，选择合适的示例样式和数量，以确保生成的SQL查询既准确又高效。这些方法不仅提高了生成SQL的性能，还增强了模型在处理复杂查询任务中的表现。

4.3 后处理

为了进一步提高基于LLM的文本到SQL方法的性能和稳定性，研究者们在生成的SQL查询后应用了后处理技术。通过对这些方法的综合调查，我们可以将它们总结为两大类：自我纠正（Self-Correction）和一致性（Consistency）。

4.3.1 自我纠正

在LLM生成答案后，自我纠正方法使用特定问题和任务下的规则，让LLM检查答案的正确性。在文本到SQL场景中，自我纠正方法可以使用SQL相关的规则进行检查，还可以提供运行SQL语句生成的结果或错误日志供LLM检查。以下是一些具体的应用和方法：

1. 规则检查：

• 定义：通过预定义的规则检查生成的SQL查询的正确性。
• 示例：
  Generic[3]：注意到表值中多余的空格细微差异，让LLM重新检查这些细节。
  DIN-SQL[68]：检查JOIN条件、WHERE子句等逻辑错误。
  DEA-SQL[95]：分析字段匹配和SQL语法中的几个重要错误点，设计特定的提示来纠正这些错误。

2. 运行结果和错误日志：

• 定义：通过运行生成的SQL查询，提供结果或错误日志供LLM检查和纠正。
• 示例：
  Retrieval & Revision[31]：如果LLM生成的SQL无法运行，将原始提示中的少量模式改为完整模式，重新生成SQL。
  DIN-SQL[68]、ReBoost[77]、CHESS[81]、MAC-SQL[84]：使用错误的SQL和执行错误信息作为提示，让LLM重新生成SQL。
  SQLfuse[110]：提出了SQL Critic模块，采用少样本上下文学习策略，利用外部SQL知识库中的示例，结合事后反馈进行优化。

3. 单元测试和代码解释：

• 定义：通过单元测试、代码解释和执行结果来细化模型的响应。
• 示例：
  ReBoost[10]：设计了单元测试、代码解释和执行结果，帮助模型细化其响应。

4. 洞察
   在文本到SQL任务中，大多数配备自我纠正机制的研究主要集中在“细化”部分，如手工制作的模式修改规则和执行日志，而“批评”部分如代码解释和答案判断还有更大的探索空间。

5. 细化部分：
   手工制作的模式修改规则：通过预定义的规则检查和修改生成的SQL查询，确保其逻辑和语法的正确性。

• 执行日志：通过运行生成的SQL查询，提供结果或错误日志供LLM检查和纠正。
• 批评部分：
• 代码解释：通过提供代码解释，帮助LLM理解生成的SQL查询的逻辑和结构。
• 答案判断：通过提供答案判断，帮助LLM评估生成的SQL查询的正确性和有效性。

4.3.2 一致性

为了进一步提高基于LLM的文本到SQL方法的性能和稳定性，研究者们提出了自我一致性（Self-Consistency）和交叉一致性（Cross-Consistency）方法。这两种方法通过不同的策略来确保生成的SQL查询的正确性和可靠性。

1. 自我一致性（Self-Consistency）
   自我一致性方法主要采用多数投票策略，允许同一个LLM在设置一定温度的情况下生成多个答案，然后选择出现频率最高的答案作为最终答案。具体应用包括：

• 多数投票：
  • 定义：通过设置不同的温度参数，让同一个LLM生成多个答案，然后选择出现频率最高的答案。
  • 示例：
    Open-SQL[11]、BINDER[12]、C3[21]、DAIL-SQL[29]、ReBoost[78]、CHESS[81]：直接使用自我一致性方法对生成的SQL进行多数投票，取得了良好的性能提升。
    SQLfuse[64]：提出了重新排序多个答案并训练一个验证器来检查生成的代码。
    PURPLE[72]：基于生成的SQL的执行结果进行多数投票。

2. 交叉一致性（Cross-Consistency）
   交叉一致性方法使用多个不同的LLM或代理分别生成答案或检查SQL的有效性。具体应用包括：

• 多代理生成和投票：
  定义：使用多个不同的LLM或代理分别生成答案，然后对生成的SQL的执行结果进行投票。
  示例：
  PET-SQL[51]：提出这种方法，指示多个LLM在较低的温度下生成SQL，然后对SQL的执行结果进行投票。
  CHESS[81]：在后处理阶段依次使用自我纠正和自我一致性方法，结合两者的优点。
  R3[93]：采用多代理框架，通过循环方式从具有不同专长的代理那里获取关于SQL的建议，结合了交叉一致性和自我纠正的优点。

• 对比与总结

  • 自我一致性：
    • 优点：通过同一模型生成多个答案，利用多数投票策略，提高了生成SQL的稳定性和准确性。
    • 应用场景：适用于单个模型在不同温度下生成多个答案的情况，如Open-SQL、BINDER、C3、DAIL-SQL、ReBoost、CHESS等。
  • 交叉一致性：
    • 优点：通过多个不同的模型或代理生成答案，利用各自的专长，提高了生成SQL的多样性和可靠性。
    • 应用场景：适用于多个不同模型或代理分别生成答案的情况，如PET-SQL、CHESS、R3等。

• 关键要点总结

  • 自我一致性（Self-Consistency）：
    • 优点：
      • 适应性强：通过设置不同的温度参数，让同一个LLM生成多个答案，能够适应不同的任务需求。
      • 方便：实现简单，只需调整温度参数即可生成多个答案。
      • 性能良好：通过多数投票策略，提高了生成SQL的稳定性和准确性。
    • 缺点：
      • 需要更多的交互：生成多个答案需要多次与LLM交互，增加了计算成本。
      • 成本较高：多次生成答案和投票过程会消耗更多的计算资源。
  • 交叉一致性（Cross-Consistency）：
    • 优点：
      • 减少偏见：通过多个不同的LLM或代理生成答案，减少了单个LLM可能存在的偏见。
      • 多样性：利用不同模型的专长，提高了生成SQL的多样性和可靠性。
    • 缺点：
      • 复杂性：实现和管理多个LLM或代理的复杂性较高。
      • 协调困难：需要协调多个模型的输出，确保最终结果的一致性和准确性。
  • 结合自我纠正和一致性方法：
    • 前景：在后处理阶段结合自我纠正（Self-Correction）和一致性（Consistency）方法，可以进一步提高生成SQL的性能和稳定性。
  • 具体应用：
    • 自我纠正：通过规则检查、运行结果和错误日志、单元测试和代码解释等方法，确保生成的SQL查询的正确性和可靠性。
    • 一致性：通过自我一致性和交叉一致性方法，提高生成SQL的稳定性和多样性。

5 微调

尽管大型语言模型（LLMs）如GPT-4在使用提示方法（如RAG、ICL和CoT）的文本到SQL任务中取得了显著成功，但需要注意的是，这些低成本提示方法与微调LLMs之间仍存在一定的差距。同时，API调用模型往往引发隐私问题。因此，我们也应关注微调LLMs在文本到SQL任务中的应用。
通过微调LLMs，可以显著提高模型在文本到SQL任务中的性能。数据准备、预训练模型选择、模型微调和模型评估是微调过程中的关键步骤。具体示例表明，微调PaLM-2、Code-LLaMA等模型在文本到SQL任务中取得了显著的性能提升。未来的研究可以进一步探索如何优化这些步骤，以实现更高的性能和稳定性。微调LLMs不仅提高了生成SQL的准确性，还增强了模型在处理复杂查询任务中的表现。

5.1 准备

训练数据的质量在确定微调模型效果的上限方面起着至关重要的作用，因此“数据准备”是整个微调过程中至关重要的一步。微调数据集可以通过整合现有数据集或创建新的数据集来获得。

5.1.1 整合现有数据集

在整合现有数据集以训练通用的文本到SQL模型时，我们的目标通常是获得一个大规模、通用的模型，即在文本到SQL领域具有强大跨域能力的LLM。为了提高模型的泛化能力，不同的数据集采用了各种数据增强方法。以下是一些常用的数据集及其增强方法：

• 常用数据集

  • Spider：
    • Spider-SYN[26]：通过合成数据生成方法，消除数据库模式显式出现在问题中的情况。
    • Spider-Realistic[17]：生成更现实的文本到SQL查询，避免数据库模式显式出现在问题中。
    • Spider-DK[27]：要求额外的知识，或对数据库列名进行对抗性修改。
    • Spider-CG[25]：重点提高模型的组合泛化能力。
  • SParC[104] 和 CoSQL[102]：
    • SParC：包含多轮对话的文本到SQL任务，提高模型处理多轮对话的能力。
    • CoSQL：同样包含多轮对话的文本到SQL任务，增强模型的交互能力。
  • CSpider[62] 和 DuSQL[86]：
    • CSpider：增强模型的多语言能力，提供中文和其他语言的文本到SQL数据。
    • DuSQL：同样增强模型的多语言能力，提供多语言的文本到SQL数据。
  • Dr.Spider[9]：
    • Dr.Spider：对问题、列名和SQL进行多方面的对抗性修改，提高模型的鲁棒性。
  • Bird[49]：
    • Bird：模拟真实的文本到SQL场景，包含多表、复杂问题和噪声，提高模型在真实环境中的表现。

• 数据增强方法

  • 消除显式模式: Spider-SYN 和 Spider-Realistic：通过合成数据或生成更现实的查询，避免数据库模式显式出现在问题中。
  • 对抗性修改：Spider-DK 和 Dr.Spider：对数据库列名进行对抗性修改，或要求额外的知识，提高模型的鲁棒性和泛化能力。
  • 组合泛化：Spider-CG：通过生成组合性的查询，提高模型处理复杂查询的能力。
  • 多轮对话：SParC 和 CoSQL：包含多轮对话的文本到SQL任务，提高模型的交互能力和处理多步推理的能力。
  • 多语言能力：CSpider 和 DuSQL：提供多语言的文本到SQL数据，增强模型的多语言处理能力。
  • 真实场景模拟：Bird：模拟包含多表、复杂问题和噪声的真实场景，提高模型在实际应用中的表现。

• 注意事项

  • 负任务迁移：[41]指出，由于负任务迁移的影响，训练更多任务不一定能带来更好的泛化效果。因此，训练多个数据集可能会遇到类似的问题。
  • 链式思维（CoT）数据：
    • 必要性：[15]指出，细调数据集中包含一定量的CoT数据可以提高模型的推理能力，但过多的CoT数据会降低非推理任务的表现。因此，需要在CoT数据的数量上找到合适的平衡。

5.1.2 构建新的数据集

构建新的数据集可以用于训练通用的文本到SQL模型和特定领域的LLM。传统的构建新数据集的方法通常涉及大量的人工工作，如Spider数据集就是由11名耶鲁大学的学生手动注释的。通过人类提出问题并标注正确的SQL，我们已经获得了许多高质量的数据集，如[17, 25–27, 62, 67, 86, 102–104, 113]。然而，手动标注数据集效率低下且成本高昂[97]。随着NLP技术的发展，特别是LLM的出现，一批半自动和全自动的数据集构建方法应运而生。

• 传统方法

  • 手动标注：
    • 定义：通过人工提出问题并标注正确的SQL查询，生成高质量的数据集。
    • 示例：
      • Spider[103]：由11名耶鲁大学的学生手动注释，包含来自不同领域的复杂查询。
      • 其他数据集：如SParC、CoSQL、CSpider、DuSQL等，都是通过人工标注生成的高质量数据集。

• 半自动方法：

  • 定义：结合人工和自动方法，通过LLM生成新的数据集。
  • 示例：
    • Dr.Spider[9]：首先使用众包方法扰动Spider数据集，然后根据新数据手动总结扰动类型，最后使用LLM在少样本情况下生成新的扰动。
  • 具体步骤：
    • 众包扰动：使用众包平台收集对现有数据集的扰动。
    • 手动总结：根据收集到的新数据手动总结扰动类型。
    • LLM生成：在每种扰动类型下，使用LLM在少样本情况下生成新的扰动数据。

• 全自动方法：

  • 定义：完全使用自动化方法生成数据集，无需人工干预。
  • 示例：[40]研究了一种全自动的方法来创建文本到SQL任务的数据集。
  • 步骤：
    • 提供模式和示例行：向LLM提供数据库的模式和示例行。
    • 零样本合成：使用LLM在零样本情况下生成SQL查询。
    • 执行验证：通过执行生成的SQL查询进行验证，确保其正确性。

• 现有自动方法的总结：截至我们撰写本文时，尚未发现其他用于文本到SQL任务的自动数据集构建方法。因此，我们总结了几种生成指令微调数据集的方法，这些方法可能可以应用于文本到SQL任务，有助于未来的研究。

  • 现有方法：
    • 采样：从现有数据中采样。
    • 少样本生成：在少样本情况下生成更多数据。
    • 过滤：对生成的数据进行过滤，确保其质量和适用性。

• 注意事项：

  • 专家比例：[97]指出，由于专家的比例和构建数据所需的时间和努力，人类可能难以编制高复杂度的数据。
  • 垂直增加指令：通过垂直增加指令的复杂度来提高问题的难度。
  • 水平扩展问题：通过水平扩展问题的范围来增加问题的丰富性。
  • 逐步生成：逐步生成复杂且丰富的指令数据集。

5.2 选择预训练模型

有许多可用的开源语言模型，如[2, 34, 50, 65, 73, 82]。这些模型在参数规模、预训练语料库和预训练过程方面各不相同，都可以进行微调。例如，PaLM-2[2]模型在[78]中被微调用于文本到SQL任务，并在当时在Spider数据集上取得了最佳结果。code-llama[73]模型在[84]中被微调，并用于为文本到SQL任务设计的Agents系统。然而，在选择用于微调的模型时，需要考虑多种因素，包括预训练模型的能力、微调数据的量、模型参数的规模和计算能力。正如[15]所提到的，微调的优势可能归因于其能够更有效地利用预训练期间获得的知识。因此，选择一个具有更大预训练语料库的语言模型可能是有利的。[20]指出，当给定相同的训练数据量时，参数规模较大的预训练模型表现更好。[106]的研究发现，专门用于编码的模型在文本到SQL任务中更为有效。

5.3 训练模型

Text2SQL模型微调：模型微调可以采用一般的微调方法，主要包括全微调（Fully Fine-tuning, FFT）和参数高效微调（Parameter-Efficient Fine-tuning, PEFT）[18, 39, 46, 55, 56, 58]。例如，[84] 和 [78] 使用全微调（FFT）对LLM进行微调，而 [116] 则使用LoRA[39] 和 QLoRA[18] 进行参数高效微调（PEFT）。

• 全微调（FFT）

  • 定义：全微调是指对模型的所有参数进行微调。
  • 优点：
    • 全面优化：可以充分利用所有参数的调整来优化模型性能。
  • 缺点：
    • 计算成本高：需要大量的计算资源和时间。
    • 容易过拟合：在小数据集上容易过拟合。

• 参数高效微调（PEFT）

  • 定义：参数高效微调是指只对模型的一部分参数进行微调，而不是所有的参数。
  • 优点：
    • 提高训练效率：通过只微调少量参数，显著减少了训练时间和计算资源的需求。
    • 降低成本：降低了训练成本。
    • 减少灾难性遗忘：根据[41]的研究，PEFT在使用过程中比FFT更不容易发生灾难性遗忘，从而证明了其优越性。
  • 具体方法：
    • LoRA[39]：低秩适应（Low-Rank Adaptation），通过添加低秩矩阵来微调模型。
    • QLoRA[18]：量化低秩适应（Quantized Low-Rank Adaptation），结合了量化和低秩适应，进一步提高了效率和性能。

• 示例

  • 全微调（FFT）：

    • [84]：使用全微调方法对LLM进行微调，特别是在构建代理系统时。
    • [78]：对PaLM-2模型进行全微调，使其在Spider数据集上取得了当时最佳的性能。

  • 参数高效微调（PEFT）：

    • [116]：使用LoRA和QLoRA对LLM进行微调，提高了训练效率和性能。

在文本到SQL领域，模型微调可以采用全微调（FFT）和参数高效微调（PEFT）两种方法。全微调通过调整所有参数来优化模型性能，但计算成本高且容易过拟合。参数高效微调通过只调整少量参数，显著提高了训练效率和性能，同时降低了训练成本，并且在使用过程中更不容易发生灾难性遗忘。这些方法的选择取决于具体的任务需求和可用的计算资源。

5.4 模型评估

微调模型后，一个重要步骤是比较微调前后的结果，以了解模型性能的变化。在文本到SQL任务的背景下，常见的做法是对测试集进行全面的指标分析，例如计算微调前后EM（Exact Match）和EA（Execution Accuracy）的准确率。然而，除了这些指标外，详细分析可以揭示更多深入的见解。例如，我们可以通过对输入进行分类来探索LLM在各种场景中的性能。LLM的出现也为模型评估分析带来了新的可能性。因此，我们将模型评估方法分为三类：指标分析评估、类别分析评估和基于LLM的分析评估。

5.4.1 按得分分析评估

微调模型后的评估指标

微调模型后，评估模型性能是一个关键步骤。在文本到SQL任务中，常用的评估指标包括Exact Set Match Accuracy (EM)、Execution Accuracy (EX)、Test-suite Accuracy (TS)和Valid Efficiency Score (VES)。每种指标都有其优势和局限性，下面详细介绍这些指标：

$$VES=\frac{{\sum }_{n=1}^{N}1(V_n,{\hat{V}}_n)}{N},R(Y_n,{\hat{Y}}_n)=\sqrt{\frac{E(Y_n)}{E({\hat{Y}}_n)}}$$

1. Exact Set Match Accuracy (EM)

• 定义：EM通过比较生成的SQL和标准SQL的字面内容来确定其一致性。具体来说，EM检查生成的SQL和标准SQL的SQL子句是否一致。
• 优势：
  • 精确匹配：确保生成的SQL与标准SQL在字面上完全一致。
• 局限性：
  • 低估预测准确性：由于同一个SQL问题可以有多种表达方式，EM指标往往会低估模型的预测准确性。

2. Execution Accuracy (EX)

• 定义：EX通过比较生成的SQL和标准SQL的执行结果来确定其一致性。具体来说，EX检查生成的SQL在数据库中执行的结果是否与标准SQL的执行结果一致。
• 优势：
  • 实际效果：直接反映生成的SQL在实际数据库中的执行效果。
• 局限性：
  • 高估预测准确性：不同的SQL逻辑可能产生相同的执行结果，因此EX指标可能会高估模型的预测准确性。

3. Test-suite Accuracy (TS)

• 定义：TS通过创建一个小而集中的数据库测试套件来评估模型的性能。这些测试套件是从大量随机生成的数据库中创建的，具有较高的代码覆盖率，能够准确地覆盖各种查询。
• 优势：
  • 严格上限：在评估过程中，测量预测查询在测试套件中的标注准确性，有效计算语义准确性的严格上限。
• 局限性：
  • 复杂性：创建和维护测试套件较为复杂，需要大量的前期工作。

4. Valid Efficiency Score (VES)

• 定义：VES将SQL的执行效率纳入评估范围。计算公式如下所示：
  [
  \text{VES} = \frac{\sum_{i=1}^{n} \hat{y}_i \cdot 1(\hat{y}_i \equiv y_i)}{\sqrt{n}}
  ]
  其中，(\hat{y}_i) 表示预测结果，(1(\hat{y}_i \equiv y_i)) 是指示函数，只有当预测的SQL与正确的SQL等价时才为1，(n) 是查询总数。
• 优势：
  • 综合评估：不仅考虑了生成SQL的正确性，还考虑了其执行效率。
• 局限性：
  • 依赖执行环境：VES的计算依赖于具体的数据库执行环境，可能在不同的环境中有所差异。

5. ESM+
   为了克服EM和TS的局限性，[5] 提出了一个新的评估指标——ESM+（Enhanced Set Match Accuracy）。ESM+在EM的基础上引入了新的规则，特别针对LEFT JOIN、RIGHT JOIN、OUTER JOIN、INNER JOIN、JOIN、DISTINCT、LIMIT、IN、外键、模式检查和别名检查等方面进行了改进。
   ESM+ 的改进点

• JOIN 类型：
  LEFT JOIN、RIGHT JOIN、OUTER JOIN、INNER JOIN、JOIN：ESM+ 能够更准确地识别和评估不同类型的JOIN操作。
• DISTINCT：
  DISTINCT：ESM+ 能够更准确地识别和评估DISTINCT关键字的使用。
• LIMIT：
  LIMIT：ESM+ 能够更准确地识别和评估LIMIT子句的使用。
• IN：
  IN：ESM+ 能够更准确地识别和评估IN子句的使用。
• 外键：
  外键：ESM+ 能够更准确地识别和评估外键的使用。
• 模式检查：
  模式检查：ESM+ 能够更准确地识别和评估数据库模式的正确性。
• 别名检查：
  别名检查：ESM+ 能够更准确地识别和评估表和列的别名使用。

5.4.2 粒度分析评估

除了上述的评估指标（如EM、EX、TS和ESM+）之外，粒度分析（granular analysis）也能为模型评估提供更多的洞见。通过类别分析（categorical analysis），可以从不同的角度了解模型的各种能力。粒度分析通过将数据集划分为不同的子集或类别，可以更细致地评估模型在不同场景下的表现。这种分析方法有助于发现模型在特定类型的任务中的优势和不足，从而指导模型的进一步优化。

按数据集特性分类

[54] 考虑了数据集的特性 [17, 25–27, 62, 67, 86, 102–104, 113]，并分别测试了以下几种场景：

1. 常见零样本场景：

   • 定义：模型在没有见过任何特定领域数据的情况下进行预测。
   • 示例：模型在从未见过的数据库模式和查询上进行测试。

2. 消除数据库模式显式出现的场景：

   • 定义：问题中不显式出现数据库模式。
   • 示例：Spider-SYN[26] 和 Spider-Realistic[17]。

3. 需要额外知识或对抗性修改的场景：

   • 定义：问题或数据库列名经过对抗性修改，或需要额外的知识。
   • 示例：Spider-DK[27] 和 Dr.Spider[9]。

4. 组合泛化场景：

   • 定义：模型需要处理组合性的查询，即包含多个子查询和复杂逻辑的查询。
   • 示例：Spider-CG[25]。

5. 多轮对话场景：

   • 定义：模型需要处理多轮对话中的查询，即用户与系统进行多轮交互。
   • 示例：SParC[104] 和 CoSQL[102]。

6. 多语言场景：

   • 定义：模型需要处理多种语言的查询。
   • 示例：CSpider[62] 和 DuSQL[86]。

按提示工程方法分类

[29] 测试了不同提示格式、不同示例选择方法和不同示例组织方法对文本到SQL任务的影响：

1. 不同提示格式：

   • 定义：使用不同的提示格式来引导模型生成SQL查询。
   • 示例：使用不同的前缀、后缀或中间插入的提示。

2. 不同示例选择方法：

   • 定义：选择不同的示例来辅助模型生成SQL查询。
   • 示例：选择与当前查询最相似的示例，或随机选择示例。

3. 不同示例组织方法：

   • 定义：以不同的方式组织示例，以辅助模型生成SQL查询。
   • 示例：按顺序排列示例，或按相关性排列示例。

按问题难度分类

Spider [103] 提出了一套SQL难度分类标准，考虑了SQL中包含更多关键词、嵌套子查询和过滤条件等因素，认为这些因素使SQL更复杂。基于这些标准，Spider数据集中的问题被分为四个难度级别：

1. 简单：

   • 定义：包含基本的SQL查询，没有复杂的子查询或过滤条件。
   • 示例：单表查询。

2. 中等：

   • 定义：包含一些简单的JOIN操作和过滤条件。
   • 示例：两表JOIN查询。

3. 困难：

   • 定义：包含复杂的JOIN操作、嵌套子查询和多个过滤条件。
   • 示例：多表JOIN查询，包含嵌套子查询。

4. 非常困难：

   • 定义：包含非常复杂的JOIN操作、多个嵌套子查询和复杂的过滤条件。
   • 示例：多表JOIN查询，包含多个嵌套子查询和复杂的过滤条件。

按错误类型分类

不同于上述分类方法，[106] 不是对数据进行分类，而是对输出结果的错误类型进行分类：

1. 系统错误：

   • 定义：在SQL执行过程中，数据库引擎发现的错误。
   • 示例：语法错误、表不存在、列不存在等。

2. 结果错误：

   • 定义：在SQL执行结果中发现的错误。
   • 细分：
     • 表查询错误：查询的表不正确。
     • 列选择错误：选择的列不正确。
     • JOIN列错误：JOIN操作中的列不正确。
     • 过滤条件错误：过滤条件不正确。

通过按数据集特性、提示工程方法、问题难度和错误类型进行分类，可以更全面地评估文本到SQL模型的性能。这些分类方法不仅有助于发现模型在特定类型任务中的优势和不足，还能指导模型的进一步优化和改进。结合常用的评估指标（如EM、EX、TS和ESM+），这些分类方法为模型评估提供了更全面和深入的视角。

5.4.3 基于大模型的评估

[13] 发现，由于强大的自然语言处理能力，LLM具有评估模型的潜力。LLM Comparator[43] 提出了一种系统，可以可视化和评估两个模型之间的差异，从“何时（when）、为何（why）、如何（how）”三个维度进行分析。虽然LLM Comparator[43] 的方法不是专门为文本到SQL任务设计的，但我们可以通过应用上述问题分类方法 [29, 54, 103, 106] 和宏观标准设计 [49, 103, 112]，将评估系统迁移到文本到SQL领域。

6 未来方向

尽管大规模语言模型（LLM）在文本到SQL任务中取得了令人印象深刻的进展，开发高质量的文本到SQL解析器仍然面临多重复杂性。在本节中，我们将探讨潜在的未来发展方向，并分享我们的观点。

6.1 关注隐私

尽管ChatGPT和GPT-4[1] 展示了令人印象深刻的能力，被认为是目前最强大的大规模语言模型（LLMs），但在使用API调用模型时，隐私问题常常引起关注[99]。在工业环境中执行文本到SQL的LLM应用程序时，可能需要将关键绩效指标（KPIs）、表结构、样本数据甚至特定知识传输给LLM API提供商，如OpenAI。毫无疑问，这可能导致商业秘密的潜在泄露。私有部署LLM可以作为解决这一问题的方案。然而，开源模型与ChatGPT或GPT-4[1] 之间仍存在能力差距。在有足够的数据时，微调LLM成为一个可行的选项，但这可能会导致模型其他能力的妥协，甚至引发灾难性遗忘。

6.2 自动化助理

LLM在文本到SQL任务中的灵活性和探索性

大规模语言模型（LLM）在大规模语料库的训练下，展现出了强大的泛化能力。借助ReAct[101]框架，我们可以构建由LLM驱动的自主代理（Autonomous Agents）。这些代理可以自动完成任务，整个过程可以建模为状态转换路径。LLM作为“大脑”，通过与环境、人类或其他代理的互动，参考存储在记忆中的过去信息来确定当前状态，并决定使用哪种预定义工具来实现状态转换。配备了自我修正能力，LLM驱动的自主代理可以检查过去行为的有效性和合理性，并在单步决策失败时探索其他可能的决策。相比管道系统，LLM驱动的自主代理具有更高的灵活性和探索性。

为什么文本到SQL需要自主代理的灵活性和探索性？

我们考察了人类编写SQL的过程，并将其与现有的文本到SQL过程进行了比较。以下是主要原因：

1. 初步数据探索：

   • 人类行为：当人类编写SQL时，他们会先写一些简单的SQL来了解数据的形态，根据任务需求进行初步探索。
   • 现有方法：现有的文本到SQL过程往往忽略了这一步骤。虽然有些工作如[12, 71]通过“SELECT * FROM Table LIMIT X”从数据库中获取一些数据，但这种方法固定且不贴近实际任务需求。人类可以根据需要调整SQL以观察更有趣的数据。

2. 迭代和验证：

   • 人类行为：人类编写SQL不是一个一次性完成的过程。他们会尝试编写SQL，执行SQL以获取结果，观察结果以确认SQL的正确性，修改SQL，然后重复上述步骤，直到满足需求。
   • 现有方法：现有的文本到SQL方法缺乏对结果的观察和自主判断结果正确性的能力。它们通常是单步完成的，缺乏迭代和验证的过程。

自主代理在文本到SQL中的应用

尽管LLM驱动的自主代理在其他领域展示了巨大的潜力，但在文本到SQL任务中，目前还没有看到其应用。MAC-SQL[84]提出了一个针对文本到SQL任务的代理框架，但它是一个管道化的、非自主的代理系统，缺乏自主代理的灵活性和探索性。

未来展望

1. 初步数据探索：

   • 自主代理：自主代理可以在初始阶段自动执行简单的SQL查询，获取数据的初步信息，帮助模型更好地理解任务需求。
   • 动态调整：根据初步数据的反馈，自主代理可以动态调整后续的SQL查询，以获取更有意义的数据。

2. 迭代和验证：

   • 多步决策：自主代理可以进行多步决策，每一步都包括生成SQL、执行SQL、观察结果和验证结果的正确性。
   • 自我修正：如果某一步的决策失败，自主代理可以自我修正，重新生成SQL并继续执行，直到满足任务需求。

3. 增强学习：

   • 学习反馈：自主代理可以通过增强学习机制，从每次任务中学习反馈，不断优化自身的决策策略。
   • 持续改进：随着时间的推移，自主代理的性能会逐渐提高，能够更有效地处理复杂的SQL查询任务。

LLM驱动的自主代理在文本到SQL任务中具有巨大的潜力。通过初步数据探索和迭代验证，自主代理可以更灵活和有效地完成任务，提高模型的性能和可靠性。尽管目前还没有看到自主代理在文本到SQL任务中的应用，但未来的研究和发展有望填补这一空白，推动文本到SQL任务的进一步发展。

6.3 更复杂的模式

在现实世界的文本到SQL任务中，涉及复杂的表结构。[23] 考虑的一个例子是，微软的一个内部财务数据仓库包含632张表，超过4000列，以及200个视图，超过7400列。这在文本到SQL任务中引入了大量的标记，产生了两个突出的问题。

第一个问题是，在生成SQL时选择正确的表和列变得困难，因为庞大的上下文长度会导致LLM的注意力分散，从而导致无效的SQL生成。另一方面，大量的标记会延长LLM的推理时间。

缓解这些问题的一个可能解决方案是模式链接（schema linking），如[23]所建议的。它指出，通过仅选择与自然语言（NL）查询相关的表和列，可以实现更高的准确性。

6.4 基准

[23] 强调，现实世界中的文本到SQL任务总是涉及复杂的表结构。然而，常用的标准数据集如Spider[103]等，仅包含简单的表结构，尽管它们在推动文本到SQL领域的发展中发挥了重要作用。Bird[49] 数据集模拟了真实场景：多个表、复杂的问题，包括噪声。然而，与上述微软内部财务数据仓库中的表规模相比，它仍然相对简单。

6.5 领域知识库

大规模语言模型（LLM）的训练过程及领域知识获取

大规模语言模型（LLM）的训练过程涉及大量的语料库信息，这赋予了LLM丰富的通用知识，为其强大的文本到SQL任务能力奠定了基础。然而，在工业界，文本到SQL任务还需要模型具备与任务相关的领域知识，例如行业特定术语的含义。如果没有相关的领域知识，LLM在理解和回答问题时可能会有严重的偏差。

LLM可以通过两种方法获取领域知识：提示工程（prompt engineering）和微调（fine-tuning）。

1. 提示工程（Prompt Engineering）：

   • 提示工程通过检索增强生成（Retrieval-Augmented Generation, RAG）来获取领域知识。然而，这种方法也存在一些问题：
     • 构建知识库：在现实中，领域知识通常存在于文档中，这些文档往往是非结构化和有噪声的，难以构建一个结构化且高质量的知识库供RAG使用。
     • 知识检索：常用的基于相似性的检索方法不够准确，可能会包含无关信息。无关信息可能会降低LLM的性能。

2. 微调（Fine-Tuning）：

   • 微调通过使用与领域知识相关的训练数据来微调LLM。然而，这种方法也存在一些问题：
     • 训练成本高：微调的训练成本较高，需要大量的计算资源和时间。
     • 灾难性遗忘：微调可能会导致LLM忘记在预训练阶段学到的知识，即灾难性遗忘。
     • 知识更新困难：微调到LLM中的知识很难修改。重新训练整个模型以适应更新的知识集成本高昂，而仅使用新数据微调模型可能会影响大量其他隐式记忆的事实。

7 结论

本文对大规模语言模型（LLM）在文本到SQL任务中的应用进行了全面的回顾。在这篇综述中，我们将LLM在文本到SQL任务中的应用分为两大类：提示工程（prompt engineering）和微调（finetuning）。

在提示工程类别中，我们围绕文本到SQL任务中的提示的基本结构、补充知识的集成方法、示例的选择以及推理过程进行了详细的讨论。

在微调类别中，我们从微调的基本步骤开始：数据准备、预训练模型选择、模型微调和模型评估，每一步都具体结合文本到SQL任务进行了讨论。

此外，我们还回顾了现有的文本到SQL任务的基准测试，并详细讨论了适合大规模语言模型时代的基准数据集。

最后，我们展望了潜在的未来发展方向，并分享了我们的观点。我们希望这篇综述能够让读者对这一领域的最新进展有更广泛的了解，并为未来的趋势提供一些见解。