模型評估 — SageMaker Debugger、Clarify 與 Experiments

SageMaker 上的模型評估是在模型被允許離開訓練環境前回答三個問題的紀律：準確度是否夠好、訓練是否健康（沒有梯度問題、過擬合、偏差結果），以及可解釋性是否足夠讓利害關係人信任。在 MLA-C01 考試上，模型評估是 Domain 2（ML 模型開發，佔 26%）Task 2.3（分析模型效能）的核心考點。這是工程考試，不是統計考試——題目幾乎從不問「推導 F1 公式」，幾乎都問「給定訓練期間的症狀，哪個 SageMaker 工具揭示根本原因」或「哪個 Clarify metric 量化不平等影響」。

本指南從 ML Engineer 視角出發。涵蓋考試期望你在四種分類 metric（accuracy、precision、recall、F1、AUC-ROC）和三種回歸 metric（RMSE、MAE、R²）之間做出選擇、在訓練中即時捕捉訓練病理而不需要程式碼變更的 SageMaker Debugger 系統、處理訓練前和訓練後偏差加上 SHAP 可解釋性的 SageMaker Clarify 服務、追蹤每個訓練跑及 lineage 與比較視圖的 SageMaker Experiments 服務，以及在模型進入 Model Registry 前記錄預期用途和限制的 model card 紀律。同時涵蓋此考試中最常被社群引用的痛點——Debugger vs Model Monitor 和 Clarify vs Model Monitor 的區分——Debugger 和 Clarify 是訓練時工具（Domain 2），Model Monitor 是部署後工具（Domain 4），考試反覆出這個混淆考點。

MLA-C01 脈絡中的模型評估是什麼

MLA-C01 的模型評估涵蓋「訓練完成」到「模型已註冊待部署核准」之間的生命週期階段。它不只是 metric 計算——還包括捕捉訓練病理（Debugger）、測量公平性和可解釋性（Clarify）、追蹤實驗和可重現性（Experiments），以及記錄模型以利治理（Model Card）。社群訊號一致：來自資料科學背景的考生在 metric 公式上過度準備，在操作工具上準備不足；來自 DevOps 背景的考生低估了 Clarify 的考試深度。

為何評估是大多數生產失敗的源頭

達到 95% 訓練準確度的模型仍可能在生產中失敗，如果（1）訓練 loss 有你沒有捕捉到的梯度問題、（2）模型對受保護族群有偏差、（3）類似輸入的特徵歸因不穩定，或（4）六個月後需要重訓時團隊無法重現訓練跑。這些失敗模式每一個都有專門的 SageMaker 工具在部署前偵測它。MLA-C01 考試測試哪個工具捕捉哪種失敗模式。

MLA-C01 模型評估涵蓋的五個工具

完整的評估堆疊使用五個 SageMaker 工具。SageMaker Debugger 擷取訓練 tensor 並應用內建規則在訓練期間偵測異常（梯度消失、過擬合、權重初始化不良）。SageMaker Debugger Insights 剖析 CPU/GPU 使用率和 IO 瓶頸。SageMaker Clarify 計算訓練前和訓練後偏差 metric，以及 SHAP 可解釋性。SageMaker Experiments 追蹤跨迭代的跑、超參數、metric 和 artifact lineage。SageMaker Model Card 記錄模型的預期用途、評估結果和已知限制以供治理審查。每個工具都有明確的用途，考試測試哪個工具回答哪個情境。

白話文解釋 Model Evaluation Tools

模型評估的五工具堆疊用具體類比能很快內化。

類比一 — 製造業的品管產線

想像汽車裝配線。SageMaker Debugger 是焊接機械手臂上的內嵌感測器陣列——監測每個焊點的扭力、角度，在不良焊點發生的當下抓出來，避免半完成的車身繼續往前推。SageMaker Clarify 是裝配後的公平性稽核——這條產線早班和晚班、不同零件廠批次的成品品質有沒有顯著差異？SageMaker Experiments 是生產日誌——每一輪每個班次的設定、產出 metric、瑕疵率都記錄下來供回溯比較。SageMaker Model Cards 是車輛使用手冊——記錄這台車的用途、測試極限、已知的失效模式。

類比二 — 醫院診斷套件

把訓練模型當成醫院引進新的診斷檢測。Debugger 是檢測過程中的即時監測（生命徵象、儀器讀值異常即時警示）。Clarify 是族群公平性審查——這個檢測對每個病患子群是否同樣有效？Experiments 是臨床試驗追蹤系統——每一群、每一劑、每個結果都記錄。Model Cards 是 FDA 送審文件，列明適用族群、禁忌症與已知限制。每個角色職責明確，混用結果就是檢測未通過真實場域。

類比三 — 餐廳廚房

高級餐廳推 tasting menu 也對得上：Debugger 是主廚煮菜過程中的試味——醬汁過鹹當下發現，菜還沒上桌就重做。Clarify 是顧客回饋的公平性審查——某些族群滿意度是否顯著不同？Experiments 是配方測試簿，每個版本每次結果都記。Model Cards 是菜單描述，提醒過敏原和食材。每個角色職責清晰，混淆會在外場出包。

分類 Metric — 選擇正確的 Objective

分類 metric 的選擇取決於假陽性 vs 假陰性的成本，加上類別平衡。考試會出選錯 metric 就是錯誤答案的情境。

Accuracy 及其何時誤導

Accuracy = (TP + TN) / (TP + TN + FP + FN)——所有預測中正確的比例。直覺但在不平衡類別上會誤導。0.1% 交易是詐欺的詐欺偵測模型，對所有交易都預測「非詐欺」可達到 99.9% accuracy——沒有用。Accuracy 掩蓋了失敗。對不平衡類別，accuracy 是錯誤的選擇。

Precision、Recall 和 F1 的折衷

Precision = TP / (TP + FP)——在我標記為正的項目中，實際是正的有幾個。Recall = TP / (TP + FN)——在所有實際的正樣本中，我捕捉到幾個。Precision 在假陽性代價高時重要（合法交易被擋、健康病患接受治療）。Recall 在假陰性代價高時重要（詐欺未被抓、癌症漏診）。F1 = 2 * (P * R) / (P + R) 是調和平均——在你需要兩者兼顧時有用，特別是在不平衡類別上。考試問「哪個 metric 用於垃圾郵件過濾」——通常是 precision（假陽性是使用者可見的正常信件被擋，代價高），或「哪個 metric 用於癌症篩檢」——通常是 recall（漏診癌症是災難性的）。

AUC-ROC 和 AUC-PR

AUC-ROC 測量 receiver operating characteristic 曲線下的面積——跨閾值的真陽性率 vs 假陽性率的取捨。AUC-ROC 0.5 是隨機猜測；1.0 是完美。它不依賴閾值——在部署閾值尚未決定時有用。AUC-PR（precision-recall AUC）對非常不平衡的資料更好，因為 ROC 在負樣本佔主導時可能過於樂觀。

混淆矩陣閱讀

混淆矩陣按類別分解預測。對二元分類器，四個格子：TP、FP、TN、FN。多類別擴展為方形矩陣。考試可能顯示混淆矩陣並問「模型錯在哪」——閱讀非對角線的格子；較大的值表示哪些類別與哪些類別混淆。

回歸 Metric — 當預測是連續值時

回歸評估有其自己的 metric 集合，對離群值和尺度有不同的敏感度。

RMSE — 均方根誤差

RMSE = sqrt(mean((y_pred - y_actual)^2))。平方誤差對大錯誤懲罰重。RMSE 與目標的單位相同，使其可解釋。當大誤差代價不成比例地高時使用 RMSE（例如，預測電池壽命——差 10 小時比差 1 小時兩次糟糕得多）。

MAE — 平均絕對誤差

MAE = mean(abs(y_pred - y_actual))。無論誤差大小線性懲罰。MAE 比 RMSE 對離群值更穩健——單一大預測誤差不會主導 metric。當你關心典型誤差且資料有離群值時使用 MAE。

R² — 解釋變異量

R²（決定係數）= 1 - (SS_res / SS_tot)。測量模型解釋的目標變異比例。R² 1.0 是完美，0.0 不比預測平均值好，負值比預測平均值更差。對在相同資料集上比較模型有用，但 R² 在訓練資料上加入特徵會人為膨脹時可能誤導。

MAPE — 平均絕對百分比誤差

MAPE = mean(abs((y_actual - y_pred) / y_actual)) * 100。當相對誤差比絕對誤差更重要時有用（規模化的需求預測）。當實際值可能為零或接近零時崩潰。

SageMaker Debugger — 捕捉訓練病理

Debugger 是訓練工作的執行時監控層。它擷取訓練內部狀態——權重、梯度、激活值、loss——並應用規則在訓練仍在進行時偵測問題。

Debugger 擷取什麼

Debugger 鉤入訓練框架（PyTorch、TensorFlow、MXNet、XGBoost）並以可設定的頻率將 tensor 資料儲存到 S3。這些鉤子是非侵入性的——大多數工作負載不需要程式碼變更；鉤子由 SageMaker 訓練容器注入。擷取的資料包括權重、偏差、梯度、激活值、optimizer state、loss 和自訂集合。

內建規則 — 18 個開箱即用的偵測器

SageMaker Debugger 提供 18 個以上涵蓋常見訓練病理的內建規則。例子包括 vanishing_gradient（深層梯度接近零）、exploding_tensor（任何 tensor 中有 NaN 或 Inf）、loss_not_decreasing（訓練卡住）、overfit（驗證 loss 偏離訓練 loss）、poor_weight_initialization（權重分佈表明初始化不良）、class_imbalance（訓練資料嚴重偏斜）、dead_relu（大比例的 ReLU 輸出為零），以及 saturated_activation（sigmoid/tanh 輸出在極端值）。每個規則在違反時發出 CloudWatch 事件；事件可觸發 Lambda 動作或停止訓練工作。

Debugger Insights — 硬體效能剖析

Debugger Insights 把規則系統擴展到系統層級 metric——CPU 使用率、GPU 使用率、GPU 記憶體使用量、IO 吞吐量、網路頻寬。Insights 在工作完成時產生詳細的效能剖析報告，識別瓶頸：低 GPU 使用率表明 IO 或 CPU 預處理使 GPU 挨餓；高 CPU 和低 GPU 表明資料 pipeline 是阻塞點；高 IO 等待時間表明 S3 讀取緩慢。Insights 回答「為何我的訓練慢」的問題，不需要手動儀器化。

Debugger 輸出 — Tensor 儲存模式

擷取的 tensor 儲存到設定的 S3 路徑。預設模式在每個步驟開始時儲存（IO 成本高）——生產設定限制只擷取特定 tensor 和較低頻率。Trial component（訓練期間 tensor 的序列）是分析單元；SMDebug Python 函式庫讀取 trial 並支援自訂規則開發。

自訂規則

除了內建規則，工程師可以用 SMDebug SDK 用 Python 撰寫自訂規則。自訂規則繼承 Rule、實作 invoke_at_step，並在違反條件滿足時回傳 True。自訂規則部署為與訓練工作並行執行的獨立 processing 容器。使用場景：領域特定的異常偵測（例如「loss 平坦 100 步然後飆升」的模式）、自訂業務 metric 監控、與非標準框架的整合。

SageMaker Clarify — 偏差與可解釋性

Clarify 是合而為一的兩個截然不同服務——偏差測量（公平性）和 SHAP 可解釋性——兩者都作為 SageMaker Processing 工作執行，都產生結構化報告。

訓練前偏差 Metric

訓練前偏差 metric 在任何模型被擬合之前分析訓練資料集。常見 metric 包括：

• CI（Class Imbalance）— 優勢和弱勢群體大小之差。
• DPL（Difference in Proportions of Labels）— 跨群體的正標籤比例之差。
• KL（Kullback-Leibler Divergence）— 群體間的分佈散度。
• JS（Jensen-Shannon Divergence）— KL 的對稱變體。
• LP（Lp norm）— 分佈之間的一般距離 metric。
• TVD（Total Variation Distance）— 累積分佈間的最大差值。
• KS（Kolmogorov-Smirnov）— 群體間最大 CDF 差值。
• CDDL（Conditional Demographic Disparity in Labels）— 子群體條件差距。

訓練前偏差訊號表示無論訓練演算法如何都會偏差模型的問題——修資料，不是模型。

訓練後偏差 Metric

訓練後偏差測量模型預測的公平性，而非只是標籤。關鍵 metric：

• DPPL（Difference in Positive Proportions of Predicted Labels）— 預測的 DPL。
• DI（Disparate Impact）— 群體間正預測率的比率；低於 0.8 違反五分之四規則。
• DCO（Difference in Conditional Outcomes）— 子群體條件結果差異。
• AD（Accuracy Difference）— 跨群體的 accuracy 差異。
• RD（Recall Difference）— 跨群體的 recall 差異。
• CDDPL（Conditional Demographic Disparity in Predicted Labels）— 預測中的子群體條件差距。

訓練後偏差表示模型本身（不只是資料）在產生不公平的結果。

SHAP 可解釋性

Clarify 計算 Shapley 值——每個特徵對預測貢獻的賽局理論歸因。兩個視角：

• 全域特徵重要性 — 資料集整體的平均絕對 SHAP 值；告訴你模型整體依賴哪些特徵。
• 局部解釋 — 單一預測的 SHAP 值；告訴你為何這個特定輸入得到這個特定輸出。

SHAP 是模型無關的——適用於樹模型、深度網路和整合方法。Clarify 透過 Kernel SHAP（模型無關，較慢）或 TreeSHAP（僅樹模型，快得多）計算 SHAP。

Clarify Processing 工作機制

Clarify 以帶有特殊 Clarify 容器的 SageMaker Processing 工作執行。工作接受指定資料集、標籤欄位、敏感屬性（偏差分析的受保護族群）、預測欄位或模型 endpoint，以及要計算的 metric 的設定 JSON。輸出是 JSON 報告加上 SageMaker Studio UI 中的視覺化。

SageMaker Experiments — 追蹤跑與 Lineage

Experiments 把訓練跑組織成層次結構，追蹤每個參數、metric 和 artifact 以供可重現性和比較。

Experiment 層次結構

資料模型有三個層次。Experiment 是頂層容器——通常對應一個業務問題（例如「fraud-detection-v2」）。Run（前身是「trial」）是 experiment 內的一次執行——一組超參數。Run component 是組成一個 run 的個別訓練、processing 和評估工作。這個層次結構讓工程師比較 experiment 內的多個超參數設定，以及在 experiment 之間比較。

Experiments 追蹤什麼

每個 run 追蹤：提供給訓練的超參數、訓練期間發出的 metric（通常從 CloudWatch 拉取）、產生的 artifact（模型檔案、評估輸出）、使用的輸入資料集、容器映像和時間。Lineage 是自動的——當 SageMaker Pipeline 執行一系列訓練工作時，每個都成為帶有明確上游依賴記錄的 run component。

Studio 中的比較視圖

SageMaker Studio 的 Experiments 視圖支援並排比較：選取多個 run、在 parallel coordinates 圖表中看超參數、重疊比較訓練/驗證曲線、並排查看混淆矩陣。這是分析師從 HPO 掃描中挑選最佳設定的主要工具。

與 HPO 和 Pipelines 的整合

Automatic Model Tuning（AMT）工作自動填充 Experiments——超參數掃描中的每個試是一個 run。SageMaker Pipelines 執行同樣填充 run 和 run component，提供從原始資料到模型註冊的完整稽核軌跡。

透過 Lineage 追蹤實現可重現性

SageMaker ML Lineage Tracking 是底層 lineage 圖。給定一個已部署模型，你可以追溯到產生它的 run、使用的超參數、資料集版本、預處理工作、原始 S3 來源。這個稽核軌跡對受管制行業和調查生產模型表現不佳的事件至關重要。

SageMaker Model Card — 治理文件

Model card 是隨模型進入 Model Registry 的結構化文件，涵蓋預期用途、限制、訓練資料、評估結果和倫理考量。

標準 Model Card 各節

標準 SageMaker Model Card 包括：模型概覽（架構、輸入/輸出 schema）、預期用途（業務目的、目標使用者）、訓練細節（演算法、超參數、資料集）、評估結果（metric、混淆矩陣、Clarify 的公平性測量）、已知限制（失敗模式、邊緣案例）、倫理考量，以及其他資訊。

為何 Model Card 在 MLA-C01 很重要

Model card 彌合技術 artifact 和治理審查之間的差距。風險長或法規遵循稽核員無法閱讀 Jupyter notebook；他們可以閱讀 model card。卡片隨 model package 一起存在 Model Registry 中，所以部署核准可以參考文件記載的限制和評估結果，而不需要深入原始碼。

從 Clarify 和 Experiments 自動填充

Model card 可以從 Clarify 報告拉取評估結果，以及從 Experiments run 拉取 metric，減少手動文件工作。整合並非完全自動——工程師仍需撰寫散文段落——但表格評估資料從現有追蹤系統填充。

Debugger vs Model Monitor — 最常考的區分

這是 MLA-C01 考試上最高頻的混淆。把這個區分內化。

Debugger 在 Domain 2（模型開發）

Debugger 即時監控訓練工作。它的規則查看訓練內部狀態——梯度、激活值、loss、硬體使用率——在訓練跑期間捕捉病理。Debugger 輸出在模型被註冊之前消化。如果 Debugger 觸發 loss_not_decreasing，你停止訓練工作並重新調優。

Model Monitor 在 Domain 4（監控/維護）

Model Monitor 監控生產中已部署的 endpoint。它的 monitor 查看生產資料——請求 payload、預測輸出、稍後到達的 ground truth 標籤——以偵測隨時間的漂移。Model Monitor 輸出在模型上線後消化。如果 Model Monitor 觸發資料品質漂移，你觸發重訓。

相同的底層概念，不同的生命週期階段

兩個工具都偵測異常，但異常型別不同。Debugger 偵測訓練時問題（模型從未收斂、梯度爆炸、GPU 使用率 30%）。Model Monitor 偵測生產時問題（模型收斂良好，但世界已改變，預測現在在漂移）。考試出題讓錯誤工具是錯誤答案——「生產模型準確度在數週內下降」是 Model Monitor（Domain 4），不是 Debugger。

Clarify vs Model Monitor — 另一個常混淆的配對

Clarify 和 Model Monitor 在概念上也重疊（兩者都測量偏差和可解釋性），但在不同生命週期階段。

Clarify — 訓練時偏差和可解釋性

Clarify 在模型開發期間作為 Processing 工作執行。它測量資料集的訓練前偏差，以及候選模型在保留評估集上預測的訓練後偏差。SHAP 可解釋性在相同評估集上執行。Clarify 的輸出在模型被註冊前消化。

Model Monitor 偏差漂移和特徵歸因漂移

Model Monitor 的偏差漂移 monitor 和特徵歸因漂移 monitor 是 Clarify 的部署後版本。它們針對生產流量持續執行，比較當前偏差和 SHAP 分佈與部署時計算的基準線。當當前值偏離基準線時，警報觸發。

為何相同引擎驅動兩者

Clarify 和 Model Monitor 的偏差/歸因 monitor 都使用相同的底層 Clarify processing 引擎。區別在於何時和對什麼評估。Clarify 是訓練時的一次性分析；Model Monitor 是生產時的排程持續分析。

MLA-C01 模型評估的常見考試陷阱

考試會埋設特定的錯誤觀念。認識它們。

陷阱 1 — 不平衡資料上的 Accuracy

1% 正類別上的 99% accuracy 沒有意義。F1 或 AUC-PR 才是正確的 metric。

陷阱 2 — RMSE vs MAE 不考慮離群值

RMSE 對大誤差懲罰重。如果離群值存在且無法修復，MAE 更能代表典型效能。

陷阱 3 — Debugger 用於生產監控

Debugger 是訓練時工具。生產監控是 Model Monitor 的事。

陷阱 4 — Clarify 只代表公平性

Clarify 是公平性 AND 可解釋性。兩者都在考試範圍。

陷阱 5 — Disparate Impact 閾值

Disparate Impact 低於 0.8（或逆向高於 1.25）違反美國 EEOC 準則的五分之四規則。考試可能陳述這個閾值。

陷阱 6 — SHAP 用於特徵選擇

SHAP 測量對特定模型預測的貢獻，不是底層問題的特徵重要性。SHAP 可能顯示模型嚴重依賴一個有雜訊的特徵；那不表示這個特徵真的有資訊量。

陷阱 7 — Experiments 自動追蹤程式碼版本

它不會。程式碼版本控制是工程師的責任（Git、S3 來源 URI）。Experiments 追蹤超參數和 metric，不是原始碼。

陷阱 8 — Debugger Insights 取代 APM

Debugger Insights 剖析訓練工作硬體。它不取代 endpoint 的應用效能監控；那是 CloudWatch 和 X-Ray 的領域。

陷阱 9 — Model Card 對所有工作流程是選項

在受管制行業（金融、醫療），model card 越來越被內部治理要求強制。考試把它們框架為最佳實踐，不是選項。

陷阱 10 — 混淆矩陣閱讀

非對角線的格子是錯誤。所有非對角線格子的總和 = 總錯誤數。讀錯矩陣導致 precision/recall 計算錯誤。

決策樹 — 選擇正確的評估工具

考試喜歡「哪個工具」的題目。把這個樹內化。

症狀：訓練 loss 沒有下降

工具：SageMaker Debugger 內建規則 loss_not_decreasing。CloudWatch 事件觸發 Lambda 停止工作。

症狀：訓練期間 GPU 使用率 30%

工具：SageMaker Debugger Insights。效能剖析報告識別 IO、CPU 預處理或同步開銷是否是瓶頸。

症狀：模型對女性申請者的表現比男性差

工具：SageMaker Clarify 訓練後偏差 metric（AD、RD、DPPL）。

症狀：利害關係人問為何特定貸款被拒絕

工具：SageMaker Clarify SHAP 局部解釋。

症狀：需要比較 HPO 跑的 50 個超參數設定

工具：Studio 中的 SageMaker Experiments 比較視圖。

症狀：稽核員要求已部署模型的來源

工具：透過 Experiments 的 SageMaker ML Lineage Tracking。

症狀：風險長需要預期用途和限制的文件

工具：SageMaker Model Card。

症狀：生產模型準確度在數月內下降

工具：SageMaker Model Monitor 模型品質（Domain 4，不是 Debugger）。

症狀：訓練資料有 95% 正類別

工具：SageMaker Clarify 訓練前偏差（CI metric）或 SageMaker Debugger class_imbalance 規則。

症狀：生產預測隨時間變得越來越難以解釋

工具：SageMaker Model Monitor 特徵歸因漂移（Domain 4）。

FAQ — 模型評估、Debugger 與 Clarify

Q1 — 0.5% 交易是詐欺的詐欺偵測應使用哪個分類 metric？

使用 F1 score 或 AUC-PR（precision-recall AUC），不是 accuracy。0.5% 正樣本時，對所有交易預測「非詐欺」可達到 99.5% accuracy——沒有用。F1 平衡 precision（合法交易被錯誤標記，損害使用者體驗）和 recall（詐欺未被抓，損害收入）。AUC-PR 捕捉跨閾值的 precision-recall 取捨，在部署閾值尚未決定時有用。如果業務有明確的成本不對稱——例如一個未被偵測的詐欺比一個假警報糟糕 100 倍——相應地加權 metric：使用 recall 加權的 F-beta score（F2 強調 recall，F0.5 強調 precision），而非普通 F1。

Q2 — SageMaker Debugger 和 SageMaker Model Monitor 的區別是什麼？

Debugger 和 Model Monitor 在不同生命週期階段解決異常偵測問題。Debugger 在訓練工作期間執行（Domain 2）。它擷取訓練內部 tensor——權重、梯度、激活值、loss——並應用內建規則偵測訓練病理（梯度消失、過擬合、tensor 爆炸、dead ReLU、GPU 使用率不足）。Debugger 輸出在模型被註冊用於部署前消化。Model Monitor 對已部署的 endpoint 執行（Domain 4）。它擷取生產流量——請求 payload、預測、稍後到達的 ground truth 標籤——並與基準線比較以偵測漂移（資料品質漂移、模型品質衰退、偏差漂移、特徵歸因漂移）。Model Monitor 輸出觸發重訓工作流程。MLA-C01 考試明確測試這個區分：訓練時症狀用 Debugger，生產時症狀用 Model Monitor。混淆它們是評估 domain 上最常被引用的錯誤。

Q3 — 什麼時候用 SageMaker Clarify vs Model Monitor 進行偏差偵測？

模型開發期間的一次性偏差分析用 Clarify——訓練前（資料集本身是否編碼偏差）和訓練後（訓練好的模型在保留評估集上是否產生偏差預測）。Clarify 作為 SageMaker Processing 工作執行，產生結構化 JSON 報告，並整合到 SageMaker Pipelines 中，在模型註冊前進行自動偏差評估。持續的部署後監控用 Model Monitor Bias Drift——已部署模型的偏差可能隨生產資料分佈改變而轉移。Model Monitor 在定期排程上對生產流量執行相同的底層 Clarify 分析，比較當前偏差 metric 與部署時建立的基準線。兩者都使用相同的 Clarify 計算引擎；區別是一次性分析（Domain 2 的 Clarify）vs 持續監控（Domain 4 的 Model Monitor）。

Q4 — 如何向利害關係人解釋我的模型為何給出特定預測？

使用 SageMaker Clarify SHAP 局部解釋。SHAP（SHapley Additive exPlanations）在考量特徵交互作用的賽局理論框架中計算每個特徵對特定預測的貢獻。對樹模型（XGBoost、LightGBM、Random Forest），Clarify 使用 TreeSHAP——快速且精確。對 deep learning 或其他黑箱模型，Clarify 使用 Kernel SHAP——模型無關但較慢。輸出是每特徵貢獻分數，顯示哪些特徵把預測推向預測類別，哪些推離它。對全域模型行為，評估集整體的平均絕對 SHAP 值產生全域特徵重要性排名。兩個視角都回答「為何這個預測」的問題：局部 SHAP 用於個別決策（GDPR 解釋權的合規），全域 SHAP 用於整體模型行為（特徵工程和除錯）。

Q5 — 我的訓練工作跑了 8 小時，在最後一個 epoch 產生 NaN loss 的模型。我如何防止這種情況？

在訓練開始時啟用 SageMaker Debugger 內建規則。相關規則是 exploding_tensor（偵測任何擷取 tensor 中的 NaN 或 Inf）、loss_not_decreasing（捕捉否則會燒算力的卡住訓練），以及 nan_loss（專門針對 loss 變成非有限值）。每個規則在違反時發出 CloudWatch 事件。把那些事件連接到一個 Lambda 函數，對違規工作呼叫 stop_training_job 並發送 SNS 通知給團隊。有了這個設置，NaN 一出現訓練就在幾秒內停止——節省 7 小時以上的浪費算力。Debugger 規則 processing 在與訓練工作並行的獨立小型容器中執行，成本只有幾分錢。在生產訓練上沒有不啟用它的合理理由；考試把「沒有 Debugger 規則的穩健訓練」視為次佳選擇。

Q6 — 我用 100 次試做了 HPO 掃描。比較它們的最佳方法是什麼？

使用 SageMaker Studio 中的 SageMaker Experiments。超參數調優工作中的每個試自動成為 experiment 中的一個 run，超參數和 objective metric 都有追蹤。在 Studio 中打開 experiment，選取要比較的 run（可以選全部 100 個或按 objective metric 篩選前 10），使用比較視圖：parallel coordinates 圖表顯示超參數和其 objective metric，折線圖重疊訓練/驗證曲線，表格視圖並排顯示完整設定。對更深入的分析，使用 SageMaker Python SDK 的 ExperimentAnalytics 類別把所有試載入 pandas DataFrame 進行自訂繪圖和統計分析。別忘了 AMT 本身根據 objective 自動選取最佳試；Experiments 是分析師人工審查為何特定設定表現不同的工具。

Q7 — SageMaker Model Card 包含什麼，誰閱讀它？

完整的 Model Card 有七個節。模型概覽——名稱、版本、負責人、框架、預期使用案例。預期用途——業務目的、應使用模型的人、不應使用的人。訓練細節——演算法、訓練資料來源和統計、超參數。評估結果——metric（accuracy、precision、recall、F1、AUC、RMSE——視情況適用）、混淆矩陣、從 Clarify 報告拉取的公平性測量。已知限制——失敗模式、邊緣案例、子群體效能、資料漂移敏感性。倫理考量——偏差測量、人工監督要求、下游影響。其他資訊——參考資料、相關文件、聯絡資訊。受眾是治理：風險長、法規遵循稽核員、下游應用負責人，以及調查生產問題的事件回應人員。Model card 隨 model package 一起存在 Model Registry 中，任何審查部署的人都可以看到文件記載的預期用途和限制，不需要閱讀原始碼。對 MLA-C01，認識 model card 是評估階段的可交付成果，而不只是部署前的事後想法。

進一步閱讀 — 模型評估的官方 AWS 文件

對超出 MLA-C01 範圍的深度，權威 AWS 資源包括：SageMaker Debugger 文件（內建規則目錄、Insights 效能剖析、自訂規則開發）、SageMaker Clarify 文件（訓練前和訓練後偏差 metric、SHAP 可解釋性方法）、SageMaker Experiments 文件（run 追蹤 SDK、比較視圖、lineage 追蹤），以及 SageMaker Model Card 文件（範本結構、治理整合）。

AWS Machine Learning Blog 有負責任 AI 與 Clarify 實作的實際案例研究，包括金融服務和醫療 ML pipeline 的偏差偵測操作說明。AWS Well-Architected Machine Learning Lens 涵蓋評估和持續改善的卓越運營支柱指引。AWS re:Invent 和 re:MARS 的 Clarify、Debugger 和 Model Monitor 議題包含與 MLA-C01 考試情境一致的實作示範。GitHub 倉庫 aws/amazon-sagemaker-examples 包含 Debugger 內建規則、Clarify 偏差和可解釋性分析、帶 HPO 整合的 Experiments 追蹤，以及從 Clarify 和 Experiments 輸出填充 model card 的端到端 notebook 範例。