从可确认的取数、可编辑的制表，到企业级 DataAgent

导语：热词很多，但 BI 到底换掉了什么

ChatBI、智能问数、Text2SQL、DataAgent、Agentic BI……这两三年，BI 赛道的新词密度大概超过了过去十年的总和。RAG 增强、模型微调、语义层、本体化语义层、元数据图谱、NL2Metrics、Multi-Agent 协同，方案一个比一个复杂，演示一个比一个惊艳。

但热闹之下有个更值得追问的问题：AI 加进来之后，BI 产品的形态到底应该变成什么样？

如果只是把菜单换成一个对话框，那叫换皮；如果连"用户能不能确认系统听懂了没有"都没解决，那叫把风险从界面搬进了黑盒；如果演示里什么都能查、一到自家数据就要先养一个专家团队，那叫把成本从采购合同挪到了后面三年。

本文想给出一个工程视角的答案：

AI 时代 BI 的形态变化，不是"把拖拽换成聊天"，而是"界面从 GUI 换成 LUI 之后，必须重新安放 AI 的位置"。

AI 只做语义转译；中间表示必须人类可读、可确认；执行必须交给规则引擎确定性地完成。

并且，LUI 要接管的不是一件事，而是两件事——取数和制表。只做完前半程，BI 只换了一半。

而判断一套方案是否真的完成了这次换代，有三根标尺：能不能确认、能覆盖多复杂、养不养得起。前两根决定它能不能用、够不够用，第三根决定它会不会一直被用。

全文的技术判断与产品实例，都绕着这三根标尺展开；它们最后会收敛成一句话：信得过、改得动、用得起。

一、先把传统 BI 拆开：它其实是两件事

谈"下一代形态"之前，得先说清传统 BI 在技术上到底做了什么。剥开各家产品的包装，核心能力可以拆成两块：

第一块：数据查询。

用户要一批数据，系统把需求变成 SQL（或等价的查询计划）打到数据库上，返回明细或聚合结果。

第二块：多维分析 / 自助报表。

在结果集之上做分组汇总、维度上钻下取、跨行计算（同比、环比、占比、排名）、条件格式、行列隐藏与显示格式设置。传统产品里，这块通常叫 OLAP 。它和第一块的差别值得多说一句：查询是"从库里把数据拿出来"，多维分析是"在拿出来的数据之上再做一层计算"——尤其同比、环比、排名这类跨行运算，依赖行与行之间的位置关系，是 GUI 最吃力、也最能体现一家 BI 产品功力的地方。

这两块共同的技术前提是 GUI（图形用户界面）：字段列表拖到行/列/指标区，维度拖进筛选器，点选聚合方式，再拖个条件格式。用户靠"看得见的控件"表达自己的意图。

GUI 常被吐槽"不方便"：字段多了找不到、口径藏在层层菜单里、做一个带环比的报表要七八步。但公允地说，GUI 有一个被严重低估的优点——它是精确的。

每一次拖拽都是用户亲手下达的一条明确指令，而且指令的状态一直挂在界面上：用户清楚知道自己选了哪个字段、按什么维度分组、用了求和还是计数、筛选器里填的是 2000 还是 5000。结果出来不对，也大致能回溯到是哪一步拖错了。控件笨拙、步骤冗长，但换来了一个很硬的性质：意图是确定的，且意图与执行之间没有被第三方"猜"过。

这个优点，恰恰是后来 LUI（Language User Interface，语言用户界面）最容易丢掉的东西。

二、LUI 的第一程：ChatBI 与 Text2SQL

AI 带来的最直观变化，就是界面：既然大模型听得懂人话，为什么还要拖拽？

于是有了 ChatBI（智能问数）：形式上是一个聊天框，用户说"上个月华北区签单金额按省份排个序"，系统返回一张表或一张图。技术上，这条路线通常叫 Text2SQL / NL2SQL——把自然语言文本转换成 SQL 去执行查询。

典型的链路是三段：先做 schema linking，把"华北区""签单金额"对应到库里的表和字段；再由模型生成 SQL或者某个中间DSL再转换成SQL；最后打到数据库执行。RAG、微调、语义层、多智能体规划，基本都是围绕前两段做增强。

体验上的跃迁是真实的：

不用记字段名，说业务黑话就行；

不用找菜单，一句话直达结果；

业务人员不再需要培训就能自己取数，开发团队从零散报表需求里被解放出来。

而且它天然带一个更远的想象：既然已经是聊天了，为什么不让它顺手把图表画了、把结论写了、把下一步该看什么也规划了？这就是后来 DataAgent、Agentic BI 一类说法的由来。我们留到最后一节再谈。

于是很多人的第一反应是：BI 的形态问题解决了，以后就是"一个对话框 + 一个大模型"。

但把 GUI 换成 LUI，代价是把"用户亲手下达指令"换成了"系统替用户猜指令"。控件消失的同时，那层确定性也消失了。而上面那条链路里的每一段——术语对不对、表关联对不对、最后的SQL 写得对不对——都可能飘。

三、幻觉不是“偶尔出错”，是结构性的信任问题

大模型天生带幻觉。对一个聊天场景，一句错话可以纠正；对一个经营分析场景，一次错误结果就够。

问题在于，业务用户看不懂 SQL，也看不懂等价于 SQL 的 中间DSL。系统最终输出的是一段机器中间表示，用户既无法在执行前判断"这就是我要问的"，也无法在结果出来后判断"这次是不是恰好错了"。注意这和 GUI 的差别：GUI 里每一步的意图都摆在屏幕上，LUI 里意图藏在模型内部。

于是行业里形成了一场持续数年的军备竞赛：RAG 增强、微调、Prompt 工程、语义层、多智能体规划……目标都指向同一个数字——准确率。从 70% 到 90%，再到 95%。

这里还有个连带后果常被忽略：业务人员连"这次结果对不对"都判断不了，最后要么不敢用，要么每次都找懂数据的人复核一遍。等于没省人力，还多了一层负担——工具从"替代拖拽"变成了"增加一个审核岗"。

图 1 AI 直接生成 SQL 的问题链路：口径、字段、JOIN 关系都不可见，错了也难发现

四、为什么 90% 的准确率没有意义

这个数字至少有三层水分，而且最后一层是致命的。

分母陷阱

同样是"90% 准确率"，测试范围可以天差地别。分母是一张单一大宽表、没有 JOIN、没有子查询、没有复杂口径时，大模型拿高分并不难；一旦涉及两三张表关联，准确率可能断崖式跌到 50%–60%；再叠加多层子查询、跨表维度对齐、复合指标计算，结果更不乐观。厂商口中的高分，往往来自最宽松的测试条件，换到真实企业的多表业务环境，数字打对折都不止。

应试困境

Spider、WikiSQL 这类公开测试集，表结构固定、提问规范，可以针对性优化模型、调试 Prompt，甚至把表结构和常见问法提前"喂"给系统。跑出来的分数只能证明"在这套题上练得好"，证明不了"在企业独有的数据模型、五花八门的业务口语里能用"。

不可判定性 —— 真正致命的一层

前两层还能靠"把测试做严"缓解，第三层是逻辑上的死结：

就算一套系统真的在真实场景达到 90% 准确率，用户也无法判断这一次查询是不是那出错的 10%。

企业经营决策不是概率游戏。80% 和 90% 对用户没有本质区别，都是黑箱输出、都要赌运气。而信任坍塌，只需要一次错误结果。

结论有点反直觉，但很硬：在黑盒生成的技术路线里，"准确率"这个指标本身就该被淘汰。 它不是不够高，而是衡量错了东西——它衡量的是"系统有多少次猜对"，而用户需要的是"我能不能确定这一次是对的"。

那么该衡量什么？先把评价坐标系换掉：

1. 执行之前，用户能不能看懂系统理解的结果，并确认"这就是我要问的"？（生死线，第五节）

2. 过了这一关，再谈通过率（真实口语提问接得住多少）和复杂度边界（多表、子查询、跨行运算覆盖多少）（第六节）。

3. 而这两根轴回答的都还是"能不能用、够不够用"。一套方案能不能在企业里活下来，还有第三根轴——实施与长期拥有成本。我们把第九节单独留给它。

五、生死线：确认层，以及润乾 NLQ 的三段式

先把判定规则说清楚，它简单到有点粗暴：

先看有没有"人类可读、可确认"的确认环节。没有，直接淘汰。过了这一关，再谈通过率、语义层、复杂计算、实施成本。能确认，就能用；不能确认，就是玩具。

一个合格的确认层需要两个条件，缺一不可：

人类可读：用接近自然语言的形式呈现查询意图，比如"去年上半年签单客户"，而不是 JSON、XML 或 SQL。业务人员不用培训就能扫一眼判断对错。

机器可解析：遵循结构化规范，能被确定性地编译成 SQL。

这两个条件必须由同一份中间表示同时满足，不能是"给人看一份、给机器跑另一份"。一旦分成两份，两份之间就又多了一层需要信任的翻译——那正是我们要消灭的东西。这也是"规范文本"这个设计看着朴素、实则很难绕开的原因。

这里还藏着一个非常关键、也最容易被糊弄过去的技术细节：

确认文本不能倒过来由 AI 根据计算逻辑生成。

一个看似聪明的做法是：先让 AI 生成 SQL（或等价 DSL），再让 AI 把这段逻辑"解读"成一句人话给用户确认。这看起来有了确认环节，实则毫无意义——AI 的幻觉可能出在生成环节，也可能出在解读环节，用户看到的确认文本和最后执行的计算逻辑之间没有任何确定性关系。确认文本与计算逻辑的关系必须是可验证的、不依赖概率模型的。

润乾 NLQ：AI 做翻译，人做确认，规则引擎做转换

润乾 NLQ（智能问数）的核心设计，就是围绕这层确认展开的三段式：

用户口语
   │  ① AI只做语义转译（不碰表结构、不写 SQL、不做逻辑决策）
   ▼
规范文本（人机双向可读）
   │  ② 用户看一眼：「对，这就是我想查的」→ 点确认
   ▼
规则引擎确定性编译
   │  ③ 规范文本 → SQL，规则驱动、可追溯、可调试，全程不再碰 AI
   ▼
查询结果

举个具体的：用户说"去年谁还没开单？"，AI 把它规整为"去年没有订单的员工"。业务人员一眼就能确认意图对不对——如果AI犯晕，把查询目标从"员工"改成了"客户"，那人可以在执行前就发现并改掉。确认无误后，规则引擎再按预定义语义规则编译成 SQL。

"确认之后不再碰 AI"这半句要较真：如果用户点完确认，后面还要靠 AI 去"猜" SQL、去"推"关联路径，那确认环节就白做了。确认的唯一价值，是锁定一个确定的输入，然后必须用确定的编译走完后半程。

这套架构里，"准确率"从执行环节消失了：

规范文本 → SQL 是 100% 确定性转换，不存在讨论准确率的空间；

AI 转译可能带来的偏差，被用户确认环节在执行前拦截；

最终交付给用户的有效结果，不是"大概率正确"，而是逻辑上的必然正确。

所以这不是"把准确率从 90% 卷到 99%"，而是换了个坐标系：不卷准确率，是因为不需要卷。评价标准随之转向真实口语的通过率和业务场景的复杂度边界——也就是第六节要讲的事。

六、别把分母做小：宽表陷阱与厚语义层

一旦不再卷准确率，很多方案会走一条捷径：简化问题。

常见的做法是把数据预先拍成一张大宽表，让 Text2SQL 只在单表上做筛选和聚合。单表、无 JOIN、无子查询，大模型确实不容易翻车，演示数据也漂亮。

但这是把分母做小了。企业级数据天然是主子表、多事实表、多层维表：订单与订单明细、订单与回款与支付、客户与区域与组织……拍成宽表意味着冗余、口径僵化、维度无法上钻下取，更意味着大量真实查询在一开始就被排除在可查询范围之外。

于是形成一个死循环：

为了保准确率 → 被迫简化语义层 → 能处理的场景越少 → 企业越用不上 → 越不敢投入把语义层做丰富 → 继续靠简化保准确率。

演示惊艳、落地残废，多半卡在这个环里。

真正的瓶颈从来不是 SQL 语法，而是业务语义。 纯大模型方案缺的不是"写 SQL 的能力"，而是一套足够厚重、足够精细的语义层。这里要补一句：语义层并不是 AI 时代的新发明，它本质上是传统 BI 建模资产的延续——主题域、维表层级、指标口径、表间关联，二十年前就在做，只是现在有了一个更直接的用处。这一点在第十一节谈数据治理时还会回来。

图 2 SQL 语法只是水面之上，真正的门槛是业务语义

润乾 NLQ 的语义层不是"给表和字段起个中文名"，而是一整套结构化业务语义体系，四大支柱：

支柱	作用	典型内容
关联体系	语义层的骨架	主子表关系、多级关联链路、同维度跨表自动对齐（订单/回款/支付三张事实表按"年"维度自动对齐）
维度体系	语义层的坐标系	层级结构（年-季-月-日、省-市-区）与上钻下取；计算维度（年龄分段、客户价值分层）
指标体系	语义层的价值核心	复合指标口径、聚合前后过滤逻辑、跨行运算（同比、环比、累积、占比、排名）
业务词典	语义层的翻译接口	把"大订单""活跃客户"这类口语映射到结构化语义对象

有了这层底座，NLQ 原生覆盖四类查询范式：单表明细、单表聚合、主子实体查询、多维对齐汇总；多表 JOIN、嵌套子查询、跨事实表按维度自动对齐、排名/占比/环比等跨行运算都在规则覆盖范围内，全程不靠模型概率生成。

图 3 润乾 NLQ 语义层的四大支柱：关联体系、维度体系、指标体系、业务词典

于是两根轴的权衡也就清楚了：

复杂度衡量系统能力的"含金量"：语义层越复杂、覆盖场景越完整，"分母"才足够大；在足够大的分母上谈通过率，才有企业级价值。为保好看的数字而把语义层砍成单表，是把能力本身当成本付掉了。

通过率衡量真实场景"接得住"：业务人员不会按字段名提问，他们会说"上个月没开单的客户有哪些""中国区的大客户都有谁"。纯规则系统直接面对口语，通过率会很难看；NLQ 用 AI 前置做"口语 → 规范文本"，把五花八门的日常问法收进系统可识别的结构里，而翻译结果仍要经过用户确认，幻觉不会传到执行环节。

在保证结果必然正确的前提下，尽可能把通过率做高、把复杂度边界做宽——这才是面向落地的思路。

七、LUI 的第二程：多维分析也要能“说”出来

到上一节为止，解决的还是传统 BI 的第一块能力：数据查询。而第二块——多维分析 / 自助报表——大多数 ChatBI 方案目前还无暇顾及：问一句、出一张表，就到头了。

这其实是个不小的缺口。第一节说过，多维分析是"在结果集之上再做一层计算"，它才是业务人员真正花时间的地方。用户想要的往往不是"给我一批数据"，而是"描述完我想要的效果，发给系统就能自己实现，不合适的地方再调整"。这就是 LUI 要接管的第二程，润乾 NLR（自然语言报表） 已经提供了这套能力。

三种用法，一条主线

NLR 把报表制作拆成一条条人机双向可读的规范命令，由规则引擎逐步执行：

图 4 口语输入 → LLM 规划 → 规则引擎 → 生成报表，中间结果白盒可查可改

① 分步输入，边做边看

每一步都实时响应，观察结果、确认无误再继续。例如做一张销售分析报表：

过滤 订单金额大于 2000

表头 客户省 签单年

订单金额求和

在客户省范围内 计算订单金额比例环比 命名为订单环比

显示为 "#0.00%"

大于 1 红色加粗

隐藏 签单年 订单金额 小于 10000

筛选 → 分组汇总 → 组内跨行计算 → 条件格式 → 隐藏明细，七步一张带环比的报表就成了。熟练用户直接输规范命令，零延迟。

② LLM 规范：把口语翻成规范句

用户说"找一下订单金额过 5000 的"，不符合 NLR 规范会查不出来。点一下"LLM 规范"，转成"过滤 订单金额 大于 5000"再执行即可。这里 LLM 只做"人话 → 规范句式"的翻译，不涉及复杂推理，小参数模型就能胜任，成本很低。

③ LLM 规划：一句话拆成多步

口语输入："只要订单金额超过 5000 的数据，然后按省份和年份分组汇总订单金额，再计算省内金额比例环比，环比以百分比显示，金额按货币格式"。系统自动拆解为 7 条规范命令：

【步骤 1】表头设置 左表头 发货省 签单年

【步骤 2】数据过滤操作 过滤 订单金额 大于 5000

【步骤 3】聚合计算 订单金额 求和

【步骤 4】组内跨行计算 在 发货省 范围内 计算 订单金额 比例环比 命名为 省内金额比例环比

【步骤 5】明细字段显示控制 隐藏全部明细

【步骤 6】格式设置 位置 订单金额 显示为 "#,##0.00"

【步骤 7】格式设置 位置 省内金额比例环比 显示为 "#0.00%"

可以"全部执行"一次出结果，也可以逐条执行、观察中间结果。注意第 6、7 步多了 位置 参数——单步操作时用户已用鼠标点中单元格，"位置"由界面选定；批量规划时没有点击动作，就必须把目标位置写进命令。这类细节正是"规范命令"作为中间表示必须完备的地方：GUI 时代由界面状态承载的信息，换成 LUI 之后必须显式写进语言里，否则规划出来的命令就落不了地。

规划不完美，但你能改得动

AI 规划会有偏差：分组顺序不对、指标名称有偏差、过滤条件遗漏。关键在于规划结果完全透明、可读、可编辑：

图 5 规划后的命令面板可直接修改参数，出错只需改一条，不必整张重做

删除多余步骤

修改某条命令参数（大于 5000 → 大于 10000）

插入新命令、调整执行顺序

重新执行，或继续用口语追加："隐藏 2025 年以外的行"

这点比听起来重要：分析是探索过程，不是一次性交付。业务人员几乎不可能第一次就把报表描述对，往往是"先出个大概，再看一眼改两处"。黑盒生成方案在这里最难受——改一个细节只能整张重来，而重来又可能改了旧错、生出新高，反复折腾。命令面板把"改"变成了一次局部编辑，使用节奏才不会被打断。

这就是"AI 规划 + 人工调整"：既借了 AI 的智能，又保留了人的控制权，比让 AI 直接吐出一张黑盒报表可靠得多。和 NLQ 的确认层是同一个设计哲学——AI 负责语言，人负责确认，规则引擎负责执行。

另外，NLQ 与 NLR 是衔接的：NLQ 在授权范围内用汉语直接向库里查出来的数据集，可以立即作为 NLR 制表的起点，从"自由取数"到"灵活制表"形成完整闭环；NLQ 侧由业务词典把术语精确映射到表、字段和计算逻辑，查询严格受用户权限约束，从机制上避免幻觉、保障数据安全。到此，传统 BI 的两块能力才算都被 LUI 接管了。

八、为什么不能让 AI 直接做自助报表：三本账

一个自然的追问：多维分析既然也能"说"，那干脆把数据全丢给AI，让它直接生成报表不行吗？

工程上要算三本账，三本都很难看。

	直接用 AI 做报表	润乾 NLR（AI + 规则引擎）
数据安全	要把数据送给AI才能生成页面，数据出域，触碰合规红线	AI 只拿到用户需求、只输出几行命令，不接触真实业务数据，数据全程留在私域；即使接公网 AI也不破边界
Token / 算力	需输入全部数据、输出渲染后的页面；2000 行与 2 万行的 Token 可能差 10 倍，token 量高出两个数量级	输入只有需求、输出只有几行命令，消耗与数据量无关；NLR 甚至可以不依赖 AI，熟手直接输规范命令，规则引擎跑在普通 CPU 上，零 Token、无需 GPU
可维护性	黑盒生成，出错没法局部改，只能整体重做，"改了旧错又出新错"，反复折腾	命令是人和机器都读得懂的中文，出错能第一时间定位，只改出错那条，不必推倒重来

第一本账最没有商量余地：数据不是随便查看的 Excel，也不是个人私有的库能随意访问，它是企业最核心的资产，大多数企业对"不出私域"是硬约束。外部 AI 分析不了内部数据——除非你把数据送出去，而那一步往往就直接卡在合规评审上。

图 6 外部 AI 访问不了内部数据，数据不出域是硬约束

第二本账的坑在于它是随数据体量增长的：一次两次看不出来，报表越做越宽、行数越来越多，成本曲线跟着数据一起涨，变成长期负担。

第三本账上一节已经展开过：分析是探索过程，改不动的结果等于没结果。

补一句容易被忽略的："LLM 可选"本身就是一种能力。NLR 的规则引擎可以独立工作，企业内网私域部署时既能享受对话式便利，也能在完全不接模型的环境里跑；即便启用 LLM 规范或规划，所需模型能力也远低于通用大模型，私有化成本可控。

九、第三根标尺：实施成本，才决定方案能不能活下来

前面八节其实都在回答两件事：准确性（第五节用确认层把"猜对的概率"从执行环节彻底拿掉）和完善性（第六到第八节把复杂度边界做宽，把取数和制表两程都交给 LUI，同时守住安全与可控）。

但一套企业级工具能不能真正落地，还有一根常被选型文档漏掉的标尺：实施成本，以及上线之后的长期拥有成本。准确和完善决定"能不能用、够不够用"，成本决定"用不用得起、养不养得住"。很多项目不是败在查不准，而是败在查准了之后没人养得起。

有句话很精准：成本不是省出来的，是设计出来的；ChatBI的实施成本，从来不由厂商定价决定，而由技术路线决定。

选型时算的那本账，通常只是个零头

很多企业选型只算软件采购费和大模型 API 调用费，觉得"一次查询几分钱"很便宜。真正落地才发现，成本大头从来不在"买"，而在"养"——要让系统在真实业务里持续能用，背后的投入远超想象。

现在行业里很少做全量微调了，主流是 RAG + Prompt 工程，看似门槛低、不用重 GPU 投入，实则成本都藏在水面下：

RAG 不是搭完就一劳永逸：业务变了要更新知识库，指标改了要调 Prompt，模型版本升级要重新适配，日常还要处理各类查询异常。每一项都是持续的、没有终点的维护。

更麻烦的是黑盒排错：查询出错了，分不清是 Prompt 问题、召回问题还是模型本身幻觉，普通开发搞不定，还需要懂大模型调优的专业人员排查。这相当于"为了坐飞机，得养个地勤机组"——人力门槛和成本都下不来。

通用模型不懂你的业务，这笔知识债得有人还

"大订单"的定义、"活跃客户"的口径、不同系统里的术语差异，这些都得人工梳理后喂给模型。不管是做知识库切片还是整理示例样本，本质都是人工沉淀业务知识，且没法跨企业复用。要保证质量，还得找既懂业务又懂数据的人，这类人才稀缺，成本自然居高不下。

更深一层，这不只是钱的问题，是组织问题：它要求企业为一个查询工具长期保留一类新岗位，而这个岗位产出的是"调好了的 Prompt 和样本"——既不算业务资产，也不算数据资产，换一家企业、换一版模型就可能作废。

修复链路的长度，才是长期成本的真身

AI 路线修复一个问题，链路是这样的：

发现错误 → 定位根因 → 补样本 / 调 Prompt / 更知识库 → 全量回归验证 → 上线

一圈走下来，少说几天，多则几周，业务等不起。更头疼的是，模型调优是全局影响：修好了这个场景，说不定另一个场景又出问题，永远在补窟窿，维护成本越滚越高。

为什么这些成本绕不开？因为 AI 天生带幻觉，要提升准确率，就必须持续注入领域知识。无论微调还是 RAG，本质都是"堆成本换更高的正确概率"，只能缓解幻觉，没法根除。投入再多人力、样本、调优工作量，也只是提高了赌对的概率，变不成 100% 的确定性。

十、换条技术路线：元数据 + 词典，把实施和维护的成本降下来

润乾 NLQ 这类规则驱动方案走的是另一条路：不让模型"记住"业务知识，而是把业务语义沉淀成企业自己的结构化资产——DQL 元数据描述物理表结构、外键关系和维表定义，汉语词典把"大客户""上月"这类口语词映射到字段视图和计算逻辑。AI 只在入口做一次轻量的"口语 → 规范文本"转译，转译结果由用户确认，之后全程由规则引擎确定性编译。对实施和维护成本而言，这意味着两件事：元数据和词典是结构化配置，写得出、改得动、能交接，是可沉淀、可复用的资产；改动是局部的，影响范围可预期。

润乾 NLQ 这类规则驱动路线的修复流程极其简单：

发现查询异常 → 定位是缺词条、映射错误还是规则未覆盖 → 补充词典配置 → 立即可用

规则引擎是确定性的，改哪里影响哪里，不需要全量回归测试，不会牵一发而动全身。一个问题的修复分钟到小时级就能完成，维护效率是 AI 路线的数十倍。

一条极简判定法则

判断一个 Text2SQL 方案的长期成本高不高，方法特别简单：就看它修复一个问题需要什么级别的资源。

需要 AI 专家调模型、改 Prompt、做全量回归的，成本低不了；

补个配置就能搞定的，成本高不了。

这根标尺也解释了为什么"准确"和"完善"不能单独当选型依据：一个能在演示里覆盖复杂查询、但每次口径变动都要拉专家团队回归两周的方案，在企业里是活不下来的。能确认决定它能不能用，复杂度决定它够不够用，成本决定它会不会一直被用。

落地动作轻还是重？

NLQ 这类基于元数据 + 业务词典的方案，落地动作就要轻得多：从数据库结构开始，梳理出 DQL 元数据（物理表结构、外键关系、维表定义）和汉语词典（词表、字段视图、维/常数词、聚合词），再配好 LLM 的"自然语言 → 规范查询文本"翻译提示词即可。和业务相关的最多就是一些例句样本，不需要标注训练数据，不需要攒大量问答库，更不需要 AI 专家团队。

更省事的是，这件工作现在可以交给AI：能读本机文件、连库读表结构、写配置文件、编译运行验证程序、把跑通的产物回填的 Agent（如 WorkBuddy/豆包），可以把繁琐易错的配置收敛成一段可复用提示词；还可以把一批带有术语和指标定义的文档直接丢给它，让它自己翻找、整理——但最后一定要人工审查：AI 会脑补、会遗漏。人负责定义规则和做判断，Agent 负责连接、生成、验证。

这又把前面算的成本账落到了地面：不需要标注样本、不需要 AI 团队、不需要 GPU、改一个词条分钟级生效。所谓"实施成本轻"不是一句形容词，是上线清单里看得见的几份配置文件和一两个工作日。

最贵的那笔钱，其实藏在下一节

而在所有实施成本里，最重、也最容易被低估的一项，恰恰是把业务语义梳理清楚：术语怎么定义、表怎么关联、指标怎么算。它既不是采购费也不是算力费，却是决定上线周期的那一项——RAG 方案要人工把它喂成知识库，词典方案要把它写成元数据。

这正好把我们带到下一个话题：数据治理。而且会看到，这笔最重的成本，有一类机构其实早就付过了。

十一、绕不开的数据治理：有底子直接复用，没底子边用边建

先回顾上一节：最贵的那笔钱，有人已经付过了

上一节说，实施成本里最重的是业务语义的梳理。这里要补一句让不少机构松口气的话：如果建设过传统 BI，这笔钱基本已经付过了，再上 ChatBI 会非常容易。

做过传统 BI，意味着至少有些数据主题是被认真整理过的：主题域边界划过、维表层级建过、指标口径定义过、表间关联在建模时理清过、历史报表和库里的数据对得上。这些恰恰就是智能问数最缺、也最贵的原料。第六节说过语义层不是新发明，是传统 BI 建模资产的延续——到这里就兑现了：别人要从零把口径人工喂给模型，你要做的只是把这份现成资产换一种格式接进来。

图 7 智能问数的业务底座：NLQ 词典连接业务语义与技术数据

所以有传统 BI 实施背景的用户，优势不是"略懂数据"，而是实施成本会出现量级上的塌缩：别人在做数据治理，你只是在做一次主题复用。它不要求把治理做到完美，只要求曾经把某一个主题做清楚过。

如果是有历史 BI 的场景，上一节那套落地动作交给AI转一圈，几乎立即就能上线。

没建过传统 BI、数据治理又混乱：还没轮到比技术就卡住了

反过来，很多没有建设过传统 BI、数据治理又混乱的场景，还没轮到比技术就卡住了——原因往往不在模型，而在用户自己的数据：

术语不统一：同一个"大客户"，销售、财务、客服三套口径；

表结构重复、不符合基本范式要求，主子关系散落在各处；

指标口径没人说得清，历史报表和库里的数据对不上。

在这种地基上，无论 RAG、微调还是语义层，都容易搞出一地鸡毛。这不是 AI 的锅，是"业务语义本来就没被定义过"，却指望模型替企业把它猜出来；而猜出来的东西又无法确认、无法局部修正——正好是前几节说过的问题在治理层的翻版。

治理不健全，也能起步，而且能反向促进治理

那没做过治理的呢？是不是得先停工半年做治理，再回来上 ChatBI？

数据治理不完善，当然会麻烦不少，但也没有那么悲观：关键不是治理完再上，而是选对技术路线，在数据治理不完美的情况下，也能落地、能验证、能逐步优化。

NLQ 这类规则驱动方案支持"配置一个、验证一个、上线一个"：

1. 拉一条明细核对："上月"是不是对应上个月？"华北"是不是对应正确的区域编码？"销量"是不是按订单金额口径？

2. 单条验证通过，映射逻辑即固化：以后所有涉及"上月""华北""销量"的查询逻辑都是对的，不会这次对、下次错。

3. 从高频词开始：先把业务最常用的几十个术语配进词典，支撑核心查询场景；边用边补充，遇到新说法就补词条，发现口径不对就改规则。

全过程可追溯、可修正、可收敛。这里和黑盒路线的差别很本质：概率模型改一处可能影响全局，词典改一处只影响这一处，所以才敢"边用边改"；也正因为敢边用边改，才不需要等治理完工。

图 8 用单条验证保证全量正确：词典映射一次验对，同类查询逻辑即固化

更重要的是：

NLQ 的元数据和业务词典本身就是一个轻量化的数据治理载体。建设ChatBI的过程，同时就是做数据治理的过程。

于是数据治理从"上线前必须完成的大工程"，变成了"每次查询都在顺手沉淀一点口径"的副产品：哪个词有歧义、哪张表关联不上、哪个指标有两套算法，都会在配置词典时被逼着摆到台面上、定下来、写进文件。对治理基础薄弱的机构，这反而是最现实的起点——先让一个主题能查、能验、能用，再一个主题一个主题地往外长。

图 9 NLQ 协助语义层逐步完善：边用边建、单条验对、逐步收敛

十二、终局形态：Chat 融进专业 Agent，BI 不再像一个“BI”

当"取数"和"制表"两段都有了可确认的 LUI、而且实施与维护成本压得住，最后一层形态变化就顺理成章了：对话框不必再是 BI 产品的门面，它可以成为专业 Agent 的一个能力。

图 10 WorkBuddy 调用润乾 NLQ MCP服务 组成 DataAgent

一个可落地的组合已经出现：WorkBuddy/豆包工作等各类AI Agent与 润乾 NLQ MCP 查询服务结合，形成能力互补——

用户意图
   │
   ▼
智能体（管"想"、管"做"）
  · 理解意图、规划执行步骤、调度工具、渲染结果
   │  调用标准工具接口（MCP / Skill）
   ▼
NLQ MCP（管"查"）
  · 把数据准确地取出来、算出来
   │  汉语书写的查询命令 → 用户可确认
   ▼
确定性结果 → 回到 Agent 的分析逻辑

这里有三个设计要点值得展开，因为它们决定了 Agent 是不是"能用在严肃场景"：

Agent 的查询动作必须可确认。NLQ 采用汉语书写查询命令，普通业务人员就能看懂；Agent 生成的查询动作对不对，用户一目了然，可以轻松确认——否则 Agent 只是把黑盒从 SQL 层搬到了工具调用层，前面五节讲的生死线等于白讲。

查询能力要给 Agent 留足空间。单表明细、计算列、多表汇总、排名过滤、环比增长等场景 NLQ 都能稳定覆盖，Agent 不必操心"这个查询能不能做"，只需关注分析逻辑本身。第六节的复杂度边界，到这里变成了 Agent 的能力天花板。

接口要标准。NLQ 已做成 MCP 服务，提供标准工具接口，智能体通过 Skill 机制接入即可，集成成本低。

Agent负责"能动手"，NLQ 负责"查得准"，两者合在一起，DataAgent 的链路才真正闭环：可落地、可验证、可扩展。到这一步，用户面对的已经不是一个"BI 系统"，而是一个懂业务、能规划、能动手、且每一步数据动作都看得懂的助手——传统 BI 的外壳被彻底摆脱了。

回看第二节埋的那条线：ChatBI 天然指向 DataAgent。但只有当底下垫着可确认的查询、可编辑的制表、以及养得起的实施成本时，这条线才走得通；否则 Agent 越聪明，把错误结果包装得越像结论，反而越危险。

结语：把满足需求的成本降到最低

报表需求的持续产生，是业务动态发展的自然结果。软件厂商和企业的关键任务，从来不是消除需求，而是把满足需求的成本降到最低。

回到开头的那条主线，评价一套加持了 AI 技术的 BI，其实就三根标尺：

能不能确认（准确性）：AI 的输出必须是人类可读的中间表示——规范文本、规范命令——而不是 SQL、JSON 或一张直接吐出来的黑盒报表；

能覆盖多复杂（完善性）：语义层够厚，分母才够大；取数和制表两程都要被 LUI 接管，别用宽表把真实场景砍掉；

养不养得起（实施成本）：修复一个问题是"补一条配置"还是"调一轮模型 + 全量回归"，决定这套东西三年后还在不在。

三根标尺最后会收敛成同一套工程气质：信得过、改得动、用得起。

GUI 慢，但精确；LUI 快，但容易把精确丢掉。真正完成形态换代的方案，不是二选一，而是把 GUI 的确定性用"可确认的中间表示"重新搬进对话框里——AI 负责听得懂人话，人负责拍板，规则引擎负责算得一分不差，而代价要低到业务人员自己就养得住。

在 AI 技术喧嚣的当下，这种聚焦于解决具体问题、降低综合成本、提升产品可销售性的务实路径，或许正是下一代 BI 最该有的样子。