MLOps簡介

1、什麼是 MLOps？

機器學習操做 (MLOps) 基於可提升工做流效率的 DevOps 原理和作法。 例如持續集成、持續交付和持續部署。 MLOps 將這些原理應用到機器學習過程，其目標是：

• 更快地試驗和開發模型
• 更快地將模型部署到生產環境
• 質量保證

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

舉個簡單的例子，幾年前咱們對於機器學習的印象主要是拿到一堆excel/csv數據，經過notebook等嘗試作一些模型實驗，最終產出一個預測結果。但對於這個預測結果如何使用，對業務產生了什麼影響，你們可能都不是頗有概念。這就很容易致使機器學習項目一直停留在實驗室階段，一個接一個作POC，但都無法成功「落地」。

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

回顧這個發展，是否是感受似曾相識？20年前軟件行業在數字化演進道路上也遇到過相似的挑戰。咱們從部署一個Web服務到要部署幾十甚至上百個不一樣的應用，在各類規模化交付方面的挑戰之下，誕生了DevOps技術。像虛擬化，雲計算，持續集成/發佈，自動化測試等軟件工程領域的各種最佳實踐基本都跟這個方向有關。在不遠的未來，或許智能模型也會與今天的軟件系統同樣廣泛。一個企業須要使用很是多的業務系統來實現數字化流程，一樣也須要很是多的模型來實現數據驅動的智能決策，衍生出更多與模型相關的開發運維，權限，隱私，安全性，審計等企業級需求。

所以最近幾年，MLOps也逐漸成爲了一個熱門話題。有了好的MLOps實踐，算法工程師一方面能更專一於擅長的模型構建過程，減小對模型部署運維等方面的「感知」，另外一方面也讓模型開發迭代的方向更加清晰明確，切實爲業務產生價值。就像今日的軟件工程師不多須要關注運行環境，測試集成，發佈流程等細節，但卻作到了一天數次發佈的敏捷高效，將來算法工程師應該也能更專一於數據insights獲取方面，讓模型發佈成爲幾乎無感又快速的自動化流程。

2、MLOps的各個步驟

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

• 1. 項目設計，包括需求收集，場景設計，數據可用性檢查等。
• 1. 模型開發，包括數據工程，模型工程，以及評估驗證等。
• 1. 模型運維，包括模型部署，CI/CD/CT工做流，監控與調度觸發等。

DevOps經過縮短開發部署的時間來更快地迭代軟件產品，使得公司業務不斷進化。MLOps的邏輯也是經過類似的自動化和迭代形式，加快企業從數據到insights的價值獲取速度。

MLOps的核心要解決的問題之一是縮短模型開發部署的迭代週期，即各種efficiency問題。從Algorithmia的2020年的這份報告中能夠看到，很大一部分公司須要31-90天上線一個模型，其中有18%的公司須要90天以上來上線一個模型。且在中小型公司中，算法工程師花在模型部署方面的時間比例也明顯偏多。MLOps但願經過更標準化自動化的流程與基礎設施支持，來提高模型交付的總體效率。

另一方面，MLOps還但願能提供一個企業內各個角色無縫協做的平臺，讓業務，數據，算法，運維等角色能更高效率的進行協做，提高業務價值產出，即transparency的需求。後面咱們的詳細討論中也會反覆印證這兩個核心訴求。

3、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

與傳統軟件系統的肯定性行爲不一樣，機器學習中帶有很多「隨機化」的成分，這對各類問題的排查，版本回滾，輸出效果的肯定性都提出了必定的挑戰。所以咱們在開發過程當中也須要時刻將可復現原則放在心上，設計相應的最佳實踐（如設定隨機數種子，運行環境等各種依賴的版本化等）。

4、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中的各個環節也須要關注相應功能的支持。