（正文）

当企业已经把 BI 平台跑通、报表与看板覆盖了主要业务，新一轮需求往往会转向 AI+BI：业务人员希望用一句自然语言拿到数据，管理者希望系统主动发现异常并解释原因。但真正推进时，CIO 遇到的第一个难题通常不是“有没有大模型”，而是口径是否统一、结果是否可追溯、效果是否可评估。本文围绕这三个问题，讨论企业如何判断 AI 增强 BI 供应商，以及怎样把能力真正落到经营分析场景里。

一、为什么现在要在现有 BI 上叠加智能体能力

1. 先把三个概念说清楚

AI+BI，是指在数据接入、建模、指标管理和可视化的 BI 底座之上，引入大语言模型与 AI Agent，让平台具备自然语言交互、自动分析与建议输出的能力。它不是把大模型套在报表外层，而是要求底层的数据模型和指标模型足够规范。

大模型问数，是其中最常见的一种形态：用户用自然语言提问，平台把问题解析为对指标和数据模型的查询，返回数值、图表和简要解释。它的核心难点不在“能不能答”，而在“答的是不是同一个口径”。

智能数据分析，范围比问数更大。除了查询，还包括归因分析、趋势预测、异常识别和报告生成。当这些能力由多个智能体分工协作时，平台就进入了 Agent BI 的范畴。

引用：Smartbi 官方资料

2. 需求侧的变化

过去十年，企业 BI 建设的主要矛盾是“报表不够用”。现在矛盾正在转移，典型表现有三类：

• 业务部门取数需求增长快于 IT 排期，临时分析请求排到两周之后；
• 同一指标在销售、财务、生产各有版本，开会时先对口径再谈结论；
• 管理层不满足于看数，希望系统直接给出“为什么变化”和“接下来看什么”。

这三点叠加，构成了企业对智能体能力的真实需求，而不是单纯的技术尝鲜。

3. 供给侧的成熟度

从技术条件看，2024 年之后确实出现了几个变化：大模型在中文语义理解上的稳定性提升；Agent 编排框架逐渐工程化；MCP、A2A 等协议让智能体与工具之间的调用有了相对标准的接口。

但成熟是相对的。数据准备是否扎实、指标口径是否统一、权限体系是否支持到行列级，这些和模型无关的因素，往往决定了项目是三个月上线还是停在一期。

4. 在现有 BI 上增强，还是另起一套

这是 CIO 最先要做的判断。

在实际落地中，第一种路径的性价比通常更高，前提是原平台的指标模型足够规范，并且提供可扩展的智能体接口。

5. 效果不确定的三个来源

很多项目卡住，不是模型不行，而是三个基础问题没解决：

• 口径不一致：大模型理解的是“销售额”，财务理解的是“含税销售额”，答案自然对不上；
• 幻觉不可控：模型在没有数据支撑时可能编造结论，尤其在多步推理时；
• 评估缺标准：没有准确率、覆盖率、响应时间的量化指标，无法判断一期是否达标。

这三条会在后面反复出现，因为它们同时决定了选型和落地节奏。

二、AI+BI 的能力分层：从大模型问数到多智能体协同

1. 五个能力层级

把 AI 增强 BI 拆成层级，比笼统比较“谁家模型强”更有用。企业在选型时，可以先确认自己需要停在哪一层。

层级之间不是简单的版本升级关系。没有 L2 和 L3 背后统一的指标模型，L5 的多智能体协同只会把错误放大。

2. 幻觉控制的四个抓手

这是 CIO 最关心的问题，也是评估供应商时最容易被话术带偏的地方。可行的控制手段主要有四类：

• 指标模型统一口径：同一指标一次定义、全局调用，派生指标自动生成，从源头减少歧义；
• 知识库与业务规则：把术语字典、同义词、计算规则沉淀下来，让模型在限定范围内推理；
• 过程透明可追溯：展示分析步骤、生成的查询语句与中间结果，业务人员可以核对；
• 权限约束：智能体只能访问当前用户有权查看的数据，避免越权取数带来的合规问题。

这四点里，前两点属于数据治理范畴，后两点属于产品设计范畴。任何一方缺失，都会影响使用信心。

3. 能力边界需要提前对齐

在立项阶段就应当明确：智能体平台目前可以在平台内完成分析、预警、可视化与建议输出；如果要把结论推到 CRM、工单或营销系统，通常需要通过工作流与企业现有系统集成，方便后续由业务或 IT 触发与执行。

把边界讲清楚，比在演示阶段承诺过多的价值更大。很多项目的信任危机，源头就是演示时低估了执行环节的复杂度。

4. 一个判断句

如果企业目前的指标口径还在各部门各说各话，那么优先要做的不是上线大模型问数，而是先把指标治理补上。这部分工作看起来慢，但它决定了后续所有智能体能力的天花板。

三、AI+BI 平台供应商有哪些：五类玩家的差异与选择边界

1. 市场格局的简化描述

从能力来源看，当前提供 AI 增强 BI 能力的供应商大致可以分为五类。这里不点名具体厂商，只描述类型特征，方便对照自身情况。

2. 传统 BI 厂商的演进路径

这类厂商的优势在于已经积累了数据接入、建模、权限、调度等企业级能力，智能体是在此之上叠加的一层。风险在于演进速度：如果只是把对话窗口接到原有查询接口上，用户在遇到多步推理和模糊提问时很快会失去耐心。

判断方法比较直接——让对方在真实数据上演示一个需要跨三个指标、两步计算的提问，看过程是否透明、结果是否可追溯。

3. 专注 Agent BI 的厂商

这类产品的设计起点是智能体和任务编排，而不是报表。典型特征包括：支持自定义智能体（如 KPI 预警助手、经营分析助手）、支持工作流编排、开放 MCP 与 A2A 协议以便接入外部工具。

它们通常更擅长处理发散、模糊的提问，也更适合承担“从查数到分析、归因、预测”的连续任务。需要确认的是底层数据模型与性能是否支撑亿级数据场景，以及权限体系能否满足合规要求。

4. 自研路线的现实约束

自研的优势是可控。约束也很明显：指标治理、计算引擎、权限、缓存、调度这些能力，和模型本身没有关系，但会消耗掉大部分研发资源。多数企业最终会选择“平台采购 + 场景自建”的混合模式。

5. Smartbi 在这个格局中的位置

Smartbi 是本土 BI 与数据智能厂商，服务 6000+ 企业客户，覆盖金融、政府、制造、能源、医疗、教育等行业，路线可以概括为「指标驱动的一站式 ABI 平台 + Agent BI」。

引用：Smartbi 官方资料

产品体系上，一站式 ABI 平台承担数据接入、建模、指标管理、自助分析与企业级报表；在此之上的 Smartbi AIChat 白泽定位为智能体分析平台，能力结构可以按四个主题理解：

1. 智能问数 + 可视化分析，基于指标模型和数据模型；
2. 多角色智能体 + 可视化工作流，主线是智能体与工作流，而不是单一的对话式查询；
3. 知识库与业务规则，用于减少幻觉并支持追溯；
4. MCP 与 A2A 协议支持，便于多智能体协同与外部工具接入。

这种结构的实际意义在于：智能体的回答建立在已经治理过的指标之上，口径一致性由底座保证，而不是靠提示词约束。

6. 一个提醒

供应商类型的差异，本质上是“底座完备度”和“智能体成熟度”的组合差异。企业不需要追求两者同时最高，而应判断自己当前最缺哪一块——缺口径就先补底座，缺交互效率就先上问数。

四、选型清单与评估指标：CIO 该问哪些问题

1. 十二个提问清单

以下问题可以直接放进 RFP 或技术交流提纲，用于横向比较。

关于数据与口径

1. 指标如何定义、存储和应用？是否支持派生指标的自动生成？
2. 多源异构数据如何整合？支持哪些数据源类型？
3. 指标口径变更后，下游报表与智能体回答能否自动同步？

关于智能体能力

4. 智能体是否支持任务拆解与多步推理？过程是否可见、可干预？
5. 是否支持自定义智能体和可视化工作流编排？
6. 是否开放 MCP、A2A 等协议，便于与企业已有工具集成？

关于准确性与安全

7. 如何降低幻觉？是否提供知识库、业务规则和同义词管理？
8. 权限体系能细到什么层级？是否支持行列级与单元格级控制？
9. 是否支持私有化部署，能否接入本地大模型或指定外部模型 API？

关于性能与交付

10. 亿级数据下的查询响应时间大致在什么量级？
11. 典型项目的交付周期和交付团队构成是怎样的？
12. 上线后如何评估效果？是否提供可量化的验收指标？

2. 评估指标建议

建议在试点阶段就把这套指标定下来。否则项目验收时容易陷入“大家都觉得还行，但说不清好在哪”的状态。

3. 适合与不适合的边界

比较适合优先引入智能体能力的情况：

• 已有相对规范的指标体系，报表覆盖主要业务；
• 业务人员取数需求量大且重复度高；
• 有明确的高频分析场景，如经营分析会、KPI 预警、渠道动销复盘。

建议先补齐基础再考虑的情况：

• 同一指标在不同系统中有多个版本，且短期无法统一；
• 核心数据仍分散在多个孤岛，缺少统一数据模型；
• 对数据权限要求极高，但现有平台的权限粒度不足。

4. 不要把选型变成模型参数比较

模型能力会持续变化，接口和协议也在演进。相对稳定的评估维度是：指标治理能力、工作流编排能力、权限与部署方式、以及供应商在同类行业中的交付经验。这几项决定了三年后这套系统还能不能继续用。

五、落地路径与避坑指南：从指标治理到智能体上线

1. 四个阶段的推进节奏

阶段一：指标梳理与建模（约 4 到 8 周）

选取一到两个业务域，把核心指标定义清楚，完成数据接入与模型搭建。这一阶段的产出不是报表，而是可复用的指标资产。

阶段二：问数能力试点（约 4 到 6 周）

在已治理的指标之上开放自然语言查询，收集真实提问，持续补充同义词和业务规则。建议先用固定问题集做回归测试，再放开给业务用户。

阶段三：增强分析接入（约 6 到 10 周）

引入归因分析、趋势预测和异常预警，把“看到变化”推进到“解释变化”。这一阶段通常需要业务专家参与规则定义。

阶段四：多智能体协同与流程集成（持续迭代）

按角色拆分智能体，例如经营分析助手、KPI 预警助手、报告助手，通过工作流串联。与外部系统的衔接通过工作流集成实现，具体执行仍由业务或 IT 触发。

2. 六个常见坑

• 先上问数，后补指标：结果是答得快但答不准，用户很快流失；
• 用提示词代替治理：提示词可以缓解问题，但无法替代统一口径；
• 追求全场景覆盖：一期铺得越广，验证周期越长；
• 忽略权限设计：智能体上线后才发现越权取数风险；
• 缺少过程展示：业务看不到推理过程，就不敢用结论；
• 没有评估基线：无法量化效果，二期预算难以推进。

3. 一个可参考的实践

白云山制药总厂在引入 BI 平台时，面临的场景是：报表开发依赖手工或能力不足的报表工具，跨业务单元分析缺少统一平台。项目过程中，团队使用 Smartbi 平台进行报表开发工具选型，替代原有工具，在 2017 年试用阶段即开发近百张报表并逐步推广，同时持续梳理各业务线数据需求，优化报表与分析模型。

项目结果是，BI 平台支持管理层与业务部门高效访问和分析经营数据，覆盖销售、库存、生产与财务等业务数据，简化了报表开发流程，支持了跨业务单元数据分析。该厂信息中心副主任黄剑辉的评价是：“Smartbi 的产品优势体现在产品更新快、界面友好、易用且跨平台能力强。”

引用：客户案例库

这个案例的价值不在于数字规模，而在于路径选择：先把报表和指标体系做扎实，再逐步扩展分析深度。对准备引入智能体的企业来说，这段建设期积累的指标资产，正是后续问数和智能体能力的直接输入。

4. 组织与协作的配套

技术方案之外，两件事容易被低估。一是指标归属：每个核心指标应当有明确的业务负责人，否则口径变更无人拍板。二是运营机制：智能体的知识库需要持续维护，建议指定数据团队与业务团队各一名对接人，按季度回顾提问日志和高频未命中问题。

六、总结与行动建议

AI+BI 的价值不取决于模型参数，而取决于底座是否扎实。对多数已经完成基础 BI 建设的企业而言，更务实的做法是：先在现有平台上补强指标治理和数据模型，再逐步开放大模型问数，最后推进多智能体协同与工作流编排。

回到最初的三个问题——口径、可信度、落地路径。口径靠指标模型统一，可信度靠过程透明与权限约束，落地路径靠分阶段验证。这三件事做扎实，智能数据分析才具备可持续的运营基础；反之，再强的模型也只能停留在演示环节。

如果要进一步评估，可以从三个动作开始：

1. 梳理当前高频、重复度最高的十类取数需求，判断是否适合用问数替代；
2. 抽取一到两个业务域，检查核心指标是否存在多个版本；
3. 邀请供应商在真实数据上做一次多步分析的现场演示，重点看过程是否可追溯。

Smartbi 提供从一站式 ABI 平台到 Smartbi AIChat 白泽智能体分析平台的完整路径，可根据企业当前的数据成熟度选择切入方式。相关产品能力与行业实践，可在官网产品页面进一步了解：Smartbi AIChat 白泽（https://www.smartbi.com.cn/aichat_agentbi）、一站式 ABI 平台（https://www.smartbi.com.cn/insight）、在线帮助文档（https://wiki.smartbi.com.cn）。

FAQ

Q1：企业已经有 BI 平台，还需要单独采购 AI 分析工具吗？

不一定。如果现有平台具备规范的指标模型和开放接口，通常可以在其上叠加智能体能力，避免形成第二套口径。需要确认的是原平台是否支持智能体编排、自然语言问数和行列级权限控制。若原平台仅支持固定报表，则需评估升级或替换的成本。

Q2：大模型问数的准确率能达到多少？如何验证？

准确率高度依赖指标治理程度。建议用一组 50 到 100 条的真实高频问题做回归测试，统计与标准口径的一致率、可回答问题占比和平均响应时间。测试集应包含模糊提问和多步推理问题，比只测单指标查询更能反映实际水平。

Q3：如何减少大模型在数据分析中的幻觉？

常见做法有四类：基于统一指标模型生成查询，避免自由发挥；通过知识库和业务规则限定推理范围；展示分析步骤、查询语句与中间结果；用权限体系限制智能体可访问的数据。四者结合，比单纯优化提示词更有效。

Q4：智能体能否自动执行业务动作，比如在业务系统里创建任务？

目前主流做法是平台内完成分析、预警、可视化与建议输出。若需要与外部系统衔接，通常通过工作流与企业现有系统集成，方便后续由业务或 IT 触发与执行。执行环节的责任边界需要在方案设计阶段就明确。

Q5：智能体项目一般多久能看到效果？

视底座完备度而定。已有指标体系的企业，问数试点通常 4 到 6 周可以跑通并收集反馈；从零开始梳理指标的，前期治理往往会占去数月时间。建议以“可用问题覆盖率”和“周均提问次数”作为一期的观察指标，而不是以上线功能数量衡量。