系統：它實際上在做什麼
核心來說，異常偵測是一個壓縮問題。你取一段長長的歷史數值——伺服器 CPU 負載、建築能耗、心率——然後建立一個典型行為的緊湊描述。接著，你將每個新觀測值與那個描述比對。如果差異夠大，你就稱它為異常。
但「夠大」是判斷，不是事實。同樣的數值偏差，在一個情境裡可能是無害的波動，在另一個情境裡可能是關鍵故障。凌晨兩點的 CPU 使用率飆升可能是批次作業；下午兩點的同樣飆升可能是失控的程式。系統必須把那個情境編碼進去，否則它就會變成放羊的孩子。
基於預測的方法，是預測下一個值並量測預測誤差。如果誤差超過門檻，那個點就被標記。門檻的選擇，就是設計所在。太緊，每個微小的波動都變成事件；太鬆，真正的問題就溜過去。文獻常用預測誤差作為新穎性分數，但那個分數只有在模型的「正常」概念與你的營運現實相符時才有用。
每一層：感測器、模型、應用
感測器層是原始資料。在智慧建築裡，那意味著量測溫度、濕度和功耗的 IoT 感測器。資料到達時帶有間隙、突波和漂移。一個慢慢失準的感測器，會產生看起來像真實變化而非故障的趨勢。除非你給模型一個理由，否則它無法分辨差異。
模型層是學術關注的焦點所在。像 LSTM 這樣的神經網路很受歡迎，因為它們天生處理序列，可以在沒有大量前處理的情況下學習時間依賴。自動編碼器學習正常模式的壓縮表示，並標記任何重建不佳的東西。一些較新的工作使用圖神經網路來建模多個感測器之間的關係，捕捉只有當你觀察整個網路而非單一串流時才可見的異常。
應用層是警報。這是人類與系統相遇的地方。一個輸出異常分數的模型是不夠的；必須有人決定如何處理那個分數。業界觀點指出，文獻常聚焦於偵測原始分佈中的異常，但實務工作者關心的是那些無法由已知因素解釋的異常——例如，考慮到天氣和一天中的時間，某個感測器讀數很奇怪。這個區別改變了整個建模方法。
邊緣案例：有趣的地方
邊緣案例是異常偵測發揮價值之處。考慮一棟建築的能耗。突然下降可能是感測器故障，也可能是建築空無一人的假日。突然上升可能是 HVAC 機組故障，也可能是排定的事件。模型需要輔助資料——行事曆、天氣、佔用率——來消除歧義。業界論文強調了這個確切的缺口：兩個感興趣的量是原始值中的異常，以及無法由其他因素解釋的異常。大多數學術工作只處理第一個。
另一個邊緣案例是異常本身的定義。一個在孤立狀態下不尋常的點，可能是模型已學會接受的緩慢漂移的一部分。相反地，一個在正常範圍內的點，可能因為它到達的時間不對而成為異常。時間脈絡與數值本身一樣重要。
基於原型的方法試圖透過學習代表性模式並將新序列與那些原型比較來解決這個問題。它們提供了一種解釋形式：「這個序列是異常的，因為它不符合我們見過的任何典型模式。」這對需要理解警報為何觸發的人類操作員來說很有用，而不只是知道它觸發了。
什麼會壞（以及為什麼知道這點很有用）
最先壞的是「正常是靜態的」這個假設。真實系統會漂移。建築的能耗概況隨季節變化。伺服器的負載隨使用者群體變化。如果模型沒有重新訓練，它會把新的正常標記為異常。如果它重新訓練得太激進，它會開始把真正的異常接受為正常。
第二個壞的是警報門檻。選擇門檻是商業決策，不是技術決策。假警報的成本與漏報的成本，決定了你設定在哪裡。業界論文指出，警報常常需要外部知識來決定某個行為是否預期——這些知識很難編碼進損失函數。
最後，感測器本身會壞。鬆動的連接產生間歇性突波。耗盡的電池產生緩慢下降。這些故障不是資料中的異常；它們是資料生成過程中的異常。要捕捉它們，需要觀察感測器隨時間行為的模型，而不只是它回報的數值。
知道這些故障模式很有用，因為它告訴你該把工程心力花在哪裡。如果你的感測器資料乾淨、問題定義良好，簡單的預測誤差門檻可能就夠了。如果你的資料雜亂、異常依賴脈絡，你需要圖形化方法或基於原型的解釋層。選擇不在於哪個模型最新；而在於系統的哪一層最可能壞。
常見問題
為什麼選擇警報門檻這麼難？
因為它是偽裝成技術決策的商業決策。門檻編碼了假警報成本與漏報成本的取捨。如果你設得太緊，你會為雜訊而呼叫人員；太鬆，真正的問題就溜過去。沒有通用的正確答案——它取決於你的營運脈絡。
簡單的模型能勝任異常偵測嗎？
有時可以。如果你的資料乾淨、異常定義良好，預測誤差門檻可能就夠了。但大多數真實世界的資料是雜亂的，異常依賴脈絡。那時你需要更複雜的模型——多感測器用圖形化、可解釋性用基於原型——否則你會淹沒在假警報中。
我怎麼知道是我的感測器故障，還是系統真的異常？
你無法從原始數值單獨判斷。緩慢的漂移可能是校準問題，也可能是環境的真實變化。你需要觀察感測器隨時間的行為——一致性、雜訊模式，以及與其他感測器的相關性。如果問題在感測器本身，再多的模型調校也無法修復。
