CodeS ：构建开源文本到SQL语言模型

语言模型在将自然语言问题转换为SQL查询（文本到SQL）任务中表现出色。然而，大多数最先进（SOTA）的方法依赖于强大的但封闭源代码的大规模语言模型（LLM），如ChatGPT和GPT-4，这些模型可能存在架构不清晰、数据隐私风险以及昂贵的推理开销等问题。为了解决这些问题，我们引入了 CodeS ，一系列参数从1B到15B的预训练语言模型，专门设计用于文本到SQL任务。 CodeS 是一个完全开源的语言模型，在较小的参数规模下实现了优越的准确性。本文研究了构建 CodeS 的研究挑战。为了增强 CodeS 的SQL生成能力，我们采用了一种增量预训练方法，使用特定策划的SQL中心语料库。基于此，我们通过策略性提示构造和双向数据增强技术解决了模式链接和快速领域适应的挑战。我们在多个数据集上进行了全面评估，包括广泛使用的Spider基准测试、新发布的BIRD基准测试，以及诸如Spider-DK、Spider-Syn、Spider-Realistic和Dr.Spider等鲁棒性诊断基准测试，还包括为金融和学术应用创建的两个真实世界数据集。实验结果表明，我们的 CodeS 在几乎所有具有挑战性的文本到SQL基准测试中均取得了新的最先进准确性和鲁棒性。

1 引言

文本到SQL任务涉及将用户的自然语言（NL）问题转换为可以在数据库上执行的有效结构化查询语言（SQL）查询。图 [fig:text2sql_example] 展示了如何将一个针对数据库（例如银行金融）的自然语言问题转换为SQL查询。文本到SQL使那些可能不熟悉SQL或数据库结构的用户能够用自然语言与数据库交互，因此受到了数据库 (Fu et al. 2023; Gu, Fan, Tang, Cao, et al. 2023; Brunner 和 Stockinger 2021) 和自然语言处理社区 (Scholak, Schucher, 和 Bahdanau 2021; H. Li 等人 2023) 的广泛关注。

CodeS 与文本到SQL基准测试中的SOTA LLMs比较，包括Spider (Yu, Zhang, 等人 2018) 和BIRD (J. Li, Hui, Qu, 等人 2023) 。虽然 CodeS 比现有SOTA LLMs小10倍到100倍，但其实现了相当甚至更优的准确性。

传统的文本到SQL利用监督微调方法（SFT） (B. Wang 等人 2020; Scholak, Schucher, 和 Bahdanau 2021; H. Li 等人 2023) ，而最近随着大规模语言模型（LLMs）如GPT-4 (OpenAI 2023) 、GPT-3.5 (Ouyang 等人 2022) 和PaLM-2 (Anil 等人 2023) 的出现，范式开始转变。LLMs无需大量微调即可通过精心设计的提示来完成文本到SQL任务，这种方法被称为“提示学习”或“上下文学习” (P. Liu 等人 2023) 。

然而，大多数最先进（SOTA）的方法依赖于 封闭源代码 的LLMs，例如基于GPT-4的DIN-SQL (Pourreza 和 Rafiei 2023) 、基于PaLM-2的SQL-PaLM (Sun 等人 2023) 和基于GPT-3.5的C3 (Dong 等人 2023) 。尽管在文本到SQL性能方面取得了令人瞩目的成果，但这些方法可能存在以下限制。（ L1 ) 封闭源代码模型隐藏了其架构和训练/推理细节，阻碍了面向特定用途的持续开发。 (L2) 通过API调用这些模型存在数据隐私风险，因为数据必须发送给模型提供者。 (L3) 大多数封闭源代码模型具有大量参数（例如GPT-3.5有175B个参数），导致显著的推理开销，通常反映在调用API的货币成本上。

本文介绍了一个专为现实世界文本到SQL应用程序设计的 开源 语言模型 CodeS 。 CodeS 基于StarCoder (R. Li 等人 2023) 构建，这是一个专门为代码生成设计的前沿LLM，参数范围从1B到15B。用户可以根据计算资源选择适当大小的 CodeS 以构建文本到SQL应用程序。如图 1 所示，与现有的SOTA文本到SQL解决方案相比， CodeS 具有以下优势。

• 完全开源的LLM。 CodeS 基于StarCoder (R. Li 等人 2023) ，是完全开源且对用户公开的。
• 新的SOTA结果。 CodeS 在几乎所有的具有挑战性的文本到SQL基准测试中都达到了 新的SOTA性能 ，如Spider (Yu, Zhang, 等人 2018) 和BIRD (J. Li, Hui, Qu, 等人 2023) 。
• 小规模。 CodeS 比现有的SOTA LLMs（如ChatGPT和GPT-4）小10倍到100倍。
  我们概述了开发 CodeS 的主要技术挑战并解释了我们的解决方案。
  直接使用预训练语言模型，如LLaMA-2 (Touvron, Martin, 等人 2023) 和StarCoder (R. Li 等人 2023) , 在文本到SQL任务中面临挑战，主要是因为SQL相关的内容在其整个预训练语料库中只占很小一部分。随后的数据偏差可能会阻碍文本到SQL能力，因为在预训练阶段，语言模型旨在拟合整个语料库的分布，而不是仅仅SQL相关数据的分布。此外，与ChatGPT或GPT-4相比，小型语言模型具有有限的推理能力，导致在文本到SQL上的能力不足。为了解决这一挑战，我们提出了一种增量预训练方法，利用与文本到SQL任务相关的大量策划数据集。具体来说，我们收集了21.5GB的数据，包括SQL相关数据（11GB）、自然语言到代码数据（6GB）和自然语言相关数据（4.5GB），目的是增强SQL生成能力和自然语言理解。通过对StarCoder (R. Li 等人 2023) 进行增量预训练，我们创建了一系列 CodeS 模型，参数范围从1B到15B。
  模式链接对于文本到SQL转换至关重要，确保模型将输入问题映射到特定的数据库元素 (Lei 等人 2020) 。然而，当面对众多表、宽表（许多列）、模糊的表/列名和大型表时，问题出现了。为了解决这一挑战，我们使用模式过滤策略，对于众多表和宽表，仅根据用户的查询保留相关表和列，确保模式不超过模型的上下文长度。对于模糊名称（如缩写），我们将注释附加到这些名称上，帮助模型理解上下文。对于大型表，我们采用“粗略到精细”的方法：首先根据问题使用BM25索引筛选值，然后使用最长公共子串算法进一步细化。通过这些技术，我们为 CodeS 模型构建提示，增强模式链接并提高复杂数据库的文本到SQL性能。
  在实际应用中，我们希望 CodeS 模型能够在各种领域中自适应。然而，一个重大障碍是缺乏用于微调的具体（问题，SQL）对。为了解决这一挑战，我们采用了双向数据增强技术。首先，我们收集了一些真实的用户查询，手动标注对应的SQL查询，并利用GPT-3.5生成一组更广泛的（问题，SQL）对，确保用户导向的真实性。另一方面，我们利用来自文本到SQL基准测试的SQL模板和问题模板。通过插入新领域的数据库中的表、列和值，我们生成了一组多样化的（问题，SQL）对。这种模板化方法有助于 CodeS 适应新分布。本质上，我们精心设计的训练数据集结合了真实示例和结构化模板，确保了真实性和广泛应用。
  我们在两个具有挑战性的文本到SQL基准测试中评估了创建的 CodeS ：Spider (Yu, Zhang, 等人 2018) 和BIRD (J. Li, Hui, Qu, 等人 2023) 。虽然Spider长期以来一直是文本到SQL的标准，但BIRD提供了更复杂的问题、模糊的模式和大型脏数据。领先的文本到SQL方法DIN-SQL+GPT-4在其测试集上只能达到大约56%。除了常规的Spider基准测试外，我们还评估了 CodeS 在Spider的四个不同变体上：Spider-DK (Gan, Chen, 和 Purver 2021) 、Spider-Syn (Gan 等人 2021) 、Spider-Realistic (Deng 等人 2021a) 和Dr.Spider (Chang 等人 2023) 。这些涵盖了总共20个测试集，旨在探测模型的弹性，特别是在测试数据分布不同于训练数据分布的情况下。为了研究我们的双向数据增强方法在快速适应新领域中的效果，我们从学术和金融领域获取了数据库。鉴于这两个数据库的训练数据不足，我们增强了训练数据，微调了模型，并在相应的测试集上评估了其性能。
  我们的贡献总结如下：
• 我们介绍了 CodeS ，一系列参数从1B到15B的语言模型，专门设计用于SQL生成。这一创新基于增量预训练技术和精心策划的预训练语料库，包含SQL相关、自然语言相关和自然语言到代码数据。这种方法标志着文本到SQL应用中语言模型的重大进步。
• 我们通过综合数据库提示增强了 CodeS 的性能。此外，为了促进其在新领域的适应性，我们引入了一种双向数据增强方法，具有有限的标注开销。
• 通过在多个文本到SQL基准测试中的广泛评估，我们证明了（1） CodeS 在SQL生成能力上超过了其他著名的开源预训练语言模型；（2）当微调后， CodeS 在几乎所有具有挑战性的文本到SQL基准测试中都实现了新的SOTA准确性和鲁棒性。
• 我们已将代码、模型和数据在GitHub上开源 2 ，以促进社区内文本到SQL领域的进一步研究、采用和创新。
  2 相关工作
  在我们的调查中，我们涵盖了监督微调和基于提示的方法用于文本到SQL。此外，我们还探讨了现有的代码语言模型，因为文本到SQL可以视为代码生成的一个子任务。此外，我们还考察了为增强文本到SQL方法提出的各种模式链接和数据增强技术。
  在大语言模型（LLM）时代之前，文本到SQL的主要方法是对“编码器-解码器”神经网络模型进行微调。显著的努力集中在增强编码器表示能力，通过合并查询标记、表和列之间存在的图形结构信息，使用图形关系神经网络 (B. Wang 等人 2020; Cao 等人 2021) 。一些其他努力则集中在向解码器注入SQL语法，这限制了解码器的输出空间，确保生成语法正确的SQL查询 (Yin 和 Neubig 2017; Scholak, Schucher, 和 Bahdanau 2021; Fu 等人 2023) 。随着语言模型的发展，越来越多的趋势是将文本到SQL格式化为序列到序列任务 (Scholak, Schucher, 和 Bahdanau 2021; Shaw 等人 2021; J. Li, Hui, Cheng, 等人 2023; H. Li 等人 2023; Dou 等人 2022; Gu, Fan, Tang, Cao, 等人 2023) ，其中输入序列由自然语言问题和扁平化的数据库信息组成，包括表、列、外键等，输出序列是目标SQL查询。然后，对T5 (Raffel 等人 2020) 和BART (Lewis 等人 2020) 等序列到序列语言模型进行微调，使其能够从提供的输入生成SQL查询。受预训练技术成就的启发 (Devlin 等人 2019; Radford 等人 2018; Raffel 等人 2020) ，一系列研究 (Yu 等人 2021; Shi 等人 2021; Herzig 等人 2020; Yin 等人 2020; Deng 等人 2021b) 探索了使用广泛的数据库相关数据和各种预训练目标对语言模型进行预训练。然而，与我们的 CodeS 不同，他们的主要目标不是直接增强语言模型的SQL生成能力。相反，他们专注于增强编码器更好地表示问题和数据库模式的能力。然后，这些预训练编码器被集成到“编码器-解码器”模型中。
  大语言模型（LLM）如GPT-3 (Brown 等人 2020) 、Codex (M. Chen 等人 2021) 、PaLM (Chowdhery 等人 2022) 、LLaMA (Touvron, Lavril, 等人 2023) 和StarCoder (R. Li 等人 2023) 的出现，带来了NLP领域的革命性变化，在不需要微调任何参数的情况下，实现了多种需要推理能力的复杂任务的显著进展 (X. Chen 等人 2023; A. Liu 等人 2023; Pourreza 和 Rafiei 2023) 。对于文本到SQL，通过利用几个文本到SQL演示作为少量样本提示，SQL-PaLM (Sun 等人 2023) （基于PaLM-2）和Self-Debugging (X. Chen 等人 2023) （基于Codex）成功地在Spider上实现了最先进（SOTA）性能。此外，受到链式思维推理的启发 (Wei 等人 2022) ，设计有效的提示以激发LLMs的文本到SQL能力已成为热门研究课题。DIN-SQL (Pourreza 和 Rafiei 2023) （基于GPT-4）将文本到SQL任务分解为几个更简单的子任务，包括模式链接、查询分类和分解以及SQL生成。C3 (Dong 等人 2023) （基于ChatGPT）通过向ChatGPT提供适当的指令，使其成为零样本文本到SQL解析器。尽管这些基于提示的方法在文本到SQL基准测试中实现了SOTA性能，但正如我们在第 1 节中分析的那样，由于使用这些模型API的巨大成本和潜在的数据隐私问题，在实际应用中实现它们具有挑战性。
  近年来，人们越来越关注利用语言模型进行编码相关任务，如代码理解和生成 (M. Chen 等人 2021; Nijkamp, Pang, 等人 2023; Nijkamp, Hayashi, 等人 2023; R. Li 等人 2023) 。现有的代码语言模型通常在多种编程语言上进行预训练，如C、C++、Python、Java、C#和SQL。这种广谱训练数据可能导致小型模型在特定编程语言（如SQL）上的表现不佳，因为它们的表示能力有限。为了解决这个问题，我们开发了 CodeS ——一系列开源生成语言模型，特别优化了SQL中心数据的混合。
  模式链接在文本到SQL过程中起着关键作用，旨在识别自然语言问题中引用的数据库模式（如表和列）和数据库值 (Lei 等人 2020) 。主要有两种模式链接策略：字符串匹配 (B. Wang 等人 2020; Guo 等人 2019; Dou 等人 2022; Brunner 和 Stockinger 2021) 和基于神经网络的方法 (Bogin, Gardner, 和 Berant 2019; H. Li 等人 2023; Gu, Fan, Tang, Zhang, 等人 2023) 。字符串匹配方法简单有效，通过直接字符串匹配识别与问题相关的模式和值。然而，这种方法在某些场景中存在局限性，例如处理同义词。为了解决这些挑战，开发了基于神经网络的方法。这些方法旨在从语义层面评估模式和值的相关性。一旦获得模式链接结果，例如所有表和列的匹配度，许多技术 (Brunner 和 Stockinger 2021; Dou 等人 2022; B. Wang 等人 2020) 将这些结果作为额外输入纳入文本到SQL模型。与它们不同的是，RESDSQL (H. Li 等人 2023) 利用这些结果进行模式剪枝，仅保留与后续神经网络输入最相关的模式，从而减少输入到LLMs的长度。
  近年来，自动合成文本到SQL数据的兴趣日益浓厚。目标是为给定数据库自动生成相关的（问题，SQL）对。当前许多方法 (Hu 等人 2023; B. Wang 等人 2021; Wu 等人 2021; Yi Zhang 等人 2023) 采用SQL到问题合成流水线。该过程通常首先根据数据库自动生成SQL查询，然后使用序列到序列模型将这些查询翻译成自然语言问题。然而，这些方法的一个显著缺点是，合成的自然语言问题往往与实际用户的问题差异很大。为了解决这一差距，我们提出了一个新的双向数据增强策略。该方法不仅利用SQL到问题合成，还结合了问题到SQL合成，更准确地生成实际用户可能提出的各种问题。
  3 基础知识

语言模型主要基于Transformer架构 (Vaswani 等人 2017) ，擅长文本理解和生成任务。它们通常在一个初始预训练阶段在大量文本数据上使用无监督学习目标进行训练。两种主要的无监督学习范式是“语言建模”和“掩码语言建模”。在前者中，像GPT (Radford 等人 2018) 、PaLM (Chowdhery 等人 2022) 和 LLaMa (Touvron, Lavril, 等人 2023) 这样的模型根据给定的上下文预测下一个词。在掩码语言建模中，输入中的特定单词或片段被随机掩码，任务是根据未掩码的上下文重建掩码部分。使用这种方法的代表性预训练语言模型包括 BERT (Yin 等人 2020) 、RoBERTa (Y. Liu 等人 2019) 和 T5 (Raffel 等人 2020) 。
预训练语言模型具备广泛的语言知识，但特定任务通常需要独特的语言模式或领域专业知识。为了解决这个问题，监督微调（SFT）涉及在特定任务标记数据上进一步训练模型，利用其初始预训练以及从新数据集中获得的见解。与 SFT 相比，“上下文学习” (P. Liu 等人 2023; Wei 等人 2022) 使语言模型通过在输入中提供适当的提示来执行新任务，而无需进行 SFT。然而，上下文学习的效果高度依赖于提示的质量和语言模型本身。
4 概述
如图 [fig:overview] 所示，我们引入了三个组件来解决开发紧凑而强大的文本到SQL模型的挑战，并展示了 CodeS 的灵活使用。
为了提高现有语言模型的SQL生成和自然语言理解能力，我们首先收集了一个新的语料库，其中包括11GB的SQL相关数据、6GB的自然语言到代码数据和4.5GB的自然语言相关数据，来自多种来源。然后，基于StarCoder，我们使用SQL中心语料库进行增量预训练，获得了我们的预训练语言模型 CodeS , 参数规模有四种：1B、3B、7B和15B。
我们提出了一种全面的数据库提示构建方法，以生成高质量的数据库提示。该策略主要包含一个模式过滤器和一个值检索器。模式过滤器用于根据给定的问题消除不相关的表和列。值检索器则针对与问题对齐的潜在有用的数据库值进行定制提取。除了表和列名外，我们还纳入了各种元数据，包括数据类型、注释、代表性的列值以及主键和外键信息。这种全面的纳入旨在为文本到SQL模型提供更丰富的上下文。
我们提出了一种双向数据增强方法，以产生大量适用于新领域数据库的（问题，SQL）对。在问题到SQL方向上，我们从真实世界问题开始，标注其对应的SQL查询，并使用GPT-3.5扩展数据集。对于SQL到问题的方法，我们从现有的文本到SQL基准测试中提取模板，用新数据库的模式填充这些模板，并使用GPT-3.5优化问题。这种双向策略创建了一个带有最小标注的稳健训练集，简化了新领域的模型微调。
当有足够的训练数据时，我们可以直接微调 CodeS 的参数，使其紧密匹配标记数据的分布（图 [fig:overview] (d)）。相反，在训练数据有限的情况下，我们可以利用 CodeS 的上下文学习能力，仅通过提供少量文本到SQL演示来进行推理（图 [fig:overview] (e)）。引入了一个演示检索器，通过同时考虑问题相似性和问题模式相似性来提取有价值的演示。
在讨论我们提出的解决方案的复杂性时，区分离线和在线过程至关重要。具体来说，增量预训练（第 5 节）和新领域适应（第 7 节）是离线进行的，意味着它们只需执行一次。相反，数据库提示构建策略（第 6 节）是一个在线过程，因为在推理过程中必须响应每个用户的查询。提示构建的复杂性主要来源于两个组成部分：模式过滤器和值检索器。模式过滤器使用紧凑的神经网络进行模式分类，实现了快速推理速度。另一方面，值检索器的效率通过集成BM25索引显著提升，从而显著加速其在线处理速度。
5 增量预训练
5.1 预训练语料库
我们通过从三个关键维度收集数据集来增强文本到SQL模型的SQL生成和自然语言理解能力：SQL相关数据、自然语言相关数据和自然语言到代码数据。
为了进一步增强语言模型的SQL生成能力，我们使用了StarCoder预训练语料库中的SQL部分 (R. Li 等人 2023) 。
为了增强自然语言理解能力，我们从三个来源中抽取了4.5GB的高质量对话数据： (1) Alpaca-cleaned 3 旨在开发遵循指令的语言模型。该数据集使用自指令技术 (Y. Wang 等人 2023) , 并由OpenAI的text-davinci-003模型辅助构建。 (2) Unnatural-instructions (Honovich 等人 2023) 也是一个大型的指令跟随数据集，几乎不需要人工标注。Alpaca-cleaned和Unnatural-instructions数据集都可以视为单轮对话。 (3) UltraChat (Ding 等人 2023) 是一个多轮对话数据集，通过迭代调用两个不同的GPT-3.5 API生成。
为了弥合自然语言问题和SQL查询之间的差距，我们将四类自然语言到代码数据集纳入预训练语料库： (1) CoNaLa (Yin 等人 2018) 和 StaQC (Yao 等人 2018) 自动从Stack Overflow获取，涵盖了大量自然语言到Python和自然语言到SQL对。 (2) CodeAlpaca-20k 4 包含大量与代码相关的指令跟随数据，使用自指令方法构建 (Y. Wang 等人 2023) 。 (3) Jupyter-structured-clean-dedup是StarCoder预训练语料库的一个子集，包含大量的结构化Jupyter笔记本，其中包含代码和相应的自然语言解释。 (4) 与上述数据集不同，NL-SQL-458K是我们新创建的数据集，包含大量的自然语言到SQL对。具体来说，我们使用正则表达式从三个广泛使用的开源语料库中提取所有“SELECT”查询：The Pile (L. Gao 等人 2021) 、The Stack (Kocetkov 等人 2022) 和GitHub Code 5 。然后我们筛选出语法错误的查询，得到458K个SQL查询。为了为每个SQL查询生成相应的自然语言问题，我们使用GPT-3.5，采用八个配对（SQL，问题）演示的提示。
5.2 预训练细节

6 数据库提示构建
除了模型改进，构建有效的数据库提示对于文本到SQL任务至关重要。高质量的提示为语言模型提供了有价值的见解，使其能够更高效地生成准确的SQL查询。为了构建这些优越的数据库提示，我们采用了两个关键策略：模式过滤器和值检索器，同时还纳入了重要的数据库元数据。提示构建过程的伪代码见算法 [alg:db_prompt] 。
6.1 模式过滤器

6.2 值检索器

6.3 数据库元数据
在我们的数据库提示中，我们还纳入了对文本到SQL有价值的某些元数据：
列的数据类型决定了其验证规则和允许的操作。例如，数值类型如 INTEGER 和 REAL 支持算术运算，而字符串类型则不支持。如果某些数据存储为字符串类型，则在SQL查询中对其执行算术运算之前必须使用 CAST 函数。
现实世界数据库中的模式模糊性非常普遍。表 1 显示了BIRD数据集中的一些模糊列示例。模糊模式可能导致模型在其生成的SQL查询中选择错误的表或列，因为语言模型通常使用语义相似性进行模式链接。幸运的是，数据库通常为模糊模式提供信息注释。我们将这些注释纳入模式项分类器的输入和数据库提示中，以帮助LLM进行准确的模式链接。

除了列名，代表性的列值也很有帮助。例如，要生成谓词如 client.gender = 'F' , 必须告知语言模型“gender”列提供的两个值：'M'和'F'。同样，对于谓词如 SUBSTR (hiredate, 1, 4) = '2009' , 模型应知道“hiredate”列的具体格式为“YYYY-MM-DD”。显然，问题匹配的值并不总是能解决这些细微差别。为此，我们为每列提取代表性的值。受 (Chang 和 Fosler-Lussier 2023) 的启发，我们使用SQL查询 SELECT DISTINCT {COLUMN} FROM {TABLE} WHERE {COLUMN} IS NOT NULL LIMIT 2 从每列中捕获两个不同的非空代表值。通过提供这些有意义的值，语言模型能够更精确地生成上下文相关的SQL查询。
主键唯一标识表中的每一行，而外键则创建表之间的关联。纳入主键和外键信息可以指导模型推导出正确的连接路径，确保准确的 JOIN ON 子句生成。实际上，我们为每个主键列使用唯一的标识符，并在数据库提示中表示每个外键为 {TABLE1}.{COLUMN1} = {TABLE2}.{COLUMN2} 。

在图 2 中，我们展示了一个来自Spider基准测试的训练样本，包含成对的输入和输出序列。此数据库提示是使用我们提出的方法构建的。如图所示，基于用户的问题，从 reviewer.name 列中提取了相关的数据库值 Sarah Martinez 。然后，显示的主键和外键进一步指导语言模型生成 JOIN ON 子句。

Spider训练集中的文本到SQL样本，包含三元组 。数据库提示是通过我们提出的方法构建的。
7 新领域适应
在实际场景中，人们通常有自己的来自各种新领域的数据库，如金融、基因、生物学、学术等。然而，由于缺乏标记的训练数据，开发这些数据库上的文本到SQL模型具有挑战性。在本节中，我们提出了一种双向数据增强技术，以最少的标注成本自动生成大量真实的（问题，SQL）对。

用于双向数据增强的提示格式。DDL代表数据定义语言。

8 CodeS 的使用

8.1 监督微调

8.2 少量样本上下文学习
在无法进行微调的情况下，我们可以利用模型内置的文本到SQL功能，无需任何微调。少样本学习的有效性不仅基于模型的内在能力；还受到所用示例的影响 (Wei 等人 2022; J. Liu 等人 2022; Yiming Zhang, Feng, 和 Tan 2022) 。因此，我们使用高效的检索器来获取有价值的演示。

为了避免过度强调实体，我们专注于问题的核心结构，去除其实体。例如，对于询问1948年或1949年出生的歌手的问题，我们希望最合适的演示问题是“ 显示来自‘美国’或‘加拿大’的成员名称 ”，而不是局限于“歌手和歌曲”。

9 实验
9.1 实验设置
9.1.1 数据集。
我们在两个英文文本到SQL基准测试上进行主要实验：Spider (Yu, Zhang, 等人 2018) 和BIRD (J. Li, Hui, Qu, 等人 2023) 。我们还在四个更具挑战性的基准测试上评估了模型的鲁棒性：Spider-DK (Gan, Chen, 和 Purver 2021) 、Spider-Syn (Gan 等人 2021) span>、Spider-Realistic (Deng 等人 2021a) 和Dr.Spider (Chang 等人 2023) 。这些涵盖了总共20个测试集，并针对模型的鲁棒性进行了特别设计，尤其是在测试数据分布与训练数据分布不同的情况下。为了研究我们提出的双向数据增强方法在快速适应新领域的效果，我们从学术和金融领域获取了数据库。鉴于这两个数据库缺乏足够的训练数据以进行有效的微调，我们增强了训练数据，微调了模型，并在相应的测试集上评估了其性能。
我们的贡献总结如下：

• 我们引入了 CodeS , 一系列参数范围从1B到15B的语言模型，专门用于SQL生成。这一创新基于增量预训练技术和精心策划的预训练语料库，包括SQL相关、自然语言相关和自然语言到代码的数据。这种方法标志着文本到SQL应用中语言模型的重大进展。
• 我们通过综合数据库提示增强了 CodeS 的性能。此外，为了促进其在新领域的适应性，我们引入了一种双向数据增强方法，具有有限的标注开销。
• 通过在多个文本到SQL基准测试上的广泛评估，我们展示了（1） CodeS 在SQL生成能力上超过了其他显著的开源预训练语言模型；（2）当微调后， CodeS 在几乎所有具有挑战性的文本到SQL基准测试中都实现了新的最先进准确性和鲁棒性。
• 我们在GitHub上开源了代码、模型和数据 2 , 以促进社区内文本到SQL领域的进一步研究、采用和创新。

9.2 少量样本上下文学习的评估

表 [tab:few_shot] 显示了在Spider和BIRD基准测试上少量样本上下文学习的评估结果。我们将演示从1增加到3再到5。为了公平比较，所有模型都使用我们的一致输入提示进行少量样本上下文学习框架。将不同版本的StarCoder（即增量预训练前）与我们的 CodeS （即增量预训练后）进行比较，可以明显看出增量预训练大大提高了StarCoder的SQL生成能力。 因此， CodeS -15B成为开源预训练语言模型中SQL生成能力最强的模型。 此外，较小的模型表现出更显著的改进，这验证了我们最初的假设，即由于参数受限，较小的模型可能无法最优地训练于SQL相关任务。

9.3 监督微调的评估

表 3 展示了在Spider开发集上的EX和TS评估结果。值得注意的是，SFT CodeS -3B优于领先的GPT-4基线方法（如DIN-SQL和DAIL-SQL），展示了微调后小型模型作为文本到SQL解析器的潜力。此外，SFT CodeS -7B和SFT CodeS -15B在Spider开发集上达到了新的最先进性能。然而，SFT CodeS -7B相对于SFT CodeS -15B仅显示出边际优势，表明SFT CodeS -15B可能存在过度拟合Spider训练数据的情况，从而稍微影响其在开发集上的泛化能力。这种现象表明，较大的模型并不总是能保证更好的微调结果。

表 [tab:fine_tune_bird] 展示了在BIRD开发集和隐藏测试集上的EX和VES评估结果。鉴于BIRD的复杂性高于Spider，我们的方法在基线方法上取得了更显著的改进。不使用外部知识时，SFT CodeS -15B在测试集上的EX显著优于ChatGPT + COT，从28.95%提高到52.15%，增加了23.20%。当结合外部知识（w/ EK）时，SFT CodeS -7B和SFT CodeS -15B在测试集上分别比之前的最先进文本到SQL方法DIN-SQL + GPT-4提升了3.35%和4.47%。然而，尽管SFT CodeS -15B优于SFT CodeS -7B，但两者之间的差距很小，尤其是考虑到后者参数规模翻倍。这表明 CodeS -7B在计算效率和文本到SQL能力之间提供了最佳平衡。此外，VES指标超过EX表明我们的模型在生成执行高效的SQL查询方面优于人类专家。截至本文撰写时，SFT CodeS -15B和SFT CodeS -7B在BIRD官方排行榜上占据首位。

9.4 鲁棒性基准测试的评估

表 [tab:spider_robustness] 评估了SFT CodeS 在三个Spider变体上的鲁棒性：Spider-DK、Spider-Syn和Spider-Realistic。值得注意的是，SFT CodeS -7B表现出色，在Spider-Syn上提升了2.6%（从67.4%到70.0%），在Spider-Realistic上提升了4.0%（从73.2%到77.2%），在Spider-DK上提升了4.5%（从67.5%到72.0%），与最佳基线相比。即使是SFT CodeS -3B也在这三个数据集上超过了以前的最先进方法。考虑到SFT CodeS 是在Spider上训练但在其变体上测试，这些结果突显了该模型在具有挑战性的分布变化场景中的出色泛化能力。

为了更全面地评估SFT CodeS 的鲁棒性，我们进一步在Dr.Spider上测试了SFT CodeS 。结果见表 [tab:drspider] 。首先，在数据库（DB）扰动方面， CodeS 略逊于ChatGPT + ZeroNL2SQL，主要原因是 DBcontent-equivalence 扰动。ChatGPT + ZeroNL2SQL使用密集检索器以获得更好的语义准确性，但它资源密集，需要更多的磁盘空间和计算时间。为了保持效率和实际应用性，我们选择使用稀疏检索器。在自然语言问题扰动方面，SFT CodeS -7B和SFT CodeS -15B均优于之前的最佳方法ChatGPT + ZeroNL2SQL，得分分别为74.3%和75.2%，而ChatGPT + ZeroNL2SQL为73.2%。这表明我们的模型更好地掌握了问题语义，从而生成了更准确的SQL查询。对于SQL扰动，我们的模型略逊于RESDSQL-3B + NatSQL。后者的中间SQL表示法NatSQL比SQL更简单，有助于其表现。然而，其语法仅限于Spider，适应性较差。在全局平均性能方面，SFT CodeS -7B和SFT CodeS -15B略微超越了专门为文本到SQL鲁棒性设计的最佳方法ChatGPT + ZeroNL2SQL。总体而言，即使没有特定的鲁棒性设计，我们的模型经常在对抗专门为文本到SQL鲁棒性设计的方法中胜出。

9.5 消融研究

我们在Spider和BIRD上进行了广泛的消融研究，以评估每个关键组件的影响。结果如表 [tab:ablations] 所示。

仅使用问题相似度来检索演示（-w/o 模式相似度）会导致Spider上的性能下降，但在BIRD上的下降较少。这可能是由于Spider的问题多样性少于BIRD，使得根据模式更容易分组类似的文本到SQL样本。然后，当我们用纯随机选择替换演示检索策略（-w/o 演示检索器）时，大多数情况下性能都会下降。

我们探讨了模式过滤器和值检索器对性能的影响。没有模式过滤器的情况下，性能下降且生成速度变慢，因为输入序列较长。省略值检索器也会导致文本到SQL性能显著下降，特别是在BIRD基准测试上，突显了其在生成SQL查询谓词中的关键作用。

我们在元数据上进行了消融研究。如表 [tab:ablations] 所示，列数据类型对性能的影响较小，可能是由于模型可以从列名和注释中推断类型。移除注释显著影响了BIRD基准测试上的性能，因为其模式模糊。此外，代表性的数据库值和主键/外键对Spider和BIRD的性能至关重要。前者提供了值格式的见解，后者帮助生成准确的 JOIN ON 子句。

9.6 实际场景评估

我们在两个新领域数据集上评估了 CodeS ：Bank-Financials和Aminer-Simplified。主要挑战在于Bank-Financials数据库中的大量列和模糊模式名称，以及Aminer-Simplified中复杂的表连接关系。

对于实际部署，我们使用 CodeS -7B模型，因为它在性能和效率之间取得了平衡。我们在推理过程中使用基于BIRD训练的模式项分类器来过滤新数据库中的模式，因为它是基于问题-模式语义评分且跨领域适用。我们的基线来自提示式GPT-3.5。我们向GPT-3.5提供三个来自新数据库的随机文本到SQL样本。输入结构为：“[DDL] + [注释（可选）] + 3个[问题, SQL]实例 + [测试问题]”。鉴于EX指标的严格性，我们还采用人工评估（HE）进行SQL查询准确性评估。例如，考虑问题“ ’Optical geometries’的摘要是什么？ ”。人工标注的真实SQL查询是“ SELECT abstract FROM Paper WHERE title = ’Optical geometries’; ”。然而，如果生成的SQL查询额外选择了表中的“ title ”列，EX会判定其不正确。但人类专家会认为预测的SQL有效，因为它提供了用户请求的关键信息。

考虑到可用的标注数据和计算资源，我们提供了以下使用 CodeS 的路径：

(1) 对于没有标注的新数据库，我们可以直接使用在Spider和BIRD基准测试上微调的检查点进行推理。表 4 显示，这样的“SFT CodeS -7B使用Spider”和“SFT CodeS -7B使用BIRD w/ EK”具有一定的领域迁移能力。应该注意的是，EX和HE之间的大差距归因于基准测试与我们新数据集之间的不同标注习惯。

(2) 如果计算资源有限， CodeS 的少量样本学习可以快速适应新数据库而无需参数调整。在我们的测试中，仅使用三个上下文演示， CodeS -7B就能为新数据库生成SQL查询（参见表 4 中的“3-shot CodeS -7B”）。如果资源允许，我们可以使用第 7 节提出的双向数据增强策略为两个新数据库生成大量的训练对。表 4 中的“SFT CodeS -7B使用增强数据”表明，使用这些增强数据对 CodeS -7B进行微调可以显著提高准确性。然而，为每个数据库单独微调模型在实际应用中会有较大的开销。我们探索了将Spider、BIRD、Bank-Financials和Aminer-Simplified的训练数据合并以训练统一的文本到SQL模型的方法。结果显示，这种方法不仅防止了性能下降，还提高了性能，特别是在Aminer-Simplified数据集上，如表 4 中的“SFT CodeS -7B使用合并数据”所示。

9.7 延迟和部署要求

小型模型的一个关键优势是其更快的推理速度。例如，之前的最先进提示式方法DIN-SQL+GPT-4在Spider数据集上的平均推理时间为每样本约60秒。相比之下，我们的SFT CodeS 表现出显著的效率提升。1B、3B、7B和15B变体的推理时间分别为0.6秒、0.9秒、1.1秒和1.5秒。这突显了我们模型的优越速度。此外， CodeS 也适合实际部署。更具体地说，当以float16精度运行时，SFT CodeS 变体（1B、3B、7B、15B）所需的GPU内存容量分别为10GB、13GB、20GB和35GB。因此，我们可以在本地机器上部署 CodeS , 避免使用昂贵的GPT-4 API。

10 结论

在这项研究中，我们在开源文本到SQL模型领域取得了重大进展。 CodeS 的引入使开发人员能够访问一系列专门预训练的语言模型，用于开发他们的文本到SQL应用程序。我们还将收集的SQL中心语料库开源给研究社区，这可能为使用增量预训练的SQL生成开辟新的创新途径。此外，我们提出了一种全面的数据库提示构建策略和一种新颖的双向数据增强方法，确保模型保持灵活性并能无缝适应各种领域。最后，我们在多个文本到SQL基准测试上进行了广泛评估。我们的发现表明， CodeS 是新的最先进预训练语言模型，在SQL生成能力方面表现卓越；我们的SFT CodeS 模型在广泛的文本到SQL基准测试中实现了新的最先进准确性和鲁棒性。我们希望我们的努力，结合代码、模型和数据的开源，能够促进文本到SQL领域的进一步探索、采用和创新。除此之外，我们乐观地认为这项工作可以为其他专业领域的语言模型部署提供宝贵的视角。

1. 值得注意的是，关于ChatGPT和GPT-4的具体规模细节尚未公开。因此，我们遵循一般假设，即ChatGPT大约相当于GPT-3-175B (Kung 等人 2023) ，而GPT-4的规模显著超过ChatGPT (Nori 等人 2023; OpenAI 2023) 。 ↩︎
2. https://github.com/RUCKBReasoning/codes ↩︎
3. https://huggingface.co/datasets/yahma/alpaca-cleaned ↩︎
4. https://huggingface.co/datasets/sahil2801/CodeAlpaca-20k ↩︎
5. https://huggingface.co/datasets/codeparrot/github-code ↩︎
6. https://github.com/castorini/pyserini ↩︎
7. Spider基准测试使用CodaLab Worksheets作为提交平台，可以通过 https://worksheets.codalab.org/home 访问。该平台提供了配备12GB内存的GPU。然而，我们最好的模型SFT CodeS -15B需要至少35GB的GPU内存来进行推理。 ↩︎

原论文：https://arxiv.org/pdf/2402.1634