ORCA-benchが6日間のテレメトリ現場を再現、最先端エージェントの中難度根本原因分析は最高でも25.3%

新たに公開されたORCA-benchは、エージェント評価を「すでに場所が特定されたコード上のバグを修正する」段階から、オンコールエンジニアの業務により近い根本原因分析（RCA）へと進めた。テスト環境は、継続稼働し、OpenTelemetryで計装されたマイクロサービスシステムだ。エージェントはGrafanaを介してPrometheusメトリクス、Jaeger traces、OpenSearch logsを利用でき、完全なソースコードも確認できる。データは6日間、約50 GBに及び、合計1,079件の根本原因分析タスクが作成された。インシデント報告の具体性、検知遅延、同時発生する障害の数は意図的に変えられている。

結果は、コードを書けることが、インシデントを確実に処理できることを意味しないと示している。5つの最先端エージェントのうち、最良のエージェントでも、より現実的な報告を想定したMediumグループでのRCA Accuracyは25.3%にとどまり、Hardグループでは10.0%まで低下した。最も性能の低いモデルは、インシデント報告の40%で妥当性のない根本原因を捏造した。ソースコードへのアクセスを除外すると、すべての評価指標が悪化した。これは、テレメトリ検索だけでは、実行時の現象から実装を遡って調査する能力を依然として代替できないことを示している。

研究では、SREが症状のground truthを人手で確認し、LLM judgeによる判定結果も人手で再評価した。報告された重み付きCohen’s κは0.90であり、単純な自動判定だけに頼る評価よりも信頼性が高い。ただし、各インシデントは依然として隔離された状態で調査されており、システム規模も実際の本番環境よりはるかに小さい。そのため、25.3%という数字はデプロイの基準ではなく、楽観的な上限である可能性が高い。

プラットフォームチームにとって、次の一手は単により大規模なモデルへ切り替えることではない。エージェントがタイムラインを構築し、metrics、logs、traces、バージョン変更を相互照合できるか、また証拠が不十分な場合に結論を出すのを止められるかを検証すべきだ。あらゆる自動修復フローでも、根本原因の仮説、クエリ履歴、変更承認を分離し、精度の低い診断が本番環境での操作を直接トリガーしないようにする必要がある。