MLOps 入門與實踐(1): 你以為的一帆風順，我看到的一波三折

簡介

Machine Learning 已悄然成為各行各業不可或缺的技術，然而要續練一個模型並上線提供服務需要經過許多複雜的流程，這往往會花費不少的時間與精力。更糟的是，模型上線後很難如想像般一帆風順，極有可能因外在變化使 得模型不再精準如初。面對開發新專案與維護現有模型的綜合壓力，資料科學家們渴望擁有一套自動化流程來加速開發並減少維運成本，Machine Learning + DevOps = MLOps 的概念便應運而生。本文將帶領各位藉由 Machine Learning 專案的實際開發流程，來窺探資料科學家們在資料準備、模型建置、線上監控等階段所遇到的種種困境，並且在後續的文章中，將會陸續介紹如何透過 Feature Store, Model Lifecycle Management, Online Monitoring 等概念來將 MLOps 文化融入專案開發流程，讓資料科學家們可以在確保服務品質的前提下高效且無後顧之憂地開發。

資料準備

由於公司內部的資料庫並不是為了 Machine Learning而設計的，裡面所存的資料也無法直接拿來訓練模型，因此在資料準備階段，需要從資料庫裡提取資料並做 Feature Engineering。首先會面臨到的問題將會是 Feature 的版本控管，由於公司本身的資料庫很有可能只保存會員當下的狀態，並沒有記錄下這個狀態的變化，因此當資料科學家們需要這個會員的歷史狀態來做為 training data 時就無從取得。

其次，相信資料科學家們都很清楚，Feature Engineering 很有可能是一個 Machine Learning Project 中最繁瑣、最耗工時的步驟，因此也是極容易犯錯的步驟，而 Machine Learning 又是一個相當仰賴資料的學問，如何確保算出來的 feature 是可靠的也就至關重要。

並且當科學家們在公司內部互相討論切磋的過程中可能會發現，英雄所見略同，不同專案有使用了相同的 feature，或者是自己想到了一個可以鋪天蓋地的好 feature 想分享給別的專案使用，卻因為各個專案是互相獨立的而難以實現。

模型建置

由於資料的分佈會隨時間不斷的變化，模型也需要定期重新訓練來維持準確度，然而我們並沒有辦法保證每一次重新訓練的模型都能達到預期的標準，並且表現得比線上的穩定版本好，這就有可能導致自動化訓練並部署上線的模型產出不適當的預測結果而降低系統的服務品質，因此模型部署上線前的模型驗證就變得很重要。

模型驗證無非是由每次實驗的數據來做檢驗，實驗數據的保存與呈現卻經常被大家忽略，因此無論是人工或是自動化的模型驗證，實驗數據是否容易取得都是很重要的一環。

當模型通過驗證部署上線後，如果有突發狀況發生，例如：疫情導致資料量瞬間降低，就有可能導致模型即使通過驗證，預測的結果卻是無法捉摸，這時候可以做的事情就是先將模型退版，回復到過去正常狀態。然而如果模型的歷史版本沒有被保存下來，所有的流程就得從頭來過，就需要花費很多時間重新訓練，這會讓模型退版變得很不容易。

線上監控

即便我們在前期的資料準備、模型訓練都做了一定的機制去確保他們的可靠性，但是模型被部署上線提供服務後，還是有可能因為現實世界的環境改變(ex: 疫情使旅遊習慣從跨國轉變為國內旅遊)而產生 Concept Drift, Data Drift，甚至是某些突發狀況導致模型準確度下滑。在軟體工程中我們會監控線上 API 服務的 CPU, RAM 使用量，而在 Machine Learning 的服務，我們還要額外監控的就是模型的表現，一旦發現表現下滑超過一定的 threshold 之後，便可以啟動對應的機制嘗試重新訓練模型來自動化解決問題，或是通知負責的人介入處理。

結語

在 Machine Learning 的世界裡並不是單純的準備資料、開發模型這麼簡單，這當中還隱藏著開發、維運的種種困境。在資料準備方面，我們遇到了特徵品質、特徵共享以及特徵版控的問題；在模型建置方面，我們缺乏上線前的模型驗證、實驗數據的保存以及模型的版本控管，除此之外線上監控也是許多人容易忽略的一環。在後續的文章中，我們將一一介紹如何透過 Feature Store, Model Lifecycle Management, Online Monitoring 等概念來將 MLOps 文化融入專案開發流程，來提升 Machine Learning Project 的服務品質以及降低開發、維運的成本。

CREDITS: The icons in this article are created by Flaticon.