简介：《2024 ChatBI+Agent实战手册（八大案例，共134页）》是一份面向数据分析、大模型与商业智能从业者及管理者的行业实践合集。手册汇集平安人寿、滴滴、喜马拉雅、腾讯、快手、阿里巴巴和网易等企业的ChatBI与AI Agent落地经验，围绕自然语言驱动的智能报表、对话式取数、SQL生成和可视化分析自动化等场景，拆解从背景设计、系统架构到实施成效与挑战的完整链路，并强调跨部门合作与模型调优对数据质量的关键作用。资源为1个PDF文件，压缩包大小9.33MB，共134页，单文件便于直接阅读或团队共享。已有433人学习下载。读者可从中获得多个企业的一手技术复盘，例如平安人寿“提问—取数—可视化—洞察—建议”的端到端方案、腾讯ABI工程探索、快手BI+AI融合实践，以及阿里数据消费场景中的Agent应用；同时还有各案例中的问题对策与操作建议，可作为企业搭建智能BI或Agent体系时的实用参考。
1. 大模型抢着做 BI，为什么成事的极少：ChatBI 的三大脏活
一个反直觉的结论：读完平安人寿、滴滴、喜马拉雅、腾讯、快手、阿里巴巴和网易伏羲这八个真实案例，决定 ChatBI 项目成败的往往不是大模型选型，而是知识库质量、指标权限和根因分析这几个容易被人忽略的“脏活”。这份 134 页的实战手册，把从“用户说一句自然语言”到“生成一张可视化报表”的完整链路拆到读者面前，覆盖对话式问数、SQL 生成、Agent 编排、BI+AI 架构、数据可视化和权限治理。
它适合正在搭数据分析平台或智能报表引擎的后端工程师、做数据产品设计的 BI 产品经理，以及需要向公司论证“大模型能不能用在 BI 上”的技术负责人。下面是我把八大案例按工程实现角度重新梳理后的拆解——共同的架构模式、可以直接套用的流程和绕不过去的坑，一次讲清楚。
2. 从平安人寿的四层架构看 ChatBI：数据中台、Agent 编排与应用层如何协作
在深入单个案例之前，先把手册里隐含的主线抽出来。八个案例分属保险、出行、音频、云计算、电商、游戏六个行业，服务对象从企业内部员工到 C 端客户都有，但架构方案惊人一致。先把最关键的那个讲透——平安人寿的整套分层，后面看滴滴、快手、腾讯时可以直接拿来对照。
2.1 平安人寿的四层架构：每一层在解决什么问题
平安人寿把 ChatBI 的整体方案拆成四层：数据中台、平台层、Agent 层和应用层。大多数技术文章会把目光集中在 Agent 层和应用层，但实际落地顺序恰好相反，数据中台是地基。
第一层数据中台，包含各种数据域和指标。手册里有一句很关键：“我们拥有完善的数据中台，包含丰富的数据域；长期的数据治理让我们拥有上万个规范的数据指标”。这句话点出了本质——没有长期治理过的数据，后面都是空中楼阁。第二层平台层，集成了 API 服务、知识管理、大模型、Cube 和 GS 平台，以及北斗可视化平台。这一层把底层能力和业务功能粘在一起，相当于把“查数据”和“生成图表”这两个动作服务化。用户每次提问，前端不直接连数据库，而是通过平台层统一的 API 拿到结果。
第三层是 Agent 层，平安人寿把它分成四类：问数、分析、数据解读和公共能力。第四层是应用层，对外只暴露三个核心能力：What（解放手）、Why（解放脑）、How（开药方）。What 是对话式取数，零代码查询，数据获取从原来的“天级”变成“秒级”，并自动生成图表；Why 是由大模型替代人工做根因分析、数据洞察和维度分析，把“提需求→分析需求→获取数据→人工分析→制作报告”压缩成一次提问；How 是在洞察基础上自动产出建议和措施，让“开药方”从依赖个人经验变成数据驱动。
这四层的顺序有明确的依赖关系：数据中台解决“数据在哪”，平台层解决“能力怎么复用”，Agent 层解决“意图怎么分发”，应用层解决“用户看到什么”。我在实际评估 ChatBI 项目时发现，常见的失败项目大多是中间两层没做扎实——API 没有服务化，或者 Agent 职责边界不清，最后大模型把所有事情一把抓，结果就是什么都做不稳定。
提示：不要小看平台层。如果公司没有把指标查询和可视化组件 API 化，后面做 Agent 编排时会发现没有“手”可用。很多团队做 ChatBI 的第一个觉悟，就是先把 API 服务化补齐。
2.2 Agent 编排层的职责切分：四类 Agent 如何分工
Agent 编排这一环，是平安人寿被问得最多的地方。手册对它的描述是“任务执行是整个系统的大脑，通过任务编排调用不同的工具和知识库”。落到工程上，就是把“用户意图”路由到不同的执行链路。四类 Agent 的分工可以整理成下面这张表：
| Agent 类型 | 承担职责 | 典型提问 | 返回内容 |
|---|---|---|---|
| 问数 Agent | 对话式取数，完成一套数据查询流程 | “查一下 XX 机构一季度业绩” | 数据结果 + 图表 |
| 分析 Agent | 根因分析，多级下钻归因 | “为什么这个月退保率上升了” | 归因结论 + 原因列表 |
| 数据解读 Agent | 解释指标口径与元数据 | “这个指标的统计口径是什么” | 口径说明、定义 |
| 公共能力 Agent | 鉴权、上下文管理、通用工具 | “我有权限看这个指标吗” | 鉴权结果 / 会话状态 |
注意公共能力 Agent 不是一个可有可无的附加项。实际系统里，每次用户提问都要先经过它完成账号鉴权和上下文清理，确认用户有没有指标使用权限。如果这一环没设计到位，大模型有可能把“无权限”的数据也带出来，这是数据安全事故。
在流程编排上，一次简单的问数会多次调用大模型。以“查一下 XX 机构今年一季度业绩同比”为例，实际运行过程是：
- 前端把问题传入 BI 大模型，做语义理解；
- 模型通过多轮对话识别出指标（业绩）、时间（2024 年一季度）、维度（XX 机构）和计算方式（同比）；
- 知识库做二次校准，补全模型可能识别错误的口径；
- Agent 编排层判断该把任务派给问数 Agent；
- 公共能力 Agent 完成 UM 鉴权，校验用户对这个指标有没有权限；
- 生成 SQL 或调用 API，从 Doris 等引擎完成秒级查询；
- 可视化组件把数据组装成图表返回用户。
第 2 步和第 3 步不是一回事。语义理解是大模型的“自由发挥”，知识库校准是把它拉回行业规范。第 3 步直接决定答案是否“专业”，这也是手册里明确说“知识库的丰富度与语义解析和结果生成的准确性息息相关”的原因。
2.3 滴滴与快手：ABI 演进的两条不同路径
滴滴的案例在手册里是一个重要的参照样本，因为他们在 23 年初就坚定地投身于大模型方向，做数据产品升级。滴滴对 ChatBI 的定位不是做成补丁功能，而是作为 ABI（AI + BI）方向的产品演进。ABI 的核心变化是让数据产品从“人找数”变成“数找人”，这也是滴滴把“ABI 方向的演进及 ChatBI 领域现状”放在最前面的原因。
快手案例的标题是“分析领域 BI+AI 探索与实践”，切入角度更接近分析流程本身。它的探索集中在“大模型给分析师打辅助”这个定位上，而不是直接替代分析师。同一个报表平台，如果让大模型承担的是辅助角色，产品形态和评价指标会和“全自动问答”完全不同。
把三个案例放一起看，能发现一个共同的底座：语义解析、可复用指标平台、Agent 编排、RAG 知识库，缺一不可。差别只在于各家的侧重点是取数效率、分析深度还是工程稳定性。后面第 4 章逐个拆解时会看得更清楚。
3. 问数主链路：意图识别、RAG 知识库和 SQL/API 生成如何协同
第 2 章讲的是架构骨架，这一章进入“问数”主链路，也就是大部分团队最先着手的那条线。链路里的每一步都有明确输入输出，也有常见的失败点。把这些失败点提前识别出来，能省掉大量排错时间。
3.1 用户提问到报表展示的九步链路
手册里平安人寿的“问数流程”实际包括九个环节，从用户提问到最终报表展示。整理成表格更直观：
| 环节序号 | 环节名称 | 核心动作 | 最常见失败点 |
|---|---|---|---|
| 1 | 提问入口 | 前端插件、会话窗口 | 问题缺时间或机构，表述不完整 |
| 2 | 语义理解 | 大模型解析同义表达、缩写词 | 多轮对话上下文丢失 |
| 3 | 意图识别 | 提取指标、时间、维度、计算方法 | 指标识别错误 |
| 4 | 知识库校准 | RAG 检索，补充口径定义 | 知识库缺失，校准无效 |
| 5 | 任务编排 | 分发任务给对应 Agent | Agent 职责边界不清 |
| 6 | UM 鉴权 | 校验用户与指标的权限关系 | 权限模型只做到行级 |
| 7 | SQL 生成 | 生成查询语句或调用 API | 直接生成 SQL 时幻觉多 |
| 8 | 数据查询 | 从 Doris 等引擎取数 | 查询超时、数据口径不统一 |
| 9 | 可视化 | 组装图表模板，美化渲染 | 图表类型选择错误 |
整条链路里，第 4 步知识库校准和第 6 步鉴权，是很多团队设计 ChatBI 时最容易跳过的。跳过知识库校准，大模型会凭“自由发挥”吃掉准确率；跳过鉴权，报表工具很容易变成内部数据泄露的通道。
3.2 RAG 知识库的两种分层：常见知识库和进阶知识库
知识库是把传统 BI 变成 ChatBI 的关键。手册里知识库直接采用了两层结构。第一层是常见知识库，包含常见名词、基本业务知识和 SQL 语法，任何 BI 场景都能用，适合平台团队统一维护。第二层是进阶知识库，包含垂直领域知识。平安人寿按业务拆成了三块：BI 知识库（同环比、累计等术语）、保险知识库（保险行业名词）、SQL 知识库（SQL 编写规范）。
这样分层的好处是维护成本和可用性被分开。常见知识库更新频率低，改动影响面大，走平台统一发版；进阶知识库和业务耦合紧，需要业务团队持续投入。手册里有一句原话值得记住：“知识库的维护需要投入大量的精力，但是知识库的丰富度与语义解析和结果生成的准确性息息相关，是非常必要的工作。”
在真实落地项目中，知识库不只是一个“文档 + 向量库”的组合。需要把指标定义、SQL 编写规范、可视化偏好全部结构化。我见过比较稳妥的起步方式是先放 30 到 50 个高频指标的完整口径和标准 SQL，再逐步放开到全域，比一次性全量导入更容易控制质量。这也是平安人寿能支撑“上万个指标”却不失控的原因——它们有长期的数据治理存量。
3.3 SQL 生成的三种路线：直接生成、平台 API 兜底和 Python 分析
很多团队做 ChatBI 时都会问同一个问题：让大模型直接生成 SQL，还是只让它做语义理解、再由平台 API 取数？手册里平安人寿的回答已经给出了取舍逻辑。
他们一开始也尝试过让大模型直接生成 SQL，但很快发现“实现路径和精准度提升较慢，难度较高”，最终转向“模型负责语义理解→通过 API 和 NLP 技术生成代码→底层数据服务中台快速生成查询”的路线。注意这里的大模型是私有部署的 Qwen 72B，经过了微调和多项工程优化，但主要查询生成逻辑并不是只靠模型完成。
三种路线的对比：
| 路线 | 原理 | 优点 | 风险 | 适合场景 |
|---|---|---|---|---|
| 直接 LLM 生成 SQL | 模型根据 schema 直接产出 SQL | 实现快，无需额外平台建设 | 幻觉多，表结构复杂时准确率低 | 表结构简单、指标少的验证性项目 |
| API 兜底（指标平台） | 模型只提取指标/维度/时间，平台生成查询 | 准确率可控、可复现 | 需要指标平台，治理前置 | 企业内正式 BI，手册推荐路线 |
| Python 分析模式 | 模型生成 Python 代码做深度分析 | 分析能力强，适合下钻 | 执行环境复杂，有安全风险 | 分析型场景，需要二次加工 |
有一个值得注意的规律：合规要求高的金融场景基本都会避开“直接 LLM 生成 SQL”的路线，因为 SQL 的语法错误、表连接错误、数据权限缺失，不是模型层面能完全解决的。指标平台 API 兜底是一种工程补偿。但如果团队手里没有成熟的指标平台，直接生成 SQL 也能起步，前提是把表结构简化（比如用宽表减少 join），让模型只产出标准模板内的 SQL。
把大模型定位成“参数提取器”而不是“SQL 生成器”，是平安人寿这条路线最核心的转变。一次语义解析的输出大概长这样：
{ "指标": "业绩完成率", "维度": "华东大区", "时间": "2024-03", "计算": "同比", "口径": "月累计完成额 / 月目标额" }这个 JSON 就是模型和指标平台之间的接口协议。模型只负责把用户口语转成结构化参数，查询由平台执行。这样做的直接好处是：同一套查询逻辑可以被不同用户的不同问法重复调用，准确率上限取决于指标字典的完整度，而不是模型的即时发挥。
提示：最低可行的 ChatBI，可以只用“指标字典 + 大模型语义解析 + 一个 REST API”三层实现。模型把“XX 机构一季度业绩”解析成上面的 JSON，再去查指标字典执行查询。这个架构可以作为从 0 到 1 的起点，后续再逐步把字典替换成知识图谱。
4. 八大案例横向拆解：从对话式问数到实时语音 Agent 的场景谱系
这一章换个角度，把八个案例按“解决什么问题”重新分组。你会发现它们虽然都叫 ChatBI+Agent，但覆盖的其实是 Agent 应用的整个谱系。
4.1 对话式问数的两种密度：平安人寿与滴滴
平安人寿的案例是整份手册里信息最完整的。它上线了随机报表功能，用户随便提问，比如“查询某个机构的业绩”，系统通过大模型、意图识别和知识库做三重配合，解析出时间、指标、计算方法和维度，再进入任务编排和鉴权，最后秒级反馈。产品目标也很聚焦：零学习成本降低报表使用门槛，智能分析建议让数据分析智慧化，通过嵌入方式整合到多个内部平台。
滴滴的案例标题是“智能数据分析的前沿探索与应用”，目标是从“查询工具”走向“分析工具”。两家共性很明显：底层都是大模型负责语义理解，中间有 Agent 编排负责任务调度，上层有可视化组件负责输出。差别在于平安人寿在数据安全和口径一致性上投入更重，滴滴在复杂分析和交互体验上放了更多精力。对中小团队来说，平安人寿的“指标平台 + 参数提取”路线更容易复制，滴滴的探索更适合已经具备成熟 BI 底座的团队参考。
4.2 分析场景的 Agent 变形：喜马拉雅、快手与阿里巴巴
喜马拉雅的“基于大模型 ChatBI 实践探索”，处于问数和分析之间的中间地带。同属内容平台，天然要处理大量 UGC 数据和播放行为数据，指标体系比传统保险业更碎片化。它的参考价值在于：当指标定义不统一、业务变化快时，知识库怎么维护、意图识别怎么兜底。
快手的“分析领域 BI+AI 探索与实践”更靠近分析师工作台。它的重点不是“一句话问数”，而是“问完数之后怎么办”。拿到一张报表后，分析师往往要展开下一轮追问：为什么数据变了？哪个维度贡献最大？快手的方案是把这类分析动作用大模型增强，让分析师能把更多时间花在业务判断上。
阿里巴巴的“数据消费场景 AI Agent 实践”，核心是解决数据产品与普通业务用户之间的供需错配。阿里的做法是把 Agent 放进数据消费链路，让用户在消费数据的同时直接用自然语言追问。这类场景最考验两件事：多轮对话的上下文管理，以及“同一问题不同表述”的意图归一。三个案例的共通点是：ChatBI 落地不需要一开始就大而全，先选一个小切口——一个部门、一类指标、一个看板——快速启动，比规划一个宏大平台更实际。
4.3 Agent 形态的三重拓展：腾讯 ABI 工程、豆包 MarsCode 与网易伏羲
腾讯的“ABI 工程领域的探索与实践”是全场最偏工程底座的一个案例。ABI 工程覆盖数据仓库、指标平台、BI 工具和 Agent 应用四个层面，腾讯对工程底座重视程度最高。如果你的团队已经有成熟的 BI 平台，参考腾讯这一章会很有帮助。
字节跳动的豆包 MarsCode 是整份手册里最“不像 BI”的案例，做的是编程助手场景。但它的价值恰恰在于展示了 Agent 的通用性：同样的语义解析、工具调用、RAG 知识库结构，换到编程场景就成了 IDE 里的 AI 助手。这也解释了为什么 Agent 不是 BI 的专有名词，而是一种通用能力。Agent 框架在这里的复用逻辑非常清晰，适合想从 BI 场景迁移到其他场景的团队参考。
网易伏羲的案例则完全超出 BI 范畴，做的是实时语音交互的游戏队友。游戏里队友开口说话，Agent 要在毫秒级完成语音识别、意图理解、任务响应，对延迟的要求比 ChatBI 严格得多。这个案例在手册里扮演的是“边界扩展”的角色——Agent 不只是处理文本任务，还能是实时交互系统。如果团队准备做语音问数或者实时陪伴类 Agent，网易伏羲这一章是值得反复看的。
综合八个案例，可以提炼出一个判断框架：同一套“语义解析 + RAG + Agent 编排 + 工具调用”的底座，按“交互入口从上手快的文本 UI 演进到语音、实时场景”，按“任务深度从查询取数延伸到根因分析与行动建议”。你的团队在哪个位置，决定了你应该重点读哪一章、抄哪一套方案。
5. ChatBI 落地的避坑指南：幻觉、根因分析和权限管理的工程化应对
这一章把手册里提到的共性问题集中整理，每一条都是真实落地时踩过的坑。按“现象 → 原因 → 解决”的顺序写，方便直接对照排查。
5.1 幻觉问题：bad case 闭环是唯一的捷径
现象：同一个问题换一种说法，系统给出的指标或时间判断就不同；“XX 机构业绩”有时被识别成一个指标，有时被拆成多个指标。用户继续追问“为什么”时，模型开始一本正经地编原因。
原因：大模型本身有“自由发挥”的属性。如果知识库覆盖不到当前业务，或者校准环节缺失，模型只能靠先验知识猜，猜测必然带来不稳定性。平安人寿在问答环节里说得很直接：“不是通过调整一两个参数就能解决的”。
解决：三条措施可以完整执行。第一，建立 bad case 闭环机制，平安人寿的做法是分析十几轮、上千个 bad case，逐条归因；第二，在产品里埋点赞/点踩入口，对点赞过的问题做重点运营分析；第三，把 bad case 的结论沉淀回知识库和意图识别规则，而不是去调 temperature 这类随机参数。注意沉淀回知识库时要定期清理，否则知识库会膨胀出大量重复、互相矛盾的条目，反而让 RAG 检索质量下降。
5.2 根因分析：为什么是公认最难的模块
现象：用户问“为什么这个月续保率下降了”，系统只能给出行变化的事实，说不清楚原因。就算把同环比、各机构明细全部列出，也回答不了“到底哪个因素在起作用”。
原因：要回答“为什么”，必须事先知道指标之间的勾稽关系和相关性。续保率可能受退保率、投诉率、客户满意度、产品到期结构等多个指标影响，其中既有显性关联也有隐性关联、还可能存在时间滞后性。这些关系平时没有以结构化形式建模，模型自然无法推导。
解决：平安人寿给出的方向是构建指标图谱。起步阶段，把指标之间的血缘关系从数据中台抽出来，作为图谱骨架；再通过图算法挖掘指标间的隐性关系。这需要专门的小模型和指标库持续迭代。工程上比较稳妥的启动方式，是先人工梳理前 20 个核心指标，把每个指标的上游、下游、平行关联维度整理成一张带权边的有向图，存到图数据库里通过接口调用，再逐步扩大到全量指标。
5.3 权限管理：从行级到列级，两年数据治理的必然结果
现象：不同角色的用户登录同一张报表，看到的数据结果完全一样。用户 A 没有某指标权限，但直接在问答里提问“这个月人均产能”，系统还是把结果返回出来了。
原因：权限模型停留在行级——只能按用户过滤行数据，控制不了列级指标。ChatBI 是对话式取数，用户可以直接点名要任何指标，如果权限没有精确到“用户 × 指标”的粒度，天然会漏。
解决：把权限模型升级到列级，并建立统一鉴权服务。平安人寿的方法是每次用户调用数据前先走 UM 鉴权，把用户和指标的权限关系放在底层权限服务里统一管理，用账号确定指标使用范围。他们为此做了两到三年的数据治理和数据中台建设。对大多数团队来说，不必一上来就做单元格级权限，先把“指标维度”的权限控制做到位，就能覆盖绝大多数安全风险。
5.4 多轮对话和指标口径：两个容易被忽视的隐性坑
现象：多轮对话场景里，用户第一轮说“看一季度业绩”，第二轮说“那环比呢”，系统常常理解不了“环比”的基准是“一季度”还是“年初”。另一个场景是同一指标在不同部门定义不同，比如“活跃用户”，有的部门定义成登录即活跃，有的要求完成至少一个核心行为才算活跃，同一个问题在不同部门问出不同答案。
原因：第一个坑是因为大模型的上下文窗口有限，且没有把上文的隐含时间基准显式带下来。多轮对话的上下文管理不能只靠拼接历史消息，要主动维护结构化状态。第二个坑是因为指标口径没有中央集权定义，各业务线各说各话，模型一旦检索到冲突的知识库条目，就无法自洽。
解决：在多轮对话模块里，把识别出的指标、时间、维度显式缓存为结构化状态，下一轮提问发生时自动把“时间基准”代入。指标口径则必须在指标字典里统一维护，遇到冲突时以治理后的口径为准，知识库里的冲突条目要定期清理。这两个坑看着小，实际在线上很容易造成“结果对不上、用户不信任”的连锁反应。
6. 把手册变成排错地图：三阶段读法、自检清单与复盘习惯
最后这一章不讲原理，讲怎么用。手册有 134 页，一次读完效率太低，按团队所处阶段取用才是正确姿势。
6.1 三种读法：验证、规模化和扩展
| 团队阶段 | 重点案例 | 要提取的内容 |
|---|---|---|
| 验证阶段（1 到 4 人小团队） | 平安人寿、滴滴 | 九步链路、指标平台 API 兜底路线、最小可行架构 |
| 规模化阶段（已有 BI 平台） | 腾讯、快手 | ABI 工程底座、Agent 编排规范、权限治理 |
| 扩展阶段（想做更智能） | 阿里巴巴、网易伏羲 | 多轮对话管理、根因分析、实时交互设计 |
6.2 三个自检问题
每次读完一个案例，强制问自己三个问题：第一，我的数据中台或者指标平台，是否已经具备能被大模型调用的 API？第二，我的知识库是按“常见/进阶”分层的结构化资产，还是一个被随手扔进向量库的文档合集？第三，如果用户问我“为什么”，系统返回的是数字，还是归因结论？
三个问题的答案，基本能判断你的 ChatBI 项目处在哪个成熟度。如果三问都是否，那最该做的不是换更强的模型，而是回头补数据治理和知识库建设。
6.3 一个翻车后养成的复盘习惯
最后分享一个我自己的习惯：拿到任何 ChatBI 方案，先不急着看模型和 Agent 代码，先画一张“问数链路图”。把从用户提问到报表展示的每个环节都画出来，标注每个环节的输入、输出、耗时上限和失败兜底。平安人寿的九步链路图我直接保存了下来，每次做架构评审时都会拿出来对一遍。
这个习惯是在一次实际翻车之后养成的。当时我们做的问答模块在 demo 时一切正常，一接真实请求问题就随机出现：有时是时间识别错误，有时是权限校验把正常请求拦了。排查了三天，最后发现根本不是大模型的问题，而是链路图里缺了一个“知识库校准”环节，前一步的输出没有对齐到下一步的输入。从那以后我每次接手 ChatBI 项目，都强制先走一遍“链路图 + 关键参数表”的流程，把每一环的输入输出固定下来，再讨论大模型调优和 Agent 细节。这个办法帮我省掉了大量无效排错时间，希望也能帮到你。
本文还有配套的精品资源，点击获取
