导语
在和客户交流"BI+AI"时，我们最常听到的一句话是：能不能就在报表旁边加一个对话框？其实，智能问数远不是在 BI 界面上贴一层 ChatBot 皮——它是一条从"用户提了一个问题"到"用户真的拿到了可信答案"的完整工程链路，包含权限→理解→取数→归因→执行五个关键环节。任何一个环节缺位，输出结果要么是答非所问，要么是数据看似正确但业务用不起来。
这篇文章会从一次真实的用户提问出发，逐段拆解这条链路在观远 ChatBI（基于自然语言对话的智能问数产品）里是如何被一节一节搭起来的，以及在每一节上我们做了哪些判断、设计了哪些能力、踩过哪些坑。
需要先说明几件事：
- 这里讨论的"智能问数"，不是指通用大模型的闲聊式问答，而是面向企业数据场景、要求口径准确、权限合规、可追溯的问数能力；
- 链路中的每个环节都有对应的产品模块在支撑：ChatBI 负责对话交互与问题路由，指标中心负责业务口径的统一定义与管理（即把"销售额""毛利率"这类指标的定义、计算逻辑、负责人沉淀到统一平台，避免各部门各算各的），DataFlow（观远自研的 ETL 数据加工与编排工具）负责数据准备与加工，洞察Agent负责自动异动归因，订阅预警负责把数据洞察按时按需推送给业务；
- 后面展开的具体能力点（如"问答流程带入用户属性""智能体/单表问答准确率达 80% 再扩多表"等），来自我们的产品文档与功能迭代说明，会在涉及的地方标注。
把这五个环节铺开来看，你会发现"AI 增强 BI"真正的难点，根本不在模型能不能理解中文，而在前面那些看不见的工程地基。这也是我们今天要重点拆解的。
一、常见的认知误区：智能问数 ≠ 加一个 ChatBot
很多团队在启动"BI+AI"项目时，第一版方案几乎长一个样：在 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 在零售场景里真正落地的形态。
