2024-12-2018:02发布于广东腾讯技术工程官方账号
划重点
01腾讯推出OlaChat数智助手，提供text2sql、指标分析、SQL智能优化等智能数据分析功能。
02OlaChat已集成至DataTalk、OlaIDE等腾讯内部主流数据平台，支持数据分析全流程场景。
03其中，text2sql功能通过大模型实现精确的SQL生成，提高数据分析效率。
04除此之外，OlaChat还提供指标分析、SQL智能优化等功能，助力数据分析工作更加简单高效。
OlaChatAI数智助手万字长文深度解析，带你了解Text-to-SQL技术的前世今生。
从自然语言问题（文本到SQL）生成准确的SQL是一个长期以来的挑战，因为用户问题理解、数据库模式理解和SQL生成中的复杂性。传统的文本到SQL系统，包括人工工程和深度神经网络，已经取得了实质性进展。随后，预训练的语言模型（PLMs）已被开发并用于文本到SQL任务，取得了有希望的性能。随着现代数据库变得越来越复杂，相应的用户问题也变得更加具有挑战性，导致参数受限的PLMs（预训练模型）产生错误的SQL。这就需要更复杂的定制优化方法，这反过来又限制了基于PLM的系统应用。
最近，大型语言模型（LLMs）在自然语言理解方面展示了显著的能力，因为模型规模的增长。因此，集成基于LLM的实现可以为文本到SQL研究带来独特的机会、改进和解决方案。在这项调查中，本文全面回顾了基于LLM的文本到SQL。具体来说，作者提出对文本到SQL的技术挑战和进化过程的一个简要概述。然后，作者们提供了详细介绍旨在评估文本到SQL系统的数据集和评价指标。之后，本文系统地分析了基于LLM的文本到SQL的最新进展。最后，讨论了该领域剩余的挑战，并提出了未来研究方向的期望。
文中”[xx]”具体指代的论文，可以查阅论文原文的参考文献部分。
由于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]等方面的进一步研究正日益增多。
●数据集和基准：详细介绍了用于评估基于LLM的文本到SQL系统的常用数据集和基准。本文讨论了它们的特点、复杂性以及它们对文本到SQL的开发和评估带来的挑战。
●评估指标：将介绍用于评估基于LLM的文本到SQL系统性能的评估指标，包括基于内容匹配和基于执行的范例。然后简要介绍了每个指标的特点。
●方法和模型：本文对基于LLM的文本到SQL所采用的不同方法和模型进行了系统分析，包括基于上下文学习和微调的范例。从不同的实施角度讨论了它们的实施细节、优势以及针对文本到SQL任务的适应性。
●期望和未来方向：本文讨论了基于LLM的文本到SQL的其余挑战和局限性，如现实世界的鲁棒性、计算效率、数据隐私和扩展。还概述了潜在的未来研究方向以及改进和优化的机会。
Text-to-SQL是一项旨在将自然语言问题转换为可以在关系数据库中执行的相应SQL查询的任务。形式上，给定一个用户问题Q（也称为用户查询、自然语言问题等）和数据库模式S，任务的目标是生成SQL查询Y，从数据库检索所需内容以回答用户问题。文本到SQL允许用户使用自然语言与数据库交互，而不需要SQL编程的专业知识，从而有可能实现数据访问的民主化[75]。通过使非熟练用户能够轻松地从数据库中检索目标内容并促进更有效的数据分析，这可以使商业智能、客户支持和科学研究等各个领域受益。
文本到SQL实现的技术挑战可以概括如下：
1）语言复杂性和歧义性：自然语言问题通常包含复杂的语言表示，例如嵌套子句、共指和省略号，这使得将它们准确地映射到SQL查询的相应部分是很有挑战性的[41]。此外，自然语言本质上是不明确的，对于给定的用户问题有多种可能的表示[76,77]。解决这些歧义并理解用户问题背后的意图需要深入的自然语言理解以及整合上下文和领域知识的能力[33]。
2）模式理解和表示：为了生成准确的SQL查询，文本转SQL系统需要对数据库模式有全面的理解，包括表名、列名以及各个表之间的关系。然而，数据库模式可能很复杂，并且在不同领域之间差异很大[13]。以文本到SQL模型可以有效利用的方式表示和编码模式信息是一项具有挑战性的任务。
3）罕见和复杂的SQL操作：一些SQL查询在具有挑战性的场景中涉及罕见或复杂的操作和语法，例如嵌套子查询、外连接和窗口函数。这些操作在训练数据中不太常见，对文本到SQL系统的准确生成提出了挑战。设计可推广到各种SQL操作（包括罕见和复杂场景）的模型是一个重要的考虑因素。
4）跨域泛化：文本到SQL系统通常很难跨各种数据库场景和域进行泛化。由于词汇、数据库模式结构和问题模式的多样性，在特定领域训练的模型可能无法很好地处理其他领域提出的问题。开发能够使用最少的特定领域训练数据或微调适应有效推广到新领域的系统是一项重大挑战[78]。
多年来，文本到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]。
在文本到SQL中整合LLM仍然是一个新兴的研究领域，具有进一步探索和改进的巨大潜力。研究人员正在研究如何更好地利用LLM的知识和推理能力、结合特定领域的知识[31,33]，以及开发更高效的微调策略[10]。随着该领域的不断发展，预计将开发出更先进、更优秀的基于LLM的实现，从而将文本到SQL的性能和泛化能力提升到新的高度。
在本节中，本文将介绍文本转SQL的基准，包括众所周知的数据集和评估指标。
如表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中的实体之间的对齐，提供比其他数据集更细粒度的监督。
5)跨语言数据集：SQL关键字、函数名、表名和列名通常以英文书写，这给其他语言的应用带来了挑战。CSpider[42]将Spider数据集翻译成中文，发现了单词分割和中文问题与英文数据库内容之间跨语言匹配的新挑战。DuSQL[34]引入了一个实用的文本到SQL数据集，其中包含中文问题和中英文数据库内容。
为文本到SQL任务介绍了以下四种广泛使用的评估指标：基于SQL内容匹配的“组件匹配”和“精确匹配”，以及基于执行结果的“执行准确性”和“有效效率分数”。
1)基于内容匹配的指标：SQL内容匹配度量主要是根据预测的SQL查询与基本真实SQL查询在结构和语法上的相似性进行比较。
组件匹配（CM）[13]通过使用F1分数测量预测SQL组件（SELECT、WHERE、GROUPBY、ORDERBY和KEYWORDS）与真实SQL组件（GROUPBY、ORDERBY和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的应用程序的实现主要依赖于上下文学习（ICL）（即时工程）[87-89]和微调（FT）[90,91]范式，因为强大的专有模型和架构良好的开源模型正在大量发布[45,86,92-95]。基于LLM的文本到SQL系统遵循这些范例进行实现。在本次调查中，将相应地讨论它们。
通过广泛和公认的研究，提示工程已被证明对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-TrivialPrompt：通过海量数据的训练，LLM在不同的下游任务中对零样本和少量的提示具有很强的整体熟练度[90,97,98]，这在实际应用中得到了广泛的认可和应用。在调查中，将上述没有精心设计框架的提示方法归类为琐碎提示（虚假提示工程）。如上文所述，式3描述了基于LLM的文本到SQL的过程，它也可以表示零样本提示。通过连接I、S和Q，可以得到整体输入P0：
为了规范提示过程，OpenAIdemo2被设置为文本转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的扩展：
跨域少量示例的影响也在研究之中[54]。当纳入不同数量的域内和域外示例时，域内示例的表现优于零次示例和域外示例，随着示例数量的增加，域内示例的表现也会更好。为了探索输入提示的详细构造，[53]比较了简洁提示和冗长提示的设计方法。前者将模式、列名、主键和外键按条拆分，后者则将其组织为自然语言描述。
C1-Decomposition：作为一种直观的解决方案，将具有挑战性的用户问题分解为更简单的子问题或使用多组件来实现，可以降低整个文本到SQL任务的复杂性[8，51]。处理复杂度较低的问题，LLM有可能生成更准确的SQL。基于LLM的文本到SQL的分解方法分为两种范式：(1)子任务分解，通过将整个文本到SQL任务分解为更易于管理的有效子任务（如模式链接[71]、域分类[54]），提供额外的解析以协助最终SQL生成。(2)子问题分解：将用户问题分解为子问题，以降低问题的复杂度和难度，然后通过解决这些问题生成子SQL，从而推导出最终的SQL查询。
参考Chain-of-Thought[103]和Least-to-Most提示[104]，QDecomp[51]引入了问题分解提示，它遵循从least-to-most提示中的问题还原阶段，并指示LLM进行分解原始复杂问题作为中间推理步骤
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-PromptOptimization：正如之前所介绍的，用于提示LLM的少数几次学习已被广泛研究[85]。对于基于LLM的文本到SQL（text-to-SQL）和上下文学习，微不足道的少次元方法取得了可喜的成果[8,9,33]，进一步优化少次元提示有可能获得更好的性能。由于在现成的LLM中生成SQL的准确性在很大程度上取决于相应输入提示的质量[107]，因此影响提示质量的许多决定性因素成为当前研究的重点[9]（例如，少量提示组织的质量和数量、用户9问题与少量提示实例之间的相似性、外部知识/提示）。
C3[30]框架由一个清晰提示组件和一个提供提示的校准组件组成，前者将问题和模式作为LLMs的输入，后者生成一个清晰提示，其中包括一个去除与用户问题无关的冗余信息的模式和一个模式链接。LLM将其组成作为用于SQL生成的上下文增强提示。检索增强框架引入了样本感知提示[64]，该框架简化了原始问题，并从简化的问题中提取问题骨架，然后根据骨架的相似性在存储库中完成样本检索。检索到的样本与原始问题相结合，进行少量提示。
DAIL-SQL[9]提出了一种新方法来解决少量示例的采样和组织问题，在少量示例的质量和数量之间实现了更好的平衡。DAILSelection首先屏蔽了用户和少量示例问题中的特定领域词汇，然后根据嵌入的欧氏距离对候选示例进行排序。同时，计算预预测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-ReasoningEnhancement：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提示总是使用带有人工注释的静态示例进行演示，这就需要通过经验判断来有效选择少量的示例，而人工注释也是必不可少的。
QDecomp[51]通过对结合CoT提示增强LLMsSQL生成的系统性研究，提出了一个新颖的框架，以解决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-ExecutionRefinement：在设计准确生成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查询进行排序，并根据贝叶斯风险（Bayesrisk）选择执行结果最小的示例[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）细粒度投票：根据难度级别细化朴素投票，以减轻投票偏差。。
由于监督微调（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]“Learningfromnoisylabelswithdeepneuralnetworks:Asurvey,”
[74]Recentadvancesintext-to-SQL:Asurveyofwhatwehaveandwhatweexpect
[29]“Asurveyoflargelanguagemodels”
DAIL-SQL[9]被设计为上下文学习框架，利用采样策略来获得更好的少样本实例。将采样实例纳入SFT流程可提高开源LLM的性能。Symbol-LLM[50]提出了数据增强指令调整的注入和注入阶段。CodeS[10]在ChatGPT的帮助下通过双向生成增强了训练数据。StructLM[70]接受多种结构知识任务的训练，以提高整体能力。
分解：将任务分解为多个步骤或使用多个模型来解决任务是解决复杂场景的直观解决方案，正如之前在第IV-A章中介绍的ICL范式。基于ICL的方法中使用的专有模型有大量参数，与微调方法中使用的开源模型的参数级别不同。这些模型本身就有能力很好地完成分配的子任务（通过少样本学习等机制）[30,57]。因此，要在ICL方法中复制这种范式的成功，就必须合理地为开源模型分配相应的子任务（如生成外部知识、模式链接和提炼模式），以便针对特定子任务进行微调，并构建相应的数据用于微调，从而协助最终SQL的生成。
DTS-SQL[71]提出了一个两阶段分解的文本到SQL微调框架，并在最终SQL生成之前设计了一个模式链接12预生成任务。
尽管文本到SQL研究取得了重大进展，但仍然存在一些需要解决的挑战。在本节中，将讨论期望在未来工作中克服的剩余挑战。
由LLMs实现的文本到SQL，有望在现实世界的复杂应用场景中实现通用性和鲁棒性。尽管最近在鲁棒性特定数据集方面取得了实质性进展[37,41]，但其性能仍然无法满足实际应用的需要[33]。在未来的研究中，仍有一些挑战需要克服。从用户方面来看，存在这样一种现象，即用户并不总是一个明确的问题提出者，这意味着用户的问题可能不具有准确的数据库值，也可能与标准数据集不同，同义词、错别字和模糊表达都可能被包含在内[40]。
例如，在微调范例中，模型是在具有具体表达的明确指示性问题上进行训练的。由于模型没有学习现实问题与相应数据库的映射，因此在应用于真实世界场景时会出现知识缺口[33]。正如对带有同义词和不完整指令的数据集进行的相应评估所报告的那样[7,51]，由ChatGPT生成的SQL查询包含约40%的错误执行，比原始评估低10%[51]。同时，使用本地文本到SQL数据集进行的微调可能包含非标准化的样本和标签。例如，表或列的名称并不总是其内容的准确表述，这就导致了训练数据构造中的不一致性。
计算效率由推理速度和计算资源成本决定，这在应用和研究工作中都值得考虑[49,69]。随着最新的文本到SQL基准测试中数据库的复杂性不断增加[15,33]，数据库将承载更多信息（包括更多的表和列），数据库schema的token长度也会相应增加，带来一系列的挑战。在处理超复杂数据库时，将相应的模式作为输入可能会遇到这样的挑战，即调用专有LLM的成本将显著增加，有可能超过模型的最大标记长度，尤其是在实现上下文长度较短的开源模型时。
为了应对这一挑战，根据意图偏差调整LLM，并针对噪声场景设计训练策略，将有利于最近取得的进展。同时，现实应用中的数据量相对小于研究型基准。由于通过人工标注来扩展大量数据会产生高昂的人力成本，因此设计数据扩充方法以获得更多的问题-SQL对将会在数据稀缺的情况下为LLM提供支持。此外，微调开源LLM对本地小规模数据集的适应性研究也有潜在益处。此外，在未来的研究中还应全面研究多语言[42,124]和多模式场景[125]的扩展，这将使更多语言群体受益，并有助于构建更通用的数据库接口。
作为LLM研究的一部分，基于LLM的文本到SQL还面临着LLM研究中存在的一些普遍挑战[4,126,127]。从文本到SQL的角度来看，这些挑战也会带来潜在的改进，从而对LLM的研究大有裨益。如前文第IV-A章所述，在最近的研究中，上下文学习范例在数量和性能上都占主导地位，大多数工作都使用专有模型来实现[8,9]。在数据隐私方面提出了一个直接的挑战，因为调用专有应用程序接口来处理本地数据库的保密性可能会带来数据泄露的风险。使用局部微调范式可以部分解决这一问题。
作为一项长期存在的挑战，为解决这一问题已经开展了大量研究[129,130]。然而，在文本到SQL的研究中，基于LLM的实现的可解释性仍然没有被讨论，无论是在上下文学习中或微调范式。具有分解阶段的方法从逐步生成的角度解释了文本到SQL的实现过程[8,51]。在此基础上，结合可解释性方面的高级研究[131,132]来提高文本到SQL的性能，以及从数据库知识方面解释本地模型架构，仍然是未来的发展方向。
作为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数智助手是腾讯PCG大数据平台部利用大模型在数据分析领域内落地实践中推出的全新智能数据分析产品，目前已集成至DataTalk、OlaIDE等腾讯内部主流数据平台，为数据分析全流程场景提供智能支持。包含了text2sql、指标分析、SQL智能优化等一系列能力，从数据分析（拖拽分析、SQL查询）、数据可视化，到结果解读与归因，OlaChat全面助力，让数据分析工作变得更加简单高效！