（来源：数字化企业）

　　2023年秋天，国产 BI 厂商几乎在一夜之间都发布了 ChatBI 产品，口径出奇一致：业务人员不用学 SQL，不用找分析师，一句话就能查指标、出图表、做分析。瓴羊有 QuickBI 智能问答，衡石推 Text2Metrics，SmartBI、永洪、亿信华辰也都跟进了类似能力。其中两家头部厂商后来的转型过程最具代表性，为便于讨论，下文分别称它们为 A软和 B远。

　　内容提要/OVERVIEW

　　本文由「CIO之家」原创首发， 数字化企业经授权发布，e-works在文首添加了少许内容。参考与数据来源说明：本文数据与案例主要来自 B远客户成功团队的公开复盘文章、A软官方公众号的系列复盘、衡石科技 Text2Metrics 技术深度文、A软官方产品材料，以及各厂商公开标杆客户项目复盘。所有量化指标均标注了对应口径与样本范围，供读者核验。文中两家厂商名称已做匿名处理。

01

　　先简单了解下什么是ChatBI？

　　本段内容为e-works编辑添加。

　　ChatBI（Chat Business Intelligence）是一种将大语言模型（LLM）与商业智能（BI）系统相结合的应用形态。它的核心理念：让用户通过自然语言（就像和真人聊天一样），直接进行数据查询、图表生成和商业洞察，从而打破传统 BI 需要写 SQL、拉表格、找数据分析师的门槛。

　　在理想状态下，它的交互就像这样：

　　你：“查一下上周华东地区的零食销量，顺便看看哪个门店拖后腿了？”

　　ChatBI：直接吐出销售额曲线图、环比数据，并用文字总结：“华东区上周总销量环比下降 5%，其中 XX 门店由于库存周转慢、跌幅最明显，建议重点关注……”

　　1.1

　　一个具体的落地例子

　　以连锁零售门店的经营复盘为例，我们可以对比一下“传统 BI”和“ChatBI”的区别：

　　1. 传统 BI 的做法：

　　● 业务员：想看上周各门店的经营情况，不会写 SQL。

　　● 流程：业务员向数据分析师提一张“取数工单” → 分析师排期、写 SQL 从数仓拉数据、做成看板 → 几天后交付给业务员。

　　● 痛点：链路长、响应慢。业务想临时多加一个筛选条件（比如“只看单价大于 50 元的零食”），又得重新找分析师。

　　2. ChatBI 的理想做法：

　　● 业务员：直接在对话框输入：“帮我拉一下上周华东区所有门店的零食销售额，按品类做个降序柱状图。”

　　系统背后发生的事情：

　　● 意图解析：大模型理解“上周”（时间范围）、“华东区”（地域筛选）、“零食”（品类标签）、“销售额”（指标）。

　　● 转译与查询：模型将其转化为底层数据库能看懂的查询指令（如 Text2SQL 或调用语义层指标）。

　　● 结果呈现：系统直接在聊天窗口渲染出柱状图，并附带简单的数据解读。

　　资本和舆论当时的判断更激进：自然语言直连 SQL，是数据分析平民化的终局。顺着这个判断，分析师要被淘汰，报表中心要消失，取数工单要归零。

　　两年多过去，行业交出的答卷是反面。

　　2026 年，B远的客户成功团队做过一轮公开调研，样本是 300 家营收 5 亿元以上、数据团队不少于 5 人的零售、制造和金融企业，且都在 2025 年 1 月至 2026 年 6 月之间上线了 AI+BI 工具。按“每周至少主动发起 1 次 ChatBI 查询的业务用户”除以“BI 平台总活跃业务用户”计算，上线满 3 个月后，ChatBI 周均使用率不足 15%，81% 的企业把它用成了演示工具，日常生产完全不用。

　　这不是孤例。多家厂商的一线交付团队给出了同向的样本结论：已部署 ChatBI 的企业里，超过 90% 的业务部门实际使用率不足 30%。大部分用户只在培训现场和 POC 演示时用过几次，随后回到固定报表、Excel，或者继续找分析师提工单。

　　A软内部的对照更直白。它做过一次“AI+BI 对照实验”：传统 BI 看板周活跃用户约 100 人，接入自家 ChatBI 产品后，周调用量涨到 600 人以上。十倍增长，拆开看却是另一回事——90% 的有效查询是“今日营收多少”“线索量多少”这类单指标、单条件问题；一旦涉及费用分摊、同比口径修正、跨部门合并，错误率就断崖式上升。这类复杂提问占 22%，却贡献了全部的用户投诉。高管的反应很实际：不敢拿它做经营决议，继续看固定经营看板。

　　这个行业切片可以用一句话概括：POC 惊艳，生产坍塌；简单可用，复杂翻车；演示很强，日常不用。

02

　　从 POC 神话到生产废墟：ChatBI 的三段式落地现状

　　要判断 ChatBI 为什么失败，先看它死在哪个环节。一线交付实践大致能把它切成三个阶段，而失败率在三段之间极不对称。

　　2.1

　　第一段：POC 阶段，通过率高达 90%

　　POC 阶段的答卷几乎总是漂亮的。原因不难理解：POC 环境是厂商和客户一起布置出来的。主题被严格限定，比如只开放“门店销售日度指标”；提前录入几十条样例问答，让大模型有充分的 few-shot 参考；脏数据清洗过，字段注释临时补齐；口径也统一过，哪怕只是演示口径。

　　这套条件下，简单查询的准确率普遍能做到 80% 以上，演示效果极强。厂商在 POC 汇报里的承诺也随之变得具体：分析师 80% 的取数工单可以由 AI 承接，响应周期从 15 天压缩到 1 天。

　　A软披露过一组对外宣传数据：在自家 ChatBI 产品帮助下，业务人员“找数据”的平均时间从 5 个小时缩短到 3 分钟，缩短了百倍；这款产品也通过了中国信通院智能分析 BI 标准认证。这些数字是真的，问题在于它们几乎全部产自 POC 环境或受控试点——而这两者恰恰是真实生产环境里最稀缺的条件。

　　2.2

　　第二段：开放试点阶段，失败高发区，约 80% 试点卡死在这一步

　　把 ChatBI 从封闭主题放开到全量数据表，问题立刻显形。开放试点的本质，是三个变量同时变化：数据源从几张准备过的表变成数百张原始表；口径从两三个统一版本变成十几个甚至几十个互相矛盾的版本；计算逻辑从“SUM 一个字段”变成分摊、返利、计提、工单、跨系统对账。

　　衡石科技在一篇技术深度文里给出过一条很具体、可复现的 Text2SQL 准确率衰减曲线，行业里普遍把它当作国内同类 Text2SQL 方案的共性基线：

　　这组数字几乎是一份判决书。单指标、单维度的简单问题还有 65% 的准确率，一旦进入带同比环比、多维交叉、跨表关联的复杂问题，准确率直接跌到 18%，甚至 8%。而企业真正需要分析的恰恰是后者——简单问题，业务自己看看板就够了。

　　生产环境的翻车因此几乎是注定的：ChatBI 把最难的业务语义推断，交给了并不掌握企业业务上下文的大模型去猜，而猜中的概率随问题复杂度指数级衰减。

　　2.3

　　第三段：规模化推广，极少成功

　　真正走到全公司规模化推广的 ChatBI 项目极少，且几乎都满足一个苛刻前提：严格收敛到固定的高频指标池、封闭的业务场景，并有人专职或兼职持续维护知识库与样例集。

　　成功样本也高度集中：连锁零售门店的日度经营复盘，比如店长查自己门店的品类销售和库存；制造车间的高频产能、良品率指标查询。至于财务、集团合并、成本分摊、多系统对账这类高合规、强考核场景，几乎没有企业敢让自由问答直接上线。原因不复杂：这些场景的每一次出错都连着考核、预算和对外披露，责任归属无法界定。

03

　　初代 ChatBI 大面积失败：五重底层困境

　　把三段现状摊开，失败原因已经呼之欲出。技术、治理、预期、权责、ROI，五个维度各有一笔账。

　　3.1

　　困境一：Text2SQL 天生解决不了企业私有口径的语义歧义

　　大模型擅长自然语言，不擅长理解企业私有、模糊、随时变化的业务口径。这是第一代 ChatBI 的根源性技术缺陷，不是工程细节。

　　同一个词“毛利”，在不同企业、甚至同一企业的不同部门，就有含税与不含税、是否扣返利、是否分摊费用、按发货口径还是按确认收入口径等十几种定义。同一个“销售额”，在数据库里也可能对应下单金额、实付金额、应收金额、剔除退款金额四个完全不同的字段。大模型没有这些业务上下文，只能靠字段名的字面匹配去猜。

　　B远复盘过一个很典型的极端案例。某区域连锁零售企业的 ChatBI 试点里，运营人员问“上周华东区的零食销售额”，大模型先后返回了 3 个差值超过 200% 的结果。排查后发现，数据集里有 5 个名称都叫“销售额”的字段，分别对应 5 种统计口径：含退款与不含退款、含优惠分摊与不含分摊、按发货与按签收……大模型每次随机挑一个字段去算，结果自然每次都不一样。上线一个月，ChatBI 周使用率不到 5%，业务彻底弃用。

　　业内把这称为“SQL 幻觉”。它的棘手之处不在于语法，而在于语法完全正确、查询能跑通、还能给出一个看上去非常合理的数字，但业务口径是错的。更麻烦的是它不可溯源、不可审计：出了错，业务和数据团队分不清是模型理解错了、字典没维护，还是底层数据本身就脏。于是没人敢拿它做经营决策。

　　3.2

　　困境二：治理前置缺失，ChatBI 放大的是数据混乱，而不是修复混乱

　　ChatBI 的逻辑前提，是已经完成指标治理、统一指标字典、数据血缘和权限体系。换句话说，ChatBI 是治理的产物，不是治理的起点。

　　而国内多数企业的底座，恰恰是这套前提的反面：数仓不规范，指标散落在数百张报表里，口径靠口头约定，同一个指标存在多个版本却没有变更记录。厂商把 ChatBI 包装成“数据治理的解药”，这句话误导了大量客户——让人误以为买个大模型工具就能把混乱的数据用起来。

　　一线的结论是反过来的：底座脏，ChatBI 只会把脏数据自动包装成漂亮图表，加快错误数据在业务侧扩散。B远的客户成功团队 2026 年统计过 120 家上线 ChatBI 的客户，口径是“字段业务语义标注覆盖率”与“用户问数准确率”的关联。业务语义覆盖率低于 70% 的项目，问答准确率稳定在 40% 以下，基本没有实用价值；覆盖率达到 90% 以上的项目，初始准确率就能做到 85% 以上。治理做没做，直接决定 ChatBI 是工具还是摆设。

　　3.3

　　困境三：用户预期错配，高估了业务人员的提问能力

　　厂商对 ChatBI 用户的假设是，业务人员清楚自己要什么，能说清维度、筛选条件和统计周期。现实恰好相反。业务用户之所以找分析师，本身就说明他不知道怎么把问题拆解清楚。他们的提问天然模糊、跳跃、缺条件，“最近销量怎么样”“哪个门店拖后腿了”就是典型。在自由 Text2SQL 模式下，这类模糊提问的错误率超过 65%。

　　容忍阈值同样被高估。多家厂商的客户成功统计指向同一个结论：只要连续两次拿到错误数据，业务人员就会永久放弃 ChatBI，并且不再采信 AI 返回的任何数据。信任需要几十次正确来建立，两次错误就能摧毁。

　　3.4

　　困境四：权限与行级过滤叠加后，可用范围急剧收缩

　　权限是最容易被忽略、也最容易走极端的一环。放得太松，所有用户都能查全量数据，财务成本、客户隐私这类敏感数据直接暴露，风控部门会叫停整个功能。卡得太死也不成立：严格做行级隔离之后（比如店长只能看自己门店的数据），大模型生成 SQL 时经常遗漏权限过滤条件，返回“无权限访问对应数据集”。用户提 10 次问，6 次报错无权限，试错三次之后就不会再用了。

　　B远还复盘过一个装备制造的案例：生产部门人员用 ChatBI 查生产进度时，会连带返回财务的成本、利润数据，存在严重合规风险，项目差点直接关停。权限问题本质上是另一层面的不可控——它让 ChatBI 要么因数据泄露被叫停，要么因频繁报错被用户抛弃。

　　3.5

　　困境五：ROI 倒挂，维护成本是长期持续性的

　　ChatBI 不是一次性上线交付，而是一个需要持续运营的“活系统”。业务术语变更、新增指标、口径调整、字段改名，每一项都要同步维护知识库和样例集；一旦停止维护，准确率就会快速下滑，用户很快放弃。

　　B远的客户成功团队算过这笔账。一个中等规模的制造企业，要把 ChatBI 的准确率稳定做到 75% 以上，需要投入数据分析师加数据治理专员，每周 4–8 小时持续维护指标词典、样例 SQL、业务术语、时间规则和口径变更记录。折算下来，每月维护成本约等于两名分析师 15% 的工作量。而这些取数需求原本靠固定报表加定期更新就能覆盖，工作量更低。

　　于是行业里出现了一个怪象：大量客户买了 ChatBI，反而新增了一个专职的“ChatBI 知识库运维岗”，ROI 为负。治理的人力成本，远高于分析师直接做报表的成本。

04

　　A软：从“AI 去数据库里猜”到“调用可信 BI 资产”

　　A软是国内头部 BI 厂商之一，也是最早一批推出 ChatBI 的厂商。它的失败复盘和转身路径，几乎可以当作整个行业从第一代 ChatBI 走向 Data Agent 的样本。

　　4.1

　　初代 ChatBI 的原始路线

　　2024 年主推的初代 ChatBI，架构是标准的 Text2SQL：用户用自然语言提问，LLM 直接生成原生 SQL，直查底层数据集或数仓表，再返回图表。对外宣传口径是“一句话问数、业务自助分析、取数时间从 5 小时缩短至 3 分钟”；在封闭主题的 POC 里，简单查询准确率能做到 82% 以上。

　　4.2

　　A软内部复盘的典型失败试点

　　A软官方公众号做过一组针对大模型的祛魅式复盘，其中披露了多个陪跑项目的真实失败过程。

　　案例 A：某大型装备制造集团试点 A软 ChatBI（2024 年 Q2）。

　　集团上线原有 BI 平台多年，但指标没有统一管理，生产、质量、财务各有一套产能和损耗口径。项目直接开放 ChatBI 对接数仓原始表，没有做指标语义层。结果，同样一句“本月车间良品率”，不同业务人员提问返回的结果相差 17%。原因是良品率存在按送检基数、按投产基数、按入库基数三套口径，大模型随机关联质检表、工单表、入库表，SQL 语法全部正确，业务口径却全错。生产部门拿 AI 数据去做车间考核，引发车间投诉，数据部紧急把 ChatBI 限制为只允许内部团队测试。上线 45 天，周使用率从试点初期的 32% 跌到 2.7%。

　　A软的结论下得很重：裸 Text2SQL 路线无法承载集团级的多口径、强考核场景。好看的 Demo，不等于生产级可信。

　　4.3

　　A软的架构级重构：Data Agent + AI 原生版双线

　　A软没有继续硬扛自由问答，而是做了一次架构层面的切换：AI 不再被允许直接生成裸 SQL 去查底层表，角色从“写 SQL 的助手”变成“调度者”——调用的是平台已经审核、校验、血缘可追溯的 BI 资产，包括指标、计算字段、报表组件和钻取逻辑。这一步值得所有 ToB 从业者反复咀嚼。

　　落地分成两条产品线。

　　其 Data Agent 平台面向存量 BI 客户。执行链路从“自然语言 → SQL”改成“自然语言意图解析 → 匹配指标中心或已发布报表组件 → 调用 BI 内置计算引擎（DSL）”，不再生成 SQL。优先场景收敛为报表解读、指标异常归因、自动经营报告、预警推送，以及辅助分析师写计算字段。自由取数能力被严格限定在已经入库、口径备案的指标池内。每一次 AI 输出都附带血缘、指标版本、口径说明和权限过滤日志，以满足财务、集团审计和等保要求。

　　AI 原生版 BI 平台则面向新建数据体系。AI Agent 是原生内置能力，底座就是指标语义层，指标治理是前置的强制环节——不治理指标，AI 分析能力就不开放。

　　A软对交付团队也下了硬约束：不再接受“直接接数仓、上线 ChatBI”的需求。交付清单强制包含指标字典、口径文档、样例问答库和权限规则；治理验收不通过，AI 问答不开放。

　　转型前后的差别可以用一句话概括：转型前是 AI 去数据库里猜，转型后是 AI 在可信 BI 资产池里调用已经定义好的分析逻辑。

05

　　B远：从“一句话问数”到“指标中心双引擎”

　　B远是国产 BI 里最早高举“业务用数、降低门槛”大旗的厂商，主打连锁零售和快消行业。它的路线和 A软不同，但同样撞上了使用率这堵墙，也给出了另一种解法。

　　5.1

　　初代 ChatBI 的原始路线

　　B远初代 ChatBI 的架构是自然语言意图解析、业务知识库、样例 SQL 库和 Text2SQL 的组合，比 A软初代多了一层人工样例兜底，也更侧重零售连锁门店场景，面向店长和区域运营人员自助问数。它本质上属于“强人工标注换准确率”的模式：靠管理员持续维护样例问答和术语词典。这种模式在零售这类指标相对收敛的行业勉强可用，放到复杂的制造、财务场景，维护成本立刻爆炸。

　　5.2

　　B远公开复盘的失败与改造案例

　　案例 A：某区域连锁超市 ChatBI 试点（2024 年 Q3）

　　项目初期为了快速上线，跳过了指标中心建设，直接接入销售 ODS 宽表，只简单标注了字段注释。上线初期 POC 准确率 74%，但进入真实运营后，同一个问题会多次返回不同数值：问“上周销售额”，模型随机选用含退款或不含退款、含优惠券分摊或不分摊的口径。业务语义覆盖率只有 58%，低于 70% 的安全阈值，问答准确率跌到 37%。店长不再使用，继续等总部每周发 Excel。周使用率 4.8%，项目停滞。

　　改造动作是重做 ADS 统一宽表，在指标中心固化“销售额 = 用户实付、剔除退款、优惠分摊”，录入 300+ 门店高频样例问答，并配置术语词典（上周 = 自然周、上月 = 自然月）。改造后准确率提升到 92%，稳定场景下店长周使用率提升到 65%，样本为 12 家门店试点。

　　案例 B：某食品集团渠道业务（先失败后改造的标杆，公开复盘）

　　第一阶段裸跑，没有指标中心，直接对接多渠道原始订单、发货、对账表，ChatBI 初始准确率只有 60%。渠道运营经常拿到和财务对账报表不一致的渠道回款数据，业务投诉不断，不敢拿它做渠道返利核算。

　　第二阶段改造：建设统一指标中心，把渠道回款、铺货、动销全部固化口径，搭建样例问答库，并增加 Agent 自检机制——生成 SQL 后自动与指标定义比对，冲突则拒绝执行并提示。改造后准确率提升至 92%；上线 3 个月活跃用户占比 52%，累计处理取数需求 3000+。这个项目成了 B远对外主推的标杆，用来证明：ChatBI 不是不行，无治理的 ChatBI 才不行。

　　5.3

　　B远的产品调整：决策智能平台 + 指标中心双引擎

　　B远没有在架构上放弃对话取数，而是给 ChatBI 加了一道强制边界：指标中心。问答被锁在指标中心之上，价值重心则向上移到决策智能平台。

　　产品首先按 Agent 分层。问数 Agent（原 ChatBI）只允许调用指标中心内已审核、已上线的指标，底层原始表不直接开放给 LLM，不在指标中心登记的字段 AI 无法查询，从源头堵住乱生成 SQL。洞察 Agent 则承担价值重心，做自动异常拆解、大促复盘、门店诊断和经营报告生成。后者才是 B远现在对外宣传的核心，而不是一句话取数。

　　交付模式随之收敛。B远不再承诺“随便问任何数据”，改为限定场景、限定指标集、行业模板先行，零售会员、促销、门店诊断都有模板包；复杂的财务和成本分摊场景，默认关闭自由问答。

　　后台管控也在加强。管理员可以配置推荐问题清单，配置高风险关键词拦截（成本、毛利分摊、合并对账），并让系统优先返回已有看板而不是生成新 SQL。用户标记错误答案后，自动回流知识库，管理员审核后再补充样例。

　　验收标准则被固化成了数字：试点阶段，限定主题内准确率 ≥ 80%，且周使用率稳定 ≥ 40%，才启动全部门推广；不达标就暂停开放，回炉治理指标。

　　5.4

　　两家厂商转型路线的差异

06

　　后 ChatBI 时代的行业共识

　　把 A软和 B远两条路线并排放，会发现表面分岔、底层同源。这个共识不是设计出来的，是两年、数百个失败项目换来的。

　　第一，死的不是“对话式 BI”，而是“无边界自由 Text2SQL”。幻想的破灭点在于，以为大模型可以绕过数据治理、绕过指标口径、绕过业务规则，直接解决取数痛点。事实证明，没有指标治理与语义层的约束，模型生成的 SQL 越自由，结果越不可信，也越没人敢用。

　　第二，新一代 Data Agent 的落地范式已经收敛，而且高度一致：指标治理、语义层前置，是上线的前提，不是可选的增值；AI 优先做解读、归因、预警、报告和辅助分析师，而不是优先做无边界的探索式取数；必须有可审计、可追溯的链路，结果责任归属明确；场景收敛，窄场景深耕，拒绝“什么问题都能回答”的宣传承诺。

　　第三，矛盾依然尖锐。市场销售团队还在沿用第一代 ChatBI 的话术（“一句话查所有数据”），客户成功和产品研发团队却已经全部切换到“指标中心 + Data Agent”的范式。这个错位，正是大量客户 POC 惊艳、上线翻车的根源，也会是未来两年行业最大的信任危机。

　　ChatBI 时代没有真正终结。它以另一种更克制、更可信、更负责任的形式重生，也就是 Data Agent。它学会的第一课并不复杂：让 AI 自由，不如让 AI 可信。