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