E-SQL:通过文本到SQL问题丰富化实现直接模式链接

论文：https://arxiv.org/abs/2409.16751

代码：https://anonymous.4open.science/r/E-SQL_Direct_Schema_Linking

摘要

将自然语言查询转换为结构化查询语言(文本到SQL或自然语言查询到SQL)是自然语言处理和数据库领域广泛研究的一项关键任务，旨在为数据库提供自然语言接口(NLIDB)，并降低非专业人员的使用门槛。尽管最近通过使用大语言模型(LLM)取得了一些进展，但仍然存在重大挑战。这些挑战包括处理复杂的数据库模式、解决用户查询中的歧义，以及生成能够准确反映用户意图的复杂结构SQL查询。在这项工作中，我们引入了E - SQL，这是一种专门设计的新型流程，旨在通过直接的模式链接和候选谓词增强来应对这些挑战。E - SQL通过将相关的数据库项(即表、列和值)和条件直接纳入问题和SQL构建计划，来增强自然语言查询，从而弥合查询与数据库结构之间的差距。该流程利用候选谓词增强来减少生成的SQL中错误或不完整的谓词。在BIRD基准测试上的全面评估表明，E - SQL取得了具有竞争力的性能，特别是在复杂查询方面表现出色，在测试集上的执行准确率达到 $66.29\%$ 。我们的实验进一步观察到，当使用最先进的专有大语言模型时，将模式过滤纳入翻译流程对性能没有积极影响。此外，我们对小型大语言模型的实验强调了丰富问题对其性能的重要性和积极影响。在不进行微调的情况下，使用DeepSeek Coder 7B Instruct 1.5v结合丰富问题进行单提示SQL生成，在BIRD开发集上的执行准确率达到56.45%。

1 引言

将自然语言查询转换为SQL(文本转SQL)的任务因其有降低非专业人员技术门槛、提升查询或推荐系统性能的潜力而备受关注。该任务处于自然语言处理(NLP)和数据库管理的交叉领域，旨在让用户通过简单的自然语言查询与数据库进行交互，而无需具备丰富的SQL语法或数据库模式结构知识。尽管在利用大语言模型(LLM)进行文本转SQL方面取得了进展，但表现最佳的模型与人类水平的准确率之间仍存在约 $20\%$ 的显著性能差距，这凸显出即使是最复杂的流程目前仍不适用于作为数据库的自然语言接口进行实际部署 [28]。

在大语言模型(LLMs) $\left[1-4,7,29,33,34,41,42\right]$ 出现之前，大量研究 $\left[6,12,16,23,30,43,44,46,54\right]$ 专注于构建基于编码器 - 解码器的神经网络架构，这些架构利用了循环神经网络(RNN)[5, 17]和各种预训练语言模型 $\left[8,9,38,51\right]$ 。这些早期方法奠定了基础，但在处理复杂查询或模式时往往存在局限性。

大语言模型(LLMs)在文本转SQL(Text-to-SQL)任务中展现出了巨大的潜力，在各种基准测试中都取得了令人瞩目的成果。为了进一步提升大语言模型的推理能力，人们引入了多种上下文学习(in-context learning，ICL)技术，包括思维链(chain-of-thought，CoT)提示 [48]、问题分解 [20, 55]、自一致性 [47] 以及其他技术 [18, 32, 49, 53]。尽管其中许多策略已成功应用于文本转SQL翻译流程 $\left[13,26,35,37,40\right]$ ，但从问题细化的角度专门提升大语言模型的推理能力仍相对较少被探索。

除了上下文学习之外，还可以通过微调或从头开始训练来提升大语言模型的性能。然而，这些技术需要大量资源，需要大量的计算资源和大量特定任务的标注数据。虽然专有模型较少针对文本转SQL进行微调 [31]，但通过对众多开源模型进行微调已经取得了不错的成果 [13, 26, 35, 36, 40, 45]。

图1展示了先前研究中使用的通用流程和模块。文本到SQL(Text-to-SQL)任务的一个关键组成部分是模式链接(schema linking)，即把自然语言查询的语义与数据库模式关联起来。尽管已经提出了各种方法来改进模式链接，但它仍然是一个核心挑战。模式过滤(schema filtering)是一种常用于排除无关数据库项的技术，已被广泛用于减少下游任务的噪声。虽然基于神经网络[25, 26]和基于大语言模型(LLM)[10, 22, 35, 37, 40]的模式过滤技术都已得到探索，但我们的发现与马马里(Maamari)等人[31]的一致，表明在使用最新一代大语言模型时，模式过滤可能会导致性能下降。此外，多项研究[13, 31, 35 - 37, 40, 45]表明，在响应查询时提供与数据库相关的信息可显著提高性能。

在这项工作中，我们介绍了E - SQL:通过文本到SQL的问题丰富化实现直接模式链接 ${}^1$ ，这是一种新颖的流程，旨在通过问题丰富化和候选谓词扩充直接应对模式链接挑战。我们从问题丰富化的角度探索了大语言模型(LLM)推理和模式链接的改进。E - SQL通过将相关数据库元素(如表、列和值)直接纳入查询以及相关的SQL构建计划，增强了自然语言查询表示。这种方法通过生成候选谓词得到进一步强化，从而降低了SQL谓词出现错误或不完整的可能性。这种方法与传统的模式过滤技术不同，传统技术通常用于简化呈现给模型的模式。E - SQL流程由四个主要模块组成:候选SQL生成(CSG)、候选谓词生成(CPG)、问题丰富化(QE)和SQL优化(SR)。

在候选SQL生成(Candidate SQL Generation，CSG)模块中，会生成一个初始的SQL查询。然后对该查询进行解析，从其谓词中提取值和操作。候选谓词生成(Candidate Predicate Generation，CPG)模块使用这些提取的元素从数据库中查找相似的值，并构建候选谓词。问题丰富化(Question Enrichment，QE)模块利用候选谓词，指示大语言模型(LLM)将相关的数据库项和可能的谓词纳入自然语言问题中，同时将SQL构建步骤制定为其推理过程。然后利用这些步骤生成一个完全丰富化的查询。同时，执行候选SQL查询以识别潜在的执行错误。最后，在SQL优化(SQL Refinement，SR)模块中，利用丰富化后的问题、候选谓词以及任何已识别的执行错误，对候选SQL查询进行优化或生成一个新的SQL查询。

我们还在我们的流程中探索了模式过滤(schema filtering)这一在以往研究中广泛采用的技术的影响。我们在流程中加入了一个额外的模式过滤模块，在该模块中，大语言模型(LLM)被要求只选择与查询相关的数据库表和列，同时排除其他的表和列。随后，应用过滤模式修正技术来解决过滤后的模式与原始数据库模式之间的任何不一致问题。我们的实验表明，当与最先进的专有大语言模型结合使用时，模式过滤可能会对性能产生负面影响。相反，通过问题丰富化和候选谓词扩充进行直接模式链接，为准确生成 SQL 提供了更可靠的策略，特别是在复杂情况下。

通过消融研究，我们展示了流程中每个模块在文本到 SQL 任务中的有效性。特别是，我们的问题丰富化模块显著提高了对具有挑战性问题的处理性能，准确率提高了近 $5\%$ 。

我们在Spider [52]和BIRD [28]基准测试(文本到SQL任务中著名的标准数据集)上对E - SQL进行了评估，证明了它在处理复杂查询时的能力，同时与最先进的方法相比保持了有竞争力的性能。我们的研究结果表明，丰富问题、SQL生成步骤和候选谓词的整合能够实现更准确的SQL生成，特别是对于涉及多个条件和连接的复杂查询。因此，我们的方法通过在文本到SQL翻译的背景下利用问题丰富化和候选谓词增强，为模式链接和提示增强建立了一种新的范式。

我们这项工作的主要贡献可总结如下:

• 我们提出了一种通过问题丰富化实现模式链接的新范式，该范式通过将相关数据库项和潜在条件纳入自然语言问题来实现直接的模式链接。完全丰富化的查询通过提供明确的逻辑步骤，进一步指导大语言模型(LLM)进行SQL构建。

• 据我们所知，在文本到SQL翻译任务中，我们首次通过使用一个组成数据库集成问题的问题丰富化模块，同时提升了大语言模型的推理能力和模式链接性能。

• 我们提出了一种利用LIKE运算符的候选谓词生成技术，并通过用候选谓词增强提示来证明了其积极影响。

• 我们的实验还证实了，当将传统模式过滤技术集成到像我们这样利用最先进的专有大语言模型(LLMs)的文本到SQL翻译管道中时，这些技术可能存在的缺点。

• 我们证明了包含逻辑SQL构建步骤的数据库集成问题，对小型大语言模型(LLMs)在文本到SQL翻译任务中的性能具有重要意义和积极影响，且无需进行微调即可实现。

2 相关工作

在大语言模型(LLMs)出现之前，文本到SQL翻译中的监督微调方法主要集中在采用循环神经网络(RNNs)[16, 43, 54]、预训练语言模型(PLMs)[12, 23, 30]、卷积神经网络(CNNs)[6]和图神经网络(GNNs)[46]的编码器 - 解码器架构上。这些方法将自然语言问题与数据库模式一起进行编码，以建立模式链接，并通过序列生成 $\left[30,54\right]$ 、基于语法的方法 $[6$ 、[16, 46]或基于草图的插槽填充策略生成SQL查询。这些方法为文本到SQL任务提供了基础理解，为更先进的解决方案铺平了道路。

专有和开源大语言模型(LLMs)的出现[3, $4,15,19,34,41]$ 标志着该领域发生了重大转变。由于它们具有先进的推理和理解能力，研究界越来越关注利用这些模型的能力来完成文本到SQL任务。

2.1 大语言模型推理

高级推理技术对于提高大语言模型(LLM)在复杂任务上的性能至关重要。虽然提示设计很重要，但增强内在推理的方法，如分解问题或优化表述，已经使大语言模型的能力取得了显著进展。

思维链(Chain-of-Thought，CoT)方法 [48] 通过引导大语言模型生成中间推理步骤，显著提高了多步推理任务的性能。小岛(Kojima)等人 [21] 探索了一种简单而有效的提示方式，即“让我们逐步思考”，以发掘语言模型在零样本模式下的推理能力。将复杂问题分解为更简单的子问题已得到研究 $\left[11,20,55\right]$ 。像自我一致性(Self Consistency) [47] 这样的技术采用多数投票来选择一致的答案，而自我改进(Self-Improve) [18] 和自我优化(Self-Refine) [32] 则分别通过自我生成的数据和反馈迭代优化回复。除了答案生成之外，席(Xi)等人 [49] 展示了通过自我润色(Self-Polish)技术优化问题上下文和问题能带来显著的提升。

图1:文本到SQL翻译任务的通用流程概述，突出了关键模块:模式过滤(Schema Filtering)、问题分解(Question Decomposition)、实体检索(Entity Retrieval)和查询生成(Query Generation)。模块化设计允许根据首选的流程配置灵活使用这些组件。

图2:所提出的E - SQL流程概述，包含候选谓词生成、问题丰富化、SQL细化模块，且不包含模式过滤模块。

据我们所知，在文本到SQL翻译任务的相关文献中，尚未对高质量用户查询的细化和生成进行探索，尤其是带有有助于构建正确SQL查询的嵌入式推理的查询。我们的工作通过提出一种方法来填补这一空白，该方法能生成清晰的、感知模式的查询，并融入推理元素，明确指导准确SQL查询的生成，克服模式链接挑战。

2.2 模式链接与过滤

将自然语言查询转换为SQL需要清晰理解查询中使用的语言和数据库的结构。模式链接(Schema Linking)有助于这一过程，它弥合了查询与数据库模式之间的差距，确保查询中的单词或短语能准确匹配到相关的数据库元素，如表、列或值。

以往的研究表明，去除无关的数据库元素可以减少基于模式的幻觉出现的可能性，从而改善文本到SQL(Text-to-SQL)任务中的模式链接并提升模型性能。这一过程被称为模式过滤(schema filtering)或模式剪枝(schema pruning)，已得到广泛研究。RESDSQL [25]和CodeS [26]通过根据模式项与自然语言查询的相关性对其进行分类，然后在排序后根据分类概率进行过滤来解决这一问题。而DIN - SQL [35]采用单步操作，仅选择与问题相关的数据库表和列，C3 [10]、CHESS [40]和MCS - SQL [22]则先过滤数据库表(表链接)，然后从之前过滤后的表中选择最合适的列(列链接)，从而实现更好的模式过滤。对于模式链接和过滤，TA - SQL [37]的TASL模块从大语言模型生成的虚拟SQL查询中生成一个模式实体(表和列)列表，然后用其创建符号表示。我们的方法也利用了最初生成的候选SQL查询；然而，我们并非将其用于模式过滤，而是从条件中提取可能的数据库值以生成潜在谓词，这些谓词随后作为数据增强的一部分用于下游任务，具体内容将在3.3节中解释。高等人[13]探讨了不同模式表示的影响，并证明将数据库模式表示为代码而非自然语言表示，有助于更好地理解问题到SQL的映射，从而改善模式链接。虽然以往的研究已经证明了模式过滤对模式链接有积极影响，但马马里等人[31]认为，显式的模式过滤对于能力较弱的大语言模型(LLMs)仍然有用，但对于GPT - 4o等最新、更先进的大语言模型则变得不必要。我们在E - SQL管道中实现的单步模式过滤实验证实了这一发现，表明在利用GPT - 4o和GPT - 4o - mini [33]等先进大语言模型的管道中应用显式模式过滤可能是多余的，并且可能导致性能下降。

2.3 数据增强

数据增强的一个重要方面是通过提示向大语言模型(LLM)提供相关内容。用与查询相关的项目增强提示对于提高文本到SQL的翻译性能至关重要。根据子任务的不同，提示通常会用数据库项目的解释、基于相似度选择的数据库值、特定子任务的示例以及以代码或自然语言表示的数据库模式(经过筛选或未筛选)，以及分解后的查询和候选SQL查询来丰富[13, 31, 35 - 37, 40, 45]。在我们的工作中，我们在提示中纳入了数据库项目的解释和与查询相似的数据库值。此外，我们还为候选查询包含执行错误，以便在查询优化过程中提供有价值的反馈。与以往的工作不同，我们提出了一种新方法，通过引入具有精确数据库值的候选条件来进一步减少谓词错误并提高大语言模型的性能，有效地弥合自然语言查询和数据库之间的差距。

2.4 SQL查询生成与修正

文本到SQL(Text-to-SQL)任务的最后一步是生成一个能准确回答用户自然语言问题的SQL查询语句。虽然有些方法，如C3 [10]采用零样本生成，但少样本提示技术更常用于提升性能。像C3、DAIL - SQL、CHESS和MSC - SQL $\left[10,13,22,31,40\right]$ 等模型采用了诸如自一致性[47]和多选选择等方法。然而，由于单个查询需要大量的生成步骤，这些技术会导致较高的计算成本。为解决生成的SQL中关键词缺失或冗余的问题，普尔雷扎(Pourreza)和拉菲伊(Rafiei)[35]引入了一个自校正模块。王(Wang)等人[45]借助MAC - SQL提出了一个精炼器代理，用于评估生成的SQL的语法正确性和可执行性，确保生成非空结果。在我们的工作中，我们提出了一个类似于MAC - SQL [45]的SQL精炼模块，在丰富问题并使用候选谓词增强提示后对SQL进行精炼。

3 方法

我们的工作重点是通过关键词映射用数据库项丰富问题，并通过SQL生成步骤和推理对其进行扩展，从而弥合数据库模式与用户自然语言查询之间的差距。我们的方法可以被描述为通过用相关数据库元素丰富查询来实现直接的模式链接。为了进一步减少谓词中表、列使用错误或值缺失等错误，我们在提取所有可能的谓词后，将它们添加到提示中。

如图2所示，我们提出的方法由四个主要模块组成:候选SQL生成(CSG)、候选谓词生成(CPG)、问题丰富(QE)和SQL优化(SR)。此外，鉴于以往工作中数据库模式过滤的结果参差不齐，我们还加入了一个模式过滤和过滤后模式修正模块(SF)。然而，我们对该流程的实验表明，当将模式过滤集成到使用最先进大语言模型(LLM)的文本到SQL流程中时，会导致性能下降，这与马马里(Maamari)等人 [31] 的研究结果一致。以下各小节将对每个模块进行详细解释。

3.1 数据库描述与值选择

在现实世界的数据库中，描述文件是一种宝贵的资源，它能提供有关数据库条目的详细信息。大规模数据库通常包含大量描述文件，其内容可能十分丰富。对于大语言模型(LLMs)而言，另一个关键信息是数据库中的实际数据值。然而，由于大语言模型的上下文窗口限制以及相关计算成本，在提示信息中加入所有可用的描述和数据库值是不切实际的。另一种有效的提示增强方法是仔细选择相关的数据库信息，同时过滤掉与查询无关的内容，从而减少噪声并提高模型性能。

李等人[27]、肖拉克等人[39]以及李等人[25]利用最长公共子串(Longest Common Substring，LCS)算法来识别与查询相关的数据库值。然而，LCS算法的时间复杂度可能会显著减慢检索过程。为解决这一问题，李等人[26]提出了一个“由粗到细”的匹配框架，该框架首先使用BM25从整个数据库中提取数百个潜在相关的值，然后应用LCS算法来检索与查询最相关的值。塔莱伊等人[40]采用了不同的方法，他们首先借助大语言模型(LLM)从自然语言查询中提取关键词，然后使用基于局部敏感哈希(Locality Sensitive Hashing，LSH)的分层检索策略从数据库中检索相似的值。DIN - SQL [35]采取了更有针对性的方法，类似于CHESS [40]的关键词提取阶段，它借助大语言模型直接从查询中提取可能的单元格值。在我们的工作中，我们不仅使用BM25排序算法来检索最相关的数据库值，还使用它来识别最相关的数据库描述。我们根据BM25排序算法，为每列增加10个最相关的数据库值和20个最相关的数据库描述语句作为提示。此外，在为每列提供数据库值时，我们确保任何包含“NULL”值的列也将“NULL”作为所选值的一部分。这确保了大语言模型能够意识到潜在的空条目，从而在需要时能够纳入诸如“IS NOT NULL”之类的条件。

3.2 候选SQL生成模块(Candidate SQL Generation Module，CSG)

当获得适当的信息时，大语言模型(LLMs)可以有效地在数据库模式和自然语言查询之间建立紧密联系，从而生成大部分准确的SQL查询。尽管这些SQL查询偶尔可能包含错误，例如表或列使用不当，或者谓词中缺少值，但它们通常不会包含完全不相关的数据库项。为了利用这一能力，我们在后续步骤中从最初生成的SQL查询中提取潜在有用的信息，以提高数据质量，进而提升模型性能。屈(Qu)等人 [37] 生成并使用虚拟SQL来提取模式实体。关于我们的方法中如何使用虚拟SQL的更多细节将在3.3节中提供。

我们的候选SQL生成模块纳入了三个随机选择的样本，每个样本都来自与当前查询关联数据库不同的数据库，这些样本来自少样本数据中的不同难度级别。这些样本按顺序排列，先呈现较简单的问题 - SQL对，然后是更具挑战性的对。在按照DAIL - SQL [13]的建议提供数据库模式代码表示后，根据上一小节3.1的描述，提示信息还会进一步增加所选数据库描述以及每列的相关数据库值。为了增强大语言模型(LLM)的推理能力，我们使用“让我们逐步思考”这一短语，并按照小岛(Kojima)等人[21]和魏(Wei)等人[48]的建议，指示大语言模型生成推理步骤。

3.3 候选谓词生成(CPG)

确定在SQL查询中使用的正确谓词是文本到SQL翻译中的关键步骤。成功建立数据库项与查询之间的关系至关重要。然而，即使是最先进的大语言模型有时也难以生成准确的谓词。对于大语言模型生成的SQL查询中的一个谓词，假设使用了正确的操作，有六种可能的情况:

(1) 该谓词在语法、模式和语义上都是正确的。换句话说，执行“SELECT * FROM <表> WHERE <表>.<列> <操作符> <值>”查询将产生结果，不会出现任何执行错误或返回空集。

(2) 表和列是正确的，但谓词中使用的值不完整，或包含多余的字符或单词。如图3所示，生成的谓词使用“弗雷斯诺(Fresno)”而不是“弗雷斯诺县教育局(Fresno County Office of Education)”作为值，尽管没有执行错误，但导致了错误的SQL语句。

(3) 表和值是正确的，但谓词中选择了错误的列。换句话说，所选表中的另一列包含该值。图4显示了在所选表和值正确的情况下使用了错误的列。

(4) 选择了正确的表，但列和值都不正确，或包含缺失或多余的部分。如图5所示，谓词中生成了“T1. ‘县名’ = ‘弗雷斯诺(Fresno)’”，而应该是“T1.‘学区名’ = ‘弗雷斯诺县教育局(Fresno County Office of Education)’”。

(5) 值生成正确，但选择了错误的表和列，这意味着生成的值应该被使用，但它属于另一个表及其某一列。

(6) 表、列和值均错误，且与问题完全无关。

为解决第(2)项至第(5)项中概述的可能错误，我们提出了候选谓词生成(Candidate Predicate Generation，CPG)模块，如图2所示，该模块通过增强提示来改进下游任务，使大语言模型(LLM)能够意识到可能的谓词并生成正确的谓词。在CPG模块中，我们首先解析候选SQL查询，以提取谓词中使用的值和操作。然后，我们使用LIKE运算符，通过执行以下查询从数据库中检索所有可能的值:

在这里， 表示从候选 SQL 查询的值中提取的一个标记。此过程会生成一个可能的谓词列表，格式为 “<表名>.<列名> <操作符> <值>”，该列表将用于下游任务。

图 3:第 3.3 节案例 (2) 中所解释的谓词中不完整值生成的示例。

3.4 模式过滤与过滤后模式校正模块 (SF)

在先前的工作中，模式过滤(即剔除与查询无关的数据库表和列)已被证明可以通过降低在 SQL 查询中生成无关模式项的可能性来提高模型性能。一种方法是指导

图4:第3.3节案例(3)中解释的谓词中表和值正确但列错误的示例。

图5:第3.3节案例(4)中解释的谓词中表正确但列和值选择错误的示例。

大语言模型(LLM)首先选择相关的数据库表，然后从这些表中选择最相关的列 $\left[10,22,40\right]$ 。另一种方法是在单个步骤中同时考虑表和列来过滤数据库模式[35]。此外，一些方法利用虚拟SQL查询来提取相关的数据库实体以进行模式过滤[37]。李(Li)等人提出了CODES(代码选择器，Code Selector)[26]，并按照RESDSQL(基于关系感知的语义分解的SQL生成，Relation-Aware Semantic Decomposition for SQL Generation)[25]训练一个模式分类器来预测相关性得分。在我们的工作中，我们采用单步模式过滤方法，仅提取相关的表及其关联的列。

然而，我们观察到过滤后的模式可能并不总是与原始模式兼容，根据原始数据库模式，所选列可能属于不同的表。当出现此类问题时，它们会对SQL生成过程产生负面影响，并导致性能下降。为解决这一问题，我们提出了一种过滤后模式校正策略，该策略会检查过滤后的模式与原始模式之间的不匹配情况，并随后进行相应的校正。虽然先前的研究已经证明了模式过滤对模式链接和整体文本到SQL翻译性能的益处，但我们的实验表明，当与最新的专有大语言模型(LLM)一起使用时，将模式过滤纳入我们的流程会导致性能下降，这一发现与马马里(Maamari)等人的研究成果[31]一致。详细的实验结果将在4.3节中提供。因此，我们选择不在我们的E - SQL流程中包含模式过滤模块。

3.5 问题丰富模块(QE)

为了增强模式链接，各种大语言模型(LLM)推理改进技术，如思维链(Chain-of-Thought，CoT)[48]、问题分解[11, 20, 55]和自一致性[47]已应用于文本到SQL(Text-to-SQL)翻译任务。几乎所有利用大语言模型的先前工作都采用了思维链推理。Pourreza等人[35]和Wang等人[45]已将问题分解应用于文本到SQL任务。自一致性和多选选择技术已被C3[10]、DAIL - SQL[13]、CHESS[40]和MSC - SQL[22]等模型采用。另一个关键方法是模式过滤，它会消除不相关的数据库项，并使用与查询相关的数据库值增强提示，从而缩小查询与数据库模式之间的差距 $\left[10,22,37,40\right]$ 。以往的范式在很大程度上忽视了通过问题重构来增强大语言模型的推理和模式链接能力。针对这一方面，我们提出了一种新颖的问题丰富策略，如图6所示，该策略通过用相关数据库项扩展问题并纳入逻辑步骤来直接将自然语言问题与数据库模式相链接，以生成准确的SQL查询。

在问题丰富模块(QE)中，我们指示大语言模型(LLM)通过纳入相关数据库项(表、列和值)及条件来完善原始问题。这一过程使问题更易理解、更连贯，且与数据库模式更匹配。此外，在问题 - 数据库集成过程中作为推理过程一部分生成的 SQL 构建计划会附加到丰富后的问题中。该计划和丰富后的问题共同构成了完全丰富问题，它明确包含了必要的 SQL 组件和逻辑步骤，指导大语言模型生成准确的 SQL 查询。结合原始问题、丰富后的问题和丰富推理的完全丰富问题的创建过程如图 6b 所示。我们采用少样本策略来生成完善后的问题，使用从开发集中随机抽样的问题 - SQL 对，这些对已被手动标注并公开。我们为每个难度级别(简单、中等和具有挑战性)标注了 12 个问题。由于手动标注的问题取自开发集，我们确保在问题丰富提示中提供的每个难度级别随机选择的 3 个示例与当前查询关联的数据库不同。这种方法可防止与所考虑查询的数据库直接相关的丰富问题示例被包含在提示中。在少样本示例中，我们同时包含丰富后的问题和丰富推理，这些是考虑到思维链技术手动准备的，以充分利用模型的推理能力并明确列出 SQL 逻辑步骤。问题丰富提示还包括数据库模式、相关数据库描述和值，以及由候选谓词生成(CPG)模块生成的候选谓词。完全丰富问题是在单个提示中生成的，无需迭代完善。迭代丰富留作未来工作的潜在方向。

(b) 原始问题、扩充推理和扩充后问题的拼接。图6:(a) 问题扩充示例；(b) 完全扩充后问题的构建。

3.6 谓词与错误感知的SQL优化模块(SR)

由于生成的SQL查询可能存在一些小错误，一种常见的解决方法是使用修正模块，如图1所示。普尔雷扎(Pourreza)等人[35]提出了一种新颖的自我修正模块，该模块严重依赖大语言模型(LLMs)来识别和纠正潜在错误，而无需执行SQL查询。另一种由C3 [10]、DAIL - SQL [13]、CHESS [40]和MCS - SQL [22]采用的方法是为一个自然语言问题生成多个SQL查询，并选择最一致的一个作为最终预测的SQL，而不是仅仅依赖贪婪生成的SQL。王(Wang)等人[45]提出的精炼器代理会验证生成的SQL的语法正确性和可执行性，如果SQL未通过这些检查，则触发修正操作。精炼器代理会迭代执行这些操作，直到结果正确或达到最大迭代次数。虽然这种设计提高了性能，但也增加了生成最终SQL查询所需的成本和时间。在我们的工作中，如图2所示，我们执行候选SQL查询并检测任何执行错误。利用这些错误信息，以及候选谓词、丰富后的问题和数据库模式，我们指示大语言模型要么生成一个新的SQL查询，要么优化现有的候选SQL查询。

我们流程中每个模块所使用的提示框架已在我们的GitHub仓库中提供。此外，还提供了一个详细示例，展示了针对示例用户查询的完整流程工作流，以供参考。

4 实验与结果

4.1 实验设置

4.1.1 数据集。我们在Spider [52]数据集和最具挑战性的跨领域BIRD数据集[28]上进行实验。Spider基准数据集包含来自200个数据库的10181个文本到SQL(Text-to-SQL)对，涵盖138个领域，每个数据库包含多个表。在我们的实验中，我们使用了Spider数据集的测试子集，其中包含2147个文本到SQL对。BIRD数据集专注于现实世界中的复杂大型数据库，并提供外部知识，以增强大语言模型更好地理解问题以及数据库结构和值的能力。BIRD数据集涵盖37个专业领域，如足球、一级方程式赛车、区块链、医疗保健和教育等，它包含来自95个数据库的12751个文本到SQL对，数据库大小为33.4GB。训练集包含9428个文本到SQL对，而开发集和测试集分别包含1534个和1789个实例。BIRD数据集的测试集是保密的。

4.1.2 评估指标。在我们的实验中，我们使用以下指标来评估模型性能:执行准确率(Execution Accuracy，EX)、基于奖励的有效效率得分(Reward-based Valid Efficiency Score，R-VES)和软F1分数，这些指标由BIRD基准测试[28]定义。执行准确率(EX)通过将预测的SQL查询的执行结果与真实SQL的执行结果进行比较，来衡量预测的SQL查询的正确性。该指标考虑到SQL查询可以有多种形式，但仍能产生相同的结果，因此更强调结果的准确性而非语法的相似性。

除了EX之外，在最新版本中，BIRD基准测试引入了基于奖励的有效效率得分(R-VES)，以衡量正确预测的SQL查询的执行效率。R-VES是之前提出的有效效率得分(Valid Efficiency Score，VES)的调整版本。R-VES在评估模型时同时考虑了SQL查询的准确性和运行时性能。下面给出了R-VES的计算方法[28]。 $$\text{ R-VES }=\{\begin{array}{ll}1.25& \text{ if }\hat{y}\text{ is correct and }\tau \ge 2\\ 1& \text{ if }\hat{y}\text{ is correct and }1\le \tau <2\\ 0.75& \text{ if }\hat{y}\text{ is correct and }0.5\le \tau <1\\ 0.5& \text{ if }\hat{y}\text{ is correct and }0.25\le \tau <0.5\\ 0.25& \text{ if }\hat{y}\text{ is correct and }\tau <0.25\\ 0& \text{ if }\hat{y}\text{ is incorrect }\end{array}$$ 其中:

• $\hat{y}$ 表示预测的SQL。

• $\tau =\frac{\text{ Ground truth SQL run time }}{\text{ Predicted SQL run time }}$ 表示时间比率。 $\tau$ 是通过运行SQL 100次，取平均值并剔除任何异常值计算得出的。

此外，BIRD基准测试引入了软F1分数(Soft F1-score)指标，旨在解决诸如EX等评估指标的局限性。软F1分数通过减轻表格输出中列重新排序或缺失值等细微差异的影响，实现更宽松的评估。这使其成为EX的补充指标，能够在现实场景中更灵活地评估模型的性能。

4.1.3 模型。在这项工作中，我们采用了最新的专有模型(GPT - 4o - mini和GPT - 4o)以及小型开源大语言模型(Qwen2.5 Coder [19]、DeepSeek Coder [15])作为实验的基础模型，且未进行微调。探索其他模型或对开源大语言模型进行微调留作未来工作。对于专有模型，大多数实验使用GPT - 4o - mini进行，它的成本比GPT - 4o低约30%。尽管成本较低，但GPT - 4o - mini表现出了强大的能力，使其成为平衡性能和预算限制的绝佳选择。

4.1.4 超参数。我们在所有测试中对实验设置进行了标准化。温度参数设置为0.0以促使输出具有确定性，而top_p参数(指核采样技术)设置为1.0。聊天完成选项的数量固定为1；不过，在未来的工作中，可以通过采用多选选择或自一致性等技术来增加该数量。最大令牌限制设置为2048。对于E - SQL流程的每个模块，提供了9个示例，每个难度级别随机选择3个示例。关于数据库列值，选择并使用了与问题最相关的10个不同值。此外，还确定并纳入了最相关的20条数据库描述语句。

4.2 结果

由于BIRD测试集未公开，我们主要在Spider测试集和BIRD开发集上评估所提出的E - SQL流程。由于GPT - 4o - mini具有成本效益，我们的大部分实验都使用它来进行。我们还在未微调的情况下对小型开源模型进行实验，以评估该流程的影响，并强调与数据库对齐的问题的重要性。表1比较了E - SQL和几个基线模型在BIRD数据集上的性能，显示出具有竞争力的结果。此外，我们评估了我们的方法在BIRD数据集不同难度级别上的性能。表2展示了E - SQL在Spider测试数据集上使用具有成本效益的专有大语言模型(LLMs)和小型开源大语言模型的性能情况。

E-SQL展现出显著的改进，特别是在BIRD数据集的挑战性问题上，这主要归功于问题丰富化(Question Enrichment，QE)和SQL优化(SQL Refinement，SR)模块的融入。使用GPT - 4o时，该流程在BIRD测试集上实现了66.29的执行准确率(Execution Accuracy，EX)和67.93的软F1分数。当使用更具成本效益的模型GPT - 4o - mini时，E - SQL在BIRD测试集上实现了59.81的EX和61.59的软F1分数。此外，使用小型开源大语言模型Qwen2.5 Coder 7B时，E - SQL在BIRD开发集上实现了53.59的EX。在Spider测试集上，使用GPT - 4o - mini时E - SQL的EX分数达到74.75，使用Qwen2.5 Coder 7B Instruct时EX分数达到58.64。不同数据集和查询复杂度级别的详细性能细分可在表3和表6中找到。关于问题丰富化和候选谓词扩充影响的进一步见解在第4.4节和第4.5节中提供。这些结果凸显了问题丰富化、候选谓词扩充和模式优化技术的有效性，特别是在处理复杂查询方面。

表1:E - SQL在BIRD开发集和测试集上的性能。如图2所示，E - SQL由CSG、CPG、QE和SR模块组成。

表2:E - SQL在Spider测试集上的性能。如图2所示，E - SQL由CSG、CPG、QE和SR模块组成。 ${}^{†}$ 符号表示使用微调大语言模型(LLMs)的方法。

4.3 模式过滤

模式过滤是一种通过移除无关的数据库模式元素来减少模型对这些元素依赖的技术，并且已经在许多先前的工作中得到应用。为了评估模式过滤对使用最先进大语言模型的基本流程的影响，我们进行了有和没有模式过滤模块(包括过滤后模式校正步骤)的各种实验。这些实验的结果如表4所示。如表4所示，模式过滤的效果因它在流程中的位置而异。然而，无论其位置如何，在基本流程中加入模式过滤模块都会导致所有难度级别的性能下降。问题丰富模块的详细结果将在下一节讨论。

表3:E - SQL在BIRD测试集上跨查询复杂度级别的详细性能

表4:不同流程在BIRD开发集上的性能表现。SF代表模式过滤模块(Schema Filtering module)，QE代表基本问题丰富模块(Basic Question Enrichment module)，G代表基本SQL生成模块(Basic SQL Generation module)。箭头表示与G基线相比性能的提升(↑)或下降(↓)。实验使用GPT - 4o - mini进行。

表5:在BIRD开发集上使用GPT - 4o - mini结合EX和Soft F1指标进行的消融研究。箭头表示与基础E - SQL相比性能的提升 $\left(\uparrow \right)$ 或下降 $\left(\downarrow \right)$ 。

在开发集上，加入模式过滤(schema filtering)导致执行准确率(EX)总体下降了高达8.21%。具体而言，如表4所示，对于简单、中等和具有挑战性的问题，性能分别下降了6.38%、12.28%和8.96%。尽管E - SQL流程本身并不包含模式过滤模块，但如表5所示，为了进行消融研究，我们将其集成到了流程中。这一集成导致开发集上的EX下降了5.54，软F1分数下降了5.68。这些发现与先前的研究[31]一致，该研究表明，先进的大语言模型(LLMs)无需显式过滤即可有效处理模式链接。因此，模式过滤被排除在最终的E - SQL流程之外，因为其负面影响超过了潜在的好处。

4.4 消融研究

我们进行了一项消融研究，以分析问题丰富(Question Enrichment)、候选谓词增强(Candidate Predicate Augmentation)和SQL细化(SQL Refinement)模块的贡献。这项研究的结果总结在表5中，展示了E - SQL流程中各个模块的影响。

表6:在使用小型开源大语言模型(LLM)的E - SQL流程中，量化评估(QE)和条件概率生成(CPG)模块的效果。

4.4.1 问题丰富化。问题丰富化模块通过将数据库条目、SQL组件、条件和SQL生成步骤注入到问题中，促进了直接模式链接，在高级专有大语言模型和小型开源大语言模型上均提升了性能，如表5和表6所示。该模块对具有挑战性的问题的影响尤为显著。若缺乏问题丰富化技术，尤其是在移除候选谓词增强模块(CPG)的情况下，会导致整体性能进一步下降。这些结果表明，通过问题重构实现的直接模式链接能够有效弥合自然语言查询与数据库模式之间的差距，从而生成更准确的SQL语句。

4.4.2 可能的谓词增强。候选谓词增强(Candidate Predicate Augmentation，CPG)模块借助LIKE运算符和候选SQL查询，对从数据库中提取的潜在谓词进行增强，从而优化了整个流程。如表5和表6所示，移除CPG模块会使整体模型性能下降近 $2\%$ 。然而，移除该模块后，在BIRD开发集的难题上性能略有提升，这表明CPG模块在某些情况下可能会引入不必要的复杂性。CPG模块对难题产生的轻微负面影响可以忽略不计，因为它显著提升了整体性能，尤其是与通过问题丰富模块所取得的显著增益相比。

4.4.3 SQL优化。SQL优化(SQL Refinement，SR)模块在纠正生成的SQL查询中的小错误方面起着至关重要的作用。如果没有SR模块，我们发现在BIRD开发集上，EX指标下降了3.57，Soft F1指标下降了3.73。这表明SQL优化步骤通过检测和纠正SQL执行错误，显著提高了最终查询的准确性。

为了进一步评估E - SQL流程中语义修正(SR)模块的影响，我们进行了以下分析，结果见表7:

• 初始生成的候选SQL查询被SR模块修改的比例。如果最终预测的SQL查询与原始候选SQL不同，则该候选SQL查询被视为已更改。

• 初始不可执行的候选SQL查询被SR模块修改为可执行查询的比例。

• 不可执行的候选SQL查询被SR模块修正为可执行且准确的SQL查询的比例。

• 包括不可执行查询在内的错误候选SQL查询被SR模块修正为准确SQL查询的比例。

如表7所示，我们对SQL优化(SR)模块的详细分析表明，GPT - 4o - mini和GPT - 4o最初生成的错误SQL查询中， $5.35\%$ 和 $1.83\%$ 分别被SR模块成功修正。虽然SQL优化技术对这两个模型都有积极影响，但在像GPT - 4o - mini这样能力较弱的模型上效果更为显著。这些结果凸显了该模块提高查询准确性的能力，特别是对于初始性能较低的模型，这使得SQL优化成为提高整个系统鲁棒性的关键组成部分。

表7:SQL优化(SR)模块在BIRD开发集上的分析

4.5 丰富问题对小型大语言模型的影响

为了评估集成数据库的问题对小型大语言模型 $\left[15,19,50\right]$ 的性能影响，我们进行了一项实验，比较它们在默认问题和丰富问题上的表现。在这个实验中，针对给定问题的 SQL 查询是使用单提示方法生成的。此步骤中使用的提示模板与 E - SQL 流程中的候选 SQL 生成(CSG)模块的模板类似，但不包括数据增强组件，如数据库描述、值样本和小样本示例。这种方法使我们能够分离出丰富问题的影响，因为单提示仅依赖于指令和问题，而没有额外的上下文。丰富问题是从使用 GPT - 4o 的 E - SQL 流程的问题丰富模块(QE)的输出中提取的，以确保它们包含数据库项和 SQL 构建计划。

如表8所示，结果表明，当提供高质量的、与数据库集成的自然语言查询时，即使是小型大语言模型(LLMs)在不进行特定任务微调的情况下也能取得有竞争力的表现。这些发现强调了与数据库集成的丰富问题的关键作用，这些问题包含了逻辑SQL构建步骤。

4.6 计算成本分析

了解计算开销对于评估该框架的实际可扩展性和适用性至关重要，特别是考虑到对大语言模型(LLMs)的依赖及其资源需求。表9突出显示了问题丰富化对令牌数量 ${}^2$ 的影响，而表10提供了BIRD开发集上关键管道组件的提示和完成阶段的平均令牌使用详情。由于定义明确的指令、数据增强(包括小样本示例、数据库描述和数据库值)，提示中的平均令牌数量本质上较高，这也是大多数文本到SQL方法中常用的做法。因此，与提示令牌的总数相比，由于丰富化导致的问题令牌数量的增加相对不显著。尽管问题丰富化会带来计算开销，增加自然语言问题及其推理的平均令牌数量，但E - SQL在计算方面优于 $\left[10,13,22,31,40\right]$ 那些为单个用户问题生成多个SQL查询的方法。这些方法由于重复的SQL生成、后续对这些SQL查询的修正以及选择过程而产生了显著的计算成本。每个E - SQL模块仅执行一次，可将与重复调用相关的计算成本降至最低，确保更高的效率。这种成本与性能之间的平衡凸显了我们的管道在大规模部署时的可扩展性和效率。

表8:丰富问题对未在BIRD开发集上进行微调的小型开源大语言模型(LLM)性能的影响。使用GPT - 4o生成的丰富问题，用于评估高质量问题丰富对小型开源模型性能的影响。 ${}^{†}$ 符号表示使用微调大语言模型的方法。

表9:BIRD开发集中默认自然语言问题与丰富自然语言问题的比较

表10:BIRD发育数据集上各模块的计算成本分析

在我们的流程中，会执行最初生成的候选SQL查询，以识别执行错误并增强大语言模型的错误感知能力。虽然这一步骤会增加整个流程的延迟，每个查询的平均执行时间为49.936毫秒，但它通过提供有关执行错误的宝贵反馈，在确保准确优化SQL方面起着至关重要的作用。需要注意的是，整个流程的响应时间会因多种因素而有所不同，包括自然语言问题的复杂程度、提示的长度以及专有大语言模型(LLMs)的API响应时间，而API响应时间又受服务器负载和流量的影响。这些因素共同导致了系统的延迟。

5 讨论与局限性

我们的实验结果凸显了问题丰富化和候选谓词增强对E - SQL流程性能的重大影响。问题丰富化模块缩小了自然语言查询与数据库模式之间的差距，对提高查询准确性至关重要，尤其是对于具有挑战性的问题。通过用数据库项、条件和SQL生成步骤丰富自然语言问题，该模块增强了直接的模式链接，确保生成的SQL查询更符合数据库的结构。消融研究证明了这一改进，凸显了这种方法的有效性。

在我们的评估中，一个值得注意的发现是，使用不同模型时，开发集和测试集的性能表现不一致。具体而言，使用GPT - 4o时，与开发集相比，该流程在测试集上的性能有所提升。然而，使用GPT - 4o - mini时，这一趋势发生了逆转，与开发集相比，测试集上的性能有所下降。由于BIRD测试集未公开，我们无法直接对其进行分析，以找出这种差异的潜在原因。此外，众所周知，大语言模型在多次运行中的性能会出现波动，这可能进一步导致了这种不一致性。因此，虽然这些性能波动的确切原因尚不清楚，但它们凸显了在可控条件下进行进一步探索的必要性。

提示词设计在影响模型性能方面起着关键作用。E - SQL流程各模块所使用的提示词模板已公开在我们的GitHub仓库中。本研究主要强调通过问题丰富化和数据增强来进行模式链接，有意不涉及对其他提示词模板的探索。

尽管有这些进展，但我们的方法仍存在一些局限性。由于硬件和成本的限制，几乎所有实验都是使用GPT - 4o - mini和未经微调的小型开源大语言模型(LLMs)进行的。在小型开源大语言模型中，整个E - SQL流程仅在Qwen2.5 Coder 7B Instruct上执行，因为其他小型大语言模型的上下文长度不足以运行并观察E - SQL流程的效果。开发能在小型大语言模型和有限上下文长度下有效运行的更高效的模式链接技术，是未来工作的一个有前景的方向。

6 结论

在本研究中，我们引入了E - SQL，这是一种新颖的流程，旨在通过问题丰富化实现直接模式链接并纳入候选谓词，来解决文本到SQL翻译中的关键挑战。我们的实验表明，问题丰富化模块将自然语言查询与相关数据库元素和逻辑步骤相结合，显著提高了查询准确性，特别是对于复杂查询而言。此外，所提出的候选谓词增强技术进一步提升了该流程的性能。而且，我们的额外实验揭示了丰富后的问题对上下文长度有限的小型开源大语言模型(LLM)性能的重要性和积极影响。

虽然一些先前的研究强调了模式过滤的实用性，但我们的研究结果表明，将模式过滤纳入利用先进大语言模型(LLM)的文本到SQL翻译流程中会导致性能下降。这支持了这样一种观点，即在采用最新大语言模型(LLM)的现代架构中，显式的模式过滤可能是多余的。

通过专注于问题丰富化、数据增强和SQL优化，E - SQL在BIRD基准测试中取得了具有竞争力的结果。具体而言，E - SQL与GPT - 4o相结合，在开发集和测试集上分别实现了 $65.58\%$ 和 $66.29\%$ 的执行准确率。这些结果凸显了E - SQL在处理复杂查询方面的有效性，并表明它是未来文本到SQL任务中一种很有前景的方法。

尽管由于问题丰富化过程中令牌数量增加导致了轻微的计算开销，但与整体令牌使用量相比，其影响可以忽略不计，并且显著的性能提升弥补了这一开销。此外，E - SQL通过仅执行每个模块一次来确保成本效益，避免了重复查询生成和修正对资源的过度需求。这种平衡凸显了E - SQL的可扩展性以及它适用于资源受限的部署场景。

对于针对上下文长度有限的小型大语言模型(LLM)进行微调、迭代或多次问题优化以及模式链接技术的进一步探索，留待未来工作开展。