MLOps：讓 AI 模型從實驗室走到生產線 — iPAS AI 應用規劃師證照教學

一、學習目標

完成本單元後，你將能夠：

定義 MLOps 及其與 DevOps 的關聯
解釋為何大多數 ML 模型無法順利進入生產環境
描述 MLOps 生命週期的七個核心環節
區分批次推論與即時推論的應用場景
說明 Model Drift（模型漂移）的類型與偵測方法
比較主流 MLOps 工具的定位與特點
描述 MLOps 成熟度模型的四個等級

二、核心內容

2-1 什麼是 MLOps？

生活比喻：MLOps 就像把一道在美食競賽（實驗室）中贏得冠軍的料理，轉化為連鎖餐廳（生產環境）能穩定、大量複製的標準食譜。冠軍主廚能做出完美的一道菜，但若沒有標準化流程，連鎖店的員工就無法每天都做出一樣品質的菜。

MLOps（Machine Learning Operations） 是 DevOps 原則在機器學習領域的延伸，目標是縮短模型從開發到生產的落差，並在模型部署後持續維護其效能與可靠性。

MLOps = DevOps 原則 + 資料工程 + 機器學習

傳統 DevOps	MLOps 的額外挑戰
程式碼版本管理	程式碼 + 資料 + 模型三者都需要版本管理
自動化測試	需要測試資料品質、模型效能，而非只測程式邏輯
持續部署	模型部署後效能可能因資料分布改變而衰退
監控系統健康	還要監控模型預測分布是否出現漂移

2-2 為什麼 MLOps 如此重要？87% 的模型永遠出不了實驗室

生活比喻：ML 工程師訓練出一個好模型就像發明家造出一台精妙的機器；但沒有製造廠的工程能力、供應鏈管理、品質管控，這台機器永遠只是一個展示品，無法量產交到用戶手中。

研究顯示，87% 的機器學習模型從未進入生產環境。主要原因包括：

1. 實驗室與生產環境的落差（Lab-to-Production Gap） 在 Jupyter Notebook 中跑得完美的模型，一旦要部署到 API 或微服務架構，就面臨依賴套件版本衝突、推論速度不符要求、記憶體用量過大等問題。

2. 可重現性缺失（Lack of Reproducibility） 沒有記錄實驗參數、資料版本、環境配置，導致模型效能無法重現，其他人也無法繼續開發。

3. 協作斷層（Collaboration Gap） 資料科學家專注模型精度，工程師專注系統穩定性，兩者語言不通，模型移交過程耗時且易出錯。

4. 持續效能衰退（Performance Degradation） 模型部署後，真實世界的資料分布會隨時間改變（如消費行為因疫情改變），但沒有監控機制，模型默默失效卻無人知曉。

2-3 MLOps 生命週期：七個核心環節

環節一：資料管道（Data Pipeline）

自動化的資料管道確保模型訓練資料的穩定供給與品質：

自動化資料攝取（Automated Data Ingestion）：從資料庫、API、串流（Kafka）自動收集資料
資料驗證（Data Validation）：每次管道執行時自動檢查資料品質（使用 Great Expectations 或 TensorFlow Data Validation）
特徵儲存（Feature Store）：集中儲存與管理工程化後的特徵，避免訓練與推論時特徵計算不一致

訓練-服務偏差（Training-Serving Skew） 是最常見的生產問題之一：訓練時的特徵計算邏輯與推論時不同，導致模型在生產環境效能大幅低於實驗室。Feature Store 是解決這個問題的關鍵。

環節二：模型訓練管道（Model Training Pipeline）

實驗追蹤（Experiment Tracking） 記錄每次訓練實驗的所有要素，確保可重現與可比較：

超參數（Hyperparameters）配置
訓練資料版本
評估指標（Accuracy、F1、AUC 等）
訓練時間與資源使用

超參數最佳化（Hyperparameter Optimization, HPO） 自動搜尋最佳超參數組合，常見方法：

Grid Search：窮舉所有參數組合
Random Search：隨機抽樣，效率比 Grid Search 高
Bayesian Optimization：根據過往搜尋結果，智慧地決定下一個搜尋點

環節三：模型登錄與版本管理（Model Registry & Versioning）

生活比喻：模型登錄就像藥品的批號管理——每個上市的藥品（模型版本）都有完整的生產履歷、成分說明（訓練資料、超參數）和臨床試驗結果（評估指標），確保任何時候都可以追溯。

模型卡（Model Card） 是一份標準化的模型說明文件，包含：

模型預期用途與限制
訓練資料集描述
評估指標（整體及分組）
已知的偏誤與公平性分析
建議使用場景與不建議使用場景

模型版本狀態流程：

Staging（測試中）→ Production（生產環境）→ Archived（封存）

環節四：CI/CD for ML（持續整合與持續部署）

傳統 CI/CD vs. ML CI/CD

面向	傳統 CI/CD	ML CI/CD
觸發條件	程式碼 commit	程式碼 commit + 新資料 + 效能退化
測試對象	程式邏輯正確性	程式 + 資料品質 + 模型效能 + 公平性
部署單元	應用程式	應用程式 + 模型權重 + 特徵管道
回滾條件	服務崩潰	服務崩潰或模型效能低於閾值

CI（持續整合）for ML 的測試清單：

程式碼單元測試（Unit Tests）
資料品質驗證（Data Validation）
模型訓練管道完整性測試（Pipeline Test）
模型效能回歸測試（不得低於基準線）
模型公平性測試（各族群效能差距）

環節五：模型服務（Model Serving）

批次推論 vs. 即時推論

面向	批次推論（Batch Inference）	即時推論（Real-time Inference）
時機	定期執行（每日/每週）	每次請求立即回應
延遲要求	低（數分鐘到數小時可接受）	高（通常需在 100ms 內回應）
應用場景	每日信用評分更新、批量推薦信件	詐欺即時偵測、即時搜尋排名
基礎設施	Spark、雲端批次運算	REST API、gRPC、WebSocket

容器化部署（Containerization） 使用 Docker 與 Kubernetes 封裝模型及其依賴環境，確保「在本機可以跑、在生產環境也能跑」：

模型權重 + 推論程式碼 + Python 環境 + 依賴套件
           ↓ 打包成 Docker Image
Kubernetes 叢集：自動擴縮容、負載均衡、健康監控

模型優化技術（減少推論延遲與資源消耗）：

技術	說明	效果
量化（Quantization）	將 32-bit 浮點數參數壓縮為 8-bit 整數	模型縮小 4 倍，速度提升 2-4 倍
剪枝（Pruning）	移除對輸出影響微小的神經元與連結	減少計算量，輕微犧牲精度
知識蒸餾（Knowledge Distillation）	用大模型（教師）訓練小模型（學生）	小模型保留大模型 90%+ 的效能
ONNX 轉換	將模型轉為跨框架標準格式	跨平台部署、推論引擎優化

環節六：監控與可觀測性（Monitoring & Observability）

生活比喻：模型監控就像汽車儀表板——引擎溫度（資料品質）、油量（資料量）、速度表（推論延遲）、警示燈（異常偵測）缺一不可。你不需要時刻盯著，但任何指標越界時必須立即發出警報。

四大監控維度：

① 資料漂移（Data Drift） 輸入資料的統計分布改變，例如用戶年齡分布從以 30 歲為主移轉到以 50 歲為主。模型雖未改變，但輸入資料的模式已不同於訓練時所見。

② 概念漂移（Concept Drift） 輸入與輸出之間的關係改變，例如 COVID 前「飯店預訂」是旅遊景氣指標，COVID 後這個關係改變了。這是最難偵測的漂移類型。

③ 模型效能退化（Model Performance Degradation） 預測準確度、AUC、RMSE 等指標隨時間下降，通常是資料漂移或概念漂移的結果。

④ 基礎設施指標（Infrastructure Metrics） API 延遲（Latency）、吞吐量（Throughput）、錯誤率（Error Rate）、資源使用率（CPU/Memory/GPU）。

漂移類型	偵測方法	工具
資料漂移	KS 統計量、PSI（Population Stability Index）	Evidently AI、WhyLabs
概念漂移	監控預測標籤分布、A/B 測試	自訂邏輯、Arize AI
效能退化	定期以有標籤資料評估模型指標	MLflow、Prometheus + Grafana

環節七：再訓練觸發（Retraining Triggers）

模型不應永遠使用同一個版本，必須依據觸發條件重新訓練：

觸發類型	說明	適用場景
排程式（Scheduled）	每週/每月固定重新訓練	資料變化較緩慢的場景（如信用評分）
效能觸發（Performance-Based）	當效能指標低於閾值時觸發	需要及時反應的場景（如詐欺偵測）
資料漂移觸發（Drift-Based）	當資料漂移指標超過閾值時觸發	資料分布快速變化的場景（如電商推薦）

2-4 主流 MLOps 工具比較

工具	類型	核心功能	適用規模
MLflow	開源	實驗追蹤、模型登錄、專案封裝	中小型團隊入門首選
Kubeflow	開源（Google）	Kubernetes 原生 ML 管道，完整 MLOps 平台	大型企業、K8s 環境
Weights & Biases (W&B)	商業（含免費版）	實驗追蹤、視覺化、協作報告	研究機構、中型團隊
Apache Airflow	開源	工作流程排程與管道編排	資料管道自動化
Seldon Core	開源	Kubernetes 上的模型服務與 A/B 測試	需要靈活部署策略的企業
BentoML	開源	快速封裝與部署 ML 模型為 API	快速原型到生產
Vertex AI	Google Cloud	全託管 MLOps 平台（訓練到部署）	使用 GCP 的企業
SageMaker	AWS	全託管 MLOps 平台	使用 AWS 的企業

2-5 MLOps 成熟度模型

生活比喻：MLOps 成熟度就像汽車工廠的自動化程度——Level 0 是手工打造每一輛車；Level 3 是全自動生產線，能根據市場需求自動調整生產。

Google 定義的 MLOps 成熟度分為四個等級：

等級	名稱	特徵	適用情境
Level 0	手動流程	資料科學家手動訓練、手動部署、無自動化	AI 探索期的小型專案
Level 1	ML 管道自動化	訓練管道自動化、實驗追蹤、但部署仍手動	有固定 AI 產品的成長期公司
Level 2	CI/CD 管道	自動化測試、自動部署、模型登錄、監控	AI 是核心業務的成熟公司
Level 3	自動化再訓練	自動偵測漂移並觸發重訓練與部署	AI 驅動的科技公司

各等級的關鍵差異：

Level 0: 實驗 Notebook → 手動複製程式碼 → 手動部署
Level 1: 自動訓練管道 → 手動觸發部署 → 部分監控
Level 2: 程式碼 commit → 自動測試 → 自動部署 → 完整監控
Level 3: 資料漂移偵測 → 自動觸發重訓練 → 自動驗證 → 自動部署 → 持續監控

考試重點：Level 0 到 Level 3 的區別常以情境題出現。判斷關鍵：是否有自動化訓練管道（Level 1+）、是否有 CI/CD（Level 2+）、是否有自動化再訓練（Level 3）。

2-6 A/B 測試與金絲雀部署

在模型更新時，不應直接將所有流量切換到新模型，而應採用漸進式部署策略降低風險：

A/B 測試（A/B Testing） 將流量一分為二，A 組使用現有模型、B 組使用新模型，比較兩組的業務指標（轉換率、點擊率、收入），在統計顯著的前提下決定是否全面切換。

金絲雀部署（Canary Deployment） 先將 5% 的流量導向新模型，觀察一段時間後若無問題再逐步擴大比例（5% → 20% → 50% → 100%）。名稱來自礦工攜帶金絲雀下礦坑——金絲雀對有毒氣體更敏感，一旦金絲雀異常，礦工立即撤退。

Shadow Mode（影子模式） 新模型接收所有請求並計算預測結果，但不回傳給用戶，只用來比對新舊模型的預測差異，完全不影響現有服務。

三、關鍵名詞中英對照

中文	英文
機器學習維運	MLOps (Machine Learning Operations)
實驗追蹤	Experiment Tracking
模型登錄	Model Registry
模型卡	Model Card
特徵儲存	Feature Store
訓練-服務偏差	Training-Serving Skew
持續整合	Continuous Integration (CI)
持續部署	Continuous Deployment (CD)
批次推論	Batch Inference
即時推論	Real-time Inference
量化	Quantization
剪枝	Pruning
知識蒸餾	Knowledge Distillation
資料漂移	Data Drift
概念漂移	Concept Drift
模型漂移	Model Drift
效能衰退	Performance Degradation
自動化再訓練	Automated Retraining
A/B 測試	A/B Testing
金絲雀部署	Canary Deployment
影子模式	Shadow Mode
超參數最佳化	Hyperparameter Optimization (HPO)
可重現性	Reproducibility

四、考試重點提示

重點 1：MLOps 的核心定義 MLOps = DevOps + 資料工程 + 機器學習，目的是縮短模型從開發到生產的落差，並在部署後持續維護效能。考試常考「MLOps 解決了什麼問題」。

重點 2：資料漂移 vs. 概念漂移 資料漂移是輸入資料分布改變；概念漂移是輸入與輸出之間的關係改變。兩者都會導致模型效能下滑，但概念漂移更難偵測（需要有標籤資料才能發現）。

重點 3：Feature Store 的用途 Feature Store 解決「訓練-服務偏差（Training-Serving Skew）」問題，確保訓練時與推論時使用完全相同的特徵計算邏輯。

重點 4：MLOps 四個成熟度等級 Level 0（手動）→ Level 1（ML 管道自動化）→ Level 2（CI/CD）→ Level 3（自動化再訓練）。考試常給情境描述，要求判斷企業處於哪個等級。

重點 5：批次 vs. 即時推論的選擇 選擇依據是延遲要求：詐欺偵測、推薦系統（即時反應）= 即時推論；定期信用評分更新、批量報告生成 = 批次推論。

隨堂小測驗

Q1. 某電商平台的推薦模型在三個月前上線後，準確率一直在下降。後來發現，原因是平台新增了大量年輕用戶，而原本訓練資料主要來自中年用戶。這個現象最符合哪種漂移類型？

A. 概念漂移（Concept Drift）
B. 資料漂移（Data Drift）
C. 模型偏誤（Model Bias）
D. 過度擬合（Overfitting）

Q2. Feature Store（特徵儲存）主要解決 MLOps 中的哪個問題？

A. 模型訓練速度太慢
B. 訓練與推論時特徵計算邏輯不一致（Training-Serving Skew）
C. 模型版本之間的效能比較
D. 自動化超參數搜尋

Q3. 根據 Google 的 MLOps 成熟度模型，哪個等級的特徵是「能自動偵測資料漂移並觸發模型重新訓練與部署」？

A. Level 0
B. Level 1
C. Level 2
D. Level 3

Q4. 某公司要上線新版推薦模型，但擔心新模型可能不如舊版。技術團隊決定先讓 5% 的流量使用新模型，觀察一週後若效能良好再逐步擴大。這個部署策略稱為什麼？

A. A/B 測試（A/B Testing）
B. 金絲雀部署（Canary Deployment）
C. 影子模式（Shadow Mode）
D. 藍綠部署（Blue-Green Deployment）

Q5. 下列哪個 MLOps 工具的定位是「實驗追蹤與模型登錄」，且是目前最廣泛使用的開源選擇？

A. Apache Airflow
B. Kubeflow
C. MLflow
D. Seldon Core

解答與解析

題號	答案
Q1	B
Q2	B
Q3	D
Q4	B
Q5	C

詳細解析：

Q1：B（資料漂移） 用戶群結構改變（從中年用戶為主轉變為大量年輕用戶加入），導致輸入資料的統計分布改變，這是資料漂移（Data Drift）。若是「用戶行為模式本身改變」（例如疫情改變了所有年齡層的消費習慣），才是概念漂移。區分關鍵：是「誰在使用」改變（資料漂移），還是「怎麼使用的規律」改變（概念漂移）。

Q2：B Feature Store 解決的核心問題是 Training-Serving Skew（訓練-服務偏差）。常見情境：資料科學家在訓練時計算「過去 30 天的平均購買金額」，但推論服務的工程師用了稍微不同的計算方式（如時區差異、資料截斷點不同），導致模型在生產環境效能遠低於實驗室。Feature Store 集中管理特徵計算邏輯，確保訓練與推論使用完全相同的特徵。

Q3：D（Level 3） Google MLOps 成熟度 Level 3 的關鍵特徵是「自動化再訓練」——系統能自動偵測資料漂移，自動觸發重訓練流程，自動驗證新模型品質，並自動部署至生產環境，形成完整的自動化閉環。Level 2 有 CI/CD 但需要人工觸發再訓練；Level 1 只有訓練管道自動化；Level 0 全部手動。

Q4：B（金絲雀部署） 金絲雀部署的核心特徵是「漸進式流量切換」，從小比例（5%）開始，逐步擴大到 100%，中途可隨時回滾。A/B 測試是同時讓兩個版本各服務固定比例的用戶，目的是做統計比較；影子模式是新模型不回傳結果給用戶，只做內部比對；藍綠部署是瞬間全切換，有問題立即全部回滾。

Q5：C（MLflow） MLflow 是 Databricks 開源的 MLOps 工具，核心功能包含四個模組：MLflow Tracking（實驗追蹤）、MLflow Projects（專案封裝）、MLflow Models（模型格式標準化）、MLflow Registry（模型登錄）。因為部署簡單、學習曲線低，是中小型團隊最常使用的 MLOps 入門工具。Airflow 是工作流程排程（非 ML 專用）；Kubeflow 是大型 K8s 環境的完整 MLOps 平台；Seldon 專注模型服務。