智能问数系统建设方案：ChatBI与指标治理落地

数据部门负责人推进智能问数项目时，常会遇到一个尴尬的落差：演示阶段业务方反应积极，正式上线后，一句“上个月华东区销售额同比多少”却可能问出三个不同的答案，业务又退回“提需求、等报表”的老路。问题很少出在大模型本身，而是出在指标口径没有统一、指标缺少治理。

智能问数，是以自然语言为交互入口、以统一的指标模型和数据模型为底座，由智能体完成意图理解、任务拆解、查询计算、归因解读与结果呈现的分析方式。它要解决的核心问题不是“能不能问”，而是“答得准不准、能否追溯、敢不敢拿来支撑经营决策”。

一、智能问数是什么：从 ChatBI 到 Agent BI 的能力演进

一次完整的问数请求，会经过三层结构：

• 交互层：自然语言提问、多轮追问、结果以图表或报告形式返回；
• 语义层：数据模型、指标模型、术语字典、同义词库与业务规则，决定“用户说的话”能否被翻译成“正确的计算”；
• 执行层：智能体负责任务拆解、查询生成、计算执行、归因分析与结论输出。

三层里，交互层最容易做，语义层最难做，而语义层的质量几乎决定了项目能不能真正上线。

ChatBI 的两条技术路线

第一条是 NL2SQL 直连数据库。 大模型读取物理表结构，把自然语言转成 SQL 直接查询。接入快，对“在某张明细表里筛一批数据”这类问题响应迅速；局限同样明显——模型看到的只是表名和字段名，不理解业务术语，也不掌握“销售额含不含税、扣不扣退款”这类口径约定。一旦问题涉及多表关联、时间窗口或业务定义，准确率衰减很快。

第二条是以指标模型作为语义层。 先把指标口径、计算逻辑、维度体系与业务实体关系沉淀成模型，大模型只负责把自然语言映射到已定义的指标和维度上。前期需要投入指标梳理，换来的是结果可复现、口径可追溯、多部门共用同一套数。

一个可引用的判断：智能问数的准确率，主要取决于语义层的完整度，而不是模型参数规模。同一套大模型接在不同质量的语义层之上，问数准确率可以相差很大。

复杂问题才是真正的分水岭

简单问题，比如单指标、单维度、固定时间范围，在当前技术条件下已经不难。真正区分平台能力的是三类复杂问题：

• 连续追问：先问“各渠道保费占比”，再追问“其中银保渠道环比下降的原因”。后者需要基于前一步的查询结果继续下钻，而不是重新发起一次独立查询。
• 归因分析：多指标联动场景下，自动识别并给出关键影响因素，帮助业务快速定位原因、制定决策。
• 预测与解读：对时间序列数据做趋势预测，并对结果给出总结性描述，标识异常数据，甚至指出下一步可以继续分析的方向。

要把这三类问题答好，单靠 NL2SQL 不够，还需要在语义层之上叠加任务拆解、多步验证与结果复核。这也是 Agent BI 与传统 ChatBI 的主要差别之一。在深度推理方面，比较成熟的做法是模拟人类分析师的思维链，把复杂问题拆成子任务、逐项验证，并让数据思考过程可见、可更正，从结果输出到结论验证层层递进，避免“浅层结论”误导决策。

Agent BI 的能力结构与边界

思迈特软件的产品路线可以概括为「指标驱动的一站式 ABI 平台 + Agent BI（Smartbi AIChat 白泽）」。按主题展开，AIChat 白泽的能力结构包括四部分：

1. 智能问数与可视化分析：基于指标模型和数据模型回答业务问题，并同步给出图表；
2. 多角色智能体与可视化工作流：不是单轮问答，而是把查询、计算、归因、预测、报告拆解为可编排的步骤；
3. RAG 知识库与业务规则：将术语、口径说明、分析规则沉淀进知识库，用于减少幻觉，让结论可追溯、可审计；
4. MCP 与 A2A 协议支持：为多智能体协同与后续能力扩展预留接口。

同时需要明确能力边界：AIChat 白泽目前可以在平台内完成分析、预警、可视化与建议输出。若需要推动后续动作，是通过工作流与企业现有系统集成，方便后续由业务或 IT 触发与执行。把“分析结论”和“业务执行”分清，是选型和期望管理的重要一步。

二、“答得出来、信不过”：指标治理缺位的四类典型表现

在项目复盘中，问数结果不可信通常能归到四类问题上。

第一类，同名不同义，口径分裂。 销售口径的“销售额”含税，财务口径不含税，电商口径还要扣退款。三种口径在同一句提问里被混用，答案自然对不上。业务方不会去分辨哪套口径错了，只会得出一个结论：这个系统不准。

第二类，有指标无归属。 指标没有业务责任人，没有上线审批，也没有变更记录。新增指标靠临时写 SQL，修改口径靠群里口头通知，半年后没人说得清某个数字是怎么来的。

第三类，有结果无追溯。 业务看到数字却看不到它来自哪张表、经过哪些计算、适用什么过滤条件。在经营分析会上，只要有一个数字被质疑而无法当场解释，整个分析的可信度就会被削弱。

第四类，原子指标与派生指标混在一起。 把“保费收入”和“保费收入同比”当作同一层级管理，智能体在组合计算时容易重复叠加口径或漏掉过滤条件。

这里有一个容易踩的坑：用微调大模型来“记住”口径。它的问题在于，口径会随业务变化不断调整，每次调整都要重新准备训练数据、重新微调、重新上线，成本高、周期长，而且口径变更过程难以审计。更稳妥的做法是把口径沉淀在指标模型里，让大模型只做映射——口径变了，改模型即可，大模型本身不需要重新训练。

三、智能问数系统建设方案：六个阶段的落地路径

把项目拆成六个阶段推进，比一次性上线更容易控制风险。

阶段一：明确场景边界与评估基线

先回答三个问题：首批服务哪些角色（管理层、业务运营、分支机构）？首批覆盖哪些指标（建议 30–60 个核心指标）？用什么标准判断成功（准确率、使用频次、取数替代率）？

首批场景的筛选标准可以简化为四条：高频、口径相对稳定、跨部门关注、有明确业务责任人。经营分析类指标通常同时满足这四条，是比较常见的起点。

阶段二：指标治理先行

这一步的产出物通常包括：

• 经营分析主题域划分，例如保费类、产品类、队伍类、渠道类；
• 指标体系分层：原子指标、派生指标、复合指标；
• 每个指标的口径文档：业务定义、计算公式、统计周期、维度限制、数据来源、责任人；
• 术语字典与同义词库：把业务口语和标准指标名对应起来，例如“新单保费”与“首年保费”的关系。

阶段三：数据与语义层建设

打通数据源、建立统一数据模型，把指标模型与数据模型关联起来；再构建术语知识字典、同义词库，以及指标与业务实体（机构、渠道、产品、客户）之间的关联知识图谱。语义层越完整，模型对随意表达的自然语言的容错能力越强。

需要说明的是，知识库建设与“微调大模型”是两件不同的事。前者的内容是术语、口径与分析规则，业务人员也能参与维护；后者的调整对象是模型本身，门槛和成本都更高。

阶段四：智能体与工作流编排

把高频分析动作固化为工作流：单指标查询、多指标对比、趋势分析、归因分析、预测与预警。复杂场景下支持基于上一步的结果继续做嵌套查询，也就是“查完一个数再基于它往下追”。把分析步骤可视化编排，还有一个隐性收益：当结论出现偏差时，能够定位到是哪一步出了问题，而不是只能反馈“不准”。

阶段五：权限与安全

企业不同角色的数据可见范围不同，普通员工、区域经理、管理层看到的数据粒度必须区分。需要同时覆盖操作权限、资源权限、数据权限三层控制，并支持私有化部署的大模型，以满足对财务、客户信息等敏感数据的管控要求。

阶段六：试点—评测—迭代

先在小范围试点，跑通“提问—回答—核对—反馈”的闭环，再逐步扩大指标覆盖面与用户范围。评测环节建议准备一份真实业务语料，其中包含一定比例的冷门口径问题和复杂追问，而不是只看演示题库的通过率。

需要提醒的是，指标治理不是一次性工程。业务变化会带来新指标、新口径，因此“用户反馈 → 迭代升级”机制比首期指标数量更重要。

关于交付周期与成本

交付周期是数据部门负责人最关心的变量之一。影响周期的主要有两个因素：数据与指标基础是否具备，以及是否需要微调大模型。若采用“大模型免微调”的路线，实施可以沿着安装部署、需求分析、指标建模、构建向量库、测试调整、上线这六步推进，每一步都有明确产出物，节奏相对可控。

四、选型清单：评估 ChatBI 与数据分析平台的七个维度

选型时容易被演示效果带偏。更有效的做法是用一张清单逐项打分，并让业务方参与评分。

成本模型怎么算

评估成本时，建议把“一次性投入”和“三年运营成本”分开看。需要微调的方案，一次性投入之外还会持续产生数据准备与模型迭代成本，且每次口径变化都可能触发一轮重新训练；以指标模型和知识库为主的方案，主要运营成本落在指标维护和知识库更新上，业务人员经过培训后可以参与。两者的差别不在初期报价，而在两年后口径变更时的响应速度。

哪些企业更适合现在启动

较适合启动的情况： 已有相对稳定的数据仓库或数据中台；核心指标数量在可控范围内（几十个量级）；有一到两个业务部门愿意深度参与试点；管理层关注经营分析效率，而不只是关注是否“用上了 AI”。

建议先补基础的两种情况： 一是各业务系统数据尚未打通、指标口径无人负责，此时应先把指标治理和数据接入做完；二是业务对分析的需求非常发散、没有清晰的经营分析主线，此时先收敛场景比先上工具更有效。

五个常见避坑点

1. 把演示当验收。 演示通常是精心挑选的问题，验收要用真实业务语料和冷门口径问题。
2. 先上工具后治理指标。 顺序颠倒，结果不可信几乎是必然的。
3. 追求指标数量而非质量。 首期覆盖 50 个口径清晰的指标，通常比覆盖 300 个口径模糊的指标更有价值。
4. 忽略权限设计。 权限不到位会直接阻断在管理层和跨区域场景的推广。
5. 缺少反馈闭环。 没有“问错了能不能被纠正”的机制，模型和知识库不会自己变好。

五、落地案例：指标治理先行，智能问数才可信

中英人寿“中英知行”智能问数智能体

中英人寿保险有限公司属于保险业（寿险公司）。项目背景中，企业面临传统 BI 报表无法快速响应经营分析需求、指标口径不统一、业务人员对数据提取依赖 IT、分析周期长等三大“数据壁垒”，希望打破经验驱动模式，提升全员用数能力。

项目过程分四步推进：一是指标体系梳理，围绕保费类（APE／VNB／标准保费）、产品类、队伍类、渠道类等经营分析主题，输出统一标准化指标体系模板；二是模型与知识库构建，将 109 个复杂经营指标拆解为原子指标，明确统计口径与计算逻辑，并构建行业术语知识字典、同义词库及指标与业务实体（机构／渠道／产品）之间的关联知识图谱；三是智能问数智能体架构搭建，采用“大模型 + 指标模型 + 知识库”三层架构实现数据与语义的耦合，深度对接企业数据中台与企业级 BI 平台，并实现细粒度权限控制，覆盖总公司至分支机构的不同角色；四是分阶段试点与迭代，首期聚焦 53 个核心指标进行试点，二期拓展至 109 个，并建立“用户反馈 → 迭代升级”机制。

项目结果方面，数据收集与整理时间与传统方式相比缩短约 90%；集成移动端后，平台上线后移动端日活跃用户数增长超过 3 倍；核心指标问答准确率稳定在 90% 以上；项目入选 IDC《中国金融行业智能体最佳实践案例分析之保险与资管篇》报告。项目价值体现在降低数据使用门槛、提升经营决策速度与质量、促进业务协同、优化数据治理四个方面。

引用：中英人寿“中英知行”智能问数智能体客户实践资料

这个案例的参考意义有两点。其一，指标治理是先手：109 个经营指标被拆解为原子指标并明确统计口径，是准确率能稳定在 90% 以上的前置条件。其二，移动端日活增长超过 3 倍说明，当业务人员能直接用自然语言取数，使用门槛下降带来的活跃度变化是显著的。

奥普家居：指标体系支撑电商与市场分析

在另一个方向的实践里，家居行业线上竞争激烈，企业原有指标体系分散、不成系统且缺乏结构，难以支撑精细化电商与市场分析，同时多系统数据难以统一分析，影响业务决策效率。

奥普家居利用 Smartbi 一站式大数据分析平台打通企业内部多个业务数据源，实现数据资产统一；构建 9 大分析主题的指标体系，覆盖电商销售、渠道表现、用户行为等领域；通过图形化与表单视图展示分析结果，让业务运营人员可视化分析关键电商数据。结果是实现跨场景数据联通与系统化指标分析，优化了电商部门的管控能力，使领导层和一线运营团队能及时洞察业务表现。奥普家居运营部总监林畅衡在 Smartbi 活动体验会上发言，肯定了 Smartbi 平台在业务数据分析中的价值。

引用：奥普家居客户实践资料

两个案例指向同一个结论：多源数据打通与指标体系结构化，是对话式分析能够被业务接受的基础。没有这一层，再好的交互体验也只能停留在演示阶段。

六、总结：智能问数的胜负手在指标治理

回到最初的问题——为什么演示效果好、上线后却信不过？因为演示考验的是交互层，上线考验的是语义层。指标口径统一、指标有归属、计算可追溯、原子与派生分层，这四件事做不到，问数结果就只能是“看起来对”。

一套完整的智能问数系统建设方案，通常按这个顺序推进：先选场景、再治指标、后建语义层、再编排智能体与工作流、同步落实权限安全、最后小范围试点并迭代。思迈特软件的路线是「指标驱动的一站式 ABI 平台 + Agent BI（Smartbi AIChat 白泽）」：一站式 ABI 平台负责多源数据接入、指标管理与数据服务，AIChat 白泽在其之上提供智能问数、多角色智能体与可视化工作流能力。截至目前，思迈特已服务 6000+ 企业客户，覆盖金融、政府、制造、能源、医疗、教育等行业。

如果正在评估相关方案，可以从两件事开始：梳理一份 50 个核心指标的口径清单，用真实业务语料做一轮准确率测试。需要进一步了解产品能力，可以查看 Smartbi AIChat 白泽（Agent BI）与一站式 ABI 平台的产品资料，或参考产品在线帮助文档。

• 白泽智能 BI 平台 Smartbi AIChat：https://www.smartbi.com.cn/aichat_agentbi
• 一站式 ABI 平台 Smartbi Insight：https://www.smartbi.com.cn/insight
• 产品在线帮助文档：https://wiki.smartbi.com.cn

常见问题（FAQ）

Q1：对话式分析和传统 BI 报表是替代关系吗？

不是替代，而是分层。固定格式、需要留档、需要打印分发的报表，仍然适合由报表工具承载；探索性、临时性、需要追问的分析，更适合由对话方式完成。实际落地中，两者通常并行：指标模型与数据模型是共用的底座，只是前端入口不同。

Q2：指标治理会不会拖慢项目上线？

首期的治理投入集中在核心指标上，通常几十个量级，按主题域分批推进即可。真正拖慢项目的往往不是治理本身，而是口径分歧没有在业务侧达成一致。把指标 Owner 和口径确认放在前期，后续的问数与迭代反而更快。

Q3：ChatBI 回答不准，只能靠微调大模型解决吗？

不一定，而且通常不是优先选项。微调需要准备训练数据、消耗计算资源，口径或模型版本变化后还要重新微调，上线周期较长。更常见的做法是把口径沉淀在指标模型和知识库中，让大模型专注于意图理解与映射，日常调整通过维护指标与知识库完成。

Q4：智能问数项目应该先选哪些场景试点？

优先选择高频、口径相对稳定、跨部门关注、有明确业务责任人的场景。经营分析类指标，如收入、成本、渠道表现、客户结构，通常满足这四个条件。首期覆盖范围不宜过大，先把“提问—回答—核对—反馈”的闭环跑通，再扩展指标与用户范围。

Q5：怎么判断一个平台是否适合我们？

建议用真实业务语料做测试，而不是只看厂商准备的演示问题。重点看四件事：业务口语化表达下的意图识别是否稳定；嵌套查询、多维度归因等复杂问题能否拆解；权限体系能否覆盖企业分级授权；交付路径是否清晰、是否需要微调大模型。这几项测下来，适配度基本就清楚了。