資料工程面試題：如何偵測並處置生產資料漂移？

1. 題目與使用場景

一個推薦、風控或預測管道在生產運行數月後，輸入欄位的分布發生變化。標籤通常有延遲，團隊不能只等準確率下降才發現問題。面試官希望看到一套可解釋、可分層、能觸發行動的監控方案。

AWS Model Monitor 將資料品質、模型品質、偏差和特徵歸因漂移分開監控；NIST 強調部署後的監控需要追蹤真實環境變化和意外後果。回答應說明監控訊號如何進入運行流程。

用「基線—訊號—閾值—處置—複盤」回答：

我先為每個版本和關鍵分群保存訓練期與近期生產基線，再分別監控缺失率、範圍、類別頻率和分布距離。告警需要連續窗口和最小樣本量，避免把季節性當成漂移；一旦觸發，先凍結自動發布並檢查上游資料契約，再根據影響範圍選擇修復資料、回滾模型或重新訓練。事後用標籤到達後的模型品質驗證告警是否真的有用。

為每個特徵保存訓練資料版本、時間範圍、分位數、缺失率、類別集合和業務分群。基線必須可重建，且隨著版本更新明確替換原因。Google Cloud 的模型監控能力支援將輸入特徵、預測和歸因資料與使用者定義閾值比較；關鍵是記錄閾值對應的版本和樣本窗口。

資料品質層檢查型別、範圍、缺失和重複；分布層比較數值分位數或類別頻率；結果層比較預測分布；標籤到達後再比較準確率、召回率或校準。不要把一個距離指標當作「模型壞了」的證據。對高風險分群單獨計算，避免總體平均掩蓋局部退化。

要求最小樣本量、連續多個窗口和季節性基線；對低流量分群使用更長窗口或僅做趨勢提示。告警訊息應帶上受影響特徵、分群、基線版本、樣本量和可能的上游變更。把偵測時間、標籤延遲和處置時間分別記錄，避免用即時訊號假裝已知道模型品質。

輕微漂移進入觀察佇列；高風險且影響核心指標時暫停自動發布、切換到上一版本或規則兜底。上游欄位變更應修復資料契約，真實業務變化才進入重新訓練評估。標籤到達後回填結果，計算告警的精確率、漏報率和處置成本，持續調整閾值。

我會先把「漂移」拆成三類：輸入資料品質、輸入分布變化和模型結果退化。訓練時我為每個特徵保存版本化基線，包括缺失率、範圍、類別頻率和關鍵分群；生產中按小時計算這些指標，並保留樣本量和資料版本。

對數值欄位我比較分位數和分布距離，對類別欄位比較頻率，對結果再觀察預測分布。告警要求連續兩個窗口超過閾值且樣本量足夠，同時使用假日和地區分層基線。標籤到達後，我把準確率和校準與當時的漂移告警對齊，驗證哪些訊號真正預示風險。

處置上，先檢查上游 schema 或採集故障；若是壞資料，暫停消費並回滾資料發布；若是業務分布真實變化，啟動模型評估和受控重訓；若核心指標已經越過安全門檻，則切換到上一模型或規則兜底。所有動作、基線版本和最終結果寫入稽核記錄，下一輪再用誤報和漏報成本調整閾值。

先監控資料品質、輸入分布、預測分布和業務代理指標，把結果標記為風險訊號而非最終品質結論；標籤到達後再回溯驗證。

單一指標受樣本量、分箱、季節性和分群選擇影響。應同時記錄樣本量、多個訊號和連續窗口，並讓閾值對應可執行的處置成本。

如果懷疑上游資料錯誤、影響範圍尚未確定，先回滾或規則兜底；只有確認業務分布真實改變並完成新資料品質驗證後，才進入重訓和受控發布。

用「基線—訊號—閾值—處置—複盤」回答：

我先為每個版本和關鍵分群保存訓練期與近期生產基線，再分別監控缺失率、範圍、類別頻率和分布距離。告警需要連續窗口和最小樣本量，避免把季節性當成漂移；一旦觸發，先凍結自動發布並檢查上游資料契約，再根據影響範圍選擇修復資料、回滾模型或重新訓練。事後用標籤到達後的模型品質驗證告警是否真的有用。