## Summary from Tweet #SRE論文紹介:Microsoftから、クラウドのインシデントの根本原因特定の自動化を、データを収集できる外部環境とのインタラクションをもつLLMのエージェントを用いた手法を実装・評価する論文。評価のための手法は既存のReActを基に実装される。ReActは段階的な推論とツールの使用によりLLMを拡張する。ツールでアクセス可能なデータは要約前のインシデントの詳細と過去のインシデント履歴である。ゼロショットにて、ReActはRAGやCoTのようなベースラインと競合する性能を持ち、かつhallcinationの割合が大幅に低くなることを示した。MS社内のRunbookやトラブルシューティングガイドに相当するKBAと呼ばれる文書にアクセス可能とし、かつ、コンソールへのログインなど人間への介入したときの可能性があることを明らかにした。 arXiv24: "Exploring LLM-based Agents for Root Cause Analysis", https://arxiv.org/abs/2403.04123 [twitter.com/yuuk1t/status/1767106729035395290](https://twitter.com/yuuk1t/status/1767106729035395290) ## Memo - Microsoftのインターンシップ学生によるarXiv論文。共著者に[[2023__ICSE__Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models|Ahmed+, ICSE2023]]や[[2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents|RCACopilot]]の著者が含まれる。 - インシデントの優先順位付けや類似のインシデント履歴の検索など根本原因分析プロセスの一部の自動化に焦点が当てられていたがLLMによるエンドツーエンドのシステムに焦点があたっている。 - [[2023__ICSE__Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models|Ahmed+, ICSE2023]]ではRCAのためにインシデントタイトルと説明のみを用いたファインチューニングを提案する。それには、コストと時間がかかるため、ベースモデルが更新されるか、サービスが進化するたびに繰り返す必要があるため、[[2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents|RCACopilot]]が提案される。RCACopilotはあらかじめ定義されたハンドラに依存しており、手作業で設計する必要があり、特定の根本原因ではなく根本原因のカテゴリを予測する。しかし、これらの先行研究では、**LLMはデータを収集できる外部環境とのインタラクションの能力がない**。 - そこで、**LLMベースのエージェント(新しい情報を収集するために外部環境と 推論、計画、相互作用することができるシステム)を用いることを提案**する。 - [[Few Shot Learning|Few Shot]]では、エージェントベースRCAの場合、推論の軌跡全体を作成することは困難である。 - RCAは標準的なNLPタスク（ウェブ検索エンジンや文書検索）と異なり、より専門的なドメイン知識（ログ、トレース、監視サービスなどの多くの情報源は、特殊なクエリ言語を用いた表形式データのクエリと処理、および付帯情報(例えば、どのデータベースにクエリを送信するか)の知識を要求する。 - 本研究では、LLMベースのエージェント、[[ReAct]]を実証評価する。 - ReActは推論とツールの使用ステップを交錯させ、[[Chain-of-Thought|CoT]]のような推論ベースのアプローチからの原理と[[ToolFormer]]のようなツール使用モデルを組み合わせている。RCAは逐次的意思決定と知識集約的なQAが必要であり、これらはReActによりサポートされている。 - ReActエージェントでは、事前に定義されたハンドラを必要とせず、関連する診断データを自律的に収集できる。 - ![[Pasted image 20240311161458.png|400]] - LLMがReActループを実行することをプランナと呼ぶ。 - エージェントが利用可能なツールは、要約で失われる情報へのアクセスとなる「インシデントの詳細」と、インシデント履歴の検索（バリエーション１：単にエージェントが生成するクエリに対して文書を返すだけ "ReAct BR"、バリエーション２：ツールは検索した文書を注入したLLMを使って、エージェントのクエリに回答する）がある。検索では、[[SentenceTransformer]]を用いる。 - 実験設定: MS社内の1万7000件のインシデントデータに対して、評価セットから100件、テストセットから500件のインシデントをランダムにサンプリングしている。インシデント履歴はgpt-3.5-turboを用いて、説明文と根本原因を要約している。ベースLLMとしてOpenAI GPT4-8kを用いる。 - リトリーバー： - Dense Retriever (ST)：事前学習済みの[[Sentence-Bert]]ベースのエンコーダ(all-mpnet-base-v2)と[[Max Marginal Relevance]] (MMR)を使用。 - Sparse Retriever (BM-25)：IR-CoTやReActエージェントのように複数の検索ステップを行うモデルでは、[[BM-25]]を使用。 - ベースライン：検索ベースライン(RB)（[[RAG]]）、CoT（"Let’s think step by step"を追加する）、IR-CoT（RBとCoTのハイブリッド。推論ステップ は検索コーパスから関連文書を検索するために使用）の3つをベースラインとして用いる。 - 評価指標：語彙的類似度に基づく3つの指標（BLEU、METEOR、Rouge）と、意味的類似度に基づく1つの指標（BertS）を使用。これらは、事実関係の正確さや意味的等価性を正確に測ることはできないため、Table 1の手動アノテーション（[40]のReActのオリジナル論文にて提示される）を行う。2人の著者が100件の予測サンプルに対して定性的コーディングを実施した。 - ![[Pasted image 20240311164215.png|600]] - RQ1) 専門的なチーム固有の診断サービスを利用できない設定。 [[2023__ICSE__Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models|Ahmed+, ICSE2023]]の評価設定を用いた静的データセットに対して検索ツールを搭載する。 - ![[Pasted image 20240311164750.png|400]] ![[Pasted image 20240311164818.png|400]] - 語彙的指標ではReActエージェントはベースラインと競合するが、意味的類似度ではやや劣る。 - 手動ラベリングでは、ReAct S+Q BM25は35％の正解率でベースライン（39％）と競合するが、ハルシネーション（事実に反する生成）の割合が大幅に低い（ReActは4％、CoTは12％、RB (k=10)は40％）。 - ReActエージェントは、検索やCoTベースラインと同等の性能を発揮しつつ、事実関係の誤りが大幅に少ない。 - RQ2) 過去のインシデントレポートから得られたディスカッションコメントを用いる。 - ディスカッションコメントを過去の事例のコーパスに組み込んでも、モデルのRCA性能は明確には向上しない。 - RQ3) Microsoftの別のチームと共同で、チーム固有の診断リソースを十分に備えた設定。 - MSでは、インシデント管理の文脈でKBA (Knowledge Base Articles) を整備しており、特定のタイプのインシデントをどのように診断・緩和すべきかのガイドラインやデータベースクエリの例など、これらの操作を行う方法について記述されている。監視サービスによってトリガーされるインシデントには、自動的または手動でトリアージ中に関連するKBAがタグ付けされる。 - KBAには、ドメイン固有の知識と、エージェントの環境に関する補助的な事実の両方が含まれている。インシデントレポートには、通常、これらのステップがどのように実行されなければならないかという運用上の知識ではなく、診断ステップの結果のみ(一般的にはディスカッションコメント)が含まれています。 - 特殊なクエリ言語を使った診断サービスのクエリには、試行錯誤が必要である。 - 複雑なワークフローのようなマルチトライアルの環境でのエージェントを拡張するには、リフレクションや長期記憶コンポーネントを用いたトライアル間の進捗を維持し、経験的学習を可能にすることが必要である。 - 信頼関係の構築と、ガードレールの提供のため、LLMに重要な操作をさせる際には、人間の介入が必要である。 - 今後の研究として、静的なデータセットの限界を克服するために、RCA環境のシミュレーションが有望である。 - 感想：本研究で初めて提案されたとされるエージェントベースのRCAには、Alibabaからの[[2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models|RCAgent]]が存在するがなぜこの論文が参照されていないかは不明である。エージェントの文脈で、KBAと表記されるいわゆる[[Runbook]]やトラブルシューティングガイド（TSGs）の、[[ポストモーテム]]にはない診断プロセスの重要性が強調されていることは興味深い。 最後の研究の方向性については、まさに自分が考える[[Interactive AIOps]]に近い話である。 ## Abstract クラウドベースのソフトウェアシステムの複雑化に伴い、インシデント管理はソフトウェア開発ライフサイクルの不可欠な一部となっています。インシデント管理プロセスの重要な部分である根本原因分析（RCA）は、オンコール・エンジニアにとって厳しいタスクであり、深いドメイン知識とチーム固有のサービスに関する豊富な経験が求められます。RCAの自動化は、時間の大幅な節約につながり、オンコール・エンジニアのインシデント管理の負担を軽減する。最近、研究者は大規模言語モデル（[[LLM]]）を利用してRCAを実行し、有望な結果を示している。しかし、これらのアプローチは、インシデントに関連するログ、メトリクス、データベースなどの追加の診断情報を動的に収集することができず、根本原因を診断する能力を著しく制限している。本研究では、この限界に対処するために、LLMベースのエージェントをRCAに使用することを検討する。マイクロソフト社で収集された本番インシデントの配信外データセットを用いて、検索ツールを装備した[[ReAct]]エージェントの徹底的な実証評価を行う。その結果、ReActは強力な検索と推論のベースラインと同等の性能を発揮し、事実の正確性が非常に向上した。次に、インシデントレポートに関連するディスカッションをモデルの追加入力として取り込むことで、この評価を拡張する。最後に、マイクロソフト社のチームとのケーススタディを実施し、ReActエージェントにツールを装備させ、チームが手動RCAに使用している外部の診断サービスにアクセスできるようにした。我々の結果は、エージェントが先行研究の限界をどのように克服できるか、また、このようなシステムを実際に実装するための実用的な検討事項を示している。