发布时间：2024 年 05 月 13 日
应用案例
MCS-SQL: Leveraging Multiple Prompts and Multiple-Choice Selection For Text-to-SQL Generation
大型语言模型（LLMs）的进步是基于上下文学习（ICL）的方法在文本到 SQL 任务中超越微调方法的关键。尽管如此，面对复杂模式和查询（如 BIRD）的挑战，它们的表现仍不及人类专家。本研究深入探讨了 LLMs 对提示的敏感性，并提出了一种创新策略，通过多提示探索答案的广阔空间，并巧妙地整合结果。我们通过多提示的架构链接，精细地调整数据库架构。接着，我们依据这些精炼架构和多样提示，创造出多样的候选 SQL 查询。最后，我们依据置信度评分筛选这些候选查询，并通过多选机制，向 LLM 展示最优解。在 BIRD 和 Spider 的测试中，我们的方法分别实现了 65.5%和 89.6%的准确率，显著超越了以往的 ICL 方法，并在 BIRD 上以准确性和效率刷新了 SOTA 记录。
https://arxiv.org/abs/2405.07467
缘起
Text2SQL问题对于试图使用自然语言与数据库接口交互的系统而言非常重要。随着大语言模型应用的快速发展，基于语境学习（in Context Learning）的文本到SQL的方法，在性能上已经能够超越传统的微调技术*。特别是在Spider基准测试中，某些ICL方法甚至在人类评估中超越了标准查询。不过，在更为复杂的BIRD基准测试中，ICL方法的准确率尚未突破60%，与人类93.0%的表现相比仍有较大差距，这表明ICL方法仍需进一步优化以更好地服务于自然语言数据库接口系统。
大语言模型的一个重要局限性就是任务效果对提示词结构和内容的变化非常敏感。即使是语义相同的提示，也可能因句子顺序、示例选择和示例呈现顺序等因素导致LLMs产生截然不同的响应。在文本到SQL的实验中，也是如此，Prompt中的内容和示例选择都会对LLM的输出产生影响。
提示工程
提示工程，作为一个专门研究如何通过运用提示词来提升大语言模型效果的技术，目前已经逐渐成为LLM研究的新热点。提示工程的有效运用可以显著提高LLM在各类任务上的效果。例如，思维链（CoT）提示法通过人工设计的示例引导LLMs在得出答案前生成推理步骤，这一技术在多项任务中都取得了显著的性能提升。
除了CoT，自洽解码技术也被提出，它通过从LLMs中抽取多个答案，并通过多数投票选择最终答案，与贪婪解码相比，这种方法有助于探索不同的推理路径，同样取得了显著的性能提升。为了更深入地探索推理步骤，还提出了思维树和思维图等变体。
然而，由于这些方法依赖单一提示生成推理步骤，不能能解决LLMs对提示高度敏感的问题，导致搜索空间受限。
一些研究集中在应用CoT或最少到最多等提示技术于文本到SQL生成。但是，这些方法依赖于固定的手工示例集，其性能会因示例选择而有显著差异。
MCS-SQL的诞生
针对以上局限性，本篇论文作者提出了一种新方法：MCS-SQL（Multiple-Choice Selection）。该方法通过多个提示生成多种候选答案并有效整合，以提高LLMs在文本到SQL任务中的准确性和稳定性。
如上图所示，SQL生成包括架构链接、多SQL生成和选择三个步骤：
• 首先，架构链接阶段通过多个提示稳健地从数据库架构中选择与问题相关的表和列。
• 然后，生成阶段利用不同提示产生多样化的候选SQL查询，以更广泛地探索潜在查询。
• 最后，选择阶段根据置信度分数筛选候选查询，并通过多项选择机制选出最优查询。
在BIRD和Spider两个基准测试中评估了该方法。在BIRD基准测试中。准确率和有效效率得分分别达到了65.5%和71.4%，较之前的最佳方法提升了5.9%和3.7%，刷新了BIRD基准测试的最佳性能记录。同时，在Spider测试集中，我们的执行准确率达到了89.6%，**比现有最佳方法提高了3.0%**。
详解MCS-SQL
如上图所示，MCS-SQL分为三个步骤：
• 首先进行架构链接，排除与问题无关的数据库表和列；
• 其次，基于多样的提示生成多个候选SQL查询；
• 最后，从这些候选中挑选出最准确的SQL查询。
架构链接
架构链接的目的是识别数据库中与自然语言问题相关的表和列，排除与问题无关的数据库表和列，以转化为SQL查询。架构链接的引入显著提升了基于微调和基于上下文学习（ICL）方法的性能。
架构链接分为两个阶段：首先是提取与自然语言查询相关的表（表链接），其次是提取这些表中必要的列（列链接）。在这两个阶段中，都采用多个提示来提高召回率。
表链接
在表链接阶段，将数据库架构和问题输入到大语言模型，由其提取生成SQL查询所需的参考表列表。借鉴零样本思维链（zero-shot-CoT）的方法，要求LLM解释每个表的必要性，而不仅仅是选择表的列表。为了便于解析LLM的回答，要求它以JSON格式进行回应。
为了增强表链接的稳定性，采用多个不同的提示。LLM的输出会受到输入句子顺序的影响，同样，LLM的架构链接输出也依赖于提示词中表和列的排列顺序。为了减少表顺序的影响，随机打乱表的顺序，生成不同的提示。对于每个提示，通过高采样温度从LLM获取多个响应。最终的表链接输出是所有返回的并集，这样操作的原因是：如果结果中包含不必要的表不会显著影响后续的SQL生成过程，但遗漏必要的表将阻碍正确SQL查询的生成。
表连接的提示词
### Given a database schema, question, and knowledge evidence, extract a list of tables that should be referenced to convert the question into SQL.
### SQLite SQL tables, with their properties:
# molecule ( molecule_id, label )
# connected ( atom_id, atom_id2, bond_id )
# bond ( bond_id, molecule_id, bond_type )
# atom ( atom_id, molecule_id, element )
#
# atom.molecule_id = molecule.molecule_id
# bond.molecule_id = molecule.molecule_id
# connected.bond_id = bond.bond_id
# connected.atom_id2 = atom.atom_id
# connected.atom_id = atom.atom_id
### Question: Among all chemical compounds identified in the database, what percent of compounds form a triple-bond.
### Knowledge Evidence: triple bond refers to bond_type = ’#’;
You need to not only select the required tables, but also explain in detail why each table is needed.
Your answer should strictly follow the following json format.
{
"reasoning": "", // The reason for choosing each table.
"tables": [], // List of selected tables.
}### Your Answer:列链接
在列链接阶段，要求LLM使用与表链接相似的提示，提取将问题转化为SQL查询所需的列。提示仅包含在表链接阶段选定的表的架构，而非整个数据库架构。由于同一列名可能存在于不同的表中，指示LLM以[表名].列名的格式提供答案。
与表链接相似，随机打乱表和列的顺序，生成多个独特的提示。然后，为每个提示生成LLM的响应，每个响应代表一个选定的列列表。列链接的最终输出是所有响应的并集。
在随后的SQL生成步骤中，向LLM提供的数据库架构仅包括通过架构链接选定的表和列，而非完整的架构。
列链接的提示词
### Given a database schema, question, and knowledge evidence, extract a list of columns that should be referenced to convert the question into SQL.
### SQLite SQL tables, with their properties:
# molecule ( molecule_id, label )
# bond ( bond_id, molecule_id, bond_type )
#
# bond.molecule_id = molecule.molecule_id
### Question: Among all chemical compounds identified in the database, what percent of compounds form a triple-bond.
### Knowledge Evidence: triple bond refers to bond_type = ’#’;
You need to not only select the required columns, but also explain in detail why each column is needed.
Your answer should strictly follow the following json format.
{{
"reasoning": "", // The reason for choosing each column.
"columns": ["table_name_i.column_name_j", ...], // List of selected columns
}}### Your Answer:多样化的SQL生成策略
鉴于大语言模型对提示词的高度敏感性，LLM的输出会因所提供的少量示例及其展示顺序而有显著差异。为了充分利用这种多样性，通过变化少量示例的选择方式及其展示顺序来创造多个提示，确保对可能的SQL查询进行更全面的覆盖。
如何精心挑选少量示例
针对每个测试样本，都从训练集中精心挑选一组少量示例。为生成含有不同示例的多个提示，采用了两种截然不同的策略：
• 一种基于问题的相似性
• 另一种则基于Masked问题的相似性
在基于问题相似性的方法中，筛选出训练集中与测试样本自然语言问题的句子嵌入最为接近的前k个问题。
同样，基于掩蔽问题相似性的方法则着眼于掩蔽问题间的嵌入相似性，这里的掩蔽问题指的是将问题中与数据库架构相关的标记隐藏起来。这种掩蔽技术能够在忽略架构特定内容的情况下，判断问题在生成相似查询方面的相似度。利用LLM进行掩蔽处理，向其提供数据库架构和问题，并指示其用特殊标记替换表名、列名和值。掩蔽问题的提示词如下：
### Given a DB schema and a question, mask the table name, column name, and values in the question.
<example1>
### SQLite SQL tables, with their properties:
# customers ( CustomerID: integer, Segment: text, Currency: text )
# gasstations ( GasStationID: integer, ChainID: integer, Country: text, Segment: text )
# products ( ProductID: integer, Description: text )
# transactions_1k ( TransactionID: integer, Date: date, Time: text, CustomerID: integer, CardID: integer, GasStationID: integer, ProductID: integer, Amount: integer, Price: real )
# yearmonth ( CustomerID: integer, Date: text, Consumption: real )
### Question: For all the people who paid more than 29.00 per unit of product id No.5. Give their consumption status in the August of 2012.
### Masked Question: For all the [TABLE] who paid more than [VALUE] per unit of [COLUMN] [VALUE]. Give their consumption status in the [VALUE].
</example1>
<example2>
### SQLite SQL tables, with their properties:
# customers ( CustomerID: integer, Segment: text, Currency: text )
# gasstations ( GasStationID: integer, ChainID: integer, Country: text, Segment: text )
# products ( ProductID: integer, Description: text )
# transactions_1k ( TransactionID: integer, Date: date, Time: text, CustomerID: integer, CardID: integer, GasStationID: integer, ProductID: integer, Amount: integer, Price: real )
# yearmonth ( CustomerID: integer, Date: text, Consumption: real )
### Question: How much did customer 6 consume in total between August and November 2013?
### Masked Question: How much did [TABLE] [VALUE] consume in total between [VALUE] and [VALUE]?
</example2>
<example3>
### SQLite SQL tables, with their properties:
# drivers ( driverId: integer, driverRef: text, number: integer, code: text, forename: text, surname: text, dob: date, nationality: text, url: text )
### Question: How many Australian drivers who were born in 1980?
### Masked Question: How many [VALUE] [TABLE] who were born in [VALUE]?
</example3>
### SQLite SQL tables, with their properties:
# molecule ( molecule_id, label )
# bond ( bond_id, molecule_id, bond_type )
#
# bond.molecule_id = molecule.molecule_id
### Question: Among all chemical compounds identified in the database, what percent of compounds form a triple-bond.
### Knowledge Evidence: triple bond refers to bond_type = ’#’;### Masked Question:通过这两种策略，生成了多个不同的提示，包括完全基于问题相似性的、完全基于掩蔽问题相似性的，以及结合两种策略、以不同序列整合示例生成的额外提示。
SQL生成提示涵盖了少量示例、数据库架构、样本表内容及自然语言问题。
少量示例由问题及其对应的标准SQL对组成。为了节省提示的有限空间，没有包含每个问题的数据库架构。在数据库架构方面，仅展示在架构链接阶段选定的表和列，避免给LLM带来无关信息的负担。此外，在提示中嵌入了CSV格式的样本表内容，帮助LLM理解每列中的潜在值，为其提供数据库数据结构的实际见解。最后，不仅要求LLM生成SQL查询，还要求其解释生成逻辑，以提升模型的可解释性和准确性。
对于每个提示，采用高采样温度从LLM获取响应，最终生成了多个候选SQL查询。
精选查询
精选步骤旨在从众多候选查询中筛选出最为精确的一条。首先，根据置信度评分对候选查询池进行初步筛选，然后交由大语言模型（LLM）从筛选后的查询池中精选出最为准确的一条。
候选查询筛选
为了在众多候选中甄别出最准确的查询，首先对候选查询池进行精简。将执行结果一致的查询归类，并在每类中仅保留执行速度最快的查询。同时，那些置信度评分较低的查询将被排除在候选之外。
具体操作上，会在数据库上执行所有候选查询，并将那些导致语法错误或超时的查询从候选池中剔除。随后，会计算候选池中每个查询的置信度，这一评分基于产出相同执行结果的查询数量。具体来说，对于包含n个查询的候选池{q1,...,qn}，qi的置信度为执行结果与qi一致的查询数量除以n。
多选择筛选（MCS）
经过初步筛选，采用大语言模型来执行多项选择，以从候选查询中挑选出最为精确的一条。
### For a given DB schema and question, select the most accurate query among the candidate SQL queries.
### DB schema: ...
### Question: ...
### Candidate SQLs:
1. SQL1
2. SQL2
3. SQL3
Your answer should be in the json format:
{
"reasoning": ".." # The reasoning steps for selecting the correct SQL query.
"sql": ".." # The selected SQL query.
}### Your answer:将一系列候选的SQL查询展示给LLM，并要求它针对特定的数据库架构和问题选出最合适的查询。为了顺应LLM倾向于优先考虑多项选择中靠前选项的行为，按照置信度分数从高到低的顺序排列候选查询。
LLM不仅需要选出一个SQL查询，还必须提供其选择的理由。从LLM获取多个响应，并通过多数投票的方式来确定最终的SQL查询。
效果评估方法
评估数据集
Spider
Spider（Yu等人，2018）是一个包含10,181个问题和5,693个独特查询的大型复杂跨领域文本到SQL的基准测试，覆盖了200个数据库，每个数据库都包含多个表。该基准测试要求模型能够适应未曾见过的数据库架构，因为训练和测试阶段使用的数据库是不同的。
BIRD
BIRD（Li等人，2023c）是一个新的大规模跨领域文本到SQL基准测试，包含12,751个独特的问题-SQL配对，涵盖95个大型真实世界数据库。与Spider相比，BIRD包含了更加复杂的SQL查询，使用了更多样的SQL关键字（如LEFT JOIN, PARTITION BY等）和函数（如IIF, CASE, ROUND等），这些在Spider中并未涉及。此外，BIRD还要求模型能够利用外部知识（例如同义词知识与数值示例）进行推理，以生成准确的SQL查询。
评估指标
执行准确率（EX）
执行准确率（EX）用来衡量模型生成的SQL执行结果是否与标准SQL查询完全一致。由于相同的SQL结果可以有多种不同的写法，基于字符串匹配的评估方法可能会显著低估模型的实际性能。
有效效率得分（VES）
在BIRD数据集的评估中，Li等人（2023c）引入了一个新的评估指标——有效效率得分（VES），它根据执行时间来衡量一个有效模型生成查询的效率。如果一个查询的执行结果与标准SQL不一致，那么这个查询将被视为无效，并得到零分。因此，VES综合考虑了模型生成查询的准确性和执行效率。
测评结果
主要成果
BIRD
上表展示了在BIRD开发和测试数据集上，MCS-SQL与基线模型在执行准确率（EX）和有效效率得分（VES）上的表现。结果显示，MCS-SQL在两个评价指标上均显著超越了现有的基于上下文学习（ICL）的方法。
具体来说，MCS-SQL在测试集上的执行准确率达到了65.45%，有效效率得分为71.35%，分别比先前最高标准的方法（Wang等人，2023a）提升了5.86%和3.67%。此外，MCS-SQL在BIRD数据集上刷新了最高标准，执行准确率和有效效率得分分别提高了4.74%和3.67%。
Spider
上表展示了在Spider开发和测试数据集上，MCS-SQL和基线方法在执行准确率（EX）上的表现。与BIRD的结果相似，MCS-SQL在所有基于ICL的方法中表现突出。特别是在开发集上，MCS-SQL准确率达到了89.5%，比之前的最高标准方法提升了2.7%。
为了探究MCS-SQL每个组成部分对执行准确率（EX）的增量影响，进行了消融研究。
上表展示了在BIRD开发数据集上的消融结果。
• 在基线的零样本设置中加入架构链接，使得性能提升了2.1%。这一点强调了在生成SQL之前对架构进行精细化处理的重要性，并显示了架构链接过程在有效选择相关表和列方面的能力。
• 在提示中进一步包含样本表内容，使得增益提升了2.4%。
• 引入基于掩蔽问题相似性动态选择的少量示例，带来了最大的性能提升，达到了4.8%。
• 此外，使用相同的提示从大语言模型中采样多个答案，并采用提出的多项选择（MCS）方法时，性能又提升了2.1%。这证明了提出的SQL选择方法在从候选集合中辨别和挑选最准确查询方面的能力。
• 最后，引入多个提示进一步增强了性能，提升了1.3%，特别是在处理复杂查询时表现尤为明显。这一改进显示了使用多样化提示扩大搜索空间显著增强了SQL生成的准确性。
上表列出了Spider开发数据集上的消融结果，显然，MCS-SQL的每个组成部分都对性能提升做出了显著贡献，与BIRD的结果相似。这种在不同基准测试中的一致性性能提升，证实了MCS-SQL在文本到SQL任务中的有效性和适应性。
多提示在架构链接中的应用影响
通过对比分析三种不同情况，探究了在架构链接中使用多个提示的效果：
• (1) 使用单一提示的贪婪解码方式；
• (2) 从单一提示生成的多个答案取并集；
• (3) 从多个提示生成的多个答案取并集。
采用同一提示生成多个响应并进行聚合，在BIRD数据集上实现了15.8%的性能提升，在Spider数据集上实现了4.7%的提升。
更进一步，结合使用多个提示带来了更显著的改进，BIRD数据集上提升了12.7%，Spider数据集上提升了2.7%。
这些数据表明，提示中表和列的排列顺序对LLM的架构链接结果有影响，而MCS-SQL多提示方法有效降低了这种敏感性。尤其在BIRD数据集上，这种改进更为明显，暗示着对于更大更复杂的数据库架构，多提示方法的效果更佳。
由于架构链接阶段若遗漏了必要的表或列，后续流程就无法生成准确的SQL查询，因此我们提出的综合多个提示生成的多种响应的方法，对于提升SQL生成的性能至关重要。
不同少量示例选择策略的影响
上表展示了采用不同少量示例选择策略时的执行准确率（EX）。相比随机选择，基于问题相似性选择少量示例的方法在BIRD数据集上提升了2.3%，在Spider数据集上提升了4.2%。此外，选择过程基于掩蔽后的问题相似性而非原始问题，使得性能在BIRD和Spider数据集上分别进一步增强了0.7%和0.5%。
多项选择（MCS）的影响
在SQL选择阶段，通过大语言模型实现的多项选择（MCS）方法是否比简单多数投票法（选择置信度最高的查询）更为高效。上表显示，MCS方法在BIRD和Spider数据集上分别以0.6%和0.3%的优势超越了多数投票法。值得注意的是，如果没有置信度过滤，MCS方法的效果会显著下降。这一发现强调了在使用MCS时结合置信度过滤来有效缩小候选查询集合的重要性。
结论
今天这篇论文提出了一种创新方法，通过多个提示增强基于上下文学习（ICL）的文本到SQL生成的精确性和稳定性。具体而言，该方法运用不同的提示进行稳固的架构链接。同时，采用多样的少量示例选择策略，用以生成多个查询生成提示，进而产生众多候选SQL查询。这些候选查询随后根据各自的置信度分数进行筛选，并通过大语言模型Agent应用（LLM）结合多项选择（MCS）策略挑选出最优查询。在BIRD和Spider两大基准测试上的评估显示，该方法在性能上显著超越了现有的基于ICL的方法，并在BIRD测试中刷新了最佳成绩，达到了新的行业领先水平。
