Amazon MLS-C01: MLOps、監控、標註與模型治理 — 學習指南

By Laurynas Brazys · 26 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

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

管線、CI/CD 與自動化

生產等級的機器學習需要端到端的自動化，將資料擷取、驗證、訓練、調校、模型封裝和部署串連成可重複執行的管線。使用 Amazon SageMaker Pipelines 來定義步驟，包括 Processing 任務 (Data Wrangler 或 ScriptProcessor)、訓練 (使用 Distributed Data Parallel 或 XGBoost/BlazingText 的託管式訓練)、超參數調校 (使用目標指標和訓練任務 StoppingCondition 的 HyperparameterTuningJob)，以及在 SageMaker Model Registry 中註冊模型。將 Pipelines 與 AWS CodePipeline 和 CodeBuild 整合，以進行程式碼層級的 CI 檢查和單元測試，並使用 CloudFormation 或 CDK 來佈建一致的環境。在步驟上設定快取，以避免重新執行未變更的工作，並將管線輸入 (S3 前綴、執行個體類型) 參數化。對於 HPO，不要只依賴 MaxNumberOfTrainingJobs；也要設定每個訓練任務的 StoppingCondition (MaxRuntimeInSeconds)，並在可用時啟用自動提早停止，以避免成本失控。常見的陷阱包括對持續增長的資料集使用 File mode (對於大型資料集，應切換到 Pipe mode 或分散式訓練)、未對資料集和特徵進行版本控制，以及在重新訓練前未能包含資料驗證關卡 (SageMaker Processing + Deequ 或 Data Wrangler 檢查)。在資料庫內模型 (Redshift ML) 和 SageMaker 之間的決策標準基於模型複雜度、延遲和操作控制：Redshift ML 對於 SQL 內的簡單 XGBoost 模型很方便，而深度網路、自訂架構和可擴展的端點則需要使用 SageMaker。

監控、漂移偵測與模型品質

持續監控必須同時捕捉模型效能和資料品質。啟用 SageMaker 模型端點的資料擷取功能，將請求和回應儲存到 S3，然後使用 SageMaker Model Monitor 的基準任務為訓練分佈建立基準線。使用內建的 Model Monitor 檢查來偵測結構違規和單變量漂移指標；對於分佈偏移，計算 KL divergence、Population Stability Index (PSI) 或 KS 檢定，並在漂移閾值上設定 CloudWatch 警報。追蹤模型指標——分類：精確率/召回率、ROC AUC、混淆矩陣和特定類別的 FPR/FNR；迴歸：RMSE、MAE 和 MAPE。Clarify 可以在訓練前和訓練後執行偏差和可解釋性檢查，並產生基於 SHAP 的特徵歸因；使用 Clarify 來偵測子群體之間的效能差異 (敏感屬性)。常見的操作陷阱包括未擷取推論情境 (特徵對應、模型版本、請求 ID)、忽略標籤延遲 (延遲的標籤會破壞及時評估)，以及將群體偏移 (population shift) 與概念漂移 (concept drift) 混為一談——應以不同方式處理它們 (重新訓練 vs 收集標籤並重新評估特徵)。對於警報，將匯總的指標和漂移指示器推送到 CloudWatch，並在超過閾值時透過 SageMaker Pipelines 自動化回滾或重新訓練。

標註、資料準備與特徵工程

高品質的標籤和一致的特徵管線是基礎。使用 Amazon SageMaker Ground Truth 建立標註工作流程，包含自動化預標註 (模型輔助標註)、主動學習和註釋合併；選擇工作者類型 (私人員工、供應商或公眾)，並設定標籤驗證和標註者間一致性 (inter-annotator agreement) 的指標。對於 EDA 和轉換，將資料集匯入 SageMaker Data Wrangler 以分析分佈、填補缺失值，並將處理腳本匯出到 SageMaker Processing 任務中。將線上和離線特徵保存在 Amazon SageMaker Feature Store 中，以實現一致的執行期擷取和簡單的回填。編碼決策取決於規模和基數 (cardinality)：低基數的類別變數可以進行 one-hot 編碼；高基數的項目 (例如 100 種產品 SKU) 使用目標編碼 (target encoding) 或嵌入 (TensorFlow/PyTorch 嵌入層或 SageMaker 內建演算法)，而多選問卷答案則對應到 multi-hot 向量。注意常見的陷阱，例如在附加每日元數據時發生標籤洩漏 (應包含特徵工程窗口和洩漏測試)、對非常大的 S3 資料集使用 File mode (Pipe mode 會串流紀錄並支援多執行個體的分散式訓練)，以及未對轉換進行版本控制——應將 Data Wrangler 的轉換匯出為可重複使用的 Processing/Training 步驟，以確保訓練和推論之間的一致性。

ML 團隊的可解釋性、治理與擴展

可解釋性與治理需要可操作的產物與稽核軌跡。使用 SageMaker Clarify 來計算訓練前偏見指標與訓練後特徵歸因 (SHAP)，並將結果與 Model Registry 項目一起儲存。在 SageMaker Model Registry 中註冊模型時，應包含核准狀態、簽署的 ModelPackageGroups，以及自動化的晉升閘道。使用 SageMaker Experiments 追蹤實驗與血緣關係，並啟用 CloudTrail 來稽核 API 呼叫。在可解釋性技術方面，對於樹狀模型 (XGBoost 內建的 SHAP)，應優先選用模型原生的特徵重要性；對於深度網路，則使用 SHAP 或積分梯度，同時注意執行時間成本——為批次客戶離線預先計算解釋，並為即時請求提供摘要。治理的最佳實踐包括：使用包含資料集描述、公平性檢查和文件化商業規則的模型卡，以及強制執行 IAM 最小權限來部署模型。為了擴展團隊，應將管線模組化、為前處理/驗證建立標準範本、集中化 Feature Store，並自動化漂移偵測與重新訓練觸發器，讓資料科學家能專注於改善而非維運。常見的陷阱包括：過度依賴特徵重要性來推斷因果關係、未維護已部署模型的稽核日誌，以及在低延遲端點中同步執行昂貴的可解釋性計算。

實務問題：使用案例情境

情境： Acme 製造公司營運著連線不穩定的遠端感測器機隊，並使用 AWS IoT 與 S3 進行集中匯總。他們的 AWS ML 環境包括 SageMaker、IoT Core、Kinesis Data Streams，以及啟用 Greengrass 的邊緣裝置。

挑戰： 在連線不穩定時，於遠端站點提供低延遲的異常偵測，同時在沒有 Direct Connect 的情況下，收集遙測資料以進行集中式重新訓練與漂移偵測。

建議方法：

將一個使用 SageMaker Neo 編譯的精簡異常偵測模型部署到邊緣裝置上的 AWS IoT Greengrass，以進行即時的本機推論與動作 (本機警報、短期緩衝)。
透過 AWS IoT Core 將摘要後的遙測資料與異常旗標串流傳輸至 Amazon Kinesis Data Streams，並使用 Kinesis Data Firehose 將原始與彙總後的資料以 parquet 格式存續到 S3 以進行集中儲存。
建立一個 SageMaker Pipeline，此管線會擷取 S3 批次資料、執行 Processing 任務 (Data Wrangler) 來計算基準線與進行特徵工程、視需要觸發 HyperparameterTuningJobs，並將驗證後的模型註冊到 SageMaker Model Registry。
在中央端點上啟用 SageMaker Model Monitor，並排程批次任務，將邊緣收集到的分佈與訓練基準線 (PSI/KL) 進行比較，並使用 SageMaker Ground Truth 搭配抽樣的警示進行人工標註，以形成閉環。

基本原理： 透過 Greengrass + Neo 進行邊緣推論，確保在連線不穩定時也能做出低延遲的決策；Kinesis + Firehose 保證了可靠、有序地將資料擷取到 S3 以供重新訓練；SageMaker Pipelines 與 Model Registry 提供了可重複的重新訓練、版本控制，以及帶有漂移檢查的自動化晉升，以維持模型品質。

← 安全性、隱私權與合規性 · 所有領域

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