导语在和客户交流BIAI时我们最常听到的一句话是能不能就在报表旁边加一个对话框其实智能问数远不是在 BI 界面上贴一层 ChatBot 皮——它是一条从用户提了一个问题到用户真的拿到了可信答案的完整工程链路包含权限→理解→取数→归因→执行五个关键环节。任何一个环节缺位输出结果要么是答非所问要么是数据看似正确但业务用不起来。这篇文章会从一次真实的用户提问出发逐段拆解这条链路在观远 ChatBI基于自然语言对话的智能问数产品里是如何被一节一节搭起来的以及在每一节上我们做了哪些判断、设计了哪些能力、踩过哪些坑。需要先说明几件事这里讨论的智能问数不是指通用大模型的闲聊式问答而是面向企业数据场景、要求口径准确、权限合规、可追溯的问数能力链路中的每个环节都有对应的产品模块在支撑ChatBI 负责对话交互与问题路由指标中心负责业务口径的统一定义与管理即把销售额毛利率这类指标的定义、计算逻辑、负责人沉淀到统一平台避免各部门各算各的DataFlow观远自研的 ETL 数据加工与编排工具负责数据准备与加工洞察Agent负责自动异动归因订阅预警负责把数据洞察按时按需推送给业务后面展开的具体能力点如问答流程带入用户属性智能体/单表问答准确率达 80% 再扩多表等来自我们的产品文档与功能迭代说明会在涉及的地方标注。把这五个环节铺开来看你会发现AI 增强 BI真正的难点根本不在模型能不能理解中文而在前面那些看不见的工程地基。这也是我们今天要重点拆解的。一、常见的认知误区智能问数 ≠ 加一个 ChatBot很多团队在启动BIAI项目时第一版方案几乎长一个样在 BI 看板边上挂一个输入框用户敲一句上个季度华东区的销售额是多少大模型返回一张表或一张图。Demo 看起来很惊艳落地之后却问题百出——同一个销售额财务口径和业务口径差出几百万同一个问题张三问得到、李四因为没权限被静默拒掉问出来的数对不对下一步该做什么依然要人肉判断。这类失败大多可以归到三个共同的认知误区上。误区一只做意图识别和 SQL 生成忽略权限与口径治理。大模型能把华东区销售额翻成一段 SQL 并不意味着这件事成立——谁来定义销售额用含不含退款的口径谁能看华东区的数据这些前置约束如果不在链路里被显式处理输出的数就既不可信、也不可用。观远在 ChatBI 的链路里把用户属性感知和指标中心作为必经节点要求每一次问答都带上当前用户身份与统一口径的指标定义来源观远 ChatBI 产品功能说明问答流程用户属性感知能力于 2025.09 上线。误区二把问答准确率当作唯一指标忽略异动归因与可执行建议。准确率衡量的是答得对不对但业务场景里更常被追问的是为什么降了和我该做什么。如果链路在取数之后就停止交付用户拿到的只是一个孤立的数字看不到异动原因也看不到建议动作。ChatBI 的设计要求在数据返回之后洞察Agent自动识别指标异动并给出归因与策略建议来源观远 ChatBI 零售行业搭建指南2025。误区三把能问出数等同于能用上数忽略后续触达与行动闭环。业务人员不一定会每天主动打开 ChatBI。问完即结束再无下文。链路必须延伸到订阅预警与触达环节让关键指标按角色、按频率主动推送到对应人手里问题才真正形成闭环。这三层误区的共同根源是把智能问数想成了一个对话壳而不是一条工程链路。壳只关心怎么回答链路还要关心答得对不对、谁有资格答、答完之后怎么办。下一节我们从链路的第一节权限与入口开始拆。二、一次完整的智能问数链路六个关键环节把一次问数拆到最细它其实由六个环节串成。任何一个环节做得粗糙最后交付的答案就立不住。环节一身份与权限识别。用户打开 ChatBI 的瞬间系统就要先回答一个问题——“你是谁你能看什么”。这一步依赖 BI 平台原有的用户体系和数据行级权限即对同一张表不同用户只能看到自己权限范围内的数据行例如华东区经理看不到华南区明细。观远在 ChatBI 路由层做了用户属性感知用户提问时当前用户身份、组织、时间等属性会一并传入大模型来源观远 ChatBI 5.7.0 功能说明。这意味着张三问我的客户时模型生成 SQL 会自动带上张三的归属过滤条件而不是返回全量数据。环节二业务知识与口径召回。销售额是含税还是不含税“毛利按什么规则扣减这些口径必须有一个统一的来源。ChatBI 在生成 SQL 前会先到指标中心和主题知识库中召回相关业务知识把这件事的标准定义是什么喂给模型。同时平台会把每次召回的知识透出给用户标注当前回答基于哪些知识”——既方便排查也建立了用户对答案的信任。环节三意图理解与 SQL 生成。在口径和知识锁定之后模型才进入翻 SQL环节。这一步要处理的是表/字段映射、筛选条件聚合方式、时间范围等。文档建议首次搭建时先基于单表做问答等准确率达到 80% 再扩展多表来源观远 ChatBI 零售行业搭建指南。这个 80% 不是营销话术而是工程经验——单表场景的字段关系清晰、歧义少准确率天花板高多表一旦涉及跨表关联意图理解的复杂度会显著上升。环节四用户属性与上下文带入。同一个问题在 A 部门和 B 部门意义不同在月初和月末关注的指标不同。ChatBI 的做法是把用户属性、对话上文、当前主题都作为上下文拼入 prompt让模型在生成阶段就贴合提问者的角色。环节五结果呈现与异动归因。数据查出来只是第一步洞察Agent会同步判断指标是否发生异动并尝试解释为什么变了。这一步把答对升级为答懂。环节六行动闭环与触达。答案不能停在对话框里。订阅预警、移动门户、钉钉集成等通道把关键结论按角色、按频率推送出去问题才真正转化为行动。六个环节环环相扣下一节我们挑其中最容易踩坑的几个环节再展开讲讲背后的产品设计取舍。三、产品能力如何映射到链路各环节以观远ChatBI为例链路讲完骨架还得落到具体配置上。六个环节每个都有对应的产品能力下面挑五个最容易被低估的设计点展开。主题与知识库配置先把问什么边界画清楚。一个 ChatBI 主题Topic相当于一个独立的问数域建议同一主题只挂同源数据集都是 MySQL 或都是 StarRocks表名、字段名避免英文缩写和特殊字符时间字段尽量用日期类型而非字符串。这套规范不是为了好看——它直接决定大模型在表/字段映射环节的命中率。首次搭建建议从单表开始单表准确率跑通后再扩多表文档给出的经验阈值是 80%来源观远 ChatBI 零售行业搭建指南。知识库侧则要维护指标中心的标准定义、错题集即把回答错误的问题和正确解法沉淀下来用于后续训练和提示、业务术语表三者配合才能让召回的知识真的可拼装。召回知识透出让用户看见模型为什么这么答。取数问题排查时平台会向用户展示本次问数向模型发送了哪些表知识、业务知识、错题集条目来源观远 ChatBI 2025.09 功能更新说明。同时新增知识召回次数统计高频命中的业务知识一眼可见低频的可以反查是不是定义过时。这一层透明化是建立信任的关键——用户不再觉得AI 在黑箱里猜而是能看到每条答案的证据链。推荐问题自定义从能问到会问的引导。早期 ChatBI 的推荐问题由模型根据数据集自动生成容易出现用户不知道能问什么的冷启动难题。升级后支持自定义推荐问题上限 20 个大模型结合示例、对话历史、数据结构动态生成 3 个示例问题来源同上。业务方可以把本周最关心的指标、最常踩坑的问法主动推上去把提问从自由发挥变成有路可循。用户属性感知同问不同答。同一句本月销售完成率在大区经理看的是全大区在门店店长看的是单店。ChatBI 在问答流程中会把当前用户的身份、组织、时间等属性值传给大模型模型据此生成带权限过滤的 SQL来源观远 ChatBI 5.7.0 功能说明。这意味着权限与口径在生成阶段就内嵌进去而不是查询返回后再事后裁剪。移动端与钉钉集成把问数塞进日常工作流。移动门户支持通过外链一种将外部页面嵌入 BI 门户的卡片把 ChatBI 主题入口铺到首页每个主题对应一条形如{环境域名}/m/chatbi/{主题ID}的链接来源观远 ChatBI 钉钉 H5 集成方案。钉钉侧则可以在移动门户添加 ChatBI 问数轻应用或通过钉钉开放平台做深度集成iOS 16.0.0 以上可通过前端插件解决卡片滑动问题。这样业务人员在钉钉里就能直接发起问数问完即走不再需要切换到 BI 后台。这五项能力合在一起构成了一次问数从配置到交付再到回流的完整映射。链路能不能跑通取决于这些能力是否被认真配置而不是只装一个对话壳。四、行业典型场景零售单店问数到异动归因把六个环节串成一条线落到零售门店场景里最容易被卡住的就是异动归因这一环。场景目标很朴素店长早上打开手机问一句昨天销售额为什么下滑了希望得到的不是一张冷冰冰的数字表而是一段能直接指导排班和促销的解读。要把这件事跑通链路上的每个环节都不能省。数据与口径准备。前置条件是销售日表的接入——表名、字段名要避免英文缩写和特殊符号时间字段用日期类型而非字符串这是降低模型映射歧义的基础来源观远 ChatBI 零售行业搭建指南。口径侧则需要在指标中心里先定义客单量“连带率”即平均每笔订单购买的商品件数等核心指标把含税还是不含税是否剔除退货这些规则沉淀成标准定义否则同一句销售额在不同人眼里就是不同数字。链路关键点一知识召回解决口径分歧。店长提问时ChatBI 先到指标中心和主题知识库中召回销售额“客单量的定义把统一口径喂给模型。这一步直接决定了答案在不在同一频道上”。链路关键点二用户属性锁定范围。张店长问的昨天只应返回他所在门店的数据而不是全区域。系统把店长的门店 ID、所属大区等属性传入模型SQL 生成阶段就自动带上过滤条件来源观远 ChatBI 5.7.0 功能说明。链路关键点三异动归因与行动建议。数据查出来只是起点。洞察Agent会判断销售额是否出现异动并尝试拆解是客单量降了还是客流少了。如果连带率下滑明显系统可以进一步提示是否高客单商品缺货把答案从对推向懂。走完这三步店长拿到的不是一行数字而是一段可以直接用于早会决策的解读——这才是 ChatBI 在零售场景里真正落地的形态。
：Backtrace (moderate))
)
