是否正在煩惱如何更有效地促進資料科學家、軟體工程師、和維運工程師之間的合作？
是否苦於找尋如何穩定地研發與交付機器學習模型服務？
是否正在找尋如何持續維持機器學習模型服務效能的方式？
如果曾經為以上的問題煩惱，或者是希望持續提升團隊交付機器學習服務的能力，那麼 MLOps 肯定是你不會錯過的議題。
機器學習模型並非是交付機器學習服務中 唯一 的工作，由上圖1，可以了解模型本身只不過佔據了實現模型服務的眾多任務中的一小部分而已。機器學習模型服務的開發，不僅僅涉及如何實現模型，還含括了軟體開發與後續維運的議題，因此相較於常見的軟體服務開發來說，複雜度更高也更容易產生技術債務的累積。MLOps 是希望能夠透過 DevOps 的優良實務作法來提升模型服務交付的水準，並且降低或免於技術債務的累積。DevOps 所提倡的持續整合與交付和溝通與協作，也讓習於沉浸在資料與模型實驗的資料科學家們有機會以全局的角度看待服務交付的議題，並且讓整個價值流上的其他人員可以更有效地與資料科學家們合作註2
三個核心概念
1. 版本控制不只侷限於程式碼
版本控制的基本目的是為變更建立可追蹤性，以便作為之後除錯與改善的基礎。
程式開發者透過 Git 之類的工具，為程式實作進行版本控制可能是相當直覺的作法，而這樣的作法，對於資料科學家或者是模型工程師來說，應該也不是太陌生的操作。透過對程式碼進行版本控制，可以妥善管理模型與資料處理的相關實作內容。但對於一個機器學習專案來說，只是管理程式碼實作則是遠遠不足的！
🤔 試著想像一下機器學習專案可能會遭遇的場景!
首先，用來建立模型的資料會隨著時間的推移與相關的系統操作而持續發生變動。另外，在進行模型開發過程中，也會對資料進行處理與篩選，這些過程都會影響當下模型的實作與訓練結果(如精確率、召回率等)。為了能夠提供之後改善的基礎，以及提供模型建立的可再現性，環繞於模型建立的相關資訊都應該進行版本控制，當然也必須包含訓練完畢的模型本身。
🤔 除了這些顯而易見的資訊外，還有其他比較沒這樣直覺相關的資訊嗎？
這個答案顯然是肯定的。當進行模型訓練時，所採用的運算資源、訓練的時間長短、以及花費的成本，最好也都能一併被記錄追蹤下來，這樣才能為之後的改善和實驗提供好的比較基礎。
所以，讓我們總結一下有哪些東西需要進行版控，以便追蹤紀錄的呢？
- 模型實作相關
1. 模型參數
2. 資料集
3. 模型效能分析數據
4. 模型本身
- 模型訓練環境
1. 運行採用的資源
2. 運行時長
3. 運行成本
最後，需要提醒的是，版號的設計自然是按照組織的原先習性與規則，但更重要的是由於每個待版控的資料，可能有不同的版本號碼，務必對版本之間的關聯性進行維護，這樣才能達成所謂的可再現性。
2. 盡可能將模型實現過程自動化，免除人為操作
由於模型的建立過程會涉及資料收集、清洗、轉換、以及模型測試等步驟。模型的維護與開發是一種動態且持續的過程，先不論相同資料尚且會產生不同的訓練結果，整個過程中的每一個環節產生的輸出所造成的不一致，都會影響模型的品質和開發的效率。因此，在機器學習專案中，將這些對專案的品質與成功有莫大影響的穩定因子程式化是相當重要的一個步驟。
試想應該沒人願意在極短周期內，重複地進行複製與貼上資料的工作吧？另外，繁瑣的人工操作也容易引發錯誤。
良好且必要的說明與註解，仍然是免不了的，畢竟球不是一個人打的，至少為未來的自己留下些紀錄與說明，也不會是太壞的事情。然而若能夠將操作型的說明文件變成可執行的自動化程式，那就更好了！這將大大地省去後續的人力耗費，也是機器學習專案中不可妥協的一部分。
3. 資料處理到模型更新與監控的完整流水線才是機器學習專案的完整交付
說到機器學習專案的成果，直覺上的反應肯定是機器學習模型。
不過，機器學習模型有別於一般開發的軟體系統。
開發完畢的軟體系統具有穩定的特性，反觀機器學習模型則無此特性，它即易受到環境與時間的遷移而影響原先的預測能力。試想無法持續滿足專案商務目標的暫時有效機器學習模型能夠成為專案的交付成果嗎？
答案很簡單，不行!!
因此，機器學習專案的交付成果必須包含能夠持續地整合資料、持續地訓練模型、持續地佈署模型、與持續地對模型進行確效的完整流水線，而非單單只是模型本身。當然可能有人會說，一些簡單小型的機器學習專案的環境變動狀況較低，持續字眼太強烈 🤮。這邊要特別解釋的是 — DevOps 所提及的持續整合，說到底是個自動化的機制，以便將因為需求所發生的變更帶入主幹後，自動地把相關檢測、建置與佈署任務完成。因此，機器學習專案在交付時，不管是需求提出方或者是需求滿足方，都應該考量變更發生時的更新機制，並且將其視為交付的一部分，尤其當處理的場景更加複雜且易變動時，確效與監控則更不應該忽略。
自建或者是購買？！
由於人工智慧的熱潮高漲，先不論真實需求為何，很多組織都前仆後繼的希望為公司建立人工智慧的能力，也恨不得能夠立即引入各種平台工具，抑或者是模型應用。公雲現在提供了很多的工具來進行機器學習專案的開發，比方說 Azure ML 或 AWS SageMaker等，即便不討論公雲也有許多其他 MLOps 相關的平台工具可以使用，比方說 allegro、cnvrg.io 等。當然可能也會有人才薈萃的團體希望能夠自建平台。因此在討論 MLOps 的同時，不得不額外再談一下自建或購買的議題!
不管是自建或購買，根據本篇文章的三個核心概念，以下是最低需求：
1. 能夠為整個模型建置的過程提供可追溯性與版本控制
2. 能夠建立完整的模型服務的流水線
3. 提供模型佈署的功能
- 關於自建
自建的好處在於可高度客製化與可擴充
自建工具的兩大首選不外乎是 KubeFlow 和 MLFlow，兩者在社群上都有廣大的支持度，因此作為首選一點也不為過。以 KubeFlow 來說，它有著許多延伸的擴展工具比方說 KFServing、Katib 等，然而在安裝與設置的困難度則較 MLFlow 來得高，雖說 MLFlow 的安裝設置過程簡單得多，不過在功能的可能性上則受限許多。但不管如何，兩個都是相當好的開源工具，對於正在探索的個人或者組織來說，都是不錯的嘗試目標。不過嘗試是一回事，自建為日後的平台則又不得不考量以下的問題：
1. 自建所需的時間成本，將推遲企業在人工智慧上的進展
2. 日後的維護
就拿 KubeFlow 為例，它不僅僅學習曲線較高，且從它的名稱大概也不意外它是基於 Kubernetes 而來，所以在使用它之前，組織必須先會 Kubernetes。容器技術自然也是開發團隊的基本技能與假設。這對於工程團隊來說，可能還好也可能很不OK。另外，建置完畢後，持續維護整個群集並且支付相關的運行成本，對於選擇自建的組織來說，也可能是不可承受之重。
- 關於購買
購買的好處在於可以立即享用，且無前置和額外成本
購買已經建立好的 MLOps 平台，自然是最速解。不僅可以專注在自身專長，並且立即開展機器學習專案外，對於成本支出來說也相對輕鬆許多。目前來說，如前文所述的公雲方案外，也有一些其他的平台工具。然而購買與自建就好比一件事的兩面，自建的缺點在購買模式得到解決，而購買模式則自然不易達到自建的好處。以下是購買的兩個麻煩：
1. 工具的選擇與整合
2. 供應商鎖定 (Vendor Lock-in)
供應商鎖定自然是不難理解，至於工具的選擇與整合，主要的問題在於各家廠商有其競合關係，且功能上各有優缺。有時不容易買一套就滿足各種需求，另外，由於 MLOps 出現的時間並未太長，工具上的研發多半不能照看完整流水線，因此難免開發商會先專注在自身優勢與利基來開展工具產品，此時就必須考量工具與工具之間的易整合性問題。避免工具雖好，但由於整合性差，反而沒提升效率，還造成問題。
自建與購買是兩種截然不同的策略，選擇哪一個比較好，套句管理學常說的話：「It depends!」。比方說，組織有較具規模的專責維運團隊，以及多組開發團隊，那或許自建是能接受的策略，但對於新創與小組織來說，專注在自身的優勢，快速地面向市場提供服務，可能更為重要。因此購買可能是當下的最佳解決方案。因此，在開始 MLOps 的旅程前，直面組織自身的狀況，選擇當下最適即可。
後記
透過 DevOps 在價值流上的關注，以及自動化的追求，可以讓機器學習專案的不同成員注意到交付的全貌、減低換手摩擦，並且促使整個交付團隊成員及早溝通，進行相關的建置，避免原先一關一關的換手模式，所導致的專案風險，進而提高機器學習專案的商務價值與交付效率。