简介《2024 ChatBIAgent实战手册》是一份面向数据分析、AI研发与管理人员的行业实践合集聚焦大模型如何重构商业智能的数据分析流程解决传统BI在智能问答、自动化报表和实时洞察上的瓶颈。资源共1个PDF文件大小9.33MB134页已有433人学习下载。内容按八大案例展开涵盖平安人寿BI 3.0智能化报表、滴滴智能数据分析、喜马拉雅大模型ChatBI实践、腾讯ABI工程、快手BIAI探索、阿里巴巴数据消费场景AI Agent以及网易伏羲实时语音交互AI Agent。各章节不止解析项目背景、整体架构与产品效果还落到SQL生成、对话式取数、根因分析、可视化组装、多轮问答、指标权限管理等技术细节坦诚讨论了模型调优、数据质量与跨部门协作挑战。对规划或实施企业级智能BI、数据分析Agent的团队可直接借鉴其中方案设计与排错思路。1. 一份覆盖八家公司的 ChatBIAgent 手册为什么说它的落地思路比模型本身更值钱大模型本身并不是 ChatBI 落地的胜负手指标治理、Agent 编排和后端查询链路才是。这本 134 页的手册把平安人寿、滴滴、喜马拉雅、腾讯、快手、阿里巴巴、网易伏羲八个真实落地案例放在一起正好回答了一个从业者最关心的问题ChatBI 和 AI Agent 到底是怎么在企业里跑起来的。平安人寿的实践尤其有参考价值——他们用私有化部署的 Qwen 72B 模型把传统 BI 里“提需求→分析需求→获取数据→做分析→写报告”的天级流程压缩成了用户直接提问、秒级返回结果的对话式问数。手册里既有总体架构、技术架构、业务架构这类宏观设计也有 SQL 生成、权限鉴权、知识库维护、坏 case 复盘这些微观落地细节适合正在做智能报表、数据产品、Agent 应用开发的团队拿来对照自己的方案。2. 先看懂 ChatBI 的四层架构数据中台、平台层、Agent 层与应用层怎么分工2.1 从 What/Why/How 反推架构设计很多人拿到 ChatBI 方案第一反应是“找个大模型接上就行了”但平安人寿的架构设计是从用户价值反推的。他们把产品能力拆成三个词What、Why、How。What 是“解放手”用户用自然语言问数系统零代码生成图表查询速度从天级变秒级Why 是“解放脑”用户追问指标为什么变化时大模型基于根因分析、数据洞察、维度分析直接给出原因How 是“开药方”模型不仅告诉用户发生了什么、为什么发生还会基于洞察自动给出建议和措施。这就决定了架构不能只有一层模型服务。如果只做 What一个 NL2SQL 服务加可视化组件就够了但要做 Why 和 How必须在底层准备指标图谱、知识库和小模型工具否则根因分析就是空谈。所以我拆这份手册时建议先看他们四个层级的划分最底层是数据中台承载数据域和上万个治理过的规范指标往上是平台层聚合 API 服务、知识管理、大模型、Cube 与 GS 平台、北斗可视化平台再往上是 Agent 层分问数、分析、数据解读、公共能力四类最上面是应用层把 What/Why/How 三个核心功能对用户开放。这个分层思路比任何模型选型都重要。2.2 平台层用到的五个关键能力API、知识库、Cube 与可视化平台层是平安人寿投入最大的地方也是很多复现者容易低估的部分。手册里提到的平台组件包括 API 服务、知识管理、大模型、Cube 与 GS 平台、北斗可视化平台每个组件都有明确职责。API 服务解决的是“数据服务 API 化”的问题底层 Doris 数据库的查询能力通过 API 暴露给上层这样大模型不需要直接拼接数据库连接串知识管理负责 RAG 检索和知识库维护Cube 与 GS 平台负责指标计算和多维分析可视化平台负责把查询结果组装成图表。这里有一个关键认知知识库不是“锦上添花”而是语义解析准确率的地基。平安人寿用的是 RAG 加外挂知识库两种方式同时上RAG 负责在语义解析后检索相关知识辅助文本和数据生成外挂知识库又分常见知识库和进阶知识库——常见库放通用名词、SQL 语法进阶库放垂直领域知识比如 BI 知识库里的同比、环比、累计口径保险知识库里的行业名词SQL 知识库里的编写规范。我见过不少团队把知识库当成“丢一堆文档进去就行”结果语义解析准确率一直上不去就是因为没做知识分层。2.3 Agent 层的四类拆法和编排边界Agent 层是这套架构里最容易被误读的部分。平安人寿把 Agent 分成四类问数 Agent、分析 Agent、数据解读 Agent、公共能力 Agent。问数 Agent 负责从用户问题里提取时间、指标、维度生成查询分析 Agent 负责归因、对比、趋势判断数据解读 Agent 负责把查询结果转成业务能看懂的文字结论公共能力 Agent 提供鉴权、取数、日志等通用能力。这个分类的价值在于把 Agent 编排的粒度定清楚了。很多团队在做 Agent 时喜欢“一个大 Agent 干所有事”结果提示词越写越长、工具越挂越多bad case 越堆越多。平安人寿的做法是让一个 Agent 对应一种原子能力通过编排组合完成复杂任务。比如用户问“华东区上个月业绩为什么下滑”问数 Agent 先查出数据分析 Agent 再基于指标图谱找关联原因数据解读 Agent 最后生成结论——每个环节都是独立服务任何一个环节出错都只影响该环节不会把整个链路拖垮。2.4 技术架构里的五段链路与一次完整问数把四层架构串起来看一次完整问数涉及五个部分前端用户、多轮对话、Agent 编排、AIBI 工具箱、可视化系统。前端通过插件形式嵌入不同平台负责鉴权、网关控制多轮对话用上下文理解能力捕获用户意图为任务编排做准备Agent 编排是“大脑”负责任务拆分和工具调用AIBI 工具箱承载各种小模型场景比如预测预警、时间序列预测、指标分析可视化系统负责把结果变成图表。我用一段伪代码来描述常见实现里一次问数的完整链路def handle_question(user_question: str, user_id: str): # 1. 多轮对话上下文拼接保留历史会话关键信息 context build_context(user_id, user_question) # 2. 意图识别抽取时间、指标、维度、算子同比/环比/累计 intent llm.semantic_parse(context, schemaINTENT_SCHEMA) # 3. 知识库二次校准用 RAG 检索指标口径和 SQL 规范 kb_chunks rag_retrieve(intent[metric], top_k3) intent llm.calibrate(intent, kb_chunks) # 4. 权限鉴权校验用户是否有该指标的使用权限 if not auth_check(user_id, intent[metric]): return build_response(error无权访问该指标) # 5. 任务编排调用问数 Agent 从指标平台取数 sql_or_query query_agent.build_query( metricintent[metric], dimsintent[dimensions], periodsintent[time_range], operatorsintent[operators] ) df data_api.execute(sql_or_query) # Doris 秒级返回 # 6. 可视化组装匹配图表模板并渲染 chart_spec visual_agent.assemble(df, intent[chart_type]) return build_response(datadf, chartchart_spec)这段代码的逻辑可以对照平安人寿的流程看意图识别负责提取关键信息知识库做二次校准UM 鉴权确认指标权限然后才进入 SQL 生成和数据查询最后做可视化包装。注意第 2 步和第 3 步是两次与大模型的交互不是一次——先用模型做粗提取再用知识库内容校准目的是降低幻觉对后续查询的影响。参数上top_k 一般取 3 到 5太少检索不到有效口径太多会把噪声带进上下文。3. 把自然语言变成 SQL 的工程路径意图识别、指标匹配与兜底策略3.1 传统 NL2SQL 的坑与平安人寿为什么改用指标平台ChatBI 最直观的能力是“让大模型直接生成 SQL”但平安人寿在问答环节里明确说了一个反直觉的结论他们尝试过让大模型直接生成 SQL发现实现路径和精准度提升较慢、难度高最终改用“语义理解 API NLP 生成代码”的方式基于底层指标平台完成查询。这个选择背后是工程现实大模型生成的 SQL 在语法上可以做到正确但在指标口径、权限过滤、维度合法性这些环节上很容易翻车。我拆这份手册时对这一段印象很深它说明了一个问题ChatBI 的价值不在于“模型写 SQL”而在于“模型理解用户在问什么”。一旦意图识别准确查询可以由指标平台已有的 API 完成SQL 只是中间产物。所以复现这个方案时别把精力全砸在提示词上逼模型输出完美 SQL先把指标平台的数据服务准备好让模型只负责语义解析查询交给平台执行精度会稳很多。3.2 意图识别与多轮对话的参数细节平安人寿的业务架构把用户需求分成三类产品功能、问法、指标。产品功能包括指标口径查询、元数据信息、指标推荐、代码生成、多轮对话问法上除了简单问题还支持同比、环比、累计、排序这类复杂查询指标上支持日频、月频、年频最关键的是指标权限管理确保每个用户只能查到自己授权范围内的数据。意图识别是整个链路里最依赖模型调优的环节。我一般会这样设计意图解析的输出结构用 JSON 结构化字段把信息抽干净{ intent: metric_query, metric: 个险新单保费, time_range: {start: 2024-01-01, end: 2024-01-31}, dimensions: [机构, 渠道], operators: [同比, 环比], secondary_question: why_decline, chart_type: bar }这段 JSON 的价值在于把模糊的自然语言变成了结构化参数。time_range 如果用户没说就按默认值补齐——平安人寿的“随机报表”功能里有兜底话术用户提问不完整时系统能补齐默认时间等信息operators 标识用户是否要求同比环比secondary_question 用来捕获追问意图比如用户问完“业绩多少”紧接着问“为什么下滑”模型需要从多轮上下文里知道第二次提问是根因分析。多轮对话的实现不是简单拼接历史消息而是把历史提取出的结构化参数传递到当前轮避免用户每次都要重复说一遍指标和时间。3.3 知识库是如何兜住幻觉的常见库与进阶库的分层平安人寿明确提到大模型幻觉的解决方案是知识库和数据中台兜底而且原话是“通过调整一两个参数是解决不了的”。他们把知识库分层的做法值得抄常见知识库存通用内容比如常见名词、SQL 语法、时间表达规范进阶知识库存垂直领域知识比如 BI 领域的同环比累计术语、保险领域的行业名词、SQL 编写规范。RAG 检索时先查常见库再查进阶库或者两者并行检索、按相关度融合具体看你的知识库规模。我自己的经验是知识库的丰富度直接决定语义解析的准确率但“丰富”不等于“量大”。很多团队往知识库里塞了几千篇文档检索出来的 chunk 跟问题关系不大反而拉低了生成质量。正确做法是先盘点高频指标把每个指标的口径、计算公式、允许维度、常见问法都整理成结构化条目再补通用规则。平安人寿在问答里提到他们已经分析了几十轮、上千个 bad case产品端设置了点赞功能运营人员会逐个分析这个数据足以说明知识库维护是持续投入。3.4 权限与鉴权UM 鉴权如何决定查询是否继续数据权限是 ChatBI 里容易被忽略、但出事就是大事的环节。平安人寿的权限管理已经从行级权限进化到列级权限底层有一个权限服务每次用户调用时都会进行鉴权确保用户和指标的权限范围是预设好的。他们在数据指标上花了两三年时间投入数据治理和数据中台建设才有能力做到列级管控。这个逻辑落到实现上就是在意图识别之后、查询执行之前插入一个鉴权节点。权限校验对象是“用户 指标”不是“用户 表”因为指标才是业务语义的边界。同一个用户在报表平台能看全量数据在 ChatBI 也许只能看本机构数据这个差异必须在指标权限里配置好。我在实际项目中会额外加一层如果用户问到的指标不在权限范围内系统不直接报错而是提示“该指标不在您的授权范围内”并推荐一个有权限的相近指标避免用户因为一次拒绝就对产品失去信任。4. Agent 编排与根因分析从对话式问数到自动分析报告4.1 四类 Agent 如何通过编排支撑完整分析流程四类 Agent 的分工在真实流程里是串行加并行的关系。问数 Agent 先拿到结果分析 Agent 再对结果做归因最后数据解读 Agent 把结论用自然语言表达出来。公共能力 Agent 贯穿全程提供鉴权、日志、异常处理。举个例子用户问“今年 Q2 华东区保费收入为什么环比下降”。问数 Agent 先解析出指标是“保费收入”、维度是“华东区”、时间范围是 Q2、算子包含环比然后从指标平台查到数据分析 Agent 收到数据后会调用根因分析小模型结合指标图谱找关联因素——可能是新单件数下降也可能是件均保费下滑数据解读 Agent 最后把这些结论组装成一段可读的分析报告并给出建议。整个链路里每个 Agent 的输入输出都是结构化数据不是让模型自由发挥。4.2 根因分析为什么“最难”指标图谱、勾稽关系与时间滞后性平安人寿原话是“根因分析是我们认为最难的问题”。难在哪手册问答部分说得很清楚需要给大模型输入指标之间的勾稽关系和相关性而且指标之间的影响有显性和隐性之分还有时间滞后性。一个指标可能受多个指标影响比如保费收入受新单保费、续期保费、退保金额共同影响其中退保金额又有滞后效应。他们给出的方向是做指标图谱包含指标之间的血缘关系数据中台本身已经有这些关系。技术方案是把图谱直接放在数据库里作为一个服务通过接口调用同时具备图算法能力能计算指标之间的隐性关系。我拆到这里越发觉得ChatBI 的深度不在模型层而在业务建模层。如果你要复现根因分析先别急着训练模型把核心指标的血缘关系和图谱数据结构化出来后面的相关性计算才有依据。4.3 多案例对照腾讯、快手、阿里场景中的相似套路手册里另外几家的实践虽然场景不同但底层套路相似。腾讯在 ABI 工程领域的探索重点是把 AI 能力注入传统 BI 工程链强调数据治理与指标标准化——这跟平安人寿“先有上万个规范指标”才能快速落地 ChatBI 的逻辑一致。快手的 BIAI 探索把重心放在分析场景的算子化沉淀上让大模型调用已有的分析算子而不是每次重新生成逻辑这对应了平安人寿的 AIBI 工具箱。阿里巴巴的数据消费场景 AI Agent 实践偏重数据消费链路里的人机交互和多轮上下文管理服务对象是内部数据消费者。网易伏羲的实时语音交互游戏队友则是最特殊的一个Agent 不再面对图表而是面对实时语音和游戏状态这提醒我们 Agent 框架本身是可以复用的但感知层和执行层的差异很大。这些案例放在一起看共性很明显都用大模型做语义理解和生成都依赖底层的指标或数据服务做查询执行都有 Agent 编排来管理多步任务。差异在场景入口——是对话式报表还是数据消费助手还是游戏队友。4.4 从文档到复现八家案例可以提炼的三条通用主线我把八家案例读完后提炼出三条通用主线。第一条是选型线大模型是私有化部署还是调用公有云取决于企业数据合规要求平安人寿因为金融企业规范选择私有部署 Qwen 72B 并微调第二条是链路线用户提问→意图识别→知识校准→权限鉴权→查询执行→可视化组装这六步在多个案例里反复出现说明它已经是 ChatBI 的事实标准流程第三条是迭代线收集 bad case→分析归因→补充知识库→细化模型→回归验证这条线决定了产品准确率能否持续提升。这三条主线也是我评估一份 ChatBI 方案是否可落地的基本框架。如果看到一份方案只讲模型怎么厉害、不讲指标体系怎么建、不讲权限怎么管、不讲坏 case 怎么迭代那大概率还停留在 Demo 阶段。5. 避坑与排查ChatBI 落地时最容易翻车的五个问题5.1 幻觉问题同一个问题多种回答靠调参救不回来现象用户用不同方式问同一个指标系统给出的口径不一致甚至同一个问法在不同时间返回不同结果。原因大模型生成具有随机性加上知识库内容冲突或缺少兜底策略。解决平安人寿的做法是知识库和数据中台兜底同时不断收集 bad case在意图识别里加入各种知识模型针对不同场景做细分。关键动作是产品端加点赞功能对点赞问题重点分析运营人员逐个案例把关。5.2 SQL 生成精度上不去生成路径比模型大小更关键现象模型生成的 SQL 语法正确但结果不对常见于指标口径错误、过滤条件缺失、join 了错误的数据表。原因纯 NL2SQL 路径下模型既要理解语义又要生成可执行 SQL还要掌握指标口径和表结构负担太重。解决换路径——大模型只负责语义理解通过 API 和 NLP 技术在指标平台上生成代码底层数据服务中台快速取数。如果你已经踩了这个坑别急着换更大的模型先把指标平台和查询 API 建好。5.3 根因分析做成了“表面归因”现象用户追问指标下降原因系统只回答“该指标下降了 X%”没有给出任何业务归因。原因缺少指标图谱和勾稽关系输入模型没有数据支撑做深度推理。解决按平安人寿的方向梳理指标之间的血缘和相关性建立指标图谱用图算法计算显性和隐性关系同时考虑时间滞后性。这是一个长期工程适合放在第二阶段做不要在第一版就承诺太多。5.4 权限控制被忽略导致数据越权现象用户 A 能查到本部门以外的数据或者能用对话方式绕过报表平台的权限限制。原因ChatBI 作为新入口没有复用原有权限体系指标和用户之间没有建立映射。解决每次调用都做鉴权从行级权限升级到列级权限把权限服务做成独立组件让所有 Agent 统一走这个通道。权限盘点需要长期数据治理投入但这部分省不得。5.5 知识库只建不用准确率没变化现象知识库文档上传了几百篇但语义解析准确率没有明显提升。原因知识库没有和意图识别流程真正对接或者文档粒度过大、内容冲突、没有维护机制。解决先做高频指标的口径条目以结构化的方式写清楚指标名称、计算口径、允许维度、常见问法每次 bad case 分析后及时把新知识补进库定期清理过期口径确保库里只有当前有效的定义。注意这五个坑在八家案例的分享里或多或少都出现过区别只是严重程度和应对方式。复现时建议按“权限—知识库—查询路径—坏 case 迭代”的顺序依次排查而不是一上来就调模型参数。6. 进阶技巧搭建坏 case 复盘闭环与指标图谱的两个切入点6.1 把点赞功能变成数据资产而不是摆设平安人寿在问答环节提到一个很容易被忽略的细节产品端设置了点赞功能对点赞的问题重点关注运营人员会逐个分析已经分析了十几轮、上千个 bad case。这个机制的价值在于它把模型优化从“等用户投诉”变成“主动收集反馈”。我建议团队在 ChatBI 产品里把“点赞/点踩”做成必选交互点踩时让用户选择一个原因标签比如“结果错误”“口径不符”“回答问题偏了”这样反馈数据可以直接结构化入库。我通常会让运营每周产出一份 bad case 复盘表包含用户原问、模型回答、错误类型、根因分析、知识库更新动作、回归状态六个字段。表结构参考如下。用户原问模型回答错误类型根因分析知识库动作回归状态上月保费多少返回了全公司保费权限缺失缺少机构维度默认值补充默认维度规则已回归通过环比下降原因只回答了下降幅度归因深度不足指标图谱未覆盖该指标新增关联指标边待回归退保率怎么算口径与财务不一致知识冲突知识库存在两版口径清理旧口径文档已回归通过6.2 指标图谱先画血缘关系再补隐性相关性做根因分析前先别追求一步到位。我的习惯是分两步第一步把核心指标的一级血缘关系画出来比如“保费收入 新单保费 续期保费 - 退保金额”这些关系大多能从数据中台的血缘信息里直接拿第二步再通过历史数据计算指标之间的相关性标记时间滞后性。图谱存储直接放数据库对外提供接口查询即可。6.3 四个验证项判断 ChatBI 是否真的落地一是秒级查询是否稳定不是 Demo 里快、生产环境卡二是权限拦截是否有日志可审计每一个被拒绝的请求都能追溯到用户和指标三是坏 case 数量是否随知识库迭代下降四是知识库更新是否是固定节奏而不是想起来才维护。从那以后我每次评审 ChatBI 方案第一件事就是问这三个问题指标口径谁来维护、权限怎么鉴、坏 case 谁来复盘。能答清楚这三点的团队落地成功率会高很多。希望帮到你。本文还有配套的精品资源点击获取
ChatBI+Agent落地实战：从架构设计到根因分析的完整指南
简介《2024 ChatBIAgent实战手册》是一份面向数据分析、AI研发与管理人员的行业实践合集聚焦大模型如何重构商业智能的数据分析流程解决传统BI在智能问答、自动化报表和实时洞察上的瓶颈。资源共1个PDF文件大小9.33MB134页已有433人学习下载。内容按八大案例展开涵盖平安人寿BI 3.0智能化报表、滴滴智能数据分析、喜马拉雅大模型ChatBI实践、腾讯ABI工程、快手BIAI探索、阿里巴巴数据消费场景AI Agent以及网易伏羲实时语音交互AI Agent。各章节不止解析项目背景、整体架构与产品效果还落到SQL生成、对话式取数、根因分析、可视化组装、多轮问答、指标权限管理等技术细节坦诚讨论了模型调优、数据质量与跨部门协作挑战。对规划或实施企业级智能BI、数据分析Agent的团队可直接借鉴其中方案设计与排错思路。1. 一份覆盖八家公司的 ChatBIAgent 手册为什么说它的落地思路比模型本身更值钱大模型本身并不是 ChatBI 落地的胜负手指标治理、Agent 编排和后端查询链路才是。这本 134 页的手册把平安人寿、滴滴、喜马拉雅、腾讯、快手、阿里巴巴、网易伏羲八个真实落地案例放在一起正好回答了一个从业者最关心的问题ChatBI 和 AI Agent 到底是怎么在企业里跑起来的。平安人寿的实践尤其有参考价值——他们用私有化部署的 Qwen 72B 模型把传统 BI 里“提需求→分析需求→获取数据→做分析→写报告”的天级流程压缩成了用户直接提问、秒级返回结果的对话式问数。手册里既有总体架构、技术架构、业务架构这类宏观设计也有 SQL 生成、权限鉴权、知识库维护、坏 case 复盘这些微观落地细节适合正在做智能报表、数据产品、Agent 应用开发的团队拿来对照自己的方案。2. 先看懂 ChatBI 的四层架构数据中台、平台层、Agent 层与应用层怎么分工2.1 从 What/Why/How 反推架构设计很多人拿到 ChatBI 方案第一反应是“找个大模型接上就行了”但平安人寿的架构设计是从用户价值反推的。他们把产品能力拆成三个词What、Why、How。What 是“解放手”用户用自然语言问数系统零代码生成图表查询速度从天级变秒级Why 是“解放脑”用户追问指标为什么变化时大模型基于根因分析、数据洞察、维度分析直接给出原因How 是“开药方”模型不仅告诉用户发生了什么、为什么发生还会基于洞察自动给出建议和措施。这就决定了架构不能只有一层模型服务。如果只做 What一个 NL2SQL 服务加可视化组件就够了但要做 Why 和 How必须在底层准备指标图谱、知识库和小模型工具否则根因分析就是空谈。所以我拆这份手册时建议先看他们四个层级的划分最底层是数据中台承载数据域和上万个治理过的规范指标往上是平台层聚合 API 服务、知识管理、大模型、Cube 与 GS 平台、北斗可视化平台再往上是 Agent 层分问数、分析、数据解读、公共能力四类最上面是应用层把 What/Why/How 三个核心功能对用户开放。这个分层思路比任何模型选型都重要。2.2 平台层用到的五个关键能力API、知识库、Cube 与可视化平台层是平安人寿投入最大的地方也是很多复现者容易低估的部分。手册里提到的平台组件包括 API 服务、知识管理、大模型、Cube 与 GS 平台、北斗可视化平台每个组件都有明确职责。API 服务解决的是“数据服务 API 化”的问题底层 Doris 数据库的查询能力通过 API 暴露给上层这样大模型不需要直接拼接数据库连接串知识管理负责 RAG 检索和知识库维护Cube 与 GS 平台负责指标计算和多维分析可视化平台负责把查询结果组装成图表。这里有一个关键认知知识库不是“锦上添花”而是语义解析准确率的地基。平安人寿用的是 RAG 加外挂知识库两种方式同时上RAG 负责在语义解析后检索相关知识辅助文本和数据生成外挂知识库又分常见知识库和进阶知识库——常见库放通用名词、SQL 语法进阶库放垂直领域知识比如 BI 知识库里的同比、环比、累计口径保险知识库里的行业名词SQL 知识库里的编写规范。我见过不少团队把知识库当成“丢一堆文档进去就行”结果语义解析准确率一直上不去就是因为没做知识分层。2.3 Agent 层的四类拆法和编排边界Agent 层是这套架构里最容易被误读的部分。平安人寿把 Agent 分成四类问数 Agent、分析 Agent、数据解读 Agent、公共能力 Agent。问数 Agent 负责从用户问题里提取时间、指标、维度生成查询分析 Agent 负责归因、对比、趋势判断数据解读 Agent 负责把查询结果转成业务能看懂的文字结论公共能力 Agent 提供鉴权、取数、日志等通用能力。这个分类的价值在于把 Agent 编排的粒度定清楚了。很多团队在做 Agent 时喜欢“一个大 Agent 干所有事”结果提示词越写越长、工具越挂越多bad case 越堆越多。平安人寿的做法是让一个 Agent 对应一种原子能力通过编排组合完成复杂任务。比如用户问“华东区上个月业绩为什么下滑”问数 Agent 先查出数据分析 Agent 再基于指标图谱找关联原因数据解读 Agent 最后生成结论——每个环节都是独立服务任何一个环节出错都只影响该环节不会把整个链路拖垮。2.4 技术架构里的五段链路与一次完整问数把四层架构串起来看一次完整问数涉及五个部分前端用户、多轮对话、Agent 编排、AIBI 工具箱、可视化系统。前端通过插件形式嵌入不同平台负责鉴权、网关控制多轮对话用上下文理解能力捕获用户意图为任务编排做准备Agent 编排是“大脑”负责任务拆分和工具调用AIBI 工具箱承载各种小模型场景比如预测预警、时间序列预测、指标分析可视化系统负责把结果变成图表。我用一段伪代码来描述常见实现里一次问数的完整链路def handle_question(user_question: str, user_id: str): # 1. 多轮对话上下文拼接保留历史会话关键信息 context build_context(user_id, user_question) # 2. 意图识别抽取时间、指标、维度、算子同比/环比/累计 intent llm.semantic_parse(context, schemaINTENT_SCHEMA) # 3. 知识库二次校准用 RAG 检索指标口径和 SQL 规范 kb_chunks rag_retrieve(intent[metric], top_k3) intent llm.calibrate(intent, kb_chunks) # 4. 权限鉴权校验用户是否有该指标的使用权限 if not auth_check(user_id, intent[metric]): return build_response(error无权访问该指标) # 5. 任务编排调用问数 Agent 从指标平台取数 sql_or_query query_agent.build_query( metricintent[metric], dimsintent[dimensions], periodsintent[time_range], operatorsintent[operators] ) df data_api.execute(sql_or_query) # Doris 秒级返回 # 6. 可视化组装匹配图表模板并渲染 chart_spec visual_agent.assemble(df, intent[chart_type]) return build_response(datadf, chartchart_spec)这段代码的逻辑可以对照平安人寿的流程看意图识别负责提取关键信息知识库做二次校准UM 鉴权确认指标权限然后才进入 SQL 生成和数据查询最后做可视化包装。注意第 2 步和第 3 步是两次与大模型的交互不是一次——先用模型做粗提取再用知识库内容校准目的是降低幻觉对后续查询的影响。参数上top_k 一般取 3 到 5太少检索不到有效口径太多会把噪声带进上下文。3. 把自然语言变成 SQL 的工程路径意图识别、指标匹配与兜底策略3.1 传统 NL2SQL 的坑与平安人寿为什么改用指标平台ChatBI 最直观的能力是“让大模型直接生成 SQL”但平安人寿在问答环节里明确说了一个反直觉的结论他们尝试过让大模型直接生成 SQL发现实现路径和精准度提升较慢、难度高最终改用“语义理解 API NLP 生成代码”的方式基于底层指标平台完成查询。这个选择背后是工程现实大模型生成的 SQL 在语法上可以做到正确但在指标口径、权限过滤、维度合法性这些环节上很容易翻车。我拆这份手册时对这一段印象很深它说明了一个问题ChatBI 的价值不在于“模型写 SQL”而在于“模型理解用户在问什么”。一旦意图识别准确查询可以由指标平台已有的 API 完成SQL 只是中间产物。所以复现这个方案时别把精力全砸在提示词上逼模型输出完美 SQL先把指标平台的数据服务准备好让模型只负责语义解析查询交给平台执行精度会稳很多。3.2 意图识别与多轮对话的参数细节平安人寿的业务架构把用户需求分成三类产品功能、问法、指标。产品功能包括指标口径查询、元数据信息、指标推荐、代码生成、多轮对话问法上除了简单问题还支持同比、环比、累计、排序这类复杂查询指标上支持日频、月频、年频最关键的是指标权限管理确保每个用户只能查到自己授权范围内的数据。意图识别是整个链路里最依赖模型调优的环节。我一般会这样设计意图解析的输出结构用 JSON 结构化字段把信息抽干净{ intent: metric_query, metric: 个险新单保费, time_range: {start: 2024-01-01, end: 2024-01-31}, dimensions: [机构, 渠道], operators: [同比, 环比], secondary_question: why_decline, chart_type: bar }这段 JSON 的价值在于把模糊的自然语言变成了结构化参数。time_range 如果用户没说就按默认值补齐——平安人寿的“随机报表”功能里有兜底话术用户提问不完整时系统能补齐默认时间等信息operators 标识用户是否要求同比环比secondary_question 用来捕获追问意图比如用户问完“业绩多少”紧接着问“为什么下滑”模型需要从多轮上下文里知道第二次提问是根因分析。多轮对话的实现不是简单拼接历史消息而是把历史提取出的结构化参数传递到当前轮避免用户每次都要重复说一遍指标和时间。3.3 知识库是如何兜住幻觉的常见库与进阶库的分层平安人寿明确提到大模型幻觉的解决方案是知识库和数据中台兜底而且原话是“通过调整一两个参数是解决不了的”。他们把知识库分层的做法值得抄常见知识库存通用内容比如常见名词、SQL 语法、时间表达规范进阶知识库存垂直领域知识比如 BI 领域的同环比累计术语、保险领域的行业名词、SQL 编写规范。RAG 检索时先查常见库再查进阶库或者两者并行检索、按相关度融合具体看你的知识库规模。我自己的经验是知识库的丰富度直接决定语义解析的准确率但“丰富”不等于“量大”。很多团队往知识库里塞了几千篇文档检索出来的 chunk 跟问题关系不大反而拉低了生成质量。正确做法是先盘点高频指标把每个指标的口径、计算公式、允许维度、常见问法都整理成结构化条目再补通用规则。平安人寿在问答里提到他们已经分析了几十轮、上千个 bad case产品端设置了点赞功能运营人员会逐个分析这个数据足以说明知识库维护是持续投入。3.4 权限与鉴权UM 鉴权如何决定查询是否继续数据权限是 ChatBI 里容易被忽略、但出事就是大事的环节。平安人寿的权限管理已经从行级权限进化到列级权限底层有一个权限服务每次用户调用时都会进行鉴权确保用户和指标的权限范围是预设好的。他们在数据指标上花了两三年时间投入数据治理和数据中台建设才有能力做到列级管控。这个逻辑落到实现上就是在意图识别之后、查询执行之前插入一个鉴权节点。权限校验对象是“用户 指标”不是“用户 表”因为指标才是业务语义的边界。同一个用户在报表平台能看全量数据在 ChatBI 也许只能看本机构数据这个差异必须在指标权限里配置好。我在实际项目中会额外加一层如果用户问到的指标不在权限范围内系统不直接报错而是提示“该指标不在您的授权范围内”并推荐一个有权限的相近指标避免用户因为一次拒绝就对产品失去信任。4. Agent 编排与根因分析从对话式问数到自动分析报告4.1 四类 Agent 如何通过编排支撑完整分析流程四类 Agent 的分工在真实流程里是串行加并行的关系。问数 Agent 先拿到结果分析 Agent 再对结果做归因最后数据解读 Agent 把结论用自然语言表达出来。公共能力 Agent 贯穿全程提供鉴权、日志、异常处理。举个例子用户问“今年 Q2 华东区保费收入为什么环比下降”。问数 Agent 先解析出指标是“保费收入”、维度是“华东区”、时间范围是 Q2、算子包含环比然后从指标平台查到数据分析 Agent 收到数据后会调用根因分析小模型结合指标图谱找关联因素——可能是新单件数下降也可能是件均保费下滑数据解读 Agent 最后把这些结论组装成一段可读的分析报告并给出建议。整个链路里每个 Agent 的输入输出都是结构化数据不是让模型自由发挥。4.2 根因分析为什么“最难”指标图谱、勾稽关系与时间滞后性平安人寿原话是“根因分析是我们认为最难的问题”。难在哪手册问答部分说得很清楚需要给大模型输入指标之间的勾稽关系和相关性而且指标之间的影响有显性和隐性之分还有时间滞后性。一个指标可能受多个指标影响比如保费收入受新单保费、续期保费、退保金额共同影响其中退保金额又有滞后效应。他们给出的方向是做指标图谱包含指标之间的血缘关系数据中台本身已经有这些关系。技术方案是把图谱直接放在数据库里作为一个服务通过接口调用同时具备图算法能力能计算指标之间的隐性关系。我拆到这里越发觉得ChatBI 的深度不在模型层而在业务建模层。如果你要复现根因分析先别急着训练模型把核心指标的血缘关系和图谱数据结构化出来后面的相关性计算才有依据。4.3 多案例对照腾讯、快手、阿里场景中的相似套路手册里另外几家的实践虽然场景不同但底层套路相似。腾讯在 ABI 工程领域的探索重点是把 AI 能力注入传统 BI 工程链强调数据治理与指标标准化——这跟平安人寿“先有上万个规范指标”才能快速落地 ChatBI 的逻辑一致。快手的 BIAI 探索把重心放在分析场景的算子化沉淀上让大模型调用已有的分析算子而不是每次重新生成逻辑这对应了平安人寿的 AIBI 工具箱。阿里巴巴的数据消费场景 AI Agent 实践偏重数据消费链路里的人机交互和多轮上下文管理服务对象是内部数据消费者。网易伏羲的实时语音交互游戏队友则是最特殊的一个Agent 不再面对图表而是面对实时语音和游戏状态这提醒我们 Agent 框架本身是可以复用的但感知层和执行层的差异很大。这些案例放在一起看共性很明显都用大模型做语义理解和生成都依赖底层的指标或数据服务做查询执行都有 Agent 编排来管理多步任务。差异在场景入口——是对话式报表还是数据消费助手还是游戏队友。4.4 从文档到复现八家案例可以提炼的三条通用主线我把八家案例读完后提炼出三条通用主线。第一条是选型线大模型是私有化部署还是调用公有云取决于企业数据合规要求平安人寿因为金融企业规范选择私有部署 Qwen 72B 并微调第二条是链路线用户提问→意图识别→知识校准→权限鉴权→查询执行→可视化组装这六步在多个案例里反复出现说明它已经是 ChatBI 的事实标准流程第三条是迭代线收集 bad case→分析归因→补充知识库→细化模型→回归验证这条线决定了产品准确率能否持续提升。这三条主线也是我评估一份 ChatBI 方案是否可落地的基本框架。如果看到一份方案只讲模型怎么厉害、不讲指标体系怎么建、不讲权限怎么管、不讲坏 case 怎么迭代那大概率还停留在 Demo 阶段。5. 避坑与排查ChatBI 落地时最容易翻车的五个问题5.1 幻觉问题同一个问题多种回答靠调参救不回来现象用户用不同方式问同一个指标系统给出的口径不一致甚至同一个问法在不同时间返回不同结果。原因大模型生成具有随机性加上知识库内容冲突或缺少兜底策略。解决平安人寿的做法是知识库和数据中台兜底同时不断收集 bad case在意图识别里加入各种知识模型针对不同场景做细分。关键动作是产品端加点赞功能对点赞问题重点分析运营人员逐个案例把关。5.2 SQL 生成精度上不去生成路径比模型大小更关键现象模型生成的 SQL 语法正确但结果不对常见于指标口径错误、过滤条件缺失、join 了错误的数据表。原因纯 NL2SQL 路径下模型既要理解语义又要生成可执行 SQL还要掌握指标口径和表结构负担太重。解决换路径——大模型只负责语义理解通过 API 和 NLP 技术在指标平台上生成代码底层数据服务中台快速取数。如果你已经踩了这个坑别急着换更大的模型先把指标平台和查询 API 建好。5.3 根因分析做成了“表面归因”现象用户追问指标下降原因系统只回答“该指标下降了 X%”没有给出任何业务归因。原因缺少指标图谱和勾稽关系输入模型没有数据支撑做深度推理。解决按平安人寿的方向梳理指标之间的血缘和相关性建立指标图谱用图算法计算显性和隐性关系同时考虑时间滞后性。这是一个长期工程适合放在第二阶段做不要在第一版就承诺太多。5.4 权限控制被忽略导致数据越权现象用户 A 能查到本部门以外的数据或者能用对话方式绕过报表平台的权限限制。原因ChatBI 作为新入口没有复用原有权限体系指标和用户之间没有建立映射。解决每次调用都做鉴权从行级权限升级到列级权限把权限服务做成独立组件让所有 Agent 统一走这个通道。权限盘点需要长期数据治理投入但这部分省不得。5.5 知识库只建不用准确率没变化现象知识库文档上传了几百篇但语义解析准确率没有明显提升。原因知识库没有和意图识别流程真正对接或者文档粒度过大、内容冲突、没有维护机制。解决先做高频指标的口径条目以结构化的方式写清楚指标名称、计算口径、允许维度、常见问法每次 bad case 分析后及时把新知识补进库定期清理过期口径确保库里只有当前有效的定义。注意这五个坑在八家案例的分享里或多或少都出现过区别只是严重程度和应对方式。复现时建议按“权限—知识库—查询路径—坏 case 迭代”的顺序依次排查而不是一上来就调模型参数。6. 进阶技巧搭建坏 case 复盘闭环与指标图谱的两个切入点6.1 把点赞功能变成数据资产而不是摆设平安人寿在问答环节提到一个很容易被忽略的细节产品端设置了点赞功能对点赞的问题重点关注运营人员会逐个分析已经分析了十几轮、上千个 bad case。这个机制的价值在于它把模型优化从“等用户投诉”变成“主动收集反馈”。我建议团队在 ChatBI 产品里把“点赞/点踩”做成必选交互点踩时让用户选择一个原因标签比如“结果错误”“口径不符”“回答问题偏了”这样反馈数据可以直接结构化入库。我通常会让运营每周产出一份 bad case 复盘表包含用户原问、模型回答、错误类型、根因分析、知识库更新动作、回归状态六个字段。表结构参考如下。用户原问模型回答错误类型根因分析知识库动作回归状态上月保费多少返回了全公司保费权限缺失缺少机构维度默认值补充默认维度规则已回归通过环比下降原因只回答了下降幅度归因深度不足指标图谱未覆盖该指标新增关联指标边待回归退保率怎么算口径与财务不一致知识冲突知识库存在两版口径清理旧口径文档已回归通过6.2 指标图谱先画血缘关系再补隐性相关性做根因分析前先别追求一步到位。我的习惯是分两步第一步把核心指标的一级血缘关系画出来比如“保费收入 新单保费 续期保费 - 退保金额”这些关系大多能从数据中台的血缘信息里直接拿第二步再通过历史数据计算指标之间的相关性标记时间滞后性。图谱存储直接放数据库对外提供接口查询即可。6.3 四个验证项判断 ChatBI 是否真的落地一是秒级查询是否稳定不是 Demo 里快、生产环境卡二是权限拦截是否有日志可审计每一个被拒绝的请求都能追溯到用户和指标三是坏 case 数量是否随知识库迭代下降四是知识库更新是否是固定节奏而不是想起来才维护。从那以后我每次评审 ChatBI 方案第一件事就是问这三个问题指标口径谁来维护、权限怎么鉴、坏 case 谁来复盘。能答清楚这三点的团队落地成功率会高很多。希望帮到你。本文还有配套的精品资源点击获取
