Text-to-SQL 进企业，准确率只剩 25%：语义层为什么是必选项

引言：从 90% 到 25% 的断崖

2024 年，GPT-4o 在经典 Text-to-SQL 基准 Spider 1.0 上交出 86.6% 的执行准确率。这个数字足够漂亮，几乎让业界相信「自然语言取代 SQL」只是时间问题。

两年后，同样的模型在 Spider 2.0 的企业级真实工作流测试中，分数骤降至 10.1%。

这不是模型变弱了——是数据库变「真实」了。Spider 2.0 的数据库动辄上千列、多方言混用、单条 SQL 超过 100 行，考察的不再是「写对一条查询」，而是「在复杂业务语境下完成一次工程级的数据探索」。

2026 年 8 月，arXiv 上出现了一篇更扎眼的论文。Bruno Santos Teixeira 提出的 SemPlan Benchmark（arXiv:2608.13612）用 1,800 个合成案例测试了四种企业级 NL2SQL 架构。结果四种方案的正确率全部落在 22.25% 到 25.67% 之间——没有一个超过四分之一。

换句话说，你把市面上最先进的 Text-to-SQL 系统直接接进企业数据库，每问四个问题，大概只有一个是答对的。而且答错的那三个，往往长得跟正确答案一模一样。

企业数据库为什么让 LLM「失忆」？

学术基准与企业生产环境之间，隔着三道几乎无法靠「更大模型」跨越的鸿沟。

1. Schema 爆炸：上下文装不下

Spider 1.0 的数据库平均 6.8 张表、72.5 列。而 BEAVER 项目采集的真实企业仓库平均 101.5 张表、869.4 列。

当你把近万张字段定义塞进 LLM 的上下文窗口，模型注意力被稀释到近乎随机。研究表明，即便给模型「oracle schema-linking」标注（人工告诉它该用哪张表），准确率也只能从 11.4% 提升到 18.9%。问题不在推理能力，而在信息过载。

2. 隐式关系：LLM 读不懂「行业黑话」

真实企业的表名往往长这样：t_cust_ord_dtl_2024_q3。字段 amt 在某些表里是「含税金额」，在另一些表里是「退款净额」——而两者差了整整一个税率口径。

没有显式文档，LLM 只能根据命名「猜测」。一篇 2026 年 4 月发表于 arXiv 的误差分析（4,602 条错误查询）指出：81% 的失败属于 schema 与语义错误——选错列、连错表、误解业务含义。语法错误反而是少数。

3. 安全与口径：沉默的致命错误

Text-to-SQL 最可怕的不是报错，而是「安静地算错」。一位工程师在 35 表的生产环境 Shape 数据库上实测发现：一个 naive 查询漏掉了去重步骤，把收入放大了 76%，输出结果看起来完全合理，直到懂业务的人复核才发现。

更糟的是权限。如果 AI 通过一个拥有 broad read 权限的服务账号访问仓库，它完全可能在回答「本月新增客户」时，把包含个人隐私的完整联系人列表一并吐出来。

dbt Labs 的对照实验：语义层能把准确率拉回 100%

好消息是，这个问题有解——而且解不在模型本身，而在模型与数据之间的那层「翻译器」。

2026 年 4 月，dbt Labs 发布了一份可复现的基准测试。他们在 ACME Insurance 的 15 张表、11 个业务问题上，对比了纯 Text-to-SQL 与经过语义层建模后的表现，每题跑 20 次：

同一批模型、同一批问题、同一个数据库。唯一的变量，是有没有语义层。

dbt Labs 还在测试前做了一组交叉验证：4 个前沿模型 × 多档推理强度（从 low 到 max）。结果显示，语义层路径上多数组合达到 100%；而纯 Text-to-SQL 成绩在 50%-65% 之间来回晃——推理预算加得再多，准确率也不涨。

关键结论写得很直白：把预算花在推理 token 上，回报接近于零；花在语义建模上，回报是三四十个百分点。

dbt Labs 特别指出一个被 vendor 普遍回避的数据点：在语义层未覆盖的多跳复杂问题上，语义层得分 0%（因为它选择拒绝），而纯 Text-to-SQL 还能蒙对 70%-100%。

这不是语义层的缺陷——恰恰是它的设计意图：在能力边界内给出可信答案，在边界外大声说「我不会」，而不是安静地编造一个数字。

OntiCards 的解法：数据卡片即语义层

语义层的价值已经被验证，但对大多数中国企业来说，建设语义层是个头疼的问题：谁写文档？怎么保证文档跟得上业务变化？口径不一致怎么办？

OntiCards 的做法是：让 AI 自动生成语义层初稿，再由业务专家校准。

在我们的架构中，这层语义能力被封装为数据卡片（Data Card）——每张卡片对应一份数据源，包含六个核心要素：

• 数据源基础信息：归属空间、来源系统、更新频率

• 字段语义说明书：每个字段的业务含义、枚举值、口径定义

• 数据质量标签：完整率、准确率、异常特征

• 权限与脱敏规则：谁可读、哪些字段需脱敏

• 业务场景标签：该数据适用于哪些分析场景

• 寻址查询规则：如何查询、关联哪些数据源

当用户用自然语言提问时，系统不会直接把问题扔给 LLM 写 SQL。而是先查阅数据卡片，锁定相关数据源、明确字段口径、检查权限边界，再生成查询。整个过程由数据卡片体系驱动，而非裸模型猜测。

这与 dbt Labs 的语义层理念完全同向，但实施路径更轻量：不需要数据团队先花三个月写 dbt 模型，而是 AI 在接入数据源的当天就生成初版卡片，FDE 工程师在后续迭代中持续校准语义。边上线、边建模、边生长。

在电商场景数据质检实操中，这种「卡片驱动」的 NL2SQL 已能稳定处理跨表 JOIN、时间窗口、聚合口径变换等复杂查询。因为系统知道「销售额」在订单表里是 net_revenue，在退款表里要扣掉 refund_amount，而不是让 LLM 去猜。

给技术负责人的一张检查清单

如果你正在评估企业级的自然语言问数方案，建议用下面这五个问题过滤供应商：

1. Schema 超过 50 张表时，系统如何保证链路稳定？ 靠堆上下文窗口的，production 必崩。

1. 模型的失败模式是「报错」还是「安静算错」？ 后者比前者危险十倍。

1. 语义层由谁维护？ 纯人工写文档不可持续，纯 AI 生成不可信任，人机协作才是正解。

1. 同一业务指标，问三遍是否得到同一答案？ 口径一致性是底线。

1. 超出覆盖范围的问题，系统是拒绝还是瞎编？ 会拒绝的系统才值得信任。

写在最后

Text-to-SQL 不是伪需求。业务人员用自然语言问数，是数据民主化的正确方向。但「裸模型直接写 SQL」这条路，在企业环境里已经被多项独立研究证伪。

模型能力在飞速进步，但企业数据的复杂度增长得更快。决定答案对不对的，不是模型参数有多大，而是模型是否拿到了一张准确的「企业数据导航地图」。

语义层——无论叫 Semantic Layer、数据卡片，还是业务口径库——就是这张地图。没有它，再强的 LLM 也只是个在陌生城市里没有导航的司机。

参考来源

• Bruno Santos Teixeira, SemPlan: Benchmarking Structured Semantic Planning for LLM-Based Queries over Enterprise Data, arXiv:2608.13612, 2026-08-12. https://arxiv.org/abs/2608.13612

• dbt Labs, Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update, 2026-04-07. 详见 Atlan 转载分析：https://atlan.com/know/ai-agent/data-for-ai/text-to-sql-for-enterprise/

• Text-to-SQL Explained: Why It Fails in Production and How to Fix It, Solution Gigs, 2026. https://solutiongigs.in/blog/text-to-sql

• The Semantic Layer: An Operator's Guide to AI Answers You Can Defend, Nufar Gaspar, 2026. https://nufargaspar.com/writing/semantic-layer-operators-guide

• Why Text-to-SQL Fails in the Enterprise, bits-bytes-nn, 2026-07. https://bits-bytes-nn.github.io/insights/data-architecture/2026/07/27/ai-ready-data-semantic-layer-knowledge-graph-en.html

• 语义层不是文档，是编译器, 夜雨聆风, 2026. https://www.yeyulingfeng.com/a/921179.html