“把数据库接给大模型，业务同学自己查数就行了”——这是今年最容易被高管拍板的方案，也是最容易在第三个月悄悄下线的一个。我们帮三家中型公司搭过 text-to-SQL 分析系统，三家里有两家在半年内退回了”提需求给数据团队”的老路，只剩一家还在用，而且只敢给看三个固定看板。
这篇是这三个项目的复盘：420 次真实提问的准确率、成本，以及一个反直觉的结论——text-to-SQL 的失败几乎从不在 SQL 语法里，而在业务语义的歧义里。
一、先定义什么叫”查对了”
NL2SQL 类项目最容易骗自己的地方，是把”SQL 能执行”当成”答案正确”。我们定的验收标准是三层，一层比一层严：
- 第一层，可执行：生成的 SQL 无语法错误、表和字段都存在。
- 第二层，口径对：用的表、过滤条件、时间范围、聚合方式符合数据仓库的规范定义。
- 第三层，答案对：执行结果和数据团队的正确答案一致（精确匹配或容差内）。
三家里，模型第一层的通过率都在 96% 以上——现在的大模型写 SQL 语法几乎没有问题。但第二层普遍只有 60% 出头，第三层掉到 45%–58%。从”能跑”到”对”，中间隔着整个业务口径。
我们用一个典型例子说明落差：业务同学问”上个月卖得最好的品类是哪个“。SQL 能跑，结果也返回一行。但这个问题的正确口径有至少四个歧义点：
- “卖得最好”指 GMV、订单数、件数还是毛利？四个口径的冠军品类经常不是同一个。
- “上个月”按自然月、近 30 天、还是财务月（25 日关账）？
- 是否包含退款单、内部测试单、赠品单？
- “品类”取叶子类目还是二级类目？
模型不会问，它会猜。而猜错的那个答案，业务同学自己是看不出来的——数字看着很合理，格式很规整，来源也标着一个数据库。这是 text-to-SQL 最危险的地方：错得静默，错得体面。
二、420 次真实提问的错因分布
我们让三家公司的业务同学连续两周真正常用，一共 420 次提问，逐条人工核对。错因分布如下：
| 失败层级 | 占比 | 典型表现 | 业务可自发觉 |
|---|---|---|---|
| SQL 语法 / 字段不存在 | 4.3% | 拼错字段、用错函数方言 | 能（报错） |
| 关联表选择错误 | 11.2% | 多路径关联时选错桥表，结果重复计算 | 不能 |
| 口径歧义猜错 | 38.6% | “卖得最好”按件数算、时间按自然月算 | 不能 |
| 时间语义误解 | 19.4% | “最近”理解成 7 天、用户想 30 天 | 不能 |
| 指标定义过时 | 13.7% | 用了仓库里已被废弃的旧指标表 | 不能 |
| 结果解读误导 | 12.8% | 数字对，但用户据此外推了错误结论 | 不能 |
只有 4.3% 是模型能力问题，剩下 95.7% 是信息不对称问题。模型缺的不是 SQL 能力，是”这家公司的 GMV 到底怎么定义”这类上下文。而这件事，公司内部的人也经常答不全——我们见过同一个指标在三个看板里有三个版本。
第三层通过率的最终成绩：
| 公司 | 库表规模 | 是否建指标层 | 420 问中第三层正确率 | 半年后状态 |
|---|---|---|---|---|
| A 公司 | 1800 表 | 无 | 45.2% | 已下线 |
| B 公司 | 600 表 | 部分（仅 12 个常用指标） | 58.1% | 限三个看板使用 |
| C 公司 | 450 表 | 完整（含口径文档） | 71.3% | 仍在用 |
三家的模型能力差别不大，甚至 A 公司用的模型更新。决定成败的是指标层的完整度，以及你敢开放多少表。
三、把正确率做上去的四个动作
1. 建”指标语义层”，而不是把全库 schema 塞进去。我们把 warehouse 里反复被查的 60 个指标，逐个写成包含”计算逻辑、时间口径、过滤条件、同义词、常见误用”的语义卡片，作为检索上下文注入。这一步单独把口径歧义错误从 38.6% 压到 14% 左右，是单项收益最大的改造。
2. 表范围做白名单，默认只开 30 张表。A 公司图省事开了全库 1800 张表，结果模型在大量相似的历史备份表里迷路。B 和 C 都做了白名单，且对”财务月””退款”这类高危口径表，要求模型强制引用语义卡而非自行推断。开放度和正确率在这里是负相关的，必须承认。
3. 强制”先反问再执行”。但凡检测到问题里有歧义信号（”最好””最近””大概””大概多少”这类词），系统不生成 SQL，先列出歧义选项让用户点选。这个交互加上以后，虽然多了一步点击，但口径歧义类错误降到 5% 以下。用户宁愿多点一次，也不想拿一个错数字去开会。
4. 答案必须带”口径回放”。每张结果表下方固定展示三行：用了哪几张表、时间范围怎么切的、指标定义是哪张语义卡。不让用户验算 SQL，让用户验算口径。这一条把”业务不可自发觉”的错误捞回来相当一部分——C 公司靠它把真实发现的错误率拉高一倍，那些原本会静静错下去的查询被拦下了。
四、成本账
| 项目 | A 公司（全库开放） | C 公司（白名单+语义层） |
|---|---|---|
| 平均单次 token 数 | 约 21,000 | 约 6,400 |
| 单次查询模型成本 | 约 0.31 元 | 约 0.09 元 |
| 月查询量 | 约 3,200 次 | 约 4,100 次 |
| 正确查询的月成本 | 约 2,190 元 | 约 515 元 |
| 数据团队返工工时/月 | 约 55 小时 | 约 19 小时 |
“开放更多”既没换来更多正确，也没换来更省钱，只是换来更多返工。语义层让 token 消耗降了七成——这是最容易被忽略的收益：精准的少量上下文，胜过海量的全量 schema。
五、落地建议
- 先盘点指标口径，再谈接数据库。如果公司自己都答不全”GMV 怎么算”，这个项目不要开。三家里最成功的那家，启动前花了一个半月写指标卡。
- 从”高频、单一指标、时间维度”的场景切，不要从开放问答切。比如”某品类近 30 天销量趋势”，口径固定，成功率能到 90% 以上。
- 歧义反问是必做交互，不是可选优化。
- 结果页常驻口径回放，这是错误能被发现的唯一机制。
- 别把 text-to-SQL 当”取数自助化”，当”指标查询的语义缓存器”——它加速的是重复的、口径明确的问题，而不是开放式探索。
总结
420 次提问的结论可以压成三句话：模型的 SQL 能力早就够用了，瓶颈在业务语义；开放度和正确率是负相关的，白名单不是保守是必须；静默错误比显式错误危险十倍，因为它会进会议纪要。
更重要的认知：text-to-SQL 项目本质上是一个”知识管理项目”，不是”技术接入项目”。它的成本大头不在模型调用，在把散落在各处的口径定义收敛成机器可读的语义层。这个工作没有捷径，而它一旦做完，收益是持续的。
最后一个判断：两年内”直接问数据库”会退居次要位置，主流形态会是”问指标层 + 少量权限内的下钻”。完全的自然语言到 SQL 只适合口径极其简单的小型库，中大型数据仓库一定会回归到受控的语义接口——不是因为模型不行，是因为组织不行。
互动提问：你们公司的”上个月卖得最好的品类”，数据团队、财务、运营三个部门给出的答案是一致的吗？如果三个部门给三个答案，text-to-SQL 该怎么判分？
互动提问：有没有人在生产环境真跑过 text-to-SQL？最常遇到的是报错型失败，还是那种”看着很合理但错了”的静默失败？
— IMAI 编辑部 | 2026-10-29