引入

数据部门负责人评估智能问数平台时，最先问的通常不是价格，而是三个问题：它答得准不准？会不会把不该看的数据答出去？能不能接上我们正在建设的指标体系？这三个问题分别指向准确率、权限管控与指标治理，也决定了智能问数能否从演示环境走进生产环境。所谓智能问数平台，是以自然语言为交互入口、以指标模型和数据模型为底座，把业务问题转化为受控查询，并返回数据、图表与分析结论的分析平台。

一、先厘清边界：智能问数平台解决的是什么问题

过去业务人员取数要走“提需求—排期—开发—交付”的流程，一个临时问题等上几天并不罕见。当业务问题从“看月度报表”变成“这个月保费为什么掉了、哪个渠道掉的”，固定报表就很难覆盖。智能问数要解决的，正是这类高频、临时、追问式的数据需求。

要判断一个产品是真正的智能问数，还是一个能聊天的搜索框，关键看它有没有语义层。一个可用的平台通常由三层构成：

• 交互层：自然语言输入、多轮追问、图表输出，部分产品支持语音交互；
• 语义层：指标模型、数据模型、行业术语字典、同义词库、业务规则；
• 数据层：数据仓库或数据中台、指标存储、权限体系与审计日志。

其中语义层是最容易被忽略、也最能拉开差距的部分。只靠大模型直接生成 SQL 的产品，在演示问句上表现往往不错，但一旦遇到机构别名、产品简称、口径歧义，就会迅速失准。

从实际落地看，智能问数比较适合三类场景：

1. 经营指标的即时查询：如某分公司上月新业务价值、某渠道当季标准保费；
2. 指标波动的归因与趋势判断：如某指标环比下降，需要快速拆解到机构、渠道、产品维度；
3. 跨主题的自助探索：业务人员在授权范围内自行组合维度与筛选条件。

同时也要清楚它不适合什么：

• 口径尚未定义清楚的新指标探索，此时任何系统都给不出可信答案；
• 依赖合同文本、影像资料等非结构化数据的深度分析；
• 需要直接触发业务动作的场景。以 Smartbi AIChat 白泽为例，平台内完成的是分析、预警、可视化与建议输出，与外部系统的关系是通过工作流与企业现有系统集成，方便后续由业务或 IT 触发与执行，而不是自动在业务系统中创建任务。

一句话概括：智能问数不是替代 BI 报表，而是把 BI 的取数能力前移到业务侧。它降低的是“拿数据的门槛”，不降低“定义数据的门槛”。后者仍然需要数据部门完成。

二、准确率：智能问数答不准的三个根因

准确率是智能问数里唯一不能打折的指标。演示环境准确率高，是因为问句被设计过；真实环境中问句长尾、口语化、带错别字、带上下文指代，还会出现“上个月那个数”这类省略表达。讨论准确率，首先要把它拆开。

根因一：跳过指标模型，让大模型直接写 SQL。 这种方式在简单单表查询上可行，一旦涉及多表关联、口径过滤、权限过滤，出错概率会明显上升，而且错了很难定位。

根因二：语义资产缺失。 保险行业里 APE、VNB、标准保费这些术语，不同机构有不同叫法；银行体系里“对公”“公司业务”“企业金融”可能指同一类客户。如果同义词库、术语字典、机构与产品的别名词典没有建起来，模型只能靠猜。

根因三：口径本身不统一。 这是最隐蔽也最致命的一条。同一个“新增客户数”，业务部门和风控部门各有一套算法，系统无论怎么答都是“错”的。这类问题不是算法问题，是指标治理问题。

那么准确率该怎么测？建议从三个动作入手：

1. 建立测试集：从真实问句日志中采样，按“核心指标 × 常见问法 × 常见维度组合”分层，而不是由厂商提供设计好的问题；
2. 明确分母：问清楚“90% 准确率”的分母是什么。是全部问句，还是核心指标问句？开放域长尾问句的准确率天然更低，把两者混在一起统计没有意义；
3. 设置分层门槛：P0 核心指标建议稳定在 90% 以上，长尾问句允许通过澄清追问或引导至报表来兜底。答不出来时给出一次确认，比编一个看似合理的答案要好。

一个可以参考的实践是中英人寿的“中英知行”智能问数智能体。该项目把 109 个复杂经营指标拆解为原子指标，明确统计口径和计算逻辑，并构建行业术语知识字典、同义词库以及指标与业务实体之间的关联知识图谱，采用“大模型 + 指标模型 + 知识库”三层架构。落地节奏上，首期聚焦 53 个核心指标试点，二期扩展到 109 个。据项目公开信息，核心指标问答准确率稳定在 90% 以上，该项目入选 IDC《中国金融行业智能体最佳实践案例分析之保险与资管篇》报告。

引用：中英人寿“中英知行”智能问数智能体客户案例

这个案例值得注意的地方不是那个数字，而是它的路径：先收敛指标范围，再谈准确率。如果一上来就要求“什么都能问、什么都答对”，项目大概率会停在 POC 阶段。

除了准确率本身，还要看可追溯性。一条答案点开后，能不能看到它调用了哪个指标、用了什么口径、查了哪些表、过滤了哪些维度？能追溯，错了才能修；不能追溯，准确率就永远是一个无法改进的黑箱。

三、权限管控：对话式入口放大了哪些风险

报表时代的权限相对好管：一张报表、一个数据集、一个目录，授权对象清晰。对话式入口改变了这一点——任何有权限登录的人，都可以用任何措辞提问，问句本身成了一次权限探测。用户问“华东区高净值客户的逾期率”，系统如果只校验了“逾期率”这一个指标的权限，却漏掉了“高净值客户”这个客群标签的权限，就会造成越权。

因此权限管控要分层看，不能只看一层。

落地时有四条原则值得坚持：

第一，复用既有权限体系，不要在智能问数层另建一套。 一旦出现两套权限，就一定会出现两边不一致的情况，最终变成数据安全事件。智能问数应当继承企业级 BI 平台已经配置好的用户、角色、组织架构与数据权限规则。

第二，默认最小可见。 新上线的分析主题，默认不授权，按角色逐个开放，而不是先全开再回收。

第三，全链路审计。 审计不只是记录登录日志，而是要能回答：某个用户在过去一个月问过哪些指标、导出过哪些数据、哪些问句被权限拦截。这既是安全要求，也是合规要求。

第四，支持组织层级继承。 在银行、保险这类多层级组织中，总行、分行、支公司的数据可见范围是逐级收敛的。中英人寿在项目中实现了细粒度权限控制，覆盖总公司至分支机构的不同角色访问需求，这类设计在多层组织中是刚性需求，而不是加分项。

引用：中英人寿“中英知行”智能问数智能体客户案例

在 POC 阶段，建议专门安排一轮“越权测试”：用低权限账号去问高权限指标、去问未授权维度的组合、去问敏感字段，看系统是拒绝、是脱敏，还是直接给出结果。很多项目在功能测试上表现完美，却在这一轮暴露出问题。

四、指标治理：智能问数能不能信的基础工程

指标治理听起来像老话题，但它决定了智能问数的上限。没有统一口径，问数答得越快，错得越快。

指标体系与指标治理通常包含五个环节：

• 定义：每个指标的业务含义、统计口径、计算公式、责任人；
• 计算：区分原子指标与派生指标，计算逻辑唯一且可复现；
• 存储：指标结果落库，避免每次问数都现算，保证口径稳定；
• 发布：形成可检索的指标目录，业务人员知道有哪些指标可问；
• 应用：报表、驾驶舱、自助分析与智能问数共用同一套指标，而不是各建一套。

其中“原子指标拆解”是最容易被低估的一步。所谓原子指标，是指不可再分、口径唯一的基础指标。复杂指标往往由多个原子指标组合而成，如果拆不干净，同一个指标在不同场景下就会算出不同结果。中英人寿的做法是把 109 个复杂经营指标拆解为原子指标，先统一口径和计算逻辑，再谈自然语言解析。这是“先治理、后智能”的典型顺序。

引用：中英人寿“中英知行”智能问数智能体客户案例

除了指标本身，还需要建设语义资产。三类资产对准确率的贡献最直接：

1. 行业术语知识字典：解释 APE、VNB、标准保费等专业术语的业务含义；
2. 同义词库：把业务口语、历史叫法、缩写映射到标准指标与维度；
3. 指标与业务实体的关联知识图谱：明确“机构—渠道—产品—指标”之间的关联关系，让模型知道某个指标可以按哪些维度下钻。

需要强调的是，这三类资产是业务资产，不是技术配置。它们必须由业务部门参与维护，数据部门负责组织。指望厂商一次性交付一套通用词典，效果通常有限。

指标治理还有一个容易被忽略的特征：它是持续运营，不是一次性项目。业务在变，口径就会变；新机构成立、产品线调整、监管口径更新，都会带来指标变更。中英人寿在项目中建立了“用户反馈 → 迭代升级”机制，这类机制比任何单次治理动作都更重要。

可以用下面这张表做一次快速自评：

如果自评结果在起步级或规范级，建议先做两件事再谈平台选型：一是确定 30 至 80 个核心指标清单，二是明确每个指标的业务 owner 与口径。这两件事做完，选型会容易得多。

五、选型与落地：一张清单判断平台能不能用

把前面三节合起来看，选型其实是在评估三件事：语义层是否扎实、权限体系是否可继承、指标治理是否有工具支撑。可以先用一张对比表做初筛。

在此基础上，可以用一份十项清单做打分（每项 1 至 5 分）：

1. 是否支持把业务指标建成独立指标模型，而不是每次现写 SQL；
2. 是否支持原子指标拆解与派生指标管理，口径变更是否留痕；
3. 是否内置术语字典、同义词库与业务实体关联能力；
4. 是否支持基于知识库与业务规则减少幻觉，答案是否可追溯；
5. 权限能否继承既有 BI 或统一身份体系，是否支持行级列级控制；
6. 是否具备完整审计日志与导出控制；
7. 核心指标问答准确率能否在真实问句集上达到约定门槛；
8. 是否支持多角色智能体与可视化工作流，而不只是一个对话框；
9. 是否支持分阶段试点，从核心指标扩展到全量指标；
10. 厂商是否具备同行业落地经验与持续运营支持能力。

前三项加起来权重建议不低于 40%，因为它们决定了长期可用性，而界面体验只决定第一印象。

落地路径建议分五步走：

• 第一步，定范围：选定 30 至 80 个核心经营指标，覆盖管理层最常问的问题；
• 第二步，治口径：完成原子指标拆解，明确计算逻辑与责任人，形成指标目录；
• 第三步，建语义：沉淀术语字典、同义词库与实体关联关系，先覆盖高频维度；
• 第四步，接权限：复用既有权限体系，完成一轮越权测试与审计验证；
• 第五步，小步上线：先在一个部门或一个业务条线试点，建立反馈闭环再扩展。

几个常见的坑值得提前避开：

• 只测准确率不测越权：安全问题的代价远高于准确率不足；
• 指标范围一次铺满：指标越多，口径争议越多，试点周期会被无限拉长；
• 把语义资产交给厂商单方维护：业务不参与，词典就会与实际叫法脱节；
• 忽视移动端：管理层更多在移动端看数，移动端体验直接影响活跃度；
• 把智能问数当成独立系统建设：脱离指标体系和 BI 底座，最终会变成又一个数据孤岛。

在这个方向上，Smartbi 的路线是“指标驱动的一站式 ABI 平台 + Agent BI”。一站式 ABI 平台负责多源数据接入与建模、指标管理与指标治理、自助分析与交互式仪表盘、经营驾驶舱以及企业级报表，并提供权限、安全、审计、集群等企业级能力；Smartbi AIChat 白泽作为构建在 ABI 底座之上的智能体分析平台，提供智能问数与可视化分析、多角色智能体与可视化工作流、基于 RAG 知识库与业务规则的可追溯问答，并支持 MCP 与 A2A 协议以增强多智能体协同与扩展性。目前 Smartbi 已服务 6000+ 企业客户，覆盖金融、政府、制造、能源、医疗、教育等行业，这类跨行业积累对指标治理这类“重经验”的工作有实际帮助。

需要说明的是，工具能解决的是“让口径可管理、让权限可继承、让答案可追溯”，但指标口径本身的业务决策权，仍然在企业自己手里。

总结：把选型问题还原成治理问题

回到最初那三个问题。准确率取决于有没有指标模型和语义资产，权限管控取决于能不能继承既有体系并做到可审计，指标治理取决于企业愿不愿意先做口径收敛这件苦活。三者之中，指标治理是根，准确率和权限管控是果。

因此，选择智能问数平台的正确顺序，不是先比功能清单，而是先做三件事：列出核心指标清单、确认权限继承方案、明确语义资产的维护责任。做完这三件事，再去看产品，判断会清晰很多。

对于正在评估的企业，建议从一个可控的试点开始：选 30 至 80 个核心指标，用一个业务条线验证准确率与权限，跑通“用户反馈 → 迭代升级”的闭环，再谈全公司推广。中英人寿从 53 个核心指标起步、二期扩展到 109 个的节奏，就是一个可以参考的分阶段路径。

如果希望进一步了解指标治理如何与智能问数衔接，可以关注 Smartbi 的一站式 ABI 平台与 Smartbi AIChat 白泽智能体分析平台的相关方案说明，结合自身指标体系成熟度做一次针对性评估。

常见问题（FAQ）

Q1：智能问数的准确率一般能做到多少？

没有统一答案，关键看分母。核心指标、固定问法的场景，稳定在 90% 以上是合理目标；开放域长尾问句的准确率会明显低于此。建议在选型时要求厂商用企业真实问句日志做测试，并区分核心指标与长尾问句分别统计，同时确认答不出时是否有澄清追问或引导报表的兜底机制。

Q2：智能问数会不会绕过原有 BI 的数据权限？

会不会绕过，取决于产品设计。合理的设计是复用企业既有的用户、角色、组织架构与数据权限规则，在问数链路上做统一的权限校验，并保留完整审计日志。选型时建议专门做一轮越权测试：用低权限账号提问高权限指标、未授权维度组合和敏感字段，观察系统是拒绝、脱敏还是直接返回结果。

Q3：指标体系还没建好，能不能先上智能问数？

可以先做小范围试点，但不建议全面铺开。没有统一口径时，系统答得越快，错误传播越广。可行的做法是先选定 30 至 80 个核心指标，完成原子指标拆解与口径确认，再在此基础上做问数试点。指标治理与智能问数可以并行推进，但治理必须先行一步。

Q4：智能问数能直接生成报表或触发业务动作吗？

生成分析结论、图表和洞察报告是可以的。但涉及业务动作的部分需要区分清楚：以 Smartbi AIChat 白泽为例，平台内完成的是分析、预警、可视化与建议输出，需要通过工作流与企业现有系统集成，方便后续由业务或 IT 触发与执行，而不是自动在 CRM、工单或营销系统中创建任务。

Q5：如何判断一个智能问数产品是真实力还是演示效果？

看三件事：一是语义层，有没有独立的指标模型、术语字典与同义词库；二是可追溯性，每条答案能不能点开看到调用的指标、口径和数据源；三是权限，能否继承既有体系并支持行级列级控制。如果这三点都答不上来，只强调大模型能力，通常说明它还是一个聊天框，而不是分析平台。