想把 ML 用到生產環境，MLOps 不是選配

MLOps 不是機器學習的附加功能，而是把模型變成可穩定上線、可監控、可回滾的生產系統的必要層。

MLOps 不是加分項，而是 ML 能不能真的進入生產環境的分水嶺；沒有它，模型多半只停留在 demo。

Thomas Nys 指出，許多 ML 專案卡在「做得出模型」和「跑得進生產」之間，真正的障礙通常不是準確率，而是環境不可重現、推論延遲不穩、退化無法監控、更新不能安全回滾，以及整體生命週期缺乏治理。這也是為什麼 notebook 裡的成功，不能直接算成商業價值。

第一個論點：生產環境會把 ML 變成另一種系統問題

傳統軟體是決定性的，程式碼不變，行為大致可預期；但 ML 系統的輸出同時受模型、資料與特徵影響。這意味著開發環境測試通過，不代表上線後仍然穩定。DevOps 管的是部署流程，MLOps 管的是資料與模型一起變動時的風險。

最典型的例子是 training-serving skew。假設訓練時某個特徵用一套計算方式，上線時卻因為資料管線不同而換成另一套，模型在離線評估看起來正常，到了真實流量卻開始失準。這不是邊角案例，而是導致 drift、錯誤預測與事故排查困難的常見原因。

第二個論點：可靠性比單次準確率更重要

Nys 的核心觀點很直接：建模只是工作量的一小段，真正耗時的是把它長期運營起來。他估計模型建立大約只佔 20%，其餘 80% 都在維護、監控、更新與治理。這個比例對產品團隊很殘酷，但也很真實，因為上線後最貴的從來不是第一次跑通，而是資料變了之後還能不能撐住。

監控就是把這件事攤在陽光下。模型可以在離線指標上表現良好，卻因為新產品上線、用戶結構改變或市場條件變化而迅速劣化。若沒有 data drift、concept drift 與基礎設施監控，團隊往往要等到營收下滑、風險升高或客訴暴增後才知道出事。MLOps 的價值，就是把退化提早變成可觀測事件。

反方可能怎麼說

最合理的反對意見是：不是每個 ML 專案都值得一套完整 MLOps。若模型只是實驗性質、風險低、更新少，重度基礎設施確實會拖慢團隊，還可能浪費預算。對小團隊來說，managed service 加上最小化自動化，常常才是正解。

另一個現實問題是過度工程化。feature store、workflow orchestrator、model registry、監控平台一字排開，如果沒有人真正負責，最後只會變成工具堆疊，而不是能力堆疊。若場景不關鍵，這種複雜度沒有回報。

但這個反對意見只是否定「做太多」，不是否定「要做」。正確答案是 right-size MLOps，而不是跳過 MLOps。至少要有實驗追蹤、版本控管與基本監控；一旦模型開始影響營收、風險或客戶體驗，操作紀律就不再是額外成本，而是上線的最低門檻。

你能做什麼

如果你是工程師，先做 experiment tracking、模型版本控管與最簡部署路徑，再談進階工具；如果你是 PM，把監控與回滾當成產品需求，而不是實作細節；如果你是創辦人，預算要包含資料品質、責任歸屬、治理與維護。不能被運營的 ML，不是產品，只是附帶儀表板的原型。