OpenRCA 2.0：从结果标签到因果过程监督
- 关联论文：2606.27154
- 作者：Tom
- 更新：2026-07-23
一句话结论
LLM Agent 在跨系统根因分析（RCA）中能以 76% 的准确率定位到正确服务，但真正把该服务锚定在经验证因果传播路径上的仅有 61.5%；现有数据集只标注根因、不标传播路径，是这个 gap 的根本原因。
解决什么真问题
SRE 场景中，LLM Agent 被用于自动根因分析——给定一段告警和系统遥测数据，让模型找出哪个组件导致了故障。这是一个综合性测试：需要 Long-Context 理解、多步推理、工具调用。但现有 RCA 数据集存在根本性缺陷——只标注最终根因，不标注从根因到症状的因果传播路径。把这任务大幅简化为「在日志里找关键词匹配」，Agent 只要猜对一个组件名就算对，不管它是否真的知道这个组件是怎么一步步导致故障的。
作者将这个问题称为「ungrounded diagnosis」：Agent 猜对了服务，但说不清楚这个服务是怎么一步步传导到症状的——这是一个危险的幻觉准确率。
核心方法
PAVE（Propagation-based Annotating with Verified Interventions）——一个利用已知故障注入干预来重建因果传播路径的逐步标注协议。核心机制是前向验证（forward verification）：从原因推理到结果，而非从症状反向推断。
具体流程（原文未给伪代码，机制描述如下）： 1. 对目标系统执行故障注入（fault injection），记录每次干预的 effect 2. 利用这些已知的 forward 干预，从根因出发逐步重建因果传播路径 3. 每一步标注该节点的输入、输出和传播条件 4. 最终得到一条带时间戳和因果依赖的传播链
由此构建 OpenRCA 2.0 数据集（500 instances），特点： - 跨系统（cross-system）：涵盖多种服务架构 - 逐步因果标注（step-wise causal annotation）：每步都有验证过的传播关系 - 经验证（verified）：每条路径都来自真实故障注入，非人工臆测
评估 11 个 frontier LLM，采用三级宽松标准： - Level 1（严格）：恢复精确根因集合（exact root-cause set）→ 平均仅 20.7% - Level 2（放松）：至少识别一个正确根因服务 → 76.0% - Level 3（再放松）：识别正确服务并锚定在经验证因果传播路径上 → 61.5%
关键实验与数据
- 数据集规模：500 个 RCA 实例，OpenRCA 2.0
- 测试模型：11 个 frontier LLMs（具体模型名原文未列出）
- 精确根因恢复率：平均 20.7%
- 服务识别率：76.0%（但其中大量属于 ungrounded diagnosis）
- 路径锚定率：61.5%
- 关键洞察：从 Level 2 到 Level 3 的 14.5 个百分点差，揭示了「猜对根因但说不清因果链」这一被 outcome-only 评估隐藏的失败模式
作者在 Reddit 评论中也坦承，模型加 retrieval 加 SOP 约束边界后作为第一响应者是有用的，但最终仍需人类工程师做判断。
亮点与局限
亮点： - 首次提出 RCA 任务中因果传播路径标注缺失这一核心问题，并给出系统化解决方案 PAVE - 三级评估标准揭示了单一 accuracy 指标看不到的隐藏失败模式 - 跨系统设置更接近真实生产环境（与单系统 RCA 数据集不同）
局限： - 数据集规模相对较小（500 instances），覆盖的系统类型原文未明确说明 - 作者标注为「work in progress」，方法可能仍有调整 - 评估的是英文场景，中文/多语言 SRE 环境未知 - PAVE 依赖故障注入，这在已上线的生产环境中未必可操作
对工程落地的启发
- 不要只看根因准确率：上线 LLM RCA Agent 时，应同时追踪「是否给出了因果推理链」，而不是仅看「是否命中了根因关键词」
- Structured Output + SOP 约束：配合检索和结构化操作流程（Structured Operational Procedures）约束搜索空间，是当前提升 Agent 有用性的可行路径，而非盲目上大模型
- 人机协同范式：Agent 做第一轮可疑服务压缩排序，人类工程师做最终判断——这是目前 LLM RCA 的现实定位
- 故障注入是基建：PAVE 的前提是故障注入基础设施；没有这套基建就无法生成可靠的因果标注数据
与同方向工作的关系
- 此前 RCA 数据集（如相关 Microsoft Research 工作）仅关注根因标签，本文是其升级版
- 与 ToolAgent 路线（ReAct、Toolformer）相关，但本文聚焦 SRE 垂直场景的评估
- 与 Agent 评测工作（如 GAIA、AgentBench）不同，OpenRCA 2.0 专门针对 RCA 的因果推理维度
适合谁读
- SRE / Platform 工程师：评估是否在 on-call 流程中引入 LLM Agent
- AI Infra / Agent 评测研究者：了解如何设计多维度评估指标，而非单一 accuracy
- 故障诊断 AI 产品 PM：理解当前 LLM RCA 的真实能力边界，避免过度承诺
原文未明确：PAVE 的具体标注工具/框架名称；11 个测试模型的完整列表；故障注入针对哪些具体系统类型（如微服务、 monolith、serverless）；中文场景适用性。
工程落地与核查（Jay）
1. 事实核查结果
| 核查项 | 结论 | 说明 |
|---|---|---|
arXiv ID 2606.27154 |
✅ 存在 | arXiv 检索已验证，OpenRCA 2.0 论文 |
| 76.0% 服务识别率 | ✅ 与 abstract 一致 | abstract 原文："identify at least one correct root-cause service in 76.0% of cases" |
| 61.5% 路径锚定率 | ✅ 与 abstract 一致 | abstract 原文："ground that service in a verified causal propagation path in only 61.5%" |
| 500 instances | ✅ 与 abstract 一致 | OpenRCA 2.0 (500 instances) confirmed |
| 11 frontier LLMs | ✅ 与 abstract 一致 | "Across 11 frontier LLMs" confirmed |
| 20.7% 精确根因恢复 | ✅ 与 abstract 一致 | "recovering the exact root-cause set succeeds in only 20.7%" confirmed |
| Reddit 评论引用 | ⚠️ 存疑 | abstract 不含 Reddit 内容；该引用未给出具体 Reddit 链接（post ID / 板块），无法独立核验；建议补链接或删去该句 |
2. 工程复现路径
最小可跑评估流程（参考 microsoft/OpenRCA GitHub 的 ICLR'25 基线接口）：
# 1. 准备 CSV 格式的 Agent 预测
# 格式：query_id, predicted_root_cause, confidence
python -m main.evaluate \\
-p rca/archive/agent-predictions.csv \\
-q dataset/test/query.csv \\
-r dataset/test/ground_truth.csv
# 2. 三级评估（需在 OpenRCA 2.0 源码中补充 Level 3 的传播路径匹配逻辑）
# Level 3 = 根因服务匹配 AND 传播路径包含预测节点 →才算✅
PAVE 标注数据生成的关键步骤： 1. 选取目标系统（微服务 / 单体均可），注入单一故障，记录 effect 2. 从故障节点出发，追踪所有受影响的下游节点，构建传播图 3. 对每条边标注「传播条件」（触发阈值、时间延迟、依赖组件） 4. 最终得到有向传播链而非单一根因标签
⚠️ 存疑：原文未提供 PAVE 的开源标注工具或代码；目前 microsoft/OpenRCA GitHub 仓库对应 ICLR'25 版本（335 failures），不包含 OpenRCA 2.0 的 PAVE 500-instances 数据集；复现 OpenRCA 2.0 需联系作者获取数据。
3. 已知坑位清单
| 坑 | 描述 | 规避方案 |
|---|---|---|
| Level 1 准确率仅 20.7% | 精确根因集合恢复率极低；生产中若仅用单一指标会高估 Agent 能力 | 同时追踪 Level 2 和 Level 3，尤其关注两者之间的 gap |
| GitHub 仓库为旧版 | microsoft/OpenRCA = ICLR'25 v1，数据集为 335 failures；OpenRCA 2.0 数据集（500）未公开 | 评估前确认数据集版本；需邮件联系作者获取 v2 数据 |
| Reddit 引用无法溯源 | 无具体链接，存 AI 幻觉风险 | 引用时补 post URL；无链接则改为"作者在公开评论中指出"并加 ⚠️ |
| 跨系统泛化未验证 | 11 个 frontier 模型均在 OpenRCA 2.0 上测；跨数据集（如换银行/电信以外系统）表现未知 | 生产部署前须在自己系统上做 transfer 评估 |
| PAVE 故障注入在生产不可操作 | 依赖 fault injection，已上线系统不能随便注入 | 用 staging 环境或历史故障日志重建传播路径；生产仅用于离线评估 |
| 中文化 / 多语言 SRE 未覆盖 | 数据和模型均为英文 | 中文告警场景需独立评估；语言差异可能导致跨模态理解进一步掉点 |
4. 核查清单
- [x] arXiv ID：2606.27154 存在于 arXiv，摘要数字已与原文 abstract 逐条核对 ✓
- [x] 数字一致性：76.0% / 61.5% / 20.7% / 500 instances / 11 frontier LLMs 均与 abstract 原文吻合 ✓
- [x] GitHub repo 区分：microsoft/OpenRCA 为 ICLR'25 v1（335 failures），OpenRCA 2.0（500 instances）数据需联系作者 ✓
- [ ] Reddit 引用：未提供 post URL，需补链接或删除该句（⚠️标注）
- [ ] PAVE 工具/代码：原文未开源标注工具，生产复现需联系作者