突破泛化瓶颈：阿里云智能运维 Agent 评测体系实践

如果无法正常显示，请先停止浏览器的去广告插件。

相关话题： #AI Agent

1. 突破泛化瓶颈：阿里云智能运维 Agent 评测体系实践李也

2. 目录 01 智能运维泛化之痛 02 高质量的评测集的重要性 03 如何构建高质量的评测集 04 阿里云智能运维评测集(持续发布) 05 基于评测集的智能运维 Agent 能力提升实践

4. 01 智能运维泛化之痛

5. 智能运维的一些技术这些技术都有难泛化的问题大模型智能运维Agent context engineering + 大模型 workflow 规则+算法的智能运维基于规则的智能运维

6. 传统的基于规则的智能运维难泛化为CPU/内存/磁盘/响应时间等指标设置固定上/下限，超限即告警泛化瓶颈： ➢ 环境变化: 如大促 ➢ 跨系统迁移差：不同应用/硬件固定阈值的时序告警用正则模板提取日志字段，基于关键字或模板频次设置规则用“if-then”把事件聚合, 如“网络断+下游告警→归为网络故障” 泛化瓶颈： ➢ 模板脆弱：日志格式/字段轻微变更就失效 ➢ 难捕获未知错误泛化瓶颈： ➢ 系统变化会使规则失效 ➢ 组合爆炸：要处理各种事件的组合，规则数量会激增关键词/正则匹配的日志告警基于If- else 规则的事件关联

7. 规则+ 算法的智能运维难泛化算法自动挖掘出if-then规则。随机游走/matrix-forest归因用STL分解/n-sigma/ESD-test 等算法设置智能基线，超限告警用spell/drain等算法挖掘出日志模板。对模板和变量的模式做告警泛化瓶颈： ➢ 参数难设置：如敏感度，周期长度等泛化瓶颈： ➢ 过度挖掘或者挖掘不充分 ➢ 系统变化，概念漂移 ➢ 过滤不充分: 无关日志造成误报泛化瓶颈： ➢ 规则挖掘依赖手动标注数据 ➢ 数学模型的假设不一定成立 ➢ 可观测数据不完整/有噪音基线/季节性建模的时序告警基于日志模板挖掘的日志告警规则挖掘, 随机游走等算法归因

8. 大模型 workflow 会遇到泛化瓶颈 ➢ 数据幻觉: 编造不存在的“500” ➢ 因果幻觉: 见GC增多就断言“内存泄漏”, 忽略了Java版本变化 ➢ 工具幻觉: 伪造API或者参数模型幻觉 workflow的限定容易过强 ➢ 从指标触发的 workflow，难泛化到日志报错的场景 ➢ 3层的workflow难处理超过3 步的根因推理 ➢ workflow分支过多时，节点数爆炸相比于确定编码的规则，大模型的输出可能会不遵从预期 ➢ prompt说“只做只读分析”，模型也有可能执行危险命令（如直接重启集群、删库清表） ➢ 顶尖的模型在超过200个指令之后，也难全遵从[1] Workflow 编排的局限性不遵从提示词 [1] How Many Instructions Can LLMs Follow at Once? Daniel Jaroslawicz et. al.

9. 大模型 Agent 也有一些泛化问题 Demo 相对容易：接入开源的脚手架，准备好prompt 和tools ，就能在特定场景完成demo 大模型Agent继承了大模型 workflow里面的很多缺点 ➢ 数据/因果/工具幻觉 ➢ 不遵从提示词还新增了更多执行流程上的缺点 ➢ JSON、SQL等易出现格式和类型错，影响自动化 ➢ 难以停止，重复探索大模型能力局限 ➢ ➢ ➢ ➢ 工具不全工具太多工具作用重叠工具描述不清工具不成体系 “按下葫芦起了瓢” ➢ 强调“仅基于证据回答”，模型过度保守，提早终止 ➢ 强调“尽量只用内部知识库” 时，模型不做合理泛化 ➢ 强调“严格特定schema 格式”，模型为过度满足schema 而填充mock值调prompt 没有掌控感

10. 02 高质量的评测集的重要性

11. 各个领域的评测集(benchmark) 推动了大模型在这些领域的进步 https://ysymyth.github.io/The-Second-Half/

12. 如果我们用一个案例的Demo 做评测例子: 我们想要做一个下面场景的的智能运维的 Demo 现象是出现了很多慢SQL ，原因是有一次代码变更使用了长连接，把数据库的线程池打满了。我们要把“代码变更”这个原因找到规则规则＋算法大模型workflow 大模型Agent “超过1s的是慢SQL”， “ active_session 数量超过CPU 核数两倍则认为是打满” “同时发生代码变更+ 线程池打满+慢SQL 时认为代码变更是原因” “将 SQL 的执行时间用STL 分解后，残差超过均值+3 倍标准差是慢SQL ”，… , “在因果图里面计算出代码变更是根因的概率” “先调用工具对感兴趣的指标和日志做一遍巡检” → “对于有异常的现象用大模型进行总结并输出”→ “将上面对根因的判断的规则写到 prompt 里面然后做根因定位” “慢 SQL 检测工具+线程池检测工具+ 代码变更识别工具”，“案例 retrieval 知识库”，然后把大模型workflow 里面硬编码的流程写到prompt 里面我们可以想象，用各种方法我们都能在上面的案例上做一个成功的demo。但是可能难泛化到其他场景

13. 如果有一个更丰富benchmark 把前面提到过的例子都作为benchmark 的任务，去评测上面各种方法的Demo 方法\任务变更导致的数据库连接池打满受季节变化和大促影响的CPU使用率异常检测 Java版本变化导致网络断+下游的GC次数上涨多告警 … [Demo] 规则 [Demo] 规则 +算法 [Demo] 大模型workflow [Demo] 大模型agent 上面的表示有一定的概率可以做对特定流量造成的报错量上涨

14. “高质量”的 benchmark 能帮我们发现AIOps 方法的局限性我们会在下一节讨论什么是“高质量”。我们先把“高质量”理解成覆盖我们常见的方方面面问题的案例集，而且还附有标准答案和评判标准一个可能的“高质量”的benchmark 案例标准答案变更导致的数据受季节和大促影响的 Java版本变化导网络断+下游库连接池打满 CPU使用率异常检测致的GC次数上涨多处告警代码变更有异常/无异常 Java版本升级 A→B 网络断开 … … … … … … 可观测数据系统在正常和异常时间段的所有logging/tracing/metrics/events数据，至少够人类专家找到答案 ➢ 发现方法的局限性 ➢ 排除不可行的方法 ➢ 提前暴露问题

15. “高质量”的评测集能帮我们优化 AIOps 方法规则不断堆规则，直到能覆盖90% 以上的benchmark 里面的问题规则＋算法根据benchmark 的结果，修改算法参数。根据benchmark ，自动挖掘规则大模型workflow 根据benchmark 的结果调整workflow 的结构和prompts ，减少bad case 大模型Agent 设计更巧妙的脚手架 + 开发更多好用的工具 + 优化prompts 使用标注数据去做监督微调/强化微调/Agentic强化学习

16. benchmark 促进循环迭代开源将能共享的benchmark 数据都尽量共享，借助社区的力量开发开发的时候可以用benchmark 中的少量案例来验证代码是否可以运行上线 + 积累更多案例正向循环上线后会产生用户真实的反馈。这些反馈能帮我们积累更多案例，又可以加入到benchmark 中形成循环评估初步开发完之后，我们可以在全量 benchmark 上评估算法的效果调优对于bad cases ，我们可以拿出来分析然后有针对性地调优算法

17. 03 如何构建高质量的评测集

18. 我们对软件系统执行要素的抽象以及对应的注入点软软软软软软软软软软软软软软软软软软软软软软软软软软软软软软 /软软软软软系统请求 workload 系统处理的请求明细及其处理时间，代表了系统的输入对应注入点: 整体流量突增/突降，特定入参的请求突增等系统资源 resources 代码/config 例如 CPU/内存/线程池等软件/程序及其配置。包括了代码的版本等对应注入点: 内存不足、CPU不足、线程池打满等对应注入点: 代码变更、特定输入触发的bug、参数欠佳等对输出的期望 (specification) 这部分对应的是注入的故障造成的影响，没有注入点系统历史状态数据库/缓存/消息队列的历史状态，内存快照等对应注入点: 复制延迟、redis大 key、DB统计信息过期等

19. 例子例子: 我们想要做一个下面场景的的智能运维的 Demo 现象是出现了很多慢SQL，原因是有一次代码变更使用了长连接，把数据库的线程池打满了。我们要把“代码变更”这个原因找到系统请求 workload 系统请求无异常现象系统资源 resources 代码/config “数据库线程池打满” “有代码变更” 系统历史状态系统历史状态无异常现象对输出的期望 (violation of specification) “出现了很多慢 SQL ” ➢ 对每个案例, 我们都能按照这样的方式将可观测数据和前因后果组织起来，形成很多根因/现象/结果等类型节点 ➢ 如果我们的benchmark 覆盖了任何一个工单中出现过的根因/现象/结果，那么我们就说覆盖度是100%

20. 高质量benchmark 的几个要点覆盖度是指要尽量各种类型的原因/现象/影响真实度是要让系统产生的可观测数据尽可能接近真实真实度覆盖度覆盖根因覆盖我们能想到的和系统各个要素相关的根因：如“流量暴涨”，“ CPU 利用率太高”，“内存打满”等覆盖传播链条系统架构真实需要产生可观测数据的系统架构接近真实的架构，包括了真实的组件等流量真实覆盖我们能想到的影响传播链路：如“流量暴涨” → “数据库CPU 打满” →“请求延迟高” 如“ 网网网网网网 ”→“控制平面队列积压” →“网络丢包增多” 需要能模拟真实用户的流量覆盖结果各组件的可观测数据真实覆盖我们能想到的最终影响的结果，包括“请求延迟高” /“报错数增多”等日志要像真实的日志，时序要像真实的时序。真实的可观测数据在正常时段会有噪音，在异常时段会有同时出现的unknowns

21. 案例来源基于生产环境中真实发生的故障样本进行归纳与复盘 - 真实可观测数据的快照 - 专家标注真实故障收集用混沌工程工具以及模拟workload 在开源真实系统 (如otel- demo) 中触发典型故障 - 实采的可观测数据 - 注入故障作为标注开源系统故障注入在与生产相近的预发/演练环境中注入故障 - 实采的可观测数据 - 注入故障作为标注演练环境故障注入用混沌工程工具以及模拟workload 在mock了函数输入输出的真实运行系统中触发典型故障 - 实采的可观测数据 - 注入故障作为标注模拟系统故障注入

22. 不同来源的案例在几个维度上的区别注入方式真实 case 收集开源系统故障注入演练环境故障注入模拟系统故障注入（Mock/仿真）覆盖度真实度可公开 (容易缺可观测数据/标注) (需要投入大量的时间精力) (开源系统的架构和生产有区别) (需要投入大量的时间精力) (workload难复现) (模拟的成本低，易覆盖) (workload难复现) (包含了真实的组件)

23. 统一模型（UModel ）

24. 从理论角度提升覆盖度方法论：统一模型umodel 下等价例子: 我们想要做一个下面场景的的智能运维的 Demo 现象是出现了很多慢SQL，原因是有一次代码变更使用了长连接，把数据库的线程池打满了。我们要把“代码变更”这个原因找到系统请求 workload apm.metric.apm.external.http_client 等指标无异常代码/config k8s.pod_restart_count > 0 提示可能有重新部署系统资源 resources AliyunRds_MySQL_ActiveSessions异常对输出的期望 (specification) AliyunRds_MySQL_SlowLogSize异常用umodel 来表达案例的前因后果 ➢ 等价性: 任何案例都可以用 umodel 来表达前因后果关系。如果两个案例用umodel 写出来形式一致，那么我们说这他们在umodel 下是等价的 ➢ 完备性：如果我们能想到的所有案例都能在benchmark 中找到某个案例在umodel 下等价。那么我们说 benchmark 在umodel 下是完备的 ➢ 必要性: umodel里面所有的实体类型和指标集合都必须要出现在 benchmark 中的某个案例里面

25. 04 阿里云AIOps 评测集(持续发布)

26. 阿里云AIOps 评测集的构建实施注入/ 案例收集故障注入系统/规划可观测数据采集+存储+ 查询分析接入系统已注入2000+ cases chaosblade chaosmesh 经验证已收集 500+ cases 系统请求 workload 类阿里云云监控2.0 OpenTelemetry demo 开源系统阿里云内部演练环境系统资源 resource 类持续收集中代码/config 类系统历史状态类阿里云日志存储 SLS/ 指标存储 SLS MetricStore 真实生产系统模拟系统 …

27. 可以和其他benchmark 互补使用，如OpenRCA 实施注入/ 案例收集故障注入系统/规划 335 cases chaosblade 可观测数据采集+存储+ 查询分析接入系统 chaosmesh 系统请求 workload 类 csv files, 68GB Telecom database 用SQL/SPL Bank system OpenRCA 系统资源 resource 类 Market system 的数据简介代码/config 类查询，开箱即用的可视化系统历史状态类

28. 第一批评测集发布第一批评测集随AI原生编程挑战赛一同发布所有人可以通过自己的阿里云账号去云监控2.0 / SLS里面查询数据后续会陆续开源新的评测集，欢迎关注“阿里云云原生”公众号 [2] https://tianchi.aliyun.com/specials/promotion/2025aicloudnativecompetition

29. 05 基于评测集的智能运维 Agent 能力提升实践

30. “高质量”的评测集能帮我们优化 AIOps 方法 – 回顾规则不断堆规则，直到能覆盖90% 以上的benchmark 里面的问题规则＋算法根据benchmark ，修改算法参数。根据benchmark ，自动挖掘规则大模型workflow 根据benchmark 的结果调整workflow 的结构和prompts ，减少bad case 大模型Agent 设计更巧妙的脚手架 + 开发更多好用的工具 + 优化prompts 使用标注数据去做监督微调/强化微调/Agentic强化学习

31. 一些根据benchmark 调优的结果规则纯规则的方案就暂不调优了规则＋算法 3000+ 样本自动挖掘规则的算法达到了 100% 准确率和 99.27% 的召回率大模型workflow 2000+ 样本正则表达式生成的benchmark 。生成的正则表达式中98.48% 的能匹配文本，95.6% 的正则可以完美解析80% 以上的字段大模型Agent 精调过的脚手架 + 工具在第一批评测集上达到了87.5% 的根因召回率经过监督微调/强化微调的模型在RCA 根因排序任务上达到了82.0% 的准确率

32.

33. THANKS 大模型正在重新定义软件 Large Language Model Is Redefining The Software