【学习日记3】DAIL-SQL论文：Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation

PS：自己回顾用的

ABSTRACT

        大型语言模型（LLMs）已成为 Text-to-SQL 任务的新模式。然而，缺乏系统的基准测试限制了有效、高效和经济的基于 LLM 的 Text-to-SQL 方案的发展。为了解决这一挑战，本文首先对现有的提示工程方法进行了系统且广泛的比较，包括问题表示、示例选择和示例组织，并详细说明了它们的优缺点。基于这些发现，我们提出了一种新的综合解决方案，名为 DAIL-SQL，它以 86.6% 的执行准确率刷新了 Spider 榜单，并设定了新的标准。

        为了探索开源大型语言模型（LLMs）的潜力，我们在各种场景中对它们进行了研究，并通过监督微调进一步提升了它们的性能。我们的研究突显了开源 LLM 在 Text-to-SQL 任务中的潜力，以及监督微调的优缺点。此外，为了实现高效且经济的基于 LLM 的 Text-to-SQL 解决方案，我们强调了在提示工程中token的高效性，并在这一指标下比较了先前的研究。我们希望我们的工作能够加深对使用 LLMs 进行 Text-to-SQL 转换的理解，并激发进一步的研究和广泛的应用。

        GPT翻译的。

1.INTRODUCTION

         以往的研究大多是question-to-SQL模式，并通过训练编码器-解码器模型来泛化这些模式。与以往的研究不同，基于 LLM 的 Text-to-SQL 解决方案的核心在于如何引导 LLM 生成正确的 SQL 查询，即提示词工程。提示词工程涉及到问题表示、实例选择和实例组织。

        Text-to-SQL 提示词工程需要系统性的研究。在问题表示方面，大多数现有研究将结构化知识文本转化为模式，并进一步添加任务说明和外键以形成提示词。此外，一些研究将数据库的表表示为若干“CREATE TABLE” SQL 语句，并在注释中提示 LLM 回答目标问题。然而，即使采用类似的表示方式，仍可能导致显著的性能差异。例如，在 OpenAI 的官方 Text-to-SQL 演示中，他们使用井号“#”来区分提示和响应，从而获得了较高的性能；如果移除这个标记，性能将显著下降。因此，对不同表示方式的系统研究以及如何与 LLM 良好配合的是现在研究的重要方面。

        真正意义上的用“#”号区分，真没有别的了，可以在写提示词的时候加入这个习惯。

        在示例选择方面，常见的做法是将与目标问题最相似的示例编码到相同的表示中。

        例如使用向量数据库？

        在组织方面，大多数以往的研究用完整的信息来表示示例，包括指令、模式、问题和实际的 SQL 查询。基于 LLM 的 Text-to-SQL 解决方案中的最佳选择和组织策略仍然模糊，因此，对提示词工程进行系统性的研究，非常有必要。

        开源大型语言模型（LLMs）的潜力尚未得到充分探索。之前的研究都基于OPENAI的大模型。现在是否可以考虑通过监督微调来增强开源大模型的实力，从而完成text2sql任务。

        效率也是一个很大的问题。根据 Chang 等人观察到的执行准确率与提示长度呈倒 U 形的关系，他们推测 LLMs 在提示长度方面可能有一个最佳点，但探索高效的提示工程仍然是一个具有挑战性的问题。

        鉴于上述挑战，本文提供了一个全面、系统且公平的基准，用于基于 LLM 的Text-to-SQL 任务。具体来说，我们的基准不仅讨论了各种提示工程策略的有效性和效率，还探讨了开源 LLM 的可行性。具体内容如下：

                1.为了系统且深入地理解 Text-to-SQL 提示词工程，本文对以往研究中的几种策略进行了评估。首先，在zero-shot场景中比较了几种典型的问题表示方式，并使用不同的 LLMs 来识别其优缺点。之后，在few-shot场景中调查了示例选择和组织策略。对于示例选择，比较了不同的选择策略，并进一步验证了 LLMs 从问题与 SQL 框架之间的映射中学习的假设。在示例组织方面，探索了仅展示完整信息、仅展示 SQL 查询和展示question-SQL 对应关系这三种策略。

                2.强调了开源 LLMs 在上下文学习和监督微调中的潜力。对各种开源 LLMs 使用不同的提示词工程策略进行了研究，观察到 LLMs 规模的增加和良好的格式排列带来的显著收益。为了进一步提升它们的性能，使用各种表示方法对开源 LLMs 进行了微调和评估。通过这一比较，证明了与上下文学习相似，表示策略对监督微调也至关重要。还观察到微调后上下文学习能力的下降，这需要进一步研究。

                3.为了实现更经济高效的解决方案，我们进一步从 token 效率的角度评估了不同的策略。为实现这一目标，我们在整个提示工程过程中考虑 token 效率。

                4.最后，我们的集成解决方案 DAIL-SQL 以 86.6% 的执行准确率刷新了 Spider 榜单，并获得了第一名。与之前的解决方案相比，DAIL-SQL 将结构化知识编码为 SQL 语句，根据结构相似性选择示例，并从示例中移除跨领域知识以提高 token 效率。

        本文的贡献如下：

                1.我们系统地研究了基于 LLM 的 Text-to-SQL 方法中的提示词工程，包括五种问题表示、两种提示组件、四种示例选择和三种示例组织方式，并在四种 LLM 上进行了实验。这项研究有助于识别合适的问题表示方式，并找出利用 LLM 上下文学习能力进行 Text-to-SQL 任务的关键点。

                2.首个探索开源 LLMs 在 Text-to-SQL 任务中进行上下文学习和监督微调的研究。通过在 Text-to-SQL 任务中使用 SFT，证明了开源 LLMs的潜力。

                3.我们还从成本效益的角度对不同的提示词进行了比较，为现实的 Text-to-SQL 应用提供了指导。

                4.最后，我们提出了一种新的解决方案，名为 DAIL-SQL，该方案成功利用了 LLMs 的上下文学习能力，并在性能和 token 效率之间达到了平衡。值得注意的是，它以 86.6% 的执行准确率刷新了 Spider 榜单，比最先进的解决方案高出 1.3%，且 token 成本更低。

2.PRELIMINARY

        text-to-sql旨在将自然语言问题自动转换为SQL查询问题，弥补非专家用户和数据库系统间的使用鸿沟，提高数据处理的效率，为智能数据库、自动数据分析和数据库问答等更广泛的应用做出贡献。

        最近，大型语言模型(LLM) 已经成为自然语言处理和机器学习的里程碑。与一般的机器学习模型不同，LLM 是在大规模文本语料库上进行预训练的，可以执行各种自然语言任务。基本的操作原理是根据输入提示逐渐产生具有最高概率的下一个单词。因此，要使用 LLM 处理text-to-SQL 的任务，核心是找到最佳提示符，也称为提示词工程。

        具体的根据提示中的实例数量将提示词工程分为两种：zero-shot和few-shot。本文将自然语言问句及相关信息的表征过程称为question representation。LLM从上下文事例的学习过程称为上下文学习，它使LLM能够从输入的提示词中识别显式或非显式的模式，并生成相应的输出。通过这种方式，LLM 能够在推理过程中执行新的任务，而不需要任何明确的对于特定任务的训练阶段。本文将从实例选择和实例组织的角度来讨论上下文学习。

        虽然 LLM 在先前的研究中被证明在zero-shot和few-shot场景中都是有效的，但是它们的性能可以通过监督微调(SFT)进一步提高，使其更适合特定的下游任务。在最近的研究中，监督微调被用作校准训练，它校准 LLM 的行为，以避免产生攻击性的，有偏见的回复。本文将着重于通过监督微调来提高LLM的text-to-SQL 的能力。

        总之，问题表示(question representation),上下文学习( in-context learning), 监督微调(together with supervised fine-tuning)是基于文本到 SQL 的大型语言模型中的三个关键环节。本文将对它们进行系统的研究和探讨。

3.METHODOLOGY

3.1 Question Representation

        考虑一个数据库D中的目标自然语言问题q，question representation 的目标是最大化大模型M生成正确SQL的可能性：

  

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

        根据上述定义，本文调查了zero-shot场景中不同的不同选择，并选取了其中四种。此外还包括Alpaca使用的问题表示法（因为在监督微调中很流行），具体见下表：

         表中INS表示指令，RI表示蕴含规则，FK表示外键，EX表示执行精度

        下面将介绍之前提过的五种问题表示方法。

         BS（Basic prompt，基础提示词）：由表模式、前缀为“Q：”的自然语言问题和响应前缀“A：SELECT”组成

         TR（Text Representation Prompt）：相比于基本提示词，在开头添加了指令。

        OD（OpenAI Demostration Prompt） ：由指令、表模式和问题组成，其中所有信息都由“ #”注释。与上一种相比，其中的提示指令更加具体，4.3将继续讨论。

        CR（Code Representation Prompt ） ：提供了创建数据库的全面信息，提高了正确预测率

        AS（Alpaca SFT Prompt ）：Alpaca的SFT提示词是一个监督微调的提示设计。它通过 Markdown 格式的输入上下文，提示 LLM 遵循指令并完成任务。我们将其纳入研究，以检验其在提示工程和监督微调场景中的有效性和效率。

        不同的提示词表示方法在不同的 LLM 中进行了实验，并集成在不同的框架中，这使得它们很难进行公平比较。此外，外键信息和蕴含规则等各个组件所扮演的具体角色仍不清楚。因此，有必要进行系统的研究，以更好地理解question representations，并通过公平比较调查它们的优缺点。 

3.2 In-Context Learning for Text-to-SQL

        上下文学习的关键是实例选择和实例组织，首先给出上下文学习的表述，给定一个三元组Q={(qi,si,Di)},其中qi和si是自然语言问题及其在数据库Di上相应的SQL查询，在上下文学习Text-to-SQL的目标是最大限度地提高LLM在目标问题q和数据库D上生成正确SQL语句s的可能性，如下图所示：

        其中，函数决定目标问题q的表示形式，利用数据库D中模式的有用信息和从Q中选择的k个例子。本文主要研究跨域文本SQL，即目标数据库D不包含在前面提到的数据库中，即。

        text-to-sql的上下文学习包括选择最有用的示例，并将这些示例组织成prompt，即有两个子任务：示例选择和示例组织。

3.2.1 示例选择

（1）Random：直接随机从候选示例中抽取k个例子。

（2）Question Similarity Selection：选择5千个问题最相似的例子，使用预先训练好的模型计算目标问题的向量，然后计算各个示例到目标的距离，最后用kNN计算出k个示例。

（3）Masked Question Similarity Selection:使用掩码标记替换所有问题中的表名、列名和值，消除了领域特定信息的负面影响，然后用kNN计算相似性

（4）Query Similarity Selection:选择与目标SQL查询结果最相似的k个示例，本文指出，在示例选择过程中，同时考虑问题和 SQL 查询可能有利于text-to-sql任务。

3.2.2 示例组织

作用：确定选定的示例的哪些信息组织到prompt。

（1）Full-Information Organization：完整提供问题（包含问题、schema等）和问题对应的SQL查询

（2）SQL-Only Organization：仅包含SQL查询，不提供问题的描述。能提供更多的SQL查询，但是每个SQL查询的质量较低。

是否存在一种示例组织形式能权衡质量和数量 

3.3 DAIL-SQL 

        为了解决上述示例组织和示例选择方面的问题，本文提出了一种新的text-to-sql的方法DAIL-SQL。其中示例组织形式如下图：

        即保留了问题-SQL的示例组织形式，删去了schema。 

        DAIL-SQL示例选择是如下流程：

              （1）DAIL选择首先在目标问题q和候选集Q中的示例问题qi中屏蔽特定领域的词汇。

              （2）根据屏蔽后的q和qi的embedding的欧几里得距离并进行排序。同时计算预测的SQL和Q中的SQL们间的距离相似度

              （3）选择标准优先考虑按问题相似度排序的候选项，并且查询相似度大于预定义阈值𝜏。

        这样，选定的前𝑘个示例在问题和查询上都具有良好的相似性。

3.4 Supervised Fine-Tuning for Text-to-SQL

        对于text-to-sql，给定一个大语言模型M，一组text-to-sql的训练数据T={(qi,si,Di)}，其中qi和si是自然语言问题，对应的查询是数据库Di，监督微调的目标是最小化下图的损失：

        其中L是损失函数，用于测量生成的查询和真实查询间的差异。与问题表示类似， 利用数据库D中schema的有用信息来决定问题表示。

        text-to-sql的监督微调包括两个子任务：利用监督数据T对给定的LLM进行微调，寻找最优的问题表示。问题表示相关讨论见3.1节。

        对于一般域，监督数据 T = {(pi，ri)}中的每个项目都包含一个输入提示符 pi 和一个来自 LLM 的期望响应 ri。为了确保与推理过程的一致性，我们采用了一个有监督的微调，并从给定的text-to- SQL 数据集生成prompt-response对。具体来说，给定一个 Text-to-SQL 数据集 T = {(qi，si，Di)} ，通过使用目标问题和给定的数据库作为提示，并将所需的查询作为来自 LLM 的响应，即 T = {(pi = σ (qi，Di) ，ri = si)} ，来调整生成的调优数据。一旦数据准备就绪，我们可以使用现有的包通过完全微调或参数有效微调来微调给定的 LLM。经过微调后，优化后的LLM可以要求它通过自然语言问题生成查询。注意，在微调和推理过程中使用了相同的问题表示 σ。

4. EXPERIMENT

4.1 设置

        略

4.2 问题表示

         其中的BS，CR，TR，AS，OD是五种问题表示形式。其中最值得注意的是GPT-4表现出对源自DIN-SQL的简单BS的偏好。此外，通过比较四种LLM的平均性能，GPT-4和GPT-3.5-Turbo在zero-shot的情况下性能更好。对于像TTEXT-DAVINCI-003 和 Vicuna-33B这样不太强大的模型，使用OD和CR更好，这类模型实验结果如下：

        外键，意味着不同关系表之间的关系，这可能有助于text-to-sql任务，由于只有CR包含外键，本文将外部关键信息添加到其他表示中，实验结果见下图：

         除了TR与 GPT-4(-0.2%)和 AS与TEXT-DAVINCI-003(-0.4%)的组合外，外键显着提高 LLM 的执行准确性0.6% -2.9% 。然而，外键对 Vicuna-33B 的影响往往是不稳定的。值得注意的是，外键的包含使BS惊人地提高了5.0% ，但是对OD和AS的性能产生了不利影响。

        蕴含规则，受到OD的超常表现的启发，我们探讨了它的影响。如下是相关的消融实验：

        由上图可知，添加这条规则可以持续提高所有LLM在精准匹配和执行精度方面的性能。而对于OD去掉这个规则会导致精确集匹配精度下降4.2%-6.2%，执行精度下降1.3%-2.4%。本文还测试了一个流行的蕴含规则“Let’s think step by step”，但是它的性能在text-to-sql任务中非常不稳定，具体实验结果如下图：

4.3 上下文学习

        本节的所有测试均是使用CR的问题表示策略进行实验。

4.3.1 示例选择

        为了验证问题和查询在示例选择中的重要性，我们计算了所选示例与目标示例之间的问题和查询的Jaccard相似度，并在下表说明了列问题相似度和查询相似度下的平均数：

        具体来说，从问题和查询中删去了特定于数据库的信息，并计算剩余token的jaccard相似性。此外，还引入了Upper LImit作为参考，它类似于 DAIL 选择，但是利用了真实查询而不是初始预测器产生的查询。值得注意的是，我们并不直接向 LLM 提供真实的SQL，而只是使用真实查询作为示例选择的参考。在一定程度上，Upper Limit表明了基于相似度的选择方法的性能上限。 

         上图通过比较了不同的选择策略，证明了DAIL的选择策略优于其他的选择策略。此外，观察到问题和查询相似度的增加大部分对应于更高的执行准确度，表明同时考虑问题和查询相似度的重要性。注意 DAIL的执行精度仍然低于上限。这种差异可以归因于较低的查询相似度，表明真实的查询和初始预测器生成的有很大差距。

4.3.2 示例组织

        比较实验结果如下图：

        从（a）和（e）中可以看到GPT-4从spider-dev和spider-Realistic的上下文中稳步获益，而对于GPT-3.5-Turbo和TEXT-DAVINCI-003，由于上下文学习能力有限，添加示例可能导致执行准确度下降。对于Vicuna-33B，其性能随着DAIL组织示例的数量的增加而持续改善。对于 TEXT-DAVINCI-003，如图4(c)和图4(g)所示，全信息组织远远超出了其他两种策略，特别是随着实例数量的增加。图4(d)和图4(h)说明了在 Vicuna-33B 的情况下，DAIL Organization 外形为 SQL-Only Organization，但是没有达到 Full-Information Organization 所实现的性能。通过比较不同的 LLM，我们推断对于具有更强的上下文学习能力的 LLM 来说，如 GPT-4，DAIL 组织是最有益的，而较弱的 LLM 需要更多的信息来从实例中学习。本文认为DAIL 组织可以是实现更高的性能一个很好的选择，在本文所有测试中，最好的执行准确性是 DAIL+GPT-4。更多比较见下图：

4.4 监督微调

4.4.1 开源大模型

        有LLaMA-7B/13B/33B、Falcon-40B、Alpaca-7B、GPT4ALL-7B、LLaMA-2-CHAT-7B/13B/70B、Vicuna-7/13/33B、CodeLLaMA-34B

4.4.2 在zero-shot场景下使用开源大模型

        实验结果：

        实验结果分析从问题表征、模型尺度和对齐三个方面分析：

        问题表示的影响：最好性能的是CR+CodeLLaMA-34B。可能原因是CR中的完整数据库知识弥补了开源LLM的不足，另一个可能的原因是CR倾向于刺激LLM的编码能力。

        模型尺度的影响：结果表明，LLaMA 和 Vicuna 的模型规模与text-to-SQL性能呈正相关。

        对齐的影响：从结果中，我们观察到 LLM 对齐可以使 Text-to-SQL 受益。具体来说，在相同的模型尺度下，Vicuna 在 Spider-dev 和 Spider-Realistic 上的执行准确率比 LLaMA 高出约5% 。尽管 CodeLLaMA-34B 的参数只有 LLaMA-2-CHAT-70B 的一半，但它的性能平均比 LLaMA-2-CHAT-70B 高出20.6% ，这突出了训练语料库在 LLM 中的重要性。

4.4.3 在few-shot场景下使用开源大模型

        本节使用 DAIL 选择来选择例子，实验结果如下图：

        上图显示了LLaMA-33B 和Vicuna-33B与CR的性能。从这个图中，我们可以看到 LLaMA-33B 比 Vicuna-33B 效果更好，并且通过5-shot全信息组织示例，可以达到了36.4% 的精确匹配精度。关于执行匹配的准确性，在大多数情况下，增加示例数量对 Text-to-SQL 有好处。此外，在不同的组织策略中，全信息组织策略在不同的 K-shot 情境中的执行效果优于其他策略。

        开源大模型在各种示例组织形式下的性能：

4.4.4 基于开源 LLM 的监督微调。

zero-shot 方案：

        实验结果如下图：

        比较不同的表示方法，Alpaca SFT Prompt 在监督微调方面表现出明显的优势，因为它是针对这种情况而设计的。同时，不同表示和不同模型规模间的差距在微调后逐渐变小，可能的原因是经过微调之后，LLM学习如何在没有任务指令和外键的情况下回答新的Text-to-SQL问题。在本实验中，采用 LLaMA-13B 和 Alpaca SFT Prompt 相结合的方法，获得了最佳的性能，其精确匹配率和执行精度分别为65.1% 和68.6% 。对于较大的 LLM，LLaMA-33B 和代码表示提示相结合，可以达到69.1% 的执行准确率和65.9% 的精确集匹配准确率。更多结果见下表：

        总之，监督微调对于text-to-sql中的开放源码LLM非常有益，与OpenAI的LLM相比，在zero-shot的环境下，微调 LLaMA-13B 和30B与TEXT-DAVINCI-003相当，略弱于GPT-4和GPT-3.5-TURBO。

few-shot方案：

        实验结果如下图：
 

        出乎意料的是，经过微调的 LLM 无法从示例中学习。具体来说，在测试提示中添加上下文示例会导致精确集匹配和执行匹配精度的突然下降，而且添加更多示例也没有帮助。一个可能的原因是 LLM 过分适合于zero-shot，这使得示例没有用处。 

4.5 token效率

        本节的实验结果如下图，其中的示例选择设置为DAIL类型：

        考虑到OpenAI LLM的费用是由token数量决定的，且LLM的运行时间与tokne的长度成正比，我们在提示词工程中对token效率进行了评分，目的是用更少的token获得更高的精度。对于 OpenAI 和开源 LLM，token的数量主要受到问题表示和示例组织的影响。除此之外，我们在比较了一些最先进的text-to-SQL 方法，包括 DIN-SQL、 STRIKE和 CBR-ApSQL，并把他们报告的最高执行精度作为他们的表现。 DIN-SQL是将10个随机抽样实例的token数进行平均。STRIKE的最佳性能是通过多数投票实现的，从1-shot到5-shot的结果，导致token的成本显着增加。对于 CBR-ApSQL 来说，toke代价是通过问题表示法和SQL-Only组织中的8-shot 示例来计算的。

        在few-shot的场景，FI效率非常低，其token数是DAIL和SO的数倍。在准确率上DAIL+GPT-4准确率最高且token数和SO相当。因此，在token效率方面DAIL比SO和FI更有高。与其他先进的解决方案相比（DIN-SQL和STRIKE），DAIL-SQL的准确率和效率都更高。

        总之，令牌效率是 LLM 在 Text-to-SQL 上的实际应用程序的一个关键指标。

5. DISCUSSION

        本文的实验可以得到如下经验：

        1. 问题表示：建议使用代码表示提示符和 OpenAI 演示提示符。其他信息，如外键和规则含义可能非常有用。

        2.示例选择：自然语言问题和SQL查询的相似性都很重要。这两个相似性指标可以帮助设计有效的选择策略。

        3.示例组织：如果采用的 LLMispower 足够强大，比如 GPT-4，使用问题-SQL 查询对是一个有效且高效的选择。模型不够强大时，还是建议给出完整的信息示例。

        4.开源大模型：LLM 中有更多的参数有利于text-to-SQL任务，但是训练语料库起着很重要的作用。此外，监督微调是必要的，在text-to-SQL中有相当大的潜力。

6.CONCLUSIONS

        略