2021 年那套成熟度模型，在 2026 年還適用嗎？ 我的答案是：框架適用，內容要改寫。

本系列為 MLOps × GenAI Engineering 雙主軸，走主軸二的讀者可以略讀，但建議至少看完第二節——那是你未來合作對象的世界觀。

今天也是這個系列與 2021 年《從 AI 落地談 MLOps》 正面對話的一天。

今天要解決的問題

一個場景：主管說「我們要導入 MLOps」，然後買了一套工具。半年後，工具沒人用，模型還是手動部署。

問題出在沒有先診斷。MLOps 不是一套工具，是一組能力；導入的正確順序是「診斷現況 → 找出最痛的那一格 → 補那一格」，而不是「買齊全套」。

為此在這一篇設計了一份可以收藏的診斷表。

📊 職缺訊號

有趣的觀察：MLOps 職缺中「模型版本與實驗管理」只佔 7.2%，是六項任務中最低的；而「平臺與基礎設施」佔 58.5%，是最高的。這不代表實驗管理不重要，而是反映了台灣市場的成熟度分布——多數團隊還在解決「怎麼把東西跑起來」，還沒到「怎麼管理跑過的東西」。

一、現象：三個等級的實際樣貌

Google 提出的 MLOps 成熟度分三級，定義及分級情形如下：

Level 0（手動流程）。 資料科學家在 Notebook 裡訓練，把模型檔案傳給工程師，工程師手動包成服務上線。上線後沒有監控，要重訓時整套流程再走一次。特徵：交付物是檔案，流程靠人記得。

Level 1（訓練管線自動化）。 訓練被寫成可重複執行的管線，資料驗證、訓練、評估、註冊都是自動的。可以排程或由條件觸發重訓。特徵：交付物是管線，模型是管線的輸出。

Level 2（CI/CD 全自動）。 連「管線本身」都納入 CI/CD，改了訓練程式碼會自動測試、建置、部署新版管線。搭配線上監控自動觸發重訓。特徵：交付物是系統，人只負責改進系統。

圖 8-1：MLOps 成熟度的十項能力在三個等級的落點（示意對照表）。升級路徑就是把整欄的紅格與黃格逐項推成綠格。

如何評估：把這十列拿去問你的團隊「這件事我們自動化了嗎」，統計你有幾個綠格。多數台灣團隊落在 4–6 格之間，通常卡在「自動重訓練」與「線上監控」。

二、原理：五年後，哪些格子的內容變了

我把 2021 年那個系列的重心與 2026 年的職缺任務訊號放在一起：

圖 8-2：MLOps 五年對照（評分為作者依兩份系列大綱與任務訊號的主觀對照示意）。灰色是 2021 年的重心，藍綠色是 2026 年的重心。

沒變的四項（地基）：

1. 可重現性——只是要重現的東西多了「提示」與「檢索索引」兩項。
2. CI/CD 與自動化管線——依然是規模化的唯一解。
3. 容器化與資源排程——重要性甚至上升了，因為 GPU 更貴、更需要調度。
4. 線上監控——重要性明顯上升，因為 LLM 的失效更安靜。

被改寫的部分（上層）：

📌 一句話總結五年的變化

2021 年的 MLOps 問「我的模型怎麼上線」；2026 年的 LLMOps 問「別人的模型，怎麼在我的系統裡穩定、便宜、安全地工作」。

主詞從「模型」換成了「系統」——這正是為什麼職缺任務訊號中「平臺與基礎設施」會高達 58.5%。

三、動手：十分鐘團隊診斷

把下面這段貼進團隊會議，逐題舉手表決（只能答「是」或「否」，不能答「算是吧」）：

【L1 檢核：訓練管線自動化】
□ 1. 重訓一次模型，可以用一個指令或一次點擊完成？
□ 2. 訓練前會自動檢查資料 schema 與分布異常？
□ 3. 每次訓練的參數、指標、產出模型都被自動記錄，可事後查詢？
□ 4. 換一個人來，能用同一份設定重現三個月前的訓練結果？
□ 5. 模型上線用的是註冊表中的特定版本，而不是某人電腦上的檔案？

【L2 檢核：CI/CD 與持續訓練】
□ 6. 改了訓練程式碼會自動跑測試（含資料測試與模型行為測試）？
□ 7. 新模型必須通過品質門檻才能進入生產，且門檻是程式自動判斷？
□ 8. 部署是自動的，且支援金絲雀或影子驗證？
□ 9. 線上模型效能與資料漂移有自動監控與告警？
□ 10. 符合條件時可自動觸發重訓，不需人工介入？

計分：1–5 全是 → 已達 Level 1；6–10 全是 → 已達 Level 2
      1–5 有任一否 → 你在 Level 0，別急著追 L2，先把 1–5 補齊

最常見的失敗模式是跳級：團隊看到 Level 2 很酷，直接做自動重訓，但因為第 2 題（資料驗證）沒做，結果自動重訓出一個用壞資料訓練的模型，還自動部署上線了。自動化會放大你的問題，不會修正它。

四、取捨：升級的順序與該停在哪一級

不是每個團隊都需要 Level 2。判斷依據是模型更新頻率與失效代價：

升級順序的建議（依投資報酬率排）：

1. 先做監控（Day 14）——你連現在好不好都不知道，做什麼都是盲目的。
2. 再做實驗追蹤與模型註冊（Day 10）——成本最低、痛感解除最快。
3. 接著做資料驗證（Day 09）——擋掉最多的線上事故。
4. 然後管線化（Day 11）——此時才值得投資。
5. 最後才自動重訓——前四項沒做就做這個，等於自動化地製造事故。

⚠️ 給主管的提醒

如果你只能投資一項，選監控。理由：其他四項改善的是「開發效率」，只有監控改善的是「風險」。效率問題會讓你慢，風險問題會讓你在某個週一早上開一場很難堪的會。

今日小結

• MLOps 成熟度三級的差別在交付物：Level 0 交付檔案、Level 1 交付管線、Level 2 交付系統。
• 五年來地基沒變（可重現、CI/CD、容器、監控），上層被改寫：不自己訓練、版本擴大為「模型＋提示＋索引＋評測集」、評估變成工程、成本從一次性變成每次請求。
• 一句話：2021 問「我的模型怎麼上線」，2026 問「別人的模型怎麼在我的系統裡穩定、便宜、安全地工作」。
• 用十題診斷表定位，別跳級——自動化會放大問題，不會修正問題。
• 升級順序：監控 → 實驗追蹤 → 資料驗證 → 管線化 → 自動重訓。只能做一項就做監控。

明天預告

明天處理 Level 1 的第一塊拼圖，也是我認為最被低估的一塊：資料。DVC 怎麼在不把大檔塞進 Git 的前提下版本化資料、資料驗證怎麼擋掉最多的線上事故，以及那個讓無數模型上線後表現落差的元凶——訓練—服務偏斜。

延伸閱讀

• 📄 Google Cloud, MLOps: Continuous delivery and automation pipelines in machine learning——Level 0/1/2 的原始出處。
• 🔗 2021 鐵人賽《從 AI 落地談 MLOps》 · GitHub——想看「五年前我們怎麼談這件事」，那個系列仍然值得一讀。