ML CI/CD with CodePipeline 與自動再訓練

ML CI/CD with CodePipeline 與自動再訓練，是所有 AWS 生產機器學習系統的運作核心。ML CI/CD 的本質，是把模型程式碼、訓練資料、超參數與推論基礎設施當成軟體產出物，讓它們從一次 Git commit 或一個資料漂移告警出發，一路流過自動化管線抵達生產端點，並賦予和後端服務同等的嚴謹度。在 MLA-C01 考試中，ML CI/CD 錨定 Domain 3（部署與 ML 工作流程編排，佔 22% 比重）的 Task 3.3，也是考試中測試最密集的主題群之一——因為這張證照定位為工程師考試，而非資料科學考試。來自 K21 Academy、Pluralsight 和 Tutorials Dojo 的社群回饋一致指出，在 ML CI/CD 管線設定深度上準備不足的考生，失敗率遠高於演算法理論準備不足者。

本指南全面涵蓋 ML CI/CD 的各個面向：AWS CodePipeline 各階段如何對應 ML 生命週期、CodeBuild 如何執行單元測試並打包 SageMaker 訓練腳本、EventBridge 如何從資料品質告警或定排 cron 觸發自動再訓練、模型審核閘道的運作方式、如何用 CloudFormation 或 CDK 建立基礎設施即程式碼、以及 SageMaker Pipelines 和 CodePipeline 如何互補而非互斥。最後以正式再訓練迴圈——從漂移偵測到模型部署——以及考試偏愛透過排序與配對題型考察的疑難排解決策樹作結。

什麼是 ML CI/CD，為何 MLA-C01 如此重視它

ML CI/CD 是把持續整合與持續交付實踐應用於機器學習系統的學科。傳統軟體 CI/CD 把原始碼當成唯一的測試和部署產出物；ML CI/CD 則必須額外管理持續訓練（CT）——當資料分佈偏移、新的標注資料到來、業務需求改變，或定排刷新視窗觸發時，自動對模型進行再訓練。這第三根支柱（CI + CD + CT）是 ML CI/CD 有別於一般 DevOps 的關鍵所在。在 MLA-C01 中，ML CI/CD 問題測試你是否能將「團隊希望在資料品質監控告警觸發時重新訓練詐騙偵測模型，並在分析師審核後部署新版本」這樣的題幹，正確對應到 EventBridge 規則、Lambda 觸發器、SageMaker Pipelines 執行、Model Registry 審核工作流程和 CodePipeline 部署階段的組合。

為何具備 DevOps 背景的工程師在 MLA-C01 比資料科學家更有優勢

社群回饋一再確認，具備後端或 DevOps 背景的考生在 MLA-C01 的表現優於純粹的資料科學家，因為這張考試在 CI/CD 管線機制、IaC 模式和運維疑難排解上的測試深度，遠超過演算法理論。能夠徒手推導反向傳播但從未寫過 buildspec.yml 的資料科學家，在面對貼出 CodePipeline JSON 定義並詢問哪個階段轉換會觸發再訓練的題幹時會十分吃力。把 ML CI/CD 當成軟體工程考試主題對待——它獎勵以階段、轉換、產出物和觸發器思考的工程師。

AWS 上 ML CI/CD 的三個支柱

持續整合涵蓋訓練腳本的自動單元測試、訓練資料的 schema 驗證、容器程式碼審查，以及針對暫存端點的整合測試。持續交付涵蓋將訓練好的模型自動打包到 Model Registry、透過開發/暫存/生產帳戶進行階段式部署，以及在健康檢查失敗時自動回滾。持續訓練涵蓋再訓練觸發器（定排、漂移驅動或新資料到達）、透過 SageMaker Pipelines 進行管線編排，以及根據評估指標進行條件式註冊。MLA-C01 考試涵蓋三個支柱，但對持續訓練和持續交付的比重高於純粹的 CI，因為 CI 模式可以直接從一般 DevOps 轉移，而 CT 模式是 ML 特有的。

白話文解釋 ML CI/CD with CodePipeline

ML CI/CD 是那種六個 AWS 服務共同編排一個工作流程的主題。三個具體類比讓各個元件更容易記憶。

類比一——連鎖便當店的食譜更新流水線

想像一家台灣連鎖便當店，每季根據顧客回饋更新招牌便當的食譜（輸入資料）。主廚（資料科學家）寫出新食譜（訓練腳本），備料台（CodeBuild）在小批量上進行試做（單元測試），試驗廚房（SageMaker 訓練任務）在完整規模下實際烹煮，品鑑小組（模型評估）以口感與擺盤（精確率和召回率）評分，行政主廚（CodePipeline 中的手動審核閘道）試吃後才批准配送，中央食材倉（Model Registry）為核准食譜蓋上版本章再發送到各分店（生產端點）。當顧客服務熱線（Model Monitor）回報現有食譜評分不佳（偵測到資料漂移）時，廚房自動化系統（EventBridge 規則）便自動觸發新食譜開發週期，不必等待季度審查。再訓練迴圈就是廚房的品管機制——從顧客回饋循環回到食譜更新、倉庫、各分店，再到下一輪回饋。每個步驟都記錄在食譜卡上（管線執行歷史），讓任何食品安全稽核員都能重建哪天供應了哪份食譜。

類比二——持續品質更新的汽車製造流水線

想像一座持續生產車輛的汽車工廠。底盤設計（模型程式碼）由工程師提交到版本控制系統（CodeCommit 或 GitHub）。當設計變更被提交時，品管站（CodeBuild）對設計執行單元測試——是否通過碰撞模擬，是否符合標準底盤規格。原型組裝線（SageMaker 訓練任務）使用新設計加上最新生產資料（來自 S3 的訓練資料）組裝一台完整原型。碰撞測試實驗室（模型評估）對原型進行標準安全測試並產出指標。若指標通過門檻，車輛便向監理機關登記（Model Registry 審核）、獲得車身號碼（模型版本），並出貨到展示間（部署到端點）。來自路上既有車輛的遙測資料（Model Monitor）回報效能下降——例如冬季輪胎磨損速度比預測快（資料漂移）。工廠控制中心（Model Monitor 告警上的 EventBridge 規則）便自動以最新路況資料排程新的生產批次，無需人工介入。工廠領班（CodePipeline）協調各組裝站的執行順序，而原型設計和構建的子程序（SageMaker Pipelines）則在更大的工廠管線內部處理 ML 特有的編排工作。兩個系統互補，而非替代。

類比三——日報的每日工作流程

想像一份日報。編輯團隊（資料科學家）撰寫新文章（模型程式碼變更）並提交到手稿存放庫（Git）。文字編輯台（CodeBuild）進行拼字檢查、事實查核和風格指南驗證（單元測試、schema 驗證）。排版組（SageMaker 訓練任務）使用最新文章加上當前廣告版位（訓練資料）組合出完整版面。主編（手動審核閘道）在批准印刷前審查樣張。印刷室（CodeDeploy 或 SageMaker UpdateEndpoint）印出版面並分送訂戶（生產流量）。報攤銷售追蹤器（生產端點上的 Model Monitor）回報哪些版塊表現不佳（訂閱者偏好的資料漂移）。當體育版銷售下滑超過 15%（CloudWatch 告警門檻）時，新聞室排程員（EventBridge 規則）便自動觸發編輯審查和更新版面，不必等到隔天早上的企劃會議。版本檔案室（Model Registry）保存每個核准版面的元資料，讓圖書館員（稽核團隊）能夠證明哪天發送了哪份版面。再訓練迴圈就是新聞室以生產速度持續適應讀者回饋的機制。

AWS CodePipeline 的 ML 階段——五階段模式

CodePipeline 使用階段-動作模型來編排 ML CI/CD。記住這個標準五階段模式。

第一階段——Source（來源）

Source 階段從 CodeCommit、GitHub、GitHub Enterprise、Bitbucket、Amazon S3 或 Amazon ECR 拉取模型程式碼、訓練腳本、管線定義和基礎設施即程式碼範本。對於 ML 工作流程，來源通常包含訓練腳本（train.py）、推論處理器（inference.py）、SageMaker Pipeline 定義（pipeline.py）、CodeBuild 的 buildspec（buildspec.yml），以及用於端點基礎設施的 CloudFormation 或 CDK 範本。Source 階段觸發器可以是 webhook 型（提交到 main 分支就觸發管線）或輪詢型（CodePipeline 每五分鐘檢查一次）。

第二階段——Build and Test（建置與測試）

Build 階段執行 CodeBuild 專案，對訓練腳本進行單元測試、用 Great Expectations 或 AWS Glue Data Quality 驗證訓練資料 schema、對 Docker 容器進行程式碼審查、將推論容器打包到 ECR，並產出建置產出物（訓練任務定義 JSON、SageMaker Pipeline 定義 JSON、CloudFormation 範本）供下游階段使用。buildspec.yml 定義測試指令和產出物路徑。CodeBuild 在短暫的容器中執行，因此每次建置都可重現且互相隔離。

第三階段——Train（訓練）

Train 階段透過 Lambda 動作或 SageMaker Pipelines CodePipeline 動作提供者呼叫 SageMaker Pipelines，啟動管線執行，依序執行 Processing → Training → Tuning → Evaluation → ConditionStep → RegisterModel。CodePipeline 階段等待 SageMaker Pipeline 執行完成，並以 Model Registry 的註冊作為成功信號。訓練階段的失敗（評估指標不佳、訓練任務失敗、資料驗證失敗）會讓管線停在此階段。

第四階段——Approval（審核）

Approval 階段使用 CodePipeline 的手動審核動作——由人工（通常是 ML 工程負責人或合規官員）審查模型卡、評估報告和血緣資料後，在 AWS 主控台或透過 SNS 通知連結點擊批准。手動審核在受監管行業（金融、醫療、保險）的生產部署中是必要的，即使在不受監管的環境中也建議作為最後防線，防止失控的再訓練。對於風險較低的環境，可以用 Lambda 函數評估指標門檻來替代手動步驟，實現自動審核。

第五階段——Deploy（部署）

Deploy 階段透過 CloudFormation 堆疊更新、CDK 部署或直接呼叫 SageMaker UpdateEndpoint API 來更新生產 SageMaker 端點。部署策略可以是全量替換（替換端點設定）、藍/綠（平行堆疊切換）、金絲雀（少量百分比流量轉移）或線性（漸進式流量轉移）。在端點層級設定的 SageMaker Deployment Guardrails 可在部署期間 CloudWatch 告警觸發時自動回滾。

CodeBuild 在 ML 中的角色——測試與打包階段

CodeBuild 是 Build 階段的執行器，負責執行單元測試、驗證訓練資料，並產出產出物。

ML 的 Buildspec.yml 結構

典型的 ML buildspec.yml 有四個階段：install（設定 Python 環境，透過 pip 安裝相依套件）、pre_build（驗證 ECR、取得測試用參考資料）、build（對訓練腳本執行 pytest、對訓練資料執行 Great Expectations 驗證、審查 Dockerfile、建置訓練容器並推送到 ECR）和 post_build（將管線定義產出物輸出到 S3，將建置元資料寫入 Parameter Store）。

ML 程式碼的單元測試

ML 腳本的單元測試涵蓋資料預處理函數（tokenizer 是否產出預期輸出、特徵轉換是否保留資料類型）、模型架構實例化（模型是否以設定的超參數建置）和評估指標計算（precision_at_k 對已知輸入是否回傳預期值）。在 CI 中不進行單元測試的項目：訓練收斂（太慢，需要 GPU，改在 SageMaker 訓練階段執行）或生產規模的資料品質（改在 SageMaker Processing 任務中執行）。

用合成資料進行整合測試

CodeBuild 中的整合測試使用小型合成資料集（1000 筆）在較小實例類型（ml.m5.large）上執行端對端 SageMaker 訓練任務，對產生的模型呼叫一筆保留的測試資料，並驗證預測形狀和信心範圍。這能在消耗 GPU 小時數進行完整訓練之前，捕捉容器打包錯誤、S3 路徑錯誤和 SageMaker SDK API 誤用。

建置容器並推送到 ECR

對於 BYOC（自備容器）工作流程，Build 階段會編譯 Dockerfile、進行容器程式碼審查、掃描漏洞（使用 Amazon Inspector 或 Trivy）、以 commit SHA 作為標籤，並推送到 ECR。下游 Train 階段透過標籤引用映像 URI。對於 BYOS（自備腳本）工作流程，Build 階段只需打包腳本並使用 SageMaker 管理的框架容器。

快取與建置效能

CodeBuild 支援本地快取（Docker layer 快取）和 S3 快取（pip wheel、npm 模組），以減少建置時間。對於每次提交都重建容器的 ML 管線，layer 快取可以將建置時間從 8 分鐘縮短到 90 秒以內（針對小型程式碼變更）。

EventBridge 觸發自動再訓練

EventBridge 是持續訓練的觸發核心。考試主要考察三種模式。

模式一——排程再訓練（Cron）

最簡單的再訓練觸發器是排程。EventBridge Scheduler 建立 cron 規則（每週日 02:00 UTC、每月第一天），目標是 Lambda 函數或直接透過 StartPipelineExecution API 呼叫 SageMaker Pipeline 執行。當再訓練頻率由業務週期（週模型刷新、月度重新校準）而非資料品質決定時，使用此模式。取捨：排程再訓練在資料未漂移時浪費計算資源，而在漂移加速時又反應太慢。

模式二——漂移驅動再訓練（Model Monitor 告警）

考試偏愛的模式。SageMaker Model Monitor 為資料品質違規、模型品質違規、偏差漂移和特徵歸因漂移發布 CloudWatch 指標。當違規指標超過門檻時，CloudWatch 告警會發布到 SNS 主題或直接向 EventBridge 發送狀態變更事件。具有告警狀態模式的 EventBridge 規則，以 Lambda 函數為目標，Lambda 啟動指示違規類型的 SageMaker Pipeline 執行。這就形成了迴圈：生產模型漂移 → Monitor 偵測 → 告警觸發 → 管線再訓練 → 登記到 Registry → CodePipeline 部署。

模式三——新資料到達再訓練（S3 事件）

當新的標注資料到達 S3（來自標注管線、每日批次 ETL、上游資料夥伴）時，S3 PutObject 事件觸發 Lambda，Lambda 判斷新批次是否值得再訓練（通常是：最小列數門檻加上距離上次訓練的最短時間間隔）。如果是，Lambda 啟動 SageMaker Pipeline 執行。此模式適合以資料為驅動而非以時間為驅動的再訓練用例。

SageMaker 事件的 EventBridge 規則模式

EventBridge 也可以消費 SageMaker 發出的事件——Pipeline 狀態變更（已開始、成功、失敗）、訓練任務狀態變更、Model Registry 狀態變更（PendingManualApproval、Approved、Rejected）。常見模式：EventBridge 規則監聽 Model Package State Change 且 ModelApprovalStatus = Approved，觸發 Lambda 更新生產端點。這將審核與部署解耦——在 Model Registry 中審核即可自動傳播到生產，無需任何人在 CodePipeline 中點擊。

模型審核閘道——手動與自動

審核閘道是訓練好的模型與生產部署之間的安全守衛。

CodePipeline 中的手動審核

手動審核動作會無限期暫停管線，直到人工透過 AWS 主控台、CLI 或 SDK 批准或拒絕。將動作設定為帶有 SNS 主題，向審核者寄送帶有管線狀態連結和相關建置產出物（模型卡、評估報告、血緣資料）的電子郵件。審核動作沒有內建超時——待審核項目會一直掛起直到有人處理，這是有意為之的設計（不希望在分析師缺席 24 小時後出現流氓自動批准）。

透過 Lambda 實現自動審核

對於風險較低的環境，以 Lambda 函數取代手動審核，Lambda 讀取 Model Registry 的評估指標，與門檻比較（精確率 > 0.85、延遲 p99 < 200ms、公平性 ΔDPL < 0.1），並呼叫 UpdateModelPackage 將 ModelApprovalStatus 設為 Approved，或帶著解釋拒絕。Lambda 也可以實作晉升邏輯——暫存環境自動批准，生產環境要求手動審核。

多層審核工作流程

受監管行業通常需要多層審核：ML 工程師簽署技術指標、資料科學家簽署公平性、合規官員簽署監管標準。CodePipeline 在獨立階段支援順序性手動審核動作，每個都有自己的 SNS 主題和審核條件。只有所有審核完成後，管線狀態才會向前移動。

審核閘道位置的反模式

一個常見的考試陷阱設定是把審核閘道放在訓練之前而非評估之後。這是錯的——在知道評估指標之前審核模型，使閘道失去意義。正確位置是在評估和部署之間，審核者可以看到評估結果。

ML CI/CD 的基礎設施即程式碼

ML CI/CD 管線本身也應定義為程式碼，而非在主控台中點擊產生。

SageMaker 資源的 CloudFormation

CloudFormation 支援 SageMaker 資源：AWS::SageMaker::Model、AWS::SageMaker::Endpoint、AWS::SageMaker::EndpointConfig、AWS::SageMaker::Pipeline、AWS::SageMaker::ModelPackage、AWS::SageMaker::ModelPackageGroup。CloudFormation 堆疊定義整個管線——SageMaker Pipeline 定義、Model Registry 群組、EventBridge 規則、Lambda 函數、IAM 角色、CodePipeline 管線本身和 CodeBuild 專案。更新堆疊即原子性地更新整個管線。

CDK 提供更高層次的構件

AWS CDK 提供編譯成 CloudFormation 的高層次構件，但以類型安全的 Python 或 TypeScript 撰寫。aws-cdk.aws-sagemaker 模組封裝 SageMaker 資源；aws-cdk.aws-codepipeline 模組封裝 CodePipeline。當管線結構是動態的（不同環境有不同階段）或當各團隊共享構件可以減少樣板程式碼時，CDK 比原始 CloudFormation 更受青睞。

SageMaker Projects MLOps 範本

SageMaker Projects 提供預建 MLOps 範本，能在幾分鐘內構建完整的 CodePipeline + SageMaker Pipelines + Model Registry + 端點部署。範本包括「用於模型建置、訓練和部署的 MLOps 範本」（單帳戶）、「用於模型部署的 MLOps 範本」（多帳戶）和從 Service Catalog 作品集拉取的自訂範本。這些範本是快速建立基準 ML CI/CD 設定的捷徑，在 MLA-C01 考試指南中被明確提及。

用於 ML 基礎設施的 Terraform

透過 AWS Terraform provider，Terraform 也支援 SageMaker 資源。許多企業在各雲端提供商上標準化使用 Terraform；對這些團隊而言，封裝 SageMaker Pipelines 和 CodePipeline 的 Terraform 模組就是 IaC 層。就 ML CI/CD 目的而言，在功能上等同於 CloudFormation；考試不偏好其中任何一個。

SageMaker Pipelines vs CodePipeline——互補角色

這個區別是 MLA-C01 考試中測試最頻繁的概念點之一。

SageMaker Pipelines 的最佳應用場景

SageMaker Pipelines 是專為 ML 工作流程設計的。它支援 CodePipeline 無法表達的步驟類型——ProcessingStep（執行 SageMaker Processing 任務）、TrainingStep（執行訓練任務）、TuningStep（執行超參數調整）、TransformStep（執行批次轉換）、CreateModelStep、RegisterModelStep、ConditionStep（根據指標門檻分支）、CallbackStep（等待外部系統）、Lambda Step、ClarifyCheckStep、QualityCheckStep、EMRStep、FailStep。管線執行自動在 SageMaker ML Lineage Tracking 中捕捉血緣。步驟快取在重新執行時避免重複計算未變更的步驟。

CodePipeline 的最佳應用場景

CodePipeline 是專為軟體 CI/CD 設計的。它支援來源整合（CodeCommit、GitHub、Bitbucket、S3、ECR）、用於任意 shell 測試的 CodeBuild 整合、CodeDeploy 進行應用部署、CloudFormation 部署用於 IaC、手動審核動作、第三方整合（Jenkins、TeamCity、Datadog）和跨區域動作支援。

分層架構模式

在生產中：CodePipeline 是外層，包裝整個 CI/CD 工作流程，包括原始碼拉取、程式碼測試、基礎設施配置、手動審核和端點部署。SageMaker Pipelines 是內層，在 CodePipeline 的 Train 階段內執行，處理預處理-訓練-評估-註冊的 ML 特有編排。每層負責最擅長的部分。這是考試的標準答案模式。

正式再訓練迴圈——端到端

記住這個迴圈。它是 MLA-C01 Domain 3 中測試最頻繁的機制。

第一步——生產端點漂移偵測

SageMaker 即時或非同步端點在啟用資料擷取的情況下服務流量（將請求和回應寫入 S3）。SageMaker Model Monitor 執行排程監控任務，將即時請求分佈與從訓練資料計算的基準進行比較。當統計漂移超過約束門檻（KS 檢定 p 值、KL 散度、缺失值率）時，Model Monitor 為 feature_baseline_drift 違規發出 CloudWatch 指標。

第二步——CloudWatch 告警觸發 EventBridge

CloudWatch 告警監視違規指標，當超過門檻時轉換到 ALARM 狀態。告警發布到 SNS 主題（用於 SOC 通知）並發出 EventBridge 消費的 CloudWatch 事件。

第三步——EventBridge 規則觸發 Lambda

EventBridge 規則符合告警狀態變更事件並呼叫 Lambda 函數。Lambda 查詢 SageMaker Model Registry 取得當前核准的模型包，從 Parameter Store 取得最新訓練資料 S3 路徑，並使用參數（TrainingDataUri、BaselineModelPackageArn）呼叫 SageMaker Pipeline 執行。

第四步——SageMaker Pipeline 執行

管線執行 Processing（從最新資料刷新特徵）、Training（在擴展資料集上訓練新模型）、Evaluation（在保留集上計算指標）、ConditionStep（如果 AUC > 基準 AUC + 0.02 則繼續；否則 FailStep）、RegisterModel（以 PendingManualApproval 狀態註冊），並發出 Model Package State Change 事件。

第五步——審核與部署

Model Package State Change 事件觸發手動審核工作流程（分析師審查、在主控台中批准）或自動批准 Lambda。當審核狀態變更為 Approved 時，EventBridge 規則觸發 CodePipeline（透過 StartPipelineExecution），CodePipeline 透過帶有 CloudWatch 告警把關的藍/綠部署將新模型部署到生產端點。

第六步——部署後監控

新端點繼承 Model Monitor 排程，基準從新訓練資料重新產生。迴圈關閉，準備在下次漂移事件發生時再次觸發。

ML 的 GitOps——版本控制管線定義

GitOps 將 ML 管線中的每個產出物——程式碼、設定、管線定義、基礎設施範本、Feature Store schema——都當成 Git 中的版本控制項，以 Git 狀態驅動部署。對於 ML CI/CD，GitOps 意味著 SageMaker Pipeline 定義是 Git 中的 Python 文件，CodePipeline 定義是 Git 中的 CloudFormation 範本，Feature Store schema 是 Git 中的 JSON 文件，對任何這些的修改在套用之前都流經 pull request 審查。好處：生產中的每個模型都有一個可追溯的 Git commit 作為其真實來源，回滾意味著還原 Git，而非在主控台中點擊。

Feature Store Schema 即程式碼

儲存在 Git 中的 Feature Store 特徵組定義確保 schema 變更（新增特徵、變更特徵類型）在套用前流經程式碼審查和對歷史資料的 CI 測試。當訓練管線和推論管線都引用相同 Git 版本控制的特徵組定義時，訓練與服務之間的 schema 漂移——典型的訓練-服務偏差——就能被預防。

管線定義版本控制

每次對管線定義文件的提交都產生新的管線版本。SageMaker Pipelines 原生支援管線版本控制——UpsertPipeline 遞增版本計數器，管線執行引用它們執行時的版本。這提供了可重現性：重新執行六個月前的執行時使用的是當時的管線定義，而非當前的。

在 CI/CD 中測試 ML 模型——Smoke、Shadow、Canary

預生產測試以 ML 特有的考量擴展了標準 CI/CD 測試模式。

Smoke 測試

Smoke 測試以一組已知輸入/輸出配對呼叫新端點，並驗證預測在容差範圍內匹配。在 CodePipeline 的 Build 階段於部署前執行。捕捉容器打包錯誤、模型產出物遺失和 schema 不匹配。

Shadow 部署

Shadow 部署將重複的即時流量路由到新模型（同時與生產模型並行），但丟棄新模型的預測。新模型的預測被記錄下來，並在線下與生產模型的預測和真實標注進行比較。這捕捉對單元測試和 smoke 測試都不可見的回歸錯誤，因為那些錯誤只在真實生產流量上才會出現。

Canary 部署

Canary 部署將少量百分比（通常 5%）的即時流量轉移到新模型，並監控錯誤率、延遲和預測分佈指標。設定了金絲雀流量轉移和 CloudWatch 告警的 SageMaker Deployment Guardrails，在金絲雀視窗期間任何告警觸發時都會自動回滾。金絲雀視窗成功完成後，流量轉移到 100%。

使用 Production Variants 進行 A/B 測試

多個模型版本同時託管在一個端點上，流量在它們之間按權重分配。用於線上學習場景，其中業務指標（轉換率、每次會話收入）的統計顯著性驅動模型選擇。

MLA-C01 ML CI/CD 常見考試陷阱

陷阱一——CodePipeline 取代 SageMaker Pipelines

錯誤。兩者互補。CodePipeline 處理外層軟體工程 CI/CD；SageMaker Pipelines 處理內層 ML 工作流程編排。兩者都用。

陷阱二——審核閘道放在訓練之前

錯誤。審核評估的是訓練好的模型指標。應放在評估之後、部署之前。

陷阱三——輪詢 SageMaker API 等待狀態變更

錯誤。SageMaker 發出 EventBridge 事件。使用基於規則的觸發器，而非輪詢。

陷阱四——排程再訓練總是優於漂移驅動

錯誤。排程再訓練在資料穩定時浪費計算資源，在漂移加速時又反應太慢。透過 Model Monitor 的漂移驅動是推薦模式；排程是在 Monitor 未設定時的備用方案。

陷阱五——手動審核總是必要的

錯誤。在受監管行業和生產部署中需要手動審核。較低風險的環境（開發、暫存）可以透過 Lambda 使用自動指標門檻審核。

陷阱六——CodeBuild 執行完整訓練任務

錯誤。CodeBuild 執行單元測試、容器建置、合成資料整合測試。完整訓練（需要 GPU 和數小時）在 CodePipeline Train 階段內的 SageMaker Pipeline 中呼叫的 SageMaker 訓練任務中執行。

陷阱七——所有環境使用一個 CodePipeline

錯誤。推薦模式是每個環境（開發、暫存、生產）一個 CodePipeline，共享通用的 CodeBuild 專案和範本，管線之間的晉升由審核閘道觸發。單一管線多環境會引入危險的跨環境副作用。

陷阱八——Model Registry 狀態自動部署

錯誤。ModelApprovalStatus = Approved 不會自動部署。部署需要在審核事件上有 EventBridge 規則觸發 CodePipeline，或手動進行階段轉換。

FAQ——MLA-C01 ML CI/CD 熱門問題

Q1——CodePipeline 和 SageMaker Pipelines 在角色上有何不同，各自何時使用？

CodePipeline 是外層軟體工程 CI/CD 編排器，具有 Source、Build、Test、Approve、Deploy 等階段，並與 CodeBuild、CodeDeploy、CloudFormation 和第三方工具整合。SageMaker Pipelines 是內層 ML 工作流程編排器，具有 CodePipeline 無法原生表達的 Processing、Training、Tuning、Transform、RegisterModel 和 ConditionStep 等步驟類型。使用 CodePipeline 作為原始碼拉取、程式碼測試、基礎設施配置、手動審核和部署的外層包裝。在 CodePipeline 的 Train 階段內使用 SageMaker Pipelines 進行 ML 特有的編排。MLA-C01 考試持續測試這個區別；單一工具答案是錯的，使用兩者的分層架構是正確答案。

Q2——偵測到生產資料漂移時如何觸發自動再訓練？

標準模式：SageMaker Model Monitor 執行排程任務偵測漂移並發出 CloudWatch 指標。當違規超過門檻時，CloudWatch 告警轉換到 ALARM 狀態。EventBridge 規則符合告警狀態變更事件並呼叫 Lambda 函數。Lambda 以指示漂移類型的參數呼叫 SageMaker StartPipelineExecution。管線再訓練、評估並註冊新模型包，然後觸發手動審核或透過 CodePipeline 進行自動部署。這是一個六服務鏈（Monitor → CloudWatch → EventBridge → Lambda → SageMaker Pipelines → Model Registry → CodePipeline），是 Domain 3 中測試最頻繁的工作流程。

Q3——在生產 ML CI/CD 管線中，手動審核閘道應放在哪裡？

在模型評估之後、生產部署之前。具體地說，閘道應在 SageMaker Pipeline 以 PendingManualApproval 狀態在 Model Registry 中註冊新模型包後觸發，閘道應向審核者顯示評估指標、模型卡和血緣資料。批准將模型包移動到 Approved 狀態，這透過 EventBridge 規則觸發 CodePipeline 部署階段。在訓練之前放置閘道使其失去意義，因為審核者沒有指標可以評估。在部署之後放置閘道會造成風險，因為模型在審核完成前已經服務流量。

Q4——如何在開發、暫存和生產帳戶之間共享核准的模型？

透過 Resource Access Manager（RAM）使用跨帳戶 Model Registry 共享。在中央登錄帳戶（通常是安全或稽核帳戶，或專用 MLOps 帳戶）建立模型包群組。透過 RAM 將模型包群組共享給消費者帳戶（暫存和生產）。每個消費者帳戶中的 CodePipeline 在呼叫 SageMaker UpdateEndpoint 時引用跨帳戶模型包 ARN。跨帳戶 Model Registry 加上 RAM 共享是 AWS 推薦的模式。

Q5——什麼測試應該在 CodeBuild 中執行，什麼應該在 SageMaker Pipelines 中執行？

CodeBuild 執行快速、基礎設施成本低的測試：Python 函數的單元測試、用 Great Expectations 對訓練資料進行 schema 驗證、Dockerfile 程式碼審查、容器漏洞掃描、在小型實例上使用合成資料的整合測試、針對暫存端點的 smoke 測試。CodeBuild 不執行完整訓練（太慢，需要 GPU）或完整資料品質檢查（太消耗記憶體）。SageMaker Pipelines 執行高成本 ML 計算：用於完整資料品質檢查的 SageMaker Processing 任務、用於實際模型擬合的 Training 任務（可能在 GPU 叢集上）、用於超參數優化的 Tuning 任務、用於公平性指標的 Clarify 處理、Model Monitor 基準計算。分工原則是「快速低成本放 CodeBuild；昂貴 ML 計算放 SageMaker Pipelines」。

Q6——如何防止失控的再訓練（例如，不穩定的漂移信號每 10 分鐘觸發一次訓練）？

三個防護措施。首先，EventBridge 觸發的 Lambda 實作最小間隔防抖——從 DynamoDB 或 Parameter Store 讀取上次訓練執行的時間戳，如果距上次執行不足 N 小時則拒絕啟動新執行。其次，SageMaker Pipeline ConditionStep 評估新模型是否比當前生產模型有意義地好（例如，AUC 必須至少提升 0.02），否則讓管線失敗，防止無休止地註冊邊際差異模型。第三，設定 CloudWatch 告警遲滯（Datapoints to Alarm = 5 中的 3），使單個嘈雜資料點不會觸發告警。有了這三個防護措施，再訓練迴圈對不穩定的漂移信號是健壯的。

Q7——如何使整個 ML CI/CD 管線在六個月後可重現以供稽核？

固定所有版本並在 Model Registry 元資料中儲存所有內容。固定 CodeBuild 映像標籤、requirements.txt 中所有 Python 相依套件版本、ECR 中的訓練容器映像標籤、Git 中的來源 commit SHA、訓練資料 S3 版本（訓練資料桶上啟用 S3 版本控制）。將所有這些固定版本作為模型包的自訂元資料屬性儲存在 Model Registry 中——TrainingDataS3VersionId、ContainerImageDigest、CodeCommitId、BuildSpecVersion、RequirementsHash。要重新產生：拉取模型包，檢索元資料，切換到相應 commit，還原資料版本，以對應的 digest 重建容器，並以記錄的參數重新執行 SageMaker Pipeline。這是 MLA-C01 考試期望你知道的稽核等級可重現性標準。

延伸閱讀——官方 AWS 文件

超出 MLA-C01 範圍的深度，權威 AWS 來源包括：AWS CodePipeline 使用者指南（特別是手動審核和 CloudFormation 部署部分）、AWS CodeBuild 使用者指南（buildspec 參考、Docker 自訂映像）、Amazon SageMaker 開發人員指南（Pipelines 部分、Projects 部分、Model Registry 部分、使用 EventBridge 自動化部分）、ML 在 AWS 上持續交付 MLOps 白皮書，以及 AWS Well-Architected 機器學習專題（部署自動化支柱）。