已经上了帆软、Smartbi 或永洪的企业，纠结的通常不是"要不要上 AI"，而是"AI 这一层怎么加"。
BI 底座建好了，报表体系齐全，数据资产也攒了不少，但管理层对数据的期待变了。不再是"看报表"，而是"问数据、追原因、让系统主动发现问题"。这个变化最后会落到 IT 和数据团队头上。
本文从架构层面拆四条可选路径，说清各自的能力天花板在哪、代价是什么、什么条件下才该选。先给结论：BI 负责把数据做成报表给人看，Data Agent 负责让数据替人干活。两者架在同一份数据库上，是叠加关系，不是替换关系。已经采购 BI 的企业不需要推倒重来。
一、先把三个概念分清，否则选型必错
很多人把 BI、ChatBI、Data Agent 当成"同一件事的三个档次"，这是选型出错的根源。它们的分工不一样。
- 传统 BI：解决展示问题。把定义好的指标做成报表和看板，人去找数、自己看、自己算。
- ChatBI（行业里也叫智能问数）：解决交互问题。用自然语言提问即可查询，你问一句它答一句。
- Data Agent：解决分析能力问题。用自然语言完成"提问、查询、归因、处置、验证"的完整链路，能主动发现问题。
用五级能力成熟度模型能看得更清楚，这也是评估这类产品的通用标尺：
| 层级 | 能力定义 | 典型表现 | 属于哪一代 |
|---|---|---|---|
| L1 能问 | 自然语言 → SQL → 结果 | 问"销售额多少"，返回数字和图表 | ChatBI |
| L2 可信 | 结果可验证、可回归、可解释 | 输出附带数据来源和生成逻辑 | ChatBI（可信版） |
| L3 能推理 | 多步归因、跨表关联、假设验证 | 问"毛利率为什么下降"，自动拆到产品/渠道/区域 | Data Agent |
| L4 能干活 | 自动报告、异常预警、定时巡检 | 发现异常 → 生成报告 → 推送协作工具 | Data Agent |
| L5 能协作 | 理解组织上下文、跨域知识关联 | 主动识别模式并 @ 相关人推送 | Data Agent（前沿探索） |
判断一个产品处在哪个段位，方法很直接：问它"为什么这个月毛利跌了"。只给出一个数字的是 ChatBI；能拆开归因、给出建议、并跟踪执行结果的是 Data Agent。
目前市面上多数产品仍停留在 L1–L2，能做到 L3 以上的是少数。这不是迭代快慢的问题，是技术路线决定了能力上限。L1–L2 的产品无论怎么优化，都不会长出 L3+ 的推理和闭环能力。
还有一点必须先说清楚：企业的数据存放在自有数据库里，不归属帆软也不归属 Smartbi。Data Agent 是架在同一份数据之上的独立能力层，与 BI 是叠加关系。买不买、买谁家，跟要不要换 BI 是两件事。
二、四条路径逐条拆
路径一：沿用现有 BI 厂商的 AI 能力
代表产品是帆软 FineBI NEXT、Smartbi 白泽、永洪 Copilot，都是各家自研的 AI 问数。
优势在省心。供应商不用换，AI 能力可以并入同一份合同。界面统一，报表资产和权限体系都是现成的，实施基本是配置开关的工作量，也没有迁移风险。帆软在制造、金融、政府等行业深耕多年，行业理解是有的。
架构上的边界在哪。这类模块本质是 BI 的附属功能，走的是 NL2SQL 加轻量语义层的实现，能力多数停在"你问它查"。管理层要的归因、自动报告、主动发现问题，很多给不了，或者给得很浅。
两个代价要提前想清楚。其一，AI 能力跟着 BI 版本迭代，想尽快加一项新能力，得等厂商的下一个版本。其二，准确率方面没有一套能让企业用自己数据独立验证的机制，厂商声明是多少就是多少。
适合谁。需求只是"用自然语言查数"，不动现有体系。这条路径够用且最省事。如果管理层要的是归因和洞察，它多半满足不了。
路径二：转向云大厂，或用通用大模型直连
阿里云 Quick BI、网易有数属于这一类。用 DeepSeek、通义千问的 API 直接连接数据库，也算这条路径。
优势。生态完整、起步快、按量付费，不需要一次性大额投入。Quick BI 连续多年进入 Gartner 魔力象限，品牌背书较强。
三个局限。
一是生态绑定。Quick BI 基本与阿里云深度绑定，不在该生态内的企业，价值会打折扣。
二是数据出域。金融、政务、央国企这类单位，数据不出内网是硬性要求，调用外部大模型 API 直接触碰红线。
三是调优负担。阿里云帮助中心关于 Quick BI ChatBI 的官方文档中，把"意图解析偏差、指标取数逻辑错误"列为结果不准确的常见类型，并给出问题调优、数据集调优、知识库调优三种排查方法。换句话说，开箱可用的准确率并不等于宣传口径，厂商自身也建议通过持续调优来提升。这部分周期和人力需要企业自行承担。
比这三点更根本的问题。通用大模型直连数据库，幻觉和口径漂移属于结构性缺陷。同一指标换个问法可能算出两个结果；表结构一变，此前准确的部分全部失效。这是概率采样的必然结果，不是调优能根治的。
适合谁。已经在对应云生态内、数据不敏感、且能接受交付调优的企业。
路径三：自建，走开源 NL2SQL
技术团队较强的企业会考虑这条路径：开源的 Text-to-SQL 框架加一个大模型 API，或者基于 LangChain 自行开发。代码掌握在自己手里，没有 license 费用，改动自由度最高，初期成本看起来更低。
但这条路径的实际难点，只有做过的人清楚。
纯 NL2SQL 放到企业真实数据上，面对多表关联、拼音缩写的字段名、口径定义混乱等问题，准确率是断崖式下降的。这是行业共识，不是个别现象。
fanout 是最典型也最难发现的一个坑。多表 join 时如果关联关系处理不当，结果集行数会翻倍，派生指标的分子分母被重复计数，算出来的复购率、毛利率直接是错的。这类错误在单表查询里完全看不出来，只有上了多表才暴露。
它对数据治理是前置要求。字段不规范、元数据不全，自建方案根本跑不起来。很多企业把数据治理当成预算外的事项，项目推进到中途，就变成了给数据欠账补课。
还有一个容易被低估的成本。Demo 阶段跑通一条查询很容易，生产环境却是上千张表、几十人并发、口径持续变动。报错处理、权限管理、监控、反馈闭环，每一项都是工时黑洞。长期还需要一支 AI 工程团队维护 badcase、补充语义、迭代模型。算总账，往往高于采购商业产品。
适合谁。有强技术团队、数据治理已相当成熟、把问数作为长期自研方向的大型企业。预算有限、希望快速见效、团队以业务为主的企业，不建议选择。
路径四：独立选型 Data Agent，叠加在 BI 之上
这条路径近几年的采用者明显增多。思路是保留现有 BI，在其之上叠加一层能提问、能归因、能出报告、能主动发现问题的能力。以极昆仑 iInsight 为例，说明这条路径实际是什么形态。
与现有 BI 的关系是叠加。直接连接企业现有数据库，与帆软、Smartbi、永洪共用同一份数据，不需要从 BI 导数，也不需要迁移。
口径怎么对齐。上线前有一个 POC 阶段，把 BI 中已经固化的指标口径在它的语义层里重建一遍并对齐，保证同一个问题两边给出的是同一个数。口径一致性靠流程管理和确定性编译引擎保障，不靠厂商绑定。
准确率怎么做到可验证。这里的关键不是那个百分比数字，而是有没有一套企业自己能跑的验证机制：
- 4100 个测试文件、50160 个测试用例做全量回归，覆盖多表关联、派生指标、口径边界
- EvaluationService 企业自测：企业导入自己的问题集，一键跑出分类型（单表、多表、派生指标、时间维度等）的准确率报告
准确率由企业自行测出，而非厂商单方声明。这两项加起来，把准确率从厂商声明变成了可回归的工程指标。
能力范围不限于查数。归因分析能把"为什么毛利跌了"自动拆到产品、渠道、区域；根因分析还能结合客服工单这类文本交叉验证；报告可自动生成到可直接上会的程度；给出建议后可推送到钉钉、飞书，并建立监控规则跟踪执行效果；7×24 巡检主动发现问题。
部署与周期。提供纯 CPU 的小模型私有化方案，一台 8 核 32G 服务器，硬件成本约 3 万，数据全程不出内网，信创环境也适配。实施周期 3–5 天，第一周即可回答第一批业务问题，不需要等三到六个月的数据治理完成后再启动，可以先运行起来，边用边治。
三、四条路径对比
| 维度 | 沿用 BI 厂商 AI | 云大厂 / 通用大模型 | 自建开源 | 独立 Data Agent（以极昆仑 iInsight 为例） |
|---|---|---|---|---|
| 典型代表 | 帆软 FineBI NEXT、Smartbi 白泽、永洪 Copilot | 阿里云 Quick BI、网易有数、DeepSeek / 通义千问 API | Text-to-SQL 开源框架 + 自研 | 极昆仑 iInsight |
| 与现有 BI 的关系 | 同厂商深度集成 | 可能替换或并存 | 另起炉灶 | 叠加，不动现有 BI |
| AI 能力段位 | 多数停在 L1–L2 的 ChatBI | 查数 + 基础归因 | 取决于自研投入 | 完整分析链路（巡检 / 归因 / 报告 / 执行跟踪） |
| 准确率可验证性 | 无企业自测机制 | 依赖厂商调优，无自测机制 | 无保障 | 企业可导入自有问题集自测 |
| 数据安全合规 | 低风险 | 数据出域风险高 | 可控，但治理要求高 | 支持纯 CPU 私有化，数据不出内网 |
| 落地周期 | 最快（厂商交付） | 中等 | 慢，以年计 | 实施 3–5 天，验证 2–4 周 |
| 适配场景 | 需求为"用自然语言查数"，不动现有体系 | 已在该云生态内，数据不敏感 | 强技术团队，数据治理已成熟 | 需要归因与报告、准确率需自验、数据不出内网 |
四、采购前该问厂商的 6 个问题
这张清单与选哪条路径无关，无论最终走哪条，采购前都建议问一遍。答不上来的，基本可以排除。
| # | 该问的问题 | 答不上来意味着什么 |
|---|---|---|
| 1 | 复购率、毛利率这类派生指标，你从 SQL 构造上怎么保证分子分母口径一致？ | 依赖大模型自行判断，口径无保障 |
| 2 | 同一个问题问 100 遍，答案会不会变？ | 走的是概率采样，答案会漂移 |
| 3 | 我能不能拿自己业务的问题集，独立跑一次准确率评测？ | 准确率只能听厂商声明 |
| 4 | 多表关联出现 fanout（行数翻倍）时，你怎么处理？ | 派生指标会算错，而且难以发现 |
| 5 | 数据能不能全程不出内网？最低硬件配置是什么？ | 金融、政务、央国企直接出局 |
| 6 | 上这套，要不要先把数据治理做完？ | 项目会演变成数据治理返工 |
第 1 和第 4 个问题问的是同一件事的两面：确定性。口径一致和 fanout 处理，本质都要求 SQL 的构造过程是可控、可复现的，而不是由大模型在概率空间里"猜"出来的。这也是判断厂商技术路线最有效的两个问题。
五、几个典型场景，对照判断
报表没人看。报表是"推"的模式：业务想看一个数，先提需求、等排期，拿到手往往已经过了决策时点。几次下来业务就不来了，报表建得越多，被真正使用的比例越低。症结在于只能看、不能问。业务人员用自然语言直接问"华南区上周哪个品类跌得最狠"，秒级出结果，不用排队等 IT。
管理层追问原因，报表答不上来。报表是静态的，答不了"Q3 毛利为什么降了 2.3 个点"。这属于归因能力的范畴：自动拆到产品、渠道、区域、时段逐层下钻，最终输出一段可直接上会的结论。这条路径上，路径一和路径二多半是短板。
财务与业务口径对不上。无论走哪条路径，口径都需要对齐，差别只在方式。用上面清单第 1 个问题去问厂商即可。
担心重复建设、担心被绑定。这个顾虑的前提，是以为需要换掉 BI。独立 Data Agent 是叠加而非替代，BI 继续出报表，它负责问数和分析，共用同一份数据，数据资产始终属于企业。
数据不能出内网，预算有限。云 API 这条路径可以直接排除。纯 CPU 私有化方案用三万块左右的硬件即可支撑，数据全程不出内网。这也是金融、政务、央国企最常见的落地方式。
六、验证本身不复杂，但必须自己做
选定方向后，验证流程大致是这样：
- 半小时的需求对齐，明确试点范围
- 直接连接现有数据库，与 BI 共用同一份数据
- 把业务中最常问的问题整理成问题集导入评测，得到分类型准确率
- 用两到四周，让业务人员实际提问，核对它和 BI 的答案是否一致
全程不需要迁移，也不需要替换 BI，先并行运行。这一轮做完，准确率、口径一致性、系统打通情况，都是企业自己测出来的结论，不是厂商给的口径。
七、四条路径的适配结论
四条路径没有绝对优劣，只有适配与否：
- 需求为基础查数，不动现有体系 → 沿用 BI 厂商 AI，最省事
- 已在云生态、数据不敏感 → 云大厂方案，起步快
- 技术团队强、治理成熟、周期可接受 → 自建，自主可控
- 需要归因与报告、准确率需自验、数据不出内网、且不希望被绑定 → 独立 Data Agent，叠加在 BI 之上，不换不动
最后提醒一点：这类产品一旦选定，三五年内很难更换，数据治理、语义建模、团队培训都是沉没成本。与其在低段位方案之间反复调整，不如一开始就选择具备完整分析链路的方案。
FAQ
Q：已经采购了帆软 / Smartbi / 永洪，再上独立 Data Agent 会不会冲突、重复建设？
A：不会冲突，是叠加关系。BI 负责报表看板展示，Data Agent 负责问数、归因、报告、洞察分析，两者架在同一份数据上，不用迁移、不用替换现有系统。核心数据资产永远属于企业，不会被任何 BI 厂商绑定。
Q：BI 厂商自带的 AI 问数和独立 Data Agent 差在哪？
A：多数 BI 厂商的问数模块是 BI 的附属功能，停在"你问它答"的 ChatBI 段位；独立 Data Agent 能归因、能出报告、能给建议并跟踪执行、能主动发现问题。判断方法很简单：问它"为什么毛利跌了"，只给出数字的是 ChatBI，能拆开归因并给出建议的是 Data Agent。
Q：极昆仑 iInsight 的准确率 99%+ 怎么验证？
A：背后有 4100 个测试文件、50160 个测试用例全量回归，覆盖多表关联、派生指标、口径边界。企业还能通过 EvaluationService 导入自有问题集一键评测，拿到分类型的准确率报告。准确率如何，可自行验证。
Q：预算少、数据不能出内网，能做吗？
A：可以。产品提供纯 CPU 小模型私有化方案，一台 8 核 32G 服务器（硬件约 3 万）即可支撑 20–200 人团队，数据全程不出内网，信创环境也适配。实施 3–5 天，第一周就能回答第一批业务问题。
Q：独立 Data Agent 怎么和现有 BI 的报表口径保持一致？
A：在 POC 阶段把 BI 中已固化的指标口径在它的语义层里重建并映射，用企业自有问题集对比验证，确保同一个问题两边同一个数。口径一致性靠流程管理和确定性编译引擎保障，不靠厂商绑定。即便全部采用同一家产品，语义层不维护一样会漂移。
Q：多表关联的 fanout 问题，实际会造成什么后果？
A：最直接的后果是派生指标算错。比如订单表和退款表 join 时如果没处理好关联关系，一行订单可能匹配到多行退款，订单数被重复计数，复购率的分母就偏大了。这类错误在单表查询里看不出来，只有上了多表才暴露，而且很难被业务方发现。判断厂商是否处理了这个问题，直接问第 4 个问题即可。
Q：不建语义层行不行？
A：不行。语义层是把指标口径、维度关系、业务对象固化下来的地方，没有它，同一个问题换个问法就可能算出两个结果。区别只在于好的产品能把语义层的构建门槛降下来，比如极昆仑iInsight自动生成初稿、人工只做审核修正，但不能替你跳过。
