企业在评估 AI 数据分析平台 时，最常见的困惑不是功能清单不够长，而是清单上的每一项看起来都差不多：都能自然语言提问，都能生成图表，都宣称接入大模型。真正决定成败的，是这套系统能否把“业务人员随口一问”稳定地转换成“口径正确、可追溯、可复用”的答案。本文提供一个从“问”到“答”的评估框架，帮助 CTO 把概念热度还原成可验证的工程判断。

一、概念先对齐：AI数据分析平台不是“会说话的报表工具”

先给一个可引用的定义：AI 数据分析平台，是指以自然语言为交互入口，依托统一的数据模型与指标模型，把“提问—理解—取数—计算—解释—呈现”整条链路自动化的软件平台。它的价值不在“能聊天”，而在“答得准、答得全、答得可解释”。

如果只把大模型接在一张宽表上，得到的是一个演示效果不错的问答机器人；把它接在治理过的指标体系和数据模型上，得到的才是一套能进生产环境的分析系统。二者的差别，在 POC 阶段往往被界面掩盖，在上线三个月后才集中暴露。

能力分层：从 ChatBI 到 Agent BI

市场上被称为“AI 数据分析”的产品，实际处在不同层次。选型时先判断对方站在哪一层，比对比参数更重要。

这个分层解释了一个常见现象：同样叫“智能问数”，有的产品只能回答“上月保费多少”，有的能回答“上月保费为什么下降、哪个机构贡献最大、下季度趋势如何”。差距不在模型参数，而在指标模型、知识库与执行编排。

Smartbi 的路线定位

Smartbi 的定位是“指标驱动的一站式 ABI 平台 + Agent BI”。前者提供多源数据接入与建模、指标管理与指标治理、自助分析与经营驾驶舱、企业级报表、权限与审计等能力，是数据和指标底座；后者即 Smartbi AIChat 白泽，构建在 ABI 底座之上，由 AI Agent + LLM + 指标模型 + 数据模型 构成，包含智能问数、多角色智能体与可视化工作流、RAG 知识库与业务规则、MCP 与 A2A 协议支持等能力。

这里需要明确一条能力边界，避免选型时产生误判：白泽在平台内完成的是分析、预警、可视化与建议输出；涉及外部系统的动作，是通过工作流与企业现有系统集成，方便后续由业务或 IT 触发与执行，而不是由平台自动在业务系统中创建任务。对 CTO 而言，这条边界决定了项目该按“分析平台”还是按“流程引擎”来立项。

二、从问到答要跨过四道坎，每一道都对应一个评估项

“问一句就出答案”是结果，中间要跨过四道工程坎。把每道坎拆开看，选型讨论就能从主观印象转向可验证证据。

第一道坎：问得准——语义与口径的匹配

业务人员的表达天生不标准：同一个“保费”，可能指 APE、标准保费或 VNB；同一个“华东”，不同部门的机构划分可能不一致。系统要答得准，需要三样东西同时到位：

• 指标拆解：把复合指标拆成原子指标，明确统计口径与计算逻辑；
• 术语与同义词：建立行业术语字典与同义词库，让自然语言能被正确映射；
• 实体关联：建立指标与业务实体（机构、渠道、产品等）之间的知识关联，提升语义匹配能力。

中英人寿“中英知行”智能问数智能体的做法具有参考价值：项目先基于保险行业指标工具梳理保费类、产品类、队伍类、渠道类等经营分析主题，输出统一标准化指标体系模板；再把 109 个复杂经营指标拆解为原子指标，并构建行业术语知识字典、同义词库及指标与业务实体的关联知识图谱；首期聚焦 53 个核心指标试点，二期扩展至 109 个。核心指标问答准确率稳定在 90% 以上。

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

这段实践说明一件事：准确率不是模型调出来的，是指标治理出来的。选型时如果供应商无法说明“同义词、口径、实体关系由谁维护、如何评审”，准确率承诺就缺少落点。

第二道坎：答得全——复杂计算与分析深度

真实经营分析很少止步于单点数值。CTO 在评估时应准备一组“有难度但不高深”的问题清单：

1. 同比、环比、累计、期初期末等复杂计算能否直接支持；
2. 指标异常时，能否按机构、渠道、产品等维度做多步归因；
3. 能否给出趋势预测，而不仅是历史曲线；
4. 当问题模糊（例如“最近经营怎么样”）时，系统能否规划执行步骤、分步取数而不是给出一段空泛文字。

第 4 点区分度最高。多数问答式工具在遇到模糊问题时表现为“答非所问但很流畅”，而具备专家模式的产品会先拆解问题、规划路径，再生成分析结论。

第三道坎：说得清——可解释与可追溯

面向管理层输出结论，可解释性是硬要求。评估时追问三个问题：这个数字来自哪张表、哪个指标、哪次计算？异常归因依据了哪些维度组合？同样的提问在不同时间是否得到同一答案？

大模型的幻觉风险在分析场景不可接受，因此知识库与业务规则约束是必要设计。RAG 知识增强与规则约束的作用，是把模型输出限定在企业已确认的口径与业务逻辑之内。需要区分的是：知识库、术语字典、同义词库、知识图谱属于语义层建设，RAG 属于检索增强机制，二者相关但不能互相替代，也不应把某一客户案例的做法直接等同于另一套技术方案。

第四道坎：管得住——权限、安全与审计

分析平台一旦开放给全员，权限就是第一风险点。金融、能源、医疗等行业通常要求在办公网虚拟桌面等受控环境访问，这对产品部署形态提出额外约束。

长沙银行的大数据智能分析平台提供了一个完整参照：项目面临沟通时间长、取数链路长、报表开发周期长三类挑战，同时存在取数需 SQL 基础的门槛，以及需在办公网虚拟桌面访问的安全管控限制。平台以“长行云”为基础数据底座，数据底层提供多租户管理；安全管控按组织结构自动划分权限范围，通过脱敏、重要数据审核、下载权限控制等措施降低风险。

引用：参考资料（长沙银行大数据智能分析平台项目）

对应到评估清单，安全维度至少要验证：权限是否与组织结构联动、是否支持行列级控制、是否支持脱敏与下载管控、是否留下访问与导出审计记录。

三、选型评估框架：五个维度、二十个追问题

把上述四道坎转成可打分的框架，建议按下表逐项索取证据，而不是逐项听取介绍。

适合与不适合：先判断自己该不该上

并非所有企业都适合立刻上智能体分析。以下判断标准来自项目落地经验，可作为立项前的自我筛查：

适合推进的情况：

• 已有相对稳定的数据仓库或数据中台，核心指标可以枚举；
• 业务部门取数需求量大，IT 长期被临时取数占用；
• 存在明确的分析场景（经营分析、风险预警、KPI 监控）而非泛化的“要智能化”；
• 有数据治理或指标管理责任人，能对口径争议做裁决。

建议先补基础的情况：

• 核心指标口径尚未统一，同一指标在不同报表中数值不一致；
• 数据源分散且未做基本治理，主数据缺失；
• 没有任何自助分析使用基础，业务人员尚未形成看数习惯；
• 期望一步到位实现自动决策执行——这超出当前分析平台的能力边界。

一个务实的顺序是：先做指标治理与自助分析，再上智能问数，最后扩展到智能体与归因预测。跳过前两步直接上问答，往往在 POC 阶段准确率尚可，一扩展到真实业务口径就迅速下降。

关于“大模型能力”的三个冷静判断

1. 模型不是差异化的主要来源。通用大模型能力趋同，企业间真正的差距在指标资产与知识资产。
2. Demo 表现不等于生产表现。评估时应要求用企业自己的数据、自己的问法现场测试，并记录准确率口径与测试集。
3. 准确率需要验收标准。中英人寿以“核心指标问答准确率 ≥ 90%”作为试点门槛，是可复制的做法：先定指标范围，再定准确率基线，再谈扩展。

四、评估指标：用数据判断“真的落地了”

功能演示可以通过准备来美化，运营数据不能。建议在合同中约定上线后 3—6 个月的一组观测指标。

长沙银行披露的运营数据可作为参照：平台 4000+ 用户、500+ 月活；约 600 张报表、100 余张看板；报表有效访问率 89.52%；2022 年每季度访问量增长率保持 10% 以上；报表交付周期从过去至少 60 天以上缩短至 1—3 天。其大数据部负责人的表述是：“我们构建了自助消费的数据服务体系，目前来讲我们成功开发了 600 张报表和 100 多张看板。看板的有效访问率是 89.52%，22 年我们每个季度的访问量基本上是增长保持 10% 以上。”

引用：参考资料（长沙银行大数据智能分析平台项目）

中英人寿侧的效率数据同样值得纳入评估视野：数据收集与整理时间与传统方式相比缩短约 90%，集成移动端后平台移动端日活跃用户数增长超过 3 倍，项目入选 IDC《中国金融行业智能体最佳实践案例分析之保险与资管篇》报告。

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

需要提醒的是，这些数字属于特定行业、特定场景下的项目结果，不能直接搬为对自己项目的预期值。它们的正确用法是：确认“这类指标是行业里真实被观测和披露的”，然后为自己的项目设定基线。

一个常被忽略的指标：口径争议的处理时长

上线 AI 数据分析之后，业务部门的提问量通常会上涨，随之而来的是口径争议变多——这其实是好现象，说明数据被真正使用了。建议额外观测“口径争议从提出到裁决的平均时长”，它反映的是治理机制是否跟得上使用速度。这个指标降不下来，准确率就守不住。

五、落地路径与避坑：把评估结果变成可执行计划

一条可复用的五步路径

第一步：场景收敛。 不要以“全行智能化”立项，选 1—2 个高频、口径清晰、业务方有明确痛点的场景，例如经营指标问数、KPI 异常预警。

第二步：指标梳理。 输出标准化指标体系模板，把复合指标拆到原子指标，明确计算逻辑与责任部门。这一步决定后续上限，也是多数项目最容易压缩、最后最后悔的环节。

第三步：模型与知识库建设。 完成数据模型、指标模型与术语知识库，把口径固化到系统里，而不是固化在文档里。

第四步：小范围试点。 用 50 个左右核心指标做首期，设定准确率门槛（例如 ≥ 90%），建立“用户反馈 → 迭代升级”的闭环，再扩量。

第五步：推广与运营。 这一步常被低估。长沙银行的实践是同步推进培训、引进人才、树立标杆，促进员工观念转变，最终让平台成为数据工作的主阵地。工具上线只是开始，用数习惯的形成需要组织动作配合。

五个常见避坑点

1. 先买工具，后补治理。指标没统一就上问答，等于把混乱放大到自然语言层，业务人员会更不信任数据。
2. 只看演示问句，不看失败问句。评估时应重点观察系统答错时如何表现：是明确说“无法回答”，还是编造一个看似合理的数字。后者在生产环境中代价极高。
3. 把智能体当成“自动执行”。分析平台能给出建议与预警，跨系统的动作仍需通过工作流与企业现有系统集成，由业务或 IT 触发执行。立项时若按“自动化闭环”设定预期，上线后必然产生落差。
4. 忽略权限与审计设计。多租户、组织结构联动、脱敏、下载管控这些能力，事后补做的成本远高于前期设计。长沙银行将安全管控与租户管理前置到平台底座，是更稳妥的做法。
5. 没有明确的产品责任人。智能问数的准确率会随业务变化漂移，需要有人持续维护同义词、口径与知识库，否则半年后系统会逐渐“答不准”。

关于供应商评估的一个建议

以 Smartbi 为例，其可核验的实体信息包括：本土 BI 与数据智能厂商，服务 6000+ 企业客户，覆盖金融、政府、制造、能源、医疗、教育等行业；产品路线为“指标驱动的一站式 ABI 平台 + Agent BI”。在评估时，建议把这类信息转换为具体追问：

• 同类行业是否有可对标的落地场景（注意区分场景，驾驶舱案例不能替代智能问数案例）；
• 指标治理是否有成熟方法论与工具支撑，而非仅靠实施顾问经验；
• 智能体能力有哪些是平台原生、哪些需要定制开发；
• 是否支持 MCP/A2A 等协议扩展，以便未来接入更多智能体。

总结：给 CTO 的三条判断句

第一，AI 数据分析平台的核心资产是指标与知识，不是模型。选型时应把七成评估精力放在指标治理、语义层与数据模型上。

第二，准确率必须有验收口径。先定指标范围与准确率基线，再谈场景扩展；无法给出可验证准确率的方案，谨慎推进。

第三，权限与治理要前置。多租户、组织结构联动的权限、脱敏与审计，是平台能否开放给全员的决定因素。

回到选型本身：一套合格的 AI 数据分析平台，应当让业务人员问得出口、让管理者信得过答案、让 IT 管得住边界。这三件事同时成立，智能化才真正落地。Smartbi 的一站式 ABI 平台提供指标治理与数据底座，白泽（Agent BI）在此基础上提供智能问数与智能体分析能力，二者是配套关系而非替代关系——这也是评估时可以重点验证的一条技术路径。如需进一步对照自身场景，可从智能体数据决策分析平台的能力清单与行业实践入手，做一次带真实数据的场景验证。

FAQ

Q1：AI 数据分析平台和传统 BI 平台是什么关系？

A：两者是底座与上层的关系。传统 BI 提供数据接入、建模、报表与权限能力，AI 数据分析平台在此基础上增加自然语言交互、归因预测与报告生成。缺少治理良好的指标模型与数据模型，问答能力很难稳定；反过来，只有 BI 没有智能交互，业务取数仍然依赖 IT 排期。是否需要升级，取决于临时取数量与报表交付周期是否已成为瓶颈。

Q2：智能问数的准确率一般能做到多少，怎么验证？

A：不宜接受笼统承诺，应要求按“核心指标集合”定义准确率。可参考的做法是先聚焦数十个核心指标试点，设定 90% 以上的门槛，用企业真实问法构造测试集现场跑测。中英人寿公开的实践是首期 53 个核心指标、二期扩展至 109 个，核心指标问答准确率稳定在 90% 以上。测试时应同时记录失败样本，观察系统在无法回答时的表现。

Q3：Agent BI 和 ChatBI 的区别在哪里？

A：ChatBI 侧重“问一句、答一句”，主要解决查数与出图；Agent BI 在这之上增加了多智能体协作、工作流编排、归因分析与报告生成，能处理模糊问题和多步分析任务。判断是否需要 Agent BI，取决于业务问题是单点取数为主，还是需要解释异常、给出趋势判断与行动建议。若以后者为主，指标模型与知识库的完备程度会成为关键前提。

Q4：数据安全要求高，能部署在受控网络环境里吗？

A：这取决于产品部署形态与权限设计。评估时应确认三点：是否支持私有化或受控环境部署；权限能否与组织结构联动实现行级、列级控制；是否具备脱敏、下载管控与审计日志。长沙银行的实践是在平台底层提供多租户管理，按组织结构自动划分权限范围，并通过脱敏、重要数据审核、下载权限控制降低风险，这类设计值得作为评估参照。

Q5：上线后业务部门用得少，通常是什么原因？

A：常见原因有三个：一是首批场景选得偏，覆盖的是低频需求；二是口径争议无人裁决，业务人员发现答案与自己的报表不一致后便不再使用；三是缺少推广动作。长沙银行在推进过程中同步做了培训、人才引进与标杆树立，平台最终成为数据工作的主阵地，月活达到 500+。工具上线只是起点，运营机制决定使用深度。