企业 FDE

Text-to-SQL新SOTA！华科团队提出双向模式链接新方法RSL-SQL

2024 年 12 月 26 日

论文标题：

RSL-SQL: Robust Schema Linking in Text-to-SQL Generation

论文链接：

https://arxiv.org/abs/2411.00073

代码链接：

https://github.com/Laqcce-cao/RSL-SQL

引言

Text-to-SQL（又称 NL2SQL）是一项将用户的自然语言问题转换为结构化查询语言（SQL）的任务，这项技术对非专家用户与关系数据库的交互至关重要。近年来，利用大型语言模型（LLM）强大的理解和生成能力，已成为提升 Text-to-SQL 任务性能的流行方法。

目前，基于 LLM 的 Text-to-SQL 主要分为两类技术路线，一类是对一些开源的参数较小的 LLM（如 Deepseek-7B）进行微调，另一类则是基于闭源的参数较大的 LLM （如 GPT-4、GPT-4o）的提示工程方法。本文聚焦于后者，即构建一种新的提示工程框架，提升已有 LLM 在 Text-to-SQL 任务上的性能。

一个最基础、最直观的提示工程方案是，输入数据库的 Database Schema，即数据库的基本结构（包括表名、列名、主外键关系等等），以及用户的问题，提示模型输入该问题对应的 SQL 语句。这种提示范式可以很方便让 LLM 适应各种不同的数据库与对应的用户查询。

近期的一些研究表明，在输入中，额外增加表和列的文本描述、小样本示例（即 few-shot Question-SQL pairs）、一定格式描述的数据样本（即数据库中每一个表的随机几行数据样本）等信息有助于 LLM 更好地理解数据库结构，从而生成更准确的 SQL。

直观上来看，只要 LLM 理解数据库结构的能力足够强，提示中的给到的数据库描述越详细，SQL 最终生成的准确率也越高。

然而，在实际场景中，尤其是面对包含数百甚至上千字段的大型工业数据库时，在提示中包含完整的数据库信息会导致输入 token 过多，计算成本增加，更重要的是会引入大量噪音。由于用户查询通常只涉及数据库中的非常小部分元素，不相关的表和列可能容易混淆模型，从而降低 SQL 生成的性能。

为了解决这一问题，模式链接（Schema Linking）技术被广泛采用。

什么是模式链接？

模式链接是识别数据库中与用户问题相关的元素，并过滤掉无关的部分，以减少噪音和输入复杂性。具体来说，就是，在生成 SQL 之前，用一些方法提前找到与用户问题相关的表和列，然后，输入给大模型的是被显著简化后的 Database Schema，从而达到减小输入噪音并增强 SQL 生成性能的目的。

例如，MCS-SQL 方法利用 LLM 直接根据 Database Schema 和用户问题，提示 LLM 直接输出相关的表和列（仍然需要输入全部的 Database Schema，但是可以选择性舍弃一些信息，例如表和列的文本描述等），MCS-SQL 设置了较高的温度参数进行了 60 次随机解码，然后把 LLM 输出的 60 次结果进行合并并去重。

MCS-SQL 方法达到了 89% 左右的严格召回率（召回的表和列完全包含实际 SQL 包含的表和列的比例）。

Chess 方法则利用了更复杂的方法，对于每个用户查询，Chess 利用 LLM 依次判断每个表的每个列是否和用户问题相关，最终达到 90% 左右的严格召回率。对于每个问题，两种方法都吊用了大量次数的 LLM。

尽管模式链接（Schema Linking）在减少噪音方面取得了显著效果，但是已有的 Schema Linking 技术在对 SQL 生成性能的提升上远未达到预期。最近的研究显示，基于较强的 LLM（例如 GPT-4o），Schema Linking 甚至会导致模型性能下降，如 [1]（https://arxiv.org/abs/2408.07702）所示。

我们将这个问题归因于 Schema Linking 带来的信息损失风险：

风险一：如果模式链接没有能召回所有必需的 Schema Elements（即相关的表和列），生成的 SQL 将不可避免地出错（假设 LLM 不产生幻觉，即其生成的 SQL 中的 Schema Elements 完全属于输入的 Database Schema）。

风险二：即使模式链接召回了所有相关的 Schema Elements，简化后的 Database Schema 已经不是原来的 Database Schema 了，这可能会破坏原始 Database 的结构完整性，从而导致性能提升未达到预期。

具体来说，简化 Database Schema 后，原来基于完整 Database Schema 回答错误的样例可能会被纠正（我们称其为正向收益），但原来能回答正确的样例可能也会被改错（我们称其为负向收益）。因此，即使在那些完全召回的案例中，正向收益需要显著高于负向收益才能带来显著的性能提升。

模式链接的这些风险说明，如何在有效过滤噪音的同时，最大程度地保留与用户查询相关的关键信息，是一个值得深入探索的问题。

RSL-SQL Framework：

为了利用模式链接的优势，同时降低其风险，我们提出了 RSL-SQL，一种基于稳健模式链接的文本到 SQL 生成框架。我们的方法旨在提高 Schema Linking 的正向收益并降低其负面收益。

在我们的框架中：

为了避免模式元素不完全召回的风险，通过 Bidirectional Schema Linking技术，我们实现了 94% 的严格召回率，并得到了简化后的 Database Schema。在这一步中，我们也得到了基于完整的数据库模式生成的初步 SQL 语句。

简化后的 Database Schema 可能存在结构不完整的风险，我们采取了两个策略。一个是在输入中添加了数据库每个表的每个列的文本描述。

另外，生成复杂查询的 SQL 可能是一个相对困难的问题，因此我们提前利用简化后的 Database Schema、用户问题等信息独立地生成 SQL 语句中的每个组件（包括 tables、colunms、keywords、conditions），这些组件也会作为额外的信息添加到输入中。

最后，我们通过在输入中包含了更多的上下文信息，基于简化后的 Database Schema 生成了另一个 SQL 语句。这一步我们称为 Contextual Information Augmentation，我们发现这一步可以提高 Schema Linking 的正向收益。

目前，我们已经得到了两个不同方法生成的 SQL（分别基于完整 Database Schema 和简化的 Database Schema），这两个 SQL 都有各自的优势。

我们使用了 Binary Selection Strategy 对其进行评估与比较，选择或生成更优的 SQL。这种策略有效平衡了完整 Schema 的完整性优势与简化 Schema 的低噪音优势，我们发现这一步可以进一步降低提高 Schema Linking 的负向收益。

最后，针对执行错误或返回空值的 SQL 语句，我们使用了 Multi-Turn Self-Correction。通过整合 SQL 执行结果的反馈，对错误的 SQL 进行迭代优化，不断改进生成结果，从而进一步提高最终 SQL 的准确性。

Token Consumption and Cost：

从成本的角度来看，我们的方法开销相对较低，具体如上表所示。比较结果表明，基于 DeepSeek 模型的 RSL-SQL 方法相比使用 GPT-4 模型的其他方法（例如 MAC-SQL、TA-SQL），既具有更低的计算成本，又实现了更优的性能。

1. 低成本与高性能的对比：在使用 GPT-4o 模型时，E-SQL 方法的 token 消耗是我们的三倍，但其性能比我们的方法低约 2%。这表明我们的方法在性能与效率之间实现了更优的平衡。

模式链接中的高效性：在模式链接阶段，前文提到，其他方法的开销明显更高。MCS-SQL 方法通过设置较高的 Temperature 参数进行了 60 次解码，才将召回率提高到 89%。而 CHESS 方法对每一列都让 LLM 输出该列是否与用户问题相关，导致 token 消耗巨大。

相比之下，我们的方法仅通过两次解码即可实现 94% 的召回率，并将后续步骤中，所需输入的表和列的总数平均削减了 83%，极大地降低了后续步骤的计算成本，同时保持了高效性和准确性。

算法介绍

2.1 Schema Linking

前向模式链接：

采用 LLM-Based 方法，选择相关的表和列，不过这部分严格召回率最低，说明单纯使用 LLM 进行选择表和列效率很低，正如 MCS-SQL 方法，解码数十次，召回率才刚刚达到 90%。
使用完全匹配方法从数据库提供的外部知识库中提取表和列，这部分召回率虽然也很低，但是却很重要。因为对每一个问题来讲，提供的外部知识库是一些专有名词的定义，大概率会使用到其中提到的表和列。

后向模式链接

从 Pre-SQL 中提取表和列，有两种方法：
使用 sqlglot 工具进行精确提取Pre-SQL使用到的表和列。
使用完全匹配提取表和列：对数据库里面的元素格式化为[表.列]，对于每一个列名出现在 SQL 中的[表.列]进行召回。

两种方法各有优缺点：

全列名匹配 提升了召回率，但可能引入冗余列。
sqlglot 工具 则在噪声控制上更具优势，但存在召回不足的风险，尤其当初步 SQL 出现错误时。
为在准确性和召回率之间取得平衡，我们最终选择了基于列名的精确匹配方法来实现后向模式链接。这种方法尽管可能引入少量冗余列，但可以有效降低基于简化模式生成 SQL 时的出错概率，从而更可靠地支持后续生成与优化。

2.2 Contextual Information Augmentation

模式链接在简化数据库结构的同时，将 LLM 的注意力集中在与问题相关的信息上。为了进一步增强这一优势，我们设计了一个方法，利用 LLM 独立生成 SQL 的关键组件，并结合简化后的模式进行全面优化。具体步骤如下：

生成 SQL 的关键组件：

元素（）：SQL 查询中可能需要的表和列的列表，这与正向模式链接完全相同。
条件（）：通过问题的分解和分析，WHERE 子句的可能条件和约束。
关键字（）：通过在问题中定位关键指示词，可能相关的 SQL 关键字（例如 DISTINCT、GROUP BY）。

列的详细描述：在模式链接简化后，列的数量显著减少。因此，我们为每个列添加详细描述，作为额外信息输入给 LLM。这些描述来源于文献[2]（https://arxiv.org/abs/2405.15307），能够帮助 LLM 更好地理解用户问题与数据库元素之间的映射关系，同时不会因简化模式后的列数量较少而引入过多噪音。

生成完整 SQL：最后，将上述生成的组件和简化模式作为输入，结合每列的详细描述，生成最终完整的 SQL 查询。

2.3 Binary Selection Strategy

这种二元选择策略是降低模式链接风险的重要一步，旨在充分平衡完整模式和简化模式各自的优缺点。

具体而言：

完整模式保留了数据库的完整结构，能够提供更全面的信息支持，但同时可能引入大量冗余信息，增加 LLM 的计算负担并引发噪音问题。
简化模式则通过模式链接大幅减少冗余信息，将 LLM 的注意力集中于与用户查询相关的部分。然而，这种简化也可能导致关键信息的丢失，尤其是无法完全召回必需的表和列时。

为平衡这两者的优劣，我们引入了二元选择策略：利用 LLM 独立生成基于完整模式和简化模式的两个 SQL，然后比较它们的质量，最终选择最优的一个。

这一过程可以更形象地理解为一种风险对冲（Risk Hedging）：

在完整模式下生成的 SQL 可以弥补简化模式可能遗漏的信息。
而简化模式生成的 SQL 则能有效减少冗余信息的干扰，提高生成效率。

Note：没有以任何方式生成 SQL 候选池，仅仅从两个 SQL 中进行选择。如果使用候选池，准确率必然会再度上升，但是成本也会随之上升。

2.4 Multi-Turn Self-Correction

为了应对高风险 SQL 查询的潜在错误，我们提出了一种基于多轮对话的纠正策略，该策略利用保存的历史对话信息进行迭代优化。具体而言，当 SQL 无法执行或返回空结果时，通常意味着查询存在问题。此时，我们通过一套规则对 SQL 的执行风险进行评估，并对高风险 SQL 查询重新生成和调整。

在此过程中，我们整合了 SQL 执行结果的反馈，将其作为生成和优化的核心依据。通过不断迭代优化错误的 SQL，我们能够逐步改进生成结果，提高 SQL 语句的准确性。这种方法不仅利用了历史对话信息来增强上下文理解，还有效结合了执行反馈进行针对性调整，从而显著提升最终生成 SQL 的准确率。

Main Results

3.1 BIRD Result

我们对基于微调的方法和基于 LLM 的方法进行了比较分析。MSc-SQL 基线目前在 BIRD 开发集上基于微调的方法中保持了 SOTA 指标。然而，它的执行精度仍然略低于我们使用 GPT-4o 模型的 RSL-SQL 框架。

值得注意的是，表中显示的利用 GPT-4 模型的几个基线无法与我们使用 DeepSeek 模型的框架的性能相匹配。在采用 GPT-4o 模型的相同条件下，与 E-SQL 方法相比，我们的方法不仅实现了更高的执行精度，而且成本显着降低。我们的框架执行准确率高达 67.21%，在开源领域树立了新的 SOTA 基准。

3.2 Spider Result

使用 DeepSeek 模型时，RSL-SQL 的执行精度为 87.7%，使用 GPT-4o 模型时，执行精度提高到 87.9%。此性能与 MCS-SQL 方法（GPT-4）非常接近，执行精度达到 89.6%。这凸显了 RSL-SQL 强大的通用性及其生成高质量SQL 的潜力。

3.3 Schema Linking Result

如表所示，CHESS 方法通过 LLM 的检索结合多轮过滤实现模式链接，达到89.7%的严格召回率。MCS-SQL 方法采用多提示和多选择解码策略，利用 LLM 进行迭代选择，达到 89.8% 的严格召回率。

相比之下，我们的方法只需要一到两轮输入，显着减少了 token 消耗。利用 GPT-4o 模型，我们的双向模式链接方法在 NSR 和 SRR 指标上实现了 SOTA 性能，完全调用了 SQL 生成所需的 94% 的列。

值得注意的是，在之前的方法中，只有 PET-SQL 在 Spider 测试数据集上应用了类似的策略，但它只关注表简化，而没有解决列简化问题。

我们的方法不仅召回了绝大多数表，而且还显着减少了列数。此外，由于前向和后向模式链接的高度互补性，两种方法的列的并集不会显着增加列的总数。因此，我们的双向模式链接总体上实现了 SOTA 性能。

3.4 Ablation Study

我们进行了一项消融研究，以调查我们提出的方法的每个组成部分对执行准确性（EX）的增量影响。下表列出了在BIRD 开发集的实验结果。该表说明了 DeepSeek 和 GPT4o 在不同任务难度级别上的执行准确性，显示了通过逐步将不同的实验步骤纳入方法中所取得的效果。

分析

4.1 Bidirectional Schema Linking

1. 双向模式链接的整体优势

如图 8a 所示，在使用 GPT-4o 模型时，双向模式链接在后续步骤中的执行精度明显高于单独使用前向或后向模式链接。然而，图 8b 显示，对于 DeepSeek 模型，仅使用后向模式链接时的执行精度略高于双向模式链接。这是因为，虽然双向模式链接实现了更高的召回率，但也引入了更多噪声，从而对 SQL 生成产生负面影响。

这一现象与文献 [1]（https://arxiv.org/abs/2408.07702）的发现一致：对于更强的模型（如 GPT-4o），高召回率通常能带来更高的执行精度，而噪声影响较小；但对于较弱的模型（如 DeepSeek），精确度的影响更为关键，召回率高但是噪音也高的情况下可能反而削弱执行准确性。

2. 前向模式链接的局限性与后向模式链接的必要性

无论是使用 GPT-4o 还是 DeepSeek 模型，图 8 显示在步骤 2 中仅基于前向模式链接结果的 CIA（Contextual Information Augmentation）的执行精度均呈下降趋势。这是因为前向模式链接的召回率较低，进一步证明了后向模式链接在模式链接过程中不可或缺的作用。

3. 二元选择策略的鲁棒性与有效性

值得注意的是，即使在上述情况下，应用二元选择策略后，基于前向模式链接结果的执行精度也显著提高。这表明，尽管前向模式链接本身可能引入一些噪声，但其增强召回的能力为后续模式链接优化提供了重要基础，而二元选择策略在平衡召回率和精确度方面展现了强大的鲁棒性与有效性。

4.2 Positive Gain and Negative Impact

RSL-SQL 框架中，step 2: CIA 与 step 3: BSS 是我们的核心。

Step 2：CIA 的关键作用在于通过上下文信息增强（H_Aug），为 SQL 生成提供更丰富的辅助信息。这一步显著提高了模式链接的积极收益。

如图 7b 所示，Step 2：CIA 大幅增加了纠正 SQL 查询的数量。通过抽样分析，我们发现生成的文本信息有效地帮助模型理解用户查询与数据库元素之间的映射，同时识别 SQL 关键字，从而增强生成 SQL 的准确性。

然而，如图 7a 所示，CIA也可能引入一定的负面影响，将完整模式生成的部分正确 SQL 转变为不正确 SQL。尽管如此，由于积极收益远远超过消极影响，CIA 整体上降低了模式链接的风险。

Step 3：BSS 则进一步通过二元选择策略对模式链接进行优化。该策略对比完整模式和简化模式生成的 SQL，选择其中更优的 SQL，从而减少负面影响。如图 7a 所示，无论使用 DeepSeek 还是 GPT-4o 模型，BSS 均显著降低了模式链接的负面影响。

此外，BSS 还提升了正增益（图 7b），特别是在 DeepSeek 模型中表现更为显著。这是因为 DeepSeek 模型的 CIA 阶段提供了更多提升空间，而 GPT-4o 模型在 CIA 后的执行准确率已达到 65.06%，进一步提升的空间有限。

Case Study

RSL-SQL 框架通过上下文信息增强、二元选择策略和多轮自校正来确保 SQL 生成的正确性。如图所示，即使前面的步骤出现了错误，后续的步骤也可以通过特定的方法纠正这些错误，提高 SQL 的准确性。

立即咨询 JOTO

JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。联系 JOTO 获取 AI 落地咨询

想把这些做法用到你的业务里?

留下你的场景和痛点,我们帮你判断从哪一步开始。

联系我们