MLOps 的工程文化與實踐：以Uber米開朗基羅為例

Published in

Gemini Open Cloud 雙子星雲端

11 min readMay 20, 2021

MLOps的工程文化

我們雙子星同仁 Jonathan Chen在《在混合多雲裡實踐MLOps》一文中，提到 MLOps 是一種「旨在結合ML系統開發與ML系統營運的工程文化與實踐」，我這一篇就是想介紹一下何謂MLOps的工程文化？然後我想引用Uber知名的米開朗基羅(Michelangelo) MLOps平台去詮釋一下Uber如何在Michelangelo 上實踐這種文化。

在混合多雲裡實踐MLOps

日前，在人工智慧協會舉辦的AI Talk活動中，我講了《在混合多雲裡實踐MLOps》這個題目。為了紀念這次經驗，特地自己整理了重點摘要如下。

medium.com

根據維基百科，文化的定義就是「整合知識、信仰、藝術、法律、道德、風俗，以及人作為社會成員而獲得的能力和習慣」。所以MLOps的文化，就是匯合大多科學家跟工程師做人工智慧及機器學習的經驗，整理出來的流程（process）跟最佳實踐（Best Practice）。以下六點，是我認為MLOps流程最重要的信念：

1. MLOps是從多個部門不同的流程組合出來的（Orchestration of multiple pipelines）

MLOps跟DevOps最大的差別，就是機器學習比單純寫一個程式，來得複雜許多。不管是從營運部門的收集數據，到AI科學家使用ML framework跟超參數（hyperparameter）訓練模型，到IT人員部署模型及接收即時數據等等。這裡面的各項流程，都是在不同的環境下進行，所以都很容易會受到非人為或外在因素的影響。

就是因為多部門不同的流程，才需要有MLOps來編排配合各流程的執行，有API定義，紀律性，跟詳細的文件，才可以減低各部門的輸出的差異。舉例來說，大家都可能都有在Netflix或Spotify上被推薦到電影或歌曲，這後面其實不是單一的AI模型，Netflix或Spotify平台除了收集個人的觀看及收聽歷史外，也會根據使用者的profile、所在地的社群、最近的熱門新聞，去提高使用者點閱的可能性。根據使用者的習性，或當地區最流行的電影歌曲，甚至最近的熱門新聞，都可能是不同的預測模型。

另一個複雜的問題，就是下游的模型，可能會依賴上游的另外一個機器學習流程，這種隱藏的相關性，使MLOps的流程更為複雜。

2. 機器學習模型的治理（Model Governance）

所謂模型治理，不外乎就是要有版控跟歷史性的數據。對應一個模型，我們要把它什麼相關的數據存起來？Michelangelo 的建議，是對每一個版本的模型，收錄以下的詮釋資料（metadata）：

模型的訓練者。
訓練的開始時間與結束時間。
模型的全部配置（configuration）, 包括用了什麼特徵、超參的設置等。
引用訓練集和測試集。
描述每個特徵的重要性。
模型準確性的評價方法。
模型每個類型的標準評價表或圖表。
模型所有學習到的參數。
模型可視化摘要統計。

MLOps的模型庫（Model hub）一定要存放在有版控的資料庫裡。每一版要把上述的配置資訊，連帶訓練跟測試的日誌，一併存放起來，對整個MLOps的生命週期，跟模型的準確度，都很有幫助。

3. 持續整合/持續交付（Continuous Integration and Deployment）

機器學習除了因為外在的環境跟不同的數據，讓流水線（Pipeline）比較複雜外，MLOps與DevOps 的持續整合、持續交付精神是一致的，有興趣的讀者，可以參閱我的另一篇文章《DevOps與MLOps的比較》。

DevOps與MLOps的比較

有些人以為，啟動一個人工智慧機器學習的專案，就只是在訓練模型，但在現實 MLOps…

medium.com

4. 人工智慧模型部署（Model Deployment）

這一點也是跟 DevOps 把服務部署到營運環境很相近，但是MLOps流程要多加考量以下三點：

a. 機器學習模型雖然也是程式編譯碼，但在營運環境，它通常是會掛在一個web service，或者在一個硬體設備裝置上（e.g. NVR），所以MLOps的部署工具，通常還會產出一個呼叫模型的API，才會把模型部署出去。

b. 機器學習跟DNN訓練架構有很大的相關性。舉例來說，一個用Tensorflow 訓練的模型，MLOps必需要經過轉檔才可以部署到PyTorch的推論環境上。ONNX open format 就是因為這個需要而發展出來的。

c. 正式的營運環境上，通常會有很多個模型，而且會隨時隨地增減，所以MLOps的模型部署工具，也需要有相當的可擴展性。

5. 預測結果及數據的監控（Monitoring — Maintain ML Health）

機器學習模型是依賴歷史數據訓練出來的。但是訓練數據會有靜態跟動態兩種：動態數據會因為時間跟環境有所差異，這些現象叫數據漂移（data drift）或模型漂移（model drift）；假若我們不經常用新的數據重新訓練（retraining）模型，它的準確度就會降低。

因此，MLOps 裡重要的一環，就是要持續監控數據跟模型的準確性。大多數的ML framework 都會附帶各種歷史和可視化監控報告，如模型準確率報告，可視化決策樹，跟特徵 (神經元) 報告等。MLOps的實踐，需要包括這些監控報告的review流程。

6. MLOps 生命週期（Manage Full Life Cycle of MLOps & scaling ML Applications）

機器學習生命週期包括了數據收集、特徵工程（feature engineering）、模型定義、超參訓練（hyperparameter training）、模型部署、模型監控等步驟。MLOps最重要的概念，不單只是提供以上步驟的環境及工具，更重要的是MLOps會把這一系列的流程相關數據，全都歸檔版控。這樣在進行重新訓練（retraining）時，就可以跟歷史數據進行相關性的比較，還模型能更為精準。

Michelangelo如何實踐MLOps文化

接下來，我們試著以有名的米開朗基羅機器學習平台（Michelangelo）為例，去了解Uber如何實踐上面說的MLOps文化信念。Michelangelo 是Uber 在2016年因為內部需求而建立出來的一個機器學習平台。它實際上提供的就是一個端到端的解決方案，可以幫助 Uber 內部團隊完成挑選數據、建立模型、訓練模型、模型比較、管理，最後把最佳模型進行分析、計算和處理。Michelangelo 是一個很成熟的MLOps平台，它包含了很多子系統，這裡介紹一下其中五個相關的步驟：

1. 管理數據 Manage Data

Uber無疑地有很多的數據，但重要的是，Uber工程師發現很多模型都是用了類似或相同的特徵，而在不同組織的團隊之間、以及同個團隊裡的不同專案之間共享特徵是一件很有價值的事情。

因此Michelangelo建立了一個數據湖和一個共享特徵庫。數據湖是用來存放所有的原生數據。除此之外，米開朗基羅的數據管理組件分為在線數據跟離線數據兩種。離線數據主要用於為批次模型訓練（Batch training）以及批次預測（Batch inference）作業提供數據。這些批次任務會從數據湖產出不同的特徵，並存放到特徵庫 (使用Hive軟件)，增加推論的速度。在線數據主要為低延遲的推論提供數據，例如處理即時串流資訊，並使用 Kafka 做緩衝，以 Cassandra 作為特徵庫。

Michelangelo 的數據管理，如圖一：

2. 訓練模型 Train model

Michelangelo對模型治理這方面也有很落實的流程。上面已經介紹過Michelangelo在模型庫（存在Cassandra內，見圖二）內存的metadata，這些信息將用於配置運行在 YARN 或 Mesos 集群上的訓練作業，每次模型訓練完畢之後，Michelangelo也會將其計算得到的性能指標（例如ROC 曲線和 PR 曲線）進行組合，得到一個模型評價報告。系統會將原始配置、學習到的參數以及評價包括存回模型庫，用於分析與部署。這樣也就紀錄了這些metadata 對模型準確度的關連性，作為日後分析之用。

3. 評估模型 Evaluate model

模型評估的目的就是為了尋找一組最佳特徵、算法、超參，針對推論題目建立最佳模型的探索過程。跟DevOps類似，模型評估是一個迭代的過程，而且非常依賴AI科學家跟領域專家的實戰經驗，自動化的程度不高。但像Michelangelo這樣的MLOps平台所可提供的，就是各種詳盡的報告，可供資料科學家跟領域專家參考，並調整各種詮釋參數。

另外報告也應要帶入歷史數據跟可視化的圖表，所以Michelangelo提供了像模型準確率報告（類似Tensorboard），可視化的Decision Tree，跟各種Feature Report 等。本文是擇自2018Uber 的報告，相信至如今，Michelangelo 應該繼續加強這些圖表，讓AI科學家更有效率的調整模型訓練的參數。

4. 部署模型 Model Deployment

前面有描述到Michelangelo的訓練數據有線上跟離線兩種。在inference部份，也有線上跟離線的模型要部署（如圖三）。離線的模型，主要是做批次、靜態數據的預測，例如哪一家UberEats特約餐廳適合那一類的客戶。線上的模型，則是對動態數據的預測，如UberEats訂單大約在什麼時候送到客戶家。

Michelangelo另外一種模型是可以「執行時函式庫」的方式（runtime library）提供給Uber 的服務使用。如上面提到的，這種模型的部署，會連帶一個Restful 的API，而不是直接部署到營運環境上使用。

上述三種部署模式基本上都是自動化的。這些都是一個MLOps平台應該要提供的功能。

5. 預測監控 Monitoring

監控模型的預測情況，就是確保其在未來正常工作的重要保障。工程師需要確保數據管道傳入的是正確的數據，並且生產環境沒有發生變化，這樣模型才能夠進行準確的預測。為了解決這個問題，Michelangelo會自動記錄並將部分預測結果加入到數據 pipeline 的標籤中去，有了這些信息，就能得到持續的、即時的模型精確度指標。