什麼是 MLOps？跟 DevOps 有甚麼區別？
MLOps 是一個近幾年隨著機器學習成熟而推出的一個「概念」。雖然對於 MLOps 的定義尚未成熟，各種工具與系統也是百家爭鳴；但是大家一致的認為 MLOps 可以幫助機器學習技術在商業系統中能夠達到各種好處，包括：
- 增加機器學習系統的可擴展性
- 增加機器學習系統的開發效率與維護效率
- 增加機器學習系統的穩定性
- 降低除錯成本
我在這篇文章整理了 NVIDIA、Amazon、Microsoft、Google 等大廠對於 MLOps 的解釋。本篇文章包含以下部分：
- 簡介 DevOps 與 MLOps 的關係
- NVIDIA: 什麼是 MLOps？
- Amazon: 為什麼 MLOps？
- Microsoft: MLOps 成熟度的 5 個等級
- Google: MLOps 成熟度的 3 個等級
- 總結
DevOps 與 MLOps
DevOps: Development + Operations
DevOps 是十年前推出的一門學問，旨在如何用敏捷 (agile) 與自動化 (automatic) 的方式來結合軟體開發 (Software Development) 與 IT 營運 (IT Operations) 兩個團隊，是一種同時增加開發效率與維護能力的方法論。
一般 DevOps 可以用一個無限循環示意圖來解釋，分為 Dev 與 Ops 兩個部分，來解釋在 DevOps 中的軟體開發流程是如何在 Dev 與 Ops 兩邊循環流動與互相影響。如下：
DevOps 作為一套方法論，發展至今也沒有統一的定義。但是提到 DevOps 以及其相關工具的時候，大部分都會提到 2 個關鍵字——CI/CD：
- CI (Continuous Integration)：持續整合，代表利用自動化的編譯與測試方法來合併多個工程師提交的程式碼。CI 的建置流程可以加速團隊的開發效率，同時提升交付的程式品質。
- CD (Continuous Deployment/Continuous Delivery)：持續部署或持續交付。與 CI 一樣，持續部署和持續交付都強調自動化把程式碼運行到測試環境與線上環境。
MLOps: ML with DevOps
機器學習領域 (Machine Learning, ML) 在於學術領域已經越來越成熟，各種工具例如 TensorFlow 與 Torch 也降低了學習難度，大家都可以訓練自己的模型。但是訓練出來的模型怎麼放到最終的軟體中，變成一個商用軟體系統，中間會遇到很多的問題，包括軟體工程、數據工程等等問題。
ML 領域需要一個與 DevOps 相似的概念與方法，來解決 ML 領域的實務問題。最終，結合 ML 與 DevOps 的產物就是 MLOps。
MLOps 是基於 DevOps 擴充到 ML 的方法論。如同 DevOps 的概念較為宏觀且廣泛，各種 MLOps 的解釋也會根據作者「如何理解 DevOps」、「如何連結 ML 與 DevOps」的不同觀點而得出不同的 MLOps 定義。
無論定義如何，所有 MLOps 的目的都是提升 ML 系統的開發效率，包括：模型訓練、模型驗證、模型部屬、模型監測、自動化……等等。
NVIDIA: What is MLOps?
在 NVIDIA Blog 的《What is MLOps? 》中，NVIDIA 引用了 Neal Analytics 的 MLOps 示意圖，基本就是在 DevOps 的左邊加上了 ML 的區域。在這個示意圖中，ML 只是作為團體開發的上游，也就是 ML 模型的提供方。整體的循環還是主要由 DevOps 形成，ML 在裡面的角色相對的獨立。
NVIDIA 對 MLOps 的觀點與 DevOps 非常相近，也非常符合 NVIDIA 在 AI 生態鏈中的角色定位：基礎技術提供方——對於團體開發者而言，機器學習其實也是屬於一種「技術提供方」，這部分的角色與 NVIDIA 是高度相似的。
這篇文章中多次提到了 Kubernetes, Container, Multi-GPU 等虛擬化技術概念。綜觀下來，這篇文章認為 MLOps 的主要任務就是：在自動化的雲平台上最大化 GPU 的使用效率，並且優化機器學習系統的研發週期與效果。
除此之外，文章與圖例都都提到了 data 與 model 本身都需要合適的追蹤與自動化工具，也是 MLOps 中很重要的 2 個部分。雖然這 2 個部分在 NVIDIA 的文章中雖然沒有詳細展開，但是在 Microsoft, Google 的文章中卻有很全面說明。
Amazon: Why MLOps
Amazon 雖然寫了《什麼是DevOps？》來介紹 AWS 對 DevOps 的基本定義與 自家提供的 AWS 工具與服務，卻沒有單獨的文章說明 MLOps。但是在其 MLOps 產品 SegeMaker 中，提到了 MLOps 的挑戰與優勢：
MLOps 的挑戰
- 專案管理：MLOps 通常需要整合跨專業的部門，包括：ML 團隊、工程團隊、產品經理團隊。這些人往往使用者不同的技術語言，對於最終的業務解釋能力與理解能力都不盡相同。
- 溝通協作：呈上，MLOps 所需要的資源也坐落在不同團隊的人員手上，例如訓練資料、模型結構、APP 程式碼等等。
- Everything is Code：MLOps 與 DevOps 相同，講求自動化的方法論，因此許多環節都可以使用程式碼來表示，例如：用 Docker 語法定义測試机器。在 MLOps 中，引入了更多額外的模組與系統，也增加了挑戰性。
- CI/CD：在 MLOps 中，CI/CD 會包含重新訓練、部署、測試 ML 模型的部分。這部分需要大数据的输入，並且也相當耗時。如果在 CI/CD 的花費時間過長，就會喪失 MLOps/DevOps 的交付效率。
- 監測與紀錄：對於機器學習應用來說，線上的效果监控比一般的 App 效果监控更有難度，因為機器學習需要使用線上的 live data 搭配實驗測試才能得到效果指標。
MLOps 的好處
- 生產力：能夠提升 ML 工程師與軟體開發工程師的效率。
- 可重複性：因為所有東西都是自動化且可擴展的，因此所有環節都保證可以重複執行。
- 可靠性：透過 CI/CD 確保程式的快速交付，同時兼顧程式碼品質。
- 可審核性：因為所有程式碼與 data 都是有版本控管的，因此當系統出現錯誤的時候就能較輕易的定位問題。
- 數據與模型品質：MLOps 對於模型效果與數據特性都會進行持續追蹤，幫助工程師發現模型偏差並快速修正。
Everything is Code, Includes ML
Amazon 雖然通篇沒有提到 MLOps 的定義，但是從側面提到了不少其認為 MLOps 該具備的特性以及能夠解決的問題，包括版本控管、自動化、快速交付等等 DevOps 中的基礎特性。
總觀這些觀點來看，Amazon 的 MLOps 是把「ML 模型」與「數據」都視為程式碼的一部分，利用 CI/CD 等方法論對這些「程式碼」做管理，引入 DevOps 的流程中。
Microsoft: 5 等級的成熟度模型
在微軟公開的 GitHub 上，對 MLOps 給了如下的解釋：
MLOps empowers data scientists and app developers to help bring ML models to production. MLOps enables you to track / version / audit / certify / re-use every asset in your ML lifecycle and provides orchestration services to streamline managing this lifecycle.
這段解釋與 Amazon 有幾個異曲同工的地方，例如微軟同時提到了數據科學家與 App 工程師，与 Amazon 提到的跨團隊與專案管理與溝通協作相符合；微軟提到的版本控管、審核、重複使用等 DevOps 中的關鍵特性，也與 Amazon 列舉 MLOps 的各種好處高度重合。
在 Microsoft Docs 中的另一篇文章《Machine Learning Operations maturity model》，提到了開發團隊在 MLOps 的成熟度模型可以用五個等級來評價：
Level 0: No MLOps
所有的訓練、測試與部署都是手動的。團隊的開發效率很低，而且存在著大量的管理盲區，隨時會發生不可預測的錯誤。
Level 1: DevOps but no MLOps
這個等級中，應用程式已經包含了自動化部屬與自動化測試能力，但是不包含 ML 模型的部分。但是在這個等級中，ML 團隊需要手動的獲取新訓練資料、手動驗證、手動交付。這個等級出現的 ML 問題通常難以追蹤與重現。
Level 2: Automated Training
這個等級中已經可以自動化的訓練，但是 ML 模型還是手動的交付到軟體開發團隊，因此仍然需要數據科學家的介入。這個階段中 ML 所需的訓練資料都是自動化的，同時團隊也對 ML 模型建立了版本控管機制，這有益於追蹤或重現任何 ML 問題。
Level 3: Automated Model Deployment
相對 Level 2，Level 3 引入了完整的 CI/CD 在部屬流程，因此大大的提升了自動化等級。在這個等級，ML 模型的訓練由於有 CI/CD 的自動化把關，因此 ML 模型訓練比較不需要數據科學家的介入，提升了開發效率。
Level 4: Full MLOps Automated Operations
比 Level 3 更進一步，ML 模型可以根據效果指標自動的重新訓練並更新。這個階段的軟體工程師會與數據科學家更緊密的合作，達到全自動化的 MLOps。
Google: 3 等級的成熟度模型
在這篇 Google Cloud 的文章《MLOps: Continuous delivery and automation pipelines in machine learning》中，Google 將 MLOps 定義為一種文化與實踐：
MLOps is an ML engineering culture and practice that aims at unifying ML system development (Dev) and ML system operation (Ops).
在一個機器學習系統中存在的大量的工作任務，例如：數據收集/分析/準備、模型訓練/測試/驗證/部署等等。Google 認為 MLOps 就是利用 DevOps 來自動化的完成 ML 的工作步驟，例如：CI, CD, CT（Continuous Training）。根據自動化程度的不同，Google 認為 MLOps 成熟度可以分為 3 個等級。
Level 0: Manual Process
這是大部分公司的 ML 業務的現有狀態，在這個階段，ML 與 Ops 是完全隔離開的，通常意味著 ML 團隊會把模型部署到代碼之中就交接給開發團隊。
這個階段介於 Microsoft 的 Level 0-1 之間。因為這個階段工程團隊會有自己的測試部署流程，ML 模型也必須跟著工程專案經過一系列的測試驗證才能運行在線上產品。
Level 1: ML Pipeline Automation
Level 1 的目的是要打造全自動化的持續訓練流程（CT），因此 ML 模型的 CI/CD 都是其中的必備條件。這代表不包括是模型訓練，模型驗證與模型測試等等步驟都必須是自動化的。這個階段介於微軟的 Level 2-3 之間。
不同於 Level 0，ML 團隊提交的是一個模型，在 Level 1 的 ML 團隊提交的是一份自動化 Pipeline。在這個 Pipeline 裡面，Liva Data 會持續地流入訓練，而 ML 模型也會經由這個訓練流程自動的更新，並自動部署上線。
因為是利用 live data 進行自動化訓練，因此數據與模型的自動化驗證至關重要。如果 live data 發生了預期外的變化，或者是模型的效果出現了異常，自動化訓練就必須重新開始，甚至終止整個訓練流程。
Level 2: CI/CD Pipeline Automation
與 Level 1 最大的差別在於：Level 1 只對 ML 模型做了 CI/CD，而 Level 2 對 ML 模型與訓練 Pipeline 都做了 CI/CD（如下圖）。這確保系統中的所有程式碼都是全自動的，且都經過了 CI/CD 的保障。
總結
MLOps 是一個大題目，且如同 DevOps 一樣，如果理解的不深的話就容易陷入瞎子摸象的困境。MLOps 包含了各種自動化、跨團隊協同工作、敏捷開發、Everything is Code 等概念，但任何一個單一概念都不足以被稱之為 MLOps。
根據自身角色的不同，MLOps 也會有不一樣的解釋。例如對於 NVIDIA 而言，MLOps 在於如何透過好的架構設計提升機器學習模型的開發效率；而對 Microsoft, Google, Amazon 等自身擁有雲服務的公司來說，MLOps 就會與雲端服務與佈署結合的更強。
MLOps/DevOps 不只是一連串流程與工具，也是一種文化。如果順利將 MLOps/DevOps 的各種概念與想法在團隊內部推行起來，對應的流程與工具就會自動的被建立起來，團隊的生產效率也會對應的提升。
如果各位同學也對 MLOps 有一套自己的解釋，也歡迎大家告訴我。
