技术解读 | 搭建 NL2SQL 系统需要大模型么？

​

近年来，大模型（LLMs）的热潮推动了自然语言处理（NLP）任务的广泛进展，NL2SQL（自然语言转 SQL）作为热门任务之一也不例外。 从下图可以看出，不同的 benchmark 以及测试方法在 T5 模型之后，出现了极速增长。

并且一些 SOTA 模型在 nl2sql 任务的表现上和以往相比，有了极大的提升：

但是普遍的这些模型的参数量都在 100B 以上，而 NL2SQL 作为一个相对 niche 的场景，并且和业务场景结合密切的情况下，是否可以在一些小参数量的模型上也获得比较好的表现呢？

NL2SQL 的核心是什么？

我们认为，NL2SQL 的核心能力并不在于“语言建模”本身，而是在两个方面：

1. 理解用户意图与问题背景（场景理解）

2. 根据数据库结构正确地生成 SQL（逻辑推理+语法生成）

这两个任务的挑战，不在于模型是否足够“大”，而在于：

• 自然语言表达是否模糊（例如“订单总量是多少”可能有多种理解）

• 数据库结构是否复杂、是否包含大量无关表/列

• 字段命名是否清晰，是否有中文注释、是否包含样例数据

这些问题，很多时候靠“更大的模型”并不能直接解决。

先说结论， 来自工程实践中的关键启发

模型并不是越大越好，Qwen Coder 3B/7B 已足够胜任任务

我们尝试了多个模型：

• Qwen 1.7B：参数过小小导致代码生成能力弱

• Qwen2.5 Coder 3B & 7B：专为代码/SQL 任务设计，结果优秀，微调后准确率达到 0.81 Execution Accuracy

这个结果已经超过了同等结构的 SOTA 方法（如 RoBERTa + T5-3B 组合），而且显著减少了部署成本。

✅ 结论：使用精调后的中型模型（3B-7B）已能解决大部分真实 SQL 生成任务。

Schema Linking 比模型大小更关键

很多真实数据库（如金盘数据库）存在如下问题：

• 字段名不可读（如 VBELN, ZZHYYH）

• 字段之间没有明确注释

• 多张表字段重复，关联复杂

这时候，如果不先过滤 schema，大模型也会“幻觉”严重，因为注意力被不相关字段稀释。

我们尝试了：

• 简单 DIN-SQL 式的 Schema Linking [1](https://arxiv.org/abs/2304.11015)

• 强化版 RESDSQL 交叉编码器 + 列增强层 [2](https://arxiv.org/abs/2302.05965)

效果立竿见影，准确率从 0.44 → 0.81，说明大模型“理解错误”更多是输入结构的问题。

✅ 结论：场景理解靠结构优化（如 schema linking），而不是盲目加参数。

训练样本设计、注释、示例数据远比模型大小重要

在对金盘等工业数据库做训练时，我们发现：

• 表/列名没信息，靠注释

• 不提供字段值样例，模型不知字段用途

• 用户问题表达差异大，golden SQL 却一样

我们通过：

• 引入字段注释

• 注入字段样例

• 打乱 schema 顺序增强泛化

• 构造不同表达相同 SQL 的样本

在没有换更大模型的前提下，准确率显著提升。

✅ 结论：训练数据质量和构造方式决定了最终效果。

“大模型 + 幻觉 + JOIN 滥用”反而是风险

在没有 schema linking 的情况下，大模型非常容易：

• 随意 JOIN 多张表

• 忽略限制条件（distinct、只返回某一列）

• 理解模糊表达错误，生成语义不符的 SQL

反而小一点、结构清晰的模型，表现更稳定可靠。

回到问题：搭建 NL2SQL 系统需要大模型吗？

结论是：

❌ 不需要 SOTA 级别的大模型（70B+）才能做好 NL2SQL。 ✅ 需要的是：

• 良好的 schema linking 策略

• 高质量的训练样本

• 合理的 prompt 设计与数据增强

• 中等规模、代码能力强的模型（如 Qwen2.5 Coder 3B/7B）

展望

未来的 NL2SQL 系统，更像是一个结构化的“智能 Agent”：

• 能理解用户问题意图

• 能快速筛选 schema

• 能学习约束和偏好

• 能精准生成 SQL 并自我验证

而不是一个越大越好的“语言模型”。如果你也在搭建自己的 NL2SQL 系统，不妨先别上来就调用 GPT-4 或 GPT-4o，先试试把 schema 理清楚，再加点样例数据，然后用一个 3B 模型看看效果——说不定，已经足够用了。

​