线上异常指标智能洞察

导读 本次分享题目为线上异常指标智能分析，主要介绍大模型与 BI 结合方向上的一些进展，首先介绍业务中台面对的场景以及建设目标，其次是我们开展 Agent 的建设思路，最后是实践。

主要包括：

1. 中台项目背景介绍

2. Agent 建设思路

3. 智能分析探索与实践

分享嘉宾｜彭阳 百度在线网络有限公司 技术专家

编辑整理｜龚萱

内容校对｜郭慧敏

出品社区｜DataFun

01

中台项目背景介绍

首先和大家介绍下数据中台面对的业务场景。

在数据中台建设中，主要面对以下三个场景的数据需求：数据报表类需求、指标归因分析、数据洞察，其中最常见的是第一类数据分析需求。

1. 数据报表类需求

在数据分析的实际业务场景中，第一类需求是最常见的。对于业务而言，面对海量数据和复杂的业务逻辑，传统的处理方式往往需要分析师向数据开发团队提交需求，经过排期开发才能完成，这个过程不仅耗时，沟通成本也很高。虽然我们中台建设了 BIP 平台，通过拖拽式报表功能让业务伙伴能自助完成部分分析需求，但由于底层数据建模的复杂性和学习门槛，这种自助化能力仍然存在较大局限。

在引入大模型技术之前，我们尝试过自然语言转 SQL 的方案，比如 NL2SQL/Seq2SQL 和规则引擎的方式。这类技术对于固定模式的简单查询效果尚可，但遇到需要灵活调整或较为复杂的查询场景时就显得力不从心，导致这项能力长期处于调试优化的状态。

大模型技术的出现带来了根本性的突破。凭借其强大的逻辑推理和代码生成能力，结合针对性地进行的工程化适配，现在这项技术已经真正落地到生产环境，能够有效解决复杂查询的需求。目前这一方向已经成为行业共识，各大厂商都在积极推进相关能力的建设。可以说，从传统的人工开发模式，到部分自助化，再到现在通过大模型实现真正的智能分析，我们正在经历一场数据分析方式的革命性变革。

2. 指标归因分析

在第二个场景中，我们探讨了指标供应分析的应用。在业务场景中，这种能力经常被使用，例如在数据报表的制作过程中。当指标出现异常时，通常需要进行指标分析，随后开展关联业务分析。这一过程往往较为繁琐和耗时。通过一系列分析后，我们得出相应结论，此时可以考虑对方案进行优化。例如，利用归因分析 Agent 学习业务方案，借鉴其分析思路，最终自动化生成归因分析报告，从而提升效率和准确性。

3. 数据洞察

数据洞察场景更智能化，旨在优化运营或 PM 同学的日常工作。这些同学每日首要任务是检查业务报表异常，如有异常则需手动分析。为此，我们提供天级任务看板，在数据产出后自动推送潜在异常及其原因。以百家号运营为例，看板首先显示当日异常处理数量，其次展示核心指标每日表现（如新增发文量突降），并分析原因（如体育垂类波动导致），进一步定位到具体责任机构，同时推荐解决方案。这样，运营同学可省去大量数据分析工作，直接通过动态看板进行业务决策。

针对刚才的这三类需求，我们通过 AI 加 BI 建设提升业务数据分析和数据洞察效率。主要做这几件事情：

• 首先是自助取数，让业务同学用自然语言方式完成数据提取及报表生成；
• 报表生成后，提供多种策略配置协助业务方进行指标告警，当指标出现波峰波谷时，智能体学习业务排查思路自动给出归因分析报告；
• 最后将这些数据分析能力输出到业务中，与业务自建的 Agent 协助配合，端到端输出指标波动的最终结论。

02

Agent 建设思路

针对数据中台 Agent 的建设思路，我们将其分为四部分：

• 最底层是数据打点，业务方数据来自端和服务方打点，通过中台采集、持久化并转发到数据中台；
• 中台收到数据后，构建离线数仓和实时数仓，并将报表指标维度注册到指标中台。平台建设采用大模型加专业小模型方式，在 SQL 代码生成等专精场景进行模型训练，并集成 RAG、意图理解及 Agent 编排等工程能力，同时完成模型训练和效果评估。
• 随后构建业务能力，通过 Text2SQL 或 Text to 图表实现需求自助，提供异动分析、归因算法和经验图谱能力，当报表波动时自动生成归因报告；面对复杂场景，与业务方协作进行多 Agent 编排，端到端输出解决方案。
• 最终，这些能力输出到上游 20 多个业务中，助力快速业务分析。

在 BI 平台的智能化架构设计中，我们构建了由两大核心模块组成的系统。

当用户发起请求时，首先经过智能编排模块，该模块深度解析用户意图，识别其所属场景和查询目的，并据此规划相应的任务执行路径。

随后进入 Agent 集合模块，这里整合了两类 Agent 能力：平台内置的数据分析 Agent（如智能用数、智能归因等）和业务方自主开发的定制化 Agent（如全网热点搜索、指标业务分析等）。这种设计源于对复杂业务场景的洞察，需要数据分析 Agent 与业务 Agent 协同形成工作流来精准定位问题。每个 Agent 都独立维护运行状态和输出结果，这些结果将作为后续 Agent 的输入依据。

最终，所有分析过程会汇总至总结模块，经过系统化梳理后生成完整的分析报告反馈给用户。

03

智能分析探索与实践

1. 智能问数&归因

在智能分析落地的实践中，智能问数和归因分析的关键在于数仓建设。当前行业存在两种主流路径：

• 基于现有数仓平台，复用已构建的数据集和报表进行模型训练，这种方式成本较低但面临严重问题，包括传统四层数仓建模混乱、指标口径不统一等问题；
• 以指标中台为核心重构数仓，虽然能实现建模合理化和口径统一，但转型成本较高。

我们观察到传统四层建模存在明显缺陷：结构过于复杂导致表数量快速膨胀（部分业务层级达 500 多张表），指标分散且同名称在不同层级可能含义和计算方式不同，这直接导致需求开发困难（需编写数百行 SQL 或十多张表关联），同时也严重影响了 chatBI 和归因分析的准确率。尽管尝试了多种工程化手段，但准确度提升仍面临瓶颈。为此，我们采用宽表建模构建指标中台的方式来应对这些挑战，旨在优化数据结构、降低维护成本并提升分析准确性。

这一方案的核心在于将复杂的加工逻辑集中沉淀到宽表层，并采用 HDFS 和 ClickHouse 实现冷热数据分层存储。重构过程中，我们特别注重将新增或变更的指标维度同步至指标中台，确保在宽表层就完成指标口径的统一管控。实施后成效显著：原本 500 多张层级表被精简为 20 余张核心宽表，数据结构大幅简化。现在用户只需编写简单 SQL 语句或通过 chatBI 生成简单 SQL，即可完成大多数分析需求。目前该体系已实现业务自主分析占比达 80%，仅 20% 需求需要数据开发团队介入进行宽表迭代优化，整体效率得到质的提升。

在完成数仓重构后，我们重点推进了智能问数与归因分析能力的建设。智能问数的核心在于提升准确率和时效性，其技术实现本质是通过表的 schema 和用户查询信息生成可执行的 SQL。但这一过程面临多重挑战：如何精准匹配用户查询与表字段、理解各业务方的专业术语、提升响应速度，以及处理 SQL 生成错误等问题。为此，我们将问数流程划分为数据构建和查询分析两大阶段。

• 数据构建阶段通过业务数据标注、现有数据集和指标中台的口径统一，构建 RAG 能力和训练专业模型，旨在增强大模型对业务的理解，提高回答的准确性和时效性。
• 查询分析阶段则从用户意图识别开始，通过查询优化改写（如提供 select 建议或案例参考）提升输入质量。SQL 生成环节细分为选表、构建和验证三个子阶段，其中选表准确率尤为关键。

我们采用小模型和 RAG 技术相结合的方式，借助宽表建模的成果（将多表查询简化为 1-2 张表查询）和全面的业务场景覆盖，使表召回准确率显著提升，为后续流程奠定了坚实基础。

在字段选择阶段，我们充分利用宽表建模的优势，通过 RAG 和高级 RAG 技术实现智能字段筛选。由于宽表字段较多，直接全量输入会影响大模型处理的准确性和时效性，因此我们采用基于相似查询案例的 few-shot 学习方式，精准召回相关字段。在 SQL 生成环节，我们选用经过 DeepSeek-R1 蒸馏的 32B 小模型，在保证准确率的同时显著提升响应速度。针对特殊情况，系统可灵活切换至 R1 或 V3 等大模型，配合完善的 RAG 工程确保效果。最后，我们设计了自我修正机制，当生成的 SQL 出现错误时，系统会自动进行反思和二次回答，经过多重校验后才会将最终结果交付业务方使用。这种分层处理方式既保证了智能问数的准确性，又维持了高效的服务响应能力。

完成智能问数能力建设后，我们重点推进了归因分析功能的开发。针对业务报表中常见的指标波动问题，传统的人工排查方式需要从数十个维度逐一分析，效率较低。为此，我们构建了一套通用归因分析解决方案：首先获取指标数据并计算同比环比，识别异常指标；然后通过维度权重挖掘（基于查询频次赋予不同权重）和贡献度计算（采用超均、波动等业界通用算法），最终输出归因结果。该方案的显著优势在于扩展性强，可适配各类业务场景，且采用的技术方案成熟稳定。但同时也存在明显局限：仅适用于单表分析，无法理解业务指标间的内在关联，导致准确性不足。特别是当业务方需要按照特定逻辑（如依次分析指标 A、B、C）进行归因时，这种通用方法难以满足需求。这反映出当前方案在业务理解深度方面的不足，也是我们后续需要重点优化的方向。

2. 指标智能洞察

为优化归因分析方案，我们核心思路是让智能体深度贴合业务，学习其分析思路的思考过程，完全按照业务逻辑进行问题分析。以百家号智慧运营合作为例：当发现发文量减少时，其业务排查流程为：

• 定位具体垂类
• 分析该垂类下用户画像作者或发文来源
• 挖掘百家号宽标中的异常机构/作者账号。

通用归因分析无法解决此类业务定制问题，因此我们改造归因分析 Agent，使其学习并固化这套业务排查流程。具体实现上，将业务排查过程构建为知识图谱，运用 Graph-RAG 技术拆解为三要素：实体模型（核心分析步骤节点）、关系定义（步骤间因果/依赖触发关系） 和路径推理（基于有向无环图结构，由大模型学习业务经验动态决策下游路径），让 Agent 学习业务的排查逻辑。

在第二个案例中，我们将数据分析 Agent 能力深度集成到 QA 团队的线上问题排查助手。背景源于各 APP 频繁出现崩溃或卡顿问题，其根本原因常是业务方在 APP 进行线上资源变更引发用户崩溃。当前排查完全依赖人找人的传统方式，导致问题定位时间显著延长，进而加剧现场问题对用户的实际影响。我们发现这种流程存在明显缺陷：定位耗时长短高度依赖值班同学对端上各组件或模块的熟悉程度，这种随机性极大的机制是不合理的。

为此，我们将智能洞察能力嵌入问题定位全流程：当线上指标出现异常时，首要动作是启动归因分析 Agent，自动诊断问题核心特征（复用第一个案例的 Agent 能力）。同时响应业务核心诉求——还原业务现场，通过专门构建的用户行为分析 Agent，深度挖掘受影响用户的共同行为模式。

具体实施分为三阶段精准推进：

• 上线单追溯阶段：构建上线单推进 Agent，根据问题特征精确召回异常波动时间点前后的上线变更记录，直接定位"是哪个上线导致节点波动"；
• 解决方案生成阶段：基于特征分析结果，即时给出针对性止损措施或修复方案；
• 闭环输出阶段：自动化生成包含根因定位、行为分析及解决路径的完整报告，直接交付业务同学。

3. 多 Agent 智能编排

在第二个案例中，我们将数据分析 Agent 能力深度集成到 QA 团队的线上问题排查助手。背景源于各 APP 频繁出现崩溃或卡顿问题，其根本原因常是业务方在 APP 进行线上资源变更引发引发用户崩溃。当前排查完全依赖人找人的传统方式，导致问题定位时间显著延长，进而加剧现场问题对用户的实际影响。我们发现这种流程存在明显缺陷：定位耗时长短高度依赖值班同学对端上各组件或模块的熟悉程度，这种随机性极大的机制是不合理的。

我们与各业务方共同建设了三大核心 Agent 体系。

• 归因分析 Agent 的构建思路与前述百家号案例高度一致：均将业务排查经验沉淀为知识图谱 DAG（有向无环图），由大模型学习业务经验并动态决策后续分析路径。
• 用户行为分析 Agent 的核心在于挖掘同类型异常用户的共性行为：当线上问题发生时，通过受影响用户的设备信息回溯异常时间点的完整行为序列，经聚类模型形成行为簇，再通过频次序列挖掘算法精准定位问题用户的 Top3 高频行为路径。
• 上线单推荐 Agent 则融合业务方与数据分析团队的双重优势：业务方主导打通厂内上线平台，数据分析团队专注线上特征挖掘。通过特征提取策略（如时间邻近原则——指标波动后越近的上线变更可疑度越高；或 AB 实验分析——实验组与对照组数据差异显著时判定实验异常）对上线单进行智能召回与排序，最终锁定引发指标波动的具体上线变更记录。

通过这套 Agent 体系，业务同学处理指标问题的模式发生根本性变革：从传统"人找人"的跨模块协同（耗时小时级），转变为掌握 Agent 工具后的自主分钟级定位。当前各 Agent 的准确率均稳定在 80% 以上。

为满足业务方对快速数据分析及线上指标异常即时定位的需求，我们与业务方协作构建了系列工具与 Agent 体系。但随着复杂场景增多，业务方在指标定位时需协同调用多个 Agent 工具，导致用户面临学习成本过高的问题——许多业务方仍沿用传统人工排查方式，不愿使用新工具。

为此我们对调用机制进行重大调整：取消业务方手动调用工具的模式，转而基于异常场景增设智能编排模块。该模块通过学习业务方历史排查步骤，在指标异常发生时自动调度各 Agent 工具协同作业，最终直接生成问题定位报告。

在智能规划 Agent 的架构选型中，我们调研了业界多类框架：

• 低代码框架（如 dify/coze/百度千帆）适合非技术人员通过拖拉拽快速构建智能体，但灵活性不足；
• MultiAgent 框架（如 MetaGPT/crewAI）通过大模型模拟多角色协作分工，但因可控性差暂不适用；
• 最终选择代码中间层框架（如 langgraph/eino），在编排中融合代码逻辑与大模型规划能力，实现任务流程的可控自动化。

以线上问题分析为例，编排模块将流程拆解为三阶段闭环：

• 影响面分析阶段：自动评估问题影响范围，向业务方明确紧急程度；
• 特征定位阶段：通过特征分析精准指向责任模块，告知对应业务同学介入；
• 异常修复阶段：综合调度工具链，指引业务方完成路径修复——包括锁定问题上线单、执行止损措施及修复方案。

全流程终结时，系统自动汇总各阶段结论形成完整定位报告交付业务方。该机制从根本上解决工具碎片化问题，使业务方从"学习调用工具"转为"直接获取解决方案"，大幅提升复杂场景下的响应效率。

我们以实际落地的编排案例说明运作效果：当线上指标出现异常时，系统自动生成完整分析报告。该报告具备清晰的逻辑分层：

• 第一步向业务方明确展示 Agent 工具的调度策略，详细说明如何选择及调用工具链；
• 第二步串联各 Agent 执行具体分析任务
• 第三步动态监测发现前序步骤未定位到根因时，自动触发新一轮工具编排（例如大模型通过"思考随身念"机制，基于历史数据分析推断"指标波动由变更单引入"）。

所有 Agent 执行完毕后，由总结分析 Agent 整合全流程分析结果。值得注意的是，智能编排过程可能存在误判（如将"变更单引入问题"错误归因，实际应为"发板引入"）。此时系统启动纠错机制：通过自然语言交互修正结论（如将"变更单"手动修正为"发板"），后续步骤立即基于修正结论重新编排工具链生成新结果。

整体而言，本次分享聚焦数据中台如何通过大模型赋能 BI 平台，核心价值在于显著提升业务方"问数"效率、数据分析及洞察效能，我们更期望这些实践能为大家提供建设思路。

以上就是本次分享的内容，谢谢大家。