企业官网建设流程全解析

简介：《2024 ChatBI+Agent实战手册》全册134页，以八大企业实战案例系统展示大模型与智能BI、AI Agent的结合路径，适合数据分析师、AI研发工程师及企业数字化管理者阅读。资源为1个PDF文件，压缩包共9.33MB，文件虽不庞杂，但134页内容相当充实，覆盖平安人寿、滴滴、喜马拉雅、腾讯、快手、阿里巴巴、网易等企业的真实落地场景，包含项目背景、总体架构、技术方案与成效挑战等完整信息。已有433人学习下载，足见其参考价值。手册从大模型赋能智能BI的四个关键能力出发，讲清自然语言理解、RAG知识学习、工具调用与逻辑推理如何支撑对话式取数、指标管理、SQL生成、多轮问答和自动化分析报告；尤其在平安人寿ChatBI案例中，可以看到从BI 3.0的智能化、自动化、实时化需求到数据中台、平台层、Agent层、应用层的落地拆解，对建设企业级智能分析系统很有帮助。各章节还总结了跨部门协作、模型调优与数据质量保证等常见问题，给出针对性对策，能够帮助读者少走弯路，是2024年ChatBI与Agent实践领域的一份高密度参考资料。

1. ChatBI 与 Agent 的实战手册：八家大厂案例不是 PPT，是能抄的作业

在数据平台这个圈子里，ChatBI 是当下最不缺话题的方向，可真正能拿出来讲的落地案例并不多。这份 134 页的实战手册把平安人寿、滴滴、喜马拉雅、腾讯、快手、阿里巴巴、网易伏羲八家企业的实践收在了一起，从智能报表、对话式取数到 Agent 编程助手和实时语音游戏队友，覆盖了 ChatBI 与 Agent 产品从背景、架构、效果到踩坑的完整链路。它不是讲大模型多厉害，而是讲每一步怎么落到系统里。每个案例都保留了嘉宾的原话问答，比如平安人寿在 SQL 生成路径上的取舍、滴滴在 ABI 方向上的演进节奏，这些都是比结论更值钱的过程信息。适合正在做数据产品、BI 平台或者想引入 Agent 的工程师和管理者，拿它当一份决策参考和方案模板。

2. 为什么 ChatBI 落地卡在“NLP 到数据”这一关：两条路径与六步链路

2.1 直接让大模型写 SQL 为什么容易翻车

传统 BI 的痛点很明确：取数靠提需求、报表靠开发、指标口径靠人记。管理者想查一个业绩数据，走完流程往往要等上几天。ChatBI 想解决的就是这件事——让用户用自然语言直接问数据。但自然语言到数据之间，横着一个大坑：大模型直接生成 SQL。

平安人寿在实践初期就试过让大模型直接生成 SQL，效果并不理想。原文里原话是：直接生成 SQL 的路径和精准度提升很慢，难度较高。这不是模型能力不够，而是企业级数据查询的复杂度远超表面。一个业务问题背后涉及表结构、指标口径、时间粒度、权限范围，SQL 里一个小小的 join 条件写错，结果就是另一套数。

所以现在做 ChatBI 的人基本分成了两派。一派坚持 NL2SQL，让大模型直接写 SQL，靠提示词和微调把准确率磨上去；另一派像平安人寿这样，把大模型的职责收窄到语义理解，真正执行查询交给底层的数据服务中台。手册里平安人寿的技术栈是私有部署的 Qwen 72B，做微调加工程优化，但即便是这个量级的模型，也选择了第二条路径。

2.2 指标平台加 API 调用：平安人寿绕开 SQL 生成的工程思路

平安人寿的方案本质上是把“写 SQL”这件事从大模型手里拿走了。大模型只做一件事：理解用户想问什么。想清楚之后，通过 NLP 技术解析出指标、时间、维度，然后调底层指标平台暴露出来的 API 接口，由数据服务中台去完成实际查询。

这么做的好处是精准度问题被降维了。与其让大模型去猜表结构和 join 关系，不如让它在预设好的指标字典里做选择题。平安人寿能走通这条路，依赖的是两个前置条件：一是完善的数据中台，包含丰富的数据域；二是长达数年的数据治理，沉淀了上万个规范数据指标。这两条缺一条，ChatBI 的方案就退化成“大模型对话 + 手动查数”的缝合怪。

不过这个方案也有它的边界。指标平台能覆盖的查询，前提是指标已经被定义好了。遇到那种从没建模过的临时分析需求，API 模式就查不出来，这时候就需要回到模型生成能力上。所以平安人寿在 Python 生成方面做了规划，把它用于更深度的数据分析场景，跟 SQL 场景分开演进。

2.3 实操：一次 ChatBI 查询走过的六步链路

这六步是平安人寿问数流程的主干，也是做 ChatBI 最需要消化的一段。第一步，用户提问；第二步，经由 BI 大模型做语义理解，结合多轮对话和意图识别，摘出指标、时间、维度这些关键信息；第三步，拿这些信息去知识库做二次校准；第四步，进入 Agent 的任务编排阶段，确定调用哪个工具；第五步，UM 鉴权，确认当前账号对该指标有没有权限；第六步，生成 SQL 调数据库查询，秒级返回，再对结果做可视化包装。

# 可参考的 ChatBI 查询链路伪代码 def chatbi_query(user_input: str, user_id: str): # 1. 意图识别与信息抽取 intent = parse_intent(user_input) # 判定是查数、分析还是口径咨询 if intent == "query": metric, dim, time_range = extract_slots(user_input) # 2. 知识库二次校准：校验指标名、默认时间 metric = knowledge_base.calibrate(metric) # 3. 任务编排：决定走 API 还是 SQL 生成 task = agent_router.route(metric, dim) # 4. 鉴权：确认用户对该指标的列级权限 if not permission_service.check(user_id, metric): return "无权限访问该指标" # 5. 执行查询并返回可视化结果 data = task.execute(metric, dim, time_range) return render_chart(data)

这段伪代码里最关键的是第 2 步和第 4 步。知识库校准解决的是“用户说的指标名跟系统里注册的指标名对不上”的问题，比如用户说“业绩”，系统里可能叫“保费收入”，校准的作用就是做归一。UM 鉴权解决的则是数据安全问题，也是 ChatBI 上生产前必须过的关，后面专门展开讲。

3. Agent 编排与 RAG 知识库：让大模型从“能聊”到“能干活”

3.1 RAG 加外挂知识库：双层设计决定 ChatBI 天花板

大模型本身不懂保险，也不懂你的指标口径，它只懂语言规律。要想让它回答得准，就得把领域知识喂给它。平安人寿在实践中用了两层方案：RAG 技术加外挂知识库。RAG 的作用是在大模型做语义解析的时候，先从知识库里检索相关内容，再用检索到的知识辅助生成，这样准确率能大幅提高。

知识库本身又分两种。常见知识库存的是通用内容，包括常见名词、基础知识和 SQL 语法；进阶知识库则是垂直领域知识，BI 知识库里是同环比、累计这类术语，保险知识库里是保险行业名词，SQL 知识库里是 SQL 编写规范。这种分层设计是有讲究的，基础问题走轻量检索，专业问题走深度检索，互不干扰。

知识库维护这块，手册里讲了一句很实在的话：知识库的丰富度跟语义解析和结果生成的准确性息息相关，需要投入大量精力。很多团队做 ChatBI，模型选型花了两周，知识库随便塞了点文档就上线，结果一问一个错，最后反过来怀疑模型不行。实际上是知识库没做到位。

3.2 四类 Agent 的分工：问数、分析、解读、公共能力

平安人寿在 Agent 层把能力拆成了四类：问数 Agent、分析 Agent、数据解读 Agent 和公共能力 Agent。这个拆分跟很多人想的不一样，它不是一个大 Agent 包打天下，而是按职责拆成多个小 Agent，各自负责一段流程，通过编排协作完成任务。这种多 Agent 协作的价值在于，每个 Agent 的 prompt 可以收敛到单一职责，准确率和可维护性都比单体 Agent 好。

问数 Agent 负责 What，对标的是查数场景，用户问什么答什么；分析 Agent 负责 Why，做根因分析和维度下钻；数据解读 Agent 负责 How，基于分析结果给出结论和建议；公共能力 Agent 提供一些通用能力，比如鉴权、日志、兜底策略。任务执行是整个系统的大脑，通过编排调度不同的工具和知识库。

Agent 跟 LLM 和 AI 模型的关系在这里体现得很清楚：模型是推理基础，Agent 是行动框架。对 ChatBI 这类产品来说，模型负责理解语言，Agent 负责把理解转化为可执行的步骤。如果没有 Agent 这层，大模型就算听懂了用户的问题，也不知道该调哪个 API、该查哪张表、该返回什么格式。

3.3 实操：Agent 编排里最容易忽略的三个设计点

第一个设计点是兜底话术。平安人寿的随机报表功能里有个“兜底”做法：用户提问不完整时，系统自动补齐默认信息，比如默认时间范围。这个看起来简单，实际很考验产品功底。补错默认值比不补更糟，所以兜底逻辑必须建立在用户画像和业务规则之上。

第二个设计点是多轮对话的上下文管理。业务用户在问数据时，经常是“上个月呢”“那华东区呢”这种省略表达。如果 Agent 不维护上下文，每个问题都当新问题处理，用户会把 ChatBI 当成一个不太好用的搜索引擎，用两次就弃了。多轮对话模块需要把历史信息缓存起来，在意图识别时结合上下文做推理。

第三个设计点是任务编排的可观测性。一次查询经过意图识别、知识检索、鉴权、生成、执行多个环节，任何一个环节出错，结果都是错的。所以编排层要记录完整链路日志，包括每次大模型交互的输入输出、工具调用参数、耗时。这些日志是后面做 bad case 分析的原料，没有日志支撑的 ChatBI 优化就是盲人摸象。

4. 权限与合规：ChatBI 落地最容易在中期爆雷的坑

4.1 从行级到列级：指标权限的颗粒度问题

ChatBI 最容易被低估的是权限管理。很多人觉得，能搜到数据就说明用户有权限，搜不到就没有，让大模型处理一下就行。但实际上权限问题不解决，ChatBI 根本过不了安全评审。平安人寿在这块花了大力气，做了两三年的数据治理和权限服务建设，才敢说每个用户能用的指标被严格定义过。

权限的颗粒度经历了从行级到列级的演进。行级权限控制的是用户能看到哪些行的数据，比如只看得到自己所在机构的数据；列级权限则更细，控制用户能看到哪些字段。对一个保险企业来说，同一个指标表里，普通员工能看到汇总数字，管理层能看到机构明细，敏感字段可能在列级就被过滤掉了。平安人寿认为列级别权限管理更细致更安全，所以最终选择了这个方向。

这个演进过程很有代表性。很多企业一开始只做行级权限，因为实现简单，但等到 ChatBI 上线，用户提问绕过了固定报表的权限设定，直接触达底层数据，行级就挡不住了。所以做 ChatBI 前，先盘一下自己的权限体系还停留在哪一级。

4.2 鉴权链路：用户提问、指标映射、权限校验的执行顺序

鉴权不是独立的一个环节，它嵌在查询链路里，而且顺序有讲究。平安人寿的做法是：用户提问后，先做语义理解抽取指标，再做知识库校准，然后进入任务编排之前进行 UM 鉴权。这背后的逻辑是：先搞清楚用户在问什么指标，再判断该不该让他问。如果顺序反了，先鉴权后解析，很多公共问题会被误杀；如果鉴权环节滞后到 SQL 执行阶段，又会造成不必要的资源浪费。

权限服务的实现思路是预设好的：用户账号和指标之间的权限范围关系提前配置好，每次调用时鉴权服务检查一遍。这种检查必须是同步的、强制性的，不能依赖大模型自觉。凡是让大模型在生成 SQL 时自主加权限过滤条件的方案，都不建议在生产环境用，因为大模型的输出不具备确定性。

4.3 实操：指标映射表与权限服务的最小设计

要做列级权限，核心是把“用户—指标—维度—权限”的关系显式化。下面是一个最小可行的指标权限表设计，可以直接当建表参考。

-- 指标权限映射表（最小可行设计） CREATE TABLE metric_permission ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id VARCHAR(64) NOT NULL COMMENT '用户ID，来自统一身份体系', metric_code VARCHAR(128) NOT NULL COMMENT '指标编码，对应指标字典', dim_filter VARCHAR(512) DEFAULT NULL COMMENT '行级维度过滤条件，如 org_id=1001', col_mask VARCHAR(256) DEFAULT NULL COMMENT '列级字段掩码策略，如 amount:mask', effective_start DATE NOT NULL COMMENT '生效开始日期', effective_end DATE DEFAULT NULL COMMENT '生效结束日期，NULL为永久', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_user_metric (user_id, metric_code) ) COMMENT 'ChatBI指标权限映射表';

这个表设计的核心是 user_id 和 metric_code 的组合，决定了什么用户能看什么指标。dim_filter 用来做行级过滤，相当于隐式拼接在查询 SQL 上的 where 条件；col_mask 用来做列级脱敏。鉴权服务每次收到查询请求时，先查这张表，匹配不到就直接拒绝，不进入下一步。这个方案不复杂，但能挡住绝大部分越权查询。

权限控制还有一个容易漏的点：动态维度。用户问“本机构”和“全省”可能是同一个指标，但权限范围不同。所以指标权限表里最好加上维度层级控制，或者在前端把可选维度约束在用户权限范围内，而不是把权限判断完全交给后台。

5. 大模型幻觉、根因分析与知识库维护：ChatBI 避坑清单

5.1 幻觉问题：同一个问题给出了不同回答

现象：用户在不同时间问同一个问题，得到的结果不完全一致，有时甚至相差很大。做演示的时候，第一次问对了，第二次再问却变了。

原因：大模型的生成结果本身带随机性，同义表述的语义解析结果不稳定，加上知识库没有命中或检索到了不相关内容，模型就会在生成环节自由发挥。平安人寿在实践中最直接的感受是没有捷径，需要不断收集 bad case 分析。

解决：建一套 bad case 分析闭环。他们在产品端设置了点赞功能，被点赞的问题会被重点关注，产品运营人员逐个分析。通过十几轮迭代、上千个 bad case 的分析，把问题归类出来——哪些是知识库缺失，哪些是意图识别歧义，哪些是模型能力边界——然后针对性地补知识库、细化意图识别规则、做模型场景细分。

5.2 根因分析：指标变了，但说不清为什么变

现象：用户发现某个指标异常下跌，问 ChatBI 原因，系统只能说出了“数据较上期下降 12%”这种废话，给不出有洞察的分析。

原因：根因分析在 ChatBI 里是最难的问题。指标变动背后可能受多个因素影响，有显性的也有隐性的，大模型虽然能推理，但缺少输入。没有指标之间的勾稽关系和数据模型支撑，模型就没有可以推理的原料。

解决：平安人寿的方向是建设指标图谱。把所有指标间的血缘关系、勾稽关系到指标间的时间滞后性都梳理成图谱，存在数据库里面作为服务接口对外调用。再用图算法计算指标之间的隐性相关性。这些做完了，模型才具备做归因分析的输入基础。这个方向没有捷径，属于基础设施类的重投入。

5.3 知识库维护不可持续：建的时候很爽，用的时候才发现是黑匣子

现象：知识库上线初期效果还行，运行一两个月后准确率下降，而且没人说得清是哪些知识过期了。

原因：知识库缺少版本管理和质量评估机制。内容更新靠人工手动改，改完不验证口径一致性，导致新知识和旧知识互相矛盾。大模型检索到矛盾信息，表现出来就是事实性错误。

解决：给知识库建立版本管理，每次更新记录变更内容和生效时间。知识库的维护走跟开发一样的流程：提需求、评审、修改、验证、发布。每次发布前用历史 bad case 回归一遍，确保修复问题的同时没引入新问题。知识库的丰富度直接影响语义解析准确率，这块不能省。

5.4 一上来就追求中文问数的“完美答案”

现象：业务高层的预期很高，问出的问题宽泛又复杂，比如“今年业绩怎么样，跟去年比差在哪，该怎么办”。系统答不上来，体验预期破灭，项目推进受阻。

原因：ChatBI 能力边界不够清晰。大模型产品最怕的就是演示时给人“什么都能问”的错觉。实际上，宽泛的问题需要拆解成多个子任务，串联多个 Agent 和工具，这对编排能力和数据基础要求极高。预期管理失误比技术失误更伤。

解决：上线初期把能力边界写清楚，支持什么问题、不支持什么问题，在界面上展示出来。先保证窄场景下 90% 以上的准确率，比如“按机构查上月业绩”，再逐步开放复杂分析能力。八家案例里每一家都是先从报表、取数这类确定性场景入手的，没有上来就做智能问答的。预期管理和能力规划，比技术本身更值得花时间。

6. 验证与进阶：从 bad case 准确率到多业务域模型细分

6.1 用 bad case 准确率量化 ChatBI 真实水平

衡量 ChatBI 做得好不好，不是看演示效果，而是看 bad case 率的趋势。我一般会建议在后台把每次用户提问的完整链路日志都收集下来，包括原始问题、意图解析结果、知识库检索结果、SQL 生成结果、执行结果和用户反馈。定期抽一批 case，人工判定哪些是对的哪些是错的。平安人寿分析的十几轮上千个 bad case，本质上就是这个流程。

关键的量化指标是两个：解析准确率和端到端准确率。解析准确率看意图识别和指标映射对不对，端到端准确率看最终给用户的结果对不对。如果前者高后者低，问题出在生成或执行环节；如果两者都低，问题多半在语义理解和知识库。用数据定位优化方向，而不是靠感觉调 prompt。

6.2 从通用模型到场景模型：区分业务的模型演进节奏

ChatBI 跑到一定阶段，会遇到通用模型的个性化瓶颈。平安人寿的思路是，面对不同场景和用户提问做服务细分，针对不同场景开发定制化的小模型，比如预测预警、时间序列预测、指标分析等场景各自适配不同模型。

这个节奏不用太急。我习惯的做法是：先用一个大模型跑通全流程，把 bad case 按场景聚类，数据量证明某个场景的失败率明显高于平均水平时，再去训练或微调一个专用小模型替换。通用大模型加场景小模型的混合架构，比一开始就分散建模型要稳得多。在 Agent 体系里也一样，一个调度入口加多个专用执行 Agent，既要保证协作效率，又要控制维护成本。从那以后我每次验证 ChatBI 效果，都强制走一遍 bad case 标注的流程，不看完十页问题记录不碰参数。这套方法说不上多聪明，但确实是我见过最稳的。希望帮到你。

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