第一次被老板问「能不能直接用中文查数」时，团队里通常会同时冒出三个答案：自己写一套 NL2SQL、装一个开源项目、买 BI 厂商的问数插件。三条路线在演示阶段几乎都能跑通，撑到生产环境却各有一处会失控的地方——多数时候不是模型，而是指标口径和字段权限。
这篇不判断「哪个最好」，只讲三件事：三条路线的钱实际花在哪、决策时该盯哪四个指标、以及一套能写进合同的验收方法。文中涉及别家产品的能力与计费，只引用其官方文档原文并标注出处；我们不填任何厂商报价，价格一律以对方官网当期计费文档为准。
一、先把三种产品形态分开：它们解决的不是同一个问题
「智能问数」在采购语境里已经被混成一个词，底下至少有三类实现，能力边界差别很大。选错形态，后面所有的报价比较都失去意义。
- 自然语言查询（NL2SQL）：把问题直接翻成 SQL 打到底层库。解决临时、一次性、探索式的查数需求；不解决同名指标在不同报表里算法不同的冲突。
- 指标语义层问答：先定义指标（口径、维度、过滤条件），再把问题映射到已定义的指标上。解决口径统一与结果可追溯；代价是没定义过的问题答不出来，需要专人维护指标资产。
- BI 工具或云厂商内置的问数 Agent：在已有报表体系上加一个对话入口。解决「报表太多、找不到、不会筛」的使用问题；不解决跨源、跨系统的口径统一。
我们在数据类交付里会把这条界线先跟甲方讲明白：买回来的是一个入口，不是口径。口径仍要由甲方数据负责人签字确认，这件事没有任何厂商能替代。
顺便说一句，凡是「自研 / 买 SaaS / 外包」的路线题，成本算法都有共同结构，站内另一篇《企业 AI 应用开发怎么选：自研、SaaS、外包三条路线成本账》已经把通用框架算过一遍，这里只讲问数场景特有的部分。
二、三条路线的钱分别花在哪
下表把四条可选路径的首年支出结构摆在一起。注意「最容易被低估的一项」这一列——预算超支基本都发生在这里，而不是许可费。
| 路线 | 首年主要现金支出 | 人力集中在哪 | 最容易被低估的一项 |
|---|---|---|---|
| 买 BI / 云厂商的问数插件 | 许可或席位、模块增购（价格以官网为准） | 把已有指标接进插件、做主题域映射 | 口径不一致时的回溯与返工 |
| 开源自建（如 SQLBot） | 服务器与推理算力、私有化部署 | 环境落地、术语与 SQL 示例维护、权限配置 | 版本能力差异（审计、提示词等是否在企业版） |
| 指标平台型厂商方案 | 平台许可 + 实施服务 | 指标资产梳理、口径评审 | 甲方配合确认口径的周期 |
| 完全自研 | 研发人力（占比最高） | 取数链路、评测集、兜底策略 | 长期维护与模型、依赖的持续迭代 |
开源自建：公开样本能查到哪些事实
自建这条路上最好比对的公开样本是飞致云的 SQLBot。官方文档的定义是「SQLBot 是一款基于大语言模型（LLM）和 RAG（检索增强生成）的智能问数系统」，用户用自然语言提问即可拿到数据答案、SQL 语句与可视化图表，并可借助工作空间实现资源隔离与细粒度数据权限（来源：飞致云文档中心 SQLBot 首页）。
这三点恰好对应自建最耗人力的三件事：取数链路、权限、口径。文档还给到 Web 嵌入、弹窗嵌入与 MCP 调用三种接入方式，意味着它能被塞进已有的管理后台或智能体平台里，不必另开一个门户——这部分省下来的是前端工时，不是模型成本。
但读文档要读结构，不能只读宣传段。飞致云把「自定义提示词」和「操作日志」列在「企业版功能」下，而「术语配置」「SQL 示例库」「权限配置」「工作空间」属于操作指南章节，另有「业务上下文配置能力」与「四步调优提升 NL-to-SQL 准确率」两节（同页目录）。这句话的实际含义是：开源版本能跑通问数与嵌入，但审计留痕、提示词定制要不要额外授权，签约前必须让实施方书面确认版本功能矩阵。
开源不等于零成本，它把成本从许可费换成了人。仓库地址在 github.com/dataease/SQLBot，项目自述的定位正是「基于大模型和 RAG 的智能问数系统，对话式数据分析神器。Text-to-SQL Generation via LLMs using RAG」。
云厂商与 BI 侧：先用免费环境做压力测试
云厂商这条线有一个被浪费得最厉害的资源：免费体验环境。阿里云帮助中心提供了一份无需购买资源的 ChatBI on DMS 体验入口（来源：阿里云 DMS 帮助文档）。
该帮助文档写明「由于体验涉及到的资源不归属于您，因此不会产生任何费用」。体验环境的预置数据集包括 nation、region、part、supplier、partsupp、customer、orders、lineitem，覆盖供应商、订单明细这类多表结构，正好用来出多表关联题。
这类环境的价值不在「好不好用」，而在于它是一个零成本的压力测试靶子：把你自己那 20 道高频问题打进去，看它在哪里翻车，比对着宣传页猜有效得多。至于 BI 厂商的问数插件按什么方式计费，各家口径随版本变化，必须以官网当期计费文档为准，我们不在这里填数字。
三、决策只看四个硬指标
对比清单可以很长，但真正决定上线后会不会被业务方骂的，就是下面四条。它们都能在选型阶段用两小时验证，不需要等上线。
1. 同名指标口径冲突怎么解
同一个「活跃客户」，财务按开票口径、运营按下单口径、销售按回款口径，三个数字天生不同。问数系统如果没有指标字典或术语配置层，只能每次让模型猜，猜出来的数字越像样越危险。
验证方法很直接：拿三个部门各自的口径问同一个问题，看系统是否会返回同一个数字、是否会提示「该指标存在多版本口径」。答不出来的，就需要在方案里补一层语义层，而不是换更大的模型。
2. 字段级权限与执行审计
字段级权限和审计是这类项目最常被「先上线再说」的两项，也是最难补的两项。SQLBot 的公开文档把工作空间与细粒度数据权限放在核心特性里，说明开源方案在这一层是有设计的；但操作日志属企业版功能，这一条要在采购里单独确认。
这一层最难靠方案书判断，因为描述写得越抽象越像达标。更实用的做法是要一次带字段级权限和审计日志的真实系统演示：换一个低权限账号登录，看它是否真的看不到不该看的列，操作是否留下可查的记录。
3. 失败问题的兜底机制
更该问的是「答不出来时它怎么办」。合格的兜底不是硬编一条 SQL 交差，而是明确返回「未找到对应口径」并给出候选指标、同时把这次失败写进语料池供后续调优。
没有兜底设计的系统，在试点期表现往往更好——因为它什么题都敢答；而到了业务真正用它做决策时，一个看起来合理的错误数字比一句「查不到」贵得多。
4. 复杂多表关联下的准确率怎么验
阿里云文档把 ChatBI 的生成过程拆成三步：问题改写、问题分析及数据表选取、SQL 生成。这个拆法值得直接抄进验收表，因为每一步都是一个可拦截的校验点：改写阶段能不能识别歧义、选表阶段会不会漏掉必要的表、生成阶段有没有把口径写进条件里。
同一份文档还有一句更实用的信息：体验环境内置的问题类别涵盖「条件筛选、聚合排序、基础信息获取、多表关联」。如果连厂商的演示都只敢用单表题，验收时就该保持警惕——多表关联才是真实业务里最常见的形态。
四、验收：20—30 题基线集，按三项打分
- 锁题。找业务方要 20—30 个真实高频问题，按主题域分层（订单、库存、财务、人力），不要用厂商自带的问题集。
- 定格。每题写清期望口径：分子分母、时间窗、去重规则、数据源表。由甲方数据负责人签字，这一页纸后面会成为争议的仲裁依据。
- 跑双轨。同一题既跑系统、也跑人工写的标准 SQL，结果不一致时以人工为准，逐条记录偏差原因。
- 打三项分。口径一致率（数字与台账对得上）、SQL 可执行率（生成的语句能跑、不报错、不超时）、回答可追溯率（能回看到用了哪些表、哪些字段、哪条口径）。
- 划结论线。三项的合格线要在试点前由甲方数据负责人书面定下：三项都达到双方认可的水位再开放给试点用户；任何一项明显掉队，先修口径和权限，不要靠换模型解决。这条线属于我们的项目内控建议，具体取值由甲方按业务容错度确认，不是行业标准。
为什么不能只看「答得像不像」？因为语言层面像样的答案，可能把「活跃用户」按登录算而不是按下单算，数值差一个量级，句子读起来却完全正确。问数是给决策用的，验收就必须落在数字和口径上，而不是措辞上。
这套方法的价值在于可复跑：三个月后模型或口径变了，把同一批题再打一遍，就知道是变好还是变坏。POC 阶段的判断标准同理，站内一篇复盘 POC 为何常走不到生产环境的文章，讲的是同一套逻辑在更早阶段的版本。
五、什么情况下这笔钱先别花
有三类情况，问数系统的投入产出比会明显劣于先做数据治理。遇到其中任意两条，建议把预算挪到前面去。
- 指标口径本身混乱。同一个指标在三个系统里有三套算法，且无人能拍板哪套为准。此时问数系统只是把混乱放大到对话层。
- 源库权限开放不完整。只能给到几张宽表、真实明细拿不到，那么再准的 NL2SQL 也只能回答宽表能回答的问题。
- 没有专人维护语料与口径。术语配置、SQL 示例、同义词都需要有人持续维护。项目验收完就没人管的口径库，半年后一定退化。
说句实在话：智能问数的上限由数据治理水平决定，不由模型决定。模型换代很快，口径不会自动跟着换代。
如果你手上已经有 20—30 个高频问题清单和一份指标口径草表，可以带着这两样东西来聊——联系我们；也可以先看案例页里数据类项目的页面记录。
优码云总部在深圳福田，服务深圳、粤港澳大湾区与全国客户，深圳软件开发相关的交付采用双周迭代：每两周交一次可用增量，这类项目第一期通常只做基线集加一条主链路，跑通再扩主题域。外包形态的验收关卡可以对照《企业 AI 应用开发外包：报价、模式与验收关卡》那篇里的清单。想看同主题更多文章可以去博客首页，想了解我们的交付方式可以看关于优码云。
常见问题
智能问数系统到底多少钱？
费用由三块构成：许可或算力、部署与实施、口径治理的人力。第三块通常被漏算，却往往占比最高，因为它需要甲方数据负责人参与评审。我们不给具体报价，因为不同厂商的计费口径随版本变化，请以各自官网当期计费文档为准；评估时更实用的做法是拿 20—30 题基线集让候选方案各跑一遍，用偏差条数折算返工工时。
开源的 SQLBot 能直接给业务方用吗？
能跑通问数、图表与嵌入接入，公开文档写明支持工作空间隔离与细粒度数据权限。但「自定义提示词」「操作日志」列在企业版功能下，若审计留痕是硬要求，签约前必须确认版本授权范围；术语配置、SQL 示例库这些也需要有人持续维护，属于运营成本而非技术成本。
自研 NL2SQL 最小要几个人？
以我们的项目配置经验，这种活最小可行的是一个规模很小的固定小组：一名后端负责取数与权限、一名前端做对话与图表、一名兼评测与语料维护，再加甲方数据负责人确认口径；人数随并行主题域增加，不要一开始就压满编制。按双周迭代推进，第一期只交付一条主链路和基线集，不建议一次性铺满所有主题域。
要不要给问数系统开放数据库写权限？
不要。问数只需读权限，而且建议只读账号指向视图层而不是原始明细表：先在视图里固定口径与字段裁剪，再让模型生成 SQL，等于在数据侧做了一层兜底。生成语句应在受控环境执行并带超时与结果行数上限，防止一次大范围查询拖垮业务库。