> [!abstract] 概要(abstract の日本語訳) > 根本原因分析(RCA)は、インシデント管理プロセスの重要な一部であり、オンコールエンジニア(OCE)にとって負荷の大きいタスクである。深いドメイン知識と、チームの特定のサービスに関する豊富な経験が要求される。RCA の自動化は、時間の大幅な節約をもたらし、OCE のインシデント管理の負担を軽減しうる。近年、研究者は大規模言語モデル(LLM)を用いて RCA を実行し、有望な結果を示してきた。しかしこれらの手法は、インシデント関連のログ、メトリクス、データベースといった追加の診断情報を動的に収集することができず、根本原因を診断する能力を著しく制限している。本研究では、この限界に対処するため、RCA 向け LLM ベースエージェントの利用を探究する。我々は、Microsoft で収集された本番インシデントの分布外データセットに対し、リトリーバルツールを備えた ReAct エージェントの徹底的な実証評価を提示する。結果は、ReAct が強力なリトリーバルおよび推論ベースラインと競合的な性能を発揮しつつ、事実的正確性を大幅に高めることを示す。さらに我々は、Microsoft のあるチームと共同でケーススタディを実施し、ReAct エージェントが手動 RCA に使われる診断サービスとインタフェースできるようにした。我々の結果は、エージェントが先行研究の限界をどのように克服できるかを示すとともに、そのようなシステムを実運用で実装する際の考慮事項を提示する。 ## 論文情報 - タイトル: Exploring LLM-Based Agents for Root Cause Analysis - 著者: [[Devjeet Roy]]([[Washington State University]]、Microsoft でのインターンシップ期間中の研究)、[[Xuchao Zhang]]、[[Rashi Bhave]]、[[Chetan Bansal]]、[[Pedro Las-Casas]]、[[Rodrigo Fonseca]]、[[Saravan Rajmohan]](いずれも [[Microsoft]]) - 媒体: Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering(FSE Companion '24)、2024-07-15〜2024-07-19、Porto de Galinhas, Brazil - DOI: https://doi.org/10.1145/3663529.3663841 - 受理: 2024-02-08 投稿、2024-04-18 受理 - 原本: [[.raw/papers/2026_Unknown_Exploring_LLM_Agents_Root_Cause.pdf]] ## 概要 本論文は、クラウドインシデント管理における根本原因分析(RCA)に対して、ReAct フレームワーク([[@2023__ICLR__ReAct Synergizing Reasoning and Acting in Language Models]])に基づく LLM エージェントを適用した初の実証研究である。ファインチューニングや few-shot 例を使わないゼロショット設定で、ReAct エージェントを一般化されたリトリーバルツールとインシデント記述 QA ツールのみで動かす評価(RQ1・RQ2)と、Microsoft の Azure Fundamental Team と 4 週間協働し、チーム固有のデータベースクエリツール・KBA(Knowledge Base Article)Q/A ツール・人間介在ツールを装備した実運用ケーススタディ(RQ3)の 2 段構成をとる。ReAct は自動評価指標(BLEU・METEOR・ROUGE・BERTScore)ではベースラインと同等かやや劣るが、人手による定性評価ではハルシネーション率が最も低い。ケーススタディでは、KBA へのアクセスが単純なインシデントの自律解決を可能にする一方、複数 KBA にまたがる複雑なインシデントでは反復試行の仕組みが必要になることを示す。(Source: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]]) ## 問題設定 先行研究([[@2023__ICSE__Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models]](Ahmed+)、[[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]] の前身にあたる Chen+ の RCACopilot)は、LLM に動的に診断情報を収集させる能力を欠いていた。Ahmed+ はインシデントのタイトルと説明のみに依拠し、RCACopilot は事前定義ハンドラで多様な診断データを収集するが手作業のエンジニアリングを要し、根本原因カテゴリしか予測しない。本論文は、推論・計画・外部環境との相互作用によって新しい情報を収集できる LLM ベースエージェントを用いてこの限界に対処する。2 つのリサーチクエスチョンを設定する: (1) ファインチューニングなしで LLM エージェントは RCA に有効か、(2) LLM エージェントの実運用適用における実践的考慮事項は何か。入力はインシデントのタイトルと説明(RQ1・RQ2)、または実際のチーム固有診断サービス(RQ3)であり、出力は特定の根本原因である。(Source: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] §1, §2.3) ## 提案手法 - **アーキテクチャ**: [[LangChain]] で実装された [[ReAct]] エージェント(本論文では ReAct 実行ループを担う LLM を「planner」と呼ぶ)。Thought(推論)→Action(ツール呼び出し)→Observation(結果)の三つ組を反復し、最大 20 イテレーションで打ち切る。ゼロショットプロンプトを用いる(few-shot 例のトラジェクトリ作成が RQ1・RQ2 の設定では困難だったため)。(Source: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] §3.1, §3.2) - **RQ1・RQ2 で使うツール**: - **Incident Details ツール**: インシデント記述に含まれる生ログ・スタックトレースを要約せず QA 形式で参照可能にする。 - **Historical Incidents ツール**: 履歴インシデントをリトリーバルするツールで 2 種の変種がある。**ReAct BR** はエージェントのクエリで検索した文書をそのまま観測として返す(SentenceTransformer リトリーバのみ使用)。**ReAct S+Q** はまず履歴インシデントを検索し、別の LLM がプランナーのクエリに回答する 2 段構成で、リトリーバル文書のサイズが LLM のコンテキスト長を超える問題を緩和する。検索は $k=3$ 件/クエリ、合計予算 10 件に制限し他ベースラインと公平性を保つ。(Source: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] §3.4) - **RQ3 で使うチーム固有ツール(ケーススタディ)**: - **Database Query Tool**: Query Execution Engine(クラスタ固有のカスタムクエリ言語でデータベースへ問い合わせ)と Pandas DataFrame Query Engine(返された結果を Pandas DataFrame に変換し、Python インタプリタで変換・自然言語 QA を行う LLM)の 2 コンポーネントで構成。 - **KBA Q/A Tool**: 14 件の KBA(Knowledge Base Article)をベクトルストア化し、エージェントのクエリに応じてチャンクから回答する。インシデントに紐づく KBA が既知の場合はベクトルストアを介さず直接そのKBAを使う。 - **KBA Planning Tool**: KBA Q/A ツールと構造は同一だが、行動空間に明示的に導入することで、ReAct の thought-action の性急なインターリーブが高レベルプランニングを損なう問題(予備実験で観察)を緩和し、詳細な診断行動の前に高レベルプランを構築するよう促す。 - **Human Interaction Tool**: エラー再現やデバイスへの手動ログインなどエージェントには実行不能なステップについて、OCE から診断情報を取得・提供するためのツール。UI 上でもエージェントのアクションステップへの介入・ツール実行の手動検証・明示的フィードバックを可能にする。(Source: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] §7.3) - **実装上の工夫**: ツール実行時のエラーメッセージを observation としてそのままエージェントへフィードバックすることで、データベースクエリの初回失敗をエージェントが自律的に修正できるようにした。(Source: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] §7.4.2, §7.5) **Figure 2: ReAct のサンプル推論トラジェクトリ** ![[_attachments/2026_Unknown_Exploring_LLM_Agents_Root_Cause/fig02-react-trajectory-example.png]] (Figure 2. RCA Agent の推論トラジェクトリ例。Thought で情報不足を認識し `incident_details` ツールを Action として呼び出し、Observation でシナリオ・テストの失敗内容を取得、最終的に Final Answer として特定タスク・特定ビルドの根本原因を推定する構造を示す。) ## 新規性 Ahmed+ が few-shot・ファインチューニングされた LLM をインシデントのタイトル・説明のみで動かすのに対し、また RCACopilot が事前定義ハンドラで診断データを収集し根本原因**カテゴリ**を予測するのに対し、本論文の ReAct エージェントは事前定義ハンドラなしに関連診断データを動的に自律収集できる。これは OCE が実際の RCA で最初に行う「新規診断データの収集」というステップを LLM ベースの手法として初めて明示的に扱ったものである。(Source: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] §1, §2.3) ## 実験設定 - **データセット**: Microsoft の社内インシデントポータルから 2020-01-01〜2021-09-30 に収集した 107,000 件のユニークなインシデントを学習(102,000)・評価(2,000)・テスト(3,000)に分割。コスト削減のため評価セットから 100 件、テストセットから 500 件をランダムサンプリング。学習セットはリトリーバルコーパスとして使用。RQ2 では discussion comments もコーパスに加える。 - **要約**: インシデント説明・根本原因・discussion comments は長さがまちまちなため gpt-3.5-turbo で要約(discussion comments はチャンク分割して個別要約後に再結合)。 - **ベース LLM**: プランナーには OpenAI GPT-4-8k(コンテキスト長 8,000 トークンでより多くの履歴インシデントを扱える)。要約には gpt-3.5-turbo(コスト削減)。 - **リトリーバ**: 密なリトリーバとして Sentence-BERT ベースの all-mpnet-base-v2 + MMR(Max Marginal Relevance)を用いる Dense Retriever(ST)、疎なリトリーバとして BM-25。 - **比較対象**: Retrieval Baseline(RB, $k$=3/6/10)、Chain of Thought(CoT、ゼロショット "Let's think step by step")、Interleaving Retrieval-CoT(IR-CoT、ST・BM25 の 2 変種)。いずれもファインチューニングを要さない ALM。 - **評価指標**: 語彙的類似度として C-BLEU・S-BLEU・METEOR・rougeL、意味的類似度として BERTScore(BertS)。加えて 3 モデル×100 件・計 300 件の人手アノテーションによる定性評価を実施(2 名のアノテーターが反復的にラベル付けし議論で不一致を解消)。ラベル体系は Yao+([[@2023__ICLR__ReAct Synergizing Reasoning and Acting in Language Models]])のカテゴリを拡張し、Correct(Precise / Imprecise / Hallucination)と Incorrect(Hallucination / Insufficient Evidence / Other)に分類。(Source: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] §5) ## 実験結果 ### RQ1: 自動評価(テストセット、Table 2) | Model | C-BLEU | S-BLEU | rougeL | METEOR | BertS | |---|---|---|---|---|---| | RB (k=3) | 4.73 | 4.64 | 18.48 | 21.62 | 0.863 | | RB (k=6) | 5.66 | 5.56 | 19.78 | 23.25 | 0.865 | | RB (k=10) | 5.97 | 5.74 | 20.30 | 24.11 | 0.866 | | CoT | 6.31 | 5.60 | 19.91 | 22.02 | 0.865 | | IR-CoT ST | 3.91 | 3.67 | 16.97 | 18.50 | 0.859 | | IR-CoT BM25 | 4.61 | 4.02 | 17.56 | 19.94 | 0.860 | | ReAct BR | 5.53 | 4.90 | 17.45 | 19.23 | 0.858 | | ReAct S+Q BM25 | 5.59 | 4.73 | 17.43 | 18.72 | 0.857 | | ReAct S+Q ST | 5.27 | 4.58 | 17.35 | 18.60 | 0.857 | (Table 2. RCA performance on test set。CoT が C-BLEU で最高 (6.31)、意味的類似度(BertS)では全モデルが 1 ポイント未満の幅に収まる。) ReAct 変種は平均 4 件の重複しない履歴インシデントを検索し、平均 2 回のルックアップを行うが、historical_incidents ツールはステートレスで既取得文書を考慮しないため一部重複が生じる。 ### RQ1: 定性評価(Table 3) | Type | RB (k=10) | CoT | ReAct-BM25 | |---|---|---|---| | Correct: Imprecise | 2 | 7 | 5 | | Correct: Hallucination | 10 | 1 | - | | Correct: Precise | 26 | 30 | 29 | | Correct: All | 38 | 38 | 34 | | Incorrect: Hallucination | 29 | 11 | 4 | | Incorrect: Insufficient Evidence | 11 | 19 | 39 | | Incorrect: Other | 19 | 27 | 8 | | Incorrect: Reasoning Error | - | 2 | 10 | | Incorrect: Retrieval Error | - | - | 2 | | Incorrect: All | 59 | 59 | 63 | (Table 3. Manual Labelling of Success and Failure Cases。RB (k=10) の正解の 26%(10/38)がハルシネーションを含み、不正解の 49%(29/59)がハルシネーション。CoT は不正解の 18%(11/59)。ReAct はハルシネーションが正解 0%・不正解 6%(4/63)と最低で、97/97 件中 28 件は 3 モデル共通正解、ReAct のみが正解する 4 件は「歴史的に語彙的に類似するが意味的に異なるインシデントを推論ステップで正しく除外できた」ケース。全体精度は RB (k=10)・CoT が 39%、ReAct S+Q BM25 が 35%とやや低い。) ### RQ2: discussion comments の効果(Table 4) | Model | C-BLEU | S-BLEU | rougeL | METEOR | BertS | |---|---|---|---|---|---| | RB (k=10) | 6.65 ↑ | 6.01 ↑ | 20.8 ↑ | 23.81 ↓ | 0.867 | | CoT | 6.18 ↓ | 5.21 ↓ | 18.8 ↓ | 21.32 ↓ | 0.861 | | ReAct BR | 5.44 ↓ | 4.91(差なし) | 17.8 ↑ | 20.04 ↑ | 0.854 | | ReAct S+Q BM25 | 5.52(差なし) | 4.68(差なし) | 17.4(差なし) | 18.96 ↑ | 0.858 | (Table 4. discussion comments を履歴コーパスに加えた後のテストセット結果。RB (k=10) は語彙的指標が改善するが METEOR はわずかに低下。CoT は全語彙指標で悪化。ReAct 両変種はおおむね改善方向。ただしいずれも差は ≤1 ポイントで、人間の知覚には現れにくい水準(Tangled up in BLEU(arXiv 2020、未 ingest) 等の指摘に整合)。意味的指標には明確な影響なし。) ### RQ3: ケーススタディ(定性) シンプルなインシデント(単一 KBA・分岐の少ない診断手順)では、ReAct はドメイン・インシデント・データベースクエリ言語構文の事前知識を一切持たないにもかかわらず、KBA Planning Tool でトラブルシューティング手順を取得し、KBA のサンプルクエリを適応・実行し、返されたテーブルを正しく評価するところまで一貫して自律解決できた。クエリの初回実行に失敗しても、エージェントはエラーメッセージの observation を手がかりに自律的に修正できた。一方で、返されたテーブルから一部の行を除外する追加フィルタリングステップが必要な outcome(false positive でない場合)は一貫して解決できず、人間介在によって修正された。複数 KBA にまたがる複雑なインシデント(チーム側は 1 年以上の経験を要すると回答)では、エージェントはもっともらしい高レベルプランを生成するものの、データベースクエリの構築が困難で 1〜2 個の診断ステップしか成功させられずイテレーション上限(20)に到達した。(Source: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] §7.4) ## 考察 - **KBA は実運用 RCA に不可欠**: KBA はデータベースアドレスや API 情報などのエージェント環境に関する補助的事実を含み、OCE と LLM エージェントの双方にとって診断ステップの実行に必須。履歴インシデントの discussion comments にも情報はあるが、通常は診断ステップの**結果**のみが記録され、**手順**そのものの運用知識は記録されないため代替にならない。 - **ツール利用は非自明**: 特殊化されたクエリ言語の使用には試行錯誤が要り、ツール失敗時のエラーメッセージをエージェントに提示することが重要。特定ツール用にファインチューニングした小型モデルへの置換や、チーム固有情報(データベースアドレス等)を in-context で注入する最適化案を提示。 - **複雑ワークフローには experiential learning・multi-trial が必要**: 単一トライアル(20 ステップ上限)は複雑インシデントには不十分。reflection(Reflexion - an autonomous agent with dynamic memory and self-reflection、arXiv 2023、未 ingest)や長期記憶コンポーネントによる試行間の経験蓄積を伴う multi-trial 枠組みへの拡張を示唆。 - **人間介在は信頼構築とガードレールに必須**: エージェントが行き詰まった箇所をエンジニアが容易に修正できるようにする必要がある。エージェントの行動空間への明示的ツールと UI 機能の組み合わせを推奨。experiential learning と組み合わせれば、少数の team-specific インシデントをエンジニアが監督しつつエージェントが経験リポジトリを構築する運用も構想できる。(Source: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] §7.5) ## 強み / 弱点・課題 **Strengths** - ファインチューニングなし・ゼロショットで、強力なリトリーバル・CoT ベースラインと意味的類似度において競合しつつ、ハルシネーション率を大幅に低減(定性評価の不正解ケースでハルシネーション比率が RB (k=10) 49%・CoT 18%に対し ReAct 6%)。 - チーム固有ツールを備えた実運用ケーススタディにより、静的データセット評価だけでは見えないエージェントの自律診断能力(KBA 活用・エラー自己修正)を実証。 - 人間介在ツールの導入により、実運用での失敗モードに対する実践的な緩和策(human-in-the-loop)を具体的に設計・実装した。 **Weaknesses/Limitations** - 評価は Microsoft 社内データセットに限定され、他組織のデータセットへの一般化は未検証。 - テストセットは予算制約から 500 件のサンプルに縮小しており、より大きなテストセットでの性能は未確認(ただしランダムサンプリングと先行研究に倣ったサンプルサイズで脅威を緩和したと主張)。 - 人手アノテーションはバイアスの余地があり、曖昧な例については複数回の議論で収束させたと述べるが、大規模な bias 定量評価はない。 - RQ2 で使われる discussion comments の要約プロセスは、参照要約が存在しないため定量評価が難しく、定性評価と end-to-end RCA 評価に依存している。 - 複雑インシデントでは 20 ステップのイテレーション上限内でエージェントが完遂できず、拡張してもコンテキスト長の制約に直面する構造的限界がある。 - 汎用エージェント評価環境(WebArena・AlfWorld・WebShop 等)に相当する RCA 向けシミュレーション環境が存在しないため、エージェントの動的診断能力そのものを大規模かつ体系的に定量評価できていない(著者自身が Future Work として明記)。