NL2SQL进阶系列(5)：论文解读业界前沿方案（DIN-SQL、C3-SQL、DAIL-SQL）、新一代数据集BIRD-SQL解读

NL2SQL基础系列(1)：业界顶尖排行榜、权威测评数据集及LLM大模型（Spider vs BIRD）全面对比优劣分析[Text2SQL、Text2DSL]

NL2SQL基础系列(2)：主流大模型与微调方法精选集，Text2SQL经典算法技术回顾七年发展脉络梳理

NL2SQL进阶系列(1)：DB-GPT-Hub、SQLcoder、Text2SQL开源应用实践详解

NL2SQL进阶系列(2)：DAIL-SQL、DB-GPT开源应用实践详解[Text2SQL]

NL2SQL进阶系列(3)：Data-Copilot、Chat2DB、Vanna Text2SQL优化框架开源应用实践详解[Text2SQL]

☆☆NL2SQL进阶系列(4)：ConvAI、DIN-SQL、C3-浙大、DAIL-SQL-阿里等16个业界开源应用实践详解[Text2SQL]

☆☆NL2SQL进阶系列(5)：论文解读业界前沿方案（DIN-SQL、C3-SQL、DAIL-SQL、SQL-PaLM）、新一代数据集BIRD-SQL解读

NL2SQL实践系列(1)：深入解析Prompt工程在text2sql中的应用技巧

NL2SQL实践系列(2)：2024最新模型实战效果(Chat2DB-GLM、书生·浦语2、InternLM2-SQL等)以及工业级案例教学

NL2SQL任务的目标是将用户对某个数据库的自然语言问题转化为相应的SQL查询。随着LLM的发展，使用LLM进行NL2SQL已成为一种新的范式。在这一过程中，如何利用提示工程来发掘LLM的NL2SQL能力显得尤为重要。

1.DIN-SQL-V3 2023.11.02

• [v1] Fri, 21 Apr 2023 15:02:18 UTC (8,895 KB)

• [v2] Thu, 27 Apr 2023 17:49:23 UTC (8,895 KB)

• [v3] Thu, 2 Nov 2023 20:30:12 UTC (2,202 KB)

论文链接：DIN-SQL: Decomposed In-Context Learning of Text-to-SQL withSelf-Correction

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

在本文中，我们提出了一种基于少样本提示（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％的匹配精度。

1.1 Few-shot Error Analysis

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

• Schema Linking

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

• JOIN

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

• GROUP BY

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

• Queries with Nesting and Set Operations

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

• Invalid SQL

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

• Miscellaneous

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

1.2 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 就有能力解决所有这些问题。

Schema Linking Module（模式链接）

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

对于问题中每次提到的列名，都会从给定的数据库模式中选择相应的列及其表。还从问题中提取可能的实体和单元格值。图 3 给出了一个示例，完整的提示可以在附录 A.3 中找到。

Classification & Decomposition Module（查询分类和分解模块）

对于每个连接，都有可能未检测到正确的表或连接条件。随着查询中联接数量的增加，至少一个联接无法正确生成的可能性也会增加。缓解该问题的一种方法是引入一个模块来检测要连接的表。此外，一些查询具有过程组件，例如不相关的子查询，它们可以独立生成并与主查询合并。为了解决这些问题，我们引入了查询分类和分解模块。该模块将每个查询分为三类之一：简单、非嵌套复杂和嵌套复杂。

• easy 类包括无需连接或嵌套即可回答的单表查询。

• 非嵌套类包括需要连接但没有子查询的查询，

• 嵌套类中的查询可以需要连接、子查询和集合操作。

类标签对于我们的查询生成模块很重要，该模块对每个查询类使用不同的提示。除了类标签之外，查询分类和分解还检测要为非嵌套和嵌套查询以及可能为嵌套查询检测到的任何子查询连接的表集。图 4 显示了提供给模型的示例输入以及模型生成的输出。

SQL Generation Module（SQL生成）

随着查询变得更加复杂，必须合并额外的中间步骤来弥合自然语言问题和 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 中提供了所有三个查询类别的完整提示，并且这三个类别的所有示例均从为分类提示选择的完全相同的数据库中获得。

Self-correction Module（自我纠正模块）

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

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

主要方法讲完，更多内容细节和测评效果参考原论文

1.3 案例

• Zero-shot prompting

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

• Few-shot prompting

2.C3: Zero-shot Text-to-SQL-2023.07.14

论文链接：https://arxiv.org/pdf/2307.07306.pdf

代码 https://github.com/bigbigwatermalon/C3SQL

在DIN-SQL提出的Few-shot方案的基础上，C3使用chatgpt作为基座模型，探索了zero-shot的方案，这样可以进一步降低推理成本。并且在生成效果上和DIN-SQL不相上下。C3方法的框架如图1所示。C3由三个关键组件组成：清晰提示（CP、Clear Prompting）、提示校准（CH）和一致性输出（CO），它们分别对应模型输入、模型偏差和模型输出。每个组件的细节如下介绍。

C3也通过Schema Linking先定位问题相关的数据表和查询字段。不过在指令构建上，论文认为在编写指令时，简洁的文本格式(clear layout)，以及不引入不相关的表结构(clear context)，会降低模型理解难度，对模型效果有很大提升。下面我们分别看下这两个部分

2.1 Clear Prompting

Clear Prompting (CP) 组件的目标是为文本到SQL解析提供有效的prompt。它包括两个部分：clear layout and clear context

• 类型 1：复杂布局：这种提示布局直接将说明、问题和上下文（数据库模式）直接连接在一起，显得混乱不堪。

• 类型 2：清晰布局：这种布局通过采用清晰的符号将说明、上下文（数据库模式）和问题分开，看起来清晰明了。

2.1.1 Clear Layout

后面的SQL-Palm也进行了类似的消融实验，对比符合人类自然语言描述的Table Schema，使用符号表征的prompt效果显著更好，在执行准确率上有7%左右的提升。

2.1.2 Clear Context

把整个数据库的全部表结构放入schema linking Context，一方面增加了推理长度，一方面会使得模型有更大概率定位到无关的查询字段。因此C3通过以下两步先召回相关的数据表和表字段，再进行schema linking

• 数据表召回

C3使用以下zero-shot指令，让大模型基于数据表schema，召回问题相关的数据表。这一步作者采用了self-consistency来投票得到概率最高的Top4数据表。当前的一些开源方案例如ChatSQL等，也有采用相似度召回的方案，更适合低延时，面向超大数据库的场景。不过需要先人工先对每张表生成一段表描述，描述该表是用来干啥的，然后通过Query*Description的Embedding相似度来筛选TopK数据表。

• 首先，表格应基于其与问题的相关性进行排名。

• 其次，模型应检查是否考虑了所有表格。

• 最后，输出格式被规定为一个列表

为确保Table Recall的稳定性，我们采用了一种self-consistency。具体而言，模型生成了十组检索结果，每组包含前四个表格。最终的结果由在这十组中出现最频繁的一组确定。

instruction = """Given the database schema and question, perform the following actions: 

1 - Rank all the tables based on the possibility of being used in the SQL according to the question from the most relevant to the least relevant, Table or its column that matches more with the question words is highly relevant and must be placed ahead.

2 - Check whether you consider all the tables.

3 - Output a list object in the order of step 2, Your output should contain all the tables. The format should be like: 

["table_1", "table_2", ...]

"""

• 表字段召回

在以上得到问题相关的数据表之后，会继续执行表字段召回的操作，同样使用了Self-Consistency多路推理投票得到概率最高的Top5字段。这一步同样可以使用相似度召回，尤其在中文场景，以及垂直领域的数据表场景，直接使用字段名并不足够，也需要对表字段名称生成对应的描述，然后使用相似度进行召回。

• 首先，基于它们与问题的相关性对每个候选表格内的所有列进行排名。

• 然后，输出格式被规定为一个字典。

instruction = '''Given the database tables and question, perform the following actions: 

    1 - Rank the columns in each table based on the possibility of being used in the SQL, Column that matches more with the question words or the foreign key is highly relevant and must be placed ahead. You should output them in the order of the most relevant to the least relevant.

    Explain why you choose each column.

    2 - Output a JSON object that contains all the columns in each table according to your explanation. The format should be like: 

    {

        "table_1": ["column_1", "column_2", ......], 

        "table_2": ["column_1", "column_2", ......],

        "table_3": ["column_1", "column_2", ......],

         ......

}

在提示中，我们还强调了与问题词或外键更匹配的列应该放在前面，以协助更准确的检索结果。同样，我们采用了self-consistency。具体而言，对于每个表格，我们一次生成十组检索到的列。然后，我们选择在每组中出现最频繁的五列作为最终结果。除了被检索到的表格和列之外，我们还将被检索到的表格的外键信息添加到上下文部分，以指定join操作所需的列。

2.2 self-consistency

Schema Linking之后，c3没有像DIN一样去判断问题的难度，而是用统一的zero-Prompt来对所有问题进行推理。不过在推理部分引入了Self-Consistency的多路投票方案。

针对每个问题会随机生成多个SQL，然后去数据库进行执行，过滤无法执行的sql，对剩余sql的执行结果进行分组，从答案出现次数最多的分组随机选一个sql作为最终的答案，也就是基于sql执行结果的major vote方案。效果上c3在spider数据集上，使用干净简洁的zero-shot-prompt+self-consistency，基本打平了Few-shot的DIN-SQL

2.3 Calibration of Model Bias(模型校准)

通过分析生成的SQL查询中发生的错误，我们发现其中一些错误是由ChatGPT固有的某些biases引起的。如图3所示，ChatGPT倾向于提供额外的列和额外的执行结果。本文总结了它们为以下两种biases。

• bias1：ChatGPT在输出中倾向于保守，通常选择与问题相关但不一定必需的列。此外，我们发现在涉及数量的问题时，这种倾向尤为明显。例如，在图3（左侧）中的第一个问题中，ChatGPT在SELECT子句中选择了Year和COUNT(*)。然而，Spider数据集中的正确SQL仅选择了Year，因为COUNT()仅用于排序目的。

• bias2：ChatGPT在编写SQL查询时倾向于使用LEFT JOIN、OR和IN，但通常未能正确使用它们。这种偏见常常导致执行结果中出现额外的值。图3（右侧）中可以找到这种偏见的一些例子。

2.3.1 Calibration with Hints (CH)策略校准

为了校准这两个偏见，我们提出了一种插件校准策略，称为Calibration with Hints (CH)。CH通过使用包含历史对话的上下文提示将先验知识引入ChatGPT。在历史对话中，我们最初将ChatGPT视为出色的SQL撰写者，并引导它遵循我们提出的去偏提示。

• 提示1：针对第一个偏见，我们设计了一个提示，引导ChatGPT仅选择必要的列。这个提示在图1的右上部分有图示。它强调在仅用于排序目的时，不应在SELECT子句中包括诸如COUNT(*)之类的项目。

• 提示2：针对第二个偏见，我们设计了一个提示，防止ChatGPT滥用SQL关键字。如图1右上部分所示，我们直接要求ChatGPT避免使用LEFT JOIN、IN和OR，而是使用JOIN和INTERSECT。我们还指示ChatGPT在适当时使用DISTINCT或LIMIT，以避免重复的执行结果。

2.4 Consistency Output 一致性输出

使用CP和CH方法，ChatGPT能够生成更高质量的SQL。然而，由于大型语言模型的固有随机性，ChatGPT的输出是不稳定的。为了了解ChatGPT不确定性输出的影响，我们分析了在不同提示下，在30次独立实验中开发集上正确计数的分布，如图4所示。在这个图中，ChatGPT-SQL是文献中提出的方法（Liu等，2023）；此外，CP和CP + CH分别表示我们提出的Clear Prompt和Clear Prompt与Clear Hint方法的组合。无论使用哪种方法，只有不到65%的SQL语句能够一致地被正确撰写。这意味着通过提高输出的一致性，模型有很大潜力正确地撰写大多数查询。

Self-consistency的动机是，在复杂的推理问题中，存在多个不同的推理路径可以得出唯一正确的答案。它首先对多个不同的推理路径进行抽样，然后选择最一致的答案，显著提高输出的质量。Text-to-SQL问题类似于推理问题，在其中有多种编写SQL查询的方式可以表示相同的含义，如图5所示。因此，我们实施了基于执行的自一致性。

具体而言，我们首先对多个推理路径进行抽样，生成多样化的SQL答案。然后，在数据库上执行这些SQL查询并收集执行结果。在从所有结果中删除错误之后，我们通过对这些执行结果应用投票机制，确定最一致的SQL作为最终SQL。例如，在图5中，我们根据执行结果对SQL查询进行分类，并用不同的颜色表示它们。然后，我们比较这些类别，确定哪个类别包含更多的SQL查询，并从该类别中选择一个SQL作为最终SQL。这种方法使我们能够利用从这些多个路径中得出的集体知识，在生成SQL查询时产生更可靠的结果。

2.5 最终Prompt 样例

当然从工程化角度看调用了太多模型，会导致性能偏低

3.DIAL-SQL 2023.11.20

论文链接：https://arxiv.org/pdf/2308.15363.pdf

大型语言模型（LLMs）已成为Text-to-SQL任务的一种新范式。然而，缺乏系统性的基准限制了设计有效、高效和经济的以大型语言模型为基础的 Text-to-SQL 解决方案的发展。为了应对这一挑战，本文首先对现有的提示工程方法进行了系统和广泛的比较，包括问题表示、示例选择和示例组织，并通过这些实验结果阐述了它们的优缺点。基于这些发现，我们提出了一种新的综合解决方案，名为 DAIL-SQL，它在 Spider 排行榜上以 86.6% 的执行准确性刷新了纪录，树立了新的标杆。为了挖掘开源大规模语言模型的潜力，我们在各种场景中探讨它们的表现，并通过有监督的微调进一步优化它们的性能。我们的研究揭示了开源大规模语言模型在Text-to-SQL 领域的潜力，以及有监督微调的优缺点。此外，为了实现高效且经济的大规模语言模型为基础的Text-to-SQL解决方案，我们强调了提示工程中的token效率，并以此为准则比较了先前的研究。我们希望我们的工作能加深对大规模语言模型中Text-to-SQL 的理解，并激发进一步的研究和广泛的应用。

3.1 研究方法

3.1.1 基础方法

• Basic Prompt ( B S P \mathrm BS_P BSP​). Basic Prompt [31] is a simple representation shown in Listing 1. It is consisted of table schemas, natural language question prefixed by “Q: ” and a response prefix “A: SELECT” to prompt LLM to generate SQL. In this paper we named it as Basic Prompt due to its absence of instructions.

基本提示 ( B S P \mathrm BS_P BSP​)。基本提示 [31] 是一个简单的表示，如 Listing 1 所示。它由表模式、前缀为 “Q:” 的自然语言问题和提示 LLM 生成 SQL 的响应前缀 “a:SELECT” 组成。在本文中，由于它没有指令，我们将其命名为基本提示。

• 文本表示法提示 ( T R P \mathrm TR_P TRP​)。如 Listing 2 所示，文本表示提示 [25] 表示自然语言中的模式和问题。与基本提示相比，它在提示的最开始就添加了指导 LLM 的指令。在 [25] 中，在零样本场景中，它在 Spider-dev 上实现了 69.0% 的执行准确率。

• OpenAI 演示提示 ( O D P \mathrm OD_P ODP​)。OpenAI 演示提示（Listing 3）首次在 OpenAI 的官方文本到 SQL 演示 [28] 中使用，并在 [22，31] 中进行了评估。它由指令、表模式和问题组成，其中所有信息都用磅号 “#” 进行注释。与文本表示提示相比，OpenAI 演示提示中的指令更具体，有一条规则，“仅完成 sqlite SQL 查询，无需解释”，我们将在第 4.3 节中进一步讨论，并结合实验结果。

• 代码表示提示（ C R P \mathrm CR_P CRP​）。代码表示提示 [5，25] 以 SQL 语法表示文本到 SQL 任务。具体来说，如 Listing 4 所示，它直接呈现“CREATTABLE”SQL，并在注释中用自然语言问题提示 LLM。与其他表示相比， C R P \mathrm CR_P CRP​它之所以引人注目，是因为它能够提供创建数据库所需的全面信息，例如列类型和主键 / 外键。有了这样的表示，[25] 使用 LLM CODE-DAVINCI-002 正确预测了约 75.6% 的 SQL。

Alpaca SFT 提示 ( A S P \mathrm AS_P ASP​)。Alpaca SFT 提示是一种用于监督微调的提示 [38]。如 Listing 5 所示，它提示 LLM 按照指示并根据 Markdown 格式的输入上下文完成任务。我们将其包括在内，以检查其在即时工程和监督微调场景中的有效性和效率。

如表 1 所示，不同的表示用不同的 LLM 进行实验，并集成在不同的框架中，这使得很难公平有效地进行比较。此外，外国关键信息和规则含义等个别组成部分所扮演的具体角色仍不清楚。因此，有必要进行系统的研究，以更好地理解问题表征，并通过公平的比较来考察它们的优缺点。

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

3.2.1 示例选择

我们先总结一下先前研究中各种示例选择策略如下。

随机选择。此策略随机采样