厂商告诉你，他们的 Text-to-SQL 系统「准确率 95%」。支撑这个数字的论文说的也是 95%。系统上线后，财务经理问「剔除内部交易后的净销售额」，SQL 自信满满地错了。厂商和论文都没撒谎——撒谎的是那个前提：那个数据集，长得和您的数仓一点也不像。
公开基准到底在测什么
每家厂商的 PPT 上都是那两个基准。搞清楚它们测什么、不测什么，是正确解读 Text-to-SQL 宣传口径的最快途径。
Spider（2018，耶鲁大学）是被引用最多的。约 10,000 个问题、200 张表、138 个领域，且查询设计成从表结构即可回答。它的继任者 Spider 2.0（2024）发布的原因很直白：原版已经被「做穿了」——模型在 Spider 1.0 上超过 90%，而包含真实企业 SQL 方言、超长上下文和多步分析的 Spider 2.0，最强系统初期得分不到 25%。版本之间这个断崖，是全领域最有教育意义的一个数据点。
BIRD（2023）的构建初衷正是弥合学术查询与混乱现实之间的差距：更大的数据库、真实数据值、需要外部知识或领域推理的问题，由香港的学术团队构建。它把 2023 年的榜单重置到 50–60% 区间；到 2025–2026 年，头部系统借提示词工程管线和微调开源模型，已把执行准确率推到 70–80% 以上。
两者都是严肃、精心构建的数据集。它们能证明的，诚实地总结如下：
| 维度 | Spider 1.0（2018） | Spider 2.0（2024） | BIRD（2023） | 典型企业数仓 |
|---|---|---|---|---|
| 表结构规模 | 5–40 张表 | 数百张 | 数十至数百张 | 300–1,000+ 张 |
| 表结构卫生度 | 干净、有文档、单领域 | 真实方言、长上下文 | 真实值、少量噪声 | 十年累积的命名、三种并存的币种 |
| 问题风格 | 自包含、无歧义 | 多步骤、需探索 | 需领域知识 | 需要内部黑话解码 |
| 数据归属 | 公开、静态 | 公开、静态 | 公开、静态 | 私有、变动、有权限 |
| 最优模型准确率（2025–2026，约值） | 90%+ | 约 40–60%，持续爬升 | 70–80%+ | 无人公开；从业者反馈 60–90%，取决于治理 |
最后一行才是重点。不存在针对您数仓的公开基准，而公开分数的可迁移性，每向企业现实靠近一步就衰减一分。
基准没有告诉您的五件事
一、表结构的脏乱差
基准随附的表结构干净又体面。您的数仓里有一张叫 tbl_sal_sum_v3_final 的表，和一个叫 amt 的字段——含义在 2021 年变过。同一位客户因为 CRM 迁移存在四个主键下；收入按三种币种入账且没有统一的换算日期；缓慢变化维让「截至去年三月」成为一个真正有难度的问题。现实中 Text-to-SQL 的准确率，不取决于模型的 SQL 功力，而取决于系统能在多大程度上与这些脏乱差隔离开。每个严肃的部署，投在模型周围那几层——精选表集、经过测试的指标定义——的精力，都超过投在模型本身的。
二、业务黑话
基准问题是由看得见表结构的人写的。您的业务用户问的是「剔除已取消未发货订单的 GMV」「华南大区」（而在您的组织树里，自 2023 年组织调整后华南大区对应的门店每年都不同）、「活跃经销商」——这个术语有三种互相打架的定义，从未对齐。模型不可能从表结构文档里把这套词汇映射到字段上，因为映射根本不在表结构里。它在机构记忆里——通常只存在三个分析师的脑子里。一个没学过您家黑话的 NL-to-SQL 系统，不是「略有降级」，而是「在回答另一个问题」。
三、权限与可见性
基准只有一个隐含用户：全知全能。而企业里有不该看到其他门店的店长、有 cleared 给总账但看不到 HR 表的财务分析师、有上季度刚调整过管辖范围的区域总监。生产环境的查询生成不是「对着数仓写 SQL」，而是「对着这个身份、此刻可见的那一片数仓写 SQL」。这是一个本质不同的问题——一半是 SQL 生成，一半是执行时的访问控制——公开基准对此完全不设考题。一个无视权限、得分 85% 的系统，在企业里不是 85% 准确；它是一条包装精美的数据泄漏通道。
四、错误的代价不对称
在基准上，一条错误查询扣一分。在董事会上，一个错误数字赔上的是信任——以及（按高管的真实行为模式）整个分析项目。错误也分轻重：一个幻觉 JOIN 静默把收入翻倍统计，比一句优雅的「答不了」糟糕得多，但执行准确率评分把两者记成同一种失败。因此生产系统需要校准过的置信度、拒答行为和可回溯源行的引用链——这些统统不出现在基准评分里。
五、语义漂移
数仓在系统脚下变化：表被改名、指标定义被修订、源系统被迁移。基准是冻结的，您的表结构不是。系统需要持续运行的回归评测，而不是一次性认证。这是最少被讨论、却在运维上最重要的鸿沟：准确率不是系统的属性，而是系统在某个时点、面对某个特定表结构的属性。
为什么「裸 LLM 写 SQL」是错误的架构
上述失败模式解释了一件事：2023 年演示效果惊艳的「把前沿模型直接怼到表结构上」的做法，到 2025 年已经不再是被推荐的架构。裸 LLM SQL 要求模型同时干四份活——理解业务语言、探索表结构、记住指标定义、写出方言正确的 SQL——并且对每一份活都给出与其把握不成比例的自信。
生产系统收敛出的替代架构，是把问题拆开：
- 语义层。 业务术语与物理表结构之间的受治理映射——指标定义、维度惯例、黑话别名——把模型任务从「发现表结构」降级为「基于已知定义组装受治理查询」。在我们的部署中，这是最大的单一准确率杠杆，在真实企业表结构上通常值 15–25 个百分点的可用回答率（我们自己的测量，与从业者公开反馈的方向一致）。
- 相关表结构的检索。 不把 400 张表塞进上下文，而是按问题检索相关的 10–20 张表及其文档。上下文更小，幻觉 JOIN 更少。
- 查询治理。 执行时强制绑定身份的行级、列级安全，查询日志、成本控制、只读强制。这一层不提升准确率；它让准确率可以安全地被使用。
- 评测体系。 一套私有评测集——100–300 道来自真实业务、带验证答案、覆盖您家黑话和表结构怪癖的问题——在每次模型、提示词或表结构变更后运行。这才是真正重要的基准，而且没有人能替您建。
经济学论证和技术论证同样有力。前沿模型的 token 成本已大幅下降（斯坦福 AI Index，2025），开源权重模型在多数 SQL 生成负载上达到同等水平——单次查询的边际成本持续下探。不会下降的，是一个被决策者信任的错误数字的代价。因此架构应该把复杂度预算花在拦截和预防错误的层上，而不是花在从模型身上挤最后几分准确率上。
应该向厂商索要哪些准确率数字
当厂商报出一个数字时，正确的反应不是争论数字本身，而是问五个把它转化为信息的问题：
- 在什么数据集上？ 2026 年，Spider 1.0 的分数已无意义——90%+ 只是及格线，不是差异化。BIRD 或 Spider 2.0 的分数信息量更大；追问版本和测试日期。
- 执行准确率还是完全匹配？对照的基准答案如何验证？ 执行准确率可能「错得碰巧对」；完全匹配会把格式不同但正确的查询判错。要问清基准答案是怎么验证的。
- 歧义问题怎么算？ 如果模型把「销售额」解成 GMV，而分析师指的是净收入，这算失败吗？成熟厂商会把拒答和澄清单独计数，与错误分开报告。
- 权限如何执行、如何测试？ 问清楚行级安全是否对每一次查询在执行时强制生效，他们的评测里有没有权限越界测试。如果评测只测 SQL 正确性，您买到的其实是一条未经审计的数仓访问路径。
- 愿不愿意在我们的数据上打分？ 唯一能预测您部署效果的基准，是从您的问题和表结构里建出来的评测集。对语义层路线有信心的厂商，会同意在结构化试点里用固定题集、公开打分——付费试点（我们的是两周、HKD 25k / RMB 20k）正是干这个用的。拒绝在您数据上打分的厂商，本身就是在告诉您答案。
按我们的部署经验和从业者反馈交叉印证，在治理良好的前提下、面对脏乱的真实企业表结构，合理预期是：精选语义范围内 85–95% 的可用回答率，对范围外的问题选择拒答而不是幻觉——而且这个拒答行为，反直觉地，恰恰是系统成熟的标志。承诺在无约束数仓上做到 99% 的人，是在向您承诺一场 Demo。
真正决定上线准确率的因素
汇总我们和其他团队的部署经验，准确率杠杆的排序非常稳定，而且在外行看来近乎无聊：
| 排名 | 杠杆 | 典型影响（估算，出自我们的部署） | 投入 |
|---|---|---|---|
| 1 | 覆盖业务核心表的语义层 | 可用回答率 +15–25 个百分点 | 数周；需要指标 owner |
| 2 | 基于真实黑话问题的私有评测集 | 不直接加分——让准确率显形，撬动其他一切杠杆 | 1–2 周搭建，持续维护 |
| 3 | 从查询日志持续维护的黑话/别名词典 | 长期 +5–15 个百分点 | 持续，成本低 |
| 4 | 表结构治理（视图、文档、下线旧表） | +5–10 个百分点，复利式 | 持续，与 BI 团队共担 |
| 5 | 模型选择（前沿 vs 开源、提示词调优） | ±5 个百分点 | 季度复评 |
注意排名在最后的是什么：一切与模型有关的东西。这是 2025–2026 年部署的一致发现，也与基准文献自己的诊断吻合——Spider 2.0 的作者把低分更多归因于「在不熟悉的真实环境中探索和推理」的困难，而不是 SQL 本身写不出来。模型已经不是瓶颈；上下文和治理才是。
还有两条组织层面的观察值得补充。其一，上面每一个杠杆都需要具名责任人：语义层要有指标 owner，黑话词典要有分析师从查询日志里持续维护，表结构文档要有 BI 工程师负责。Text-to-SQL 准确率衰减，往往不是因为系统坏了，而是因为没有人对系统所编码的定义负责。其二，评测集会实实在在地改善分析职能的内部政治：当准确率每周在真实问题上打分，关于「AI 回答能不能信」的争论，就变成了「第 37 题为什么错了、怎么修」的具体工程讨论——这是健康的对话，而不是弥散的焦虑。公布分数的企业赢得信任；隐藏分数的企业收获小道消息。
对 IM 时代对话式 BI 的启示
最后一块拼图：Text-to-SQL 准确率在当下不是更不重要了，而是更重要了，因为交付面变了。当分析长在企业微信、钉钉、飞书、WhatsApp 或 Teams 里，一个错误答案不再是给一位能自查的分析师看——而是瞬间被整个群聊看到，还盖着您公司的名字。IM 原生交付同时抬高了准确率门槛和失败行为的要求（拒答、引用、转人工）。
这就是为什么把准确率当模型问题的对话式 BI 厂商会持续让人失望，而把它当治理问题的厂商——语义层、权限、评测、引用——其系统才能在企业里活得下去。评估 IM 原生分析平台时，Text-to-SQL 准确率这个问题本身是成立的，但正确的问法是：「在像我们这样的数据、并执行我们权限的前提下，你们的实测准确率是多少？系统对答不了的问题会怎么处理？」
这个问题的健康答案可度量、朴素、且有架构背书。不健康的答案是一张榜单截图。
给 CIO 的一页评估清单
2026 年评估 Text-to-SQL 宣传口径，压缩成一张实操清单：
- Spider 1.0 分数直接忽略。 要 BIRD 或 Spider 2.0 结果（附日期），或与您类似的表结构上的分数。
- 要求具备拒答行为。 对超纲问题，系统必须回答「受治理数据范围内答不了」——用陷阱问题显式测试。
- 对抗性测试权限。 试点期间安排低权限用户想办法问出受限数据。任何一次得手即一票否决。
- 检查引用链。 每个数字都应能回溯到源行，与数仓核对。
- 评测集建在试点之前，不是之后。 100–200 道带验证答案的真实问题，向您的黑话倾斜。每周打分，内部公布。
- 测试表结构变更的应对。 试点中途给一张表改名，看会发生什么——答案会告诉您系统背后是治理层，还是仅仅一段提示词。
- 为无聊的层做预算。 如果报价单上的科目全是模型相关的，而没有语义层和评测的科目，90 天后的准确率曲线会让您失望。
2026 年对 Text-to-SQL 的成熟立场，既不是怀疑也不是狂热。这项能力是真实的，而且在快速进步——基准文献记录了货真价实的进展。但上线准确率是造出来的，不是买来的：它来自编码了术语含义的语义层、决定每个身份能看什么的权限、每周向您说真话的评测集，以及一个把拒答做成工程能力而非尴尬的交付面。能向您展示这四样东西的厂商，值得您的试点；只会展示榜单截图的厂商，值得您的怀疑。
