# Accurate and Interpretable Log-Based Fault Diagnosis using Large Language Models **通称**: LogInsight | **所属**: [[Nankai University]]・[[Tsinghua University]]・[[China Mobile Research|CMCC]]・[[ZTE Corporation]] | **年**: 2025 ## 論文情報 | 項目 | 内容 | |---|---| | 著者 | [[Yongqian Sun]]・[[Shiyu Ma]]（南開大 \*）、[[Tong Xiao]]（清華大 †）、[[Yongxin Zhao]]（南開大 \*）、Xuhui Cai・Wei Dong・Yue Shen・Yao Zhao（CMCC ‡）、[[Shenglin Zhang]]（南開大 \*）、Jing Han（[[ZTE Corporation]] §）、[[Dan Pei]]（清華大 †） | | 発表媒体 | IEEE Journal（査読中 / 掲載予定、"JOURNAL OF LATEX CLASS FILES" テンプレート使用） | | URL | [PDF](https://nkcs.iops.ai/wp-content/uploads/2025/08/Accurate_and_Interpretable_Log_Fault_Diagnosis_using_Large_Language_Models.pdf) | ## 概要 大規模オンラインサービスシステムで障害が発生した際、O&M エンジニアは膨大なログを解析して障害の種類を特定（障害トリアージ）する。既存の自動化手法は「どのタイプの障害か」という分類結果のみを出力し、判断根拠を説明しないため、エンジニアの信頼獲得と後続対応の効率化に限界があった。 本論文は **LogInsight** を提案する。LLM を用いた正確かつ解釈可能なログベース障害診断フレームワークで、二つの中核技術を組み合わせる。 1. **FOLS（Fault-Oriented Log Summary）**: DBSCAN クラスタリングによる重複排除と TF-IDF スコアリングによる重要ログの抽出で、LLM のコンテキスト長制約を克服する 2. **LoRA ファインチューニング**: GPT-4 が生成し専門家が検証した説明付きインストラクションデータセット（LFDInstruction）で Mistral-7B を訓練し、ドメイン特化知識を注入する ![[wiki/sources/_attachments/loginsight-log-fault-diagnosis/fig1-traditional-vs-interpretable.png]] *図1：従来の障害診断（分類ラベルのみ）と解釈可能な障害診断（説明付き）の比較* ## 問題設定 ### 課題 - **LLM のドメイン知識不足**: LLM は障害診断に特化した訓練を受けておらず、ドメイン固有のスキルと文脈理解が不足するため、直接適用では性能が低い - **LLM のコンテキスト長制約**: 障害診断には大量のログ解析が必要だが、LLM のコンテキスト長は有限で、全ログを一度に入力することが困難。コンテキスト長延長研究も計算量の指数的増加と精度劣化という課題を抱える ### 既存手法の限界 - 機械学習系（LogCluster、Cloud19）: ノイズや冗長ログに影響されやすく、説明性がない - 深層学習系（MoniLog、SwissLog）: 複雑なログパターンへの対応は優れるが偽陽性 / 見落としがある - データマイニング系（LogBASA、LogKG）: フォーマット特定性が高く汎用性に限界 **共通の欠点**: すべての既存手法が「解釈可能な説明」を提供できない。 ## 提案手法：LogInsight ![[wiki/sources/_attachments/loginsight-log-fault-diagnosis/fig2-loginsight-framework.png]] *図2：LogInsight の全体フレームワーク（オフラインステージ：知識注入 + ファインチューニング、オンラインステージ：推論）* LogInsight は 4 つのコンポーネントで構成される。 ### 1. ログ前処理（Log Preprocessing） 障害発生時刻 $t$ に対して $[t-w : t]$ の時間窓内に生成された生ログを収集し、正規表現でログを構造化してコンテンツフィールドのシーケンスを生成する。ログパースを行わない点が従来手法との相違で、LLM の自然言語理解能力を活用する。 ### 2. FOLS モジュール（Fault-Oriented Log Summary） ![[wiki/sources/_attachments/loginsight-log-fault-diagnosis/fig4-fols-module.png]] *図4：FOLS モジュールのワークフロー（クラスタリングによる集約 → TF-IDF によるランキング）* LLM のコンテキスト長制約に対処するための中核モジュール。2 段階で動作する。 **① クラスタリングによるコンテンツ集約（Clustering-Based Content Aggregation）**: - ログコンテンツ間のジャッカード距離 $d(x,y) = 1 - |X \cap Y| / |X \cup Y|$ で N×N 距離行列を構築 - DBSCAN アルゴリズム（密度ベースクラスタリング）でクラスタを自動形成（k-means と異なりクラスタ数指定不要） - 各クラスタの重心（他全メンバとの平均距離最小）を代表コンテンツとして選択 **② TF-IDF によるコンテンツランキング（TF-IDF-Based Content Ranking）**: - $TF(t) = n_t / n$（トークン $t$ の出現頻度） - $IDF(t) = \log(N / (n_t + 1))$（$N$: 障害総数、$n_t$: トークン $t$ を含む障害数） - スコア $= \sum_i TF(t_i) \times IDF(t_i)$ で各ログコンテンツを評価 - 閾値以下のスコアを持つログを除外し、残りを時系列順に並べ替えて「障害サマリ」として出力 ### 3. 知識注入（Knowledge Injection） O&M エキスパートが広範な障害ケースのログデータを収集し、FOLS で簡潔なサマリを生成して入力とする。GPT-4 が初期の説明（出力）を生成し、専門家が手動検証して **LFDInstruction データセット**を構築する。50 件 / データセットの査読対象で、2 名のエンジニアが約 1 時間で 50 件をレビューできる（一回限りの初期コスト）。 ### 4. 教師あり LoRA ファインチューニング（Supervised Fine-tuning） LoRA（Low-Rank Adaptation）を使ってパラメータ効率的なファインチューニングを実施。損失関数: $\theta^* = \arg\min_\theta \frac{1}{N} \sum_{i=1}^N L(M_\theta(x_i, I_i), y_i)$ ベースモデルとして Mistral-7B・Qwen1.5-7B・LLaMA2-7B・Gemma-7B を比較し、Mistral-7B が最良（表II）のため採用。LoRA 設定: rank=8、alpha=32、dropout=0.05、学習率=10⁻⁴、バッチサイズ=16、最大トークン上限=4096。 ## 新規性 1. **解釈可能な障害診断フレームワーク**: 既存の純分類型手法と異なり、障害種別と同時に自然言語の説明（根拠）を生成する 2. **FOLS モジュール**: ログクラスタリング（DBSCAN + ジャッカード距離）と TF-IDF ランキングの組み合わせで LLM のコンテキスト長制約を実用的に解消する 3. **GPT-4 支援 + 人手検証によるデータキュレーション**: 初期アノテーションを GPT-4 で自動化しつつ専門家検証で品質を担保し、少数（50 件）のラベルデータで高品質なファインチューニングを実現する ## 実験設定 ### データセット | データセット | ログエントリ数 | ログテンプレート数 | 障害種別数 | 障害ケース数 | |---|---|---|---|---| | Dataset 1（業務サーバ、天池） | 282,537 | 157 | 3 | 2,671 | | Dataset 2（OpenStack） | 1,461,006 | 727 | 6 | 93 | | Dataset 3（CMCC 本番 4G/5G スイッチ） | 178,773 | 99 | 9 | 2,267 | 各データセットから 50 ケースをファインチューニング用（全障害種別を網羅）に選択し、残りをテストに使用。 **Dataset 1**: サーバのログ（CPU Caterr / Memory Constraint Error / Hardware Error の 3 種類、障害前 12 時間のログを収集） **Dataset 2**: OpenStack のログ（AMQP Server Unreachable / MySQL Lost Connection / Computing Node Down / Flavor Disk Too Small / Linuxbridge-agent Anomalies / Nova-conductor Lost Connection の 6 種類） **Dataset 3**: CMCC 本番ネットワーク（322 台スイッチ、1 年間のログ。Power Supply Fault / Fan Fault / Optics Module Fault / Port Flapping Fault / CRC Error / STP Fault / BFD Down / LACP Flapping / OSPF Neighbor Flapping の 9 種類） ### 評価指標 Micro F1・Macro F1・Weighted F1 の 3 種類を使用。Macro F1 はクラス不均衡に関係なく各クラスに等重みを与え、Weighted F1 はクラスサイズに比例した重み付きで評価する。 ### ベースライン - **LogCluster**（教師なし）: TF-IDF + 階層的クラスタリング - **Cloud19**（教師あり）: word2vec 埋め込み + 分類 - **LogKG**（教師あり）: 知識グラフ + OPTICS クラスタリング - **GPT-4**: 同一プロンプトでの非ファインチューニング評価 ### 実験環境 Ubuntu 18.04 LTS、Intel Xeon Gold 6430 × 2（各 64 コア / 128 スレッド）、NVIDIA A800-80GB GPU × 2 ## 実験結果 ### RQ1: 障害診断性能 ![[wiki/sources/_attachments/loginsight-log-fault-diagnosis/table3-performance-comparison.png]] *表3：LogInsight とベースラインの性能比較* LogInsight は全データセット・全メトリクスで最高性能を達成。 | データセット | 指標 | LogInsight | 最良ベースライン | 改善率 | |---|---|---|---|---| | Dataset 1 | Weighted F1 | 0.883 | Cloud19（0.514） | **+36.9%** | | Dataset 2 | Weighted F1 | 0.997 | LogCluster（0.869） | **+12.8%** | | Dataset 3 | Weighted F1 | 0.997 | GPT-4（0.924） | **+7.3%** | ベースライン手法は Macro F1 が Micro / Weighted F1 と比べて一貫して低く、クラス不均衡への対応に弱い。LogInsight は全指標で安定した高精度を示す。GPT-4 をも全データセットで上回るのは、LoRA ファインチューニングによるドメイン知識注入の効果。 ### RQ2: 効率性 オンライン推論時間（1 ケースあたり平均）: Dataset 1 → 2.707s、Dataset 2 → 8.541s、Dataset 3 → 2.819s。リアルタイム展開の許容範囲内。 ### RQ3: FOLS モジュールのアブレーション FOLS を除去すると Dataset 1 の Weighted F1 が 0.883→0.767（−0.116）、Dataset 2 で 0.997→0.382（−0.615）と大幅に劣化。クラスタリングに関しては K-means・HAC より DBSCAN が優位。ログパース手法（Drain / DivLog / LILAC）はクラスタリング系手法より一般的に劣る（パース誤りやプレースホルダ「\*」が LLM を誤導するため）。 ### RQ4: 解釈性評価（専門家評価、n=200） | 評価者 | 有用性 Mean | 有用性 HIP | 可読性 Mean | 可読性 HIP | |---|---|---|---|---| | R1 | 3.62 | 62.5% | 4.02 | 87.5% | | R2 | 3.90 | 85.5% | 4.03 | 85.0% | | R3 | 3.87 | 79.0% | 4.08 | 87.5% | | **平均** | **3.80** | **75.7%** | **4.04** | **86.7%** | HIP（High Interpretability Percentage、スコア 4 以上の割合）: 有用性 75.7%、可読性 86.7%。説明の多くが実際の障害診断に有益で、文法的に正確で理解しやすい。 ### RQ5: 異なる LLM との互換性 ベースモデルを Qwen1.5-7B / LLaMA2-7B / Gemma-7B に変えても同様のファインチューニングで競争力ある性能を発揮。Mistral-7B が最良だが、アーキテクチャ非依存の汎用フレームワークとして機能する。 ### ケーススタディ ![[wiki/sources/_attachments/loginsight-log-fault-diagnosis/fig8-case-study.png]] *図8：2 障害ケースの診断結果（Port Flapping Fault と Power Supply Fault）* - **Port Flapping Fault**: 796 件の生ログ → FOLS で 29 件のクラスタ代表 → TF-IDF フィルタで 18 件の障害サマリ → LOS アラームによる複数ポートの Down と LACP / Smartgroup の状態変化を根拠に Port Flapping Fault と正確に診断 - **Power Supply Fault**: 365 件の生ログ → 23 件の障害サマリ → 「power abnormal」「Power malfunction alarm」「電圧エラー」を根拠に Power Supply Fault と正確に診断 ## 考察・議論 ### ファインチューニング vs プロンプトベース vs RAG | 手法 | Dataset 1 Weighted F1 | |---|---| | LogInsight（ファインチューニング） | 0.883 | | RAG ベース | 0.302 | | プロンプトベース | 0.508 | ファインチューニングが圧倒的に優位。ベース LLM（RAG あり・なしとも）は指示に従わず、無関係・非構造的なコンテンツを生成したり、要求フォーマットの出力に失敗したりする。専門タスクには知識注入のためのファインチューニングが不可欠。 ### 制限事項 1. **類似ログパターン問題**: Dataset 3 の「Port Failure」と「LACP Flapping」のように、ある障害が別の障害を誘発するため、ログパターンが高度に類似する場合の誤分類。将来的には性能メトリクスやトレース等のマルチモーダルデータ統合が有効。 2. **未知障害種別**: 既知障害種別のリストをプロンプトで指定するため、実運用で出現する未知の障害種別を「unknown type」として正しく分類できず、既存種別に誤分類することが多い。外部知識ベースや自己教師学習の統合が今後の課題。 ## 強み・弱点・課題 ### 強み - 説明生成という実務的価値の高い機能を、少量ラベルデータ（50 件）で実現 - FOLS による文脈圧縮が DBSCAN の理論的性質（クラスタ数指定不要・任意形状対応）と well-motivated に組み合わさっている - GPT-4 生成 + 人手検証という現実的なデータキュレーションパイプライン - 複数の LLM アーキテクチャで同様の手法が機能するフレームワーク汎用性 ### 弱点・課題 - ファインチューニング用の人手ラベル（障害種別情報）が必須で、新種の障害に再学習が必要 - 未知障害への対応が弱い（closed-set 分類に帰着している） - ログ単一モダリティに依存しており、ログだけでは判別困難な障害種別がある - オフラインステージに 30〜67 分の訓練時間を要する ## 関連リンク - [[ログ解析]] — ログ解析の親概念（FOLS のコンテキスト圧縮はパイプラインの上流前処理に位置する） - [[ログベース障害診断]] — 本論文の中心概念 - [[LLMによる根本原因分析]] — LLM × 障害診断の比較文脈 - [[ログパース]] — FOLS はパース不要でコンテンツシーケンスを直接扱う（対比） - [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]] — 前先行研究：同じ Nankai/CMCC グループによる知識グラフベース障害診断