本文將探討如何實作及自動化處理機器學習系統的持續整合 (CI)、持續推送軟體更新 (CD) 和持續訓練 (CT) 作業。本文主要適用於預測型 AI 系統。
資料科學和機器學習正成為解決複雜現實問題、轉型產業，以及在所有領域創造價值的核心能力。目前，您可使用以下有效機器學習的應用程式：
- 大型資料集
- 經濟實惠的隨選運算資源
- 各種雲端平台上的機器學習專用加速器
- 機器學習研究領域快速發展，例如電腦視覺、自然語言理解、生成式 AI 和推薦 AI 系統。
因此，許多企業紛紛投資數據資料團隊和機器學習功能，開發可為使用者帶來業務價值的預測模型。
本文適用於想將 DevOps 原則套用至機器學習系統 (MLOps) 的資料科學家和機器學習工程師。機器學習運作是一種機器學習工程文化和實務，旨在統一機器學習系統開發 (Dev) 和機器學習系統運作 (Ops)。導入機器學習運作代表您提倡在建構機器學習系統的各個步驟中，自動執行及監控作業，包括整合、測試、發布、部署和基礎架構管理。
資料科學家可根據相關訓練資料，在離線保留資料集上導入及訓練機器學習模型，以預測其用途的成效。不過，真正的挑戰並非建構機器學習模型，而是建構整合式機器學習系統，並在正式環境中持續運作。Google 擁有悠久的機器學習服務生產歷史，我們發現在實際工作環境中運作以機器學習為基礎的系統時，可能會遇到許多陷阱。如需部分陷阱的摘要說明，請參閱「機器學習：技術債務的高利息信用卡」。
如下圖所示，真實世界中的 ML 系統只有一小部分是由 ML 程式碼組成。周圍的必要元素數量龐大且複雜。
圖 1. 機器學習系統的元素。改編自「機器學習系統中的隱藏技術債」。
上圖顯示下列系統元件：
- 設定
- 自動化
- 資料收集
- 資料驗證
- 測試與偵錯
- 資源管理
- 模型分析
- 程序和中繼資料管理
- 服務基礎架構
- 監控
如要開發及運作這類複雜系統，您可以將 DevOps 原則套用至機器學習系統 (MLOps)。本文涵蓋為資料科學實務做法設定機器學習運作環境時應考量的概念，例如機器學習中的 CI、CD 和 CT。
本文將討論下列主題：
- 開發運作與機器學習運作
- 開發機器學習模型的步驟
- MLOps 成熟度
- 生成式 AI 適用的機器學習運作平台
開發運作與機器學習運作
DevOps是開發及運作大規模軟體系統的熱門做法。這項做法可縮短開發週期、提升部署速度，並確保發布內容的可靠性。如要享有這些優點，您可以在軟體系統開發中導入兩個概念：
機器學習系統是軟體系統，因此適用類似的做法，確保您能大規模建構及運作機器學習系統。
不過，機器學習系統與其他軟體系統的差異如下：
團隊技能：在機器學習專案中，團隊通常會包含資料科學家或機器學習研究人員，他們專注於探索性資料分析、模型開發和實驗。這些成員可能不是經驗豐富的軟體工程師，無法建構實際執行環境等級的服務。
開發：機器學習本質上屬於實驗性質。您應嘗試不同的特徵、演算法、建模技術和參數設定，盡快找出最適合解決問題的方法。這項作業的挑戰在於追蹤哪些做法有效，哪些無效，並在盡量提高程式碼重複使用率的同時，維持可重現性。
測試：測試機器學習系統比測試其他軟體系統更複雜。除了典型的單元和整合測試外，您還需要進行資料驗證、訓練模型品質評估和模型驗證。
部署：在機器學習系統中，部署作業並非只是將離線訓練的機器學習模型部署為預測服務。機器學習系統可能需要您部署多步驟管線，自動重新訓練及部署模型。這個管道會增加複雜度，且需要自動執行資料科學家在部署前手動執行的步驟，才能訓練及驗證新模型。
正式環境：機器學習模型效能降低的原因不只是程式碼不夠理想，不斷演變的資料設定檔也是原因之一。換句話說，模型衰退的方式比傳統軟體系統更多，因此您必須考量這種衰退情形。因此，您需要追蹤資料的摘要統計資料，並監控模型的線上成效，以便在值偏離預期時傳送通知或還原。
機器學習和其他軟體系統類似，都會持續整合來源控制、單元測試、整合測試，以及持續交付軟體模組或套件。不過，在 ML 中，有幾個顯著差異：
- 持續整合不再只是測試及驗證程式碼和元件，還包括測試及驗證資料、資料結構定義和模型。
- 持續交付不再只是單一軟體套件或服務，而是系統 (機器學習訓練管道)，應自動部署另一項服務 (模型預測服務)。
- CT 是機器學習系統特有的新屬性，與自動重新訓練及提供模型有關。
下一節將討論訓練及評估 ML 模型的典型步驟，以做為預測服務。
機器學習的資料科學步驟
在任何機器學習專案中，定義業務用途並建立成功條件後，將機器學習模型交付到實際工作環境的過程會包含下列步驟。這些步驟可以手動完成，也可以透過自動管道完成。
- 資料擷取：從各種資料來源選取並整合相關資料，用於機器學習工作。
- 資料分析：您會執行探索性資料分析 (EDA)，瞭解可用的資料，以便建構機器學習模型。這個程序會產生下列結果：
- 瞭解模型預期的資料結構定義和特徵。
- 找出模型所需的資料準備和特徵工程。
- 資料準備：準備用於機器學習工作的資料。準備工作包括資料清理，也就是將資料分成訓練、驗證和測試集。您也會將資料轉換和特徵工程套用至解決目標工作用的模型。這個步驟的輸出內容是已準備格式的資料分割。
- 模型訓練：資料科學家會使用準備好的資料，透過不同演算法訓練各種機器學習模型。此外，您還可對實作的演算法進行超參數調整，以取得效能最佳的機器學習模型。這個步驟會輸出經過訓練的模型。
- 模型評估：我們會使用保留測試集評估模型，這個步驟的輸出內容是一組指標，用於評估模型品質。
- 模型驗證：確認模型適合部署，且預測成效優於特定基準。
- 提供模型：將經過驗證的模型部署至目標環境，以提供預測結果。這個部署作業可以是下列其中一項：
- 具有 REST API 的微服務，可提供線上預測。
- 嵌入式模型，可嵌入邊緣或行動裝置。
- 批次預測系統的一部分。
- 模型監控：監控模型預測效能，以便在機器學習程序中可能叫用新的疊代。
這些步驟的自動化程度決定了機器學習流程的成熟度，反映出在有新資料或新實作項目時，訓練新模型的速度。以下各節將說明三種 MLOps 級別，從最常見的級別 (不涉及自動化) 開始，一直到自動化機器學習和 CI/CD 管道。
機器學習運作第 0 級：手動程序
許多團隊都有數據資料學家和機器學習研究人員，可以建構最先進的模型，但他們建構及部署機器學習模型的程序完全是手動。這屬於基本成熟度等級，也就是第 0 級。下圖顯示這個程序的流程。
圖 2. 手動執行機器學習步驟，將模型做為預測服務。
特性
如圖 2 所示，MLOps 第 0 級程序的特徵如下：
手動、指令碼驅動和互動式程序：每個步驟都是手動進行，包括資料分析、資料準備、模型訓練和驗證。您必須手動執行每個步驟，並手動從一個步驟轉移到下一個步驟。這個程序通常是由資料科學家在筆記本中以互動方式編寫及執行的實驗程式碼驅動，直到產生可用的模型為止。
機器學習與作業之間缺乏連結：這個程序會將建立模型的資料科學家，以及提供模型做為預測服務的工程師分開。資料科學家會將訓練好的模型做為構件，交給工程團隊部署到 API 基礎架構。交接方式包括將訓練好的模型放入儲存位置、將模型物件簽入程式碼存放區，或是上傳至模型登錄。接著，部署模型的工程師必須在實際工作環境中提供所需特徵，以實現低延遲服務，這可能會導致訓練/服務偏差。
發布疊代次數較少：這個程序假設資料科學團隊管理幾個不會經常變更的模型，無論是變更模型實作方式，還是使用新資料重新訓練模型，每年只會部署幾次新版模型。
無 CI：假設實作變更很少，因此忽略 CI。通常，測試程式碼是筆記本或指令碼執行作業的一部分。實作實驗步驟的指令碼和筆記本會受到來源控管，並產生訓練模型、評估指標和視覺化效果等構件。
沒有 CD：由於模型版本部署不頻繁，因此不考慮 CD。
部署是指預測服務：這個程序只會將訓練好的模型部署為預測服務 (例如具有 REST API 的微服務)，而不是部署整個 ML 系統。
缺乏主動式成效監控：這個程序不會追蹤或記錄模型預測和動作，而這是偵測模型成效降低和其他模型行為偏移的必要條件。
工程團隊可能會有自己的複雜設定，用於 API 設定、測試和部署，包括安全性、迴歸、負載和 Canary 測試。此外，部署新版機器學習模型時，通常會先進行 A/B 測試或線上實驗，再將模型升級，處理所有預測要求流量。
挑戰
許多企業剛開始將機器學習應用於用途時，通常會採用 MLOps 0 級。如果模型很少變更或訓練，這種由資料科學家主導的手動程序可能就足夠。實際上，模型部署到現實世界時，經常會發生故障。模型無法適應環境動態變化，或描述環境的資料發生變化。詳情請參閱「Why Machine Learning Models Crash and Burn in Production」。
為因應這些挑戰，並在實際工作環境中維持模型準確度，您需要採取下列行動：
主動監控正式環境中的模型品質：監控功能可協助您偵測效能降低和模型過時的情況。這項指標可做為新實驗疊代的提示，並 (手動) 使用新資料重新訓練模型。
經常重新訓練正式模型：如要掌握不斷演變和出現的模式，您需要使用最新資料重新訓練模型。舉例來說，如果應用程式使用機器學習技術推薦時尚產品，建議應根據最新趨勢和產品調整推薦內容。
持續嘗試新的實作方式，以產生模型： 如要運用最新的概念和技術進展，您需要嘗試新的實作方式，例如特徵工程、模型架構和超參數。舉例來說，如果您在臉部偵測中使用電腦視覺技術，臉部模式是固定的，但採用更優質的新技術可以提高偵測準確度。
為解決這項手動程序帶來的挑戰，建議採用 CI/CD 和 CT 的 MLOps 做法。部署機器學習訓練管道後，即可啟用 CT，並設定 CI/CD 系統，快速測試、建構及部署機器學習管道的新實作項目。接下來的章節將詳細探討這些功能。
機器學習運作第 1 級：機器學習管道自動化
第 1 級的目標是自動執行機器學習管道，持續訓練模型，並持續推送軟體更新模型預測服務。如要自動化使用新資料的流程，以便重新訓練實際工作環境中的模型，您需要在管道中導入自動化資料和模型驗證步驟，以及管道觸發條件和中繼資料管理功能。
下圖是 CT 的自動化機器學習管道示意圖。
圖 3. 機器學習管道自動化，以進行 CT。
特性
如圖 3 所示，MLOps 第 1 級設定具有下列特徵：
快速實驗：系統會協調機器學習實驗的步驟。步驟之間的轉換是自動進行，因此可快速疊代實驗，並更妥善地將整個管道移至實際工作環境。
實際工作環境中的模型 CT：系統會根據即時管道觸發條件，使用新資料自動訓練實際工作環境中的模型，詳情請參閱下一節。
實驗與作業的對稱性：開發或實驗環境中使用的管道實作項目，也會用於前置製作和實際工作環境，這是 MLOps 實務的關鍵層面，可統一 DevOps。
元件和管道的模組化程式碼：如要建構機器學習管道，元件必須可重複使用、可組合，且可能在機器學習管道之間共用。因此，雖然 EDA 程式碼仍可存在於筆記本中，但元件的原始碼必須模組化。此外，元件最好能以容器化方式執行下列操作：
- 將執行環境與自訂程式碼執行階段分離。
- 確保程式碼可在開發和正式環境之間重現。
- 隔離管道中的每個元件。元件可以有自己的執行階段環境版本，以及不同的語言和程式庫。
持續推送模型更新：正式環境中的機器學習管道會持續推送預測服務，以提供給根據新資料訓練的新模型。系統會自動執行模型部署步驟，將訓練及驗證完成的模型做為線上預測的預測服務。
管道部署：在第 0 級，您會將訓練好的模型部署為實際工作環境的預測服務。在第 1 級，您會部署整個訓練管道，該管道會自動且重複執行，將訓練好的模型做為預測服務。
附加元件
本節說明需要新增至架構的元件，以啟用機器學習持續訓練。
資料和模型驗證
將機器學習管線部署至正式環境後，系統會自動執行「機器學習管線觸發條件」一節中討論的一或多個觸發條件。管道會預期新資料 (即時資料) 產生以新資料訓練的新模型版本 (如圖 3 所示)。因此，實際工作環境管道中必須有自動化資料驗證和模型驗證步驟，確保下列預期行為：
資料驗證：這是訓練模型前的必要步驟，可決定是否應重新訓練模型或停止執行管道。如果管道偵測到下列情況，系統就會自動做出這項決定。
- 資料結構定義偏差：這些偏差視為輸入資料中的異常狀況。因此，下游管道步驟 (包括資料處理和模型訓練步驟) 會收到不符合預期結構定義的輸入資料。在這種情況下，您應停止管道，讓資料科學團隊進行調查。團隊可能會發布修正程式或更新管道，以處理結構定義中的這些變更。架構偏差包括收到非預期的功能、未收到所有預期的功能，或收到具有非預期值的功能。
- 資料值偏差：資料的統計屬性出現重大變化，表示資料模式正在改變，因此您需要觸發模型重新訓練，以擷取這些變化。
模型驗證：成功使用新資料訓練模型後，就會執行這個步驟。您可以在模型升級至正式環境前進行評估和驗證。這個離線模型驗證步驟包含下列項目。
- 使用測試資料集，透過訓練好的模型產生評估指標值，評估模型的預測品質。
- 將新訓練模型產生的評估指標值，與目前模型 (例如生產模型、基準模型或其他業務需求模型) 進行比較。您會先確認新模型比目前模型更有效，再將新模型升級為正式版。
- 確保模型在各種資料區隔上的成效一致。舉例來說，與先前的模型相比，新訓練的顧客流失模型可能整體預測準確度較高，但每個顧客區域的準確度值可能差異很大。
- 請務必測試模型是否可供部署，包括基礎架構相容性，以及與預測服務 API 的一致性。
除了離線模型驗證外，新部署的模型還會經過線上模型驗證 (在 Canary 部署或 A/B 測試設定中)，才會為線上流量提供預測。
特徵儲存庫
層級 1 機器學習管道自動化可選用的額外元件是特徵商店。特徵儲存庫是集中式存放區，可供您標準化特徵的定義、儲存和存取，以用於訓練和服務。特徵儲存庫需要提供 API，以高處理量批次提供特徵值，並以低延遲即時提供特徵值，同時支援訓練和提供模型的工作負載。
特徵儲存庫可協助資料科學家執行下列作業：
- 探索並重複使用實體的可用特徵集，不必重新建立相同或類似的特徵集。
- 維護特徵及其相關中繼資料，避免定義不同的類似特徵。
- 從特徵儲存庫提供最新特徵值。
使用特徵儲存庫做為實驗、持續訓練和線上服務的資料來源，避免訓練服務偏移。這種做法可確保用於訓練的特徵與服務期間使用的特徵相同：
- 為了進行實驗，資料科學家可以從特徵商店取得離線擷取內容，然後執行實驗。
- 如要持續訓練，自動化機器學習訓練管道可以擷取用於訓練工作的資料集最新特徵值批次。
- 如果是線上預測，預測服務可以擷取與所要求實體相關的特徵值批次，例如顧客人口統計特徵、產品特徵和目前工作階段匯總特徵。
- 對於線上預測和特徵擷取，預測服務會找出實體的相關特徵。舉例來說，如果實體是顧客，相關特徵可能包括年齡、購物記錄和瀏覽行為。這項服務會將這些特徵值批次處理，並一次擷取實體的所有必要特徵，而非個別擷取。這種擷取方法有助於提高效率，特別是在需要管理多個實體時。
中繼資料管理
系統會記錄機器學習管道的每次執行作業，協助您瞭解資料和構件的沿襲、可重現性及比較結果。這也有助於偵錯錯誤和異常狀況。每次執行管道時，ML 中繼資料儲存庫都會記錄下列中繼資料：
- 執行的管道和元件版本。
- 開始和結束日期、時間，以及管道完成每個步驟所需的時間。
- 管道的執行者。
- 傳遞至管道的參數引數。
- 指向管道各步驟所產生構件的指標，例如準備好的資料位置、驗證異常、計算出的統計資料，以及從類別特徵擷取的詞彙。追蹤這些中繼輸出內容，有助於在管道因步驟失敗而停止時，從最近的步驟繼續執行管道，不必重新執行已完成的步驟。
- 如果需要還原至先前的模型版本，或在管道於模型驗證步驟中取得新的測試資料時，需要為先前的模型版本產生評估指標，則可使用先前訓練模型的指標。
- 模型評估步驟中產生的模型評估指標，適用於訓練和測試集。在模型驗證步驟中，您可以根據這些指標，比較新訓練模型的成效與先前模型的記錄成效。
機器學習管道觸發條件
視您的用途而定，您可以自動執行機器學習正式版管道，使用新資料重新訓練模型：
- 隨選：臨時手動執行管道。
- 依排程：系統會定期提供新的標記資料，供機器學習系統使用，頻率為每日、每週或每月。重新訓練的頻率也取決於資料模式的變化頻率，以及重新訓練模型的成本。
- 新的訓練資料可用時：機器學習系統不會有系統地取得新資料，而是會在收集新資料並提供給來源資料庫時，臨時取得新資料。
- 模型效能下降時：模型效能明顯下降時，系統會重新訓練模型。
- 資料分布情況大幅變動時 (概念偏移)。您很難評估線上模型的完整成效，但會發現用於執行預測的特徵資料分布有顯著變化。這些變化表示模型已過時，需要使用最新資料重新訓練。
挑戰
假設您不會經常部署管道的新實作項目，且只管理少數管道，通常會手動測試管道及其元件。此外，您還會手動部署新的管道實作項目。您也會將經過測試的管道原始碼提交給 IT 團隊，以便部署至目標環境。如果您是根據新資料 (而非新的機器學習概念) 部署新模型，就適合採用這種設定。
不過，您需要嘗試新的機器學習構想，並快速部署機器學習元件的新實作項目。如果您在正式版環境中管理許多機器學習管道，就需要設定 CI/CD，自動建構、測試及部署機器學習管道。
機器學習運作第 2 級：持續整合/持續推送軟體更新管道自動化
如要在實際工作環境中執行快速又可靠的管道更新作業，您必須具備一套強大的自動化持續整合/持續推送軟體更新系統。這套自動化 CI/CD 系統可讓您的資料科學家迅速探索特徵工程、模型架構和超參數領域的新概念，然後將這些概念付諸實行，並在目標環境中自動建構、測試及部署新的管道元件。
下圖顯示使用 CI/CD 實作的機器學習管道，具有自動化機器學習管道設定的特徵，以及自動化 CI/CD 常式。
圖 4. 持續整合/持續推送軟體更新與自動化機器學習管道。
這個 MLOps 設定包含下列元件：
- 原始碼控管
- 測試及建構服務
- 部署服務
- Model Registry
- 特徵儲存庫
- 機器學習中繼資料儲存庫
- 機器學習管道自動化調度工具
特性
下圖顯示機器學習 CI/CD 自動化管道的階段：
圖 5：持續整合/持續推送軟體更新自動化機器學習管道的階段。
這個管線包含下列階段：
開發和實驗：您會反覆嘗試新的機器學習演算法和新模型，並協調實驗步驟。這個階段的輸出內容是機器學習管道步驟的原始碼，隨後會推送至原始碼存放區。
管道持續整合：建構原始碼並執行各種測試。這個階段的輸出內容是 pipeline 元件 (套件、可執行檔和構件)，將在後續階段部署。
管道持續推送軟體更新：將 CI 階段產生的構件部署至目標環境。這個階段的輸出內容是已部署的 pipeline，其中包含模型的新實作項目。
自動觸發：系統會根據排程或觸發條件，在正式環境中自動執行管道。這個階段的輸出內容是已訓練的模型，會推送至模型登錄。
模型持續推送軟體更新：您可將訓練好的模型做為預測服務，提供預測結果。這個階段的輸出內容是已部署的模型預測服務。
監控：根據即時資料收集模型成效的統計資料。這個階段的輸出內容是執行管道或新實驗週期的觸發條件。
在管道開始新一輪實驗前，資料科學家仍須手動分析資料。模型分析步驟也是手動程序。
持續整合
在這個設定中，當新程式碼提交或推送至原始碼存放區時，系統會建構、測試及封裝管道及其元件。除了建構套件、容器映像檔和可執行檔，CI 程序還可以包含下列測試：
單元測試特徵工程邏輯。
對模型中實作的不同方法進行單元測試。舉例來說，假設您有一個函式會接受類別資料欄，並將函式編碼為獨熱特徵。
測試模型訓練是否會收斂 (也就是模型損失會隨著疊代次數減少，並過度擬合幾個樣本記錄)。
測試模型訓練是否會因除以零或操控小值/大值而產生 NaN 值。
測試管道中的每個元件是否產生預期構件。
測試管道元件之間的整合。
持續推送軟體更新
在這個層級，系統會持續將新的管道實作項目傳送至目標環境，進而提供新訓練模型的預測服務。如要快速且可靠地持續推送管道和模型，請考慮下列事項：
在部署模型前，請先確認模型與目標基礎架構是否相容。舉例來說，您需要確認模型所需的套件已安裝在服務環境中，且可用的記憶體、運算和加速器資源符合需求。
呼叫服務 API 並提供預期輸入內容，測試預測服務，確保您收到預期回應。這項測試通常會擷取更新模型版本時可能發生的問題，並預期會有不同的輸入內容。
驗證用於重新訓練或批次預測的資料。
在部署模型前，先確認模型是否達到預測成效目標。
自動部署到測試環境，例如將程式碼推送至開發分支時觸發的部署作業。
半自動部署至前置製作環境，例如在審查人員核准變更後，將程式碼合併至主要分支版本時觸發的部署作業。
在試產環境中成功執行管道多次後，手動部署到正式環境。
總而言之，在正式環境中導入機器學習，不只是將模型部署為預測 API，而是指部署機器學習管道，自動重新訓練及部署新模型。設定 CI/CD 系統後，您就能自動測試及部署新的管道實作項目。這個系統可協助您因應資料和業務環境的快速變化。您不必立即將所有程序從一個層級移至另一個層級。您可以逐步導入這些做法，協助改善機器學習系統開發和生產的自動化程度。
後續步驟
- 進一步瞭解使用 TensorFlow Extended、Vertex AI Pipelines 和 Cloud Build 的機器學習運作架構。
- 瞭解從業人員的機器學習運作指南 (MLOps)。
- 在 YouTube 觀看 2019 年 Cloud Next 大會的 MLOps 最佳做法 Google Cloud 。
- 如要瞭解適用於 Google CloudAI 和機器學習工作負載的架構原則和建議，請參閱 Well-Architected Framework 中的AI 和機器學習觀點。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。
貢獻者
作者：
- Jarek Kazmierczak | 解決方案架構師
- Khalid Salama | 機器學習軟體工程師
- Valentin Huerta | AI 工程師
其他貢獻者：Sunil Kumar Jang Bahadur | 客戶工程師