论文链接：
代码链接：
引言
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）。
模式链接的这些风险说明，如何在有效过滤噪音的同时，最大程度地保留与用户查询相关的关键信息，是一个值得深入探索的问题。
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：
相比之下，我们的方法仅通过两次解码即可实现 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
生成 SQL 的关键组件：
-
元素（）：SQL 查询中可能需要的表和列的列表，这与正向模式链接完全相同。 -
条件（）：通过问题的分解和分析，WHERE 子句的可能条件和约束。 -
关键字（）：通过在问题中定位关键指示词，可能相关的 SQL 关键字（例如 DISTINCT、GROUP BY）。
2.3 Binary Selection Strategy
具体而言：
-
完整模式保留了数据库的完整结构，能够提供更全面的信息支持，但同时可能引入大量冗余信息，增加 LLM 的计算负担并引发噪音问题。 -
简化模式则通过模式链接大幅减少冗余信息，将 LLM 的注意力集中于与用户查询相关的部分。然而，这种简化也可能导致关键信息的丢失，尤其是无法完全召回必需的表和列时。
这一过程可以更形象地理解为一种风险对冲（Risk Hedging）：
-
在完整模式下生成的 SQL 可以弥补简化模式可能遗漏的信息。 -
而简化模式生成的 SQL 则能有效减少冗余信息的干扰，提高生成效率。
2.4 Multi-Turn Self-Correction
Main Results
3.1 BIRD Result
▲Open column indicates whether the code is released or not. ∗ symbol denotes fine-tuned methods.
3.2 Spider Result
3.3 Schema Linking Result
3.4 Ablation Study
分析
4.1 Bidirectional Schema Linking
1. 双向模式链接的整体优势
2. 前向模式链接的局限性与后向模式链接的必要性
3. 二元选择策略的鲁棒性与有效性
4.2 Positive Gain and Negative Impact
Case Study
（文：PaperWeekly）