Microsoft 的 MLOps 五級成熟度模型
Microsoft Azure 把 MLOps 分成五級，從手動訓練到自動監控與重訓。這套模型重點不是打分數，而是看團隊能不能重現、追蹤和自動化模型流程。
Microsoft 的 Azure 指南把 MLOps 分成五級，從手動訓練一路到自動監控與重訓。
說真的，這份指南很實在。它不是在賣夢想，而是在拆流程。Microsoft Learn 的 MLOps maturity model 直接把機器學習維運切成 5 個層級。
重點也很直白。從 Level 0 到 Level 4，差別不是模型多準，而是能不能重現、能不能追蹤、能不能自動化。很多團隊卡住，不是卡在演算法，是卡在交接和上線。
| Level | 名稱 | 變化重點 |
|---|---|---|
| 0 | No MLOps | 手動訓練、手動發版、幾乎沒追蹤 |
| 1 | DevOps but no MLOps | App code 自動化了，模型流程還很手工 |
| 2 | Automated training | 訓練可重現、可追蹤，發版仍手動 |
| 3 | Automated model deployment | CI/CD、測試、跨 workspace 推進 |
| 4 | Full MLOps automated operations | 監控可觸發 retraining，還能政策式升版 |
Microsoft 到底在量什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
這套模型不是拿來貼標籤。它量的是營運成熟度。Microsoft 把它拆成三塊：people and culture、processes and structures、objects and technology。講白了，就是人、流程、工具三件事。
這很重要。很多團隊 notebook 寫得很漂亮，demo 也能跑。可是一到 production，就開始亂。版本沒管好，監控沒接上，出事時也找不到是誰改了什麼。
所以這份模型真正想問的，不是「你的模型多強」。而是「你的系統能不能穩定交付」。這差很多。前者是研究味，後者才是企業真的會付錢的地方。
- Level 0：手動訓練、手動部署、手動測試
- Level 1：App release 自動化，但模型還靠資料團隊接手
- Level 2：訓練可重現，程式碼與模型都有版本控管
- Level 3：CI/CD 成形，模型可跨 workspace 推進
- Level 4：監控能觸發 retraining，還能依政策自動升版
Microsoft 也很務實地說，團隊常常同時落在多個層級。這句很有意思。因為真實世界就是這樣。你可能有自動化部署，但模型還在手動審核。
所以別把成熟度模型看成考卷。它比較像地圖。它告訴你，哪一段還在土路，哪一段已經鋪好柏油。
五個等級，白話講就是這樣
Level 0 就是最原始的玩法。有人把模型檔案寄來寄去，訓練、驗證、部署都靠人盯。實驗紀錄不完整，出問題時也很難回頭查。
Level 1 先把軟體那半邊救起來。App code 有版本控管了，build 也能自動跑，但模型還是靠資料團隊人工處理。看起來比較像 DevOps，實際上 MLOps 還沒真的落地。
Level 2 才開始有點像樣。訓練環境變成 managed，訓練流程可重現，模型與 training code 也有版本。Microsoft 還提到 managed feature store 和 Azure Event Grid，這代表事件驅動的流程開始進場。
Level 3 就進入正式的發版節奏。模型部署可以自動化，CI/CD、單元測試、整合測試都要跟上。模型 artifacts 也能透過 Azure Machine Learning registries 在不同 workspace 間流動。
Level 4 是很多團隊嘴上說想要，實際上很少真的做完的那層。監控不只是看儀表板而已，還能直接觸發 retraining。Promotion 也能靠 policy 決定，不再全靠人拍板。
“The MLOps maturity model defines principles and practices to help you build and operate production machine learning environments.” — Microsoft Learn
真正的瓶頸，常常不是模型
這份指南最有價值的地方，是它把成熟度拆得很細。它看 people、model creation、model release、application integration。這很對。因為很多團隊以為問題在準確率，其實問題在交接。
你想想看。模型準了，不代表能上線。上線了，也不代表能追蹤。追蹤了，也不代表出問題時知道怎麼回滾。這些才是 production 的真麻煩。
Microsoft 的表格一直在重複同一個方向：更多自動化、更多版本控管、更多測試、更多可視性。這些詞聽起來很工程，但它們其實就是少出包的基本功。
- Level 0 和 Level 1 都還是手動 release
- Level 2 開始有 managed compute 與 tracked experiments
- Level 3 需要 CI/CD，還要有 unit test 和 integration test
- Level 4 把 production signal 接回訓練流程
很多 MLOps 計畫會卡住，就是因為順序搞反了。有人先衝 training 自動化，卻沒做 release。也有人加了 monitoring，卻沒定義 alert 之後誰要動作。
Microsoft 的模型把這些事排成一條線。先讓訓練可重現，再讓部署可預測，最後才讓 production 訊號回頭影響下一輪。這個順序很土，但很有效。
GenAI 把規則又拉開一層
Microsoft 也把傳統 MLOps 和 GenAIOps 分開看。這點很合理。因為 LLM 工作流不是只有 retraining，還有 prompt lifecycle、retrieval augmentation、output safety 和 token 成本治理。
這裡很多團隊會犯一個錯。把 GPT、Claude、LLM 的流程硬塞進舊的 MLOps 架構，然後以為加一層 pipeline 就結束了。其實不行。Prompt 版本、輸出安全、成本控管，都是新問題。
但別誤會。這不代表 MLOps 沒用了。剛好相反。版本控管、測試、監控、發版流程，這些老骨架還是要留著。只是控制點從 model weights，移到 prompt、retrieval、policy 和 cost。
如果你們團隊已經有 Azure Machine Learning 的基礎，Microsoft 的意思很明白：先把既有流程延伸出去，不要整套打掉重來。說白了，工具只是工具，流程才是本體。
競品怎麼看這件事
如果拿其他平台來比，Microsoft 這套模型的優點是清楚。它把成熟度講得很細，也很適合企業內部做盤點。缺點也有，就是太偏 Azure 生態。你如果用的是其他雲，很多概念能抄，實作細節就得自己補。
像 AWS SageMaker 也在講 MLOps，但它更常從服務與元件切入。Google Vertex AI 則偏向整合式平台。Microsoft 的路線比較像先給一張成熟度地圖，再告訴你 Azure 裡有哪些元件能對上。
這三家都在講同一件事：模型不是訓練完就結束。真正麻煩的是上線後。誰來監控 drift，誰來處理資料變動，誰來決定要不要 retrain，這些才是成本大頭。
- Microsoft：成熟度分級清楚，適合做內部盤點
- AWS：服務元件多，適合既有 AWS 團隊接軌
- Google：平台整合強，適合想要一站式流程的團隊
- 共通點：都把監控、版本、部署、回滾放在核心
如果你是台灣的開發團隊，我會很直接地說。先別急著比誰的模型最準。先比誰的 release 最穩，誰的資料變動最早知道，誰的回滾最不痛。
那才是真正的成本差。模型分數高，不代表維運省事。這點很多人都踩過雷。
這張成熟度圖，對團隊有什麼用
這份模型最實際的用途，是拿來排優先順序。你可以先問三個問題：實驗能不能重現、模型能不能追蹤、production 訊號能不能回流。只要有一題答不出來，就還有很大空間。
如果你們現在還在 Level 0 或 Level 1，先做 traceability 和 automated training 最划算。不要一開始就想搞花俏的 production optimization。那通常只是把問題包裝得比較漂亮。
如果你們已經接近 Level 3，那下一步通常是監控。不是裝一個 dashboard 就算數。你要的是監控能真的觸發動作，像 retraining、promotion、rollback 這些。
講白了，MLOps 成熟度不是看你買了多少工具。是看模型改一次，能不能穩穩地走到 production，還能留下完整紀錄。這才是團隊值不值得擴大的差別。
我自己的判斷很簡單：接下來一年，真正贏的團隊，不會是模型最會講故事的那群，而是最少靠人肉救火的那群。