NL2SQL是将自然语言转化为SQL的任务，该任务隶属于NLP的子任务，NL2SQL在AIGC时代之前，以seq2seq、BERT等系列的模型在NL2SQL的主流数据集上取得了不错的效果，2022年底，ChatGPT爆火，凭借LLM强大的逻辑推理、上下文学习、情景联系等特点，按理说LLM应该可以超过seq2seq、BERT等系列的模型，但是使用少样本、零样本提示方法用LLM解决NL2SQL问题效果却比不上之前的模型。今天分享的这篇来自NLP顶级会议的论文解决了这个问题：如何改进Prompt让LLM超越之前的方法，并让LLM在Spider数据集上霸榜。

论文原文链接：[2304.11015] DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction (arxiv.org)

摘要：我们研究将复杂的文本到 SQL 任务分解为更小的子任务的问题，以及这种分解如何显着提高大型语言模型 (LLM) 在推理过程中的性能。目前，在具有挑战性的文本到 SQL 数据集（例如 Spider）上，微调模型的性能与使用 LLM 的提示方法之间存在显着差距。我们证明 SQL 查询的生成可以分解为子问题，并且这些子问题的解决方案可以输入到 LLM 中以显着提高其性能。我们对三个 LLM 进行的实验表明，这种方法持续将其简单的小样本性能提高了大约 10%，将 LLM 的准确性推向 SOTA 或超越它。在 Spider 的 Holdout 测试集上，执行准确度方面的 SOTA 为 79.9，使用我们方法的新 SOTA 为 85.3。我们的情境学习方法比许多经过严格调整的模型至少高出 5%。

一、Introduction

数据库的自然语言接口旨在使最终用户更轻松地访问关系数据库中的数据。例如，给定自然语言“查找收入超过经理的员工”以及员工表和管理表的schema，人们可能希望在 SQL 中生成一个查询，从数据库中检索这些员工。

在过去的二十年中，该领域的研究经历了几个阶段的发展，早期系统是特定领域的，支持受控自然语言或依赖基于规则的方法，而最近的研究方法使用在不同领域的数据集上训练监督模型提供更大的领域独立性以及最近训练的深度神经模型大型文本和代码存储库。

这一领域的最新进展是在零样本和少样本提示下使用大型语言模型（LLM）。事实证明，LLM仅使用少量演示且无需微调即可提供强大的基线。然而，与精心设计和微调的模型相比，这些模型在常用的 benchmark（例如 Spider）上落后了。表1显示了两个最新的LLM CodeX和GPT4在Spider数据集的dev开发集上的性能。

 

尽管表现强劲，但与现有方法相比，LLM 仍然落后，特别是在中等和复杂的查询上。本文研究的问题是这些LLM在哪里失败，以及是否可以缓解他们面临的一些问题，以推动性能达到或超过微调的 SOTA 模型。

与使用预训练或微调的传统方法相比，Prompt有几个优点。主要好处是LLM可以执行预测任务，而不需要大量特定于任务的训练数据。从头开始训练大型语言模型或对其进行微调是一个资源密集型过程，通常需要大量的训练样本和机器资源，而这些资源可能不可用。此外，在几个基准数据集上，少样本提示(few-shot prompting)已被证明优于以前最先进的方法，并且即使训练示例有限，也能实现高精度。

最近的研究表明，LLM在更复杂的任务（例如数学应用题、作文写作）上的表现可以通过使用思想链、从最小到最大等方法来提高。以及分解（Khot et al, 2022）提示技术，其中任务被分解为多个步骤，中间结果用于生成最终答案。然而，与代数表达式不同的是，代数表达式中每个步骤的输出直接输入到下一步，由于语言的声明性结构以及查询子句之间的复杂关系，破坏复杂的 SQL 查询可能是一项更加艰巨的任务。

在本文中，我们提出了一种基于少样本提示（few-shot prompting）的新颖方法，将自然语言文本到 SQL（称为 text-to-SQL）的任务分解为多个步骤。之前使用 LLM 进行文本到 SQL 提示的工作仅在零样本（ zero-shot）设置中进行评估。然而，零样本提示仅提供了LLM对于大多数任务的潜在能力的下限。在这项工作中，我们首先评估了 LLM 在少样本设置中的性能，然后提出了我们的分解方法，该方法大大优于少样本提示方法。为了将我们的方法与以前的方法进行比较，我们使用执行精度和匹配精度这两个官方评估指标。我们利用 CodeX 系列的两个变体，即 Davinci 和 Cushman以及 GPT-4 模型进行prompt。在Spider的测试集上，我们的方法使用GPT-4和CodeX Davinci模型分别实现了85.3％和78.2％的执行精度，并且使用相同模型分别实现了60％和57％的匹配精度。

匹配精度和执行精度之间的巨大差距是由于我们的方法的上下文中的少数情景语境造成的。预训练和微调的方法更有可能生成具有更高精确集匹配精度的 SQL 查询，因为这些模型在训练过程中看到了许多遵循测试集中查询的组合风格的示例（两个集合中的查询通常都写成由同一个人）。在我们的工作之前，测试集上的 SOTA 的执行精度为 79.9% ，匹配精度为 74% ，因此我们的方法在执行精度上奠定了新的ground。

应强调有关这些结果的两个重要观察结果。首先，我们的方法使用 GPT-4 排名第一，使用 CodeX 、Davinci 在 Spider 数据集的执行准确性排行榜上排名第三，超越了许多微调和预训练方法。其次，我们的方法是执行准确性排行榜上唯一一种不需要数据库单元来生成 SQL 查询的方法。这有几个优点。首先，出于安全和隐私原因，在查询之前，数据库内容可能在客户端计算机上不可用。其次，数据库内容定期更改，而查询经常被重用。最后，使用数据库内容（如果可用）可以解决话语和数据库内容之间的歧义和可能的不匹配（例如，“多伦多市”与“多伦多”），并且有望提高包括我们在内的许多模型的性能。为了重现本文报告的结果，所有设计的提示、结果和代码都可以在我们的 GitHub 存储库上找到。

二、Related Work

序列到序列模型（Sutskever 等人，2014）在包括文本到 SQL 的代码生成任务中显示出巨大的潜力。关键思想是将给定的自然语言问题与数据库模式联合编码，并利用解码器进行预测目标SQL。

在编码器方面，学习问题的表示和数据库模式是使用 IRNet 中的双向 LSTM、预训练语言模型以及 RATSQL、SADGA和 LGESQL中的图神经网络。 Gan 等人 (2021) 提出了一种中间表示，可以弥合自然语言问题和 SQL 语句之间的差距。还有对表格和文本进行编码的表格语言模型的工作，例如 TaBERT、TaPas和 Grappa。

解码器方面的方法可以分为基于草图的槽填充和基于生成的方法。基于 Sketch 的方法将问题分解为多个槽预测子问题，并聚合要生成的 SQL 查询槽的预测。这些方法的缺点是它们无法推广到不遵循预定义模板的查询。基于生成的方法将 SQL 查询解码为抽象语法树。

与预训练和微调模型相比，Rajkumar 等人（2022）和 Liu 等人（2023a）使用 Spider 数据集上的不同提示对文本转 SQL 的LLM的零样本提示能力进行了评估。提示技术也用于表格理解、表格推理和表格到文本生成等任务，其中表明，当仅仅用少量的几个例子去prompt大语言模型的时候，LLM就可以取得很好的效果。

三、Few-shot Error Analysis

为了更好地了解 LLM 在少样本设置下失败的地方，我们从 Spider 数据集的训练集中的不同数据库中随机抽取了 500 个查询，排除提示中使用的所有数据库。我们搜索的查询产生的结果与Spider官方给出的标准的结果不同，因此执行准确性不合格。我们手动检查了这些故障，并将其分为六类，如图 1 所示，并在接下来进行讨论。

 3.1 Schema Linking

此类别包含最大数量的失败查询，并包含模型无法识别问题中提到的列名称、表名称或实体的实例。在某些情况下，查询需要聚合函数，但会选择匹配的列名称。例如，问题“所有体育场的平均容量和最大容量是多少？”的数据库模式包括一个名为“average”的列，该列是由模型选择的，而不是取容量列的平均值。

3.2 JOIN

这是第二大类别，包括需要 JOIN 的查询，但模型无法识别所需的所有表或连接表的正确外键。

3.3 GROUP BY

此类别包括以下情况：SQL 语句需要 GROUP BY 子句，但模型无法识别分组的需要，或者使用了错误的列对结果进行分组。

3.4 Queries with Nesting and Set Operations

对于此类别，Spider给出的标准查询使用嵌套或集合操作，但模型无法识别嵌套结构或无法检测正确的嵌套或集合操作。

3.5 Invalid SQL

一小部分生成的 SQL 语句存在语法错误，无法执行。

3.6 Miscellaneous

此类别包括不属于上述任何类别的案例。示例包括包含额外谓词、缺少谓词或缺少或冗余 DISTINCT 或 DESC 关键字的 SQL 查询。此类别还包括缺少 WHERE 子句或查询具有冗余聚合函数的情况。

四、Methodology

尽管少样本比零样本模型有所改进，但少样本模型在处理更复杂的查询时遇到了困难，包括那些模式链接不那么简单的查询以及使用多个联接或具有嵌套结构的查询，如第 3 节中所述。

我们应对这些挑战的方法是将问题分解为更小的子问题，解决每个子问题，并使用这些解决方案构建原始问题的解决方案。

类似的方法（例如，思想链提示（Wei et al, 2022b）和从最少到最多的提示（Zhou et al, 2022））已被用来提高法学硕士在任务上的表现，这些任务可以分解为多个步骤，例如数学应用题和构图概括（Cobbe 等人，2021；Lake 和 Baroni，2018）。与这些任务具有过程结构（其中一个步骤直接进入下一步）的领域不同，SQL 查询在大多数部分都是声明性的，可能的步骤及其边界不太清晰。然而，编写 SQL 查询的思维过程可以分解为 (1) 检测与查询相关的数据库表和列，(2) 识别更复杂查询的一般查询结构（例如分组、嵌套、多重联接 、集合运算等）（3）制定任何可以识别的过程子组件，以及（4）根据子问题的解决方案编写最终查询。

基于这个思维过程，我们提出的分解文本到 SQL 任务的方法由四个模块组成（如图 2 所示）：（1）模式链接，（2）查询分类和分解，（3）SQL 生成， (4)自我修正，将在以下小节中详细解释。虽然这些模块可以使用文献中的技术来实现，但我们都使用提示技术来实现它们，以表明如果问题被简单地分解到正确的粒度级别，LLM就有能力解决所有这些问题。

4.1 Schema Linking Module

模式链接负责识别自然语言查询中对数据库模式和条件值的引用。它被证明有助于跨领域的通用性和复杂查询的综合（Lei 等人，2020），使其成为几乎所有现有文本到 SQL 方法的关键初步步骤。在我们的案例中，这也是LLM失败次数最多的一个类别（图 2）。我们设计了一个基于提示的模式链接模块。提示包括从 Spider 数据集的训练集中随机选择的 10 个样本按照思路链模板（Wei 等人，2022b），提示以“让我们一步一步思考”开头，正如 Kojima 等人（2022）建议的那样。对于问题中每次提到的列名，都会从给定的数据库模式中选择相应的列及其表。还从问题中提取可能的实体和单元格值。图 3 给出了一个示例，完整的提示可以在附录 A.3 中找到。

4.2 Classification & Decomposition Module

对于每个连接，都有可能未检测到正确的表或连接条件。随着查询中联接数量的增加，至少一个联接无法正确生成的可能性也会增加。缓解该问题的一种方法是引入一个模块来检测要连接的表。此外，一些查询具有过程组件，例如不相关的子查询，它们可以独立生成并与主查询合并。

为了解决这些问题，我们引入了查询分类和分解模块。该模块将每个查询分为三类之一：简单、非嵌套复杂和嵌套复杂。 easy 类包括无需连接或嵌套即可回答的单表查询。非嵌套类包括需要连接但没有子查询的查询，而嵌套类中的查询可以需要连接、子查询和集合操作。类标签对于我们的查询生成模块很重要，该模块对每个查询类使用不同的提示。除了类标签之外，查询分类和分解还检测要为非嵌套和嵌套查询以及可能为嵌套查询检测到的任何子查询连接的表集。图 4 显示了提供给模型的示例输入以及模型生成的输出。

 

4.3 SQL Generation Module

随着查询变得更加复杂，必须合并额外的中间步骤来弥合自然语言问题和 SQL 语句之间的差距。这种差距在文献中被称为不匹配问题（Guo et al, 2019），对 SQL 生成提出了重大挑战，这是因为 SQL 主要是为查询关系数据库而设计的，而不是表示自然语言中的含义。

虽然更复杂的查询可以从思路链式提示中列出中间步骤中受益，但此类列表可能会降低更简单任务的性能（Wei 等人，2022b）。在相同的基础上，我们的查询生成由三个模块组成，每个模块针对不同的类别。

 对于我们划分的简单类别中的问题，没有中间步骤的简单的少量提示就足够了。此类示例 Ej 的演示遵循格式 <Qj, Sj, Aj>，其中 Qj 和 Aj 分别给出英语和 SQL 的查询文本，Sj 表示模式链接。

我们的非嵌套复杂类包括需要连接的查询。我们的错误分析（第3节）表明，在简单的几次提示下，找到正确的列和外键来连接两个表对于法学硕士来说可能具有挑战性，特别是当查询需要连接多个表时。为了解决这个问题，我们采用中间表示来弥合查询和 SQL 语句之间的差距。文献中已经介绍了各种中间表示。特别是，SemQL（Guo et al, 2019）删除了在自然语言查询中没有明确对应项的运算符 JOIN ON、FROM 和 GROUP BY，并合并了 HAVING 和 WHERE 子句。 NatSQL（Gan 等人，2021）基于 SemQL 构建并删除了集合运算符。作为我们的中间表示，我们使用 NatSQL，它与其他模型结合使用时显示出最先进的性能 (Li et al, 2023a)。非嵌套复杂类的示例 Ej 的演示遵循格式 <Qj, Sj, Ij, Aj>，其中 Sj 和 Ij 分别表示第 j 个示例的模式链接和中间表示。

最后，嵌套复杂类是最复杂的类型，在生成最终答案之前需要几个中间步骤。此类可以包含不仅需要使用嵌套和集合操作（​​例如 EXCEPT、UNION 和 INTERSECT）的子查询，而且还需要多个表连接的查询，与上一个类相同。为了将问题进一步分解为多个步骤，我们对此类的提示的设计方式是LLM应首先解决子查询，然后使用它们生成最终答案。此类提示遵循格式<Qj, Sj , <Qj1, Aj1, ..., Qjk, Ajk> , Ij, Aj>，其中k表示子问题的数量，Qji和Aji分别表示第i个问题-第一个子问题和第i个子查询。和之前一样，Qj 和 Aj 分别表示英语和 SQL 的查询，Sj 给出模式链接，Ij 是 NatSQL 中间表示。

附录 A.4 中提供了所有三个查询类别的完整提示，并且这三个类别的所有示例均从为分类提示选择的完全相同的数据库中获得。

4.4 Self-correction Module

生成的 SQL 查询有时可能会缺少或冗余关键字，例如 DESC、DISTINCT 和聚合函数。我们对多个 LLM 的经验表明，这些问题在较大的 LLM 中不太常见（例如，GPT-4 生成的查询比 CodeX 生成的查询具有更少的错误），但仍然存在。为了解决这个问题，我们提出了一个自我纠正模块，指示模型纠正这些小错误。

这是在零样本设置中实现的，其中仅向模型提供有错误的代码，并要求模型修复错误。我们为自我纠正模块提出了两种不同的提示：通用和温和。通过通用提示，我们要求模型识别并纠正“BUGGY SQL”中的错误。另一方面，温和提示并不假设 SQL 查询有错误，而是要求模型检查任何潜在问题，并提供有关要检查的子句的一些提示。我们的评估表明，通用提示可以在 CodeX 模型中产生更好的结果，而温和的提示对于 GPT-4 模型更有效。除非另有明确说明，否则 DINSQL 中的默认自我更正提示对于 GPT-4 设置为“温和”，对于 CodeX 设置为“通用”。通用和温和的自我纠正提示的示例可以在附录 A.6 中找到。

五、Experiments

5.1 Models

我们使用 CodeX 系列的两个变体（Davinci 和 Cushman 变体）和 GPT-4 模型评估了所提出的方法。这些是在撰写本文时最大的开放可获取的LLM。较小的模型不太适用，因为提示被认为是参数数量达到数十亿规模的法学硕士的一种新兴能力。

5.2 Hyperparameter

所有模型均通过 OpenAI API 访问。使用贪婪解码通过将温度设置为零来生成输出。自校正模块的最大令牌设置为 350，所有其他模块的最大令牌设置为 600。对于自校正模块，停止标记序列设置为“#;\n \n”，对于所有其他模块，设置为“Q:”。

5.3 Dataset

我们的评估是在具有挑战性的跨域 Spider 数据集上进行的，该数据集包含 200 个数据库中的 10,181 个问题和 5,693 个独特的复杂 SQL 查询，涵盖 138 个域，每个域包含多个表。该数据集的标准协议将其分为跨 146 个数据库的 8,659 个训练示例、跨 20 个数据库的 1,034 个开发示例以及跨 34 个数据库的 2,147 个测试示例。

每个集合中使用的数据库都是不重叠的。根据使用的 SQL 关键字数量、嵌套子查询的存在以及列选择和聚合的使用，SQL 查询分为四个难度级别。 WikiSQL（Zhong et al, 2017）是另一个大型跨域数据集，只有单表查询，它被认为很简单，因此由于成本衡量而没有在我们的评估中使用。

5.4 Metrics

我们的模型的性能使用两个常用的指标进行评估：逻辑匹配精度（EM）和执行精度（EX）。前者将每个子句视为一个集合，并将预测与其相应的真实 SQL 查询进行比较。仅当预测的 SQL 查询的所有组件都与真实值匹配时，才认为预测的 SQL 查询是正确的。该指标不考虑值，这可能会导致误报和漏报。后者将预测的 SQL 查询的执行输出与某些数据库实例上的真实 SQL 查询的执行输出进行比较。执行准确性提供了对模型性能的更精确估计，因为给定问题可能有多个有效的 SQL 查询，而精确集匹配准确性仅根据其中之一评估预测的 SQL。

 5.5 Results

5.5.1 Test set results

如表 2 所示，我们的方法开辟了新的天地，在撰写本文时，使用 GPT-4 实现了最高的执行精度，使用 CodeX Davinci 实现了第三高的执行精度。这是甚至无需利用数据库内容即可实现的。在EM精度方面，我们的方法取得了与之前不使用数据库内容的方法相当的结果。

5.5.2 Development set results

我们在开发过程中的大部分评估都是在易于访问的开发集上进行的，这与只能通过 Yu 等人（2018）提供的评估服务器访问的测试集不同。表 3 显示了我们使用不同 LLM 的方法的性能，与 Rajkumar 等人 (2022) 和 Liu 等人 (2023a) 的零样本提示以及我们自己的少样本提示相比。为了确保对小样本提示进行公平比较，我们将用于三个类（简单、非嵌套复杂和嵌套复杂）的所有示例合并到提示中。鉴于 CodeX Cushman 模型的输入上下文大小比 CodeX Davinci 和 GPT-4 模型更小，我们仅使用每个类别的 2 个示例（总共 6 个示例）。

在精确的集合匹配和执行精度方面，我们的方法显着优于简单的少样本提示和零样本提示，并且无论模型大小如何，所有模型的改进都是一致的。例如，与少样本提示相比，我们的方法将所有模型的执行准确性提高了至少 10%。

 我们进一步分析了我们提出的方法在不同难度级别的查询上的性能。表 4 展示了我们提出的方法与 Spider 开发集上基本的few-shot prompting 相比的性能。

我们提出的方法在所有难度级别上都优于基本的少样本提示，在超困难和困难类别中观察到性能的最大改进，其中少样本提示表现不佳。我们的方法甚至显示了对简单类的改进，这与我们在提示中合并模式链接的基本few-shot prompting 不同，突出了我们的模式链接模块的重要性。

 5.5.3 Error improvements

在第 3 节中，我们对从训练集中随机选择的 500 个查询进行了基本的少样本提示的错误分析。为了了解这些错误得到解决的程度，我们对相同的 500 个查询运行了 DIN-SQL。如图 5 所示，我们提出的方法提高了所有类别的性能，其中 JOIN 和嵌套类别的改进最大。尽管有用于模式链接的显式模块，但最大部分的失败案例仍然属于此类。

 5.6 Ablation study

在一项消融研究中，我们评估了使用和不使用四个模块的方法。如 CodeX Davinci 模型的表 5 所示，排除任何模块会导致执行精度方面的性能总体下降。当我们研究每个模块在不同查询类中的有效性时，会出现更多细节。模式链接有助于所有查询类，对困难类的改进最少。我们对失败案例样本的检查表明，由于问题或模式不明确，模式链接有时会发现冗余链接，这可能会引入冗余连接或输出列。如果没有分类，我们必须对所有查询使用简单的几次提示或分解思维链 (COT) 提示。后者包含我们的所有模块，包括具有模式链接和查询分解的详细 SQL 生成模块，但查询并未分为我们的三个类。正如预期的那样，分解的思维链提示对于困难和超困难的查询效果更好，而简单的几次提示对于简单的类别效果更好。为了进行自我修正，我们使用 CodeX Davinci 和 GPT-4 进行了研究。对于 CodeX Davinci，通用的自我更正提示有助于跨所有查询类的模型。温和的自我修正提示也很有帮助，但增益小于 CodeX Davinci 的通用提示。然而，GPT-4 生成错误代码并给出“Buggy SQL:”的通用提示的可能性较小。 。 。

固定 SQL:. 。 ”。会损害性能。温和的提示对于 GPT-4 效果更好，并且可以提高除简单类别之外的所有类别的表现。

 六、Conclusion

提示使大型语言模型能够在跨不同领域的众多 NLP 任务上取得令人印象深刻的性能，而无需大型训练集。然而，文本到 SQL 任务的提示方法的性能低于微调模型的性能。在本研究中，我们开发了一种分解方法来使用提示来解决问题。我们的实验结果表明，我们的方法可以有效地弥合两种范式之间的差距，并在具有挑战性的 Spider 数据集上提供与最先进的方法相当的结果。

Limitations

这项工作有一些限制。首先也是最重要的，唯一包含文本到 SQL 域中复杂 SQL 查询的开放域大型数据集是 Spider 数据集。因此，我们的工作仅在此数据集上进行评估。我们需要更多带有类似于现实世界查询的 SQL 查询的数据集。此外，与许多其他提示策略一样，我们的方法需要手动查找特定于任务的演示和设计提示。该领域的自动化是未来工作中可以探索的领域。

 附录A

本节提供了我们在 GPT-4 和 CodeX 模型上提出的方法的四个模块中使用的所有提示的完整列表。详细提供了每个模块使用的提示，以便于轻松复制和理解该方法。此外，我们还包含了用于方法的少样本和零样本实现的提示。

A.1 Zero-shot prompting

用于零样本提示场景的提示灵感来自于 Liu 等人的工作(2023a)为 ChatGPT 的提议。在图 6 中，我们演示了我们工作中使用的零样本提示的一个示例。

 A.2 Few-shot prompting

 

 

 

 

后续全是附录，而且页数非常非常多，这里就不截图展示了，具体可以参看原文