Amazon MLA-C01: 模型監控與可觀測性 — 學習指南

By Laurynas Brazys · 4 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

屬於 AWS Machine Learning Engineer Associate MLA-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

核心概念：漂移、基準線與可觀測性

模型監控是一門營運紀律，它將原始的執行階段遙測資料轉換為可採取行動的信號，例如：資料漂移、概念漂移、模型品質下降以及基礎設施健康狀況。資料漂移意指生產環境中輸入特徵的統計分佈，與訓練期間觀察到的基準線分佈產生了分歧；概念漂移則意指輸入與標籤之間的統計關係發生變化，導致模型的預測對應關係效能降低。有效的可觀測性需要一個預期行為的基準線、對生產環境的輸入與輸出進行持續剖析、指標提取（包含以模型為中心的指標如 F1/ROC AUC，以及以資料為中心的指標如 KS 距離、PSI、缺失率、類別基數），以及一個可靠的警報與工作流程系統，以形成回饋到驗證或重新訓練的閉環。

基準線通常是利用描述性統計和約束檔案，從具代表性的訓練（和驗證）資料快照中產生。在 AWS SageMaker 中，可使用 DefaultModelMonitor.suggest_baseline 工具或一個 Processing job 來計算基準線統計數據和一組初始約束（例如：最小值/最大值、允許的類別值、百分位數）。其輸出是一個儲存在 S3 上的 JSON 約束檔案和一個統計檔案；這些產物會成為後續監控任務所參考的標準基準線。監控任務會將每批次的統計數據與這些基準線進行比較，並在超過設定的閾值時標記出違規情況。可觀測性也意味著擷取模型輸入、模型輸出、推論延遲以及下游的業務指標（如果有的話），並將這些信號關聯起來，以便快速診斷像 F1 這類模型層級指標下降的原因。

關鍵服務與組態設定

SageMaker Model Monitor 提供了託管功能，可用於排程處理任務，以計算統計數據並根據基準線進行評估。您將會使用的核心 API 和組態物件包括 CreateMonitoringSchedule，其參數為 MonitoringScheduleName 和 MonitoringScheduleConfig，其中 MonitoringScheduleConfig 包含一個帶有 cron 風格 ScheduleExpression 的 ScheduleConfig，以及一個 MonitoringJobDefinition，後者包含 RoleArn、MonitoringAppSpecification.ImageUri、MonitoringResources.ClusterConfig (InstanceType、InstanceCount、VolumeSizeInGB)、MonitoringInputs (S3 輸入位置和 DatasetFormat) 和 MonitoringOutputConfig.S3OutputPath。基準線產物是透過 MonitoringJobDefinition.BaselineConfig 來參考。若要自動推導基準線，請使用 DefaultModelMonitor.suggest_baseline 呼叫 (SageMaker Python SDK)，它會執行一個 ProcessingJob，將約束和統計數據寫入 S3。

可觀測性與警報功能是使用 CloudWatch 指標和警報，以及用於事件驅動工作流程的 EventBridge 來實現的。Model Monitor 會發布執行結果，這些結果可以轉換為 CloudWatch 指標；若要建立警報，您可以使用 PutMetricAlarm API，並帶上 AlarmName、MetricName、Namespace、Statistic (或 MetricDataQuery)、ComparisonOperator、Threshold、Period 和 EvaluationPeriods 等參數。透過指定指向 SNS 主題或 EventBridge 目標的 AlarmActions，可以將警報與自動化操作綁定。EventBridge 規則可以篩選來源為 “aws.sagemaker” 的事件，並使用一個模式來匹配 Model Monitor 監控排程執行失敗或約束違規的情況，然後將事件路由到一個 Lambda 或直接觸發 SageMaker Pipeline 的 StartPipelineExecution。

對於受控部署和手動核准，SageMaker Model Registry 支援 ModelPackage 和 ModelPackageGroup 物件。當您呼叫 CreateModelPackage 時，可以將 ModelApprovalStatus 設定為 “PendingManualApproval”，之後授權的使用者可以呼叫 UpdateModelPackage，將 ModelApprovalStatus 設定為 “Approved”。執行模型部署的 Pipelines 或 CI/CD 任務，只會提升 ModelApprovalStatus 為 “Approved” 的模型套件版本。使用 IAM 政策來控制誰可以呼叫 UpdateModelPackage。

一個完整的監控堆疊通常會結合使用以下服務：

Amazon SageMaker Model Monitor
Amazon SageMaker Pipelines and Model Registry
Amazon S3 (用於存放基準線、真實標籤和推論擷取資料)
Amazon CloudWatch (指標、日誌、PutMetricAlarm)
Amazon EventBridge (事件規則與路由)
AWS Lambda 或 Step Functions (自動化目標)
Amazon SNS (警報通知)
AWS Glue / Athena / QuickSight (用於臨時性的探索與視覺化)

設計模式與權衡取捨

一個常見且穩健的模式是將短期偵測與長期修復分開。使用高頻率的監控排程（例如，每小時或每日使用 CreateMonitoringSchedule 搭配 ScheduleExpression）來計算每個批次的統計數據，並快速偵測漂移。使用 PutMetricData 將每次執行的結果饋送至 CloudWatch 自訂指標，並建立 CloudWatch Alarms，為自動化的低信賴度動作（例如，傳送通知）設定保守的閾值，為自動化的高信賴度動作（例如，觸發重新訓練 pipeline）設定更嚴格的閾值。EventBridge 規則將偵測與修復橋接起來，方法是將 Model Monitor 違規事件或 CloudWatch Alarm 狀態變更對應到一個 Lambda，該 Lambda 會進行身份驗證並為 SageMaker Pipeline 呼叫 StartPipelineExecution，或透過 CreateTrainingJob 叫用重新訓練任務。

在決定要自動重新訓練還是需要手動批准時，請權衡業務風險與合規性。自動重新訓練適用於低風險模型，且其 pipeline 中包含可靠的自動化驗證步驟（資料驗證、對照保留資料的模型評估、回滾測試）。對於受監管或高影響力的模型，請採用 Model Registry 的手動批准模式：推送 ModelApprovalStatus 為 "PendingManualApproval" 的候選 ModelPackage，觸發人工審核流程（例如，在 MLOps 儀表板中建立一個工單，或由一個 approver Lambda 透過 UpdateModelPackage 來更新 ModelPackage），然後才允許部署到生產環境的端點。

監控頻率和推論擷取的大小會在成本與敏感度之間產生權衡取捨。較小的批次窗口會增加對暫時性雜訊的敏感度並提高處理成本，而較大的窗口則會降低成本，但可能會延遲對快速漂移的偵測。同樣地，擷取完整的推論負載可能成本高昂，並引發資料治理問題；除非需要完整的重放來進行根本原因分析，否則請考慮取樣或僅儲存彙總後的特徵和模型輸出。

對於重新訓練的觸發器，建議採用事件驅動的自動化，將業務邏輯編碼在 pipeline 中：一個 CloudWatch Alarm 的觸發會啟動一個 EventBridge 規則，該規則將最小化的負載（擷取資料的 S3 URI 和約束差異檔案）傳遞到 StartPipelineExecution，並帶有 PipelineParameters，例如 "TrainingDataS3Uri"、"BaselineConstraintsS3Uri" 和 "RetrainTriggerReason"。這使得觸發器具有確定性且可供稽核。

常見陷阱與決策標準

一個常見的陷阱是將統計漂移視為必然需要採取行動。並非所有漂移都會影響模型效能。在啟動昂貴的重新訓練之前，應先將特徵分佈的變化與模型品質指標（F1、precision-recall、calibration）建立關聯。另一個錯誤是未能保護所擷取的推論資料；應選擇靜態加密（S3 SSE-KMS）、S3 儲存貯體政策和 VPC 端點，以保持生產資料的隔離。在設定監控任務時，請確保 IAM RoleArn 具有最低權限存取：讀取推論擷取 S3 前綴、寫入監控輸出 S3 前綴，以及在您發出日誌時建立 CloudWatch 日誌的權限。

在選擇重新訓練的頻率與管線的複雜度時，應根據觀察到的訊噪比來做決策。如果 Model Monitor 顯示頻繁的短暫違規，請實作平滑化處理，或要求在觸發管線前必須有連續多次的違規執行。對於手動核准工作流程，應透過一個狹窄的 IAM 權限集來強制執行

undefined

，並在管線執行中繼資料中記錄核准者身份，以符合法規要求。

實務問題：使用案例情境

公司名稱：FinSecure Analytics；挑戰：一個用於詐欺偵測的生產中 XGBoost 模型，其偽陽性（false positives）出現間歇性遽增，且 F1 分數在數月內持續下降；資料來自 S3 交易日誌和一個本地部署 (on-premises) 的 MySQL 客戶資料鏡像；模型必須經過稽核和人工核准後才能重新訓練。

自動化監控與基準線：針對一個具代表性的訓練快照執行

undefined

，以產生儲存在 S3 中的基準線統計資料和限制條件（基準線 S3 前綴）。使用

undefined

建立監控排程，其中

undefined

指定了用於每小時執行的

undefined

、具有 S3 讀寫權限的 [[CODE_8]]、指向 Model Monitor 容器的

undefined

、具有

undefined

和

undefined

1 的

undefined

、指向已擷取推論 S3 前綴的

undefined

，以及用於擷取執行輸出的

undefined

。

警示與分類處理：使用

undefined

將每次執行的違規計數發佈到 CloudWatch 的自訂

undefined

下，並建立一個

undefined

，其

undefined

設定為當

undefined

X 連續三個週期時觸發。將

undefined

設定為一個 SNS 主題和一個 EventBridge 規則，該規則篩選來源為 “aws.sagemaker” 且 detail-type 為 “SageMaker Model Monitor” 的事件，以包含違規的中繼資料。

包含手動核准的修復管線：實作一個 SageMaker Pipeline，執行資料擷取（使用 Glue 任務將 S3 + MySQL 鏡像的資料集中到一個訓練資料集）、自動化特徵工程、透過

undefined

使用 XGBoost 容器進行訓練、產生 F1 和偏差報告的評估步驟，以及透過

undefined

並將

undefined

註冊到 Model Registry。該管線會將評估指標寫入 CloudWatch 和

undefined

的中繼資料中。

人機協作與強制執行：使用一個由 CloudWatch Alarm 觸發的 EventBridge 規則，透過 SNS 通知資料科學團隊；核准者檢視存放在 S3/QuickSight 中的評估產出，然後呼叫

undefined

並將

undefined

。CICD/部署步驟會在呼叫

undefined

（或更新 SageMaker 端點）之前檢查

undefined

。對於自動化重新訓練（當指標低於自動化閾值且業務上接受自動重訓時），將一個 Lambda 目標附加到 EventBridge 規則上，該規則呼叫

undefined

並帶上

undefined

和

undefined

等參數，從而啟用一個由更嚴格的閾值所保護的全自動化路徑。

AWS 的理由：SageMaker Model Monitor 以最少的維運工作集中了漂移偵測和基準線比較；CloudWatch 和 EventBridge 提供了穩健的警示與路由功能，可傳送至 SNS/Lambda；SageMaker Pipelines 自動化了重新訓練和模型驗證；Model Registry 的

undefined

為生產部署強制執行一個手動核准的關卡；而 S3/Glue/Athena 為訓練和視覺化提供了集中且安全的資料彙總。這些服務共同實現了可重現的基準線、可稽核的核准、以及可設定的自動化重新訓練，並在偵測與修復之間有明確的分離。

← MLOps 與模型生命週期管理 · 所有領域 · 安全性、治理與合規性 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →