SageMaker Pipelines 是 MLA-C01 期望每位 ML Engineer 熟知的編排引擎——它是 AWS 原生的答案，解決「如何用可重現性、血緣追蹤和條件分支來自動化訓練→評估→登錄→部署的循環」。考試大量測試它，因為這也是排序和配對問題類型出現的地方：題幹呈現一個 pipeline 步驟列表，要求考生正確排序（Processing → Training → Evaluation → Condition → Register → Deploy），或將步驟類型與其用途配對（TrainingStep → 適配評估器，ConditionStep → 根據指標分支，RegisterModel → 添加到 registry）。排序和配對問題要求所有項目正確才能得分——不給部分分。記住標準步驟序列是強制的。
本指南涵蓋完整的 pipeline 步驟分類、參數和快取機制、依賴圖設計、與 Data Wrangler 和 Feature Store 的整合、用於再訓練迴圈的 EventBridge 觸發模式、Step Functions vs Pipelines vs MWAA 決策矩陣，以及血緣追蹤。本文以 MLOps 的角度撰寫——ML Engineer 實際需要配置什麼、考試喜愛的排序問題模式，以及 MLA-C01 細膩測試的 Pipelines、Step Functions 和 Airflow 之間的精確區別。
什麼是 SageMaker Pipelines，為何對 MLOps 重要
SageMaker Pipelines 是 ML 工作流程的托管編排服務，以有向無環圖（DAG）形式表達，其中包含在 SageMaker 基礎設施上執行的具型步驟。Pipeline 定義是步驟、依賴關係、參數和條件邏輯的 Python SDK 聲明（或 JSON）；pipeline 執行是一次包含具體參數值的執行。Pipelines 提供內置的步驟快取、血緣追蹤、參數化和條件分支——這些特性使 ML 工作流程有別於通用 ETL。
為何 Pipelines 優於手動串接 Lambda 和 Step Functions
通用編排器（Step Functions、Lambda 鏈）需要手動串接每個 SageMaker API 呼叫：CreateProcessingJob、CreateTrainingJob、CreateTransformJob、RegisterModel 等。每個呼叫都有自己的輸入契約、輸出架構和錯誤處理。SageMaker Pipelines 將這些呼叫包裝在具型步驟抽象中（ProcessingStep、TrainingStep、TransformStep、RegisterModel），具有自動的輸入/輸出傳遞、自動重試和內置血緣追蹤。對於 80% 都是 SageMaker 呼叫的 ML 工作流程，Pipelines 是正確的抽象；對於 SageMaker 是眾多非 AWS 服務之一的工作流程，Step Functions 或 MWAA 更靈活。
標準再訓練迴圈
每個 MLA-C01 再訓練 pipeline 問題都歸結為這個標準序列：觸發器觸發 → ProcessingStep 準備資料 → TrainingStep 適配模型 → ProcessingStep 在測試資料上評估 → ConditionStep 根據評估指標分支 → RegisterModel 添加到 registry（如果指標低於閾值則 FailStep）→ 批准事件觸發部署。記住這個；排序問題直接對應到它。
白話文解釋 SageMaker Pipelines
Pipeline 抽象感覺很機械，直到你把它對應到人們實際執行的實體工作流程。
類比一：飯店廚房的日常備料工作流程
想像一家飯店廚房的每日備料流程。每天早上廚房執行固定序列：收取食材（資料攝入）、洗切（前處理）、烹飪菜餚（訓練）、依照食譜標準進行試吃（評估），然後要麼裝盤服務（登錄菜餚、批准）要麼如果試吃失敗就送回廚師（FailStep）。SageMaker Pipelines 是廚房牆上的印刷工作流程——每個步驟都有名稱，每個步驟的輸入和輸出都已定義，廚房明天可以用不同食材（參數化）重新執行相同邏輯。ConditionStep 是試吃關卡：如果菜餚達到標準，就上桌服務（RegisterModel）；如果沒有，就打回去。Pipeline 參數是可配置的旋鈕——今天的鹽量、今天的烹飪時間、今天的份量。步驟快取是「我們一個小時前已經切好了這些洋蔥，如果食譜沒有改變就不要重切」。Pipeline 觸發器是工作流程啟動的方式：排程（每天早上 6 點）、事件驅動（新食材剛剛到貨）或手動（廚師按下按鈕）。血緣追蹤是食品安全記錄本，記錄哪個食材批次在哪天進了哪道菜。MLA-C01 考試要求你以正確順序排列廚房步驟——搞錯一個就是把生洋蔥放進客人的盤子。
類比二：汽車工廠的生產線
想像一家汽車工廠。生產線有固定的工作站：衝壓車身板件（資料準備）、焊接底盤（模型訓練）、噴漆和檢驗（評估）、通過品質管制（ConditionStep——通過進入配送或失敗進入返工）、最終組裝（RegisterModel）和出貨（部署）。SageMaker Pipelines 是工廠的主排程，定義哪個工作站供應哪個、每個工作站的輸入和輸出是什麼、哪些工作站與哪些並行執行。Pipeline 參數是今天建造的型號和配色——相同的生產線，不同的配置。步驟快取是「我們在批次 47 中已經衝壓了這些板件，重用它們」的最佳化。Pipeline 觸發器是流水線的開始信號——時鐘時間、零件可用性事件或主管按鈕。血緣追蹤是記錄每輛車（VIN 到零件號溯源）每個工作站輸出的建造清單。FailStep 是品管拒絕路徑——如果汽車未能通過檢驗，它被從生產線上移除，失敗記錄在血緣追蹤中。MLA-C01 排序問題對應到「以正確順序給出工廠排程」——衝壓→焊接→噴漆→檢驗→組裝→出貨；重新排列就會使生產線崩潰。
類比三：電影製作的生產流水線
想像一家電影製片廠的製作排程。步驟以固定順序執行：寫劇本（資料準備）、拍攝場景（訓練）、剪輯和審看（評估）、焦點小組試映（ConditionStep——如果分數高就發行，如果低就重拍）、分發到院線（RegisterModel 並批准）、宣傳（部署到 endpoint）。SageMaker Pipelines 是製片廠的製作計畫。ProcessingStep 是任何把原始輸入轉換成精煉輸出的準備或後準備階段（劇本→劇本、每日粗剪→剪輯場景）。TrainingStep 是拍攝本身——昂貴的創意製作。TuningStep 是嘗試多個剪輯以找到最佳剪輯的排練階段（超參數調整）。TransformStep 是把每個場景離線批次渲染為最終格式。Pipeline 參數是今天的預算、片長和目標評級——相同的製作流程，每部電影不同的參數。Step Functions 相比之下是更通用的項目管理工具——當工作流程包含非製片廠步驟如供應商協調、物流和旅行時很有用；SageMaker Pipelines 是當工作流程主要是製片廠製作時的正確答案。MLA-C01 考試透過信號——工作流程主要是 SageMaker（Pipelines）、主要是多服務（Step Functions）還是主要是混合/舊有 Airflow 專業知識（MWAA）——來問「你選擇哪個編排器」。
Pipeline 步驟類型——完整分類
每個 SageMaker pipeline 步驟都有一個具型抽象。記住名稱和用途——排序和配對問題直接對應到這些。
ProcessingStep
包裝一個 SageMaker Processing 任務。用於任何資料轉換：原始資料前處理、特徵工程、訓練後在留出測試集上的評估、用 Clarify 進行的模型公平性分析、部署後評估報告。輸入是 S3 路徑；輸出是 S3 路徑。常用容器：Scikit-Learn、Spark、自訂 Docker 映像。
TrainingStep
包裝一個 SageMaker 訓練任務。接受一個評估器物件（內置算法或自訂容器或框架）、超參數、執行個體類型/數量和 S3 輸入頻道。輸出是 S3 中的模型成品。
TuningStep
包裝一個 SageMaker 自動模型調整（AMT）超參數最佳化任務。接受帶有搜索策略（貝葉斯、隨機、Hyperband）、參數範圍、最大任務數和並行度的 HyperparameterTuner 物件。輸出是最佳訓練任務的模型成品。
TransformStep
包裝一個 Batch Transform 任務。用於 pipeline 內的批次推論——將訓練好的模型套用到大型資料集進行離線評分。輸入是 S3 輸入前綴和模型名稱；輸出是 S3 輸出前綴。
CreateModelStep / RegisterModel
CreateModelStep 在 SageMaker 中登錄一個模型物件（建立引用訓練輸出的模型資源）。RegisterModel 將模型套件添加到 SageMaker Model Registry 的 Model Package Group，帶有批准狀態。RegisterModel 是 pipeline 末端通過 model registry 把關部署的典型步驟。
ConditionStep
根據對步驟屬性評估的條件表達式分支 pipeline。最常見的模式：根據評估 ProcessingStep 的指標設定條件——如果 AUC > 0.85，RegisterModel；否則 FailStep。多個 if 條件和 else 條件可以鏈接成巢狀分支。
FailStep
以配置的錯誤訊息顯式使 pipeline 失敗。用於模型未通過品質關卡時 ConditionStep 的 else 分支。有助於向 CloudWatch 和 EventBridge 消費者發出清晰的失敗原因。
LambdaStep
呼叫 Lambda 函數作為 pipeline 步驟。用於不適合 SageMaker 步驟類型的自訂邏輯——發送通知、更新外部系統、呼叫第三方 API 或實作自訂驗證邏輯。
CallbackStep
暫停 pipeline 並等待外部 SQS 回調後再繼續。用於 model registry 批准流程之外的人工審核批准關卡。
EMRStep
在 pipeline 中執行 EMR 任務步驟。當資料準備流程的 Spark 轉換在 EMR 上執行時使用。
NotebookJobStep
執行 SageMaker Notebook Job（排程執行的 Jupyter 筆記本）作為 pipeline 步驟。用於作為 pipeline 一部分的臨時分析或報告生成。
QualityCheckStep / ClarifyCheckStep
用於 SageMaker Model Monitor 基準建立和 SageMaker Clarify 偏差和可解釋性分析的專用步驟。在訓練時用於捕捉 Model Monitor 將在部署後使用的基準。
SageMaker Pipeline 是具型步驟的 DAG，每個步驟包裝特定的 SageMaker API 呼叫（ProcessingStep、TrainingStep、TuningStep、TransformStep、RegisterModel、CreateModel）加上控制流步驟（ConditionStep、FailStep、CallbackStep、LambdaStep）。 步驟透過輸入/輸出引用連接——一個步驟的輸出 S3 路徑成為另一個步驟的輸入——pipeline 服務自動追蹤它們之間的血緣關係。Pipelines 在 Python SDK 中以聲明式方式定義並用參數值執行；每次執行產生一個血緣記錄，顯示哪些步驟版本以哪些輸入執行並產生哪些輸出。這是 MLA-C01 期望的思維模型——pipeline 作為具型 DAG，而非命令式腳本。
Pipeline 參數——執行時的可配置性
Pipelines 支援在執行時而非定義時綁定的具型參數。
參數類型
ParameterString——字串值（S3 路徑、模型名稱、環境名稱）ParameterInteger——整數值（執行個體數量、epoch 數量、最大任務數）ParameterFloat——浮點值（學習率、閾值）ParameterBoolean——布林旗標（enable_caching、debug_mode）
為何參數重要
單一 pipeline 定義服務多個環境和多次執行。相同的 DAG，不同的參數。今天的執行使用 instance_type=ml.m5.xlarge 用於開發；明天的生產執行使用 instance_type=ml.m5.4xlarge。一個 pipeline 定義，多次執行，在執行時參數化。
預設值
每個參數可以有預設值。沒有明確參數值的執行使用預設值。用於始終使用相同配置的生產執行。
步驟快取——避免重複計算
Pipeline 執行可以快取步驟結果：如果步驟的輸入和參數與前一次成功執行相比沒有改變，SageMaker 重用前一次的輸出而不重新執行。
快取配置
CacheConfig(enable_caching=True, expire_after="P30D") 啟用三十天的快取。快取鍵是步驟輸入、參數和步驟定義的雜湊；如果任何改變，步驟重新執行。
快取的適用場景
- 長 pipeline 中早期步驟（資料準備）很少改變而後期步驟（訓練、調整）頻繁迭代
- 反覆調試，重新執行完整 pipeline 會重新處理未更改的資料
- 成本最佳化——當輸入未改變時跳過昂貴的 Processing 或 Training 步驟
快取失效陷阱
快取鍵使用輸入雜湊。如果 Processing 步驟的輸入是「前綴 X 下的所有檔案」且前綴增加了一個新檔案，雜湊改變，步驟重新執行。但如果輸入是一個以相同鍵就地覆寫的特定 S3 物件（不同內容），AWS 可能不會使快取失效，因為 S3 物件引用是相同的。最佳實踐：用明確的版本路徑對資料輸入進行版本化，使快取行為可預測。
預設為開發 pipeline 啟用步驟快取，為稽核敏感工作流程的生產執行禁用它。 在迭代過程中快取節省大量時間和成本——當只有訓練步驟改變但資料準備沒有時，跳過準備節省了幾小時和幾美元。生產再訓練執行相比之下，通常希望無論快取如何都重新執行每個步驟，以捕捉顯示每個步驟實際執行的不可變血緣追蹤供稽核使用。配置：開發 pipeline 在 pipeline 層級用 expire_after="P7D" 啟用快取；生產再訓練 pipeline 在 pipeline 或步驟層級禁用快取。混合這些是常見的 ML Engineer 錯誤——在生產中啟用快取會產生指向舊執行的血緣記錄，讓稽核審查困惑。
ConditionStep——品質關卡
ConditionStep 是 pipeline 決定模型是否足夠好以登錄的地方。
條件表達式
條件對步驟屬性進行評估。最常見的：評估 ProcessingStep 輸出上的屬性——JsonGet("evaluate", "metrics.auc.value") > 0.85。SageMaker SDK 提供 ConditionGreaterThan、ConditionGreaterThanOrEqualTo、ConditionLessThan、ConditionEquals、ConditionIn，以及 ConditionOr/ConditionAnd 組合器。
分支模式
ConditionStep(
name="check-auc",
conditions=[ConditionGreaterThanOrEqualTo(left=auc_value, right=0.85)],
if_steps=[register_model_step],
else_steps=[fail_step],
)
如果條件評估為真，執行 if_steps；否則執行 else_steps。兩個分支是互斥的——每次執行只有一個運行。
為何 ConditionStep 對 MLOps 重要
沒有 ConditionStep，每次訓練執行都會登錄，無論品質如何，用壞的模型污染 model registry。有了 ConditionStep，只有通過品質關卡的模型進入 registry，壞的執行透過 FailStep 以診斷訊息被明確記錄為失敗。
始終包含一個 ConditionStep，根據品質閾值（AUC、F1、RMSE 或業務指標）把關 RegisterModel 步驟——永遠不要無條件地登錄模型。 模式：TrainingStep 產生模型 → ProcessingStep 在留出測試集上執行模型並寫入 evaluation.json → ConditionStep 從 evaluation.json 讀取指標並把關 → 如果指標通過閾值，RegisterModel；否則 FailStep 帶描述性錯誤訊息。這個模式保持 model registry 乾淨（只有好的模型進入）、為壞的執行提供明確的失敗記錄，並與 EventBridge 整合以自動告警。跳過 ConditionStep 是 SageMaker 參考架構標記的最常見 Pipeline 反模式，也是 MLA-C01 用「確保只有滿足品質閾值的模型被登錄」等題幹測試的 ML Engineer 錯誤。
Pipeline 觸發器——再訓練如何啟動
Pipeline 定義在某些東西觸發執行之前是靜態的。
EventBridge 排程
Cron 風格排程週期性觸發——每 6 小時、每週一凌晨 2 點、每月第一天。用於與資料刷新頻率一致的排程再訓練週期。
EventBridge 事件模式
觸發 AWS 服務事件：新檔案在 S3 中落地（Object Created 事件）、Model Monitor 觸發違規（SageMaker Model Quality Violation 事件）、CodeCommit 推送（分支中的 Reference Created 事件），或發布到 EventBridge 的自訂應用程式事件。用於當資料改變或品質偏移時的事件驅動再訓練。
手動呼叫
從 Lambda、Jupyter 筆記本或 CLI 命令呼叫 StartPipelineExecution API。用於臨時重新執行和人工觸發的迭代。
CodePipeline 觸發器
CodePipeline 在更廣泛的 CI/CD 流程中呼叫 SageMaker Pipelines 作為一個階段。當 pipeline 是更廣泛的持續交付流程中的一個階段，還涉及基礎設施部署、冒煙測試和下游系統整合時使用。
閉環再訓練模式
標準模式結合了觸發器：每週排程再訓練作為基準節奏；當 Model Monitor 在排程間隔之間偵測到偏移違規時的事件驅動再訓練；手動呼叫用於臨時實驗。這種組合確保模型定期被重新訓練、在降級時立即重新訓練，以及按需可以輕易重新訓練。
Step Functions vs SageMaker Pipelines vs MWAA——決策矩陣
每個編排器在什麼時候勝出？
SageMaker Pipelines
- 工作流程主要是 SageMaker 呼叫（Processing、Training、Transform、Model Registry）
- 需要原生步驟類型、自動血緣追蹤、內置快取
- 需要與 Model Registry、Feature Store、Data Wrangler、Clarify 的原生整合
- 團隊熟悉 SageMaker 和 Python
- 使用場景：ML 再訓練迴圈、特徵 pipeline、評估 pipeline
AWS Step Functions
- 工作流程涉及許多非 SageMaker 步驟（Lambda、ECS、Batch、第三方 API、複雜重試邏輯、錯誤補償）
- 需要具有並行分支、動態步驟生成和複雜錯誤處理的細粒度狀態機控制
- 已為非 ML 工作流程標準化使用 Step Functions
- 使用場景：跨資料工程、ML 訓練和下游業務系統的端到端編排
Amazon MWAA（Managed Workflows for Apache Airflow）
- 團隊有現有的 Airflow 專業知識和要遷移的 DAG
- 工作流程是多系統的，包括非 AWS 服務和自訂運算子
- 需要豐富的運算子生態系統（Airflow 有數百個服務運算子）
- 使用場景：編排 ML 和非 ML 工作流程的資料工程中心
考試時如何選擇
- 「主要是 SageMaker 呼叫，需要原生血緣追蹤」→ SageMaker Pipelines
- 「複雜的多服務編排，細粒度狀態機」→ Step Functions
- 「現有 Airflow 專業知識」或「托管 Airflow 服務」→ MWAA
Step Functions 和 SageMaker Pipelines 不可互換——它們解決不同的問題，MLA-C01 考試細膩地測試這個區別。 Pipelines 是為 ML 工作流程量身打造的：包裝 SageMaker API 的具型步驟、到 Model Registry 的自動血緣追蹤、與 Feature Store 和 Data Wrangler 的原生整合。Step Functions 是通用的：任何 AWS 服務的狀態機，包括透過 SageMaker 整合的 SageMaker，但沒有 ML 特定的抽象。當工作流程 80% 是 SageMaker 時使用 Pipelines；當 SageMaker 是眾多元件之一且你需要細粒度狀態機控制時使用 Step Functions。題幹說「主要是 SageMaker 訓練和推論」→ Pipelines；題幹說「編排 Lambda、Batch、ECS 和 SageMaker 並帶有自訂重試邏輯」→ Step Functions。
與 Data Wrangler 和 Feature Store 的整合
SageMaker Pipelines 與資料準備和特徵管理服務原生整合。
Data Wrangler 匯出到 Pipeline
Data Wrangler 流程可以匯出到 SageMaker Pipeline，作為帶有 Data Wrangler Spark 容器的 ProcessingStep。流程是可規模化重現的——在 Data Wrangler 中定義的互動式轉換在 pipeline 執行期間作為托管 Processing 任務執行。
Pipeline 中的 Feature Store 攝入
ProcessingStep 可以從 S3 讀取、轉換特徵，並在 Feature Store 線上存儲上呼叫 PutRecord，或寫入離線存儲。後續的訓練步驟透過 Feature Store 離線存儲的 S3 + Athena 介面查詢，確保訓練-服務一致性。
訓練的 Feature Store 讀取
TrainingStep 的輸入頻道可以是 Feature Store 離線存儲上的 Athena 查詢結果，以 CSV 或 Parquet 格式存放在 S3 中。這個模式產生一個與推論時服務的內容完全匹配的訓練資料集，消除訓練-服務偏差。
血緣追蹤——預設的可重現性
SageMaker ML 血緣追蹤自動記錄每個步驟的輸入、輸出、參數和程式碼版本。
追蹤的內容
Pipeline 執行建立血緣記錄，連結：來源資料 S3 路徑 → 前處理任務輸出 → 訓練任務輸入和輸出 → 模型成品 → 評估報告 → 登錄的模型套件 → 部署的 endpoint。每個連結都是可查詢的。
為何對稽核重要
監管機構和稽核審查員問「給我看哪些訓練資料產生了目前服務客戶 X 在 Y 日期預測的模型」。沒有血緣追蹤，這是數天的鑑識偵探工作。有了血緣追蹤，一個 API 呼叫就能返回答案。
查詢血緣
ListAssociations API 或 SageMaker Studio 血緣 UI 遍歷血緣圖。常見查詢：「使用資料集版本 X 的所有訓練執行」、「目前從 model package group Y 部署的所有 endpoint」、「現在服務 endpoint Z 的模型的資料來源」。
SageMaker ML 血緣追蹤自動記錄每個 pipeline 步驟的輸入、輸出和程式碼版本，產生從資料來源到訓練再到部署 endpoint 的可查詢圖。 這對 SageMaker Pipelines 執行自動發生——不需要額外配置。血緣回答監管機構和稽核員的問題：「哪些訓練資料產生了這個預測？」「哪些模型曾經從這個資料集部署？」「給我看這個 model package group 的完整歷史。」在 MLA-C01 考試中，血緣追蹤是「如何產生顯示資料到模型溯源的稽核軌跡」或「如何追蹤生產模型回到其來源訓練資料」的答案。用自訂標籤或元數據的手動溯源追蹤不是 AWS 建議的模式——血緣追蹤才是。
端到端 Pipeline——排序和配對參考
考試測試為排序問題的標準再訓練 pipeline 結構：
有序步驟序列
- 觸發器觸發（EventBridge 排程、Model Monitor 違規、S3 事件）
- ProcessingStep——資料準備（Glue / Spark / Data Wrangler 容器）
- ProcessingStep——特徵工程（或 Data Wrangler 流程）
- （可選）透過 PutRecord 或離線存儲寫入進行 Feature Store 攝入
- TrainingStep（或用於 HPO 的 TuningStep）
- ProcessingStep——評估（在留出測試集上的模型，產生指標 JSON）
- ConditionStep（根據指標閾值把關）
- 如果通過：RegisterModel（以 PendingManualApproval 狀態添加到 Model Package Group）
- 如果失敗：FailStep（帶描述性錯誤訊息）
- （Pipeline 外部）ML Engineer 審核並批准模型套件
- （Pipeline 外部）
Model Package State Change上的 EventBridge 觸發帶部署護欄的 UpdateEndpoint
配對參考
| 步驟類型 | 包裝 | 典型用途 |
|---|---|---|
| ProcessingStep | Processing 任務 | 資料準備、評估、後處理 |
| TrainingStep | 訓練任務 | 適配模型 |
| TuningStep | AMT 任務 | 超參數最佳化 |
| TransformStep | Batch Transform | 離線批次推論 |
| CreateModelStep | 模型資源 | 登錄引用成品的模型物件 |
| RegisterModel | 模型套件 | 以狀態添加到 Model Registry |
| ConditionStep | 分支 | 根據指標把關 |
| FailStep | 失敗 | 帶訊息的明確失敗 |
| LambdaStep | Lambda 呼叫 | SageMaker 外部的自訂邏輯 |
| CallbackStep | SQS 等待 | 人工審核批准 |
MLA-C01 常見 Pipeline 陷阱
陷阱一：RegisterModel 自動部署
錯誤。RegisterModel 只以某個狀態將模型套件添加到 registry。部署需要單獨的 UpdateEndpoint 呼叫（通常來自由批准觸發的 CodePipeline 或 Lambda）。
陷阱二：ConditionStep 有多個 else 分支
錯誤。ConditionStep 是二元的：if-steps 和 else-steps。多路分支需要巢狀的 ConditionStep。
陷阱三：快取重用任何前一次執行的輸出
部分錯誤。快取鍵是步驟輸入、參數和步驟定義的雜湊。如果任何改變，快取未命中，步驟重新執行。
陷阱四：Step Functions 始終是更好的選擇
錯誤。對於主要是 SageMaker 的 ML 工作流程，Pipelines 在原生整合、血緣追蹤和 registry 方面勝出。Step Functions 對 SageMaker 之外的多服務編排勝出。
陷阱五：Pipelines 必須在 SageMaker Studio 中執行
錯誤。Pipelines 作為托管服務執行。Studio 是用於視覺化的 UI。CLI、SDK、CodePipeline 都可以啟動和監控 pipeline 執行。
陷阱六：血緣追蹤需要手動配置
錯誤。血緣對 SageMaker Pipeline 執行是自動的。只有非 Pipeline 的 SageMaker 工作流程才需要手動血緣配置。
陷阱七：Pipeline 參數可以改變步驟邏輯
部分。參數改變輸入值，但不改變 DAG 結構。條件分支透過 ConditionStep 改變結構，而非透過參數值。
陷阱八：MWAA 是 AWS 的 ML 預設值
錯誤。SageMaker Pipelines 是 AWS 建議的 ML 編排器。MWAA 是當團隊有現有的 Airflow 專業知識或混合工作流程時的答案。
MLA-C01 exam priority — SageMaker Pipelines 與 ML 工作流程編排 — MLA-C01 ML Engineer 學習筆記. This topic carries weight on the MLA-C01 exam. Master the trade-offs, decision boundaries, and the cost/performance triggers each AWS service exposes — the exam will test scenarios that hinge on knowing which service is the wrong answer, not just which is right.
FAQ——SageMaker Pipelines 和 ML 工作流程編排
Q1：典型的 SageMaker 訓練和部署 pipeline 的步驟應該以什麼順序執行？
標準順序：資料準備的 ProcessingStep → 特徵工程的 ProcessingStep（或 Data Wrangler 流程）→ TrainingStep（或用於 HPO 的 TuningStep）→ 評估留出測試資料的 ProcessingStep → 根據評估指標把關的 ConditionStep → 如果通過，以 PendingManualApproval 狀態將模型套件添加到 registry 的 RegisterModel；如果失敗，帶描述性錯誤訊息的 FailStep。部署到 endpoint 通常不是 pipeline 的一部分——而是外部的 EventBridge 規則監聽 ML Engineer 批准套件時的 Model Package State Change 事件，並觸發帶部署護欄的 CodePipeline 或 Lambda 呼叫 UpdateEndpoint。MLA-C01 考試在這個確切序列上提出排序問題；任何步驟順序錯誤（例如 RegisterModel 在 ConditionStep 之前）都是錯的。
Q2：何時應該使用 ConditionStep 而不是讓每個模型通過登錄？
始終包含根據品質閾值把關 RegisterModel 的 ConditionStep。沒有關卡，每次訓練執行都會產生登錄的模型套件，無論品質如何，用批准審查員必須手動過濾的壞模型污染 model registry。有了關卡，只有通過閾值的模型（例如 AUC ≥ 0.85、F1 ≥ 0.75、業務指標達標）進入 registry，壞的執行透過 FailStep 以捕捉在血緣記錄中的診斷訊息明確失敗。ConditionStep 也提供防止回退的自動品質標準——產生比當前生產版本更差模型的再訓練 pipeline 應該在 ConditionStep 快速失敗，而不是產生一個必須手動比較指標的困惑審批者。
Q3：SageMaker Pipelines 步驟快取如何工作，何時應該禁用它？
步驟快取重用前一次成功執行的輸出，如果步驟的輸入、參數和步驟定義未改變。快取鍵是這些元素的雜湊；如果任何改變，快取未命中，步驟重新執行。用 CacheConfig(enable_caching=True, expire_after="P30D") 在步驟或 pipeline 層級配置。為迭代和開發啟用快取，重新執行未改變的資料準備會浪費幾小時和幾美元。為需要捕捉每個步驟實際執行的完整血緣追蹤以供稽核目的的生產再訓練執行禁用快取——快取產生指向舊執行的血緣記錄，讓稽核審查困惑。最常見的錯誤：在生產中啟用快取讓再訓練 pipeline 靜默地重用幾週前的舊資料準備輸出，遺漏了最近的資料品質修復。
Q4：Step Functions 還是 SageMaker Pipelines——什麼時候選哪個用於 ML 編排？
當工作流程主要是 SageMaker 呼叫（Processing、Training、Transform、Model Registry、Feature Store）時選擇 SageMaker Pipelines——Pipelines 提供具型步驟抽象、到 Model Registry 的自動血緣追蹤、與 Data Wrangler 和 Feature Store 的原生整合，以及內置步驟快取。當工作流程涉及大量非 SageMaker 元件——Lambda、ECS、Batch、第三方 API 呼叫、複雜的重試補償、動態並行分支或跨區域編排——可受益於 Step Functions 的通用狀態機模型時選擇 Step Functions。決策不是「哪個更強大」而是「哪個抽象與工作流程形態匹配」。MLA-C01 考試的題幹措辭提供了答案：「主要是 SageMaker 訓練和 registry」→ Pipelines；「編排 SageMaker 加 Lambda 加 Batch 加 DynamoDB Streams 並帶有重試補償」→ Step Functions。
Q5：當生產資料偏移時，如何觸發 SageMaker pipeline 重新訓練模型？
配置 SageMaker Model Monitor（資料品質監控器或模型品質監控器）在生產 endpoint 上，帶有基準和監控排程。當 Model Monitor 偵測到違規時，它發出 CloudWatch 指標和 EventBridge 事件（SageMaker Model Quality Violation 或來自處理違規報告的 Lambda 的自訂事件）。配置一個匹配此事件模式的 EventBridge 規則，目標是一個呼叫再訓練 pipeline 上的 StartPipelineExecution 的 Lambda，帶有適當的參數（例如最近的資料窗口、當前生產模型套件 ARN 用於比較）。再訓練 pipeline 然後運行其完整的 DAG：資料準備 → 訓練 → 評估 → ConditionStep → RegisterModel。批准和部署在下游作為單獨的步驟發生。模式：Monitor 偵測偏移 → EventBridge → Lambda → StartPipelineExecution → ConditionStep → RegisterModel → 人工批准 → CodePipeline → 帶護欄的 UpdateEndpoint。這個閉環再訓練是 MLA-C01 測試的標準端到端 MLOps 流程。
Q6：可以用相同定義對開發、測試和生產環境參數化 SageMaker pipeline 嗎？
可以——Pipeline 參數（ParameterString、ParameterInteger、ParameterFloat、ParameterBoolean）在執行時綁定，允許一個定義服務多個環境。為環境特定值定義參數：instance_type（開發中用較小執行個體、生產中用較大執行個體）、instance_count（開發中單執行個體、生產中多節點）、s3_input_prefix（每個環境不同的資料）、model_approval_status（生產中 PendingManualApproval、開發中 Approved 用於快速迭代）和 enable_caching（開發中 True、生產中 False）。從 CodePipeline 觸發執行時，為每個階段傳入環境特定的參數值。相同的 pipeline 定義在開發中以廉價執行個體和積極快取執行，在測試中以類生產配置，在生產中以完整執行個體數量和對稽核友好的禁用快取。這個模式是 AWS 建議的跨環境維護單一 pipeline 邏輯真相來源的方式。
Q7：SageMaker Pipelines 如何與 Model Registry 和下游部署整合？
整合是事件驅動的。Pipeline 的 RegisterModel 步驟以配置的初始狀態（生產通常是 PendingManualApproval，開發是 Approved 用於快速迭代）將模型套件添加到 Model Package Group。狀態改變發出 SageMaker Model Package State Change 事件到 EventBridge。下游自動化監聽此事件：由事件觸發的 CodePipeline 或 Lambda 函數可以呼叫 UpdateEndpoint，帶有包含 blue/green 策略、canary 流量轉移和 AutoRollbackConfiguration 的 DeploymentConfig。部署在 CloudWatch 警報上自動回滾繼續進行，成功後新模型套件成為部署的生產版本。流程是：Pipeline（訓練、評估、把關、登錄）→ Registry（PendingManualApproval）→ 人工批准 → State Change 事件 → EventBridge → CodePipeline/Lambda → 帶護欄的 UpdateEndpoint → 成功或回滾。MLA-C01 考試測試這條鏈上的每個部分；最常引用的錯誤是忘記 RegisterModel 不會自動部署——部署是由批准事件驅動的單獨下游步驟。