ORCA-bench: How Ready Are Language Model Agents for Oncall?
一句话概括
ORCA-bench 是面向值班（Oncall）根因分析的高保真基准。它检验通用编码智能体能否在真实微服务系统中定位故障根因。
速览
- 任务与方法：智能体在 OpenTelemetry 插桩的微服务系统上做根因分析（RCA）。它需经 Prometheus、Jaeger、OpenSearch（经 Grafana）查询遥测数据，并可访问全部源码。
- 关键数字：最佳 RCA 准确率在 Medium 难度为 25.3%，Hard 难度为 10.0%。最弱模型在 40% 的 incident 报告中幻觉出不合理的根因。LLM-as-judge 与人类复核的加权 Cohen's κ 为 0.90。
- 数据规模：测试床运行六天，产生约 50GB 指标、日志与追踪数据，共 1,079 个 RCA 任务。
- 开源情况：公开数据集发布于 https://hub.harborframework.com/datasets/orca-bench/ORCA-bench。
问题背景
大语言模型已能写代码、修补丁、搜代码。但值班根因分析是另一类任务。
- Oncall 工程师面对的是噪声信号。凌晨收到含糊投诉「支付变慢了」，需在几分钟内判断原因。可能是连接池耗尽，可能是内存泄漏，也可能是上游依赖抖动。
- 这要求在时间压力下跨指标、日志、追踪与源码做多跳推理。它不是写一段代码。
- 现有编码基准（如 SWE-bench）通常给出明确 issue 与代码仓库。任务边界清晰。生产环境的 incident 报告往往模糊、不完整，故障还可能由多因素叠加。
- ORCA-bench 的动机正是填补这一空白。它要回答：通用编码智能体在多大程度上能胜任真实生产环境的 oncall 工作。
方法要点
设计分三层。
- 真实系统与真实遥测。构建 OpenTelemetry 插桩的微服务系统，运行六天，产生约 50GB 指标、日志与追踪数据。数据经真实接口暴露：Prometheus 存指标，Jaeger 存追踪，OpenSearch（经 Grafana）存日志。智能体需像人类工程师一样查询工具，而非读打包好的 JSON。系统源码完全开放。
- 任务设计的系统化变化。1,079 个 RCA 任务在三个维度上变化：报告具体程度、故障检测延迟、共现故障场景。任务按难度分为 Medium（现实输入设定）与 Hard（更模糊、更延迟、更多共现故障）。
- 评估的严谨性。每个任务的 ground-truth 症状由专家 SRE 人工整理并签字确认。LLM-as-judge 评分由人类独立复核，加权 Cohen's κ 达 0.90。评估指标为 RCA Accuracy，即能否在合理时间内定位正确的根因组件与症状。
关键结论
- 五个前沿智能体（包括 Claude Fable 5 等）在 Medium 难度任务上的最佳 RCA 准确率为 25.3%。Hard 难度仅 10.0%。即使最强模型，在真实输入设定下也有约四分之三的任务无法正确定位根因。
- 最弱模型在 40% 的 incident 报告中幻觉出不合理的根因。这不是「没找到」，而是「编造了看似合理但实际错误的原因」。这对生产环境危险。
- 移除源码访问权限后，所有指标都下降。这说明源码阅读是 RCA 的关键能力。但「能读代码」不等于「会做根因分析」。
- 作者强调，这些数字来自精心策划的测试床。其代码与插桩公开，任务隔离研究。真实生产系统大几个数量级、更动态、更特化。因此该性能差距是「下界」，实际部署所需工程投入只会更大。
读后思考
ORCA-bench 把智能体能力评估从代码仓库拉到了可观测性工作台。其适用场景明确：
- 智能体研发的靶场。它为开发 oncall 助手提供可复现、有专家标注的测试环境。它能精确衡量加一个工具调用、改进提示词、引入记忆机制带来的增益。
- 能力边界研究。25.3% 的准确率说明当前模型在「多源异构信号融合推理」上存在系统性短板。研究社区的方向不是继续堆代码能力，而是发展「在噪声中做假设生成与验证」的推理框架。
- 工程风险评估。对平台团队而言，这是量化标尺。把智能体接入生产告警链路前，先看它在 ORCA-bench 上的表现，可避免「上线即翻车」。
一个值得注意的细节：难度从 Medium 到 Hard 的准确率断崖（25.3% → 10.0%）。这说明当报告更模糊、延迟更长、故障更复杂时，智能体推理能力衰减极快。短期内智能体更适合做「辅助排查」而非「独立值班」。它可快速缩小范围、生成假设，但最终决策仍需人类把关。
局限与开放问题
摘要明确提到的局限是：测试床是「策划的、公开的、隔离的」，与真实生产环境有数量级差距。以下问题摘要未直接讨论，但值得追问：
- RCA Accuracy 的定义粒度。摘要未给出「正确」的判定标准。是定位到具体服务、具体代码行，还是具体故障类型？不同粒度难度差异很大，会影响对 25.3% 的解读。
- 时间维度的评估。Oncall 的核心约束是「快」，但摘要未提及智能体的平均排查耗时。30 分钟答对与 5 分钟答对，即使准确率相同，实际价值也不同。
- 任务隔离的简化。真实 oncall 中工程师常同时处理多个 incident，系统状态动态变化。任务「隔离研究」意味着智能体无需处理「排查过程中故障仍在演化」的挑战。
- 幻觉的深层机制。40% 的幻觉率值得警惕，但摘要未分析幻觉集中在哪类任务。是报告太模糊？还是遥测数据本身有歧义？理解幻觉触发条件，可能比单纯提升准确率更有价值。
总体而言，ORCA-bench 设计严谨、执行扎实。它用数据说明：当前前沿智能体离「安全值班」还有很长的路。这个「下界」不是坏消息，而是一张清晰的路线图。