LLM Text2SQL能力基准测试：全面评估

大型语言模型（LLMs）已成为推进文本到SQL（Text-to-SQL）任务的强大工具，显著超越了传统方法。然而，作为一个新兴的研究领域，目前还没有关于最佳提示模板和设计框架的共识。此外，现有的基准测试未能充分探索LLMs在Text-to-SQL过程中各个子任务的性能，这阻碍了对LLMs认知能力的评估和基于LLM的解决方案的优化。为了解决上述问题，我们首先构建了一个新的数据集，旨在减轻LLMs过拟合的风险。然后，我们制定了五个评估任务，全面评估不同LLMs在Text-to-SQL过程中的性能。我们的研究突出了LLMs之间的性能差异，并提出了针对每个任务的最佳上下文学习解决方案。这些发现为促进基于LLM的Text-to-SQL系统的发展提供了宝贵的见解。论文强调了Text-to-SQL任务的重要性，并指出了当前研究领域中存在的问题和挑战，为本文的研究目标和方法提供了背景和动机。

引言

Text-to-SQL任务涉及将自然语言（NL）问题自动转换为结构化的SQL语句，这是促进用户与数据库无缝交互的关键组成部分。以往的方法主要关注自然语言和SQL语句之间的模式匹配，利用机器学习模型来获取两者之间的映射。然而，LLMs的引入和快速发展为这一领域带来了重大变革。LLMs已成为强大的工具，展示了在理解复杂NL问题和生成准确SQL语句方面的巨大潜力。通过结合先进的推理技术和上下文学习能力，LLMs显著推动了这一领域的最新技术边界，大幅度超越了传统方法。

文本到SQL的方法

1. 传统基于学习的Text-to-SQL方法：这些方法主要分为非序列到序列（non-seq2seq）和序列到序列（seq2seq）方法。非序列到序列方法通常使用关系感知的自注意力机制作为编码器来学习问题和模式的表示，然后使用基于语法的解码器生成SQL。序列到序列方法直接通过基于变换器的架构将自然语言问题翻译成SQL查询。

2. 基于LLM的Text-to-SQL方法：随着LLMs的发展，研究者开始利用LLMs强大的语言和编码能力，通过零次推理和领域泛化能力，刷新了跨领域Spider排行榜的记录。例如，C3方法基于ChatGPT构建，通过模型输入、偏差和输出的处理，达到了82.3%的执行准确率。DIN-SQL通过将Text-to-SQL任务分解为更小的子任务，实现了85.3%的准确率。DAIL-SQL通过监督微调和系统研究上下文学习，刷新了Spider的准确率至86.6%。

评估步骤

1. 数据集构建：作者构建了一个名为“BigTable-0.2k”的新数据集，它是BIRD数据集的扩展和增强，旨在通过考虑问题复杂性、数据库大小和先验知识来减少LLMs的过拟合风险。

2. 选择评估模型：研究评估了两类LLMs的性能，包括通用目的和编码特定模型，这些模型在参数大小上有所不同。

3. 评估任务规划：研究制定了五个不同的任务来评估LLMs在Text-to-SQL过程中的能力，包括Text-to-SQL、SQL调试、SQL优化、模式链接和SQL到文本。

4. 评估指标：使用了执行准确率（EX）和有效执行分数（VES）等指标来评估SQL的准确性和执行效率。

传统学习型Text-to-SQL方法主要分为以下两类，并具有各自的特点：

1. 非序列到序列（Non-seq2seq）方法：

• 这类方法通常采用关系感知的自注意力机制作为编码器，用于学习问题和模式的表示。
• 然后使用基于语法的解码器生成SQL作为抽象语法树，或者利用基于草图的解码器通过填充槽位来获取SQL。
• 这些方法可以从预训练的语言模型（如BERT及其扩展）中受益，用于输入嵌入初始化。
• 非序列到序列方法在输入编码、输出解码、神经训练和输出精炼方面有较大的变化，使得Text-to-SQL成为一个繁荣的研究领域。

2. 序列到序列（Seq2seq）方法：

• 这类方法直接将自然语言问题翻译成SQL查询，通过基于变换器（Transformer）的架构以端到端的方式进行。
• 这些方法通过微调而不是从头开始训练，以较少的努力获得竞争力的性能。
• 它们通常使用更智能的解码技术（例如，约束解码器的预测或模式感知去噪）来防止生成无效的SQL。
• 例如，RESDSQL方法进一步解耦了模式链接（确定SQL中的模式项，如表和列）和骨架解析（确定SQL关键字）的交织过程，这减轻了Text-to-SQL的难度。

传统学习型Text-to-SQL方法的特点：

• 依赖于模式匹配和机器学习模型来建立自然语言和SQL之间的映射。
• 通常需要大量的标注数据来训练模型。
• 在处理复杂查询和多表查询时可能面临挑战。
• 尽管在Spider等基准测试中取得了一定的成绩，但最高准确率仍然远未达到可靠的Text-to-SQL解析器的水平。

这些传统方法在LLMs出现之前是Text-to-SQL领域的主要研究方向，但随着LLMs的发展，它们在性能上逐渐被超越。

论文中，大型语言模型（LLMs）在文本到SQL任务中的优势主要体现在以下几个方面：

1. 强大的理解能力：LLMs能够理解复杂的自然语言问题，并将其转换为准确的SQL语句。这得益于它们在预训练阶段接触到的大量文本数据，使得它们能够捕捉到语言的细微差别和上下文信息。

2. 先进的推理技术：LLMs结合了先进的推理技术，这使得它们能够在处理文本到SQL任务时，更好地理解和执行复杂的查询逻辑。

3. 上下文学习能力：LLMs展现出了在上下文中学习的能力，这意味着它们可以根据给定的上下文（如数据库模式和用户问题）来生成合适的SQL查询。这种能力对于处理多表查询和复杂SQL语句尤为重要。

4. 零样本和少样本学习：LLMs能够在没有或仅有少量示例的情况下进行学习，这在文本到SQL任务中尤其有用，因为可以减少对大量标注数据的依赖。

5. 性能提升：LLMs在多个基准测试中显著提高了文本到SQL任务的性能，与传统方法相比，它们在执行准确度上有显著提升。

6. 自我调试能力：LLMs展现出了自我调试的能力，它们能够识别并修正自己生成的SQL语句中的错误，这对于提高生成SQL语句的准确性至关重要。

7. 优化SQL查询：LLMs还能够优化SQL查询，提高查询的执行效率，这对于实时系统和大规模数据库尤为重要。

8. 模式链接能力：LLMs在模式链接方面表现出色，这是生成正确SQL查询的先决条件。它们能够理解数据库的结构和用户问题的语义，并准确地将问题中的实体引用与相应的数据库表或列对齐。

总的来说，LLMs在文本到SQL任务中的优势在于它们强大的语言理解能力、推理能力、上下文学习能力以及自我调试和优化能力，这些都使得它们在这一领域具有显著的潜力。

数据集和评估指标

WikiSQL被认为是第一个大规模的数据集，它使得基于学习的Text-to-SQL方法的训练和评估成为可能，同时也提供了一个标准化的基准，以便在各种方法之间进行直接比较。它也被称为跨领域数据集，包含了超过25,000个表格和80,000个问题-SQL对，涵盖了从Wikipedia派生的各种领域。然而，WikiSQL中的SQL查询表现出较低的复杂性。

随后，大多数最近的Text-to-SQL工作都是在Spider上进行的，因为它被广泛认为是最具挑战性的跨领域基准。它包括10,181个查询，涵盖了138个不同的领域，涉及多表查询（通过JOIN体现）、复杂的SQL子句（如ORDER BY、GROUP BY和HAVING等）以及嵌套SQL。Spider的几种变体被设计出来以评估Text-to-SQL方法的适应性。

鉴于Spider专门为基准测试Text-to-SQL方法而设计，与实际场景有所偏离，KaggleDBQA从Kaggle构建了一个小型的跨领域数据集，强调了实际网络源数据库的多样性。它包含了数据库的文档和元数据等知识，提出了如何利用这些额外信息来提高性能的问题。

最新的里程碑式基准是BIRD，它包含了12,751个Text-to-SQL对和95个数据库，总大小为33.4 GB。它结合了以前数据集的优点，如Spider（跨领域且包含复杂SQL）和KaggleDBQA（需要使用外部知识证据）。它是第一个为评估SQL执行效率而策划的大规模数据库，从而进一步弥合了学术设置和实际应用之间的差距。在本文中，我们构建了一个基于BIRD的新数据集，并在评估中使用（见第3.3节）。

在Spider上评估SQL准确性的两个主要评估指标是精确匹配（Exact Matching, EM）和执行准确度（Execution Accuracy, EX）。

• EM 衡量预测查询整体是否与标准查询等价。由于一个问题可能通过多个语法不同但语义相同的SQL语句解决，所以可能会遇到假阴性评估。
• EX 是一个更广泛使用的指标，衡量执行预测查询的结果是否与标准值匹配。我们在本文中使用EX来评估SQL的准确性。
  此外，BIRD进一步提出了有效性分数（Valid Efficiency Score, VES），这是一个综合指标，评估执行结果的准确性（即EX）和SQL查询的执行效率。为了提高VES，方法需要同时提高SQL查询的执行准确性和效率。

评估模型选择

论文中基准研究评估了两类具有不同参数规模的LLMs的性能：通用目的和特定于编码。

• 通用目的LLMs旨在为多样化领域的文本生成和理解提供服务，它们在广泛的互联网文本数据集上进行训练。选择了ChatGPT (gpt-35-turbo-16k) 2, LLaMa2-Chat-70B, InternLM-70B 3和InternLM2-20B作为主要的基线模型。
• 特定于编码的LLMs经过微调和优化，以适应编程场景，擅长代码生成和技术语言理解。选择了Codellama-34B 和 SQLCoder-34B的性能分析。

根据论文中的讨论，现有的Text-to-SQL数据集和评估指标存在以下局限性：

1. 数据集复杂性：现有的数据集（如WikiSQL）虽然提供了大量的表格和问题-SQL对，但SQL查询的复杂性相对较低，这可能不足以全面评估模型处理复杂查询的能力。

2. 跨领域挑战：Spider数据集被认为是最具挑战性的跨领域基准，但它包含了多表查询、复杂SQL子句和嵌套SQL，这可能导致评估结果与实际应用场景的差异。

3. 评估指标的局限性：在Spider数据集上，常用的评估指标包括精确匹配（Exact Matching, EM）和执行准确度（Execution Accuracy, EX）。EM可能因为多个语法不同但语义相同的SQL语句而产生假阴性评估。EX虽然更常用，但它可能无法完全反映模型在SQL生成中的准确性和效率。

4. 过拟合风险：现有的数据集可能在LLMs的训练过程中被过度利用，导致模型在这些数据集上表现良好，但在新的、未见过的数据上泛化能力不足。

5. 缺乏子任务评估：现有的基准测试通常关注端到端的Text-to-SQL任务，而没有详细探索模型在Text-to-SQL过程中各个子任务（如模式链接、SQL调试等）的性能。

6. 执行效率的评估：BIRD数据集提出了有效性分数（Valid Efficiency Score, VES），这是一个综合指标，评估执行结果的准确性和SQL查询的执行效率。然而，LLMs在优化SQL查询以提高执行效率方面仍面临挑战。

7. 缺乏统一的评估框架：没有一个全面的框架来评估LLMs在Text-to-SQL任务中的所有方面，这使得不同研究之间的比较和模型的改进变得困难。

8. 外部知识的需求：KaggleDBQA数据集强调了实际Web源数据库的多样性，并提出了如何利用数据库的文档和元数据来提高性能的问题，这表明现有的数据集可能没有充分考虑外部知识在Text-to-SQL任务中的作用。

为了克服这些局限性，论文中提出了构建新的数据集和评估任务，以更全面地评估LLMs在Text-to-SQL任务中的性能。

数据集构建

对各种LLMs在多个开源数据集上的性能进行了初步评估。如表1所示，LLMs在不同数据集上的性能表现不一致。具体来说，在Spider数据集上，Codellama-34B优于InternLM-70B和SQLCoder-34B，而在Bird数据集上，SQLCoder-34B超过了InternLM-70B和Codellama-34B。一方面，不同的LLMs可能在处理不同类型的问题上有优势。另一方面，考虑到LLMs从大型语料库中学习和训练，这些发现表明，观察到的性能差异可能归因于在微调过程中对开源数据集的潜在利用，特别是对于特定于编码的LLMs。这在确保这些数据集上获得的评估结果的可靠性方面带来了挑战。

为了解决LLMs（特别是那些专门用于编码任务的LLMs）可能存在的过拟合问题，并确保对其能力的可靠和准确评估，我们构建了一个新数据集，称为“BigTable-0.2k”。这个数据集是最近发布的广泛认可的用于评估Text-to-SQL解析的基准BIRD数据集的扩展和增强。

表2：“BigTable-0.2k”的数据分布，包括实例中涉及的平均地面真实（GT）表格数量。

具体来说，我们的构建过程包括对原始BIRD数据集的系统分析，识别不同难度级别和涉及不同数量表格（1、2、3和超过3个）的查询。我们通过更改表格和列名以及过滤条件来修改和扩展这些查询，以创建更具挑战性的多样化问题集。原始数据集缺乏四个或更多表格的足够示例的情况下（在BIRD-Dev数据集中只有20个实例），我们将涉及三个表格的查询扩展到四个。如表2所示，这个过程为每个类别生成了50个新实例，从而产生了“BigTable-0.2k”数据集。此外，数据集中的每个项目都经过至少两个人的相互验证，以确保准确性。

“BigTable-0.2k”数据集保留了原始BIRD数据集的属性，如其大规模和复杂性、数据来源的多样性、跨领域适用性以及对外部知识推理的需求。

现有的Text-to-SQL模型在处理多表查询和复杂SQL子句时面临的问题主要包括：

1. 模式链接的准确性：在多表查询中，正确地识别和链接涉及的数据库表是一个挑战。模型需要理解自然语言问题中的实体如何映射到数据库模式中的表和列。现有的模型可能在处理具有高度语义相似性的表或列时出现错误。

2. 复杂子句的处理：复杂SQL子句，如包含ORDER BY、GROUP BY和HAVING子句的查询，要求模型能够理解和生成复杂的逻辑结构。这可能超出了一些模型的能力，导致生成的SQL语句无法正确执行或返回错误的结果。

3. 多表JOIN操作：在多表查询中，JOIN操作是常见的，但正确地执行JOIN并处理相关联的数据需要模型具备高级的推理能力。现有的模型可能在处理涉及多个表的JOIN条件时遇到困难。

4. 语义理解的深度：生成准确的SQL查询需要深入理解自然语言问题中的意图和上下文。对于复杂查询，模型需要能够捕捉到问题中的细微差别，这在现有的模型中仍然是一个挑战。

5. 执行效率：除了生成正确的SQL语句外，提高查询的执行效率也是一个重要目标。现有的模型可能生成了语法正确但效率低下的SQL语句，这在实时系统中尤其成问题。

6. 泛化能力：现有的模型可能在特定的数据集上表现良好，但在新的、未见过的数据集上泛化能力不足。这表明模型可能过度拟合了训练数据，而没有学会通用的查询生成策略。

7. 错误调试和修正：当模型生成错误的SQL语句时，它们可能无法有效地识别和修正错误。这在多表查询和复杂子句中尤为明显，因为错误可能涉及多个层面，如表的选择、列的引用、JOIN条件等。

8. 外部知识的应用：在实际应用中，可能需要利用外部知识来解决Text-to-SQL任务，例如，数据库的元数据和文档。现有的模型可能没有充分利用这些信息来提高查询的准确性和效率。

为了解决这些问题，研究人员正在探索更先进的模型架构、更有效的训练策略以及更全面的评估方法，以提高Text-to-SQL模型在处理多表查询和复杂SQL子句时的性能。

在处理多表查询时，现有的Text-to-SQL模型可能会犯以下几种常见的错误类型：

1. 表查询错误（Table Query Error）：

• 过多/缺失/错误表（Excessive/Missing/Incorrect Tables）：模型可能错误地选择了不必要的表（过多），遗漏了必要的表（缺失），或者选择了错误的表（错误）。

2. 列选择错误（Column Selection Error）：

• 过多/缺失/错误列（Excessive/Missing/Incorrect Columns）：模型可能选择了过多的列，或者遗漏了必要的列，或者选择了错误的列。

3. JOIN列错误（Join Columns Error）：

• 在执行JOIN操作时，模型可能没有正确地匹配两个表中的相关列，导致错误的数据关联。

4. 条件过滤错误（Condition Filter Error）：

• 模型可能在应用条件过滤时出现错误，例如使用了错误的比较逻辑或者应用了错误的过滤条件。

5. 数据处理错误（Data Processing Error）：

• 在数据加工阶段，模型可能在聚合、计算等操作中出现错误，导致最终结果不准确。

6. SQL语法错误（System Error）：

• 尽管不直接与多表查询相关，但模型生成的SQL语句可能包含语法错误，如拼写错误、缺少关键字等。

7. 结果错误（Result Error）：

• 即使SQL语句在语法上是正确的，执行结果可能与预期的地面真实（ground truth）不符。这可能是由于上述任何一种错误导致的。

8. 外部知识应用不足：

• 在需要外部知识来正确链接表和列的情况下，模型可能没有充分利用这些信息，导致链接错误。

9. 上下文理解不足：

• 模型可能没有充分理解用户问题的上下文，导致无法正确地识别和链接涉及的表和列。

10. 模式链接的不准确性：

• 在将自然语言问题中的实体与数据库模式中的表或列进行链接时，模型可能无法准确地识别正确的映射关系。

为了解决这些问题，研究人员正在开发更先进的模型架构，改进训练策略，并设计更有效的提示（prompt）模板来引导模型生成更准确的SQL查询。此外，也在探索如何利用外部知识库和数据库元数据来提高模型的性能。

在处理多表查询时，Text-to-SQL模型避免列选择错误的策略通常涉及以下几个方面：

1. 增强语义理解：通过改进模型的语义理解能力，使其能够更准确地理解用户查询的意图和上下文，从而正确识别所需的列。这可能涉及到对模型进行更深入的预训练，或者在特定任务上进行微调。

2. 改进模式链接：确保模型能够准确地将用户查询中的实体映射到数据库模式中的相应列。这可能需要设计更有效的提示模板，或者使用外部知识库来辅助模型理解。

3. 使用注意力机制：在模型中引入注意力机制，特别是在处理多表查询时，可以帮助模型集中注意力于与查询最相关的列。这可以通过调整模型架构，如使用自注意力或图注意力网络来实现。

4. 上下文学习：利用上下文学习技术，使模型能够根据给定的数据库模式和用户问题动态调整其输出。这可以通过在训练过程中引入上下文信息，或者在生成SQL查询时使用上下文提示来实现。

5. 错误检测和修正：在模型生成SQL查询后，实施错误检测和修正机制。这可以包括使用规则引擎来识别常见的列选择错误，或者训练模型进行自我调试，以识别并修正其生成的SQL查询中的错误。

6. 多任务学习：通过多任务学习，同时训练模型处理多种类型的SQL查询，包括单表查询和多表查询。这有助于模型学习到更通用的列选择策略。

7. 数据增强：在训练数据中引入更多的多表查询示例，特别是那些涉及复杂列选择的情况。这可以帮助模型更好地泛化到新的查询场景。

8. 集成外部知识：利用数据库的元数据和文档来辅助模型理解表和列之间的关系，从而提高列选择的准确性。

9. 评估和反馈：在模型训练过程中，使用精确的评估指标来衡量列选择的准确性，并根据评估结果调整模型参数。

通过这些策略的综合应用，Text-to-SQL模型可以更有效地避免在处理多表查询时的列选择错误，从而提高生成SQL查询的准确性。

本研究提出了五个评估任务，旨在全面评估大型语言模型（LLMs）在Text-to-SQL过程中的性能。这些任务分别反映了LLMs在不同方面的处理能力：

1. Text-to-SQL：这个任务评估模型将自然语言问题转换为SQL查询的能力。它反映了模型理解自然语言问题和生成结构化查询语句的能力。

2. SQL Debugging：在这个任务中，模型需要识别并修正生成的SQL查询中的错误。这测试了模型的自我调试能力，包括识别不同类型的错误（如系统错误、结果错误）并进行有效的修正。

3. SQL Optimization：这个任务要求模型优化给定的SQL查询以提高执行效率，同时保持查询结果的准确性。这反映了模型在理解查询执行效率和进行系统级优化方面的能力。

4. Schema Linking：在这个任务中，模型需要将自然语言问题中的实体与数据库模式中的表和列正确关联。这测试了模型在模式理解和实体解析方面的能力。

5. SQL-to-Text：这个任务涉及将SQL查询转换回其原始的自然语言问题。这不仅测试了模型在理解SQL查询语义方面的能力，还有助于评估模型在语义描述和转换方面的表现。

这五个任务共同构成了一个全面的评估框架，它们从不同的角度考察了LLMs在Text-to-SQL任务中的性能，包括语言理解、问题解析、错误处理、模式链接和语义转换等关键能力。通过这些任务，研究人员可以更深入地了解LLMs在Text-to-SQL领域的强项和弱点，从而指导未来的研究方向和模型改进。

在Schema Linking任务中，LLMs的表现取决于它们理解和链接自然语言问题中的实体与数据库模式中相应表和列的能力。根据论文中的评估，以下是一些有效的方法和LLMs的表现概述：

1. Zero Shot：这种方法要求LLMs在没有任何示例的情况下直接对数据库表进行排名，根据问题的相关性从最相关到最不相关。这种方法通常依赖于模型的预训练知识和对自然语言的理解能力。

2. Few Shot：在这种方法中，LLMs通过提供少量示例来学习如何链接表。这些示例展示了如何根据问题中的关键词与数据库模式中的表进行匹配。Few Shot方法通常比Zero Shot方法表现更好，因为它提供了具体的上下文信息。

3. PreSQL：这种方法首先使用Text-to-SQL模型生成一个初步的SQL查询，然后从这个查询中提取表和列信息作为Schema Linking的结果。这种方法利用了LLMs在Text-to-SQL任务中的推理能力。

4. Few Shot + PreSQL：这种方法结合了Few Shot和PreSQL的优点，通过使用Few Shot示例来指导模型，并结合PreSQL生成的结果。这种方法旨在利用两种方法的优势，以提高Schema Linking的准确性。

在论文中提到的实验结果表明，特定于编码的模型（如SQLCoder）在使用PreSQL方法时表现最佳，而通用目的模型（如InternLM）在使用Few Shot + PreSQL方法时表现更好。这表明不同类型的LLMs在Schema Linking任务中可能有不同的优势。

此外，论文还提出了一种新的评估指标，称为检索效率分数（Retrieval Efficiency Score, RES），用于更准确地评估Schema Linking方法的性能。这个指标考虑了召回所有正确表的重要性，同时尽量减少冗余表的检索。

总的来说，Schema Linking任务是Text-to-SQL流程中的一个重要组成部分，LLMs在这个任务上的表现直接影响到最终生成的SQL查询的准确性。通过不断优化模型和方法，研究人员可以进一步提高LLMs在Schema Linking任务中的性能。

评估Evaluation

评估大型语言模型（LLMs）在Text-to-SQL任务中的方式和方法可以总结如下：

1. 任务划分：评估被划分为多个子任务，包括Text-to-SQL、SQL Debugging、SQL Optimization、Schema Linking和SQL-to-Text，以便全面评估LLMs在Text-to-SQL流程中的各个阶段。

2. Text2SQL Zero-shot 提示模板优化：对不同的提示模板进行测试，以确定在Text-to-SQL任务中哪些模板能够引导LLMs生成更准确的SQL查询。这包括对DDL/SimpleDDL前缀、MD/HTML/Coding中缀以及Complete/Chat后缀的不同组合进行评估。

3. 端到端评估：使用选定的最佳提示模板在新构建的数据集“BigTable-0.2k”上进行端到端的Text-to-SQL评估，以比较不同LLMs的性能。

4. SQL调试：评估LLMs在SQL调试方面的能力，包括自我调试和多轮调试，以及它们在处理不同类型的SQL错误时的表现。错误信息被分为两大类：

   系统错误（System Error）：这类错误指的是SQL语句中的语法错误。这些错误通常由数据库管理系统（DBMS）生成，例如“syntax error”（语法错误）和“no such column”（不存在的列）等。系统错误信息通常由DBMS提供，指出SQL语句中的语法问题。

   结果错误（Result Error）：这类错误表明SQL语句的语法是正确的，但执行结果与预期的地面真实（ground truth）不匹配。结果错误可能包括但不限于以下子类别：

   这些错误分类有助于更细致地分析LLMs在生成SQL查询时的常见问题，并为改进模型提供了方向。通过识别和分类这些错误，研究人员可以更好地理解模型在Text-to-SQL任务中的弱点，并针对性地进行优化。

• 表查询错误（Table Query Error）：涉及SQL查询中表选择的问题，如选择了过多的表、遗漏了必要的表或选择了错误的表。
• 列选择错误（Column Selection Error）：涉及SQL查询中列选择的问题，如选择了过多的列、遗漏了必要的列或选择了错误的列。
• JOIN列错误（Join Columns Error）：涉及JOIN操作中的错误，如错误地匹配了两个表的列。
• 条件过滤错误（Condition Filter Error）：涉及SQL查询中条件过滤的问题，如使用了错误的比较逻辑或应用了错误的过滤条件。
• 数据处理错误（Data Processing Error）：涉及SQL查询中数据处理阶段的错误，如聚合、计算等操作的错误。

为了评估不同信息粒度对性能的影响，我们提出了五种不同的自我调试策略，逐步引入更详细的信息：

• Regenerate 重新生成：简单地使用第4.1节中的相同提示重新生成SQL查询。这个设置作为基线，以消除模型随机性的影响。

• w/ Wrong SQL 使用错误的SQL：让LLMs基于错误的SQL语句生成一个新的SQL查询。

• w/ Wrong SQL + System_error_info 使用错误的SQL + 系统错误信息：提供错误的SQL语句、相应的系统错误信息和大致的结果错误信息。

• w/ Wrong SQL + All_error_info 使用错误的SQL + 所有错误信息：为那些语法正确但语义错误的SQL查询添加详细的结果错误信息。

• w/ Wrong SQL + All_error_info + Comment 使用错误的SQL + 所有错误信息 + 注释：为所有错误信息添加手动注释。有关详细的提示模板，请参见附录A.2。

如图4所示，随着引入更细粒度的错误信息，LLMs的自我调试性能呈上升趋势。在没有额外信息的情况下，LLM没有能力重新生成正确的答案。然而，所有模型都能够理解细粒度的错误信息，无论是否包括注释，并纠正自己的错误。

5. SQL优化：测试LLMs在SQL查询优化方面的能力，包括直接生成优化SQL和两阶段生成方法，并使用有效性分数（VES）和正确性有效性分数（C-VES）作为评估指标。

6. SQL转文本：评估LLMs将SQL查询转换回原始自然语言问题的能力，以验证SQL查询的准确性。这包括使用Rouge和BertScore等指标来衡量转换后的文本与原始问题的语义一致性。

7. 模式链接：评估LLMs在模式链接方面的表现，这是生成正确SQL查询的先决条件。引入了新的评估指标Retrieval Efficiency Score (RES)来衡量模式链接的性能。

8. 性能比较：比较不同LLMs在各个子任务上的性能，包括通用目的模型和特定于编码的模型，以确定它们在Text-to-SQL任务中的性能差异。

9. 错误信息分析：对LLMs生成的错误SQL查询进行详细分析，包括系统错误和结果错误，并进一步对结果错误进行分类，以便更好地理解模型的弱点。

10. 多轮调试：研究LLMs在多轮自我调试过程中的性能改进，以确定调试过程中性能提升的边界。

通过这些评估方法，研究提供了对LLMs在Text-to-SQL任务中性能的深入理解，并为未来的模型改进和优化提供了方向。

在论文中，为了评估大型语言模型（LLMs）在Text-to-SQL任务中的性能，研究者们设计了一系列的提示模板（prompt templates）。这些模板在结构和内容上有所不同，以测试模型在不同上下文中生成SQL查询的能力。以下是论文中提到的一些提示模板的例子：

1. DDL-HTML-Chat：这个模板包含了数据库模式（DDL）的详细表示，并以HTML格式呈现，同时在聊天（Chat）的上下文中要求模型回答问题。

2. SimpleDDL-MD-Chat：这个模板使用了简化的数据库模式（SimpleDDL），并用Markdown（MD）格式包裹整个提示，同样在聊天上下文中进行。

3. DDL-Coding-Chat：这个模板以代码注释（Coding）的形式呈现数据库模式，适用于那些更熟悉编程语言格式的模型。

4. SimpleDDL-MD-Complete：这个模板与SimpleDDL-MD-Chat类似，但要求模型完成SQL语句，而不仅仅是回答基于SELECT子句的问题。

5. DDL-HTML-Complete：这个模板在HTML格式中提供了完整的数据库模式信息，并要求模型生成完整的SQL查询。

6. DDL-Coding-Complete：这个模板以代码注释的形式提供数据库模式，并要求模型生成完整的SQL查询。

7. SimpleDDL-MD-Chat-Efficiency：这个模板要求模型直接生成最高效的SQL查询语句，以避免多次生成可能引入的错误。

这些提示模板的设计旨在测试LLMs在不同上下文和格式下的性能，以及它们在处理不同复杂度的数据库模式和用户问题时的能力。通过比较不同模板下模型的表现，研究者可以更好地理解模型的强项和弱点，并为未来的模型改进提供指导。

在论文中，提出了几个核心结论（Core Conclusion）：

1. 核心结论1：提示模板“SimpleDDL-MD-Chat”在Text-to-SQL任务中实现了最佳性能。

2. 核心结论2：随着用户查询中涉及的表格和列的数量增加，LLMs面临的Text-to-SQL挑战显著升级。

3. 核心结论3：详细的错误信息和相应的注释极大地增强了LLMs的能力，使它们能够有效地纠正错误。

4. 核心结论4：多轮自我调试有助于LLMs纠正错误，但存在性能边界，1-2轮调试是最佳选择。

5. 核心结论5：跨LLM SQL调试的性能不如直接重新生成。整合不同模型输出的多代理方法显示出巨大的潜力。

6. 核心结论6：在LLMs中实现有效的SQL优化面临挑战，上下文学习方法在提高SQL优化方面的效果有限。

7. 核心结论7：在SQL语句的语义描述方面，使用通用目的模型比特定于编码的模型是更好的选择。

8. 核心结论8：外键信息能够提升模式链接的性能。PreSQL在特定于编码的模型上表现最佳，而将Few Shot的结果整合到通用目的模型中可以进一步提高性能。

结论

在这项研究中，我们对Text-to-SQL流程中的各种子任务进行了系统的基准测试，包括Text-to-SQL、SQL调试、SQL优化、SQL转文本和模式链接。我们的全面评估涉及六种不同的LLMs，涵盖通用和特定于编码的模型。我们专注于确定每个任务的最佳提示模板，评估不同方法之间的性能变化，并识别每种LLM的独特能力和局限性。研究结果表明，LLMs之间的性能存在显著差异，强调了在文本到SQL任务中仔细选择模型和提示工程的重要性。我们的基准测试为流程提供了细致的视角，为研究社区提供了改进LLMs的语义理解和计算性能的策略。这一进步有助于开发更可靠的Text-to-SQL系统。

引用

• https://arxiv.org/pdf/2403.02951.pdf

关于我

【点击➕关注】：小贾探AI
本人投身于互联网软件行业近十余年，专注于LLM工程落地、大数据领域、图谱领域以及AI领域(LLMs-GPT-应用落地)，平时会不定期分享一些技术类和实践类的文章

欢迎关注，一起进步一起成长