2023年秋天，国产BI厂商几乎在一夜之间都发布了ChatBI产品，口径出奇一致：业务人员不用学SQL，不用找分析师，一句话就能查指标、出图表、做分析。瓴羊有QuickBI智能问答，衡石推Text2Metrics，SmartBI、永洪、亿信华辰也都跟进了类似能力。其中两家头部厂商后来的转型过程最具代表性，为便于讨论，下文分别称它们为A软和B远。
内容提要/OVERVIEW
本文由「CIO之家」原创首发，数字化企业经授权发布，e-works在文首添加了少许内容。参考与数据来源说明：本文数据与案例主要来自B远客户成功团队的公开复盘文章、A软官方公众号的系列复盘、衡石科技Text2Metrics技术深度文、A软官方产品材料，以及各厂商公开标杆客户项目复盘。所有量化指标均标注了对应口径与样本范围，供读者核验。文中两家厂商名称已做匿名处理。
01
先简单了解下什么是ChatBI？
本段内容为e-works编辑添加。
ChatBI（ChatBusinessIntelligence）是一种将大语言模型（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走向DataAgent的样本。
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软的架构级重构：DataAgent+AI原生版双线
A软没有继续硬扛自由问答，而是做了一次架构层面的切换：AI不再被允许直接生成裸SQL去查底层表，角色从“写SQL的助手”变成“调度者”——调用的是平台已经审核、校验、血缘可追溯的BI资产，包括指标、计算字段、报表组件和钻取逻辑。这一步值得所有ToB从业者反复咀嚼。
落地分成两条产品线。
其DataAgent平台面向存量BI客户。执行链路从“自然语言→SQL”改成“自然语言意图解析→匹配指标中心或已发布报表组件→调用BI内置计算引擎（DSL）”，不再生成SQL。优先场景收敛为报表解读、指标异常归因、自动经营报告、预警推送，以及辅助分析师写计算字段。自由取数能力被严格限定在已经入库、口径备案的指标池内。每一次AI输出都附带血缘、指标版本、口径说明和权限过滤日志，以满足财务、集团审计和等保要求。
AI原生版BI平台则面向新建数据体系。AIAgent是原生内置能力，底座就是指标语义层，指标治理是前置的强制环节——不治理指标，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越自由，结果越不可信，也越没人敢用。
第二，新一代DataAgent的落地范式已经收敛，而且高度一致：指标治理、语义层前置，是上线的前提，不是可选的增值；AI优先做解读、归因、预警、报告和辅助分析师，而不是优先做无边界的探索式取数；必须有可审计、可追溯的链路，结果责任归属明确；场景收敛，窄场景深耕，拒绝“什么问题都能回答”的宣传承诺。
第三，矛盾依然尖锐。市场销售团队还在沿用第一代ChatBI的话术（“一句话查所有数据”），客户成功和产品研发团队却已经全部切换到“指标中心+DataAgent”的范式。这个错位，正是大量客户POC惊艳、上线翻车的根源，也会是未来两年行业最大的信任危机。
ChatBI时代没有真正终结。它以另一种更克制、更可信、更负责任的形式重生，也就是DataAgent。它学会的第一课并不复杂：让AI自由，不如让AI可信。