Google的 MLOps

機器學習的CD(continuous delivery )與自動化pipeline

此篇出自Google的 Cloud Architecture Center的文件說明。主要是要討論運用軟體開發工程DevOps的理論(CI-continuous integration與CD-continuous delivery)並加上機器學習(以下簡稱ML)的獨有的特徵 — CT(continuous training)來組成MLOps的系統。

資料科學與ML在現今的企業中運用的越來越廣泛，並且可以解決的問題也變得趨於複雜。目前，可以讓我們有效使用的ML的資源有:

• 大型的資料集
• On-demand 且便宜的電腦運算能力
• 各種雲端平台上的ML加速器(如GPU、TPU)
• 不同ML使用領域(如 computer vision、自然語言、與AI推薦系統)

由於可以幫助企業解決的問題類型繁多，現在很多企業開始投資建立自己的資料科學與ML團隊。

這一篇文章在說明資料科學家與ML工程師如何運用DevOps原則來套用在ML系統(也就是MLOps)。MLOps 是一種 ML 工程文化和實踐，主要在統一 ML 系統開發 (Dev) 和 ML 系統操作 (Ops)。 實踐 MLOps 意味著我們在企業內提倡在 ML 系統建置的所有步驟中進行自動化和監控，包括整合(integration)、測試、發布、部署與相關的infrastructure管理。

給與相關的訓練資料，資料科學家可以在offline 的dataset上實施和訓練具有預測效能的 ML 模型。 然而，真正的挑戰不是建立 ML 模型，而是建立整合的 ML 系統並在production環境中持續運作它。 Google在這篇文章中講述了他們在建置MLOps相關的經驗，我們借鏡到在production環境中運行 ML 的系統可能存在許多的坑(陷阱-pitfalls)。

如下圖所示，在真實世界中只有一小部分 ML 系統由 ML code所組成。 其他所需要的周圍系統是龐大而複雜的。

在上圖中我們可以看到在ML code的周圍有需多的輔助系統需要存在，如configuration/automation/data collection/data verification/testing/debugging/resource management/model analysis/process and metadata management/serving infrastructure/monitoring。

為了將這些系統自動化變成MLOps，我們需要借助DevOps的原則。以下有幾個概念可以讓我們了解在建立MLOps環境時所需要考量的。它們分別是

• DevOps VS. MLOps
• 建立ML models的步驟
• ML 的成熟度層級

DevOps VS. MLOps

DevOps 是開發和維運大型軟體系統的一種流行做法。 這種做法提供了諸如縮短開發週期、提高部署速度和可靠發布等優點。 為了實現這些效益，我們通常會在軟體系統開發中引入了兩個概念：

• Continuous Integration(CI)
• Continuous Delivery(CD)

ML 系統其實也是一個軟體系統，因此類似的做法可以用在大規模建置和運作ML 系統。

然而ML系統還是與一般軟體開發有不一樣的地方，它們分別是:

• 團隊技能:
  在 ML 專案中，團隊通常包括資料科學家或 ML 工程師，他們專注於EDA(exploratory data analysis)、模型開發和資料實驗。 這些成員可能不是有經驗於建置procudtion等級服務的軟體工程師。
• 開發(Development):
  ML 的本質是experimental(實驗)。 我們在建模的過程中會嘗試不同的功能、演算法、建模技術和參數配置，以期盡快找到最適合我們要解決商業問題的方法。 而挑戰在於tracking哪些是有效，哪些是無效，並在最大限度上提高code的reusability的同時保持reproducibility。
• 測試:
  測試 ML 系統會比測試其他軟體系統更複雜。 除了典型的unit and integration test之外，我們還需要資料驗證(data validation)、經過訓練的模型品質評估(quality evaluation)和模型驗證(model validation)。
• 部署:
  在 ML 系統中，部署並不像將經過offline training的 ML 模型部署為真實可以預測服務那麼簡單。 ML 系統可能要求我們部署multi-step pipeline能夠自動的重新訓練和部署模型。 這個pipeline會增加複雜性，並需要我們自動執行資料科學家在部署之前手動完成的步驟，以訓練和驗證新模型。
• 生產環境(production):
  ML 模型的效能降低不僅是由於code寫得不好，而且是由於不斷發展的資料data profiles。 換句話說，模型會比傳統軟體系統有更多的衰減方式，我們需要考慮這種衰減。 因此，我們需要追踪資料的summary statistics並監控模型的online performance，以便在value偏離我們的模型功能預期時發送通知或rollback。

ML 和其他軟體系統在source control的CI、unit testing、integration testing以及software module或package的CD方面是相似的。 但是，在 ML 中，存在一些顯著差異：

• CI 不再只是測試和驗證code和components，還包括測試和驗證資料、資料的模式和模型本身。
• CD 不再是一個單一的software package或service，而是一個應該自動部署另一個服務（模型預測服務）的系統（一個 ML training pipeline）。
• CT 是 ML 系統獨有的新屬性，它與自動重新訓練和服務模型有關。

以下部分討論了訓練和評估 ML 模型以用作預測服務的典型步驟。

ML的資料科學步驟

在任何 ML 專案中，在我們定義business use case並建立成功標準後，將 ML 模型交付到生產環境的過程涉及以下步驟。 這些步驟可以手動完成，也可以通過自動pipeline完成它。

1 . 資料萃取(Data extraction): 我們選擇並整合來自與各種管道的資料來源

2. 資料分析(Data analysis) : 我們使用EDA來理解資料來建立ML model。這個流程會引導出以下兩件事:

• 了解模型預期的data schema和characteristic。
• 確定模型所需的data preparation和feature engineering。

3. 資料準備(data preparation): 資料是為 ML 作業而準備的。 此準備工作涉及資料清理，我們可以將資料拆分為training、validation和test 三個部分。 我們還需要將資料轉換和特徵工程應用於解決目標任務的模型。 此步驟的output是準備好的資料格式的資料分拆。

4. 模型訓練:
資料科學家使用準備好的資料實施不同的演算法來訓練各種 ML 模型。 此外，我們可以對正在跑的演算法進行超參數(hyperparameter)調整，以獲得最佳效能的 ML 模型。 此步驟的output是已經過訓練的模型。

5. 模型評估(model evaluation):
使用測試集的資料來評估模型的品質。 此步驟的output是一組用於評估模型品質的指標

6. 模型驗證(model validation):
驗證模型適合部署到生產環境 — — 它的預測性能優於某個基準(baseline)。

7. 開始服務預測:
經驗證的模型被部署到生產環境以提供預測服務。 此部署可以是以下的方式之一：

• Microservices with a REST API to serve online predictions.
• An embedded model to an edge or mobile device.
• Part of a batch prediction system.

8. 模型監控
上面這些步驟的自動化級別定義了 ML 流程的成熟度，它反映了給新資料訓練新模型或給新實行訓練新模型的速度。 以下部分描述了三個等級的 MLOps，從手動的等級開始，一直到自動化 ML 和 CI/CD pipeline。

MLOps level 0 : 手動流程

許多企業都有數據科學家和 ML 工程師團隊，他們可以建立最先進的ML模型，但他們建立和部署 ML 模型的過程完全是手動的。 這被視為成熟度的基本級別，下圖顯示了此過程的工作流程。

特徵(Characteristics)

以下說明在level 0狀況下手動流程的特徵:

• 手動、script-driven和交互過程：每一步都是手動的，包括資料分析、資料準備、模型訓練和驗證。 它需要手動執行每個步驟，並手動從一個步驟跳到下一個步驟。 這個過程通常由資料科學家在類似jupyter notebooks中編寫和執行code並且調整，直到產生一個可行的模型。
• ML 和維運之間脫節：該過程將建立模型的資料科學家和為模型提供預測服務的工程師分開。 資料科學家將經過訓練的模型交給維運團隊，以部署在他們的 API 基礎設施上。 這種交接可以包括將經過訓練的模型放在存儲位置、將模型對象檢查到code repository中。 然後，部署模型的工程師需要在生產環境中提供所需的功能以實現低延遲服務，這可能會導致training-serving skew。
• 次數少的release iterations：該過程假設我們的資料科學團隊管理著一些不經常更改的模型 — — 要嘛更改model implementation，要嘛使用新資料重新訓練模型。新模型版本一年可能只部署幾次。
• 無 CI：因為假設implementation很少更動，所以會忽略 CI。通常，測試code是notebooks 或script執行的一部分。implement實驗步驟的script和notebook都是source controlled，它們產生諸如訓練模型、評估指標和可視化等artifacts。
• 無 CD：因為沒有頻繁的模型版本部署，所以不考慮 CD。
• 部署指的是預測服務：該過程只關心將訓練好的模型部署為預測服務（例如，帶有 REST API 的微服務），而不是部署整個 ML 系統。
• 缺乏主動性能監控：該過程不追踪或記錄模型預測和操作，這是檢測模型效能下降和其他模型behavioral drifts所必需的。

維運團隊可能有自己複雜的 API configuration、testing和deployment，包括security、regression以及負載和canary testing。 此外，新版本 ML 模型的生產環境部署通常要經過 A/B testing或online experiments，然後才能將模型提升到為所有prediction request流量提供服務。

挑戰

MLOps 0 等級在許多開始將 ML 應用自家環境的企業很常見。 當模型很少更改或訓練時，這種由資料科學家負責的手動過程可能就足夠了。 在實踐中，模型在現實世界中部署時經常會掛掉。 因為模型無法適應環境動態的變化，或實際環境的資料的變化。

為了應對這些挑戰並在生產環境中保持模型的準確性，我們需要執行以下的工作：

• 主動監控生產環境中模型的品質：監控模型可讓我們檢測效能下降和模型是否變舊。 它幫助我們再新的experimentation iteration和手動在新資料上重新訓練模型的提醒。
• 經常重新訓練我們的production模型：為了捕捉不斷變動和新型態的模式，我們需要使用最新資料重新訓練我們的模型。 例如，如果我們使用 ML 推薦時尚產品，則這個推薦應適應最新的產品趨勢。
• 不斷嘗試新的implementation來生成模型：為了利用最新的想法和新技術，我們需要嘗試新的implementation，例如feature engineer、model architecture和hyperparameters。 例如，如果在人臉辨識中使用computer vision，人臉模式是固定的，但更好的新技術可以提高辨識準確率。

為了解決手動流程帶來的挑戰，CI/CD 和 CT 的 MLOps practices是可以幫助我們自動化這些流程。 通過部署 ML training pipeline，我們可以啟用 CT，並且可以設置 CI/CD 系統來快速測試、建置和部署 ML pipeline的new implementation。

MLOps level 1: ML pipeline自動化

Level 1 的目標是通過自動化 ML pipeline來執行模型的CT； 這讓我們可以實現模型預測服務的CD。 要自動化使用新資料在Production中重新訓練模型的流程，您需要向管道引入自動化數據和模型驗證步驟，以及pipeline triggers和metadata管理。 下圖是用於 CT 的自動化 ML pipeline的示意圖。

特徵(Characteristics)

以下說明在level 1狀況下的特徵:

• Rapid experiment：ML experiment的步驟是orchestrated。 步驟之間的轉換是自動化的，這導致experiment的快速iteration和更好地準備將整個pipeline移動到production。
• production中模型的 CT：使用基於live pipeline triggers的最新資料在production中自動訓練模型。
• Experimental-operational symmetry：在開發或測試環境中使用的pipeline implementation用於preproduction和production環境，這是統一 DevOps 的 MLOps practices的一個關鍵。
• Modularized code for components and pipelines：要建立 ML pipeline，components需要是reusable、composable，並且可能跨 ML pipeline來共享。 因此，雖然 EDA code仍然可以存在於 notebook 中，但component的source code必須modularized。 此外，理想情況下，component應該被容器化以執行以下操作：
  1. decouple執行環境與custom code runtime。
  2. 使code可在開發和生產環境之間reproducible。
  3. isolate pipeline中的每個component。 component可以有自己的runtime environemnt版本，並有不同的語言和libraries。
• 模型的CD：production中的 ML pipeline持續向在新資料上訓練的新模型來提供服務。 模型部署步驟是自動化的，它將經過訓練和驗證的模型作為在online services。
• pipeline 部署：在第level 0，我們將經過訓練的模型作為服務部署到production中。 對於level 1，我們部署一個完整的training pipeline，該pipeline會自動和循環運行以將訓練好的模型提供成service。

附加的component

這一邊我們會提到需要添加到架構中以啟用 ML CT的component。

資料與模型的驗證
當我們將 ML pipeline部署到production時，ML pipeline triggers部分中討論的一個或多個trigger會自動執行pipeline。 pipeline會期待有新的即時資料來產生新的模型版本，該版本在資料上進行訓練（如上圖所示）。 因此，production pipeline中需要自動化執行資料驗證和模型驗證的步驟，以確保以下我們所希望有的行為：

• 資料驗證：在模型訓練之前需要此步驟來決定是否應該重新訓練模型或停止pipeline的執行。 如果pipeline識別出以下內容，則會自動做出此決定。
  * Data schema skews：這些skews被視為input data中的異常，這意味著downstream pipeline steps（包括資料處理和模型訓練）接收到不符合預期模式的資料。 在這種情況下，我們應該停止pipeline，以便資料科學家團隊進行調查。 團隊可能會發布對pipeline的修復或更新，以處理架構中的這些changes。 Schema skews包括接收意外features、未接收所有預期的feature或接收具有unexpected values的feature。
  * Data values skews : 這些skew是資料統計屬性的重大變化，這意味著資料模式正在發生變化，我們需要觸發模型的retraining來擷取這些變化。
• 模型驗證：在給於新資料成功訓練模型後，就要執行此步驟。 在將模型部署到生產環境之前，我們需要對其進行評估和驗證。 這個offline模型驗證步驟包括以下內容。
  * 使用經過訓練的模型在測試資料集上產生評metric values，以評估模型預測的品質。
  * 將新的訓練模型產生的評估metric values與當前模型（例如，production model、baseline model或其他業務需求model）進行比較。 在將其上線道生產環境之前，我們要確保新的模型產生比當前模型有更好的效能。
  * 確保模型的效能在資料的各個部分(segments)上是一致的。 例如，與之前的模型相比，我們新訓練的客戶流失模型可能會產生總體上更好的預測準確度，但每個客戶區域的準確度值可能存在較大差異。
  * 確保我們測試模型以進行部署，包括基礎架構相容性和與預測服務 API 的一致性。

除了offline模型驗證之外，新部署的模型在上線到production之前，還要在canary deployment或 A/B testing設置中進行online model validation。

Feature store

用於 Level 1 ML pipeline自動化的可選的附加compoent是feature store。 feature store是一個集中式repository，我們可以在其中標準化用於training和serving的feature的定義、存儲和access。 feature store需要為feature values的high-throughput batch serving和low-latency real-time serving提供 API，並支援training和serving工作負載。

Feature store幫助資料科學家執行以下操作：

• Discover並reuse其entities的available feature sets，而不是重新create相同或相似的feature sets。
• 通過維護features及其相關metadata，避免使用具有不同定義的相似features。
• 提供來自feature store的最新的feature values。
• 通過使用feature store作為experimentation、CT和在online serving的data source，避免訓training-serving skew。 這種方法確保用於訓練的feature與serving期間使用的feature相同：
  *在experimentation中，資料科學家可以從feature store中拿到一個offline extract來進行他們的實驗。
  *對於CT，自動化 ML training pipeline可以獲取用於訓練任務的資料集的一批最新feature values。
  *對於online prediction，prediction service可以批量獲取與request entity相關的feature value，例如客戶人口統計特徵、產品特徵和當前session aggregation features。

Metadata管理

記錄有關 ML pipeline每次執行的資訊，以協助處理資料和artifacts、可重現性和比較。 它還可以幫助我們debug errors和異常。 每次執行pipeline時，ML metadata 存儲都會記錄以下metadata：

• 執行的pipeline和component的版本。
• 開始和結束日期、時間以及pipeline完成每個步驟所用的時間。
• pipeline的執行者。
• 傳遞給pipeline的parameter arguments。
• Pipeline每個步驟產生的artifacts的pointers，例如prepared data的位置、驗證異常、計算統計數據以及從categorical feature中提取的詞彙。如果pipeline因步驟失敗而停止，追踪這些intermediate outputs可幫助我們從最近的步驟 resume pipeline，而無需重新執行已經完成的步驟。
• 如果我們需要rollback到之前的模型版本，或者在模型驗證步驟中為pipeline提供新的測試資料時需要為之前的模型版本產生evaluation metrics，則指向以前訓練過的模型的pointer。
• 在模型評估步驟中為訓練集和測試集產生的模型evaluation metrics。這些metrics可幫助我們在模型驗證步驟中將新訓練模型的效能與先前模型的效能紀錄進行比較。

ML pipeline triggers

我們可以自動化 ML production pipeline ，以使用新資料重新訓練模型，具體取決於我們的use case：

• On demand：pipeline的臨時手動執行。
• On a schedule：每天、每週或每月為 ML system 系統性的提供新的labelled data。 重新訓練的頻率取決於我們的資料模式變化的頻率以及重新訓練模型的成本。
• 關於新訓練資料的可用性：新資料不是系統性的用於 ML system，而是在當新資料被收集並且放在source DB中，這時在一個ad-hoc basis中新資料才算available。
• 關於模型效能下降：當出現明顯的效能下降時，重新訓練模型。
• 關於資料分佈的重大變化（concept drift）。 很難評估online model的完整效能，但我們會注意到用於執行預測的feature的資料分佈發生了重大變化。 這些變化表明我們的模型已經過時，需要在新資料上重新訓練。

挑戰

假設不經常部署pipeline的new implementations並且我們只管理少數的pipeline，我們通常手動測試pipeline及component。 此外，我們手動部署新的pipeline implementation。 我們還可以將經過測試的pipeline source code交給 IT 團隊以部署到生產環境。 當我們基於新資料而不是基於新的 ML ideas部署新模型時，這種方法是適用的。

然而，我們需要嘗試新的 ML ideas並快速部署 ML component的new implementation。 如果我們在生產環境中管理許多 ML pipeline，則需要一個 CI/CD 設置來自動建置、測試和部署 ML pipeline。

MLOps level 2 : 自動化的CI/CD pipeline

為了快速可靠地update production的pipeline，我們需要一個強大的自動化 CI/CD 系統。 這個自動化的 CI/CD 系統讓我們的資料科學家能夠快速探索在圍繞著feature engineering、model architecture和hyperparameters的一些新想法。 他們可以實現這些想法並自動建置、測試並將新的pipeline component部署到生產環境。

下圖顯示了使用 CI/CD 實現的 ML pipeline，它具有自動化 ML pipeline setup以及自動化 CI/CD routines的特徵。

上圖的ML pipeline 的CI/CD 包含了以下component:

• Source control
• Test and build services
• Deployment services
• Model registry
• Feature store
• ML metadata store
• ML pipeline orchestrator

特徵(Characteristics)

下圖顯示自動化的ML CI/CD pipeline的各階段

每一階段的說明如下:

1. Development and experimentation：我們會在此階段反覆嘗試新的 ML 算演法和新的建模，其中的experimentation steps是orchestrated。此階段的output是 ML pipeline步驟的source code，然後放到source repository。
2. Pipeline CI : build source code 並運行各種測試。 此階段的output是將在稍後階段部署的pipeline component（packages、可executables和artifacts）。
3. Pipeline CD: 我們將 CI 階段產生的artifacts部署到目標環境。 此階段的outputs是一個已部署的pipeline，其中包含模型的new implementation。
4. Automated triggering: pipeline在production中根據schedule或回應trigger自動執行。 此階段的output是一個經過訓練的模型，該模型被推送到model registry。
5. Model CD: 我們將經過訓練的模型正式上線服務。 此階段的output是已部署的正式ML服務。
6. Monitor : 我們根據live data收集有關模型效能的統計資訊。 此階段的output是執行pipeline或執行新的new experiment cycle。

在pipeline開始新的experiment之前，資料分析步驟仍然是資料科學家的手動過程。 模型分析步驟也是一個手動過程。

CI(Continuous integration)

在CI中，當新的code commit或push到source code repo時，將build、test和package pipeline及其component。 除了build package、container image和executables之外，CI 過程還可以包括以下測試：

• Unit testing我們的feature engineering logic。
• 對模型中使用不同方法進行unit testing。 例如，我們有一個接受categorical data column的函數，並將該函數編碼為one-hot feature。
• 測試我們的模型訓練是否收斂（也就是說，我們的模型的損失會因interations而下降並overfit一些樣本記錄）。
• 測試我們的模型訓練不會因除以零或操縱 small or large values而產生 NaN values。
• 測試pipeline中的每個component是否產生預期的artifacts。
• 測試pipeline components之間的integration。

CD(continuous delivery)

在CD中，我們的系統不斷向生產環境提供新的pipeline implementations。 為了快速可靠地持續交付pipeline和模型，我們應該考慮以下幾點：

• 在部署模型之前驗證模型與生產環境的基礎架構相容性。例如，我們需要驗證模型所需的package是否安裝在生產環境中，以及可用的memory、compute和accelerator資源。
• 通過使用預期的input 來呼叫 API 測試ML，並確保獲得預期的反應。此測試通常會抓到我們在update model version時可能出現的問題，並且這需要不同的input來測試。
• 測試ML效能，這涉及對ML服務進行負載測試以擷取query per seconds(QPS) 和模型延遲等指標。
• 驗證資料以進行retraining或batch prediction。
• 在部署之前驗證模型是否滿足我們想要的ML效能。
• 自動部署到測試環境，例如通過將code push到development branch觸發部署。
• 半自動化部署到pre-production環境，例如，在審核者批准更改後通過將code合併到main branch而觸發的部署。
• 在pre-production環境中多次成功運行pipeline後，手動部署到production環境。

總而言之，在production環境中實施 ML 不僅意味著將我們的模型部署是用於預測的 API。 相反，它意味著部署一個可以自動重新訓練和部署新模型的 ML pipeline。 設置 CI/CD system使我們能夠自動測試和部署新的pipeline implementations。 該系統可讓我們應對資料和業務環境的快速變化。 我們可以逐步實施這些practices，以幫助提高 ML 系統開發和生產的自動化程度。

PS:
大數據的出現讓我們比以往任何時候都能夠歸檔我們的過去、量化我們的現在、預測我們的未來。因此人類是自己歷史的數據探索家，以智慧方式在歷史的盡頭規劃自己的人生。