ML 開發生命週期

ML 開發生命週期（ML development lifecycle）是一套九階段的端對端流程，能把一個商業問題轉化為持續創造價值的生產級機器學習系統。對於 AIF-C01 考生而言，熟練掌握 ML 開發生命週期的相關詞彙，是 Domain 1 任務說明 1.3 的核心關鍵，而且它悄悄地支撐著每個其他 Domain 的考題——因為每個 Amazon SageMaker 服務、每個 Bedrock 微調決策、以及每個負責任 AI 控制措施，都插接在 ML 開發生命週期的某個階段之中。

本指南完整走訪 ML 開發生命週期的每個階段——商業問題定義、資料收集、資料準備、feature engineering（特徵工程）、model training（模型訓練）、evaluation（模型評估）、deployment（部署）、monitoring（監控）、re-training（再訓練）——並對照傳統軟體開發生命週期（SDLC）的差異，說明在大規模場景下自動化 ML 開發生命週期的 MLOps 原則，將每個階段對應至正確的 AWS 服務，並說明負責任 AI 查核點的位置。讀完本文，你將能看到任何 AIF-C01 ML 開發生命週期題目，並立刻辨識出該情境所指向的具體階段。

什麼是 ML 開發生命週期？

ML 開發生命週期是一個組織用來設計、建構、驗證、部署、操作和維護機器學習模型的結構化階段序列。與一次性的資料科學 notebook 實驗不同，ML 開發生命週期將模型視為長期存活的生產資產，必須經過版本控制、監控、再訓練，最終退役。Amazon SageMaker 文件以及 AWS Machine Learning Lens 將 ML 開發生命週期正式化為可在 AIF-C01 直接考核的具體階段。

在最抽象的層次上，ML 開發生命週期建立在三個反覆出現的核心理念之上：

1. 資料優先 — 模型的品質取決於訓練它的資料，因此九個 ML 開發生命週期階段中，有四個階段圍繞著資料展開。
2. 評估閘門 — ML 開發生命週期的每個階段都以一個決策（繼續 / 修改 / 放棄）結束，而不是直接移交給下一關。
3. 閉環迴路 — 生產環境的監控回饋至再訓練，使 ML 開發生命週期成為一個迴路，而非單向瀑布流。

理解 ML 開發生命週期，意味著能將任何真實世界的情境（「上週模型準確率下降了」）對應到正確的階段（「監控偵測到漂移——觸發再訓練」）。AIF-C01 考試幾乎不會孤立地考查抽象定義，而是呈現一個症狀，再問哪個 ML 開發生命週期階段負責修復。

為什麼 AIF-C01 考試重視這個主題

AIF-C01 是一張基礎級 AI 認證，但 Domain 1 將考試的 20% 配置給 ML 與 AI 基礎知識，而任務說明 1.3（「描述 ML 開發生命週期」）是該 Domain 三大支柱之一。在 65 題的 AIF-C01 考試中，預期有 4 到 6 題直接考查 ML 開發生命週期的階段辨識能力。熟記精確的階段名稱，能幫助考生避開最常見的陷阱：選了一個聽起來合理、但 AWS 並未使用的說法，例如以「資料驗證」代替 AWS 正式稱謂的「資料準備」。

這個主題如何串接 AIF-C01 的其他內容

ML 開發生命週期的討論並不孤立存在，它是以下概念的根本：

• Amazon SageMaker 平台知識（每個 SageMaker 功能都對應一個或多個階段）
• Foundation model evaluation（基礎模型評估）（evaluation 階段在 FM 場景的特殊化）
• 負責任 AI 工具（Clarify、Model Monitor、A2I 各自插入特定階段）
• Fine-tuning（微調）vs in-context learning（情境學習）（微調是一種特殊的再訓練迴路）

ML 開發生命週期 vs 傳統軟體開發生命週期（SDLC）

傳統軟體只有單一產物——程式碼——以及由人類需求驅動的線性變更週期。ML 開發生命週期有三個相互糾纏的產物——程式碼、資料與訓練好的模型——其變更週期可能由團隊從未撰寫程式碼的資料偏移所觸發。AIF-C01 經常測試這個差異，因為有軟體工程背景的考生往往錯誤套用 SDLC 的直覺。

三個產物，不是一個

在 SDLC 中，唯一需要版本控制的產物是原始碼。在 ML 開發生命週期中，三個產物必須一起進行版本控制：

• 程式碼（training scripts、feature pipelines、inference 邏輯）
• 資料（訓練資料集、驗證資料集、標籤定義）
• 模型（訓練完成的權重、hyperparameter（超參數）、評估指標）

一次可重現的訓練執行，需要三者保持在相同的版本。SageMaker Model Registry 與 SageMaker ML Lineage Tracking 的存在，正是為了填補這個缺口。

非確定性輸出

傳統軟體對相同輸入產生相同輸出。ML 開發生命週期產生的是機率性輸出：即使程式碼沒有改變，再訓練後的同一個模型對相同的使用者查詢，也可能給出不同答案。因此，ML 開發生命週期中的測試是統計性的（準確率門檻值、混淆矩陣），而非通過╱失敗的單元測試。

隨時間衰退

軟體不會因為外部世界改變而「腐爛」；但已部署的 ML 模型會。ML 開發生命週期必須監控 data drift（資料漂移）和 model drift（模型漂移）——這是 SDLC 中完全不存在的現象。再訓練不是功能增強，而是預防性維護。

資料相依性

SDLC 的部署需要二進位檔案與設定檔。ML 開發生命週期的部署，則需要在模型上線後數個月，仍能證明訓練資料集的完整性、標籤品質，以及隱私合規性。因此，資料血緣（data lineage）在 ML 開發生命週期中是第一優先關注事項，而在 SDLC 中則不然。

白話文解釋 ML 開發生命週期

只要停止思考梯度下降，改用日常生活的事物來理解，ML 開發生命週期就會變得一目了然。以下三個符合台灣文化脈絡的類比，讓各階段深刻難忘。

夜市攤位的類比

在夜市開一攤滷肉飯，不是煮一碗飯就結束。它是一個生命週期：決定賣什麼（商業問題定義）、到批發市場採購食材（資料收集）、洗菜、切蔥、挑豬肉的肥瘦比例（資料準備）、研究滷包配方、調整辛香料比例讓滷汁更有層次（feature engineering，特徵工程）、開爐試煮（model training，模型訓練）、讓家人試吃確認口味（evaluation，模型評估）、正式開攤賣給客人（deployment，部署）、觀察客人回饋與衛生局稽查（monitoring，監控）、季節換了、豬肉漲價或客人口味改變就調整配方（re-training，再訓練）。ML 開發生命週期的每個階段都在這個夜市攤位的類比中有直接對應。跳過試吃步驟，客人就會第一個發現鹹淡不對；跳過監控，攤位悄悄流失回頭客而渾然不知。

健保醫療資料庫的類比

台灣健保署管理全民健保資料庫，是全球最完整的醫療大數據之一，它也運作著一個持續的生命週期。首先確立研究方向——例如預測糖尿病高風險族群（商業問題定義）；向各大醫院申請就診紀錄與檢驗數值（資料收集）；剔除重複就診紀錄、補齊缺漏欄位、統一計量單位（資料準備）；從原始診斷碼中萃取「近一年就診次數」、「HbA1c 趨勢」等有意義的變數（feature engineering）；用這些變數訓練預測模型（model training）；比較不同年齡層、城鄉地區的預測準確率是否公平一致（evaluation）；將風險預測介接至家醫科診間系統（deployment）；定期追蹤預測結果是否因生活型態改變而偏離（monitoring）；每年新增一個世代的資料後重新訓練（re-training）。ML 開發生命週期就是這套嚴謹的公衛研究流程，套用至一切預測任務的通用版本。

台積電晶圓廠良率管理的類比

晶圓製造不只是把晶片做出來，更需要持續提升良率——這正是 ML 開發生命週期的完整體現。工程師定義目標良率並釐清哪些製程參數影響最大（商業問題定義）；從設備感測器蒐集每批次的溫度、壓力、化學品濃度等數據（資料收集）；清除感測器異常值、對齊不同設備的時間戳記（資料準備）；將原始感測器數列轉化為「移動平均偏差」、「批次間相關性」等高階特徵（feature engineering）；訓練良率預測模型（model training）；在測試批次上驗證預測準確率、確認對不同製程節點都公平有效（evaluation）；將模型接入即時製造執行系統（deployment）；即時監看每批次的輸入分布是否偏離訓練基準（monitoring）；當新製程節點導入或設備老化後，以新數據重新訓練（re-training）。在晶圓廠，跳過監控就等於讓良率悄悄下滑，這與放棄 ML 開發生命週期監控所造成的後果完全相同。

考試當天選用哪個類比

三個類比從不同角度描述相同的 ML 開發生命週期。依照題目情境的措辭選擇最合適的一個：

• 情境關於食譜迭代、試吃再調整、上桌前把關 → 夜市攤位類比
• 情境關於標籤、原始輸入的組織整理、大型資料庫管理 → 健保資料庫類比
• 情境關於長期維護、漂移、設備老化、定期重新校正 → 台積電晶圓廠類比

核心運作原則：ML 開發生命週期的九大階段

ML 開發生命週期在 SageMaker 文件和 AWS Machine Learning Lens 中，被正式表述為九個依序進行的階段。AIF-C01 的考題幾乎逐字引用這些階段名稱，因此熟記確切措辭是效益最高的備考任務。

第一階段：商業問題定義（Business Problem Framing）

ML 開發生命週期從商業問題出發，而不是從資料集出發。在撰寫任何程式碼之前，團隊必須先判斷 ML 是否真的是正確的工具。關鍵問題包括：正在做什麼決策？預測錯誤的成本與漏報的成本各是多少？真實答案（ground truth）是否可觀測？是否有足夠的歷史資料？許多 ML 開發生命週期的失敗，都可追溯到跳過這個階段，從恰好手邊有的資料直接開始。

第一階段的交付物包括：問題類型（分類、迴歸、分群、生成）、與商業成效對齊的成功指標（例如「將客戶流失率降低 5 個百分點」），以及明確的非目標範圍。

第二階段：資料收集（Data Collection）

問題定義完成後，ML 開發生命週期進入取得原始材料的階段：資料。來源包括交易資料庫、應用程式日誌、第三方資料串流、人工標注資料集，以及公開語料庫。監督式學習的收集階段必須包含標籤；非監督式學習只需原始資料；生成式 AI 則需要用於 RAG grounding 的領域文件，或用於 instruction tuning 的微調配對資料。

涉及的 AWS 服務：作為標準資料湖的 Amazon S3、用於資料擷取的 AWS Glue、提供人工與 ML 輔助標注管理的 Amazon SageMaker Ground Truth，以及用於串流資料的 Amazon Kinesis 與 Amazon MSK。

第三階段：資料準備（Data Preparation，清洗與轉換）

原始資料都是「髒的」。ML 開發生命週期的資料準備階段負責清除缺失值、移除重複資料、標準化單位、統一格式、平衡類別分布，並將資料集切分為 training（訓練）、validation（驗證）與 test（測試）三個子集。這個階段通常佔資料科學家 60 到 80% 的時間，也是 AIF-C01 測試最多的階段——因為每一道「模型對某個族群表現較差」的陷阱題，都可以追溯到資料準備的失誤。

涉及的 AWS 服務：Amazon SageMaker Data Wrangler（低程式碼資料準備工具，內建超過 300 種轉換）、AWS Glue DataBrew（適合商業分析師的視覺化資料清洗工具），以及用於 SQL 型探索的 Amazon Athena。

第四階段：Feature Engineering（特徵工程）

Feature engineering（特徵工程）是將原始資料轉化為有意義輸入的創造性工藝。一個時間戳記可以變成「星期幾」、「當天第幾小時」、「是否為假日」。一個自由文字格式的地址可以變成郵遞區號、城市層級、距最近門市的距離。一位使用者的購買紀錄可以變成滾動式的 30 天平均購物車金額。在 ML 開發生命週期中，feature engineering 對最終準確率的影響，往往大過演算法的選擇。

涉及的 AWS 服務：Amazon SageMaker Feature Store（集中化、版本化的特徵儲存庫，可在 training 與 inference 之間共用）、SageMaker Data Wrangler（可將工程化好的 features 直接匯出至 Feature Store），以及用於即時特徵計算的 AWS Lambda。

第五階段：Model Training（模型訓練）

備妥特徵後，ML 開發生命週期進入 model training（模型訓練）。團隊選擇演算法或 foundation model，設定 hyperparameter（超參數），分配運算資源（CPU、GPU，或 AWS Trainium），然後執行訓練任務。隨著 hyperparameter 的調整，training 可能迭代數十次。對於 foundation models，這個階段包含預訓練（pre-training）、繼續預訓練（continued pre-training）、fine-tuning（微調），或 RLHF（reinforcement learning from human feedback，來自人類回饋的強化學習）。

涉及的 AWS 服務：Amazon SageMaker Training Jobs（管理型分散式訓練，支援 CPU、GPU、Trainium）、SageMaker JumpStart（預訓練模型與解決方案範本；也是 foundation model 微調的起點）、SageMaker Automatic Model Tuning（Bayesian hyperparameter 搜尋）、SageMaker Experiments（追蹤每次訓練執行的參數與指標），以及 Amazon Bedrock fine-tuning（針對支援的 foundation models 提供管理型微調）。

第六階段：Model Evaluation（模型評估）

Training 產出權重；ML 開發生命週期在對這些權重在 held-out 資料上完成評估之前，不會信任它們。評估指標依任務而定：分類任務使用準確率、精確率、召回率、F1、AUC-ROC；迴歸任務使用 MAE、RMSE、R²；文字生成任務使用 ROUGE、BLEU、BERTScore、perplexity；圖像生成任務使用 inception score 與 FID。Evaluation 還包括跨人口統計群體的公平性指標——這是一個負責任 AI 查核點。

涉及的 AWS 服務：Amazon SageMaker Clarify（bias 偵測與可解釋性分析）、Amazon Bedrock Model Evaluation（針對 FM 的自動化與人工評估任務），以及用於跨執行比較指標的 SageMaker Experiments。

第七階段：Deployment（部署）

驗證合格的模型必須送到使用者手中。ML 開發生命週期的 deployment 階段涵蓋封裝、托管、暴露 inference API，以及流量路由。Deployment 模式包括：real-time endpoints（低延遲、持續運行）、batch transform（對大型資料集進行排程評分）、serverless inference（適用於流量突發但量少的工作負載），以及 asynchronous inference（用於長時間執行、payload 最大 1 GB 的預測）。

漸進式發布策略可防範不良部署：canary（將 5% 流量路由至新模型，觀察指標後再擴大）、blue-green（同時啟動新版本與舊版本，再一次性切換全部流量），以及 shadow deployment（將流量鏡射至新模型，但仍回傳舊模型的答案給使用者，同時在背景比較兩者結果）。

涉及的 AWS 服務：Amazon SageMaker Endpoints（real-time、serverless、async、batch）、Amazon Bedrock（管理型 FM inference）、SageMaker Model Registry（核准並追蹤可部署的模型版本），以及 AWS CodePipeline（部署自動化）。

第八階段：Monitoring（監控）

模型上線後，ML 開發生命週期進入持續監控。模型會被監控四種不同的失效模式：

• Data quality drift（資料品質漂移） — 輸入分布偏離訓練時的基準線
• Model quality drift（模型品質漂移） — 預測準確率相對於回饋訊號而下降
• Bias drift（偏差漂移） — 公平性指標在不同人口統計群體之間出現分歧
• Feature attribution drift（特徵歸因漂移） — 可解釋性結果發生偏移，暗示模型可能學習到了新的、可能是虛假的模式

Monitoring 並非可選項——它是將 ML 開發生命週期從瀑布式轉為閉環迴路的關鍵階段。

涉及的 AWS 服務：Amazon SageMaker Model Monitor（標準服務，提供與四種漂移類別對應的四種監控器類型）、Amazon CloudWatch（用於延遲、錯誤率、呼叫次數等維運指標），以及 AWS Lambda（用於客製化監控邏輯）。

第九階段：Re-Training（再訓練）

當 monitoring 發現模型漂移超過容忍度時，ML 開發生命週期就會回到起點。再訓練可由排程觸發（每月、每季）、由漂移閾值觸發（準確率下降 2 個百分點），或由概念變化觸發（新產品類別上線）。再訓練並非一次性事件；在成熟的 MLOps 運作中，它是一條全自動化的 pipeline，用新資料重新執行 ML 開發生命週期的每個階段。

涉及的 AWS 服務：Amazon SageMaker Pipelines（自動化再訓練工作流程的標準協調服務）、AWS Step Functions（客製化協調），以及 Amazon EventBridge（事件驅動的再訓練觸發器）。

九大階段如何分為三個群集

將 ML 開發生命週期的九個階段分成三個 meta 群集，有助於記憶：

• 資料群集：第 1–4 階段（商業問題定義、收集、準備、feature engineering）
• 模型群集：第 5–6 階段（training、evaluation）
• 維運群集：第 7–9 階段（deployment、monitoring、re-training）

AIF-C01 鮮少考查同一群集「內部」的銜接；它大量考查群集「之間」的轉換（尤其是資料到模型，以及評估到部署之間）。

MLOps：將 ML 開發生命週期系統化運作

MLOps 是自動化 ML 開發生命週期的學科，使再訓練、再評估與再部署能以業務所需的速度可靠地進行。AIF-C01 要求對 MLOps 原則有概念性的熟悉，儘管深度實作題屬於 AIP-C01 的範疇。

CI/CD for Models — 不只是為了程式碼

在傳統軟體 CI/CD 中，一次 code commit 觸發單元測試、建置與部署。在 MLOps 中，一次 code commit、一次資料版本變更，或一次漂移警報，都能觸發同樣的 pipeline。Pipeline 端對端重新執行 ML 開發生命週期的各個階段——資料準備、training、evaluation、deployment。Amazon SageMaker Pipelines 正是圍繞這個理念所打造的 AWS 原生服務，每個 pipeline 步驟都會產出被追蹤的 artifacts（資料集版本、模型版本、evaluation 報告）。

版本控制一切

MLOps 要求 ML 開發生命週期中的每個 artifact 都一起進行版本控制：

• 原始碼 → Git（AWS CodeCommit、GitHub）
• 訓練資料集 → S3 versioning、Feature Store versions、LakeFS 或 DVC
• 訓練好的模型 → SageMaker Model Registry（含語意版本號、核准狀態與 lineage）
• 設定檔 → infrastructure-as-code（AWS CDK、Terraform、CloudFormation）

若三個 artifacts 的版本控制未同步，要重現生產環境事故將變得不可能。

可重現性（Reproducibility）

一條可重現的 ML 開發生命週期 pipeline 意味著：相同的程式碼＋資料＋hyperparameter＋隨機種子，數個月後仍能產出相同的模型權重與相同的評估指標。可重現性對受監管的行業（金融、醫療）而言是不可妥協的要求，因為稽核時可能需要重新執行歷史訓練任務。SageMaker ML Lineage Tracking 記錄了資料、程式碼、訓練任務與模型 artifacts 所構成的 DAG，供日後重播之用。

自動化與協調（Automation and Orchestration）

手動步驟是 ML 開發生命週期的大敵。MLOps 以下列方式取代手動步驟：

• 協調器（SageMaker Pipelines、Step Functions、Airflow on EC2）——串連各階段
• 排程觸發器（EventBridge cron）——按週期進行再訓練
• 漂移驅動觸發器（Model Monitor → EventBridge → Pipeline execution）——依訊號觸發再訓練
• 核准閘門（Model Registry approval workflows）——需要人工監督的情境

持續訓練（CT）vs 持續整合（CI）vs 持續部署（CD）

MLOps 在 DevOps 詞彙表中新增了一個「C」：

• CI — 測試程式碼（與傳統 DevOps 相同）
• CD — 自動化部署（與傳統 DevOps 相同）
• CT — continuous training（持續訓練）：自動化再訓練，作為 ML 開發生命週期迴路的一部分

AWS 服務與 ML 開發生命週期各階段的對應

AIF-C01 頻繁考查服務到階段的對應關係。請記住 ML 開發生命週期每個階段的標準工具，以及常見的干擾選項。

資料收集階段服務

• Amazon S3 — 原始儲存
• AWS Glue — ETL 任務與資料編目
• Amazon SageMaker Ground Truth — 管理型人工標注（SageMaker Ground Truth Plus 為全託管變體）
• Amazon Kinesis / Amazon MSK — 串流資料擷取
• Amazon AppFlow — SaaS 到 AWS 的資料傳輸（Salesforce、ServiceNow）

資料準備階段服務

• Amazon SageMaker Data Wrangler — 標準低程式碼資料準備工具；內建超過 300 種轉換
• AWS Glue DataBrew — 適合商業分析師的視覺化資料清洗工具
• Amazon Athena — 無伺服器 SQL 探索
• Amazon EMR — 大規模 Spark/Hadoop 處理

Feature Engineering 階段服務

• Amazon SageMaker Feature Store — 集中化特徵儲存庫，提供 online store 與 offline store
• SageMaker Data Wrangler — 將工程化的 features 匯出至 Feature Store
• AWS Lambda — inference 時的即時特徵計算

Training 階段服務

• Amazon SageMaker Training Jobs — 管理型分散式訓練，支援 CPU、GPU、Trainium
• SageMaker JumpStart — 預訓練模型與解決方案範本；foundation model 微調的入口
• SageMaker Automatic Model Tuning（Hyperparameter Tuning） — Bayesian hyperparameter 最佳搜尋
• SageMaker Experiments — 追蹤執行紀錄、參數、指標、artifacts
• SageMaker Studio — 撰寫與除錯 training 的 IDE
• SageMaker Canvas — 適合商業用戶的無程式碼 AutoML
• Amazon Bedrock fine-tuning — 針對支援的 foundation models 的管理型微調

Evaluation 階段服務

• Amazon SageMaker Clarify — bias 偵測（訓練前與訓練後）及基於 SHAP 的可解釋性分析
• Amazon Bedrock Model Evaluation — 針對 FM 的自動化與人工評估任務
• SageMaker Experiments — 跨執行比較指標

Deployment 階段服務

• Amazon SageMaker Endpoints — real-time、serverless、async 與 batch transform inference
• Amazon SageMaker Model Registry — 核准閘門；儲存含 lineage 的可部署模型版本
• Amazon Bedrock — foundation models 的管理型 inference（無需管理 endpoint）
• Amazon SageMaker Multi-Model Endpoints — 在單一 endpoint 後托管多個模型以節省成本

Monitoring 階段服務

• Amazon SageMaker Model Monitor — 四種監控器類型：data quality、model quality、bias drift、feature attribution drift
• Amazon CloudWatch — 維運指標（延遲、錯誤率、throttles）
• AWS CloudTrail — 用於治理的 API 呼叫稽核記錄

Re-Training 階段服務

• Amazon SageMaker Pipelines — 標準協調服務；涵蓋 ML 開發生命週期各步驟的 DAG
• Amazon EventBridge — 漂移觸發或排程觸發的再訓練事件
• AWS Step Functions — 超越 SageMaker Pipelines 的客製化協調

Model Drift 與 Data Drift 偵測

ML 開發生命週期之所以是個迴路，正是因為模型會衰退。AIF-C01 考查兩種截然不同的衰退現象，考生經常將它們混淆。

Data Drift（資料漂移，Covariate Shift）

Data drift 發生在輸入特徵的分布隨時間改變之時。模型對看起來像訓練資料的輸入仍能準確預測；問題在於生產環境的輸入已不再像訓練資料。範例：一個在 2020 年前訓練的信用評分模型，現在遇到遠端工作收入模式與實體辦公室薪資結構截然不同的申請人。

Data drift 在不需要真實標籤（ground-truth labels）的情況下即可測量——只需比較輸入分布。Amazon SageMaker Model Monitor 的「data quality」監控器，會藉由將即時輸入統計數據與訓練時的基準線比較來處理這個問題。

Model Drift（模型漂移，Concept Drift）

Model drift 發生在特徵與標籤之間的「關係」改變之時。輸入看起來可能與訓練資料一模一樣，但正確答案已經不同了。範例：一個詐欺偵測模型看到相同的交易模式，但「詐欺」的定義已隨著詐騙者的適應而演進。

Model drift 只有在取得生產環境真實標籤（透過回饋迴路、人工審查或延遲 ground truth）之後才能測量。SageMaker Model Monitor 的「model quality」監控器負責處理這個問題。

Bias Drift 與 Feature Attribution Drift

兩個較微妙的漂移類別，使 ML 開發生命週期的監控故事更加完整：

• Bias drift（偏差漂移） — 部署後公平性指標在不同人口統計群體之間出現分歧（由 SageMaker Model Monitor 的 bias 監控器測量，底層由 Clarify 提供支援）
• Feature attribution drift（特徵歸因漂移） — 模型最依賴的特徵已發生偏移，暗示它可能學習到了虛假的新模式（由 Model Monitor 的可解釋性監控器測量，同樣由 Clarify 提供支援）

記住四種漂移類型

偵測節奏與再訓練觸發設計

並非每個漂移事件都應觸發再訓練。ML 開發生命週期的設計決策在於容忍度閾值的設定：

• 過於敏感 → 持續再訓練、運算成本爆炸、生產環境模型頻繁切換
• 過於寬鬆 → 使用者體驗在團隊反應之前就已劣化

成熟的 MLOps pipeline 會針對不同漂移類型設定不同閾值（例如，準確率下降超過 2 個百分點觸發再訓練；單純的 data drift 觸發調查）。

負責任 AI 在 ML 開發生命週期中的查核點

負責任 AI 不是獨立的生命週期；它是一組貫穿 ML 開發生命週期的查核點。AIF-C01 Domain 4 考查考生對這些查核點位置的了解。

查核點一：商業問題定義 — 傷害分析

在收集任何資料之前，ML 開發生命週期的商業問題定義階段必須回答：錯誤的預測可能傷害誰？這個使用案例在 EU AI Act 下是否屬於高風險？此決策是否影響信用、住房、就業或醫療保健的取得？輸出的結果是一個風險等級，決定了後續流程的嚴謹程度。

查核點二：資料收集 — 同意授權、資料來源與 PII

資料收集階段必須驗證個人資料的同意授權、記錄資料來源（每個資料集來自哪裡、在什麼授權下取得），以及偵測 PII（個人識別資訊）。Amazon Macie 在資料餵入 training 之前，掃描 S3 中的 PII。Amazon Comprehend 偵測自由文字文件中的 PII。

查核點三：資料準備 — 代表性稽核

在 training 之前，ML 開發生命週期必須稽核資料集中是否有代表性不足的群體。SageMaker Clarify 的訓練前 bias 報告計算類別不平衡、人口統計群體之間的 Kullback-Leibler 散度，以及標籤不平衡等指標。在這裡發現 bias，比部署後才發現便宜了幾個數量級。

查核點四：Model Training — Instruction Tuning 與 RLHF

對於 foundation models，ML 開發生命週期的 training 階段包含對齊（alignment）：instruction tuning 讓模型學會遵循指令，RLHF（reinforcement learning from human feedback，來自人類回饋的強化學習）讓模型與人類偏好對齊。兩者都是嵌入模型本身的負責任 AI 控制措施。

查核點五：Evaluation — 公平性指標與 Model Cards

部署前的 evaluation 必須在準確率之外，同時計算公平性指標。SageMaker Clarify 的訓練後 bias 報告計算 disparate impact（差異影響）、equal opportunity（機會均等）和 demographic parity（人口均等）。SageMaker Model Cards 產出一份結構化文件，記錄預定用途、訓練資料、評估結果和已知限制——這是 ML 開發生命週期的稽核 artifact。

查核點六：Deployment — Guardrails 與 Human-in-the-Loop

對於生成式 AI，Amazon Bedrock Guardrails 位於 deployment 端，負責過濾內容、遮蔽 PII、拒絕被封鎖的主題，以及執行 grounding 檢查。對於任何高風險的 inference，Amazon A2I（Augmented AI）會將低信心預測路由給人工審查者——這是嵌入 ML 開發生命週期 deployment 階段的負責任 AI 查核點。

查核點七：Monitoring — Bias Drift 與 Explainability Drift

四種 Model Monitor 類型中，有兩種明確是透過 ML 開發生命週期 monitoring 階段持續運行的負責任 AI 查核點。Bias drift 偵測確保公平性在部署後持續成立；feature attribution drift 偵測在模型開始依賴非預期特徵時發出警告（這可能是學習到捷徑或代理歧視的跡象）。

查核點八：Re-Training — 核准閘門

ML 開發生命週期的 re-training 階段不得自動升級一個通過準確率檢查、但未通過公平性檢查的模型。SageMaker Model Registry 支援核准工作流程，使再訓練的模型保持「待核准」狀態，直到負責任 AI 審查者簽字確認。這是 ML 開發生命週期的治理層閘門。

必背數字與限制

AIF-C01 會獎勵能背出少數幾個 ML 開發生命週期及其 AWS 工具的標準數字的考生。以下數字直接來自 AWS 文件與認證頁面。

ML 開發生命週期常見考試陷阱

數個陷阱模式在 AIF-C01 社群考試報告中反覆出現。每一個都涉及 ML 開發生命週期題目中的微妙措辭。

其他常見易錯陷阱模式

• **「跳過 evaluation 階段」**是 AIF-C01 的經典題型。答案永遠不是「為了加快部署而跳過 evaluation」——evaluation 是 ML 開發生命週期不可省略的階段。
• 「Feature Store ≠ Data Lake」 — Feature Store 存放工程化、隨時可被取用的 features；S3 存放原始資料。將原始 CSV 存入 Feature Store 是反模式（anti-pattern）。
• 「Ground Truth ≠ ground-truth labels」 — Amazon SageMaker Ground Truth 是標注服務；小寫的「ground truth」指的是任何資料集中的真實標籤。仔細閱讀題目。
• 「Model Registry ≠ Model Monitor」 — Registry 是核准模型版本的存放處；Monitor 是執行時期的漂移偵測器。

ML 開發生命週期 vs 傳統分析 Pipeline

直接比較能釐清 ML 開發生命週期在那些原本依賴 BI 儀表板與 SQL 報表的組織中取代了什麼。

輸出類型比較

工具比較

傳統分析仍然勝出的場景

ML 開發生命週期比傳統分析更為繁重。對於用良好索引的 SQL 查詢就能從歷史資料中回答的問題，執行 ML 模型是不必要的大材小用。ML 開發生命週期在以下情境才是合理的投資：決策必須基於從未見過的新資料（在流失發生前預測，而非在事後度量），或者規則複雜到無法手動撰寫。

考題連結：AIF-C01 Task 1.3 練習指引

AIF-C01 任務說明 1.3「描述 ML 開發生命週期」最常以階段辨識題和服務對應題來考查。以下練習題範本代表最常見的題型。附有完整解析的詳細練習題請見 ExamLab 題庫。

範本 A：從症狀辨識階段

某個已部署模型的準確率在過去一個月內下降了 6 個百分點，儘管程式碼沒有任何變更。ML 開發生命週期中的哪個階段負責回應？預期答案：monitoring（偵測）與 re-training（回應）。干擾選項通常包括「model training」（錯誤，因為只有在 monitoring 確認漂移之後才回到 training）和「deployment」（錯誤，因為部署已經完成了）。

範本 B：服務到階段的對應

某個團隊想要為物件偵測標注 100,000 張圖片的邊界框。哪個 AWS 服務屬於 ML 開發生命週期的這個階段？預期答案：Amazon SageMaker Ground Truth（資料收集╱標注）。這道題考查考生是否將 Ground Truth 與 Rekognition 混淆（Rekognition 是推論，不是標注）。

範本 C：漂移類型辨識

一個詐欺偵測模型的 precision 下降，但輸入交易分布看起來與訓練資料一模一樣。哪種漂移類型最可能發生？預期答案：model drift（concept drift）——輸入與詐欺標籤之間的關係已改變。Data drift 是常見的干擾選項。

範本 D：MLOps 自動化情境

某家公司希望每次向 training repository 提交新的 commit，都能自動觸發資料準備、training、evaluation 與條件式 deployment。哪個 AWS 服務負責協調？預期答案：Amazon SageMaker Pipelines。AWS Step Functions 是有效但較不具體的干擾選項；Jenkins 或 CodePipeline 是不含 ML 原生步驟的通用替代方案。

範本 E：負責任 AI 查核點位置

受監管行業要求在模型進入生產環境之前驗證公平性。ML 開發生命週期的哪個階段負責這項檢查，哪個 AWS 服務執行它？預期答案：model evaluation 階段，使用 Amazon SageMaker Clarify（訓練後 bias 報告）。加分答案：訓練前 bias 也應在資料準備階段進行檢查。

ML 開發生命週期常見問答（FAQ）

AIF-C01 中 ML 開發生命週期有哪些階段？

AIF-C01 的 ML 開發生命週期由 AWS Machine Learning Lens 及 SageMaker 開發者指南所記載的九個標準階段組成：商業問題定義、資料收集、資料準備、feature engineering（特徵工程）、model training（模型訓練）、model evaluation（模型評估）、deployment（部署）、monitoring（監控）與 re-training（再訓練）。AIF-C01 任務說明 1.3 考查你將症狀和 AWS 服務對應至這九個 ML 開發生命週期階段的能力。

ML 開發生命週期與軟體開發生命週期有何不同？

ML 開發生命週期與 SDLC 在三個關鍵面向上有所差異：它對三個 artifacts 進行版本控制（程式碼＋資料＋模型）、產出機率性而非確定性的輸出，以及因 data drift 和 concept drift 而隨時間衰退。因此，ML 開發生命週期是一個閉環迴路，具備 monitoring 和 re-training 階段，而這些在 SDLC 中完全沒有對應物。

ML 開發生命週期有幾個階段？

九個。標準的 ML 開發生命週期階段為：定義、收集、準備、feature engineering、training、evaluation、deployment、monitoring 與 re-training。部分 AWS 文件為了簡潔而將這些壓縮成較少的階段，但 AIF-C01 考題與 SageMaker 開發者指南中的九階段分解方式對齊。

Data drift 和 model drift 有什麼差別？

Data drift（covariate shift，協變量偏移）是輸入特徵分布隨時間改變；輸入與標籤之間的關係可能仍然有效。Model drift（concept drift，概念漂移）是輸入與目標標籤之間關係的改變；輸入看起來可能與訓練資料一模一樣，但正確答案已經不同了。兩者在 ML 開發生命週期的 monitoring 階段分別被監控——data drift 透過 SageMaker Model Monitor 的 data quality 監控器（不需要標籤），model drift 透過 model quality 監控器（需要標籤）。

我需要 ML 實作經驗才能通過 AIF-C01 的 ML 開發生命週期題目嗎？

不需要。AIF-C01 是一張基礎級 AI 認證，針對的是具備最多六個月 AWS AI 接觸經驗的考生，包含非工程職位。ML 開發生命週期的題目考查概念詞彙與服務到階段的對應，而非實作深度。話雖如此，在免費方案的 SageMaker Studio 上跑完一次使用內建演算法的端對端訓練，能非常有效地將生命週期的輪廓鞏固在記憶中，強烈建議一試。

MLOps 和 ML 開發生命週期有什麼關係？

MLOps 是讓 ML 開發生命週期系統化運作的自動化層。ML 開發生命週期描述了「必須發生什麼」（九個階段），而 MLOps 描述了「如何透過 CI/CD/CT pipeline、程式碼＋資料＋模型的版本控制，以及漂移到再訓練的閉環迴路，使這些階段可重複、可重現且可自動化」。Amazon SageMaker Pipelines 是圍繞 ML 開發生命週期所打造的 AWS 原生 MLOps 協調器。

每個 ML 開發生命週期階段對應哪個 SageMaker 服務？

精簡對應：資料收集 → SageMaker Ground Truth；資料準備 → SageMaker Data Wrangler；feature engineering → SageMaker Feature Store；training → SageMaker Training Jobs＋JumpStart＋Automatic Model Tuning；evaluation → SageMaker Clarify＋Experiments（FM 另加 Bedrock Model Evaluation）；deployment → SageMaker Endpoints＋Model Registry；monitoring → SageMaker Model Monitor；re-training 協調 → SageMaker Pipelines。背下這個一對一的對應表，就能回答 AIF-C01 上大多數的服務選擇題。

負責任 AI 檢查點在 ML 開發生命週期中的位置為何？

負責任 AI 以八個查核點的形式分散在 ML 開發生命週期各處，而非集中在單一階段。關鍵查核點包括：商業問題定義中的傷害分析、資料收集中的 PII 偵測（Macie、Comprehend）、資料準備中的訓練前 bias（Clarify）、evaluation 中的公平性指標加 Model Cards（Clarify）、deployment 中的 Guardrails 加 A2I，以及 monitoring 階段的 bias drift 監控（Model Monitor）。AIF-C01 考試的啟發式準則是：在 ML 開發生命週期中盡可能早地發現負責任 AI 問題，因為在部署後才修復的成本要高出幾個數量級。

模型應多頻繁進行再訓練？

沒有通用答案。ML 開發生命週期的 re-training 階段由三種訊號中的一種觸發：時間（每月或每季的排程節奏）、漂移（Model Monitor 偵測到 data 或 model quality 劣化），或概念變化（新產品上線、法規生效、季節性偏移）。成熟的 MLOps pipeline 透過 Amazon EventBridge 規則，將三種觸發器全部路由至 SageMaker Pipelines 的執行，同時支援。

延伸閱讀

• Amazon SageMaker — Machine Learning Lifecycle Concepts: https://docs.aws.amazon.com/sagemaker/latest/dg/how-it-works-mlconcepts.html
• AWS Well-Architected Framework — Machine Learning Lens: https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/machine-learning-lens.html
• MLOps: Emerging Trends in Data, Code, and Infrastructure (AWS Whitepaper): https://docs.aws.amazon.com/whitepapers/latest/mlops-framework-to-operationalize-ml/mlops-framework-to-operationalize-ml.html
• Amazon SageMaker Pipelines: https://docs.aws.amazon.com/sagemaker/latest/dg/pipelines.html
• Amazon SageMaker Model Monitor: https://docs.aws.amazon.com/sagemaker/latest/dg/model-monitor.html
• Amazon SageMaker Clarify: https://docs.aws.amazon.com/sagemaker/latest/dg/clarify-fairness-and-explainability.html
• Amazon SageMaker Data Wrangler: https://docs.aws.amazon.com/sagemaker/latest/dg/data-wrangler.html
• Amazon SageMaker Feature Store: https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html
• Amazon SageMaker Ground Truth: https://docs.aws.amazon.com/sagemaker/latest/dg/sms.html
• Amazon SageMaker Model Registry: https://docs.aws.amazon.com/sagemaker/latest/dg/model-registry.html
• AWS AIF-C01 Certification Page: https://aws.amazon.com/certification/certified-ai-practitioner/

相關 ExamLab 主題：AI 與 ML 核心概念、監督式、非監督式與強化學習、Amazon SageMaker 平台、Foundation Model Evaluation。