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

自然语言转SQL，这个领域这几年可以说是火得一塌糊涂。毕竟，谁能拒绝用大白话跟数据库聊天呢？大型语言模型（LLM）的出现，更是把这把火添得旺旺的。现在主流的玩法基本上两条路：要么拿像Deepseek-7B这样的小模型来微调，要么就靠GPT-4这类闭源巨无霸，玩提示工程。我们今天要聊的RSL-SQL，就属于后者——它不碰模型本身，而是琢磨怎么把提示词这块“敲门砖”打磨得更趁手。

最朴素的提示方案，就是把数据库的结构一股脑全塞给模型，让它看着问题编SQL。这个法子很直观，模型对数据库理解得越透彻，理论上SQL写得就越准。但问题来了，现实世界里的数据库，尤其是工业级的，动辄成百上千个字段。你把整个Schema都怼进去，先别说token烧得快，关键是噪音太大。用户的问题可能就涉及其中三五个元素，无关的信息反倒成了干扰源，反而会带偏模型。

为了解决这个“信息过载”的毛病，业界想了个法子——

。说白了，就是在正式写SQL之前，先做个“预筛选”，把跟当前问题八竿子打不着的表和列给过滤掉，只把最相关的那部分结构喂给大模型，这样既能省成本，又能提精度。

这招听起来很妙，但以往的做法，效果却有些差强人意。比如MCS-SQL，它让模型自己从完整Schema里挑相关的表和列，为了确保不遗漏，得设置高温度参数，随机解码个60次，最后把结果合并去重，折腾一圈，严格召回率也就89%左右。而Chess方法更夸张，它让模型对着每个表的每个列，挨个判断跟问题有没有关系，成本高得吓人，最终召回率也只是勉强摸到90%的边。

更要命的是，最近有研究指出，对于GPT-4o这样的强模型，用了Schema Linking之后，性能反而可能往下掉。这又是为什么呢？问题出在两个方面：

如果模式链接漏掉了必需的某个表或某列，那后面生成的SQL注定是错的，这属于“一票否决”。

就算把所有相关元素都召回了，你得到的也是一个“残缺”的Schema。原始数据库里那些表之间的关联、完整性约束，可能都被破坏了。这就好比你把一栋房子的承重墙拆了，虽然客厅看着大了，但整栋楼不稳了。在完全召回的例子里，有些原本能做对的SQL，因为输入结构变了，反而被改错了。

所以，核心矛盾就在于：如何在有效过滤噪音的同时，最大限度地保留数据库的结构完整性和关键信息？RSL-SQL就是冲着这个难题来的。

RSL-SQL框架：既要又要还要的平衡术

RSL-SQL的思路很清晰，就是一套组合拳，专门用来提升Schema Linking的“正向收益”（把错的改对），同时压制它的“负向收益”（把对的改错）。

先是用LLM做一轮“前向”筛选，再用一个“后向”手段兜底——先基于完整Schema生成一个“草稿SQL”（Pre-SQL），然后从这个草稿里精确提取用到了哪些表和列。这两招结合起来，严格召回率直接干到了，还顺手把后续要处理的表和列数量，平均砍掉了。

不过，光召回高还不够，还得解决简化Schema结构不完整的毛病。RSL-SQL这儿又用了两招：

• 一是给简化后的Schema里的每一列，都附上详细的文本描述，帮模型理解这些列到底是干啥的。
• 二是针对复杂查询，先独立地把SQL里的各个组件（比如用到了哪些表、列、关键字、条件）拆开来生成，再把它们作为额外信息喂给模型。这相当于给了模型一份“半成品”，降低了它从头造轮子的难度。

做完这些，模型就能基于简化后的Schema，再生成一个SQL。现在，我们手头就有了两个SQL：一个基于完整Schema（结构全，但噪音大），一个基于简化Schema（噪音小，但结构可能不全）。

怎么选？RSL-SQL用了

，让LLM自己比较这两个SQL，挑出质量更高的那个。这一步堪称“风险对冲”，完美地平衡了完整性和低噪音的优势。

最后，对于那些执行报错或返回空结果的SQL，还准备了

机制，把执行结果反馈给模型，让它自己迭代优化，直到写出正确的SQL。

算法拆解：每一步都打在点上

2.1 Schema Linking：前向与后向的完美互补

▲ 双向模式链接框架图

这里的“前向”和“后向”是两个阶段。

，就是利用LLM直接从完整Schema里捞相关的表和列。不过单靠这个，召回率通常不太够，跟MCS-SQL一个毛病。但光靠这个也不行，所以RSL-SQL还用了方法，从数据库的外部知识库（比如一些专有名词的定义）里提取可能涉及的表和列。这部分虽然命中率不高，但胜在精准。

，则是从前一步生成的Pre-SQL里“反向”提取。这里又分两种路子：一个是直接用sqlglot工具精确解析，另一个是用“表.列”的格式做列名全匹配。

两种方法各有优劣：全列名匹配召回更高，但可能带进来一些多余列；sqlglot更干净，但可能漏掉关键列，尤其是Pre-SQL本身写错了的时候。最终，RSL-SQL选择了基于列名的精确匹配，用一点小小的冗余，换来了更可靠的后向召回。

2.2 Contextual Information Augmentation：给模型更多“上下文”

▲ 上下文信息增强示例图

这一步是关键。模式链接把模型的注意力集中到小范围内，但RSL-SQL觉得还不够，又加了三味“猛料”：

• 关键元素
  ：独立生成SQL中可能需要的表和列。

• 条件
  ：分析问题后，生成WHERE子句中可能用到的条件和约束。

• 关键字
  ：识别问题中的关键词，给出可能用到的SQL关键字（如DISTINCT、GROUP BY）。

同时还给简化后的每一列附上详细描述。这就像是先给模型列了一个“写作提纲”，再让它结合“字典”，最后写出完整的SQL。实验证明，这一步大幅提升了正向收益，把很多原本会写错的SQL给纠正了过来。

2.3 Binary Selection Strategy：做最稳健的选择

▲ 二元选择策略示例图

这一步是风险控制的关键。它没有像其他方法那样，搞一个巨大的SQL候选池，然后从中挑最优的，而是只比较基于完整Schema和简化Schema的两个SQL。这么做成本极低，但却能有效对冲两种方案的风险。当简化Schema漏了信息时，完整Schema的SQL顶上；当完整Schema被噪音干扰时，简化Schema的SQL又能救场。实验数据也证实，这一步有效降低了模式链接的负向收益。

2.4 Multi-Turn Self-Correction：不抛弃不放弃

▲ 多轮自纠正策略示例图

对于执行出错或返回空结果的SQL，RSL-SQL会启动一个迭代优化的循环。它把执行结果作为反馈，让模型重新审视问题，修正SQL。这就像人类写代码时的Debug过程，通过不断试错，最终写出正确的查询。结合历史对话信息，这个纠正过程会更高效。

实验结果：用数据和成本说话

3.1 BIRD结果

在BIRD这个业界公认的“地狱级”数据集上，RSL-SQL凭借GPT-4o模型，拿下了

的执行准确率，一举刷新了开源领域的SOTA纪录。更亮眼的是，它的成本控制得极好——同样用GPT-4o，E-SQL方法消耗的token是我们的三倍，但准确率反而比我们低2%。这几乎等同于在性能和成本之间，找到了一个完美的黄金分割点。

3.2 Spider结果

在经典的Spider数据集上，RSL-SQL用DeepSeek模型达到了87.7%，用GPT-4o则提升到了87.9%，与之前MCS-SQL（GPT-4）的89.6%非常接近。这足以证明RSL-SQL方法的

——不管是对强模型还是相对较弱的模型，都能稳定地输出高质量SQL。

3.3 Schema Linking结果

在模式链接这个环节，RSL-SQL的优势更是碾压级的。CHESS和MCS-SQL费了九牛二虎之力才达到89%多的严格召回率，而RSL-SQL的“双向模式链接”仅仅用了一两轮输入，就做到了

。这不仅意味着更高的召回，还意味着更低的成本和更少的噪音。之前的方法要么只简化表，要么只简化列，而RSL-SQL是表、列两手抓，两手都硬。

3.4 消融实验

消融实验的结果，清楚展示了RSL-SQL每个模块的价值。CIA（上下文信息增强）带来了最大的正向收益，把很多错题变成了对题；而BSS（二元选择策略）则有效减小了负向收益，防止原本做对的题被改错。这两个环节的协同，构成了RSL-SQL性能提升的核心引擎。

深度分析：为什么这套组合拳这么有效？

4.1 双向模式链接：强模型和弱模型的最佳拍档

一个有意思的发现是：对于GPT-4o这样的强模型，双向模式链接带来的高召回率，能直接转化为精度提升；但对于DeepSeek这样的弱模型，高召回带来的高噪音反而可能拖后腿。这也验证了最近研究的一个观点：模型更强时，受噪音影响更小，召回率的价值更高；模型较弱时，精确度（控制噪音）才是更需要优先解决的问题。

这也解释了为什么“后向模式链接”不可或缺。因为单靠“前向”召回率不够，会导致CIA步骤效果不佳，而加上“后向”兜底，能显著提升最终SQL的质量。而“二元选择策略”又能在弱模型应用双向链接时，有效地平衡召回和噪音，展现出极强的鲁棒性。

4.2 正向收益与负向影响：CIA和BSS的完美配合

CIA的核心优势在于大幅提升正向收益，把很多“接近正确”的SQL变成“完全正确”。通过让LLM独立生成SQL组件，它能让模型更清晰地理解用户意图与数据库元素之间的映射关系。但它也不是完美的，偶尔也会把一些原本正确的SQL带跑偏。

这时候BSS就派上用场了。它就像一个稳健的裁判，在CIA带来的“正确SQL”和“完整Schema”生成的“稳妥SQL”之间，选择那个最优解。结果就是，CIA负责冲锋（提升上限），BSS负责殿后（守住下限），两者配合，实现了整体性能的显著提升。

案例分析

此外，RSL-SLF还通过多轮自纠正机制，确保了SQL生成的稳健性。即便前面几步出现了错误，后续步骤也能通过执行反馈，对错误进行修正，这相当于给SQL的准确性上了“双保险”。

总的来说，RSL-SQL没有去追求花哨的模型结构，而是回归到“信息”本身。它用一套设计精巧的提示工程框架，稳健地提升了Schema Linking的收益，同时控制了成本和风险。对于任何一个想把LLM高效、低成本地应用到文本到SQL生成任务中的团队来说，RSL-SQL的研究思路都极具参考价值。