SageMaker Model Monitor——偏差漂移與可解釋性漂移

SageMaker Model Monitor 的偏差漂移與特徵歸因漂移監控，是 AWS 上負責任 AI 的生產等級執行層——沒有它們，一個在訓練時通過偏差測試的模型，可能在生產中悄悄地對受保護的人口群體變得不公平，持續數月才有人注意到；而一個特徵重要性悄悄偏移的模型，可能繼續以錯誤的理由提供看似合理的預測。在 MLA-C01 考試中，這兩種監控類型錨定 Domain 4（ML 解決方案監控、維護與安全，佔 24% 比重）Task 4.1（監控模型推論）的較難部分。社群反映的痛點普遍將 SageMaker Clarify 和 SageMaker Model Monitor 的混淆列為真實考試中最常失分的邊界——Tutorials Dojo 特別將此列為 MLA-C01 中最高頻率的考試陷阱。

本指南以工程師視角建構。它涵蓋偏差和可解釋性漂移的概念框架、Clarify 追蹤的偏差指標（DPL、DI、CDDL、AD）、SHAP 型特徵歸因漂移偵測、Clarify 作為訓練時分析器和生產時監控器的雙重角色、特定於偏差和特徵歸因監控的基準建立、整合到四監控統一違規報告模型，以及 MLA-C01 將測試的精確考試陷阱模式。然後介紹成熟 MLOps 團隊如何將所有四種監控類型接入統一再訓練管線，並以映射真實考試題幹模式的 FAQ 作結。

為何偏差和可解釋性需要持續監控

在訓練時稽核並認證公平的模型，不能保證在部署後保持公平。三種力量在生產中侵蝕公平性和可解釋性：輸入分佈偏移（與系統互動的人口結構改變）、標注反饋迴圈（模型的預測塑造了未來的訓練資料），以及特徵含義漂移（上游列的語義在沒有 schema 變更的情況下演變）。這些力量對傳統的準確率監控都是不可見的——模型可以在整體上保持準確，同時對受保護的子群體變得系統性不公平，因為整體準確率平均了傷害。

負責任 AI 的生產差距

部署前的公平性稽核是必要但不充分的。受監管的領域——信貸決策、招聘、保險、醫療分診、貸款——面臨稽核要求，要求提供持續公平性執行的證據，而非僅僅是時間點認證。SageMaker Model Monitor 偏差漂移透過對擷取的推論流量和真實標注執行排程 Clarify 處理任務、比較即時公平性指標與訓練時計算的基準，以及每當公平性偏離容差時發出 CloudWatch 指標，來填補這個空白。

為何特徵歸因漂移是微妙的孿生

模型可以保持準確、在設定的公平性指標上保持無偏差，但如果它產生預測的原因已改變，它仍然可能悄悄地損壞。一個最初將收入權重設為 40%、信用記錄設為 35% 的貸款審核模型，可能在生產中轉變為收入 70%、信用記錄 5%——相同的整體準確率，每個申請者的決策邏輯卻大相徑庭。基於 SHAP 的特徵歸因漂移透過比較基準和即時流量之間的每特徵重要性分佈來偵測這種偏移。監管背景（歐盟 AI 法案、美國公平貸款）越來越要求提供穩定模型推理的證據，而不僅僅是穩定的模型輸出。

白話文解釋偏差漂移與特徵歸因漂移

這兩種監控類型最好用具體類比來理解——「模型不公平嗎？」和「模型的理由穩定嗎？」之間的概念差異讓許多工程師困惑。三個類比讓結構更容易記憶。

類比一——招聘小組稽核

想像一家公司的招聘小組，面試並為工程職位的候選人打分。第一天，一名外部稽核員審查了 500 名歷史候選人的小組選擇，確認小組以相稱的比例錄用了男性和女性——建立了公平性基準。小組繼續面試了一年。偏差漂移監控是每季使用新的面試資料重新執行相同公平性稽核，並在男女錄用率偏離基準容差時發出標記的常設委員會。

500 名候選人的歷史稽核是 Clarify 在訓練時計算的偏差基準。每季執行的常設公平性委員會是偏差漂移監控排程。「按性別錄用率」公平性指標是 DPL（正標注比例差異）——Clarify 計算的偏差指標之一。當錄用率偏斜時開啟的調查是 CloudWatch 告警上的 bias_metric_DPL_<facet>。現在想像一個單獨的稽核員——特徵歸因漂移監控——讀取每個面試官的備注，統計小組在決策中實際使用了哪些因素（工作年限、大學、先前項目、溝通評分）。第一天，工作年限佔決策權重的 40%，大學佔 30%。一年後，歸因稽核員重新統計，發現工作年限現在佔 70%，大學佔 5%——按性別的錄用率相同，整體通過率相同，但小組現在以非常不同的理由做決策。這就是特徵歸因漂移，即使公平性指標看起來不錯，它也可以隱藏系統性傷害。

類比二——麵包店食譜穩定性稽核

想像一家銷售五種招牌麵包的麵包店。主廚的品質稽核員每季檢查兩件事。首先，偏差稽核員稱量每條麵包，確認黑麥麵包和酸麵包以麵包店承諾給顧客的比例生產——對產品線的公平性檢查。其次，食譜穩定性稽核員打開每條麵包，分析成分比例——麵粉、水、鹽、酵母——並檢查它們是否與記錄的食譜相符。重量正確且味道「還不錯」的麵包仍然可能在比例悄悄偏移時未通過食譜穩定性稽核。通過比例稽核但未通過食譜稽核的麵包店，正在以錯誤的理由生產外觀良好的麵包。

比例稽核是偏差漂移監控——檢查受保護群組的預測率是否保持在基準容差內。食譜稽核是特徵歸因漂移監控——檢查模型對每特徵的推理權重是否接近基準。主廚每日品嘗是模型品質監控——檢查麵包是否仍然好吃（準確率仍然跟蹤真實標注）。溫度和濕度日誌是資料品質監控——檢查輸入條件是否符合食譜的環境約束。所有四個監控器觀察相同生產系統的不同面向；共同形成完整的負責任 AI 監測面。禁用任何一個都會創造其他無法填補的盲點。

類比三——醫院分診系統稽核

想像一家區域醫院運行 ML 驅動的分診系統，對到達的患者按嚴重程度評分。醫院倫理委員會每月在兩個維度上稽核系統。公平性稽核檢查老年患者、兒童患者和殘疾患者是否以其實際嚴重程度成比例地被分診——沒有哪個群體被系統性地優先降低。推理稽核檢查分診模型是否仍然以原始驗證研究認證的比例權重生命體徵、主訴症狀和患者歷史。分診模型可以通過公平性稽核（每個群體都以正確比例被分診）但未通過推理稽核（現在它忽略生命體徵並過度加權年齡，即使年齡恰好與當前結果不相關，這是偶然原因）。推理失敗是更微妙的傷害——最終模型會開始犯公平性稽核無法捕捉的錯誤。

每月在擷取的分診資料上執行的公平性委員會是偏差漂移監控排程。在相同擷取上執行 SHAP 分析的推理委員會是特徵歸因漂移監控排程。當老年患者的分診結果漂移時開啟的事件是訂閱偏差漂移 CloudWatch 指標的 EventBridge 規則。當特徵推理偏移時發出的再訓練建議是由 CloudWatch 告警觸發的自動 SageMaker Pipeline。這個類比的每個部分都對應 MLA-C01 考試大綱的一個部分——尤其是，類比清楚地說明了公平性監控和推理監控是互補的，而非多餘的。

偏差漂移監控——機制與指標

偏差漂移監控是四種 Model Monitor 類型中的第三種。它按排程對擷取的推論流量加上真實標注執行 Clarify 處理任務，並計算群組層面的公平性指標。

偏差漂移偵測什麼

訓練時基準和生產時擷取之間群組層面公平性指標的漂移。「面向」（facet）是受保護屬性（性別、年齡段、族裔代碼、地理區域），偏差指標量化預測和結果如何在面向群組之間不同。漂移意味著公平性指標的值從其基準超出了設定的門檻。

Clarify 計算的偏差指標

Clarify 支援涵蓋訓練前、訓練後和部署後偏差的記錄指標目錄。MLA-C01 中最常測試的：

• DPL（正標注比例差異）——僅訓練前；標注資料集中群組之間正類別比例的差異。
• DI（差異影響）——群組之間正預測率的比率；低於 0.8 是美國法規五分之四規則門檻。
• CDDL（標注中的條件人口差異）——衡量在控制混淆變數後不平衡是否持續。
• AD（準確率差異）——訓練後；跨群組的準確率差異。
• DPPL（預測標注中的正比例差異）——訓練後；DPL 的類比但基於模型預測。
• TE（處理平等）——跨群組的假負例與假正例的比率。

偏差漂移監控執行訓練後和部署後指標——DPPL、DI、AD、RD（召回率差異）、CDDPL、TE、FT（翻轉測試）。DPL 等訓練前指標在任何模型存在之前就對資料集執行，是訓練時 Clarify 的使用案例，而非 Model Monitor 類型。

設定偏差漂移監控

需要三個產出物：偏差設定，描述面向（哪一列是受保護屬性、哪個值定義了特權群組、哪個值定義了弱勢群組）；模型設定，描述其預測被評分的 SageMaker 模型；以及透過在訓練時對標注訓練資料執行 Clarify 計算的偏差基準。監控排程使用 Python SDK 中的 ModelBiasMonitor 建立，指向擷取的推論資料和真實標注。

真實標注依賴

偏差漂移監控與模型品質監控一樣，需要真實標注來計算群組層面的結果指標。預測到達擷取流；真實標注從下游系統稍後到達；合併任務在 inferenceId 上連接它們。沒有真實標注引入，依賴實際結果的指標（AD、RD、TE）無法計算。只依賴預測的指標（DPPL、DI）可以在沒有真實標注的情況下執行——但對公平性認真的部署需要兩半部分。

特徵歸因漂移監控——機制與 SHAP

特徵歸因漂移是第四種 Model Monitor 類型。它按排程對擷取的推論流量執行 Clarify SHAP 分析，並比較每特徵 SHAP 值分佈與基準。

特徵歸因漂移偵測什麼

基準和當前流量之間每特徵 SHAP 值分佈的漂移。SHAP 值量化每個特徵對每個個別預測的貢獻多少。許多預測中每特徵 SHAP 值的聚合分佈描述了模型如何推理。當該分佈偏移時，模型以與基準說應該的不同的理由做決策。

SHAP 計算在 SageMaker 中如何工作

SHAP（SHapley Additive exPlanations）值由 Clarify 使用 KernelSHAP 演算法計算——對於每個預測，它抽樣特徵的組合，評估每個組合的模型，並將預測分解為加總到模型輸出減去基準（通常是資料集均值）的每特徵貢獻。KernelSHAP 是模型無關的但計算昂貴；對於監控，Clarify 在每個排程時鐘週期對擷取流量的取樣子集執行它。

為何特徵歸因漂移在運維上很重要

模型可以通過準確率監控（預測仍然在整體上與真實標注匹配）和通過偏差監控（群組層面公平性指標仍在容差內），但如果其推理已偏移，仍然可能悄悄損壞。典型例子：一個信用違約模型最初以大約 35-40-25 的比例權重信用使用率、還款歷史和信用組合；在生產中，比例偏移為 60-30-10，因為生產資料具有比訓練資料更高的使用率變異。整體準確率和群組層面公平性都可能看起來不錯，而模型現在以在邊緣情況下最終會產生系統性偏差決策的方式過度加權一個特徵。

設定特徵歸因漂移監控

需要三個產出物：描述 SHAP 計算方式的可解釋性設定（樣本數量、用作參考分佈的基準行）、描述模型的模型設定，以及在訓練時計算的可解釋性基準。監控排程使用 Python SDK 中的 ModelExplainabilityMonitor 建立。與偏差漂移不同，特徵歸因漂移不需要真實標注——SHAP 值只從輸入和預測計算。

每特徵漂移報告

違規報告按漂移大小對特徵排名。偏移最大的特徵排在第一位；超過門檻的特徵觸發名稱如 feature_attribution_drift_<feature_name> 的 CloudWatch 指標。指標是每特徵的單一標量，代表基準和當前 SHAP 分佈之間的分佈距離（通常是 Jensen-Shannon 散度）。

SageMaker Clarify 有兩種生命——訓練時和生產時

Clarify 和 Model Monitor 之間的邊界是 MLA-C01 Domain 4 中測試最頻繁的概念。

訓練時的 Clarify

訓練時 Clarify 在模型開發期間作為一次性 SageMaker Processing 任務執行。它產出：

• 訓練前偏差報告——DPL、KL 散度、KS、CDDL、JS 散度對標注訓練資料集。在任何模型存在之前計算；識別資料集不平衡。
• 訓練後偏差報告——DPPL、DI、AD、RD、CDDPL、TE 對訓練模型在保留驗證資料上的預測。訓練後計算；在部署前認證訓練的模型公平。
• 可解釋性報告——全局 SHAP 特徵重要性和每預測本地 SHAP。記錄模型依賴哪些特徵。

這三個報告透過一次執行帶有適當設定的 clarify.processor() 產生。輸出儲存在 S3 並在 SageMaker Studio 的 Clarify 面板中呈現。

生產時的 Clarify——透過 Model Monitor

生產時 Clarify 透過偏差漂移或特徵歸因漂移類型的 SageMaker Model Monitor 排程間接呼叫。使用者建立 ModelBiasMonitor 或 ModelExplainabilityMonitor 排程；SageMaker 按 cron 節奏產生 Clarify 處理任務；結果寫入 S3 和 CloudWatch。在這個路徑中，使用者不直接呼叫 Clarify——Model Monitor 排程它。

為何這個區別在考試中很重要

MLA-C01 考試題幹將描述一個場景並詢問使用哪個服務或監控類型。決策樹：

• 「在訓練前稽核資料集的類別不平衡」→ 訓練時 Clarify 訓練前偏差。
• 「在部署前為稽核委員會產生訓練模型的公平性報告」→ 訓練時 Clarify 訓練後偏差。
• 「隨著生產流量演變持續驗證已部署的模型保持公平」→ Model Monitor 偏差漂移類型。
• 「持續驗證已部署的模型的推理保持穩定」→ Model Monitor 特徵歸因漂移類型。
• 「在推論時即時為個別預測產生 SHAP 特徵重要性」→ SageMaker Clarify 線上可解釋性（一個單獨的推論時 Clarify 能力）。

偏差和特徵歸因監控的基準建立

偏差漂移和特徵歸因漂移基準不同於資料品質和模型品質基準。每種監控類型有自己的基準產出物。

偏差基準

透過對帶偏差設定（面向、標注列、群組定義）的標注訓練資料執行 ClarifyBiasMonitor.suggest_baseline()（或帶有 Clarify 偏差容器映像的底層 CreateProcessingJob）建立。輸出：描述每指標基準值的 bias_baseline.json 文件。排程引用這個文件來確定漂移門檻。

特徵歸因基準

透過對帶可解釋性設定（SHAP 樣本數、用作參考分佈的基準行）的訓練資料執行 ClarifyExplainabilityMonitor.suggest_baseline() 建立。輸出：描述訓練時每特徵 SHAP 值分佈的 explainability_baseline.json 文件。排程引用這個文件來計算漂移。

為何基準在重新訓練後必須重新產生

與資料品質基準一樣，偏差和特徵歸因基準都綁定到特定的訓練模型和特定的訓練資料集。在重新訓練的模型上重用舊基準會產生無意義的漂移信號——新模型的 SHAP 分佈與舊模型不同，但這種差異在運維意義上不是「漂移」。每次重新訓練都必須從新訓練資料和新模型重新產生所有四個基準（資料品質、模型品質、偏差、特徵歸因）。

運維模式

在訓練步驟成功後、監控排程更新步驟之前，將基準重新產生嵌入 SageMaker Pipeline 作為步驟。每個步驟將其基準 JSON 寫入與模型版本綁定的版本化 S3 前綴。監控排程透過 update_monitoring_schedule() 更新，指向新的基準位置。這種模式確保基準始終與已部署的模型版本同步，也是考試偏好的設計模式。

結合所有四種監控器——統一違規報告

成熟的 MLOps 部署同時執行所有四種 Model Monitor 類型，並將其信號聚合到統一的可觀測層。

統一 CloudWatch 儀表板

每種監控類型在可預測的命名空間下發布指標。統一的 CloudWatch 儀表板呈現：

• 資料品質面板——每個監控特徵的 feature_baseline_drift_<feature>。
• 模型品質面板——準確率、AUC、F1 的 model_metric_<metric>。
• 偏差漂移面板——每個面向的 bias_metric_DPPL_<facet>、bias_metric_DI_<facet>、bias_metric_AD_<facet>。
• 特徵歸因漂移面板——每特徵的 feature_attribution_drift_<feature>。

將儀表板與告警矩陣配對：每個面板至少有一個帶有適當嚴重性路由到 PagerDuty 或 SNS 的 CloudWatch 告警。

將違規類型對應到修復行動

不同的違規需要不同的回應：

• 單獨的資料品質違規——調查上游管線；可能是良性季節性偏移或合法的引入錯誤。
• 單獨的模型品質退化——可能是概念漂移；觸發再訓練。
• 單獨的偏差漂移違規——公平性回歸；停止部署，調查原因，用重新平衡的資料或去偏差技術重新訓練。
• 單獨的特徵歸因漂移——沒有準確率損失的推理偏移；需要更深入的調查，可能對上游特徵語義進行根本原因分析。
• 資料品質 + 模型品質組合——明確的再訓練觸發器；輸入分佈改變，模型無法跟上。
• 偏差漂移 + 模型品質組合——有準確率代價的公平性回歸；高優先級帶偏差緩解的再訓練。

再訓練觸發器——將違規對應到管線

EventBridge 規則訂閱 CloudWatch 告警狀態變更。每個規則路由到特定的 Lambda 或 Step Functions 修復。修復編排啟動 SageMaker Pipeline，重新產生基準，重新訓練模型，針對偏差和可解釋性約束驗證新模型，以適當的審核狀態在 Model Registry 中登記，並透過藍/綠策略條件部署。完整的負責任 AI 迴圈——偵測漂移、重新訓練、重新驗證、重新部署——是 MLA-C01 期望的 MLOps 成熟度標準。

SageMaker Clarify 作為雙重角色服務——摘要表

這個表是 MLA-C01 Domain 4 複習中最有用的單一產出物。把它燒入記憶。

MLA-C01 偏差和歸因漂移常見考試陷阱

陷阱一——Clarify 取代生產公平性的 Model Monitor

錯誤。Clarify 透過 Model Monitor 排程呼叫用於部署後監控。單獨的 Clarify 是一次性訓練時分析。考試題幹將「持續」或「排程」與「公平性」配對——選 Model Monitor 偏差漂移，而非 Clarify。

陷阱二——偏差漂移偵測所有公平性問題

部分錯誤。偏差漂移偵測公平性指標從基準的移動。在部署時不公平且保持不公平的模型不會觸發漂移——基準已經編碼了不公平性。部署前 Clarify 訓練後偏差是認證基準本身公平所必需的。偏差漂移是維護工具，而非認證工具。

陷阱三——特徵歸因漂移需要真實標注

錯誤。SHAP 值從輸入和預測計算；真實標注不需要。特徵歸因漂移可以在沒有真實標注管線的情況下執行。相反，偏差漂移對結果指標（AD、RD）通常確實需要真實標注。

陷阱四——DPL 和 DPPL 是相同的指標

錯誤。DPL 是訓練前的——在任何模型存在之前對標注訓練資料集測量。DPPL 是訓練後的——對模型的預測測量。相同的概念結構，不同的階段。考試測試這個區別。

陷阱五——四種監控類型都使用相同的容器

錯誤。資料品質和模型品質監控使用內建的 Model Monitor 容器。偏差漂移和特徵歸因漂移在內部使用 Clarify 處理容器。使用者面 API 透過 Model Monitor 排程統一，但工作人員不同。

陷阱六——重新訓練後重用舊偏差基準

錯誤。與資料品質基準一樣，偏差基準在每次重新訓練後必須從新訓練資料重新產生。否則漂移信號是無意義的。

陷阱七——差異影響門檻按使用案例可設定

部分正確但有注意事項。DI 的行業標準門檻是五分之四規則（DI < 0.8 根據美國 EEOC 指導表示差異影響）。Clarify 讓你設定自己的門檻，但在受監管的貸款題幹上回答「我們將 DI 門檻設為 0.5」將是錯的，因為監管要求將門檻固定在 0.8。

陷阱八——偏差漂移監控取代手動公平性審查

錯誤。偏差漂移是偵測層；修復需要人工迴圈調查、根本原因分析，以及可能使用去偏差技術的重新訓練。將偏差漂移視為自動修復是過度設計的錯誤模式。

陷阱九——特徵歸因漂移偵測概念漂移

錯誤。特徵歸因漂移偵測模型對特徵的依賴偏移；概念漂移是特徵和標注之間關係的偏移。它們可能同時發生但在概念上不同。概念漂移出現在模型品質監控中（預測偏離真實標注）；歸因漂移出現在特徵歸因漂移監控中（SHAP 分佈偏移）。仔細閱讀題幹以獲得精確的症狀。

陷阱十——偏差漂移和特徵歸因漂移可以在沒有資料擷取的情況下執行

錯誤。兩者都需要端點上擷取的推論流量，就像資料品質和模型品質監控一樣。對於任何監控類型在即時端點上運行，都必須在端點設定上啟用資料擷取。

必記數字與重要事實

監控類型（全部四種）

• 資料品質、模型品質、偏差漂移、特徵歸因漂移
• 前兩種在 Model Monitor 容器上；後兩種在 Clarify 上
• 每種都需要自己的基準；基準在每次重新訓練後必須重新產生

偏差指標

• 訓練前：DPL、KL、KS、CDDL（僅由訓練時 Clarify 計算）
• 訓練後：DPPL、DI、AD、RD、CDDPL、TE、FT
• 偏差漂移監控使用訓練後和部署後指標
• 受監管工作負載的 DI 五分之四規則門檻是 0.8

特徵歸因

• 透過 Clarify 中的 KernelSHAP 演算法進行 SHAP
• 透過基準和當前分佈之間的 Jensen-Shannon 散度測量漂移
• 每特徵 CloudWatch 指標命名為 feature_attribution_drift_<feature>
• 不需要真實標注

Clarify 雙重角色

• 訓練時：一次性訓練前和訓練後偏差加 SHAP
• 生產時：透過 Model Monitor 偏差漂移和特徵歸因漂移排程呼叫
• 線上可解釋性：推論時每請求即時 SHAP（單獨的推論時能力）

排程設定

• ModelBiasMonitor 和 ModelExplainabilityMonitor SDK 類別
• cron 驅動；預設每小時或每日
• 輸出落在 S3 加上 SageMaker 命名空間下的 CloudWatch 指標

FAQ——偏差和歸因漂移熱門考試問題

Q1——一家受監管的貸款機構部署了信貸決策模型。合規團隊希望確保模型在部署的整個生命週期內對受保護群組保持公平。哪個 AWS 服務是答案？

SageMaker Model Monitor 帶有偏差漂移監控類型，每日或每週排程，讀取擷取的推論流量加上真實信貸申請結果，計算部署後偏差指標（DPPL、DI、AD、RD），並發出 CloudWatch 指標，告警接入合規審查流程。部署前認證用訓練時 Clarify 訓練後偏差分析完成；持續執行是 Model Monitor 偏差漂移。單獨選「Clarify」意味著一次性稽核，不符合「在部署的整個生命週期內」的標準。

Q2——模型通過了準確率監控和偏差漂移監控，但稽核委員會希望有模型推理沒有悄悄偏移的證據。需要什麼額外的監控？

特徵歸因漂移監控。基於 SHAP 的每特徵歸因分佈在訓練時基準和即時擷取之間進行比較。當某個特徵的重要性偏離門檻時，CloudWatch 告警觸發。這獨立於準確率（模型品質）和獨立於公平性（偏差漂移）；模型可以通過兩者但仍未通過特徵歸因漂移。對於要求穩定模型推理證據的監管背景——歐盟 AI 法案高風險系統、美國公平貸款——這是負責任 AI 監控面的第四個支柱。

Q3——團隊設定了偏差漂移監控，但每次監控執行都報告零違規，即使生產人口結構明顯已偏移。什麼出了問題？

三個可能的原因。首先，偏差設定的面向定義可能與生產擷取中的實際人口列不匹配——精確驗證面向名稱和群組值完全匹配擷取 schema。其次，偏差基準從已包含生產人口結構的訓練資料產生，因此團隊認為的「新漂移」實際上在基準容差內——從刻意平衡的參考資料集重新產生基準。第三，設定的漂移門檻過寬——審查 bias_baseline.json 並收緊每指標容差值。並排讀取違規文件和基準文件後再下結論。

Q4——SageMaker Clarify 線上可解釋性與特徵歸因漂移監控有何不同？

Clarify 線上可解釋性在推論時對每請求執行 SHAP——端點返回預測加上那個單一預測的每特徵 SHAP 值。有助於向終端用戶解釋個別決策或用於監管披露。特徵歸因漂移監控按排程對許多擷取的預測執行 SHAP，並隨時間追蹤分佈偏移。前者是每預測解釋；後者是聚合推理監控。它們服務於不同的運維需求——線上可解釋性支援面向用戶應用程式中的模型可解釋性功能；歸因漂移支援 MLOps 可觀測性。

Q5——正在設計新的訓練管線。在管線的哪個位置應產生所有四種監控類型的基準？

在訓練步驟成功後、在 Model Registry 中將模型登記為 Approved 之前。標準 SageMaker Pipeline 結構：Data Wrangler 步驟 → Processing 步驟 → Training 步驟 → 基準建立步驟（資料品質、模型品質、偏差、特徵歸因——四個並行處理任務） → Evaluation 步驟 → 條件 ApproveModel 步驟 → Update-monitoring-schedules 步驟 → Deploy 步驟。每個步驟將其基準 JSON 寫入與模型版本綁定的版本化 S3 前綴。監控排程透過 update_monitoring_schedule() 更新，引用新的基準位置。這種模式確保基準始終與已部署的模型版本同步，也是考試偏好的設計模式。

Q6——訓練時 Clarify 訓練前偏差何時有意義，相比偏差漂移監控？

訓練前 Clarify 在任何模型訓練之前對標注訓練資料集執行一次。它偵測資料集層面的不平衡——資料集本身是不公平的——獨立於任何模型。輸出指導資料收集或取樣決策。偏差漂移監控持續對擷取的生產流量執行，偵測已部署模型預測的公平性指標何時偏離基準。它們回答不同的問題：訓練前 Clarify 說「我的資料公平嗎？」，偏差漂移監控說「已部署模型的公平性行為是否已改變？」在成熟的負責任 AI 管線中兩者都需要。

Q7——團隊正在執行詐騙偵測模型。詐騙標注的真實標注在推論後 60 天才到達（確認拒付時）。偏差漂移監控仍然可以執行嗎？

部分可以。只依賴預測的偏差指標——DPPL、DI——可以立即對擷取的預測資料執行。依賴實際結果的指標——AD、RD、TE——必須等待真實標注並在 inferenceId 上與預測合併。設定排程以與 60 天延遲的真實標注資料饋送合併；今天的監控執行合併 60 天前的預測與今天的標注。第一個 AD/RD 信號在部署後 60 天落地。DPPL/DI 信號立即落地。在設計告警接線時考慮這個延遲，並向合規團隊記錄基於結果的偏差指標有固有的 60 天評估延遲。

延伸閱讀——官方 AWS 文件

權威的 AWS 來源是 SageMaker Clarify 開發人員指南（公平性、可解釋性、訓練前和訓練後偏差）、SageMaker Model Monitor 開發人員指南（偏差漂移和特徵歸因漂移部分）、AWS 負責任 AI 政策白皮書，以及用於編排基準重新產生和排程更新的 SageMaker Pipelines 開發人員指南。MLA-C01 官方考試指南和 Tutorials Dojo MLA-C01 學習路徑強化了主導 Domain 4 問題的 Clarify 對 Model Monitor 邊界。