企业官网建设流程全解析

简介：《2024 ChatBI+Agent实战手册（八大案例，共134页）.pdf》是一份聚焦大模型驱动商业智能与智能代理落地的实战合集，适合数据分析师、AI工程师及企业管理人员阅读。资源汇集平安人寿、滴滴、喜马拉雅、腾讯、快手、阿里巴巴、网易等企业的真实案例，覆盖ChatBI产品设计、技术架构、SQL生成、对话式取数、数据分析自动化及AI Agent场景应用，并给出具体的落地挑战与优化思路。全文134页，共1个PDF文件，压缩包约9.33MB，阅读轻便，可按企业章节顺序浏览，也可直接检索所需场景。截至当前已有432人学习，内容兼具行业广度和技术深度。读者既能从中了解头部企业如何搭建ChatBI体系、解决数据质量与模型调优难题，也可借鉴其跨部门协作经验；文档对ChatBI发展现状、未来趋势及模型调优关键作用的总结，更可为自身企业决策支持、智能BI或Agent项目提供直接参考。

1. 为什么 ChatBI 不是“给 BI 加个聊天框”

传统 BI 的痛点不在“没有图表”，而在指标口径不统一、取数要走工单、分析结论靠人工拍脑袋。把大模型接进 BI 之后，最容易被低估的难题也不是“自然语言转 SQL”，而是如何在多轮对话里稳定锁住指标、时间、维度和权限。平安人寿在手册中给出的方案是反直觉的：大模型只做语义理解，SQL 生成交给底层指标平台和 API 服务完成。这个取舍让 ChatBI 从演示 Demo 变成了生产环境里的高频工具。适合数据分析师、数据平台工程师和正在做 Agent 开发的团队参考，尤其是已经建了数据中台但取数效率仍偏低的公司。

2. ChatBI 的总体架构：BI 3.0 的四层拆解与 Agent 编排设计

2.1 从数据中台到应用层的四层架构

手册里平安人寿的实践可以分成四层来理解。最底层是数据中台，负责沉淀数据域和上万个规范指标；往上一层是平台层，集成了 API 服务、知识管理、大模型、Cube 和 GS 平台，以及北斗可视化平台；再往上是 Agent 层，分成问数、分析、数据解读、公共能力四类；最上层是应用层，对外体现为 What、Why、How 三种能力。What 是对话式取数，把数据获取时间从天级压到秒级；Why 是用大模型做根因分析、维度分析，替代人工推导原因；How 是在洞察之后直接给出建议，相当于“开药方”。

这四层不是简单的一层层调用。平台层把知识管理和大模型并列，说明 RAG 检索不是挂在某个模块后面的附件，而是和模型推理同等重要的基础设施。Agent 层拆成四类，则是为了把一次用户提问拆成可复用的小任务：问数 Agent 负责取数，分析 Agent 负责下钻归因，数据解读 Agent 负责把查询结果翻译成人话，公共能力 Agent 统一处理鉴权、指标推荐和元数据查询。这样拆的收益是，后面接入新场景时不需要重写整个链路，只要替换其中一两个子 Agent。

2.1.1 一个最小可用的 Agent 编排配置

下面这个 JSON 是常见做法中的最小编排配置，手工把四类 Agent 的职责写清楚，方便在团队里对齐边界：

{ "agent_id": "chatbi_v1", "intent_agents": ["query_agent", "analysis_agent"], "support_agents": ["data_interpret_agent", "common_agent"], "common_agent_capabilities": ["um_auth", "metric_recommend", "metadata_query"], "model": { "llm": "qwen-72b-private", "temperature": 0.2, "top_p": 0.8 }, "knowledge_base": { "common": ["metric_name", "sql_syntax"], "advanced": ["insurance_terms", "same_period_terms", "sql_rules"] } }

逻辑说明：intent_agents是面向用户主问题的 Agent 组成员，support_agents是结果加工与兜底用的支持节点。common_agent_capabilities列举了公共能力，um_auth是账号鉴权，metric_recommend负责在用户没讲清指标时做推荐，metadata_query对应“言出必答”这类元数据问答。knowledge_base把手册中提到的常见知识库和进阶知识库分开，便于后面接不同的检索源。参数上，temperature和top_p都调低，是为了减少大模型在指标名和时间条件上的自由发挥；私有化部署的qwen-72b-private对应平安人寿提到的 Qwen 72B 微调模型。

提示：Agent 层的四类划分不是固定答案。如果团队只做报表查询，可以先只上问数 Agent 加公共能力 Agent，分析类 Agent 等指标图谱成熟后再接。

2.2 RAG 知识库：决定语义解析准确率的底座

手册里把知识库工作称为“开发过程中最重要的工作之一”。平安人寿用的两层知识库结构很值得参考：常见知识库存常见名词和 SQL 语法，进阶知识库存垂直领域内容，比如 BI 术语里的同比、环比、累计，保险行业名词，以及 SQL 编写规范。大模型在做语义解析后会先检索知识库，再用检索结果做二次校准，然后才进入任务编排。这个顺序保证了同一个词在不同业务域里能命中正确的口径。

下面用一张表看知识库的分层与作用：

表格的价值在于：上线新业务域时，先确认口径落在哪一层，再决定是否需要新增检索源。知识库的丰富度与语义解析和结果生成的准确性直接相关，这是手册中反复提到的一点。

我这里补一个简化版的 RAG 检索函数，用来演示“向量召回—阈值过滤—组装上下文”的过程：

import numpy as np from typing import List def rag_retrieve(query: str, vector_store, top_k: int = 3) -> List[str]: # 1. 把用户问题编码成向量 query_vec = embed(query) # 2. 从知识库召回 top_k 最相似的片段 hit_scores = vector_store.search(query_vec, k=top_k) # 3. 按相似度过滤，低于阈值的片段不送入 prompt valid_hits = [doc for doc, score in hit_scores if score >= 0.75] return valid_hits

逻辑说明：第一步生成用户问题的向量表示；第二步用向量库召回最相近的知识片段；第三步按相似度阈值过滤，避免把不相关的内容塞给大模型。top_k通常取 3 到 5，太小容易漏口径，太大会把噪声带进上下文；阈值 0.75 是实践中的起步值，需要根据自己的 bad case 集去调。

3. 对话式问数的实现链路：意图识别、任务编排与权限鉴权

3.1 一次 ChatBI 请求的完整流程

手册里的业务流程图可以拆成七步：用户提问、BI 大模型语义理解、知识库二次校准、任务编排、UM 鉴权、SQL 生成并查询 Doris、可视化组装。整条链路会多次与大模型交互，而不是一次生成回答就结束。第一步从问题里摘出时间、指标、计算方法、维度四类信息；第二步用知识库校准，防止模型把“累计保费”理解成“当月保费”；第三步的鉴权发生在任务执行前，确保用户对指标有权限，避免越权取数。

这里用 curl 示例模拟“意图识别 + 参数抽取”这一步的接口调用，生产环境通常封装成内部服务，请求头里的鉴权先省略：

curl -s -X POST http://chatbi-internal/parse_intent \ -H "Content-Type: application/json" \ -d '{ "query": "帮我查一下上海机构本月业绩，按团队排序", "knowledge_base": "advanced", "strict_mode": true }'

这条命令传入了用户原始问题、知识库层级和严格模式开关，目标是拿到结构化的查询参数。接口返回的常见格式如下：

{ "metric": "premium_income", "dimensions": ["organization", "team"], "time_range": "2024-07-01~2024-07-31", "sort": {"dimension": "team", "order": "desc"}, "missing_info": [] }

参数说明：metric映射到数据中台的指标 ID，dimensions决定后续 group by 的字段，time_range由“本月”解析出自然月边界，sort由“按团队排序”推导得到。missing_info为空表示信息完整；如果非空，任务编排层会返回追问或使用手册中提到的兜底话术补齐默认时间，比如用户只说了“业绩”没给时间，就默认查最近一个完整月份。

3.2 为什么让指标平台生成 SQL，而不是让大模型直接写 SQL

这是手册问答环节里最值得留意的一个决策。平安人寿的嘉宾明确说，早期尝试过让大模型直接生成 SQL，但实现路径和精准度提升较慢，难度较高，所以最终采用现有指标平台：大模型只做语义理解，之后通过 API 方式和 NLP 技术生成代码，底层数据服务中台负责快速生成数据查询。这个决策的本质，是把口径治理前置到数据中台，换来查询可靠性和权限可控性。

一个典型的数据查询 SQL 模板可以这样写：

SELECT org_name, team_name, SUM(metric_value) AS premium_income FROM dwd_metric_agg WHERE metric_id = ${metric} AND stat_date BETWEEN ${start_date} AND ${end_date} AND ${permission_filter} GROUP BY org_name, team_name ORDER BY premium_income DESC

说明：${metric}、${start_date}、${end_date}由上一节的结构化参数填充，${permission_filter}由权限服务注入。metric_id必须是数据中台里的规范指标 ID，而不是让大模型自由生成的列名。这样做的好处是，即使大模型把“业绩”理解成另一个指标，最终执行的 SQL 仍然落在白名单之内。

3.3 鉴权前置：从行级权限到列级权限

手册提到，平安人寿的权限管理已经从早期的行级别权限服务，进化到列级别权限管理，后者更细致和安全。底层有一个权限服务，每次用户调用时都会做鉴权检查，确保用户和指标的权限范围已经预设好。对应到 Agent 设计里，我会把鉴权放在资源请求之前，而不是在结果返回之前，这样即使模型生成了非法查询，也会在真正执行前被拦截。

下面是一个简化的权限校验伪代码：

def check_permission(user_id: str, metric_id: str, columns: list) -> bool: # 查到该用户在该指标上的列权限清单 allowed_cols = permission_service.get_user_metric_columns(user_id, metric_id) # 请求涉及的列必须在允许清单内 return set(columns).issubset(set(allowed_cols))

参数说明：get_user_metric_columns返回当前用户对这个指标可见的列集合，只要请求涉及的列全部落在集合内，才允许继续执行。如果校验失败，建议返回“请联系数据治理团队申请指标权限”，而不是把内部堆栈抛给用户。

4. 幻觉治理、根因分析与指标图谱：落地中最难的三件事

4.1 bad case 闭环：幻觉治理没有捷径

手册把幻觉问题放在挑战第一位。同一个问题出现不同回答，背后往往不是模型参数问题，而是指标口径没有被知识库约束住。平安人寿的做法是不断收集 bad case，已经分析了十几轮、上千个，并在意图识别里加入各种知识；产品端设置点赞按钮，运营人员对点赞问题逐个分析。他们得出的结论是：通过知识库和数据中台的维护来解决问题，而不是调整一两个参数就能解决。

比较实用的做法是搭一个 bad case 回归表，每次模型或知识库变更后跑一遍，格式可以这样设计：

这张表要和点赞/点踩数据一起看。点赞功能不只是产品交互，它是 bad case 的来源，也是判断修复是否生效的依据。每次更新模型后，优先看这些案例有没有从“失败”变“通过”。

4.2 根因分析：从单指标查询到指标图谱

手册里把根因分析称为最难的问题。当指标变动时，需要判断是哪个维度、哪个关联指标导致的变化，这要求在后台有大量的指标图谱和知识库支撑。方向是把指标之间的勾稽关系和相关性整理成知识图谱，一个指标可能受多个指标影响，包括显性的和隐性的，还要考虑时间滞后性。平安人寿把图谱直接放在数据库里，作为一个服务通过接口调用，并用图算法计算指标之间的隐性关系。

实际工程中，我会先把指标间的相关性计算出来，生成边列表，再灌入图数据库或关系表。下面是一个简化的指标相关性计算片段：

import pandas as pd from scipy.stats import pearsonr def build_metric_edges(metric_df: pd.DataFrame, metric_pairs: list) -> list: edges = [] for m1, m2 in metric_pairs: # 计算两个指标时间序列的相关系数 corr, p_value = pearsonr(metric_df[m1], metric_df[m2]) # 相关系数超过阈值且显著，则记为一条隐性关系边 if abs(corr) > 0.8 and p_value < 0.05: edges.append({"source": m1, "target": m2, "corr": round(corr, 3)}) return edges

说明：metric_df是多个指标按时间对齐的宽表，metric_pairs是需要考察的指标对列表。相关系数高于 0.8 且 p 值小于 0.05 时，认为两个指标存在强相关，可以作为指标图谱中的隐性边。实际场景里要考虑时间滞后性，可以先用shift平移目标序列，再重新计算相关性。

4.3 数据治理和 API 化是 Agent 的隐形前提

手册里平安人寿能快速落地 ChatBI，离不开几个前置条件：完善的数据中台、长期数据治理形成的上万个规范指标、丰富的可视化组件，以及数据服务的 API 化。换句话说，ChatBI 的进度更多被这些工程基础决定，而不是大模型本身。如果团队还没有统一指标字典就直接上 Agent，大模型会在指标映射上反复出错，bad case 很难收敛。

注意：ChatBI 上线前的第一优先级不是选模型，而是确认指标口径是否有唯一负责人。口径不统一时，先补数据治理，再谈 Agent 编排。

5. 八大案例的共性：ChatBI 与 Agent 在不同业务里的同一套骨架

5.1 从平安人寿到滴滴：ABI 演进中的同一条主线

这本手册覆盖了平安人寿、滴滴、喜马拉雅、腾讯、豆包 MarsCode、快手、阿里巴巴和网易伏羲八个案例。前几家公司的场景都围绕“BI + 大模型”展开，但切入点不同：平安人寿强调报表查询秒级化和根因分析，滴滴从 ABI 方向演进，探索智能数据分析的前沿与应用，快手在分析领域做 BI+AI 探索。它们的共同主线是：先把指标治理好，再用 RAG 知识库约束大模型，最后用 Agent 编排把查询、分析、解读串起来。

5.2 喜马拉雅与腾讯：工程底座和多轮对话设计

喜马拉雅和腾讯的案例，更多在讲 ABI 工程化和平台化。喜马拉雅基于大模型做 ChatBI 实践探索，腾讯在 ABI 工程领域探索与实践。工程化的重点通常落在三个地方：一是多轮对话的上下文管理，避免用户问了“上海”再问“那北京呢”时丢失主语；二是查询性能，把秒级返回从演示环境推向生产环境；三是可视化组件复用，让返回数据能自动选择合适的图表。

这里我一般会用上下文状态对象保存每轮已确认的指标和维度，作为 agent 记忆里最基础的一种形式：

class ChatContext: def __init__(self): self.metric = None self.dimensions = [] self.time_range = None def update_from_utterance(self, parsed: dict): # 新一轮解析结果覆盖当前上下文 if parsed.get("metric"): self.metric = parsed["metric"] if parsed.get("dimensions"): self.dimensions = parsed["dimensions"] if parsed.get("time_range"): self.time_range = parsed["time_range"]

说明：update_from_utterance只覆盖新出现的字段，没提到就沿用上一轮的默认值。这个设计能避免大模型在多轮对话中反复猜同一个参数，同时让后续 Agent 拿到稳定的查询条件。生产环境还会给上下文加时间戳，超过 5 轮就压缩成摘要，防止 token 膨胀。

5.3 阿里巴巴、网易伏羲与豆包 MarsCode：Agent 走出 BI 的边界

阿里巴巴的数据消费场景 AI Agent、网易伏羲的实时语音交互游戏队友、豆包 MarsCode 的编程助手 Agent，这三个案例已经超出传统 BI 的范围。它们的共同特点是 Agent 需要调用外部工具并感知环境：数据消费 Agent 要打通不同数据产品，编程助手 Agent 要读写代码文件，游戏 AI Agent 要做实时语音交互。尽管场景不同，Agent 骨架仍然可以沿用“意图识别—工具调用—结果校验”这条链路。

下面这张表是我对手册整体案例的观察整理，方便快速对比使用：

复制案例时不是照搬某一家的架构，而是先找到自己的业务属于哪一列。如果做内部报表，重点参考前五行；如果是外部交互或代码生成，重点看后三行。手册的价值不在于让你抄一套答案，而在于给出不同边界条件下 Agent 设计的选择依据。

6. 从手册到实战：ChatBI Agent 的参数、验证与上线技巧

6.1 参数初始化与回归验证

按手册里的案例做第一版时，我会直接把大模型参数设为低随机性：temperature用 0.1 到 0.2，top_p用 0.8 左右，max_tokens给足到能容纳完整 SQL 和解释文本。知识库检索top_k从 3 开始，相似度阈值从 0.75 开始，然后跑一批问法看漏召回。多轮对话上下文轮数限制在 5 轮以内，超过就把最早一轮压缩成摘要，避免上下文膨胀影响后续意图识别。

回归验证脚本可以这样写：

def validate_regression(question_set: list, parse_func, golden: dict) -> dict: metric_ok, intent_ok = 0, 0 for q in question_set: pred = parse_func(q) if pred["metric"] == golden[q]["metric"]: metric_ok += 1 if pred["intent"] == golden[q]["intent"]: intent_ok += 1 return { "metric_accuracy": metric_ok / len(question_set), "intent_accuracy": intent_ok / len(question_set), "sample_size": len(question_set) }

说明：question_set是提前维护的 50 到 100 条问法，golden是人工标注的期望指标和意图。每次模型或知识库更新后执行一次，指标准确率低于 90% 时先不发布，而是回到 bad case 表里看哪些问法挂了。这个脚本比人工点几个问题更能暴露回归。

6.2 上线前先拦住三类问题

第一类是字段映射错误，修复方式是把“新单”“续期”“个险”“团险”这类词在知识库里的映射维护成表格，每次新指标上线时同步刷新。第二类是权限漏检，试运行阶段要把权限校验结果单独打日志，每天比对一次越权拦截量，确认没有绕过路径。第三类是查询超时，在 Doris 这类 OLAP 引擎上先把 group by 维度和时间范围限制住，再考虑加缓存。我一般会在 Agent 服务里加一个 dry_run 开关，让它返回最终要执行的 SQL 和权限过滤条件，方便在 UI 上做人工核对后再放量。

本文还有配套的精品资源，点击获取