第二類型的監控 Feature Storage Based Monitoring ，更偏重是一個更長窗口的計算，換句話說前一個 Data Collector Based Monitoring 注重在近乎實時地去偵測模型異常，但在這邊我們更住在的 Batch 的去偵測異常，而這裡的異常更在乎的是 Drift

Drift

從結果論來看，Drift 就是模型隨著時間推移，以指標評估的效能逐步遞減，這主要是因為資料或環境的變化，導致模型的預測不再準確，

1. Data Drift: 指訓練資料和實際運行時資料的分佈產生變化。例如，假設你有一個預測天氣的模型，但因為氣候變遷如全球暖化，過去的數據可能不再反映現在的情況。
2. Concept Drift: 這是當預測目標本身發生變化時會出現的 Drift。以股市預測為例，即使數據沒有變，投資者的心理和行為可能會改變，從而影響模型的預測效能。
3. Model Drift: Model Drift 是指模型的參數或結構隨時間變化，通常因為不斷的更新或優化。這種 Drift 較少見，比較常在 Online Learning 或是 Recommender System 中比較常見

在本篇中，我們不會討論 Model Drift，並為了減少爭議，我也習慣不管是 Data Drift 還是 Concept Drift 我都先以 Drift 來描述資料分佈改變的問題

為什麼不重新訓練就好

當然整個 Drift Detetion 的問題可以直接從觀測模型的 Performance Metrics 開始，觀測模型是不是預測能力變差了，而進一步發覺可能需要重新訓練模型的時間點，然而這樣的缺點是把模型變差的原因完全當作是一個黑盒子，當然你可以真的把模型當作黑盒子，並拿最新的資料直接訓練，但這會有以下幾個問題

1. 有些特徵，已經不再適合使用
2. 有些老闆，希望你能解釋得更清楚為什麼要重新訓練
3. 更嚴重的是，線上模型如果會影響用戶行為，那過去的標記資料是相對骯髒的，從新訓練的成本會比初次上線來得高

監控 Metrics

所以更好的一個方式是你從抽象到詳細地去一層一層監控你的模型，剛提到的 Perfoamce Metrics 就是最抽象的一層，這裡的抽象就是指內部有很多的變因，你很難釐清有哪些變因是有影響效果的，哪些是沒有的，在進一層你可以根據 Inference Score，最後到最底層針對特徵值得分佈進行監控

監控的中心思想不外乎是要看資料的分佈是否發生了變化，分佈就可以用我們之前在 Research Section (Day 10) 中提到的 PSI 指標, KS 檢定來觀測，而觀察比較的對象可以是最近一個月的窗口和訓練時資料的分佈來比較，當然有些特徵本身可能具有時間週期性，也可以和上一個同一週期的時間來做比要，舉例來說在每年下半年 10 月開始，美國會進入購物季，所以你要比較資料是否發生 Drift 的對象就要和去年 10 月到 12 月的資料而不是同一年 1 到 9 月的資料

大多數的 Cloud Service 像是 AWS, Azure, GCP 都已經為資料提供了很好的 Drift 偵測功能，像是 Alibi Detect 也提供了一些 Drift Detection 工具

很多的 Drift 不一定是突然間發生的，而是隨著時間慢慢的變化，因此在 Realtime 的 Data Collector Based Monitoring 時，雖然我們透過窗口可以一定程度的也去發掘一些 Drift，然而他的效果有限，他們更像是要處理資料邏輯上的 Semantic Error (如上篇提到的 Dependency Erro or Discrepancy Error，而今天提到的 Data Drift/ Concept Drift 我認為不能說是一種 Error，雖然我前面用 Drift Error 這個詞，但 Drift 本身就是在描述一個分部已改變的事實，就像在愛情裡沒有誰對誰錯

所以我將第二種 Monitoring 稱為 Feature Storage Based Monitoring 是因為我們是基於存下來的資料，去切割出不同的 Segment，並把這些 Segment 進行分析來觀測模型是否還維持一樣的效力，在這個使用情境中，我們又可以把之前的 Feature Store 設計拿過來，如果 Featrue Store 把儲存方式做了一次好的 Normalization，在這裡的監控我們就可以更 Generalzed 的去時做監控邏輯