機器學習新概念-MLOps簡介

什麼是 MLOps？

機器學習操作 (MLOps) 基于可提高工作流效率的 DevOps 原理和做法。 例如持續內建、持續傳遞和持續部署。 MLOps 将這些原理應用到機器學習過程，其目标是：

• 更快地試驗和開發模型
• 更快地将模型部署到生産環境
• 品質保證

顧名思義，MLOps就是機器學習時代的DevOps。它的主要作用就是連接配接模型建構團隊和業務，運維團隊，建立起一個标準化的模型開發，部署與運維流程，使得企業組織能更好的利用機器學習的能力來促進業務增長。

舉個簡單的例子，幾年前我們對于機器學習的印象主要是拿到一堆excel/csv資料，通過notebook等嘗試做一些模型實驗，最終産出一個預測結果。但對于這個預測結果如何使用，對業務産生了什麼影響，大家可能都不是很有概念。這就很容易導緻機器學習項目一直停留在實驗室階段，一個接一個做POC，但都沒法成功“落地”。

最近幾年，大家對于機器學習項目落地愈發重視起來，對業務的了解，模型應用流程等都做的越來越好，也有越來越多的模型被部署到真實的業務場景中。但是當業務真實開始使用的時候，就會對模型有各種各樣的需求回報，算法工程師們就開始需要不斷疊代開發，頻繁部署上線。随着業務的發展，模型應用的場景也越來越多，管理和維護這麼多模型系統就成了一個切實的挑戰。

回顧這個發展，是不是感覺似曾相識？20年前軟體行業在數字化演進道路上也遇到過類似的挑戰。我們從部署一個Web服務到要部署幾十甚至上百個不同的應用，在各種規模化傳遞方面的挑戰之下，誕生了DevOps技術。像虛拟化，雲計算，持續內建/釋出，自動化測試等軟體工程領域的各類最佳實踐基本都跟這個方向有關。在不遠的将來，或許智能模型也會與今天的軟體系統一樣普遍。一個企業需要使用非常多的業務系統來實作數字化流程，同樣也需要非常多的模型來實作資料驅動的智能決策，衍生出更多與模型相關的開發運維，權限，隐私，安全性，審計等企業級需求。

是以最近幾年，MLOps也逐漸成為了一個熱門話題。有了好的MLOps實踐，算法工程師一方面能更專注于擅長的模型建構過程，減少對模型部署運維等方面的“感覺”，另一方面也讓模型開發疊代的方向更加清晰明确，切實為業務産生價值。就像今日的軟體工程師很少需要關注運作環境，測試內建，釋出流程等細節，但卻做到了一天數次釋出的靈活高效，未來算法工程師應該也能更專注于資料insights擷取方面，讓模型釋出成為幾乎無感又快速的自動化流程。

MLOps的各個步驟

從大的方面看，MLOps分3個步驟：

1. 項目設計，包括需求收集，場景設計，資料可用性檢查等。
2. 模型開發，包括資料工程，模型工程，以及評估驗證等。
3. 模型運維，包括模型部署，CI/CD/CT工作流，監控與排程觸發等。

DevOps通過縮短開發部署的時間來更快地疊代軟體産品，使得公司業務不斷進化。MLOps的邏輯也是通過相似的自動化和疊代形式，加快企業從資料到insights的價值擷取速度。

MLOps的核心要解決的問題之一是縮短模型開發部署的疊代周期，即各類efficiency問題。從Algorithmia的2020年的這份報告中可以看到，很大一部分公司需要31-90天上線一個模型，其中有18%的公司需要90天以上來上線一個模型。且在中小型公司中，算法工程師花在模型部署方面的時間比例也明顯偏多。MLOps希望通過更标準化自動化的流程與基礎設施支援，來提升模型傳遞的整體效率。

另外一方面，MLOps還希望能提供一個企業内各個角色無縫協作的平台，讓業務，資料，算法，運維等角色能更高效率的進行協作，提升業務價值産出，即transparency的需求。後面我們的詳細讨論中也會反影印證這兩個核心訴求。

MLOps的原則

Automation

在整個workflow中所有可以自動化的環節，我們都應該進行自動化，從資料的接入到最後的部署上線。Google那篇經典的MLOps指導中就提出了3個層級的自動化，非常值得借鑒，後面我們會詳細介紹。

Continuous

一說起DevOps，大家就很容易聯想到CI/CD，也從側面印證這條原則的重要性。MLOps在持續內建，持續部署，持續監控的基礎上，還增加了持續訓練的概念，即模型線上上運作過程中可以持續得到自動化的訓練與更新。我們在設計開發機器學習系統時，要持續思考各個元件對“持續”性的支援，包括流程中用到的各種artifacts，他們的版本管理和編排串聯等。

Versioning

版本化管理也是DevOps的重要最佳實踐之一，在MLOps領域，除了pipeline代碼的版本管理，資料，模型的版本管理屬于新湧現的需求點，也對底層infra提出了新的挑戰。

Experiment Tracking

實驗管理可以了解為version control中commit message的增強。對于涉及模型建構相關的代碼改動，我們都應該能記錄當時對應的資料，代碼版本，以及對應的模型artifacts存檔，作為後續分析模型，選擇具體上線的版本的重要依據。

Testing

機器學習系統中主要涉及到3種不同的pipeline，分别是資料pipeline，模型pipeline和應用pipeline（類似于模型與應用系統的內建）。針對這3個pipeline，需要建構對應的資料特征測試，模型測試以及應用infra測試，確定整體系統的輸出與預期的業務目标相符，達到将資料insights轉化為業務價值的目的。這方面Google的ML test score是一個很好的參考。

Monitoring

監控也是一項軟體工程的傳統最佳實踐。上面提到的ML test score中也有一部分是與監控相關。除了傳統的系統監控，例如日志，系統資源等方面外，機器學習系統還需要對輸入資料，模型預測進行監控，確定預測的品質，并在出現異常情況時自動觸發一些應對機制，例如資料或模型的降級，模型的重新訓練與部署等。

Reproducibility

與傳統軟體系統的确定性行為不同，機器學習中帶有不少“随機化”的成分，這對各種問題的排查，版本復原，輸出效果的确定性都提出了一定的挑戰。是以我們在開發過程中也需要時刻将可複現原則放在心上，設計相應的最佳實踐（如設定随機數種子，運作環境等各類依賴的版本化等）。

MLOps流程細節

我們來看下具體的機器學習項目流程，并對每一個子產品中MLOps需要提供的支援進行詳細的展開。

項目設計

項目設計所需要受到的重視程度毋庸置疑，之前在Fullstack Deep Learning的課程介紹中我們也有很大的篇幅來進行介紹。在MLOps領域，我們應該為這部分的工作也設計一系列的标準與文檔。業界可以參考的材料也有很多，例如 Machine Learning Canvas ，Data Landscape 等。

資料接入

資料接入方面，我們會利用成熟的資料平台，例如各類資料倉庫，資料湖或實時資料源等。對于接入到平台後的資料存儲，可以優先考慮帶有資料版本支援的元件，例如Delta Lake等。當然也可以采用DVC或自行中繼資料維護等方案來進行ML相關資料資産的管理。

資料分析

在資料接入後，一般會需要進行各類EDA分析。傳統的做法一般是使用notebook來進行互動式分析，但對于分析結果的儲存管理，共享協作，資料更新後的自動重新整理，進階互動分析能力方面，原生notebook本身還是有不少缺陷，難以很好滿足。有一些研究與産品在這個方向上做了一些改進，例如Polynote，Facets，Wrattler等。

資料檢查

對于接入的原始資料，通常會出現各類品質問題或資料類型，含義，分布等方面的變化。而機器學習pipeline即使在資料有變化的情況下基本也能順利運作成功，造成意向不到的各種“靜默失敗”問題，其排查處理會相當艱難，耗費算法工程師大量的時間精力。是以設定各類自動化的資料檢查就顯得尤為重要，例如Tensorflow Data Validation就是這方面比較知名的一個library。

O'Reilly在20年做了個關于資料品質方面的調研，發現企業中存在的主要資料問題如下所示：

除上述問題外涉及到模型應用，各類drift的探測也相當重要，比如輸入資料的分布變化(data drift)，或者輸入資料與預測目标之間關系的變化(concept drift)。為了應對這些資料品質問題，我們需要根據不同的業務領域設計相應的資料品質檢查模闆，并結合具體情況進行各類屬性，統計，甚至基于模型的資料問題檢查。

資料工程

這部分的工作包括資料清洗，資料轉換，特征工程。根據業務形态的不同，這部分所占的比重可能會各不相同，但總體上來說這部分在整個模型開發過程中占的比重和遇到的挑戰是比較大的。包括：

• 對于大量資料處理邏輯的管理，排程執行和運維處理。
• 對于資料版本的管理和使用。
• 對于資料複雜依賴關系的管理，例如資料血緣。
• 對于不同形式資料源的相容和邏輯一緻性，例如lambda架構對batch，realtime兩種資料源類型的處理。
• 對于離線和線上資料服務需求的滿足，例如離線模型預測和線上模型服務。

以資料血緣為例，一個經常遇到的場景是當我們發現下遊資料有問題時，可以通過資料血緣圖快速定位上遊依賴項，分别進行排查。而在問題修複後，又可以通過血緣關系重新運作所有影響的下遊節點，執行相關測試驗證。

在模組化應用領域，有不少資料處理特征工程方面的操作和應用會更加複雜，例如：

• 需要使用模型來生成特征，例如各種表達學習中學到的embedding資訊。
• 需要考慮特征計算生成的實踐開銷與其所帶來的模型效果提升的權衡。
• 跨組織的特征共享與使用。

在這些挑戰下，feature store的概念逐漸興起。

關于這方面又是一個比較大的話題，我們先不做細節展開。從上圖可以看出的一個基礎特性是我們會根據線上離線的不同通路pattern，選用不同的存儲系統來存放特征資料。另外在下遊消費時也要考慮特征的版本資訊，確定整個流程的穩定可複現。

模型建構

模型建構方面總體來說是受到關注與讨論比較多的部分，有非常多成熟的機器學習架構來幫助使用者訓練模型，評估模型效果。這塊MLOps需要提供的支援包括：

• 模型開發過程中的結果評估與分析，包括名額誤差分析，模型解釋工具，可視化等。
• 模型本身的各類中繼資料管理，實驗資訊，結果記錄(名額，詳細資料，圖表)，文檔(model card)等。
• 模型訓練的版本化管理，包括各種依賴庫，訓練代碼，資料，以及最終生成的模型等。
• 模型線上更新和離線再訓練，增量訓練的支援。
• 一些模型政策的內建，例如embedding的提取與儲存，stratified/ensemble模型支援，transfer learning之類的增量訓練支援等。
• AutoML類的自動模型搜尋，模型選擇的支援。

在模型實驗管理方面，可以借鑒的産品有MLflow，neptune.ai，Weights and Biases等。

從以模型為中心的角度來看，與feature store一樣，我們需要進一步引入model repository，支援連結到實驗結果的記錄，以及模型部署狀态，線上監控回報等資訊的打通。各類與模型運維相關的操作都可以在這個元件中進行支援。開源方面的實作可以關注 ModelDB 。

內建測試

完成資料和模型兩大塊pipeline的建構後，我們需要執行一系列的測試驗證來評估是否能将新模型部署到線上。包括：

• 模型預測方面的測試，如精度，預測穩定性，特定case回歸等。
• Pipeline執行效率的測試，如整體執行時間，計算資源開銷量等。
• 與業務邏輯內建的測試，如模型輸出的格式是否符合下遊消費者的要求等。

參考Google經典的ML Test Score，具體有以下各類測試：

• 資料驗證測試，除了對原始資料輸入方面的資料品質檢查外，在機器學習的pipeline中做的各類資料特征處理，也需要用一系列的測試來驗證其符合預期。
• 特征重要度測試，對于各類建構的特征，我們需要確定其在模型中的貢獻度，以免造成計算資源和特征存儲上的浪費。對于無用的特征也需要及時清理，控制pipeline的整體複雜度。
• 隐私審計等相關要求測試。
• 模型訓練測試，模型應該能夠利用資料進行有效訓練，如loss會在訓練中呈下降趨勢。并且預測目标相對于業務目标是有提升作用。
• 模型時效性測試，與舊版本模型的效果進行比對，測試模型名額的下降速度，并設計模型的重訓練周期。
• 模型開銷測試，確定複雜模型的訓練時間投入産出比，相比簡單的規則和基線模型有顯著的效果提升。
• 模型名額測試，確定模型的測試集驗證或特定回歸問題驗證能夠通過。
• 模型公平性測試，對敏感資訊，例如性别，年齡等，模型應該在不同特征分組的情況下表現出公平的預測機率。
• 模型擾動測試，對模型的輸入資料進行微小的擾動，其輸出值的變動範圍應該符合預期。
• 模型版本比對測試，對于沒有進行重大更新的模型，例如例行觸發的retrain，兩個模型版本的輸出之間不應該有過大的差别。
• 模型訓練架構測試，例如重複執行2次相同的訓練，應該給出穩定可複現的結果。
• 模型API測試，對于模型服務的輸入輸出做驗證測試。
• 內建測試，對整個pipeline進行運作和驗證，確定各個環節的銜接正确。
• 線上測試，在模型部署但對外服務前，需要進行與離線環境相同的一系列驗證測試，確定運作結果無誤。

模型部署

通過測試後，我們就可以把模型部署上線啦。這裡又根據業務形态的不同分成很多不同的類型，需要考慮不同的釋出方式，例如：

• Batch預測pipeline
• 實時模型服務
• Edge device部署，如手機app，浏覽器等

模型部署的assets除了模型本身外，也需要包含end-to-end測試用例, 測試資料和相應的結果評估等。可以在模型部署完成後再執行一遍相關測試用例，確定開發和部署環境中得到的結果一緻。

對于輸出較為critical的模型，還需要考慮一系列model governance的需求滿足。例如在模型部署前需要進行各類人工稽核，并設計相應的sign-off機制。順帶一提responsible AI近年來也是越來越受到重視，在MLOps中的各個環節也需要關注相應功能的支援。

模型服務

在模型服務流程中，也需要有許多檢查與政策的融入，才能保證整體輸出的可靠性和合理性。各類測試檢查的邏輯可以借鑒前面的測試環節的例子。

模型服務在形式上也非常多變：

是以涉及到的話題也非常多，例如實時模型服務需要考慮模型的序列化，異構硬體利用，推理性能優化，動态batch，部署的形式(container, serverless)，serving緩存，model streaming等。要是涉及到線上更新，還需要考慮online learning的實作。

對于edge deploy，我們需要考慮模型的不同打包方式，模型壓縮等。甚至還可以做hybrid形式的serving或聯邦學習，例如像智能音箱，可以在裝置端部署一個簡單的模型來接收喚醒指令，而将後續複雜的問答發送到雲端的複雜模型進行處理。

在上述模型部署步驟完成時一般也不算是正式釋出，一般會使用一些政策來逐漸用新模型來替代舊模型，包括shadow model，canary部署，A/B測試，甚至MAB自動模型選擇政策等。

在雲原生時代Kubeflow中提供的一系列serverless serving，彈性伸縮，流量管理，以及附加元件(異常檢測，模型解釋)等方面的能力非常強大，值得學習：

模型監控

最後，對于線上模型的運作，我們需要持續進行監控，包括：

• 模型依賴元件的監控，例如資料版本，上遊系統等
• 模型輸入資料的監控，確定schema與分布的一緻性
• 離線特征建構與線上特征建構輸出的一緻性監控，例如可以對一些樣本進行抽樣，比對線上線下結果，或者監控分布統計值
• 模型數值穩定性的監控，對NaN和Inf等情況進行記錄
• 模型計算資源開銷方面的監控
• 模型metric方面的監控
• 模型更新周期的監控，確定沒有長時間未更新的模型
• 下遊消費數量的監控，確定沒有處于“廢棄”狀态的模型
• 對于排查問題有用的日志記錄
• 對于提升模型有用的資訊記錄
• 外界攻擊預防監控

上述的各類監控都要配合相應的自動/人工應對機制。

以模型效果監控為例，當效果出現下降時，我們需要及時介入排查處理，或觸發重訓練。對于重訓練來說，需要綜合考慮模型效果變化，資料更新頻率，訓練開銷，部署開銷，重新訓練的提升度等，選擇合适的時間點進行觸發。雖然有很多模型也支援線上實時更新，但其穩定性控制，自動化測試等都缺少标準做法的參考，大多數情況下，重新訓練往往比線上更新訓練的效果和穩定性更好。

而如果出現了依賴資料的問題，我們也可以設計一系列的降級政策，例如使用最近一版正常的曆史資料，或者丢棄一些非核心特征，使用更基礎的模型/政策給出預測等。

另外這裡還有一個比較有意思的trade-off，如果環境變化較快，而模型重訓練的代價又很高，有時候可以考慮使用更簡答一些的模型政策，往往對于環境變化的敏感度沒有那麼高，但代價是可能會有一些效果上的損失。

流程串聯

Google的這篇文章中，提出了3個level的MLOps流程自動化，将上述我們介紹的各個流程中可以自動化的部分進行了整體的串聯，堪稱MLOps的最佳實踐之一。其中兩個關鍵的自動化提升是pipeline自動化和CI/CD/CT自動化。另外一個比較核心的思想是模型部署并不隻是部署一個模型對外提供服務的API，而是把整個pipeline進行打包部署。另外一個值得參考的方法論來自于Martin Fowler的CD4ML，其中還包含了很多具體元件的選擇建議。

在整體的串聯過程中，一些通用的依賴項有：

• 版本控制系統，包括資料，代碼，和各類機器學習相關artifacts。
• 測試與建構系統，可以将各類運作邏輯在版本更新後自動執行相應測試，通過後打包成pipeline執行的元件鏡像。
• 部署系統，可以将pipeline整體部署到應用環境，包括線上服務和用戶端等。
• 模型中心，儲存已經訓練好的模型，對于訓練時間較長的場景來說尤為重要。
• Feature store，存儲各類特征，并服務于離線場景的批量消費和線上場景的實時查詢消費。
• ML meta store，存儲實驗訓練中産生的各類資料，包括實驗名稱，使用的資料，代碼版本資訊，超參數，模型預測相關的資料和圖表等。
• Pipeline架構，串聯一系列工作流程的執行架構，包括排程執行，斷點續跑，自動并行等等特性。

這些依賴元件中有不少是MLOps中出現的新需求，業界也開始有各類對應産品的湧現，例如Michelangelo，FBLearner，BigHead，MLflow，Kubeflow，TFX，Feast等等。但目前看起來各個元件還遠沒有達到像Web開發持續內建那樣的标準化和成熟程度。例如對于workflow/pipeline元件的選擇，可以參考這個調研。CI/CD方面，傳統的Jenkins，GoCD，CircleCI，Spinnaker等基本也可以滿足需求，當然也可以考慮DVC出品的CML，更加針對機器學習場景來定制。Arize AI的這篇整體ML infra的介紹包含的scope更加全面，對于MLOps中各個元件的選型都可以提供一些參考。對應的開源方面的資源可以參考 awesome production ML 。

最後在設計選型過程中，可以根據以下這個canvas來進行思考規劃。

針對整個流程的開發演進，建議通過靈活疊代的形式進行。即先開發一個基礎的能跑通的pipeline，使用最基礎的資料和簡單模型，把整個流程搭建起來。後續通過業務回報，再去發現整個流程中的重要改進點，逐漸去疊代傳遞。

Summary

MLOps如果能做的好，可以獲得很多回報。個人感覺其中價值最大的有兩點，一是通過各種工程上的最佳實踐，提升了團隊整體開發傳遞模型的效率。二是由于項目運維成本的降低，我們将有機會大大提升機器學習類應用的scale能力，例如在企業内上線上千個模型來為各方面的業務場景産出價值。