LLMによる根本原因分析 - yuuk1's Digital Garden

# LLMによる根本原因分析 ## 定義 LLMによる根本原因分析(LLM-based Root Cause Analysis)は、Large Language Model の emergent capabilities(in-context learning、instruction learning、chain-of-thought reasoning)を用いて、システム障害の原因を推定する研究領域。LLM はテキスト形式の異種テレメトリ(alert、log、incident description、SOP)を直接読み、専門家の思考プロセスを emulate して原因推定を行う。 [[根本原因分析]] の親領域に対し、LLM × RCA は (a) 訓練済みモデルの zero-shot/few-shot 推論能力により annotated training data を要求せず、(b) 自然言語で説明可能な分析結果を出力でき、(c) 既存の SOP / runbook / 外部知識を context として活用できる、という特徴を持つ。 ## 横断的知見 - **LLM の "RCA 内での役割" は同一研究領域でも 3 系統に分化する**: 同じ「LLM × 故障解析」でも LLM の責務が分かれる。(1) **外部知識リーダー**: SOP/runbook を読み因果ルールを抽出([[@2024__ICSE-SEIP__Knowledge-aware Alert Aggregation in Large-scale Cloud Systems - a Hybrid Approach|COLA]])。(2) **グラフマッパー**: 多様なテキスト alert を構造化知識グラフ(Service Dependency Graph 等)のノードへ写像([[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs|Zha+ Electronics2024]])。(3) **多因子分析器・因果推論器**: 複数因子の比較と causality mining を chain-of-thought で実行([[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model|VOCE]])。SkyNet が LLM を **採用しない**位置を取るのは、severe network failure では context size 制約 + ハルシネーション耐性が運用上許容できないため(§2.3)。LLM が真に貢献するシナリオは外部知識やドメイン特化 reasoning が必須な層に限定され、scale 駆動の問題(10⁵ デバイス × 10M syslog/15min)には符号化済みヒューリスティクスや構造的アルゴリズムが優位。(Source: [[@2024__ICSE-SEIP__Knowledge-aware Alert Aggregation in Large-scale Cloud Systems - a Hybrid Approach]], [[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs]], [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]], [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] §2.3) - **LLM が "Chain-of-Thought + 階層分解 + 反復多数決" で安定化する**: 単一プロンプトでは長い incident や複雑な因果推論に失敗するため、LLM ベース RCA は反復的な分解設計に収束しつつある。VOCE([[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model|Chen+ FASE2025]] §4.3)は「source 内 → 隣接 source 間」という階層分解と「k 回反復多数決」(k=5)で accuracy +4.71pt(GPT)/+3.75pt(LLaMA)を達成。CoT 単体や Prompt 単体に対して再現可能な改善を示す。Zha+ 2024 も Phase 2 で LLM を「クラスタ単位」に呼び出し、全アラートを一度に LLM に投げる naive 設計を否定する(§3.2.2 「直接 LLM 適用は impractical」)。長文 context への一発投入を避け、構造化された反復呼び出しに分解する設計が共通する。(Source: [[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs]] §3.2.2, [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]] §4.3) - **外部知識(SOP / SDG / Topology)が LLM の事実根拠を補強する**: 純粋な LLM プロンプトは hallucination の懸念が大きく、本番運用では deterministic な根拠が要求される。Zha+ 2024 は **Service Dependency Graph** で LLM のマッピング先を制約し(§3.2.2 「LLMs lack sufficient knowledge about the relationships between services」と明示)、VOCE は **System Topology** で causality mining の対象を制約し(§4.3)、COLA は **SOP** で domain knowledge を提供する。LLM 単独では「分かったふりの hallucination」を起こすため、ドメイン知識グラフでの bind が必須。SkyNet は「次世代 LLM の context window が拡張されれば SkyNet の structured output を LLM に流すという integration が成立する」と§8で明示し、LLM × deterministic preprocessing の posterior integration を将来方向として位置づける。(Source: [[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs]] §3.2.2, [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]] §4.3, [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] §8) - **GPT-4o は accuracy で LLaMA-2 13B を一貫して上回るが時間コストでは劣る**: VOCE(§5.2 RQ1)で GPT-4o は LLaMA-2 13B より accuracy +7.64pt(VOCE)/+6.68pt(CoT)/+9.72pt(Prompt)で一貫して優位。一方時間コストは GPT-4o の方が低い(56.79s vs 279.91s for VOCE)が、これは LLaMA の 8 GPU 並列 vs OpenAI クラウドリソースという比較条件差で、純粋な性能差ではない。商用 LLM 採用は accuracy 優先の場面で説得力を持ち、open-source LLM 採用はデータ機密性・コスト最適化の場面で意味を持つ二分。(Source: [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]] §5.2) ## 未解決の問い - **LLM の hallucination 発生率と RCA 精度の関係**: VOCE は GPT-4o で accuracy 88.90% を達成するが、「誤った因果推論」を「自信満々に」出力する hallucination は本論文で測定されていない。誤分析の corner case を engineer が見抜けない場合、自動化が逆効果になる可能性。 - **LLM 不採用設計(SkyNet)と LLM ハイブリッド設計(VOCE / Zha+ 2024)を同一データセット上で比較した実証**は未着手。データセット規模(数千〜数万 alerts)と severity(daily incident vs annual severe failure)で何が決定的因子か。 - **context window 拡張(Gemini 1.5 / Claude 3 / 100M token LLM)で SkyNet が "LLM 不採用" 立場を変えるか**: SkyNet §2.3 の根拠の (a) context size 制約と (c) reliability/hallucination 耐性は別問題で、(a) のみが解消されても (c) は残る。両者の独立性を分けた実証が必要。 - **multi-LLM cooperative RCA**: VOCE 1 つの LLM を反復呼び出すが、複数の LLM(GPT-4o + Claude + Gemini)の多数決や役割分担(分析 LLM + 検証 LLM)が精度をどう変えるかは未検証。 - **continuous improvement**: 本番運用で誤判定したケースを LLM の next call に反映する機構(retrieval-augmented memory、fine-tuning など)はどう設計すべきか。 ## 関連 - 親概念: [[根本原因分析]]、[[AIOps]] - 兄弟概念: [[Chain-of-Thought Prompting]]、[[アラートインシデント分析]] - 関連手法: VOCE(Chen+ FASE2025)、Zha+ Electronics2024、COLA(Kuang+ ICSE-SEIP2024)、Ahmed+(ICSE 2023)、NetAssistant(NSDI 2024)、MonitorAssistant(FSE 2024)、RCAgent(CIKM 2024) - LLM 不採用の対比: SkyNet(Yang+ SIGCOMM2025、severe failure × 10⁵ デバイススケールで LLM を意図的に避ける) - ソース: [[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs]] / [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]] / [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] ## 出典 - [[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs]] §3.2.2(LLM × Service Dependency Graph) - [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]] §4, §5(VOCE 設計と実験) - [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] §2.3, §8(LLM 不採用の根拠と posterior integration)