システム：実際に何をするのか
核心的には、異常検知は圧縮問題です。長い履歴の値——サーバーのCPU負荷、建物のエネルギー消費、心拍数——を取り、典型的な振る舞いのコンパクトな記述を構築します。そして、それぞれの新しい観測値をその記述と比較します。差が十分に大きければ、それを異常と呼びます。
しかし、「十分に大きい」は判断であり、事実ではありません。同じ数値の偏差が、ある文脈では無害な揺らぎであり、別の文脈では重大な障害であることがあります。午前2時のCPU使用率のスパイクはバッチジョブかもしれません。午後2時の同じスパイクは暴走プロセスかもしれません。システムはその文脈をエンコードしなければなりません。さもなければ、狼が来たと叫び続けることになります。
予測ベースの手法は、次の値を予測し、予測誤差を測定することで機能します。誤差がしきい値を超えれば、その点はフラグされます。しきい値の選択が設計の核心です。厳しすぎると、あらゆる小さな変動がインシデントになります。緩すぎると、実際の問題がすり抜けます。文献では予測誤差を新規性スコアとして使うことがよくありますが、そのスコアは、モデルの「正常」の概念が運用上の現実と一致している場合にのみ有用です。
各層：センサー、モデル、アプリ
センサー層は生データです。スマートビルでは、温度、湿度、消費電力を測定するIoTセンサーを意味します。データはギャップ、スパイク、ドリフトを伴って到着します。ゆっくりと校正がずれるセンサーは、障害ではなく実際の変化のように見えるトレンドを生み出します。モデルは、理由を与えない限り、その違いを区別できません。
モデル層は、学術的な注目のほとんどが集まる場所です。LSTMのようなリカレントニューラルネットワークは、シーケンスをネイティブに処理し、重い前処理なしで時間的依存関係を学習できるため、人気があります。オートエンコーダーは、正常なパターンの圧縮表現を学習し、再構築が不十分なものをフラグします。いくつかの新しい研究では、グラフニューラルネットワークを使用して複数のセンサー間の関係をモデル化し、単一のストリームではなくネットワーク全体を見たときにのみ見える異常を捉えています。
アプリ層はアラートです。ここで人間がシステムと出会います。異常スコアを出力するモデルだけでは不十分です。誰かがそのスコアをどうするかを決めなければなりません。業界の視点は、文献が生の分布における異常の検出に焦点を当てることが多い一方で、実務家は既知の要因では説明できない異常、例えば天候や時刻を考慮すると奇妙なセンサー読み取り値などに関心があることを指摘しています。その区別が、モデリングアプローチ全体を変えます。
エッジケース：面白くなるところ
エッジケースは、異常検知がその価値を発揮するところです。建物のエネルギー消費を考えてみましょう。突然の低下はセンサー障害かもしれません。あるいは、建物が空の休日かもしれません。突然の上昇は、HVACユニットの故障かもしれません。あるいは、予定されたイベントかもしれません。モデルは、曖昧さを排除するために、カレンダー、天候、占有状況などの補助データを必要とします。業界の論文は、この正確なギャップを強調しています。関心のある二つの量は、生の値における異常と、他の要因では説明できない異常です。ほとんどの学術研究は最初のものだけを扱います。
もう一つのエッジケースは、異常自体の定義です。孤立して珍しい点は、モデルが受け入れることを学んだゆっくりとしたドリフトの一部かもしれません。逆に、正常範囲内の点でも、間違った時間に到着したために異常である可能性があります。時間的文脈は値と同じくらい重要です。
プロトタイプベースの手法は、代表的なパターンを学習し、新しいシーケンスをそれらのプロトタイプと比較することで、これに対処しようとします。それらは説明の形を提供します。「このシーケンスは、これまで見た典型的なパターンのどれにも一致しないため、異常です。」これは、アラートが発火した理由を理解する必要がある人間のオペレーターにとって有用です。発火したことだけでなく。
何が壊れるか（そしてそれを知ることがなぜ役立つか）
最初に壊れるのは、正常が静的であるという仮定です。実際のシステムはドリフトします。建物のエネルギープロファイルは季節とともに変化します。サーバーの負荷はユーザーベースとともに変化します。モデルが再トレーニングされなければ、新しい正常を異常としてフラグします。あまりにも積極的に再トレーニングすると、実際の異常を正常として受け入れ始めます。
次に壊れるのはアラートしきい値です。しきい値を選ぶことは、技術的な決定ではなくビジネス上の決定です。誤警報のコストと見逃し検出のコストが、どこに設定するかを決定します。業界の論文は、アラートがしばしば外部知識を必要とすることに言及しています。その知識は損失関数にエンコードするのが難しいものです。
最後に、センサー自体が壊れます。緩んだ接続は断続的なスパイクを生成します。バッテリーの低下はゆっくりとした減少を生成します。これらの障害はデータ内の異常ではなく、データ生成プロセス内の異常です。それらを捉えるには、センサーが報告する値だけでなく、時間の経過に伴うセンサーの動作を調べるモデルが必要です。
これらの障害モードを知ることは、エンジニアリングの労力をどこに費やすべきかを教えてくれるので役立ちます。センサーデータがクリーンで問題が明確に定義されていれば、予測誤差の単純なしきい値で十分かもしれません。データが乱雑で異常が文脈に依存する場合は、グラフベースのアプローチやプロトタイプベースの説明層が必要です。選択は、どのモデルが最新かではなく、システムのどの層が最も壊れやすいかについてです。
FAQ
アラートしきい値の選択がなぜそんなに難しいのですか？
それは技術的な決定を装ったビジネス上の決定だからです。しきい値は、誤警報のコストと見逃し検出のコストをエンコードします。厳しすぎると、ノイズのために人を呼び出します。緩すぎると、実際の問題がすり抜けます。普遍的な正解はありません。運用上の文脈に依存します。
異常検知に単純なモデルは機能しますか？
時には、はい。データがクリーンで異常が明確に定義されていれば、予測誤差のしきい値で十分かもしれません。しかし、ほとんどの実世界のデータは乱雑で、異常は文脈に依存します。その場合、より洗練されたモデルが必要です。マルチセンサーにはグラフベース、説明可能性にはプロトタイプベース。さもなければ、誤検知で溺れることになります。
センサーの故障とシステムの実際の異常をどうやって見分けますか？
生の値だけからは判断できません。ゆっくりとしたドリフトは、校正の問題か、環境の実際の変化かもしれません。センサーの時間の経過に伴う動作、つまり一貫性、ノイズパターン、他のセンサーとの相関を調べる必要があります。問題がセンサー自体にあるなら、モデルをどれだけ調整しても修正できません。
