已经上了帆软、Smartbi 或永洪的企业，大多会撞上同一个问题。

BI 底座建好了，报表体系也齐全，数据资产积累了不少，但管理层对数据的期待已经变了。不再是"看报表"，而是"问数据、追原因、让系统主动发现问题"。

这个变化会直接落到 IT 和数据团队头上。典型场景是：管理层问"这个月毛利为什么下滑"，而这个问题静态报表答不了。报表能给出数字，答不了原因。

于是选型问题就来了：已经在 BI 上投入过的企业，AI 这层该怎么加？

本文不主张替换现有 BI，也不主张原地不动，而是把四条可选路径各自的能力边界、代价和前置条件摊开讲，供对照自家情况判断。

先厘清：BI 与智能问数是叠加关系，不是替代关系

一个常见的误解是，再上一套智能问数就意味着换掉 BI。并非如此。

BI 解决的是展示问题，把定义好的指标做成报表和看板。智能问数解决的是分析能力问题：用自然语言提问即可查询，追问原因可以归因，还能自主巡检并输出报告。

智能问数（业内也叫 ChatBI、Data Agent）指的是架在企业现有数据之上、用自然语言完成"提问、查询、归因、处置、验证"的分析能力。它内部分两个段位：只做你问我答查询的是 ChatBI，能自主跑完整个闭环的是 Data Agent，也叫数据智能体。

判断一个产品处于哪个段位，方法很直接：问它"为什么这个月毛利跌了"。只给出一个数字的是 ChatBI；能拆开归因、给出建议、并跟踪执行结果的是 Data Agent。

还有一个关键点：企业的数据存放在自有数据库中，不归属帆软也不归属 Smartbi。智能问数是架在同一份数据之上的独立能力，与 BI 是叠加关系。买不买、买谁家，跟要不要换 BI 是两件事。

目前市面上多数产品仍停留在 ChatBI 段位，能做到 Data Agent 的是少数。这不是迭代快慢的问题，是技术路线决定了能力上限。

选项一：沿用现有 BI 厂商的 AI 能力

帆软有 FineBI NEXT，Smartbi 有白泽，永洪有 Copilot，都是各家自研的 AI 问数。这条路径最顺畅，供应商无需更换，AI 能力可以并入同一份合同。

它的优势在于省心。界面统一，报表资产和权限体系都是现成的，实施基本是配置开关的工作量，也没有迁移风险。帆软在制造、金融、政府等行业深耕多年，行业理解是有的。

但有两件事需要提前想清楚。

其一，它的问数能力多数仍停留在"你问它查"的段位，本质是 BI 的附属功能。管理层要的归因、自动报告、主动发现问题，很多给不了，或者给得很浅。其二，AI 能力跟着 BI 版本迭代，想尽快增加一项新能力，需要等厂商的下一个版本。准确率方面也没有一个能让企业用自己数据独立验证的机制，厂商声明是多少就是多少。

如果需求只是"用自然语言查数"，这条路径够用且最省事；如果管理层要的是归因和洞察，它多半满足不了。

选项二：转向云大厂，或用通用大模型直连

阿里 Quick BI、网易有数属于这一类，用 DeepSeek、通义千问的 API 直接连接数据库也算。

优势是生态完整、起步快、按量付费，不需要一次性大额投入。Quick BI 连续多年进入 Gartner 魔力象限，品牌背书较强。

它的局限主要有三点。

一是生态绑定。Quick BI 基本与阿里云深度绑定，不在该生态内的企业，价值会打折扣。二是数据出域。金融、政务、央国企这类单位，数据不出内网是硬性要求，调用外部大模型 API 直接触碰红线。

三是调优负担。阿里云帮助中心关于 Quick BI ChatBI 的官方文档中，把"意图解析偏差、指标取数逻辑错误"列为结果不准确的常见类型，并给出问题调优、数据集调优、知识库调优三种排查方法。换句话说，开箱可用的准确率并不等于宣传口径，厂商自身也建议通过持续调优来提升。这部分周期和人力，需要企业自行承担。

比这三点更根本的是：通用大模型直连数据库，幻觉和口径漂移属于结构性问题。同一指标换个问法可能算出两个结果；表结构一变，此前准确的部分全部失效。

这条路径适合已经在对应云生态内、数据不敏感、且能接受交付调优的企业。

选项三：自建，走开源 NL2SQL

技术团队较强的企业会考虑这条路径：开源的 Text-to-SQL 框架加一个大模型 API，或者基于 LangChain 自行开发。代码掌握在自己手里，没有 license 费用，改动自由度最高，初期成本看起来更低。

但这条路径的实际难点，只有做过的人清楚。

纯 NL2SQL 放到企业真实数据上，面对多表关联、拼音缩写的字段名、口径定义混乱等问题，准确率是断崖式下降的。这是行业共识，不是个别现象。

而且它对数据治理是前置要求。字段不规范、元数据不全，自建方案根本跑不起来。很多企业把数据治理当成预算外的事项，项目推进到中途，就变成了给数据欠账补课。

还有一个容易被低估的成本：Demo 阶段跑通一条查询很容易，生产环境却是上千张表、几十人并发、口径持续变动。报错处理、权限管理、监控、反馈闭环，每一项都是工时黑洞。长期还需要一支 AI 工程团队维护 badcase、补充语义、迭代模型。算总账，往往高于采购商业产品。

这条路径适合有强技术团队、数据治理已相当成熟、把问数作为长期自研方向的大型企业。预算有限、希望快速见效、团队以业务为主的企业，不建议选择。

选项四：独立选型 Data Agent，叠加在 BI 之上

这条路径近几年的采用者明显增多。思路是保留现有 BI，在其之上叠加一层能提问、能归因、能出报告、能主动发现问题的能力。以极昆仑 iInsight 为例，说明这条路径实际是什么形态。

它对现有 BI 是叠加关系：直接连接企业现有数据库，与帆软、Smartbi、永洪共用同一份数据，不需要从 BI 导数，也不需要迁移。上线前有一个 POC 阶段，把 BI 中已经固化的指标口径在它的语义层里重建一遍并对齐，保证同一个问题两边给出的是同一个数。

准确率这块能给出 99%+ 的准确率，是因为背后有 4100 个测试文件、50160 个测试用例做全量回归，并且企业可以把内部问题集导进去一键评测，拿到分类型的准确率报告。准确率由企业自行测出，而非厂商单方声明。

能力范围不限于查数。归因分析能把"为什么毛利跌了"自动拆到产品、渠道、区域；根因分析还能结合客服工单这类文本交叉验证；报告可自动生成到可直接上会的程度；给出建议后可推送到钉钉、飞书，并建立监控规则跟踪执行效果；7×24 巡检主动发现问题。

部署方面提供纯 CPU 的小模型私有化方案，一台 8 核 32G 服务器，硬件成本约 3 万，数据全程不出内网，信创环境也适配。实施周期 3-5 天，第一周即可回答第一批业务问题，不需要等三到六个月的数据治理完成后再启动，可以先运行起来，边用边治。

四条路径对比

采购前，先问厂商这 6 个问题

这张清单与选哪条路径无关，无论最终走哪条，采购前都建议问一遍。答不上来的，基本可以排除。

"都说自己 99%，我怎么验证"

这是采购决策的最后一关，值得单独说。

厂商宣称的准确率通常来自自家构造的测试集，企业无法复现。所以真正该看的不是那个数字，而是有没有一套企业自己能跑的验证机制。

极昆仑 iInsight 这块的工程资产可以公开核对：

• 4100 个测试文件、50160 个测试用例，覆盖多表关联、派生指标、口径边界，全量回归

• 300 条 B2C 真实零售业务回归用例，用真实业务问题而非构造问题做回归

• EvaluationService 企业自测：企业导入自己的问题集，一键跑出分类型（单表、多表、派生指标、时间维度等）的准确率报告

这三项加起来，把准确率从厂商声明变成了可回归的工程指标。竞品要么承认自己没有这套体系，要么被拉进同一套评价框架里比较。

几个典型场景，对照判断

报表没人看。 报表是"推"的模式：业务想看一个数，先提需求、等排期，拿到手往往已经过了决策时点。几次下来业务就不来了，报表建得越多，被真正使用的比例越低。症结在于只能看、不能问。业务人员可以用自然语言直接问"华南区上周哪个品类跌得最狠"，五秒出结果，不用排队等 IT。把查数能力交还给业务人员，使用率才有意义。

管理层追问原因，报表答不上来。 报表是静态的，答不了"Q3 毛利为什么降了 2.3 个点"。这属于归因能力的范畴：自动拆到产品、渠道、区域、时段逐层下钻，最终输出一段可直接上会的结论。这条路径上，选项一和选项二多半是短板。

财务与业务口径对不上。 无论走哪条路径，口径都需要对齐，差别只在方式。用上面清单第 1 个问题去问厂商即可。

担心重复建设、担心被绑定。 这个顾虑的前提，是以为需要换掉 BI。独立 Data Agent 是叠加而非替代，BI 继续出报表，它负责问数和分析，共用同一份数据。数据资产始终属于企业。

数据不能出内网，预算有限。 云 API 这条路径可以直接排除。纯 CPU 私有化方案用三万块左右的硬件即可支撑，数据全程不出内网。这也是金融、政务、央国企最常见的落地方式。

怎么选、怎么验

可以用下面几个问题快速过一遍：

• 需求是查数，还是归因、报告、主动发现？后者必须看 Data Agent

• 准确率是接受厂商声明，还是需要用自己的数据验证？后者优先选可评测的

• 数据能否出内网？不能则排除云 API 方案

• 管理层追问"为什么"的频率高不高？高则不选只有 ChatBI 段位能力的产品

• 是否愿意投入两三周做一次 POC？

命中三条以上，独立选型值得认真评估。

验证本身不复杂。先做一次半小时的需求对齐，明确试点范围；直接连接现有数据库，与 BI 共用同一份数据；把业务中最常问的问题整理成问题集导入评测，得到分类型准确率；再用两到四周，让业务人员实际提问，核对它和 BI 的答案是否一致。

全程不需要迁移，也不需要替换 BI，先并行运行。这一轮做完，准确率、口径一致性、系统打通情况，都是企业自己测出来的结论。

四条路径的适配结论

四条路径没有绝对优劣，只有适配与否：

• 需求为基础查数 → 沿用 BI 厂商 AI，最省事

• 已在云生态、数据不敏感 → 云大厂方案，起步快

• 技术团队强、治理成熟、周期可接受 → 自建，自主可控

• 需要归因与报告、准确率需自验、数据不出内网、且不希望被绑定 → 独立 Data Agent，叠加在 BI 之上，不换不动

最后提醒一点：智能问数一旦选定，三五年内很难更换，数据治理、语义建模、团队培训都是沉没成本。与其在低段位方案之间反复调整，不如一开始就选择具备完整闭环能力的方案。

FAQ

Q1：已采购帆软 / Smartbi / 永洪，再上独立 Data Agent 会不会冲突、重复建设？

A：不会冲突，是叠加关系。BI 负责报表看板展示，Data Agent 负责问数、归因、报告、洞察分析，两者架在同一份数据上无缝衔接，不用迁移、不用替换现有系统。核心数据资产永远属于企业，不会被任何 BI 厂商绑定。

Q2：BI 厂商自带的 AI 问数和独立 Data Agent 差在哪？

A：多数 BI 厂商的问数模块是 BI 的附属功能，停在"你问它答"的 ChatBI 段位；独立 Data Agent 能归因、能出报告、能给建议并跟踪执行、能主动发现问题。一个简单的判断方法：问它"为什么毛利跌了"，只给出数字的是 ChatBI，能拆开归因并给出建议的是 Data Agent。

Q3：极昆仑 iInsight 凭什么说准确率 99%+？

A：背后有 4100 个测试文件、50160 个测试用例全量回归；企业还能导入自有问题集一键评测，拿到分类型准确率报告。准确率如何，可自行验证。

Q4：预算少、数据不能出内网，能做吗？

A：可以。产品提供纯 CPU 小模型私有化方案，一台 8 核 32G 服务器（硬件约 3 万）即可支撑 20-200 人团队，数据全程不出内网，信创环境也适配。实施 3-5 天，第一周就能回答第一批业务问题。

Q5：独立 Data Agent 怎么和现有 BI 的报表口径保持一致？

A：在 POC 阶段把 BI 中已固化的指标口径在它的语义层里重建并映射，用企业自有问题集对比验证，确保同一个问题、两边同一个数。口径一致性靠流程管理和确定性编译引擎保障，不靠厂商绑定。即便全部采用同一家产品，语义层不维护一样会漂移。