这两年 ChatBI 很火，几乎所有主流 BI 厂商都上线了对话式分析功能，但热闹归热闹，真正能落地的并不多，有调研显示，90% 已部署 ChatBI 的企业，业务部门实际使用率不足 30%；更有数据显示，ChatBI 功能上线 3 个月后的周均使用率不足 15%，八成以上企业的 ChatBI 最终沦为摆设，问题出在哪？

ChatBI 有两环
第一环是智能问数，也就是用自然语言查询数据——你说一句“帮我查一下北京发往青岛的订单”，系统返回一张数据表
第二环是智能报表，针对查询后的数据做多维分析报表——分组、汇总、排名、算环比、加图表、调格式，所有这些操作，用说话来完成

智能问数：困在幻觉里

智能问数的主流技术路线是基于 LLM 做 Text2SQL——大模型把自然语言翻译成 SQL，去数据库里查，这个路线有一个根本性的缺陷：幻觉
据 2026 年的测试统计显示，即使是最先进的大模型，在 Text2SQL 任务上的准确率也仅有 64.5%——每三个 AI 生成的 SQL 查询中，就有一个可能存在问题
为了缓解幻觉，业界想了不少办法，比如引入中间层 DSL，通过 "降智" 换取准确性提升，效果确实有——准确率从 60% 多拉到了 80-90%，但这远谈不上 "解决"，只是把问题缩小了，并没有消灭它
如果这仅剩的 10% 幻觉能够被业务人员识别出来，那倒也还能用——毕竟人机协同嘛，AI 打底稿、人来审核，但问题恰恰在这里：不管是大模型直接生成的 SQL，还是经过中间层转换的 DSL，对业务用户来说都是黑盒，他们既看不懂，也无法判断对错，更不知道错在哪，对于严肃的企业数据分析场景来说，90% 准确率但无法定位错误的产品是不可接受的

智能报表：被忽视的第二环

第一步还没走稳，自然顾不上第二步， 这是大多数 ChatBI 解决方案的现状

当前几乎所有 ChatBI 的关注点都在第一环，LLM 在 Text2SQL 阶段还在被幻觉困扰，准确性问题都没解决，基本没有余力向后端报表延伸
用户问完数，得到的结果只是粗线条的数据表格展示，后续的分析工作——分组、汇总、排序、算指标、调格式、加图表——还是要回到传统界面手动拖拽分析

而且智能报表多维分析面临的数据困境其实比 SQL 更严峻，SQL 作为通用查询语言，有海量公开代码可供训练，而多维分析报表是一连串有状态的操作序列——分组、汇总、环比、格式化——环环相扣，且每步都绑定特定 BI 工具的上下文，这种“BI 操作 - 自然语言”的配对数据在现实中少之又少，LLM 既缺乏学习样本，也难以在推理时兼顾步骤间的逻辑依赖，自然无法可靠地规划和执行整个流程
有些 ChatBI 解决方案也可以利用 LLM 生成一些图表，但仍然是个黑盒，用户发现有细节不合适也只能全部重新生成，结果改了旧问题又出现新问题，没完没了，永远也得不到期望的结果

润乾智能报表的新思路

既然大模型这条最热闹的路走不通，那有没有人走了不一样的路？有，润乾报表就绕开了 LLM 推理的泥潭，从规则引擎和规范文本的角度另起炉灶

它的思路是：不把宝全押在大模型上，不用 LLM 做推理执行，只用 LLM 做翻译， 让 LLM 回到它最擅长的领域——理解自然语言、做翻译，把自由随意的命令，翻译成较为规范的人机都可读的规范命令，而执行则交给自创的规则引擎来做，确保 100% 准确执行

基于这个思路，润乾 NLQ（智能问数）彻底解决了幻觉引发的不可靠问题

传统方案里，LLM 生成的 SQL 或 MQL 对业务用户是黑盒——看不懂、没法验证、错了也不知道，而润乾的方案里，LLM 把口语转成规范文本，也还是汉语，是人类可确认，机器可解析的汉语命令，虽然它也可能有幻觉，但业务人员一眼就可以看出来翻译的对不对，可以直接定位问题并纠错，这样幻觉的问题就解决了，就能保证产品的可靠性了

润乾 NLR（智能报表）同样采用这一思路

不是让 LLM 直接生成报表，而是让它规范用户的命令，然后用规范后的自然语言指令，通过规则引擎精准匹配到报表的每一个操作动作，精准生成报表

它可以一步步制作，比如先做一个简单表样出来，再一步步完善，过滤数据，增加统计项，设置显示格式，增加同环比，排名等
每一步一个命令，像下面这样分步操作

还可以利用 LLM 一步到位做报表，把整体需求说出来，“LLM 规划”功能会自动拆分成多个规范命令，然后一次性整体执行或分步执行出结果
比如输入：
只要订单金额超过 5000 的数据，然后按省份和年份分组汇总订单金额，再计算省内金额比例环比，环比以百分比显示，金额按货币格式
点击 LLM 规划，就可以把任务拆分成下图左面的 6 个分步指令了，然后就可以单条执行或者全部执行了

执行后的结果

这样的架构既保留了 LLM 带来的交互友好性，又通过规则引擎锁定了执行的精确性，杜绝了 AI 幻觉
更关键的是，这里每一步都是白盒可见的，可以局部调整，既使 LLM 有错误也可以被人类校正而逐步收敛，也就避免了改了这里又冒出那里的没完没了问题

这种方案还有个优势，低成本与高安全：由于 LLM 仅负责“文字规范化”的任务，难度较低，不需要海量推理资源，也就不用担忧 Token 的过度消耗, 甚至想私域部署都可以，小参数模型就能胜任，而且不管哪种方式，数据代码都不出私域，也更容易满足企业安全合规的要求

结语
ChatBI 的两环，现状都不是很乐观
智能问数这一环，大家扎堆用 LLM 做 Text2SQL，看似繁荣，但却被幻觉困扰的极其难落地，智能报表这一环，大多数厂商第一环都没走稳，也没精力去顾及
润乾报表提供了一种不同的思路：用规则引擎做骨架、用 LLM 做翻译
这条路能不能成为行业的主流方向，还有待时间检验，但至少，它目前是可落地可信赖，可实实在在提升效率的——在 AI 时代做智能问数和智能报表，不一定非要让 AI 替你做决定，让 AI 帮你把话说清楚，可能更靠谱