大语言模型（LLMs）已成为Text-to-SQL任务的一种新范式。然而，由于缺乏系统的基准测试，对于设计有效、高效且经济的基于大语言模型的Text-to-SQL解决方案的发展受到了阻碍。为了应对这一挑战，本文首先对现有的提示工程方法进行了系统而广泛的比较，包括问题表示、示例选择和示例组织，并根据这些实验结果阐述了它们的优缺点。基于这些发现，本文提出了一种新的集成解决方案，名为DAIL-SQL，它以86.6%的执行准确率刷新了Spider排行榜，树立了新的标杆。

同时，为了探索开源大语言模型的潜力，实验在各种场景中对它们进行了研究，并通过监督微调进一步提升了它们的性能，突出了开源大语言模型在Text-to-SQL任务中的潜力，以及监督微调的优缺点。此外，为了实现高效且经济的基于大语言模型的Text-to-SQL解决方案，本文强调了提示工程中的词元效率，并在此指标下对先前的研究进行了比较。本工作旨在让人们对使用大语言模型的Text-to-SQL任务有更深入的理解，并启发进一步的研究和广泛的应用。

1. 研究背景与动机

1.1 Text-to-SQL任务的兴起

Text-to-SQL任务是自然语言处理和数据库领域中一项具有挑战性的任务，它将给定关系数据库上的自然语言问题映射为SQL查询。之前大多数工作都侧重于提取问题到SQL的模式，并通过使用Text-to-SQL语料库训练编码器-解码器模型来进行泛化。近年来，大语言模型（LLMs）成为了Text-to-SQL任务的一种新范式。比如，GPT-4在Spider排行榜上以85.3%的执行准确率位居榜首。与先前的研究不同，基于大语言模型的Text-to-SQL解决方案的核心问题是如何促使大语言模型生成正确的SQL查询，即提示工程。这种提示工程涉及问题表示、示例选择和示例组织。

1.2 Text-to-SQL的提示工程需要系统的研究

尽管先前的研究取得了显著进展，但对于基于大语言模型的Text-to-SQL解决方案中的提示工程，仍然缺乏系统的研究，主要分为对问题表示，示例选择和示例组织三个方面：

1. 在问题表示方面：大多数现有研究将结构化知识文本化为模式，并进一步添加任务指令和外键来形成提示。此外，一些研究将表表示为几个“CREATE TABLE”SQL语句，并在注释中促使大语言模型回答目标问题。然而，即使表示方式相似，它们详细的任务指令也可能导致显著的性能差异。因此，迫切需要对不同的表示方式进行系统研究，并探究如何与大语言模型更好地配合。

2. 在示例选择方面：常见的做法是对与目标问题具有相同表示形式的最相似示例进行编码。一些研究者如Nan等人进一步强调了示例选择中多样性的重要性。

3. 在示例组织方面：大多数先前的研究使用完整信息来表示示例，包括指令、模式、问题和正确的SQL查询。一些研究只在选定的示例中保留SQL查询，以较少的词元数来引导大语言模型。再加上不同大语言模型的偏好，基于大语言模型的Text-to-SQL解决方案中最优的选择和组织策略仍不明确。因此，对提示工程进行系统研究，涵盖不同的大语言模型、问题表示、示例选择和组织，是非常有必要的。

1.3 开源大语言模型的潜力尚未得到充分挖掘

最近，开源大语言模型不断发展，在编程、数学推理和文本生成任务中取得了显著进展。然而，以前的Text-to-SQL研究主要集中在OpenAI的大语言模型上，而对开源大语言模型的研究较少。此外，与OpenAI的大语言模型相比，开源大语言模型在理解上下文和生成连贯响应方面通常功能有限。因此，开源大语言模型面临的一个关键挑战是进一步提升它们在Text-to-SQL任务中的性能，这可以通过监督微调来实现。

1.4 提示效率仍然是一个具有挑战性的开放问题

在基于大语言模型的Text-to-SQL任务中，除了提升性能，另一个关键挑战是效率。原因是大多数先前的研究集中在OpenAI的大语言模型上，调用它们的API成本高昂、耗时且有速率限制，特别是对于包含多个示例的上下文学习提示。尽管已有一些研究推测大语言模型在提示长度方面可能存在一个最佳点，但如何探索高效的提示工程仍然是一个具有挑战性的开放问题。

1.5 提出基于大语言模型的Text-to-SQL任务的基准

鉴于上述挑战，本文为基于大语言模型的Text-to-SQL任务提供一个全面、系统且公平的基准。该基准测试讨论了各种提示工程策略的有效性和效率，以及开源大语言模型的可行性：

1. 为了对Text-to-SQL的提示工程有一个系统而深入的理解，本文首先评估了先前研究中的几种策略。首先，在零样本场景下，使用不同的大语言模型比较了几种典型的问题表示方式，并确定了它们的优缺点。之后，本文研究了少样本场景下的示例选择和组织策略。

2. 之后，本文探索了开源大语言模型在上下文学习和监督微调方面的潜力。作者实证研究了使用不同提示工程策略的各种开源大语言模型，通过对开源大语言模型进行微调并评估比较，证明了表示策略对于监督微调也至关重要。这些探索强调了一种有效的Text-to-SQL解决方案的潜力，将有益于实际的Text-to-SQL应用。

3. 为了实现更经济高效的解决方案，本文进一步根据词元效率评估不同的策略。具有成本效益策略应能以较少的词元数实现可观的性能。作者在提示工程的整个过程中考虑词元效率，包括问题表示、示例选择和组织的选择。

4. 最后，本文提出的集成解决方案DAIL-SQL以86.6%的执行准确率刷新了Spider排行榜的最佳表现。DAIL-SQL将结构知识编码为SQL语句，根据框架相似性选择示例，并从示例中删除跨域知识以提高词元效率。DAIL-SQL树立了新的标杆，以激发更多的后续工作。

2. 预备知识

Text-to-SQL旨在将自然语言问题自动转换为SQL查询。它弥合了非专业用户与数据库系统之间的差距，大大提高了数据处理的效率，并为智能数据库服务、自动数据分析和数据库问答等更广泛的应用做出了贡献。然而，由于难以完全理解自然语言问题并生成正确的SQL查询，Text-to-SQL仍然是一项极具挑战性的任务。

数据库和自然语言处理领域都对Text-to-SQL进行了广泛的研究：

1. 早期的研究通过预定义规则或查询枚举来处理Text-to-SQL任务，或者将其视为一个序列到序列的任务，专注于使用编码器-解码器架构训练机器学习模型。随着深度学习的迅速发展，注意力机制、图表示、语法解析等技术被应用于Text-to-SQL任务。最具代表性的之一是BERT，在当时取得了最先进的性能。此外，为了缩小Text-to-SQL研究与实际应用之间的差距，许多大规模的基准数据集被发布，包括WikiSQL、Spider、KaggleDBQA、BIRD等。

2. 最近，大语言模型（LLMs），如OpenAI的GPT-4和Meta的 LLaMA，成为了自然语言处理和机器学习的一个里程碑。大语言模型在大规模文本语料库上进行预训练，能够执行各种自然语言任务。其基本操作原理是根据输入提示逐步生成概率最高的下一个单词。因此，为了使用大语言模型处理Text-to-SQL任务，核心是找到最优的提示，也称为提示工程。

根据提示中提供的示例数量，提示工程可分为两种场景：零样本场景和少样本场景：

1. 零样本场景：在此场景中，不提供任何示例，主要挑战是如何有效地表示自然语言问题，包括整合相关信息（如相应的数据库模式）。本文中将自然语言问题和相关信息进行表示的过程称为问题表示。

2. 少样本场景：在此场景中，可以利用有限数量的示例，因此除了问题表示之外，还需要研究如何选择最有帮助的示例，并在提示中适当地组织它们。在自然语言处理中，大语言模型从上下文示例中学习的过程被称为上下文学习。它使大语言模型能够从输入提示中识别显式或隐式模式，并生成相应的输出。通过这种方式，大语言模型在推理过程中无需任何特定任务的训练阶段就能完成新任务。本文中将在示例选择和示例组织中来讨论上下文学习。

尽管先前的研究表明，大语言模型在零样本和少样本场景中都有效，但它们的性能可以通过监督微调（SFT）进一步提升。监督微调通过使用额外的特定任务训练数据来增强大语言模型，使其更适合特定的下游任务。在最近的研究中，监督微调被用作一种对齐训练范式，使大语言模型的行为更加规范，避免生成冒犯性、有偏见的响应和幻觉内容。本文将专注于使用监督微调来增强大语言模型在Text-to-SQL任务中的能力。目前探索大语言模型在Text-to-SQL任务中监督微调的研究却很少，是一个有待研究的领域。

综上所述，问题表示、上下文学习和监督微调是基于大语言模型的Text-to-SQL的三个关键要素。本文中将对它们进行系统的研究和讨论。

3. 方法论

本文主要关注问题表示、上下文学习和监督微调。本节将对这三个问题进行形式化定义，系统地调研它们现有的解决方案，并指出现有技术中存在的潜在问题。为了解决这些问题，本文提出了一种新的Text-to-SQL提示工程方法，名为DAIL-SQL。

3.1 问题表示

在本节中，首先讨论Text-to-SQL在零样本场景下的问题表示。考虑在特定数据库D上的自然语言目标问题q，问题表示的目标是最大化大语言模型M生成正确的SQL的可能性，如下所示：

其中函数决定目标问题q的表示形式，它包含来自数据库D模式的有用信息,还可以包括指令语句、规则暗示和外键等信息。

根据上述定义，本文调研了零样本场景下的不同选择，并从文献中选取了五种具有代表性的问题表示，如表所示。

五种现有工作中问题表示的方法

1. 基本提示（）：基本提示是一种简单的表示形式。它由表模式、前缀为“Q:”的自然语言问题和用于促使大语言模型生成SQL的响应前缀“A: SELECT”组成。在本文中将其命名为基本提示。

基本提示示例

2. 文本表示提示（）：文本表示提示用自然语言表示模式和问题。与基本提示相比，它在提示开头添加了指令来引导大语言模型。一些研究中在零样本场景下的Spider-dev数据集上实现了69.0%的执行准确率。

文本表示提示示例

3. OpenAI演示提示（）：OpenAI演示提示由指令、表模式和问题组成，所有信息都用井号“#”注释。与文本表示提示相比，OpenAI演示提示中的指令更具体，并且包含一条规则：“仅完成sqlite SQL查询，无任何解释”。

OpenAI演示提示示例

4. 代码表示提示（）：代码表示提示以SQL语法呈现Text-to-SQL任务。它直接呈现“CREATE TABLE”SQL语句，并在注释中用自然语言问题促使大语言模型。的特点在于它能够提供数据库创建所需的全面信息，如列类型和主键/外键。这种表示方法在使用大语言模型CODE-DAVINCI-002时正确预测了约75.6%的SQL查询。

代码表示提示示例

5. Alpaca SFT提示(): Alpaca SFT提示是一个专为监督微调而设计的提示。它提示LLM按照指示并根据Markdown格式的输入上下文完成任务。

Alpaca SFT提示示例

由于不同的表示方法在不同的大语言模型上进行了实验，并集成在不同的框架中，这使得难以公平有效地对它们进行比较。此外，诸如外键信息和规则暗示等单个组件所起的具体作用仍不明确。因此，对于这些表示方法有必要进行系统的研究，通过公平的比较来探究它们的优缺点。

3.2 Text-to-SQL的上下文学习

除了上述表示方法，大语言模型通过上下文学习在Text-to-SQL任务中可以表现得更好，在上下文学习中，输入提示中仅提供少量示例

本小节中将讨论上下文学习的关键，即示例选择和示例组织。

上下文学习学习表示如下：

在Text-to-SQL任务中，给定一组三元组，其中和是数据库上的自然语言问题及其对应的SQL查询。

Text-to-SQL的上下文学习目标是最大化大语言模型M针对目标问题q和数据库D生成正确SQL的可能性：

其中函数决定目标问题q的表示形式，它包含来自数据库D模式的有用信息以及从Q中选择的k个示例。在本文中，目标数据库D不包含在Q中提到的数据库之中。Text-to-SQL的上下文学习涉及选择最有帮助的示例，并决定如何将这些选定示例的信息组织到提示中。

3.2.1 示例选择

先前研究中的各种示例选择策略主要有如下：

1. 随机选择（Random）：该策略从可用候选示例中随机抽取k个示例。先前的工作已将其用作示例选择的基线方法。

2. 问题相似性选择（）：选择与目标问题最相似的k个示例。它使用预训练的语言模型对Q中的示例问题和目标问题q进行嵌入，然后对每个（示例-目标）对应用欧几里得距离/余弦相似度度量。最后，利用k-近邻（kNN）算法从Q中选择与目标问题q紧密匹配的k个示例。

3. 掩码问题相似性选择（）：通过用掩码标记替换所有问题中的表名、列名和值，消除特定领域信息的负面影响，然后使用kNN算法计算它们的嵌入相似度。

4. 查询相似性选择（）：旨在选择与目标SQL查询相似的k个示例。它使用一个初步模型，根据目标问题q和数据库D生成SQL查询，这个生成的可以看作是的近似值。然后，它根据关键词,将示例中的查询编码为二进制离散语法向量。之后，通过考虑与近似查询的相似度以及所选示例的多样性来选择k个示例。

上述的策略仅仅侧重于使用目标问题或查询来选择示例。然而，上下文学习本质上是通过类比进行学习。在Text-to-SQL的情况下，目标是生成与给定问题匹配的查询，大语言模型应该学习从问题到SQL查询的映射。因此，在示例选择过程中，同时考虑问题和SQL查询可能会对Text-to-SQL任务有益。

3.2.2 示例组织

示例组织能够决定如何将上述选定示例的哪些信息组织到提示中。本文将先前研究中的现有策略总结为两类：完整信息组织和仅SQL组织。在这些示例中，${DATABASE_SCHEMA}表示数据库模式，${TARGET_QUESTION}代表问题表示形式。

1. 完整信息组织（）：以与目标问题相同的表示形式来组织示例。示例的结构与目标问题完全相同，唯一的区别是在“SELECT”后面，选定的示例是相应的SQL查询，并非“SELECT”词元。

完整信息组织示例

2. 仅SQL组织（）：在提示中仅包含选定示例的SQL查询，并带有一个前缀指。这种组织方式在有限的词元长度内最大化示例的数量，但是删除了问题与相应SQL查询之间的映射信息。

仅SQL组织示例

3.3 DAIL-SQL

为了解决上述示例选择和组织中存在的问题，本文提出了一种新颖的Text-to-SQL方法，名为DAIL-SQL。

DAIL-SQL的伪代码

在示例选择方面，本文提出了DAIL选择（），以同时考虑问题和查询来选择候选示例：

● DAIL选择首先在目标问题q和候选集Q中的示例问题中mask与数据库相关的单词。

● 然后，它根据掩码后的q和的嵌入之间的欧几里得距离对候选示例进行排序。同时，它计算预先预测的SQL查询与Q中的之间的查询相似度。

● 最后，DALI选择标准优先考虑排序后的候选示例中查询相似度大于预定义阈值
的示例。

通过这种方式，选定的前k个示例在问题和查询方面都具有良好的相似性。

为了保留问题和SQL查询之间的映射信息，同时提高词元效率，本文还提出了一种新的示例组织策略DAIL组织（），以在质量和数量之间进行权衡。同时呈现问题和相应的SQL查询。不同于之前的策略，保留了问题-SQL之间的映射，并通过删除耗费词元的数据库模式来减少示例的词元长度。

策略示例

在DAIL-SQL中采用作为问题表示。与其他表示方法相比，包含数据库的完整信息，包括主键和外键，这可能为大语言模型提供更多有用信息。此外，由于大语言模型在广泛的编码语料库上进行了预训练，它们可以更轻松地理解中的提示，而无需太多额外努力。

综上所述，DAIL-SQL使用作为问题表示，根据问题和查询的信息选择示例，并组织示例以保持问题到SQL的映射。在这种提示设计下，大语言模型可以更好地处理Text-to-SQL任务。

3.4 Text-to-SQL的监督微调

为了提升大语言模型在零样本场景下的性能，现有Text-to-SQL方法中常用的选择是上下文学。然而，监督微调目前尚未得到充分探索。与各种语言任务的监督微调类似，本文将其应用于Text-to-SQL领域，以提高大语言模型在这个下游任务上的性能。监督微调在Text-to-SQL任务中的工作原理如下：

对于Text-to-SQL任务，给定一个大语言模型M，一组Text-to-SQL训练数据，其中和是数据库D上的自然语言问题及其对应的查询，监督微调的目标是最小化以下经验损失：

其中L是衡量生成的查询与真实查询之间差异的损失函数。与问题表示类似，决定了包含来自数据库D模式有用信息的问题表示形式。在这个定义中，Text-to-SQL的监督微调涵盖两个子任务，包括使用监督数据T对给定的大语言模型M进行微调以获得最优的大语言模型，以及搜索最优的问题表示。

对于一般领域，监督数据中的每个项目都包含一个输入提示和大语言模型的预期响应。为了确保与推理过程的一致性，本文采用一种监督微调方法，并从给定的Text-to-SQL数据集中生成（提示-响应）对。

具体来说，给定一个Text-to-SQL数据集，本文中使用目标问题和给定的数据库作为提示，将期望的查询作为大语言模型的响应，从而生成微调数据来微调大语言模型，即。然后使用现有的工具包通过全量微调或参数高效微调对给定的大语言模型M进行微调。微调之后，优化后的大语言模型可用于推理，即通过自然语言问题让它生成查询。在微调过程和推理过程中,使用相同的问题表示。

4. 实验

4.1 实验设置

1. 数据集：实验在两个公认的数据集Spider和Spider-Realistic上评估Text-to-SQL方法。

● Spider：是一个大规模的跨域Text-to-SQL数据集，其中每个实例由特定数据库上的自然语言问题及其相应的SQL查询组成。在本文中，由于测试集未发布，使用开发集Spider-dev进行评估。

● Spider-Realistic：是Spider的一个更具挑战性的变体。它从 Spider-dev中选择了508个示例，并在保持SQL查询不变的情况下手动修改了问题。

2. 评估指标：为了进行公平比较，评价指标使用精确集匹配准确率（EM）和执行准确率（EX）。

● 精确集匹配准确率（EM）：衡量预测的SQL查询与相应真实查询之间匹配的SQL关键词。

● 执行准确率（EX）：该指标比较预测的SQL查询和真实SQL查询在某些数据库实例上的执行输出。由于单个问题可能有多个有效的SQL查询，这个指标能更精确地评估模型的性能。

3. 大语言模型：对于所有方法，实验使用相同的最大上下文长度，即对于OpenAI大语言模型为4096，开源大语言模型为2048。在评估过程中，实验预留200个词元用于响应生成。默认情况下，温度参数被设置为0，以消除随机性的影响。在后期处理方面，实验遵循现有工作，提取响应中的第一个SQL查询并删除额外输出。

4.2 问题表示

在本小节中，实验在零样本场景下评估3.1节中提出的问题表示方法，使用四个大语言模型：GPT-4、GPT-3.5-TURBO、TEXT-DAVINCI-003和Vicuna-33B。

在零样本场景下各个问题表示方法的效果

图中展示了在Spider-dev数据集上不同问题表示方法的比较结果。通过比较不同的表示方法可以观察到：

1. 适用于所有四个大语言模型，并且在使用GPT-3.5-TURBO时达到了75.5%的执行准确率。

2. 相比之下，在与GPT-3.5-TURBO、TEXT-DAVINCI-003和Vicuna-33B配合使用时表现不佳，这表明它需要一个合适的大语言模型才能发挥良好效果。

3. GPT-4与结合时效果较好，这表明强大的大语言模型可以减轻表示设计带来的复杂性。

4. 通过比较四个大语言模型的平均性能，可以看出，GPT-4和GPT-3.5-TURBO在零样本场景中表现更出色。由于GPT-4的成本较高，GPT-3.5-TURBO与OD��的组合可能是零样本场景下更好的选择。对于功能较弱的大语言模型，如TEXT-DAVINCI-003和Vicuna-33B，和这两种表示方法更受青睐。

消融实验：

● 外键（FK）：外键暗示了不同关系表之间的关系，这在Text-to-SQL任务中可能会有所帮助。在所有方法中，只有包含外键信息。为了检验其效果，实验将外键信息添加到其他表示方法中。

对于OpenAI的大语言模型，实验表明到外键显著提高了大语言模型的执行准确率，提升幅度在0.6%-2.9%之间，但少数组合（如与GPT-4的组合、与TEXT-DAVINCI-003的组合）除外。然而，外键对Vicuna-33B的影响往往不稳定。添加外键使的性能有了惊人的5.0%的提升，但却对和的性能产生了负面影响。

消融实验—外键

● 规则暗示（RI）：受出色表现的启发，实验探索了规则暗示的效果。促使大语言模型生成“无需解释”的SQL查询。为了检验问题表示中“无需解释”规则的效果，实验研究了包含该规则暗示后不同表示的性能以及准确率的变化。

消融实验—规则暗示

实验结果表明，添加此规则始终能提高所有大语言模型在精确匹配和执行准确率方面的性能，其中最显著的提升分别超过6%和3%。而对于，去除此规则会导致精确匹配准确率和执行准确率均下降，这表明了该规则暗示的重要性。

总之，外键和“无需解释”的暗示规则都对Text-to-SQL任务有益。在实验评估中，带有外键的与GPT-3.5-TURBO的组合是最有效且经济的，实现了51.5%的精确匹配准确率和78.4%的执行准确率。

4.3 Tex-to-SQL的上下文学习

实验在少样本场景中使用GPT-4、GPT-3.5-TURBO、TEXT-DAVINCI-003和Vicuna-33B来检验不同的示例选择和组织策略。为确保公平比较，本小节的所有实验中都采用作为问题表示。

4.3.1 示例选择

为验证问题和查询在示例选择中的重要性，实验计算所选示例与目标实例之间问题的Jaccard相似度和查询的Jaccard相似度。

不同的示例选择策略的比较结果

表格展示了在Spider-dev数据集上少样本场景下不同示例选择策略的比较。通过比较不同的选择策略，结果表明通常优于其他策略。在5样本场景下，配备GPT-4的DAIL-SQL实现了82.4%的执行准确率。此外，从表格中可以观察到，问题相似度和查询相似度的提高大多对应着更高的执行准确率，这表明同时考虑问题和查询相似度的重要性。但是，的执行准确率仍低于上限。这种差异可归因于查询相似度较低，这表明真实查询与初步模型生成的查询之间存在差距。

4.3.2 示例组织

实验为比较不同的示例组织策略，在Spider-dev和Spider-Realistic数据集的少样本场景中评估了完整信息组织（）、仅SQL组织（）和DAIL组织（）。

不同的示例组织的比较结果

通过比较不同的组织策略，实验发现：

● GPT-4在Spider-dev和Spider-Realistic 数据集上都偏向于DAIL组织，这表明它能够有效地从（问题-SQL）对中学习映射关系。

● 对于GPT-3.5-TURBO，它在上下文学习中得到的提升是四个大语言模型中最小，这是由于其上下文学习能力较弱。

● 对于TEXT-DAVINCI-003，完整信息组织在所有策略中表现最佳，尤其是随着示例数量的增加。

● 在Vicuna-33B的情况下，DAIL组织优于仅SQL组织，但仍不及完整信息组织的性能。

通过比较不同的大语言模型，本文推断对于上下文学习能力较强的大语言模型，如GPT-4，从DAIL组织中受益最大，而较弱的大语言模型则需要更多信息来从示例中学习。

综上所述，对于示例选择，实验强调了从问题到SQL查询映射的重要性，同时考虑问题和查询相似度的优于其他选择策略；对于示例组织，实验展示了的有效性，并指出了它对强大大语言模型的需求。最后，当DAIL-SQL配备GPT-4后，在Spider-dev上和Spider-Realistic都达到了最高性能。

4.3 Tex-to-SQL的监督微调

实验在本节研究Text-to-SQL中的监督微调，重点放在开源大语言模型上。鉴于很少有现有工作采用开源大语言模型且其性能未知的情况，实验首先使用各种问题表示、示例选择和组织策略，对开源大语言模型进行全面评估。之后，实验对Text-to-SQL的开源大语言模型进行微调，并观察它们在零样本和少样本场景中的性能提升。

4.4.1 开源大语言模型

为探究开源大语言模型的潜力，实验选择了LLaMA及其不同规模的对齐变体：

● LLaMA-7B/13B/33B是由Meta在大规模语料库上预训练的一组广泛认可的开源大语言模型。

● Falcon-40B仅在经过提炼的网络数据大规模语料库上进行预训练。

● Alpaca-7B是LLaMA-7B的对齐版本，使用由TEXT-DAVINCI-003生成的5.2万个遵循指令的数据进行微调。

● GPT4ALL-7B是LLaMA-7B的另一个对齐版本，使用约80万个数据进行训练，旨在打造有帮助、无害且诚实的人工智能助手。

● LLaMA-2-CHAT-7B/13B/70B是LLaMA的最新版本。它们都经过预训练和对齐，在大多数基准测试中表现优于先前版本。

● Vicuna-7/13/33B是一组基于用户共享对话从LLaMA对齐而来的开源聊天机器人。

● CodeLLaMA-34B是LLaMA-2 34B的对齐版本，使用5000亿个代码数据词元进行微调。

4.4.2 开源大语言模型的零样本场景

开源大语言模型在零样本场景下的性能结果

实验展示了大语言模型在Spider-dev数据集上使用不同问题表示的零样本性能，并从问题表示、模型规模和对齐等方面进行分析：

1. 问题表示的影响：在Spider-dev数据集上，取得了最佳性能，执行准确率达到68.5%。这可能是因为中的完整数据库知识弥补了开源大语言模型的能力不足。倾向于激发大语言模型的编码能力。这种效果在CodeLLaMA-34B中尤为明显，它在使用时执行准确率仅为40.3%。

2. 模型规模的影响：在Text-to-SQL任务中，LLaMA和Vicuna的模型规模与性能之间存在正相关关系。具体来说，LLaMA在Spider-dev上的平均执行匹配准确率从9.1%显著提升到34.0%，Vicuna也呈现出类似的上升趋势。参数数量最多的LLaMA-2-CHAT-70B平均性能也得到提升。在更具挑战性的Spider-Realistic数据集上，也可以观察到相同的特征。

3. 对齐的影响：另一方面，大语言模型的对齐对Text-to-SQL任务有益。具体来说，在相同模型规模下，Vicuna在Spider-dev和Spider-Realistic数据集上的执行准确率比LLaMA高出约5%。对于Falcon-40B，它在所有表示方法下表现都不佳，这归因于其训练数据集中缺乏专门的代码数据。相比之下，在对齐阶段经过精心收集代码数据的CodeLLaMA-34B，在相似模型规模下，在Text-to-SQL任务中表现出显著的提升。

总而言之，大语言模型中更多的参数可能对Text-to-SQL任务有一定的潜在好处，但训练语料库（例如包含特定任务的训练数据）起着更关键的作用。

4.4.3 开源大语言模型的少样本场景

对于少样本场景，实验展示了使用的LLaMA-33B和Vicuna-33B 的性能。实验使用来选择示例，

开源大语言模型在少样本场景下的性能结果

从图中可以看出，LLaMA-33B比Vicuna-33B受益更多，在5样本完整信息组织示例下，达到了36.4%的精确集匹配准确率。关于执行匹配准确率，在大多数情况下，增加示例数量对Text-to-SQL任务有益。此外，在不同的组织策略中，完整信息组织在不同的k样本场景中表现优于其他策略。

值得注意的是，在零样本和少样本场景中，开源大语言模型与OpenAI大语言模型仍有较大差距。实验将尝试通过监督微调进一步提升它们的性能。

4.4.4 开源大语言模型的监督微调

为了进一步提升开源大语言模型的性能，作者首先使用不同的表示方法，在零样本训练样本上对开源大语言模型进行微调。遵循监督微调的设置，实验阻止提示的梯度传播，仅使用响应（SQL查询）的梯度来更新权重。

在零样本场景下大语言模型进行监督微调的性能

1. 零样本场景：与微调前的零样本性能相比，它们的性能有了显著提升。通过比较不同的表示方法，Alpaca SFT提示在监督微调中显示出明显的优势，因为它是为这种场景设计的。同时，不同表示方法和模型规模之间的差距缩小了。在Spider数据集上，LLaMA-13B和的组合取得了最佳性能，其精确集匹配准确率和执行准确率分别为65.1%和68.6%。对于更大的大语言模型，LLaMA-33B和的组合实现了69.1%的执行准确率和65.9%的精确集匹配准确率。

可以见得，监督微调对Text-to-SQL的开源大语言模型非常有益。在零样本场景中，与OpenAI大语言模型相比，微调后的LLaMA-13B和33B与TEXT-DAVINCI-003相当，略弱于GPT-4和GPT-3.5-TURBO。

2. 少样本场景：实验评估了微调后的LLaMA-7B和13B在0样本、1 样本、3样本和5样本提示下的性能。

在少样本场景下大语言模型进行监督微调的性能

令人意外的是，微调后的大语言模型无法从示例中学习。在测试提示中添加上下文示例会导致精确集匹配准确率和执行匹配准确率突然下降，并且添加更多示例也无济于事。一个可能的原因是大语言模型过度拟合了零样本提示，使得示例变得无用。

综上所述，开源大语言模型在Text-to-SQL任务中显示出显著的潜力，特别是在监督微调方面。微调后它们的性能在零样本场景中与TEXT-DAVINCI-003相当。然而，微调后的大语言模型无法从上下文示例中学习。微调后如何保持上下文学习能力仍是未来研究有待探索的问题。

4.5 词元效率

在本节中，实验从词元效率的角度在Spider-dev数据集上的实验。对于OpenAI和开源大语言模型，本文通过实验研究了执行准确率和词元数量之间的权衡，词元数量主要受问题表示和示例组织的影响。对于示例选择，实验固定为。此外，作者在比较中纳入了几种最先进的Text-to-SQL方法，包括DIN-SQL、STRIKE和CBRApSQL，将它们报告的最高执行准确率作为它们的性能。对于词元成本，对DIN-SQL随机抽取的10个实例的词元数量取平均值；对STRIKE，通过对1样本到5样本的结果进行多数投票获得的，这导致词元成本显著增加；对于CBR-ApSQL，词元成本是根据其问题表示和仅SQL组织中的8样本示例计算的。

词元效率在不同表示下的结果

在零样本场景中，与规则暗示相比，带有外键的提示通常以更多的词元为代价实现更高的执行准确率。

在少样本场景中，比较不同的组织策略，效率非常低，其词元数量是和的几倍。比较和，与GPT-4配合使用时达到了最高的准确率，且词元成本与相似。因此，在词元方面，比和更高效。

与其他最先进的解决方案相比，DAIL-SQL在准确率和效率方面均优于DIN-SQL和STRIKE。对于CBR-ApSQL，它使用TEXT-DAVINCI-003实现了78.2%的准确率，但仍低于实现的最优性能。

此外，对于图（d）中的开源大语言模型，在Text-to-SQL上进行微调的大语言模型效率要高得多。词元效率是大语言模型在Text-to-SQL实际应用中的一个关键指标。DAIL-SQL提供了一个有吸引力的解决方案，它结合了高执行准确率和更高的词元效率，使其非常实用且适合实际应用。

5. 讨论

基于实验可以得到以下经验性的见解和指导方针：

1. 在问题表示方面：推荐使用代码表示提示（Code Representation Prompt）和OpenAI演示提示（OpenAIDemostration Prompt），以及利用其他信息（如外键和规则暗示等）会更加有益。

2. 在示例选择方面：自然语言问题和SQL查询的相似度都很重要。这两个相似度是设计有效选择策略的良好指标。

3. 在示例组织方面：对强大的大语言模型（GPT-4）呈现问题和SQL查询对是一种有效且高效的选择。否则，建议对其呈现完整信息的示例。

4. 对于开源大语言模型：模型参数越多，对Text-to-SQL任务越有利，但训练语料库起着更为关键的作用。此外，监督微调在Text-to-SQL任务中是必要的，并且具有相当大的潜力。

不过本文也存在一些局限性：

● 由于资源有限，实验只测试了两种规则暗示，探索更多规则可能会进一步有益于基于大语言模型的Text-to-SQL解决方案。

● 实验仅使用Spider训练集对开源大语言模型进行微调，额外的Text-to-SQL数据将进一步提升大语言模型的性能。此外，Spider和Spider-Realistic数据集中的数据库可能不够大，更大的数据集可能会对大语言模型带来有效性和效率的新挑战。

● 目前的评估指标优先考虑正确性而非效率，如何促使大语言模型在正确的备选方案中生成更高效的SQL，仍然是一个重要且有待探索的问题。

6. 结论

本文中从提示工程和监督微调两个方面，对基于大语言模型的Text-to-SQL任务进行了系统研究。现有的Text-to-SQL上下文学习技术忽略了问题与查询之间的映射关系，以及示例质量和数量之间的权衡。为了解决这些问题，作者提出了一种新的提示工程方法DAIL-SQL，它以86.6%的执行准确率位列Spider排行榜榜首。在监督微调方面，本文展示了开源大语言模型在Text-to-SQL任务中的巨大潜力，强调了训练语料库和模型规模的重要性，并指出了微调后上下文学习能力的退化问题。此外，通过对比现有解决方案的效率，表明DAIL-SQL效率更高，并强调了提示工程中词元效率的重要性。作者希望本文的工作能够为Text-to-SQL任务提供全面的研究，为实际应用提供一些指导，并推动该领域的发展。

论文解读联系人：

刘思源

13691032906（微信同号）

liusiyuan@caict.ac.cn