DevOps與MLOps的比較

內容

• 前言
• MLOps 的生命週期
  - 原始數據匯集 (Raw Data Aggregation)
  - 數據前處理 (Data Preprocessing)
  - 模型訓練 (AI Model training）
  - 模型驗證 (Model validation)
  - 模型最佳化 （Model Optimization )
  - 推論 (Inference)
  - 重新訓練模型 （Retraining）
• MLOps與 DevOps的差異性
• 總結

前言

於 Jonathan Chen 的《在混合雲裡實踐MLOps》一文中，描述了工程師可以從單一地端瀏覽器介面，在多座私有雲跟公有雲上，快速部署出開發、測試、以及正式營運的容器環境。証明了機器學習可以利用混合雲環境，達到最佳的效果。

在混合多雲裡實踐MLOps

有些人以為，啟動一個人工智慧機器學習的專案，就只有三個步驟：

1. 指定一個深度學習的架構 (如 TensorFlow, PyTorch, Caffe, …)
2. 使用者開啟 IDE (如 Jupiter)，編譯 python 程式及訓練參數，讀入資料，訓練 model
3. 重覆步驟2，直到 model 準確度滿意為止，然後把 model 送出做推論(inference)

在現實 MLOps 世界中，其實只有一小部分的人工智慧訓練系統是深度學習的程式，但周圍所需要的基礎設施是龐大而複雜的。這包括了硬軟體的安裝、資源分配、如何使用開源工具、模型的部署等等。結果是資料科學家的時間大半花在基礎架構上，如下圖所示：

Source: GTC 2020

MLOps 的生命週期

MLOps 不只是深度學習與產出模型的流程而已，它其實跟 DevOps 的流程很相近。MLOps 需要環境的部署，一方面與各部門緊密交接，收集來自各個部門的數據集，另一方面產出模型，將模型部署到營運環境上，並持續地更新。同樣的，MLOps 也是一個循環性的生命週期流程，如下圖：

MLOps 生命週期

原始數據匯集 (Raw Data Aggregation)

AI 機器學習最重要的元素當然就是數據。任何一個產業 AI 化都需要它自家的運營數據。所以產業AI化，機器學習的第一步，就是建立一個數據匯集流程，擁有清晰的、連續的、高質量的數據流。

數據前處理 (Data Preprocessing)

原始數據不等於訓練數據。原始數據通常太龐大，包含太多相關的特徵 (feature)，而且可能會包括一些有雜質的數據。此外，不同的深度學習框架 需要不同的數據格式，因此，原始數據通常都要經過前處理，才可以用來做訓練。例如，常見的數字辦識模型 MNist，就需要轉成 Numpy 需要的格式才開始訓練。

模型訓練 (AI Model training）

所謂人工智慧模型，其實就是一個經過程式運算重覆調整後的數學函數，可以根據既有數據，預測未來結果。

因為模型是一個數學函數，所以必須要有 Input 跟 Output。Input 就是可以用來預測 output 的特性 （feature）。特性在 DNN 理論中的學術名稱叫做神經元 (neurons)，例如做人臉辦識，神經元就可以包括眼耳口鼻等等。

人工智慧的開發人員要做的，就是在他選擇的 DNN 框架上，定義模型的神經元，以及做模型訓練需要的訓練參數。最常見的 DNN 框架，包括 TensorFlow、PyTorch、Caffe、MXNet、Chainer 等等。訓練參數可以包含任何在訓練過程中可以調整的東西，但目前最常被資料科學家調整的參數包括 batch size、epoch、learning rate 等等。

模型驗證 (Model validation)

類似於軟體工程裡，Integration Test 和 Regression Test 的概念，新的模型訓練出來後，一定要經過驗証，才可以用到實時數據上。

通常在數據前處理之時，資料科學家都會把訓練數據分成 Test Data、Training Data 跟 Validation Data。Validation Data 不會用來做訓練，而是在模型訓練出來之後，用來驗證模型的。

模型最佳化 （Model Optimization )

上面提到的 Test Data 是用來做最初定義模型需要的神經元和比重 (Bias & Weight)，但真正的深度學習過程是要經過很多層 (multi-layer) 的反向傳播 （backpropagation）調整出來 的。

模型最佳化通常是指使用不同的訓練資料 Batch size、epoch、跟 learning rate 去精進模型的準確度跟失真率，因為要同時對多個神經元進行運算，所以模型最佳化是最需要用到 GPU 的 MLOps 流程的一部份。

另外值得一提的是，近年來自動機器學習(AutoML)漸漸流行，而AutoML就是一個應用，試著去把 Hyperparameter 自動產生出來，讓早期導入階段的公司可以更快速地參數優化。

推論 (Inference)

模型訓練好後，當然就是上線，去更新在營運環境上的舊模型，就像 DevOps 一樣，這裡也有一些最佳實務 (best practise)：

• 模型版控，存到 Git 之類的版本控制系統上，如此一來，萬一新的模型有問題，IT 還是 可以 rollback 到舊的模型。
• 因為模型位在營運環境上，部署新的模型不能讓營運環境中斷。所以模型的更新，也是用類似藍綠部署的型式，把不同的 web service，循序的指向新的 model，才可以把舊的 model 移除。

重新訓練模型 （Retraining）

最後，跟 DevOps 一樣的概念，整個 MLOps 的模型訓練，其實是一個週而復始的循環，只不過在 MLOps 的流程，資料科學家需要持續監視模型的準確率，決定是否重新訓練；不單止是要改 DNN 框架的 API 呼叫程序，更要把新收進來 的實時數據，再做前數據處理，決定加入到 test data、training data 或 validation data 內。

MLOps與DevOps的差異性

DevOps 生命週期

從生命週期角度來看，MLOps 跟 DevOps 其實很接近，但是 MLOps 跟 DevOps 最大的差別，就是 data 跟環境的變數。傳統的 DevOps，每次服務 (軟體應用) 更新，絕大部份都是 fix bugs 或是新的功能，對於整合測試或是回歸測試來說，使用的環境或是 test data，都是不會改變的。

但是對於 MLOps 來說，model 的更新通常是表示原來運營中的 model，準確率有降低，但是這種情形卻不一定跟演算法或新的功能有任何關係。重新訓練一個模型，是表示已累積了一些新的 training data，這可能會導致原先模型的神經元(特徵)或比重 (weight & Bias for the neurons) 需要調整。另一方面，營運環境的改變，也很可能導致模型需要重新訓練。舉例來說，一個在白天非常準確的車牌辦識模型，在陰天或外物阻擋自然光源時，很可能就需要重新訓練。

這個過程就要比傳統的 DevOps 生命週期要複雜多了。軟體工程中，有個「技術債」(technical debt)，以後有機會再解釋，在傳統的軟體開發，技術債通常都是人為因素，但對 MLOps 而言，技術債不一定是人為因素，無法控制的訓練數據雜質、外界環境改變，都會增加技術債。所以 MLOps 流程 就需要更頻繁的監控、更有原則的變更，才可以保證營運環境的品質。

總結

DevOps 與 MLOps 的精神非常相近，都是提供一個企業內不同的部門共同工作的協同開發環境與流程。MLOps 計畫人員包括數據科學家、軟體開發人員、人工智慧科學家、IT/MIS 等等。所以，很多在 DevOps 上的最佳實踐原則，都可以引入 MLOps 中；但是因為人工智慧模型容易受到實時數據（Live data）和環境的影響，它的技術債 (Technical debt) 很容易累積，所以一套能用來管理 MLOps 流程與基礎架構的工具，就能發揮更大的功效。

未來有機會，我們將會討論一下 MLOps 流程的管理。

References

1. https://en.wikipedia.org/wiki/Deep_learning
2. https://machinelearningmastery.com/difference-between-a-batch-and-an-epoch/
3. https://machinelearningmastery.com/learning-rate-for-deep-learning-neural-networks/
4. https://en.wikipedia.org/wiki/Stochastic_gradient_descent
5. https://en.wikipedia.org/wiki/AlphaGo
6. https://www.semanticscholar.org/paper/Hidden-Technical-Debt-in-Machine-Learning-Systems-Sculley-Holt/1eb131a34fbb508a9dd8b646950c65901d6f1a5b
7. https://medium.com/inside-machine-learning/ai-ops-managing-the-end-to-end-lifecycle-of-ai-3606a59591b0
8. https://towardsdatascience.com/intro-to-mlops-ml-technical-debt-9d3d6107cd95
9. https://towardsdatascience.com/avoiding-technical-debt-with-ml-pipelines-3e5b6e0c1c93