Text2SQL 新一代解决方案Tool-SQL，基于LLM和Agent智能体实现，效果提升显著

在互联网时代，数据爆发式增长，如果高效的分析数据成为一个亟待解决的问题。SQL是数据分析师的常用工具，编写高效的SQL需要用户具备一定的IT基础，对于普通人员来说存在一定门槛。

Text-to-SQL技术可以实现自然语言转换成SQL，用户只需要用自然语言描述自己的目标，Text-to-SQL工具就可以自动生成对应的SQL，大大降低SQL编写的门槛和效率。

为了提高Text-to-SQL的效果，北航提出了一个基于LLM和智能体的Text-to-SQL框架。实验表明，新方法在执行准确率和完全匹配准确率上得到显著提升。论文地址：https://arxiv.org/pdf/2408.16991

最近我们建了交流群，感兴趣的朋友可以点赞关注后加我v: longyunfeigu 拉进群，也可以直接扫描下面二维码加群

最新的Text-to-SQL方法利用大型语言模型（LLMs）和数据库系统反馈，有效解决SQL查询中的执行错误。然而，对于不引发执行异常但与数据库不匹配的问题，如条件不匹配和严格约束不匹配等方面表现出挑战性。

为解决此类问题，提出了一个名为SQL检查和细化的工具辅助代理框架，装备有两个专门工具：检索器和检测器，能诊断和纠正SQL查询与数据库的不匹配问题。这增强了LLMs处理实际查询的能力。

同时引入了一个新的数据集Spider-Mismatch，专门构建以反映真实场景中遇到的条件不匹配问题。实验结果表明，该方法在Spider和Spider-Realistic数据集的平均结果上实现了最高性能，并且在更现实的数据集Spider-Mismatch上明显优于基线方法。

Text-to-SQL任务致力于将自然语言问题自动转化为结构化查询语言（SQL）查询，便于非专家用户访问数据库。历史上，此任务的研究集中于开发需要大量标注数据的训练模型。近期，研究转向利用大型语言模型（LLMs）和上下文学习（ICL），通过提供示例进行模型微调。最初的ICL方法旨在通过创建更好的提示来利用LLMs的推理能力，而后续研究通过多步骤过程辅助LLMs生成SQL查询。这包括自校正方法和基于执行反馈的细化方法，后者通过数据库管理系统（DBMS）执行反馈来改进查询。

尽管这些方法通过DBMS反馈解决执行错误，但难以处理不触发执行异常的数据库不匹配错误。这包括条件不匹配和查询器约束的不匹配，这两种情况在现实场景中常见，下图展示了这两种错误：

为了解决这些问题，提出了一个工具辅助代理框架，使用数据库检索器和错误检测器工具来检测和纠正SQL查询中的错误。

此外，主流Spider数据集及其变体很少反映真实场景中的条件不匹配问题。为了弥合这一差距，引入了Spider-Mismatch数据集，专门设计来突出SQL条件子句中的不匹配问题，通过特定干扰挑战模型，更贴合现实世界情况。

Text-to-SQL

在近年来，大型语言模型（LLMs）对于文本转SQL（Text-to-SQL）任务的应用成为了研究的热点，众多研究致力于通过各种方法提升LLMs在此领域中的表现。特别是，关于如何设计更有效的提示以挖掘LLMs在解析Text-to-SQL任务时的潜力成为了研究的焦点。

例如，ACT-SQL和一个由Tai等人在2023年提出的方法，都通过构建复杂的思维链提示来增强LLMs的推理能力。另一方面，DAIL-SQL在2024年由Gao等人进行的研究中，对LLM在Text-to-SQL任务中的提示工程进行了系统性的探讨，这包括了问题的表示、示例的选择以及示例的组织方式。

近期的研究趋向采用一种多阶段的框架策略，意图通过将Text-to-SQL任务细分为若干更小的子任务，并为每个子任务定制专门的提示，从而提升LLMs的处理性能。比如，Pourreza和Rafiei在2024年提出的DINSQL方法，就是将Text-toSQL任务分解为模式链接、问题分类、SQL生成及自相关四个子步骤，以期减轻任务的整体难度。接着，Xie等人在2024年进一步对DINSQL的流程进行了增强，引入了DEA-SQL，该方法不仅沿用了DINSQL的框架，还新增了一个主动学习模块。

为了降低生成SQL查询中的错误率，多阶段方法通常会集成一个错误校正模块。DIN-SQL和DEA-SQL通过采用自我纠错机制，指导LLMs依据提示中的规则对SQL进行修正。此外，MAC-SQL方法由Wang等人在2024年提出，它通过利用数据库管理系统的反馈来指导LLMs，专注于解决SQL查询执行过程中的错误。

LLM Agent

随着大型语言模型（LLM）的迅速发展，基于这些模型的代理技术的应用潜力正逐步被挖掘。这些代理的核心优势之一在于它们的识别工具能力，此功能极大地弥合了LLM代理与外部世界之间的信息鸿沟。在此背景下，多个项目和研究团队投入了大量资源，开发出了一系列旨在增强这些代理功能的工具和框架。

AutoGPT（团队于2023年提出）是一种开源的AI代理实现，它集成了众多工具，旨在提升单个代理的能力。同时，OpenAgents（由Xie等人在2023年开发）设计了三种不同的代理，每种都聚焦于特定的应用领域，并搭载了专为该领域定制的工具。

另外，ToolLLM（由Qin等人在2024年提出）和API-Bank（由Li等人在2023年提出）专注于促进LLM代理与支持RESTful API的开放域实际应用之间的交互。这为代理提供了与真实世界应用程序进行交互的能力，极大地扩展了它们的应用范围。

在更具体的应用场景中，如Text-to-SQL任务，MAC-SQL（由Wang等人在2024年提出）引入了一个多代理框架。该框架旨在独立解决Text-to-SQL转换过程中遇到的各种子任务，例如通过执行异常来精细调整SQL语句。尽管在利用工具诊断SQL查询错误及提供反馈以帮助LLM代理进行SQL细化方面已取得了一定进展，但在检测和解决SQL查询与数据库不匹配的问题上，相关研究仍相对匮乏。

为了填补这一研究空白，研究人员开始探索使用工具来识别和解决SQL查询中的数据库不匹配问题。这一进展不仅提高了基于LLM的代理处理复杂查询的能力，也为进一步提升代理与外部数据交互的准确性和效率开辟了新的路径。

基于LLM的Text-to-SQL任务

LLM的方法通常采用上下文学习范式，将Text-to-SQL视为生成任务。生成过程可以公式化为：

其中，对大语言模型f的输入包括任务指令提示I、一组演示示例E、数据库D的数据库模式S和新查询Q。证明E = [（S，Q，Y），...，（S，Q，Y）]由来自训练集的k个示例组成，每个示例具有预期输出Y。LLM的输出Y可以是SQL查询或其他形式的中间结果。

框架

Tool-SQL，这是一个工具辅助的代理框架，旨在使用基于LLM的代理指导的多个工具来持续检查和改进SQL查询。这个框架定义了一组Python函数作为基于LLM的代理的动作空间。这些函数对应于不同的SQL子句。输出Y是表示SQL查询的操作序列，而不是SQL查询本身。通过Python解释器执行操作序列，工具集中的每个工具T都被调用，以根据问题Q和数据库D检查函数调用Y中的不同错误。如果检测到错误，每个工具都会向基于LLM的代理提供特定的反馈，帮助代理细化特定的SQL子句，而不是盲目地修改SQL查询。检查过程可表述为：

检查和细化过程是迭代的。在基于LLM的代理生成一系列操作之后，将调用所有工具来检查潜在问题。如果所有工具都批准了操作序列，则它将用于组装最终的SQL查询。相反，如果任何工具检测到问题，则代理将基于原始序列Y和来自工具的反馈来生成新的动作序列Y。该过程可以重复多次，直到所有工具都批准该序列或达到最大尝试次数。细化过程可以公式化为：

大致方法如下：

1. 为基于LLM的代理设计了一系列Python函数调用，以执行一系列操作
2. 方法中集成了两个工具：数据库索引器和错误检测器。前者检查SQL条件子句的有效性，并通过探索数据库内容来协助代理，而后者则根据SQL执行语法、数据库模式和SQL功能或领域专家定义的更严格的约束来检测查询中的错误
3. 获取最终SQL查询的过程，其中Python解释器执行动作序列，并使用LLM补充SQL查询中缺失的信息

函数

在设计了一套基于SQL的函数库，该库包含八个专门针对构建和细化SQL查询的Python函数。这些函数分别对应SQL的不同子句，以便简化和组织查询的构建过程。例如，处理“WHERE”子句的任务交由“add where”函数负责。进一步地，为了减少基于大型语言模型（LLM）的代理在执行任务时需要考虑的操作范围，将SQL中用于查询串联的操作符（如“UNION”、“INTERSECT”和“EXCEPT”）整合进一个统一的“添加合并”函数中。同时，逻辑运算符如“AND”和“OR”，通常用于“WHERE”或“HAVING”子句，被设计成在函数内部处理，留给LLM在最终步骤中解决，以此简化查询构建过程。每个函数接受特定于其对应SQL子句的参数，例如，一个“WHERE”子句的“A = B”条件，会以“add where（A，=，B）”的形式传递给函数。这种参数化的设计方式不仅提高了工具在诊断SQL子句错误方面的效率，也减少了字符串解析的复杂度。

检验工具

数据库检索器

定义了两个工具-数据库检索器和错误检测器，它们检查SQL查询中的问题，并帮助基于LLM的代理改进SQL查询。

数据库检索器数据库检索器的主要职责是协助基于LLM的代理验证SQL条件子句的正确性。如图3所示，检索器检查条件动作中的参数（例如，“add where”和“add having”）匹配数据库中的任何条目，如果没有找到匹配项，则为代理提供对类似单元格的引用。通过使用检索器，代理可以将SQL查询中的值与数据库中相应的单元格对齐，或者决定从条件子句中排除列，这对于实际场景中的Text-to-SQL任务至关重要。在现实环境中，用户问题通常包含与数据库中的标准化值不同的不规则值，因此在执行查询之前需要进行验证。此外，用户问题的模糊性可能使其具有挑战性，即使对于高级代理来说，在条件子句中定位正确的列名也是如此。

错误检测器

错误检测器的功能在于识别与严格约束不匹配的问题，并间接访问数据库以发现SQL执行中的错误。当LLM生成的SQL包含错误时，通常是由于对特定领域的SQL不熟悉或受到幻觉等因素的影响，这使得错误检测变得尤为重要。为了进行广泛的检测，开发了一个验证程序，它通过解析Python函数的参数，并在数据库的协助下执行。

与Wang et al. 2024提出的MAC-SQL方法不同，该方法并不直接在数据库管理系统（DBMS）中执行SQL查询来获取反馈。这种差异化的做法是因为直接执行SQL查询的方法在错误检测能力上有限，通常只能捕捉到语法错误和数据库模式错误等执行异常。

在进行错误检测的过程中，首要步骤是提取数据库的模式信息，这包括所有表名、列名及其类型、外键关系等。随后，通过设计的验证程序对照这些信息检查函数参数是否满足SQL操作和数据库模式的要求。针对更严格的约束，诊断过程聚焦于基于SQL特征来检测诸如外键关系不匹配、"JOIN"操作的冗余或缺失、条件子句中列类型不匹配、以及"GROUP BY"子句的缺失或不当使用等错误。

此外，还特别强调了该工具的可扩展性，它能够轻松适应检测用户定义的约束。在实际应用场景中，这意味着通过分析函数调用的参数，工具可以针对具有特定数据处理需求的场景进行调整。例如，对于需要排除"NULL"值或需要以特定格式处理列数据的情况，该工具能够进行相应的扩展以满足这些特定的需求。

SQL生成

在最后阶段，我们使用纠正后的动作序列生成SQL查询。我们使用Python解释器来执行这些函数调用并提取SQL查询的主要组件。对于“WHERE”或“HAVING”子句中缺失的逻辑运算符“AND”和“OR”（不包括在动作序列中），我们依靠LLM来预测它们。有了所有的组件，我们就可以组装完整的SQL查询了。

数据集构建

在真实世界的应用场景中，用户提出的问题呈现出广泛的多样性，这些问题与数据库的实际内容之间往往存在不小的差距。为了更精确地评价不同模型在实际环境中的适应性及泛化能力，Spider基准测试应运而生。然而，Spider基准并非完美，因此衍生出了几个新的数据集，包括Spider-SYN、Spider-DK和Spider-Realistic，以便更好地应对不同的挑战。同时，Bird数据集的推出，关注点放在了处理更为复杂的数据库内容和提升SQL查询的效率上。大多数现行方法并没有充分考虑到用户问题中提到的数值与数据库中实际数值之间的潜在不匹配问题，为解决这一问题，SpiderMismatch数据集被引入。这个新数据集通过增添模型在生成正确的条件子句时所需克服的难度，引入了用户问题与数据库内容之间的微妙差异性，从而推动了模型性能的进一步提升。

条件后处理模块

当前的LLM Text-to-SQL技术在处理SQL查询中的值方面存在不足，这让生成准确的条件子句变得复杂。针对这一问题，本文引入了一个被称为条件后处理的新模块。该模块的作用是从预测的SQL语句中抽取出值的引用，并利用SimCSE检索技术，将每个值与其所在列最匹配的单元格进行替换。为了确保评估的一致性，本研究在所有测试方法中均应用了条件后处理模块，以便进行公正比较。

实验设置

1. **数据集: **使用Spider和Spider-Realistic数据集
2. **LLM: **使用ChatGPT和GPT-4
3. **评估指标: **包括执行准确率和完全匹配准确率
4. **基线: **包括DIN-SQL、MAC-SQL和ACT-SQL

DIN-SQL：一种多阶段方法，采用自校正方法来细化SQL查询; MAC-SQL：一种多代理协作方法，根据DBMS的反馈改进SQL; ACT-SQL：一种单阶段方法，引入了用于SQL生成的思想链范例，与使用ChatGPT的其他方法相比，该方法在Spider-Realistic数据集上取得了优异的结果。

结果

实验结果表明，Tool-SQL在Spider数据集和Spider-Realistic数据集上的执行准确率最高，且在Spider-Mismatch数据集上也表现出色。Tool-SQL的性能稳定，能够有效地处理不同场景下的挑战。

消融分析

研究发现，在去除数据库检索功能的情况下，ChatGPT与GPT-4的执行效率分别降低了4.1%和3.2%。这一现象揭示了，在面对用户提问的多义性时，语言模型生成精确的SQL条件子句遇到了挑战。进一步的实验显示，移除错误检测机制对ChatGPT的性能影响更为显著，暗示了在错误识别方面，性能较弱的模型可能更加脆弱。另外，当错误检测工具被数据库验证工具取代时，ChatGPT和GPT-4的准确性分别降低了1.6%和1.0%，这一结果强调了错误检测功能在维护SQL查询准确性中的关键作用。

讨论

研究展示了ChatGPT和GPT-4在作为优化代理时，对SQL查询错误修正过程的影响。主要发现是大部分错误能通过单次修正得到解决，尤其是那些涉及执行错误和约束不匹配的情况。然而，仍需多轮迭代来精细调整，特别是对条件子句的修改。这意味着在处理复杂的用户问题时，基于大型语言模型（LLM）的代理可能需要多次尝试才能找到正确的条件。

实验结果还表明，结合Tool-SQL的ChatGPT和GPT-4在进行错误修正时的平均迭代次数分别为0.74和0.44。这种方法避免了在没有错误检测时引入不必要的步骤，减少了额外成本。

此外，研究还考察了去除条件后处理模块对性能的影响。结果显示，移除该模块后，所有基准测试的性能都有所下降，这强调了LLM预测值与数据库实际值之间存在差异。尽管如此，由于该方法能够协助LLM代理生成正确的条件子句，去除后处理模块并未导致性能降低。反之，该模块在实际应用中可能会导致错误的答案，因为它会强制替换条件子句中的值为与之最相似的数据库单元格，从而可能引起无答案或错误答案的问题。

在本文中，我们提出了工具SQL框架设计的SQL生成在更现实的情况下。这个框架着重于使用基于LLM的代理来改进SQL查询，并从各种工具中获得有针对性的反馈，以检查SQL查询中的特定问题。我们设计了一个数据库检索器和一个错误检测器，以解决现实世界中常见的潜在数据库不匹配问题。在Spider数据集和Spider-Realistic数据集上的平均实验结果表明，我们的方法在少数情况下达到了最高的性能。此外，在SpiderMismatch上的实验结果表明，该方法在实际干扰下仍能保持较高的性能，说明了该方法在增强SQL查询性能方面的有效性。