> [!abstract] 概要(abstract の日本語訳) > 大規模クラウドサービスは、その安定性に重大な影響を及ぼしうるインシデントに頻繁に見舞われる。インシデントトリアージは、インシデントを解決のために専門チームへ割り当てる重要なプロセスである。しかし、様々なシステムで一般的に採用されているルールベース手法は、継続的な更新を必要とする有限のルール集合に起因する限界を抱えており、性能は最適とは言えない。現在の最先端の手法は主にテキスト情報に依存し、分類器または教師なしクラスタリングを利用する。残念ながら、テキスト情報の豊富さとそれに伴うかなりのノイズが、これらの手法の精度に大きな課題をもたらしている。これらの課題に対処するため、我々は COMET を導入する。これは、非重要なログを除外する AutoExtractor を利用し、キーワード抽出のために大規模言語モデル(LLM)を採用する革新的なシステムである。このアプローチは、無秩序なテキスト情報から生じる複雑性を効果的に緩和する。さらに、COMET はキーワード抽出の過程で重要なドメイン知識を組み込み、LLM のテキスト理解を強化する。我々は COMET を Microsoft 内の複数のクラウドサービスに展開し、6ヶ月以上継続的に稼働させた。オフラインおよびオンラインの評価により、COMET が精度を向上させ、Time to Mitigation(TTM)を削減することが示された。 ## 論文情報 - タイトル: Large Language Models Can Provide Accurate and Interpretable Incident Triage - 著者: [[Zexin Wang]]、[[Jianhui Li]]、[[Minghua Ma]]、[[Ze Li]]、[[Yu Kang]]、[[Chaoyun Zhang]]、[[Chetan Bansal]]、[[Murali Chintalapati]]、[[Saravan Rajmohan]]、[[Qingwei Lin]]、[[Dongmei Zhang]]、[[Changhua Pei]]、[[Gaogang Xie]] - 所属: [[Microsoft]]、Computer Network Information Center([[Chinese Academy of Sciences]])、[[University of Chinese Academy of Sciences]] - 媒体: 2024 IEEE 35th International Symposium on Software Reliability Engineering(ISSRE 2024)、pp. 523–534 - DOI: [10.1109/ISSRE62328.2024.00056](https://doi.org/10.1109/ISSRE62328.2024.00056) - PDF(著者側ホスト、Microsoft Research 公開ページ経由): `https://www.microsoft.com/en-us/research/wp-content/uploads/2024/08/ISSRE24_LLM4triage.pdf`(IEEE Xplore の DOI 版は有料壁の向こう。本ソースはこの Microsoft Research 直接公開版を原本として取り込んだ) ## 概要 論文は、クラウドサービスのインシデントを適切な担当チームへ割り当てる**インシデントトリアージ**を対象に、LLM でログからキーワードを抽出して埋め込みベースの類似検索でチームを推薦するシステム **COMET** を提案する。Microsoft の2つの大規模クラウドサービスに6ヶ月以上本番展開し、オフライン評価とオンライン評価の両方で従来のルールベース・分類器ベース手法を上回る精度と TTM 短縮を達成した。 ## 問題設定 - **入力**: インシデント発生時に収集される大量の生ログ(Change Management Logs・Crash Logs・System Event Logs・Windows/Linux System Events Logs・Container Management Logs など複数カテゴリ)と、ルールベース診断(AutoAnalysis)が出力するタイトル。 - **出力**: インシデントを担当すべきチーム(過去の類似インシデントの担当チームとして予測)。加えてエンジニア向けにキーワードとサマリ、類似インシデントへのリンクを提示する。 - **前提条件**: Microsoft 社内で年間を通じて発生する数千件規模のインシデント、70 チーム超にまたがる担当割り当てというクラス不均衡な多クラス分類問題。訓練データは1年分の履歴インシデント、テストは直近25%。 - **必要なデータ**: インシデントごとの生ログ群(1インシデントあたり数千件規模になりうる)、AutoAnalysis が生成するタイトル、担当チームの正解ラベル(履歴データ)。 **Figure 1: Microsoft におけるインシデント管理の全体像** ![[_attachments/ISSRE24_LLM4triage/fig01-incident-management-overview.png]] (Figure 1. モニタが障害を検知(Detection)してインシデントトリアージへ報告(Report Incidents)し、担当チーム(Owning Team)が議論(Discussion)を経て緩和(Mitigation)に至る流れ。検知からトリアージ完了までを Time to Triage(TTT)、検知から緩和完了までを Time to Mitigation(TTM)と定義する。Source: Fig. 1, 論文 p.1。) ### Challenge(論文が明示する3つの課題) 1. **どのテキスト情報が重要か(ログ vs 議論)**: ログは毎秒百万件規模で生成されテンプレートも絶えず変化するため扱いが難しく、議論(discussion)はエンジニアが書き込むまで時間がかかり、略語やリンクなどノイズも多い。どちらも直接モデル入力にするのは不適切。 2. **大量テキストからどう要点を抽出するか**: embedding へ丸ごと変換すると長文で情報が失われる。生成要約は生成のたびに揺らぎがあり、要約自体が数百語に及ぶため embedding にとって依然として長すぎる。 3. **ドメイン知識をどうモデルに組み込むか**: LLM は汎用コーパスで訓練されているため、ドメイン固有の略語(例: 特定のイベントコード)を見落としがちで、それがまさにエンジニアが注目したい情報である。 ## 提案手法 ### アーキテクチャ COMET は **オフラインフェーズ**(埋め込みモデルの学習)と**オンラインフェーズ**(新規インシデントの推薦)の2段構成。 **Figure 4: COMET のアーキテクチャ** ![[_attachments/ISSRE24_LLM4triage/fig04-comet-architecture.png]] (Figure 4. Incident から AutoExtractor(生ログ→TrimmedLogs)と AutoAnalysis(→Title)が並行して走り、TrimmedLogs はドメイン知識・データ拡張を伴う LLM でキーワードに変換される。キーワードと Title を Word2Vec 系(実際は FastText)で埋め込み、オフラインでは埋め込みモデルの学習、オンラインでは Faiss による recall で類似インシデントと担当チームを返す。Source: Fig. 4, 論文 p.4。) - **AutoAnalysis**: 既存のルールベース決定木の例を下図に示す。仮想マシンの状態を入力に根本原因を説明するテキストを出力し、その出力を後段処理の「タイトル」として利用する(精度が低くても補助情報として有用というのが実験で裏付けられた設計判断)。 **Figure 5: AutoAnalysis(HINodeTriage/HostRCA)のルールベース決定木の例** ![[_attachments/ISSRE24_LLM4triage/fig05-autoanalysis-example.png]] (Figure 5. HINodeTriage が不健全状態を検知すると HostRCA を呼び出し、HW Analysis→OS Analysis→Process Analysis の順にハードウェア/OS/プロセスを判定する決定木。根本原因が特定できない場合は "Inconclusive RCA" を返す。Source: Fig. 5, 論文 p.5。) - **AutoExtractor**: 大量の生ログから TrimmedLogs(数十件程度に絞り込んだ関連ログ)を生成するコンポーネント。 - *Log Parser*: 既存手法([36]、SPINE 系)に類似したクラスタリング・スケジューリングベースのログパーサ。フィードバック機構でテンプレートの継続的更新に対応。 - *Selection Mechanism*: (a) 運用担当者が定義したルール(例: "crash"・"hardware issue" を含むログは高優先度)と、(b) チーム横断で頻出するログを低優先度、稀少で特徴的なログを高優先度とする TF-IDF ライクな手法、の2基準で優先度付けし、TrimmedLogs を生成する。 **Figure 6: AutoExtractor のアーキテクチャ** ![[_attachments/ISSRE24_LLM4triage/fig06-autoextractor-architecture.png]] (Figure 6. CML・CL・SEL・WL-SEL・CTML 等の各種ログが Log Parser でテンプレート化され、Template Database の分布情報を参照しつつ Selection(運用担当者が与えるルールとフィードバック)で絞り込まれて TrimmedLogs になる。Source: Fig. 6, 論文 p.5。) - **キーワード抽出(LLM)**: TrimmedLogs をプリプロセッシング(Web リンク・画像 URL・コンテナ ID などの不要要素を除去)した上で、ドメイン知識を組み込んだプロンプト(Table III)で LLM(GPT-3.5)にキーワードとサマリを2回に分けて生成させる(入力が長く複数タスクを一度に要求すると誤解釈のリスクが高まるため、キーワード抽出とサマリ生成を別呼び出しにする)。 - **埋め込みモデル(FastText)の学習**: 抽出したキーワードで事前学習済み FastText をファインチューニングし、キーワードの平均ベクトルとタイトルのベクトルからインシデント埋め込みを合成する。 - **データ拡張**: 出現数の少ないチームのインシデントに対し、LLM の temperature を変えて複数回抽出を行うことで多様性を持たせるデータ拡張を行う(サンプリングベースの決定論的拡張と異なり、LLM 由来のランダム性を積極的に利用する)。 - **オンラインフェーズ**: 新規インシデントの埋め込みと Faiss による類似検索で過去インシデントを recall し、類似度上位インシデントの担当チームを予測結果として採用する。式(2)はユークリッド距離ベースの類似度 `Similarity = 1 / (1 + Distance(X,Y))`。再ランキングは行わず、recall 結果をそのまま予測に用いる。 ### アルゴリズム/手法の詳細 - **ドメイン知識プロンプト**(Table III、5項目): (1) 障害・エラーを示すキーワードに注目、(2) フォールトコード・イベントID等のコードに注目、(3) FPGA 等の一般的なコンピュータ用語に遭遇したら何が問題かを特定、(4) ツール・デプロイメントに注意、(5) 頻出する一般語をキーワードに含めない。これらは「多数の事例分析から導出した」とのみ記載され、導出プロセスの詳細は論文に記述がない。 - **ハルシネーション緩和**: (a) ドメイン固有の略語について LLM に説明を与える、(b) TrimmedLogs の各エントリを JSON 形式の構造化データとして LLM に渡し、ログカテゴリの意味も伝えることで構造理解を助ける。 ### 実装上の工夫 - LLM には GPT-4 と同等の性能をより低コストで得られるという理由で GPT-3.5 をオンライン運用のデフォルトとして採用(オフライン評価では GPT-4 版の COMET も比較対象に含める)。 - キーワード抽出の推論時に用いる語彙は、訓練フェーズで抽出された全キーワードの集合に限定する(オンライン処理でのリアルタイム TF-IDF 適用が困難なため)。ただしこの語彙制限は訓練データに存在しない有用語を除外しうるトレードオフを伴う。 - Azure web app framework 上に2つの大規模クラウドサービス(仮想マシン提供サービス)向けとしてデプロイ。新規インシデント発生をトリガに web app が起動する。 - 既存のインシデント管理サイトの構造を変えず、AutoAnalysis の出力をタイトルとして、AutoExtractor が生成した TrimmedLogs を discussion エントリとして追加するのみで運用に統合(Figure 8)。 ## 新規性 - 既存のルールベース手法(AutoAnalysis 等)は新規シナリオへの継続的なルール更新が必須で、"Inconclusive" 判定になりやすいという限界がある。COMET はルールを置き換えるのではなく、AutoAnalysis の出力をタイトルとして活用しつつ LLM ベースの補完で精度を底上げする設計を取る。 - 既存の分類器ベース(DeepCT、DeepTriage など)は議論(discussions)や要約をテキスト表現として使うが、本論文は実証実験(§II-B, §II-C)により、ログをフィルタしたもの(TrimmedLogs)の方が discussions より、さらにキーワードの方が生成要約より、インシデントトリアージにおいて有効であることを比較実験で示した点が主要な貢献である(Table I・Table II)。 **Figure 3: 同一インシデントに対するキーワードとサマリの生成例** ![[_attachments/ISSRE24_LLM4triage/fig03-keywords-vs-summary-example.png]] (Figure 3. TrimmedLogs から LLM が抽出した Keywords("bad hardware health, fatal io error, x.dll, y driver failing, …")と Summary(自然文の説明)の対比。サマリは人間には読みやすいが接続語を含み冗長で、トリアージに直結する情報はキーワードに集約されていることを示す例。Source: Fig. 3, 論文 p.4。) - キーワード抽出タスクにドメイン知識をプロンプトとして注入する手法を、ファインチューニングのコストを避けつつ導入した点を新規性として主張する。 ## 実験設定 - **ハードウェア/ソフトウェア環境**: 記載なし(Microsoft 内部クラウド基盤上でのオフライン評価・オンライン展開)。 - **データセット**: Microsoft の2つの大規模クラウドサービス(仮想マシン提供、システムA・システムB)から1年分収集したインシデントデータ。直近25%をテストに使用。70チーム超にわたる担当割り当て。 - **比較対象(baseline)**: - DeepCT([17], ASE 2019): GRU + attention で discussions のタイトル・要約から関連情報を抽出する継続的トリアージ手法。 - DeepTriage(DT, [19], KDD 2020): MART・LGBM・Inverted Index・局所性鋭敏型ハッシュ(SI)・DNN を組み合わせたアンサンブル。個別のサブモデル(MART, LGBM, II, SI, DNN)も単独ベースラインとして比較。 - **評価指標**: `ACC@N = (Top N チームに正解が含まれるインシデント数) / テストサイズ`(式(1))。ACC@1・ACC@5 を主指標として使用。オンライン評価では TTM(Time to Mitigation)・FTT(First Triage Time)も測定。 ## 実験結果 - **オフライン全体性能(Table V)**: COMET(GPT-4) が ACC@1/ACC@5 で All(2サービス統合)0.65/0.82 を達成し、最良ベースライン DeepCT の 0.56/0.74 を上回る(システムAで+5%、システムBで+4% の ACC@1 向上、ACC@5 はそれぞれ+10%・+6%)。COMET(GPT-3.5)でも 0.62/0.78 とベースラインを上回る。 - **テキスト情報比較(Table I)**: TrimmedLogs は discussions に対して ACC@1 で 0.57 対 0.54、ACC@5 で 0.78 対 0.76 と一貫して上回る(DeepCT をベースに入力テキストのみ差し替えた比較実験)。 - **キーワード vs 要約(Table II)**: キーワードが ACC@1 0.65 / ACC@5 0.82 に対し、要約は ACC@1 0.22 / ACC@5 0.55 と大差でキーワードが優位。 - **アブレーション(Table VI)**: (1) キーワード+ルールベースマッチングのみ(ACC@1 0.36)→(2) FastText 埋め込み追加(+12%/ +4%、ACC@1 0.48)→(3) ドメイン知識プロンプト追加(+7%/+2%、ACC@1 0.55)→(4) データ拡張追加(+5%/+2%、ACC@1 0.60)→(5) タイトル情報追加=COMET(+5%/+4%、ACC@1 0.65 / ACC@5 0.82)と、各コンポーネントの寄与を段階的に確認。 - **埋め込みモデル比較(Fig. 10)**: FastText は BERT よりも ACC@1・ACC@5 双方で優れ、かつ訓練時間が大幅に短い。理由として、キーワードは単語数が少なく単語間の複雑な文脈関係を考慮する必要が乏しいため、BERT の文脈考慮能力が過剰であると論じる。 - **TF-IDF ノイズ除去実験(Fig. 9)**: TF-IDF による低頻度語のフィルタリングの有無・語彙制限あり/なしを比較し、生成されたキーワードのノイズがもともと小さいため語彙制限は効果が乏しい(むしろ多様性を損ないうる)ことを確認。タイトル情報の追加が最も効果的という結果を補強。 - **パラメータ感度(Fig. 11)**: 学習エポック数・学習率に対する精度の頑健性を確認(具体的な数値は本文に記載なし、図のみ)。 - **オンライン結果(Table IV)**: Baseline(既存ルールベース)は ACC@1 0.47・FTT 7.85TU、ACC@5 は単一推薦のため算出不可。COMET は ACC@1 0.61・ACC@5 0.88・FTT 1.30TU・TTM -35% を達成。 - **ケーススタディ**: OS crash を含むインシデントで、COMET がキーワード(HostOSCrash, Bugcheck n…)とサマリで根本原因の要点を的確に抽出し、類似インシデントへのリンクも提示することで、エンジニアがログを逐一確認する手間を削減する例を提示。 **Figure 8: インシデントウェブサイト上での COMET 出力例** ![[_attachments/ISSRE24_LLM4triage/fig08-incident-website-case-study.png]] (Figure 8. タイトル "VM reboot due to 'OS Bugcheck xxx MissingDump' for Cluster A" のインシデントに対し、TrimmedLogs(タイムスタンプ・メッセージ・種別)と COMET の出力(Keywords: HostOSCrash, Bugcheck n…／Summary／Team Recommendations／Similar Incidents へのリンク)がインシデントサイトの discussion 欄に追加される様子。Source: Fig. 8, 論文 p.8。) ## 考察 - FastText を選んだ根拠として、BERT は単語間の文脈関係を捉えるのに強いが、パラメータ数が多くメモリ・訓練コストが大きい点、およびキーワードという短い単語集合には文脈考慮の恩恵が乏しい点を挙げる。n-gram ベースの FastText の方がオンライン運用の効率と精度の両面で適合すると結論づける。 - ドメイン知識プロンプトの効果(Table VI method 2→3)は、LLM が汎用コーパスで訓練されているためドメイン固有語の重要性を認識できないという課題(Challenge 3)に対する直接的な検証結果として位置づけられる。 - データ拡張(LLM の temperature 操作による多様なキーワード生成)は、従来のサンプリングベース拡張が決定論的でランダム性を追加できない点との対比で新しいトレンドとして論じられている。 - タイトル(AutoAnalysis 由来)を追加した効果が最大(ACC@1 +5%)であった点は、ルールベース手法の出力が不正確であっても放棄せず補助信号として活用する価値を裏付ける結果として、§III-A1 の設計判断(AutoAnalysis の結果は「不正確でも」有用)の実験的根拠になっている。 ## 強み / 弱点・課題 **強み** - Microsoft の実運用クラウドサービス2件に6ヶ月以上デプロイし、オフラインだけでなくオンラインの実運用指標(TTM・FTT)で改善を確認した数少ない実運用実証研究である。 - テキスト表現の選択(ログ vs 議論、キーワード vs 要約)について、比較実験に基づく明確な設計根拠(Lesson 1〜3)を提示している。 - アブレーション(Table VI)が各コンポーネント(埋め込みモデル・ドメイン知識・データ拡張・タイトル)の寄与を定量的に切り分けており、設計判断の妥当性検証が丁寧。 **弱点・課題(論文が示す限界と読み取れる懸念)** - ドメイン知識プロンプト(Table III の5項目)がどのように導出されたか(専門家インタビューか、事例からの帰納か)の具体的なプロセスは記述がなく、他ドメインへの転用可能性が不明瞭。 - オンライン評価は「1ヶ月間に発生し解決済みのインシデント」に限定されており(§IV)、評価期間・件数の規模、統計的有意性の検証は論文中に明記されていない。 - 語彙制限(訓練時抽出キーワードのみを推論時に許容)は、実運用上の制約として導入されているが、新規かつ重要なキーワードを取りこぼすリスクを著者ら自身も認めている(§III-A3)。 - LLM 呼び出し(キーワード抽出+サマリ生成の計2回)によるレイテンシがFTTの主要因になっていると述べられているが(§IV)、具体的なレイテンシ内訳や LLM API コストの定量評価は示されていない。 - 比較対象のベースライン(DeepCT・DeepTriage)はいずれも2019〜2020年発表であり、2023年以降のLLMベース root cause analysis 手法(RCACopilot・[[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models|RCAgent]]・[[@2024__ICSE__Xpert - Empowering Incident Management with Query Recommendations via Large Language Models|Xpert]] など、関連研究節で言及)との直接比較は行われていない。