【论文】CHASE-SQL: Multi-Path Reasoning and Preference Optimized Candidate Selection in Text-to-SQL

||Φ|(|T|Д|T|)|Φ||/

已于 2025-02-26 21:48:50 修改

阅读量914

点赞数 12

文章标签： sql 数据库人工智能

于 2025-02-26 21:43:00 首次发布

本文链接：https://blog.csdn.net/qq_51700285/article/details/145889193

版权

ABSTRACT

在解决大型语言模型（LLM）在Text-to-SQL任务中的表现问题时，我们提出了CHASE-SQL，这是一个新的框架，采用创新策略，通过在多代理建模中使用测试时计算来改善候选生成和选择。CHASE-SQL利用LLM的内在知识，采用不同的LLM生成器生成多样化且高质量的SQL候选，具体方法包括：（1）通过分治方法将复杂查询分解为可管理的子查询，从而在单次LLM调用中生成查询；（2）基于查询执行计划的推理链，反映数据库引擎在执行过程中采取的步骤；（3）独特的实例感知合成示例生成技术，提供针对测试问题的特定少量示范。为了识别最佳候选，使用选择代理通过与经过微调的二元候选选择LLM进行成对比较来对候选进行排名。这种选择方法被证明比其他方法更具鲁棒性。我们提出的生成器-选择器框架不仅提高了SQL查询的质量和多样性，还优于以前的方法。总体而言，所提出的CHASE-SQL在著名的BIRD Text-to-SQL数据集基准测试的测试集和开发集上分别达到了73.0%和73.01%的最先进执行准确率，使得CHASE-SQL成为提交时排行榜的第一名。

1.INTRODUCTION

Text-to-SQL，作为连接自然语言和机器可读的结构化查询语言的桥梁，对于许多应用场景至关重要。它能够将自然语言问题转换为可执行的SQL命令。Text-to-SQL使用户无需精通SQL就能与复杂的数据库系统进行互动并能够提取有价值的见解、进行高效的数据探索、做出明智的决策、生成数据驱动的报告，并为机器学习挖掘更好的特征。此外，Text-to-SQL系统在自动化数据分析和复杂推理中起着至关重要的作用，并推动了交互式智能体的应用，使其不仅限于传统的数据检索。随着数据量的指数级增长，能够在不依赖深入SQL知识的情况下高效查询数据库，变得越来越重要，适用于更广泛的应用场景。

表1: 评估 BIRD 开发集上使用 Gemini 1.5 Pro 实现text-to-sql的自修正和上限的单查询生成与集合方法。
在这里插入图片描述

Text-to-SQL可以视为一种特化的代码生成形式，其上下文信息可能包括数据库模式、元数据及其值。在更广泛的代码生成领域，利用大型语言模型（LLM）生成各种候选方案并选择最佳方案已被证明是有效的。然而，什么样的机制能够产生最有效的候选方案并选择最佳答案并不显而易见。一种简单而有效的方法是通过zero-shot或few-shot提示，生成候选方案，然后利用自一致性方法选择最佳选项，这种方法包括根据执行输出对候选方案进行聚类。这一方法在若干研究中取得了良好的效果。然而，单一的提示设计可能无法完全释放大型语言模型在Text-to-SQL任务中的潜力，而自修正方法也未必总是有效。实际上，正如表1所示，最一致的答案并不总是正确的，其性能上限比自一致性方法高出14%。这一显著差距凸显了通过实现更有效的选择方法，能够在候选查询池中识别最佳答案，从而获得显著改进的潜力。

本文在上述挑战的基础上提出了CHASE-SQL。如表1中的上限所示，充分利用LLM的内在知识有显著的提升Text-to-sql准确率的潜力。我们提出了一种方法，通过生成多样化且高质量的候选回答，并应用选择机制来识别最佳答案。获得既高质量又多样化的候选回答对于基于评分的选择方法至关重要。较低的多样性限制了提升潜力，并减少了自修正方法和基于评分方法之间的差异。虽然像提高temperature或重新排序提示内容等技术可以增加多样性，但它们通常会妥协候选答案的质量。为了解决这个问题，我们引入了有效的候选生成器，旨在增强多样性同时保持高质量的输出。具体而言，我们提出了三种独特的候选生成方法，每种方法都能生成高质量的回答。第一种方法受分治算法的启发，将复杂问题分解成更小、更易处理的部分，用于应对困难的查询。第二种方法采用基于查询执行计划的推理链策略，其推理过程与数据库引擎在查询执行期间所采用的步骤相匹配。最后，我们引入了一种新颖的在线合成示例生成方法，帮助模型更好地理解测试数据库的底层数据模式。这些方法单独使用时，能够生成高度准确的SQL输出。为了有效地在候选之间选择最佳答案，我们引入了一种选择智能体，采用分类目标进行训练，根据候选查询之间的成对比较为每个候选分配评分。通过这个代理，我们为所有候选生成了一个比较矩阵，并根据最高的累积得分选择最终答案。通过将这些候选生成方法与提出的评分模型结合，我们创建了一种集成方法，充分利用每种策略的优势，从而显著提高整体性能。

我们对CHASE-SQL提出的方法进行了全面评估。我们的创新候选生成方法在性能上优于传统的通用推理链提示，展示了它们在引导LLM通过将复杂问题分解为可管理的中间步骤方面的能力。此外，提出的选择智能体在性能上大大超越了传统的基于自修正的方法，推动了最新的研究成果。具体而言，CHASE-SQL在具有挑战性的BIRD Text-to-SQL数据集的开发集和测试集上分别达到了73.01%和73.0%的执行准确率，远超该基准上已发布和未公开的方法，差距相当大。

2 Related Work

早期的Text-to-SQL方法主要采用序列到序列（Seq2Seq）架构，使用图神经网络（GNN）、循环神经网络（RNN）、长短期记忆（LSTM）网络以及预训练的变换器编码器等模型对用户查询和数据库模式进行编码。在解码方面，这些系统采用了槽填充或自回归建模方法，从编码输入中构建最终的SQL查询。此外，像TaBERT、TaPas和Grappa等表格语言模型也被开发出来，有效地编码表格和文本数据。然而，随着大型语言模型（LLM）的广泛使用，研究领域发生了变化，LLM凭借其优越的性能大多取代了早期的方法。最初的工作集中在优化这些LLM的提示设计上。随后的进展引入了更为复杂的方法，包括模式链接、自我修正或自我调试以及自一致性技术，这些方法通过提出复杂的基于LLM的管道进一步提升了性能。

3 Methods

3.1 Overall Framework

CHASE-SQL 框架由四个主要组件组成: 1)值检索，2)候选生成器，3)查询修复程序和4)选择Agent。如图1所示。提出的框架首先检索相关的数据库值。随后，将所有上下文信息(包括检索到的值、数据库元数据和模式)提供给 LLM 以生成候选查询。这些候选查询然后经历一个修正循环，最后，使用经过训练的选择代理以两两比较所有候选者以选择正确的答案。以下部分将深入探讨每个组件的细节。
在这里插入图片描述

图1: Text-to-SQL 的拟议 CHASE-SQL 框架概述，其中包括值检索和使用一个选择Agent来改进在生成的候选人中挑选答案的工作，同时还有一个修正程序来提供反馈以改进产出。

3.2 Value Retrieval

数据库可能包含非常多的行，通常只有少数行与查询相关。检索相关值是至关重要的，因为它们可以用于各种 SQL 子句，如“ WHERE”和“ HAVING”。与CHESS中的方法类似，我们首先从给定的问题中提取关键字，使用一个 LLM 提示并附有few-shot。对于每个关键词，我们使用局部性敏感哈希(LSH)来检索句法上最相似的单词，并根据嵌入相似度和编辑距离对它们进行重新排序。该方法对问题中的输入错误具有鲁棒性，并在检索过程中考虑关键字语义。

3.3 Multi-path Candidate Generation

如表1所示，仅仅依赖于自修正功能可能导致次优性能。因此，我们优先考虑生成多个响应候选人的多样性，以增加生成至少一个正确答案的可能性。在由候选生成器产生的不同响应中，我们使用一个选择智能体来选择一个作为最终响应，该代理将候选者成对地进行比较。不断增加temperature，并刷新列和表在prompt中的顺序。

链式思维（CoT）提示（Wei等，2022）被提出用于通过基于逐步推理的链条来调整LLM的最终回应，从而增强其推理能力。大多数CoT提示方法依赖于提示中的少量示例，引导LLM逐步思考，格式为 M = (qi, ri, si)，其中qi是示例问题，ri是推理路径，si是qi的真实SQL查询。我们采用了两种不同的推理方法和一种在线合成示例生成方法。如图3a所示，不同的生成器可以产生不同的输出，表明它们在特定问题和数据库中的有效性。
在这里插入图片描述

图 3a 维恩图解说明了每种方法的数量: 查询计划、合成示例、分而治之，至少产生一个正确的候选者。重叠区域表示生成正确候选项的多个方法

分治法 CoT：分治法的视角通过将复杂问题分解为更小的子问题，逐个解决这些子问题，然后将解决方案合并以获得最终答案。基于这一思路，我们提出了一种CoT提示方法，首先通过伪SQL查询将给定问题分解为更小的子问题。在“conquer”步骤中，将这些子问题的解决方案汇总，以构建最终答案。最后，应用优化步骤来简化构建的查询，去除冗余的子句和条件。这种方法在处理涉及嵌套查询的复杂场景时特别有效，例如复杂的WHERE或HAVING条件，以及需要高级数学运算的查询。在附录图17中，我们举例展示了一个问题及其相应的SQL查询，该问题通过这个生成器成功解决，而本论文中考虑的其他方法由于查询的复杂条件和SQL子句无法处理该场景。有关分治法提示的更详细视图，请参见附录图16。此外，算法1概述了使用单次LLM调用生成最终SQL输出的分步过程。

在这里插入图片描述

输入的仅有数据库模式、问题和evidence

Database Info
{DATABASE_SCHEMA}
**************************
Question
Question: What is the gender of the youngest client who opened account in the lowest average salary branch?
Hint: Given that Later birthdate refers to younger age; A11 refers to average salary
**************************

输出分为三个部分。首先是“Divide and Conquer”部分，这部分主要就是将原始问题“Main Question”分解成一堆子问题“Sub-question”。如果子问题还是很复杂，也可以继续拆分子子问题，颗粒度可以以子问题能用正常SQL来表示为止。然后，每一个问题都配上对应的CoT解释“*Analysis”以及解释对应的伪SQL代码“Pseudo SQL”。在解释中尽可能的使用一些话术，如“对应知识XXX我们应该”、“问题提到了XXX是应该在XXX里的”、“XXX可能指的是XXX”、“指标XXX的计算应该是XXX”等来进行引导。在伪SQL代码中还原解释的内容，对于复杂的需要继续拆解的部分用简单的“代词”文本，并且在子问题的内容和解释中Call back这些代词。

**1. Divide and Conquer:**
* **Main Question:** What is the gender of the youngest client who opened account in the lowest average salary branch?
* **Analysis:** Question asking about ‘gender‘, and it appears in table ‘client‘. We will use this as the output column, selecting it from the youngest client in the lowest average salary branch.
* **Pseudo SQL:** SELECT ‘T1‘.‘gender‘ FROM ‘client‘ AS ‘T1‘ WHERE youngest client in the lowest average salary branch
* **Sub-question 1:** youngest client in the lowest average salary branch
* **Analysis:** According to the hint, we need to use the ‘A11‘ from ‘district‘ to get the salary info, and the youngest client can be obtained from using the ‘birth_date‘ column of table ‘client‘. The items between these two tables can be INNER JOIN using district_id.
* **Pseudo SQL:** SELECT ‘T1‘.‘client_id‘ FROM ‘client‘ AS ‘T1‘ INNER JOIN ‘district‘ AS ‘T2‘ ON ‘T1‘.‘district_id‘ = ‘T2‘.‘district_id‘ WHERE lowest average salary branch ORDER BY ‘T1‘.‘birth_date‘ DESC NULLS LAST LIMIT 1
* **Sub-question 1.1:** lowest average salary branch
* **Analysis:** We can get the lowest average salary branch using order by ‘A11‘ ASC and pick top 1. The column ‘A11‘ is not NULLABLE, so we do not need to add "IS NOT NULL" filter 
* **Pseudo SQL:**
SELECT ‘district_id‘ FROM ‘district‘ ORDER BY ‘A11‘ ASC LIMIT 1

第二部分是“Assembling SQL”，将第一部分中拆解了问题并得到对应部分的伪SQL组装起来

**2. Assembling SQL:**
* **Sub-question 1.1 (lowest average salary branch):** * **SQL:** SELECT ‘district_id‘ FROM ‘district‘ ORDER BY ‘A11‘ ASC LIMIT 1
* **Sub-question 1 (youngest client in the lowest average salary branch):**
* **SQL:** SELECT ‘T1‘.‘client_id‘ FROM ‘client‘ AS ‘T1‘ INNER JOIN ‘district‘ AS ‘T2‘ ON ‘T1‘.‘district_id‘ = ‘T2‘.‘district_id‘ WHERE ‘T2‘.‘district_id‘ IN (SELECT ‘district_id‘ FROM ‘district‘ ORDER BY ‘A11‘ ASC LIMIT 1) ORDER BY ‘T1‘.‘birth_date‘ DESC NULLS LAST LIMIT 1
* **Main Question (gender of the client):**
* **SQL:** SELECT ‘T1‘.‘gender‘ FROM ‘client‘ AS ‘T1‘ WHERE ‘T1‘.‘client_id‘ = (SELECT ‘T1‘.‘client_id‘ FROM ‘client‘ AS ‘T1‘ INNER JOIN ‘district‘ AS ‘T2‘ ON ‘T1‘.‘district_id‘ = ‘T2‘.‘district_id‘ WHERE ‘T2‘.‘district_id‘ IN (SELECT ‘district_id‘ FROM ‘district‘ ORDER BY ‘A11‘ ASC LIMIT 1) ORDER BY ‘T1‘.‘birth_date‘ DESC NULLS LAST LIMIT 1)

最后一部分“Simplification and Optimization”，是一个查缺补漏以及优化结构的阶段。

**3. Simplification and Optimization:**
* The nested queries can be combined using a single ‘INNER JOIN‘ and the filtering can be done within a single ‘ORDER BY‘ clause.
**Final Optimized SQL Query:**
SELECT ‘T1‘.‘gender‘ FROM ‘client‘ AS ‘T1‘ INNER JOIN ‘district‘ AS ‘T2‘ ON ‘T1‘.‘district_id‘ = ‘T2‘.‘district_id‘ ORDER BY ‘T2‘.‘A11‘ ASC, ‘T1‘.‘birth_date‘ DESC NULLS LAST LIMIT 1

查询计划 CoT：查询（执行）计划是数据库引擎执行SQL命令时访问或修改数据的步骤序列。当SQL查询执行时，数据库管理系统的查询优化器将SQL文本转换为数据库引擎能够执行的查询计划。这个计划概述了如何访问表、如何连接表以及对数据执行的具体操作（例如，见附录图19）。受到数据库引擎执行SQL查询时逐步过程的启发，我们提出了一种推理策略来构建最终的SQL输出。任何给定SQL查询的查询计划都可以通过“EXPLAIN”命令获得，该命令提供执行步骤的详细分解。然而，这些输出通常以LLM难以解读的格式呈现（例如，SQLite中的格式）。为了解决这一问题，我们将“EXPLAIN”命令的输出转换为更易于人类阅读的文本格式，使其与LLM的预训练数据更为契合。查询计划的人类可读版本包括三个关键步骤：

这个推理方法补充了分治法CoT策略。虽然分治法更适用于分解复杂问题，但查询计划方法在问题涉及更多关于问题各部分与数据库模式之间关系的推理时表现更优。它系统地解释了扫描哪些表，如何匹配列，以及如何应用过滤条件。附录图20展示了仅通过该方法正确回答的问题示例。附录图18提供了用于该推理策略的提示。

与分治法COT不同在于：

分治法（CoT）：分治法COT是将任务分解为小块，最后合并，适用于将复杂的问题分解成更小、更易处理的部分，通常在解决复杂问题时有效。

查询计划推理方法：查询计划CoT则是将问题分为了特定的选表、表连接等、选列操作，更适合处理涉及数据库模式和问题各部分之间关系的推理问题。它专注于如何从数据库中获取相关数据，如何匹配表和列，以及如何应用过滤条件等操作。

在线合成示例生成：使用M个示例进行少量样本的上下文学习在各种相关任务中已显示出良好的效果（DIN-SQL）。除了帮助指定任务并展示逐步推理过程来导出输出外，使用相关表格和列构建的示例还可以帮助模型理解底层的数据模式。基于这一观点，我们提出了一种用于Text-to-SQL的合成示例生成策略——给定用户问题Qu、目标数据库D和选定的列ti（采用类似于CHESS的列选择方法）。

在这里插入图片描述

算法 2 概述了在线合成示例生成方法，包含两种生成步骤。

第一种侧重于生成具有常见SQL特性的示例，这些特性在指导方针Rf中有描述。SQL特性包括等式和不等式谓词、单表和多表JOIN、嵌套JOIN、ORDER BY和LIMIT、GROUP BY和HAVING、各种聚合函数。这些是广泛使用的SQL子句和函数——生成的示例SQL查询包含这些特性，遵循BIRD SQL特性分布（见图23a）。

在这里插入图片描述

图23a展示了为BIRD开发数据集生成的合成示例的SQL特性分布，该分布与实际SQL特性分布非常接近，唯一的例外是省略了CASE语句的示例，因为除非真实SQL查询中实际使用了CASE语句，否则展示包含CASE语句的示例对生成没有帮助。

You are a SQLite SQL expert. Your job is to create {k} examples, where each example consists of a question and a SQL query to fetch the data for it. I want each example to look like this, question input and SQL output pairs:
"input": "What’s the description of the series code SM.POP.TOTL for Aruba?
(Hints: Aruba is the name of the country where ShortName = ’Aruba’)"
"output": "SELECT T2.Description FROM Country AS T1 INNER JOIN CountryNotes AS T2 ON T1.CountryCode = T2.Countrycode WHERE T1.ShortName =  ’Aruba’ AND T2.Seriescode = ’SM.POP.TOTL’"
You should generate examples that examine and showcase different aspects and relationships of the following table schemas, described in "Table creation statements". Understand the database tables and their relationships. Understand the columns and their types and meanings to construct intresting examples.
Generate a mixture of SQL examples that include:
• some simple SQL query examples without JOIN
• some SQL query examples with aggregates, like COUNT
• some simple SQL query examples with JOIN
• some complex SQL query examples with nested JOIN
**************************
Table creation statements
{TARGET_DATABASE_SCHEMA}
**************************
Generate total of {k} examples. Only outputs the examples (question input and SQL output pairs), and each example can be separated by a new line.

第二种侧重于生成强调正确解释底层数据模式的示例——模型θ被要求使用ti生成示例，并与Rt中列出的示例相似（附录A.10提供了用于示例生成的提示）。

You are a SQLite SQL expert. Your job is to create a set of examples, where each example consists of a question and a SQL query to fetch the data for it.
You should generate examples that examine and showcase different aspects and relationships of the following table schemas. Understand the database tables and their relationships. Understand the columns and their types and meanings to construct intresting examples.
I will also show you multiple examples generated for the other database and its table schemas, so you can see what kind of examples can be generated for a given database.
**************************
###Examples from other database### The following is the table schemas and column examples for
other database:
The database (¨{TRAIN_DATABASE_NAME}¨) structure is defined by the following table schemas (comments after ’–’ provide additional column descriptions).
{TRAIN_DATABASE_SCHEMA}
————————–
The folloiwing are the examples generated for the above database schemas:
Example 1) "input": "Among the countries in the group of Heavily Indebted Poor Countries, how many of them are under the lending category of the International Development Associations? (Hints: group of Heavily Indebted Poor Countries is OtherGroups = ’HIPC’; International Development Associations refers to lendingcategory = ’IDA’)"
"output": "SELECT COUNT(CountryCode) FROM Country WHERE LendingCategory = ’IDA’ AND OtherGroups = ’HIPC’"
...
Example 10) "input": "What is the description of the footnote on the series code AG.LND.FRST.K2 in 1990 for Aruba? (Hints: Year = 1990; Aruba is the name of country where ShortName = ’Aruba’)"
"output": "SELECT T2.Description FROM Country AS T1 INNER JOIN FootNotes AS T2 ON T1.CountryCode = T2.Countrycode WHERE T1.ShortName = ’Aruba’ AND T2.Seriescode = ’AG.LND.FRST.K2’ AND T2.Year = ’YR1990’"
**************************
Now similarly, generate examples (question input and SQL output pairs) for the table schemas defined below, in "Table creation statements".
**************************
###Table creation statements###
TARGET_DATABASE_SCHEMA
**************************
Only outputs the examples (question input and SQL output pairs), and each example can be separated by a new line.

虽然相关示例（例如，展示带有多表嵌套JOIN的查询）对于需要复杂JOIN查询的问题很有帮助，但过度使用此类示例也可能误导LLM（例如，当仅需简单的单表查询时）。这加上自然语言查询qi本身的固有歧义（我们根据相关性生成示例），使得示例选择变得具有挑战性。因此，我们对每个qi在线生成并注入示例到提示中。我们要求LLM为上下文学习生成多个输入输出对。最终的qi合成示例集包含通过Rf和Rt生成的示例。这确保示例集在SQL特性/子句以及使用的相关表/列选择方面具有多样性。示例集的多样性是必要的，以避免将输出过拟合到某些特定模式（例如，模型在显示大多数JOIN示例时总是写JOIN的SQL）。混合多种SQL特性和数据库表的示例，包括和不包括列过滤，观察到可以整体提高生成质量（详见附录表8）。

应当尝试提高示例的多样性，以避免将输出过拟合到某些特定模式。例如：如果大多数示例展示JOIN，模型总是写出带有JOIN的SQL。

3.4 Query Fixer

在某些情况下，LLM 可能生成语法不正确的查询。这些查询显然需要更正，因为它们未能提供正确的答案。为了解决这个问题，我们应用了一个基于 LLM 的查询修复程序，它利用了自反射self-reflection方法。修复程序反映以前生成的查询，使用诸如语法错误详细信息或空结果集等反馈来指导更正过程。我们继续这种迭代修复方法，直到一个特定数量的尝试，β (在本文中设置为三)。

3.5 Selection Agent

通常来说通过执行候选查询来衡量它们的一致性，根据执行结果将它们分组，并从最大组中选择一个查询作为最可能的正确答案。但事实是这种方法假设最一致的答案不一定是最好的。

之前强调了多样性，就导致尽可能能让它生成正确的SQL，如果只选择最一致的组，确实有可能导致全部都只有一个或者最多组不是正确的SQL

为此，我们提出了一种更精细的选择策略——算法3，该策略依赖于选择代理。
在这里插入图片描述

给定一组候选SQL查询 C = {c1, c2, …, cn}，最终的响应通过找到由选择模型分配最高分的候选查询来选择。这个模型 θp 可以接受 k 个候选查询，并根据每个查询回答给定问题的准确性对它们进行排序。具体而言，我们将最终响应的选择公式化为：

在这里插入图片描述

其中，Qu 表示用户的问题，Hu 是提供的提示，D 是提问所使用的目标数据库。在公式 1 中，我们将 k 个候选查询传递给选择模型进行排序，k 的取值范围在 1 和 n 之间。在极端情况下，当 k = 1 时，模型无法对候选查询进行比较，这使得模型的评估过程变得更加复杂。随着 k 的增大，比较更多的候选查询会使模型的过程更加具有挑战性，因为它需要同时考虑多个方面。因此，我们设定 k = 2，并训练一个分类目标模型，仅在每次比较两个候选查询。

拥有一组高质量且多样化的候选项，最直接的解决方案是使用现成的大型语言模型（LLMs）进行成对选择。然而，使用未经过微调的LLM进行实验时，Gemini-1.5-pro的二分类准确率仅为58.01%。这主要是因为候选项之间非常相似，模型需要经过微调才能学习到细微差别，从而做出更准确的决策。为了训练选择代理，我们首先在训练集（Text-to-SQL基准测试）上生成候选SQL查询，并根据执行结果将它们分组为若干簇。对于至少一个簇包含正确查询而其他簇包含错误查询的情况，我们创建训练样本，样本以元组（Qu, Ci, Cj, Dij, yij）表示，其中Qu是用户的问题，Ci和Cj是正在比较的两个候选查询，Dij是两个候选查询使用的数据库模式，yij∈{0, 1}是标签，指示Ci或Cj哪个是正确的查询。为了避免训练中的顺序偏差，我们在每一对候选查询中随机打乱正确与错误查询的顺序。由于同时存在正确和错误候选项的情况有限，对于没有正确候选项的实例，我们将在提示中包含真实SQL查询作为线索，以引导模型生成正确的候选项。

在算法3的伪代码中，我们首先为每个候选查询初始化一个零分。然后，对于每一对不同的查询（ci, cj），我们将（ci, cj）和（cj, ci）都进行比较，以避免顺序偏差，确保每一对候选查询都能得到公平的评估。如果两个查询在数据库上产生相同的执行结果，我们将其中一个标记为胜者，并增加其得分，因为这种结果表明查询的一致性。如果执行结果不同，我们会生成两个查询所使用的数据库模式的并集，并使用二分类器来判断哪个查询更可能是正确的。分类器考虑问题、两个候选查询和合并后的数据库模式来做出决策。然后，更新胜者的得分。经过所有比较后，得分最高的候选查询将被选为最终查询。如果最终得分出现平局，我们通过随机选择其中一个候选查询来打破平局。

Instruction:
Given the DB info and question, there are two candidate queries. There is correct one and incorrect one, compare the two candidate answers, analyze the differences of the query and the result. Based on the original question and the provided database info, choose the correct one.
**************************
Database Schema
{DATABASE_SCHEMA}
**************************
Question:
{QUESTION}
Evidence:
{HINT}
**************************
Candidate A
{CANDIDATE_A_QUERY}
Execution result
{CANDIDATE_A_RESULT}
**************************
Candidate B
{CANDIDATE_B_QUERY}
Execution result
{CANDIDATE_B_RESULT}
Just output the correct answer "A" or "B".

使用训练集微调了Gemini-1.5-pro模型，使其更加适合进行SQL语句的二分类。

然后对于之前的候选者两两进行“挑战”，如果平局，则从中随机抽一个

4 Experiments

4.1 Datasets and Models

数据集略

模型：使用Gemini 1.5 Pro和Claude-3.5-Sonnet两种模型的性能。对于查询选择模型，我们训练了一个Gemini 1.5 Flash模型（其延迟远低于Gemini 1.5 Pro模型），该模型在一个包含3.8K样本的数据集上进行训练，这些样本是通过在BIRD训练数据集上运行候选生成器生成的。Gemini 1.5 Flash模型使用LoRA适配器（秩为16）并通过Vertex AI调优API进行了10个epoch的训练。

4.2 BIRD results

在这里插入图片描述

4.3 Spider results

略

4.4 Generator and selection performance

SQL生成与修正模块：

表4：比较了使用Gemini 1.5 Pro在BIRD开发集上执行的原始BIRD prompt+zero-shot CoT与候选生成器生成的候选项。Selector是我们最终的性能，应用选择智能体于所有生成器生成的21个候选项。
在这里插入图片描述

选择模块：

表5：评估不同选择模型的二分类选择准确率。
在这里插入图片描述

候选生成分析：我们对每种候选生成方法的性能进行了单独分析。为了更好地理解在有效选择正确的SQL查询时，候选池的性能潜力，我们从每个生成器方法中生成七个候选SQL查询（总共21个候选项），并针对BIRD开发集中的所有样本进行评估。我们确定生成的候选数量为七个，基于观察到候选池超过20个时并未带来显著提升，如图d所示。

在这里插入图片描述

图d 所有三个候选生成器在不同难度类别上的上限性能。

通过假设我们有一个理想选择模型，它能从七个候选中始终选择正确的SQL查询，我们计算了每个生成器的上限性能。相反，假设使用一个对抗性选择模型，该模型总是选择错误的SQL查询，我们则计算了下限性能。下面三张图展示了所有三种方法的上限和下限性能，以及我们选择智能体的表现。
在这里插入图片描述

在这里插入图片描述

结果显示，两个CoT方法的上限性能通常高于合成示例生成方法，即使在不同数量的候选项下也是如此。然而，它们的下限性能也低于合成方法。下限准确率反映了所有候选项都正确的情况，这减少了选择过程中的噪声，因为无论选择哪个候选项都无关紧要，因此较高的下限表现更为理想。这一点在选择代理的表现中得到了体现，在下限性能下降的情况下，提升上限所带来的收益逐渐减小，导致选择代理的性能趋于平稳。此外，结合三种方法的上限性能达到了82.79%，这表明通过更好的候选选择方法仍有显著的提升空间。这表明LLM的参数化知识已经包含了解决大多数问题所需的信息，强调了集成方法在有效提取和利用这些知识方面的必要性。

此外，我们通过结合来自三种候选生成方法的所有候选项，评估了BIRD开发集在简单、中等和挑战性难度级别下的上限性能。这些难度类别是由人工专家在创建BIRD开发集时分配的。图2d显示，正如预期的那样，随着候选项数量的增加，上限性能在所有难度级别上都有所提升。然而，对于挑战性和中等难度类别，性能的提升比简单类别提前趋于平稳，这表明对于这两个难度级别，生成更多的样本并未进一步提高上限性能。

在这里插入图片描述

图3：SQL生成方法比较：左侧为维恩图，展示了独特和重叠的正确答案；右侧为不同复杂度级别下的性能表现。

图3a展示了一个维恩图，展示了三种生成方法的性能：查询计划（Query Plan）、分治法（Divide and Conquer）和合成示例（Synthetic Examples）。交集区域中的数字表示多个方法至少生成了一个正确的候选查询。这张图形象地突出了每种方法的独特贡献，表明使用所有三种生成器的必要性。此外，在图3b中，我们比较了每种SQL生成方法生成的、其他生成器没有生成正确答案的正确查询数量。分治法在挑战性问题上表现优于其他方法，而查询计划方法在中等难度的查询上表现出色。为了进一步分析生成器在不同领域以及不同数量的列和表中的表现，我们比较了每个数据库生成的正确查询数量，如附录图4所示。图中显示，两个CoT方法在不同数据库中的表现通常相似，而在线合成示例生成方法显著增加了多样性，从而在不同数据库中整体产生了更多的正确答案。

选择模块分析：我们通过将选择代理的Text-to-SQL执行准确率与自一致性方法（使用多数投票）、理想模型（上限）和对抗性模型（下限）进行比较，评估查询选择性能。在评估中，我们使用两种不同的采样温度（0.5和1.8）从每种候选生成方法中生成10个样本。结果如表6所示，选择代理显著优于自一致性方法，准确率差距大约为6%。正如预期的那样，增加采样温度提高了上限，但也降低了下限。对于合成数据生成方法，这一效应比两种CoT方法更为明显，主要是因为LLMs在生成最终SQL查询之前会生成推理步骤，这有助于减轻高温采样带来的随机性。使用自一致性方法时，性能通常随着温度的升高而下降，因为随着更多随机查询的出现，主要簇变得更小。然而，所提的训练选择代理对于温度变化的影响较小，在两个情况下，甚至在更多样本池的情况下提升了性能。

在这里插入图片描述

表6：不同选择方法在BIRD开发集上生成的候选项上的性能比较，使用两种不同的温度。QP指的是查询计划CoT，DC指的是分治法CoT，OS指的是在线合成示例生成方法。

4.5 Ablation Studies

在前面的部分，我们评估了选择代理和每种候选生成方法的重要性。接下来，我们将重点分析CHASE-SQL的其余组件：用于值检索的LSH、查询修复器以及三种推理策略（QP、OS和DC）。表7展示了去除这些步骤后CHASE-SQL的性能，突出了它们在实现更高质量性能中的重要性。结果显示，每个组件的贡献，去除LSH、查询修复器或任何候选生成器都会导致执行准确率的下降，进一步验证了这些CHASE-SQL组件的重要性。此外，表中还比较了我们的二分类选择代理与其他两种选择方法：自一致性方法和排序代理的性能。排序代理接收由我们三个候选生成器生成的所有候选项，并进行比较，为每个候选项生成一个排名。对于排序代理，我们选择排名最低的查询作为最佳答案。二分类选择代理显著优于自一致性方法和排序代理，展示了所提方法的有效性。

在这里插入图片描述

5 Conclusion

我们提出了一个新颖的代理框架——CHASE-SQL，旨在利用测试时计算生成多样化的高质量SQL查询，并准确选择正确的查询。我们提出了多种链式思维提示方法和在线合成示例生成技术，同时引入了一种基于成对比较为候选项打分的查询选择机制。我们的框架CHASE-SQL在提交时的著名公共Text-to-SQL排行榜中设立了新的最先进水平，展示了测试时计算在生成多样化查询和选择最准确响应方面的有效性。CHASE-SQL解决了查询多样性和选择优化等关键问题，为进一步改进复杂推理任务在实际Text-to-SQL挑战中的表现铺平了道路。