【要約】fit_predictで体で覚えた、異常検知の定石 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
検証者がGCP上のVM障害を検知する際、Isolation Forestの検知精度が極めて不安定になる問題に直面した。当初の設計では、短い観測窓ごとに学習と判定を同時に行う手法を採用していた。具体的には以下の課題が発生した。
- ・短い観測窓（25〜55行）ごとにfit_predict()を繰り返し実行していた。
- ・窓の中に障害データが混在し、正常の基準が毎回書き換えられていた。
- ・その結果、Recall（再現率）が0.44〜1.00の間で激しく変動した。
- ・特徴量を削減するなどの対策では、この根本的な設計ミスを解決できなかった。
// Approach
検証者は、学習（fit）と判定（predict）のプロセスを明確に分離する設計変更を行った。モデルのパラメータは変えず、データの使い方のみを最適化した。具体的な手順は以下の通りである。
- ・正常データのみを抽出して、モデルの学習（fit）を行う。
- ・未知のデータに対しては、学習済みのモデルを用いて判定（predict）のみを行う。
- ・評価時には、対象のデータを含まない正常データで基準を作るleave-one-run-out方式を採用した。
- ・実測データの特性を反映させるため、疑似データではなく実測データでbaselineを構築した。
// Result
設計変更により、未知のデータに対しても極めて安定した検知性能を実現した。検証の結果、以下の成果が得られた。
- ・実測4回の検証において、すべてRecall 1.00を達成した。
- ・完全新規のデータ（run5）を用いた厳格なテストでも、Recall 1.00 / Precision 0.76という良好な結果を得た。
- ・実測データに基づくbaseline構築により、疑似データ使用時よりも誤検知（Precisionの低下）を抑制できた。
Senior Engineer Insight
> 異常検知の実装において、モデルの選定以上に「正常の定義」と「学習データの純度」が重要である。学習データに障害（ノイズ）が混入すると、検知基準自体が汚染される。これは大規模運用におけるモデルのドリフト問題に直結する。実運用では、継続的なメトリクス流入に対し、いかにクリーンな正常状態を定義し、baselineを更新し続けるかというパイプライン設計が鍵となる。