M09.01｜MLOps 概覽：從實驗到產品的橋樑

一句話搞懂

MLOps 就是把「機器學習模型」像「軟體產品」一樣管理的一整套工程實踐 — 從資料準備、模型訓練、上線部署，到上線後的持續監控與更新，確保模型在真實世界裡長期穩定運作，而不是訓練完就扔在角落慢慢腐爛。

白話解說

為什麼訓練出好模型還不夠？

很多人學完機器學習之後，以為工作流程就是：準備資料、訓練模型、評估準確率，然後大功告成。但這只是故事的開頭。

想像你花了三個月訓練一個信用評分模型，準確率高達 92%，你興奮地把它上線了。六個月後，業務主管打電話來問：「為什麼最近核准率跌了這麼多，是模型出問題了嗎？」你打開系統一看，模型還在跑，但它的預測品質已經悄悄下滑。

問題出在哪裡？這段時間，外部環境可能發生了很多變化：利率上升讓民眾消費習慣改變、新的詐騙手法出現、甚至只是季節性的消費波動。模型訓練時的世界和現在的世界，已經不一樣了。這就是為什麼「訓練好模型」只是起點，讓它持續健康運作才是真正的挑戰。

MLOps 是什麼？從 DevOps 說起

DevOps 你可能聽過——它是把軟體開發（Dev）和維運（Ops）整合在一起的工程文化，核心目標是讓程式碼能快速、安全地從開發環境推上生產環境，並透過自動化測試、CI/CD 流水線來確保品質。

MLOps 借用了 DevOps 的精神，但加入了機器學習特有的複雜性：

傳統軟體系統：你管的是「程式碼」。程式碼版本管理用 Git，測試用 pytest，部署用 CI/CD。只要程式碼沒變，系統行為就可預測。

機器學習系統：你要同時管「程式碼」、「資料」、「模型參數」三個會變動的東西。即使程式碼完全沒改，只要訓練資料的分布悄悄改變了，模型的行為就會不一樣。這讓 ML 系統的維運難度高出許多。

2015 年，Google 發表了一篇著名論文「Hidden Technical Debt in Machine Learning Systems」，提出 ML 系統中隱藏的技術負債問題：在一個完整的 ML 系統裡，真正的模型訓練程式碼只佔很小一部分，周圍包圍著大量的資料管道、特徵提取、監控、設定管理等支援系統。忽略這些周邊系統，就會積累難以維護的技術負債。

ML 生命週期的七個階段

一個完整的機器學習專案生命週期，遠比「訓練→部署」複雜：

第一階段：問題定義。要先把業務問題轉化成 ML 問題。「提升顧客留存率」不是 ML 問題，「預測未來 30 天內流失機率超過 70% 的顧客名單」才是。這步驟常被跳過，導致後面訓練方向完全跑偏。

第二階段：資料收集與整理。從各種資料來源收集原始資料，清洗遺漏值、處理異常值、理解資料分布。這個階段通常佔整個專案 60-70% 的時間，卻最容易被低估。

第三階段：特徵工程。把原始資料轉換成模型能理解的數值特徵。這是 ML 工程師最需要領域知識的地方——例如「過去 30 天的購買頻率」可能比「過去 30 天的購買金額」更能預測流失，但這需要對業務的深入理解。

第四階段：模型訓練與實驗。嘗試不同的演算法、超參數設定，記錄每次實驗的結果。這個階段需要系統性的實驗管理，而不是用 Excel 表格手動記錄。

第五階段：模型評估與驗證。不只看準確率，還要檢查公平性、穩健性、在不同子群體上的表現。通過評估後，才能進入部署。

第六階段：模型部署。把訓練好的模型包裝成可供外部呼叫的服務。包括 A/B 測試、藍綠部署、金絲雀發布等策略。

第七階段：監控與再訓練。上線後持續監控模型的預測品質，偵測資料漂移，並在必要時觸發重新訓練。這是讓模型長期健康的關鍵，也是最容易被忽略的階段。

資料漂移與概念漂移：模型最常死於這兩件事

資料漂移（Data Drift）：輸入特徵的統計分布改變了。例如，你的推薦系統訓練時，用戶平均年齡是 28 歲。六個月後平台來了大量 45 歲以上的新用戶，但模型還在用 28 歲的行為模式做推薦，效果自然變差。資料漂移可以用統計方法自動偵測，例如比較輸入特徵的分布是否顯著偏移。

概念漂移（Concept Drift）：輸入和輸出的關係本身改變了。例如，在 COVID 之前訓練的需求預測模型，學到「春節前後需求會上升」的規律。疫情期間這個規律完全失效，因為「節假日」與「需求」的關係根本變了。概念漂移比資料漂移更難偵測，通常需要持續追蹤模型的預測準確率才能發現。

MLOps 的成熟度模型

Google 提出了 MLOps 成熟度的三個層次，可以用來評估自己的團隊現在在哪個階段：

Level 0（手動流程）：所有步驟都是手動的——手動訓練、手動評估、手動部署。沒有 pipeline，沒有版本追蹤，每次「重新訓練」都是重新跑一遍 Jupyter Notebook。很多公司的第一個 ML 專案都在這個層次。

Level 1（ML pipeline 自動化）：訓練流程自動化，有實驗追蹤，有模型登錄。當新資料到來時，可以自動觸發重新訓練。但 CI/CD 還沒整合，部署還是手動。

Level 2（CI/CD pipeline 自動化）：訓練、評估、部署全都自動化。程式碼修改能自動觸發整個流水線，新模型通過測試後自動部署。這是大型 ML 團隊的目標狀態。

應用場景

常見誤區

誤區 1：「模型訓練好、準確率高，上線就沒問題了」

這是最普遍也最危險的誤解。模型訓練時的「準確率」是在歷史資料上測量的，它告訴你的是「這個模型能從過去的資料中學到多少規律」，而不是「這個模型在未來的真實環境中表現如何」。

真實世界是動態的。用戶習慣會改變，市場環境會演化，甚至連資料收集的方式也可能悄悄改變（例如 App 改版後，某個用戶行為的定義不一樣了）。如果沒有上線後的持續監控，你根本不知道模型什麼時候開始「衰老」。

更麻煩的是，模型衰退通常不是突然發生的，而是緩慢漸進的，所以業務人員也不容易察覺，等到發現問題往往已經造成一段時間的損失。這就是為什麼 MLOps 強調監控的重要性——不是在訓練時監控，而是在上線後持續監控。

誤區 2：「MLOps 就是把 DevOps 工具套用在 ML 上」

有些工程師的第一反應是「我已經會 DevOps 了，MLOps 不就是一樣的東西嗎？」這個想法部分正確，但忽略了 ML 系統特有的複雜性。

傳統軟體的行為完全由程式碼決定：只要程式碼版本相同，在任何環境執行都會得到相同結果。但機器學習系統的行為由「程式碼 + 訓練資料 + 模型參數」共同決定。你可以用完全一樣的訓練程式碼，但因為訓練資料的時間範圍不同，訓練出完全不同的模型。這意味著光做程式碼版本控制是不夠的，你還需要資料版本控制、模型版本控制、實驗追蹤。

此外，ML 系統的「測試」也比傳統軟體複雜。你不只要測程式有沒有跑壞，還要測模型的公平性、在邊緣案例上的行為、對抗樣本的穩健性。這些都需要 ML 特有的工具和方法。

誤區 3：「小公司/小團隊不需要 MLOps，那是 Google 在玩的」

這個誤解讓很多中小型團隊在 ML 的泥沼裡掙扎許久。MLOps 的核心原則——版本控制、可重現性、監控——不是大公司的專利，而是任何 ML 團隊的基本衛生習慣。

當然，初期不需要全套的工具鏈。但至少應該做到：用 Git 管理程式碼、用 DVC 或 MLflow 追蹤實驗結果、記錄每個部署的模型版本和訓練資料版本。這些基本實踐的成本不高，但能在「六個月後被問到：這個模型是用什麼資料訓練的？」時保住你的理智。

從 Level 0 到 Level 1 的進化，不需要昂貴的雲端平台，只需要改變工作習慣。等到團隊規模夠大、模型數量夠多的時候，再考慮更完整的 MLOps 平台也不遲。

小練習

練習 1：找出你身邊的 ML 系統風險

想想你的工作或生活中接觸過的一個 AI/ML 系統（例如推薦系統、客服機器人、預測工具）。嘗試回答以下問題：

• 這個系統的輸入資料（特徵）會隨時間改變嗎？怎麼改變？
• 如果模型預測品質下降，你（或公司）會怎麼知道？有沒有監控機制？
• 這個模型多久重新訓練一次？由什麼事件觸發？

練習 2：MLOps 成熟度自評

假設你的團隊已經有一個 ML 模型在生產環境中運作，根據以下清單評估你們目前的 MLOps 成熟度：

Level 0 特徵（手動）：

• 訓練流程主要靠 Jupyter Notebook 手動執行
• 沒有系統性的實驗追蹤（靠 Excel 或記憶）
• 沒有模型版本管理（不知道線上跑的是哪個版本）
• 上線後沒有自動監控

Level 1 特徵（部分自動化）：

• 訓練流程有 pipeline 腳本，可一鍵執行
• 使用 MLflow/W&B 等工具追蹤實驗
• 有模型登錄（Model Registry），知道每個版本的資訊
• 有基本的上線監控（至少監控預測量和延遲）