使用 Azure 機器學習 將機器學習作業 （MLOps） 架構升級為機器學習生命週期

這個客戶項目説明一家財富500強食品公司改善了其需求預測。 該公司將產品直接運送到多個零售店。 改進有助於他們優化在 美國 數個區域中不同商店的產品庫存。 為了達成此目的，Microsoft 的商業軟體工程（CSE）小組與客戶的數據科學家合作進行試驗研究，以開發所選區域的自定義機器學習模型。 模型會考慮：

• 購物者人口統計
• 歷史天氣和預報天氣
• 過去的出貨
• 產品傳回
• 特殊活動

優化庫存的目標是專案的主要組成部分，客戶在早期現場試驗中實現了顯著的銷售提升。 此外，與歷史平均基準模型相比，該小組在預測平均絕對百分比誤差（MAPE）方面也減少了 40%。

該專案的關鍵部分是瞭解如何將數據科學工作流程從試驗研究擴大至生產水準。 此生產層級工作流程需要 CSE 小組：

• 開發許多區域的模型。
• 持續更新和監視模型的效能。
• 促進數據與工程小組之間的共同作業。

現今典型的數據科學工作流程比生產工作流程更接近一次性實驗室環境。 數據科學家的環境必須適合他們：

• 準備資料。
• 試驗不同的模型。
• 微調超參數。
• 建立 build-test-evaluate-refine 迴圈。

大部分用於這些工作的工具都有特定用途，而且不適合自動化。 在生產層級機器學習作業中，必須考慮到應用程式生命週期管理和 DevOps。

CSE 小組協助用戶端將作業相應增加至生產層級。 它們實作持續整合和持續傳遞 （CI/CD） 功能的各種層面，並解決了可觀察性、與 Azure 功能的整合等問題。 在實作期間，小組發現現有MLOps指引中的差距。 需要填補這些差距，以便更清楚地瞭解 MLOps 並大規模應用。

瞭解 MLOps 做法可協助組織確保系統產生的機器學習模型是可改善商務效能的生產品質模型。 實作 MLOps 時，組織不再需要花太多時間處理與開發和執行生產層級作業所需的基礎結構和工程工作相關的低階詳細數據。 實作 MLOps 也可協助數據科學與軟體工程社群瞭解如何共同合作，以提供生產就緒的系統。

CSE 小組藉由解決開發 MLOps 成熟度模型之類的問題，使用此專案來解決機器學習社群需求。 這些努力旨在藉由瞭解 MLOps 程式中主要參與者的典型挑戰來改善 MLOps 採用。

參與和技術案例

參與案例會討論 CSE 小組必須解決的實際挑戰。 技術案例會定義建立 MLOps 生命週期的需求，該生命週期與妥善建立的 DevOps 生命週期一樣可靠。

參與案例

客戶會定期將產品直接送到零售市場網點。 每個零售店在其產品使用模式中各有不同，因此每個每周交貨的產品庫存都必須有所不同。 將銷售量最大化，並將產品回報降到最低，並失去銷售機會是客戶所使用的需求預測方法的目標。 此專案著重於使用機器學習來改善預測。

CSE 小組將專案分成兩個階段。 第1階段著重於開發機器學習模型，以支持針對所選銷售區域進行機器學習預測有效性的現場試驗研究。 第 1 階段的成功導致了第 2 階段，該小組從支援單一地理區域的最小模型小組將初始試驗研究擴大為所有客戶銷售區域的一組可持續生產層級模型。 相應增加解決方案的主要考慮是需要容納大量的地理區域及其當地零售店。 小組會將機器學習模型專用於每個區域中的大型和小型零售店。

第 1 階段試驗研究確定，一個區域零售店專用的模型可以使用當地銷售歷史、當地人口統計、天氣和特殊事件，將該區域的網點需求預測優化。 四種合奏機器學習預測模型在單一區域中為市場網點提供服務。 模型會以每周批次處理數據。 此外，小組還開發了兩個基準模型，使用歷程記錄數據進行比較。

針對第一版的相應增加階段 2 解決方案，CSE 小組選取了 14 個地理區域參與，包括小型和大型市場網點。 他們使用了 50 多個機器學習預測模型。 小組預計進一步的系統成長，並持續精簡機器學習模型。 很明顯，只有在基於適用於機器學習環境的 DevOps 最佳做法原則時，這種更廣泛的機器學習解決方案才可持續。

MLOps 程式為相應增加的系統提供了架構，可解決機器學習模型的完整生命週期。 架構包括開發、測試、部署、作業和監視。 它滿足傳統 CI/CD 程式的需求。 不過，由於與 DevOps 相比，其相對不成熟，因此很明顯，現有的 MLOps 指導方針有差距。 專案小組努力填補其中一些空白。 他們想要提供功能程式模型，以確保相應增加機器學習解決方案的可行性。

從這個項目開發的 MLOps 程式，在將 MLOps 移至更高層級的成熟度和可行性方面，邁出了重要的真實世界步驟。 新的程式直接適用於其他機器學習專案。 CSE 小組使用他們學到的內容來建置 MLOps 成熟度模型的草稿，任何人都可以套用至其他機器學習專案。

技術案例

MLOps 也稱為適用於機器學習的DevOps，是一個傘式詞彙，其中包含在生產環境中實作機器學習生命週期的相關哲學、做法和技術。 它仍然是一個相對新的概念。 有許多嘗試定義 MLOps 是什麼，許多人質疑 MLOps 是否可以從數據科學家如何準備數據到最終提供、監視和評估機器學習結果等一切來細分所有專案。 雖然 DevOps 有數年時間開發一組基本做法，但 MLOps 仍在其開發初期。 隨著它的發展，我們探索了將兩個經常以不同技能集和優先順序運作的專業領域的挑戰：軟體/作業工程和數據科學。

在真實世界的生產環境中實作 MLOps 具有必須克服的獨特挑戰。 Teams 可以使用 Azure 來支援 MLOps 模式。 Azure 也可以為用戶端提供資產管理和協調流程服務，以有效管理機器學習生命週期。 Azure 服務是我們本文所述 MLOps 解決方案的基礎。

機器學習模型需求

第 1 階段試驗實地研究期間的大部分工作是建立 CSE 小組在單一區域中套用至大型和小型零售商店的機器學習模型。 包含的模型值得注意的需求：

• 使用 Azure 機器學習 服務。

• 在 Jupyter Notebook 中開發的初步實驗模型，並在 Python 中實作。

  注意

  Teams 針對大型和小型商店使用相同的機器學習方法，但定型和評分數據取決於商店的大小。

• 需要準備模型耗用量的數據。

• 批次處理的數據，而不是實時處理。

• 每當程式代碼或數據變更，或模型過時時，模型重新定型。

• 在Power BI儀錶板中檢視模型效能。

• 相較於歷史平均基準模型，MAPE <= 45% 時，評分中的模型效能會被視為顯著。

MLOps 需求

小組必須滿足幾個關鍵需求，才能從第1階段試驗實地研究擴大解決方案，其中只有少數模型是針對單一銷售區域開發的。 階段 2 針對多個區域實作自定義機器學習模型。 實作包括：

• 每個區域中大型和小型存放區的每周批處理，以使用新的數據集重新定型模型。

• 機器學習模型的連續精簡。

• 在類似 DEVOps 的 MLOps 處理環境中整合開發/測試/測試/部署常見 CI/CD 的程式。

  注意

  這代表數據科學家和數據工程師過去一般運作方式的轉變。

• 唯一模型，根據商店歷程記錄、人口統計和其他重要變數，代表大型和小型商店的每個區域。 模型必須處理整個數據集，以將處理錯誤的風險降到最低。

• 一開始擴大以支援 14 個銷售區域的能力，並計劃進一步擴大。

• 針對區域和其他存放區叢集進行長期預測的其他模型規劃。

機器學習模型解決方案

機器學習生命週期也稱為數據科學生命週期，大致適用於下列高階程式流程：

此處的部署模型 可以代表已驗證機器學習模型的任何操作用途。 相較於 DevOps，MLOps 提出了將機器學習生命週期整合到一般 CI/CD 程式的額外挑戰。

數據科學生命週期不會遵循典型的軟體開發生命週期。 它包含使用 Azure 機器學習 來定型和評分模型，因此這些步驟必須包含在 CI/CD 自動化中。

數據的批處理是架構的基礎。 兩個 Azure 機器學習 管線是流程的核心，一個用於訓練，另一個用於評分。 下圖顯示用於用戶端專案初始階段的數據科學方法：

小組測試了數種演算法。 他們最終選擇了 LASSO 線性回歸模型的合奏設計，以及具有類別內嵌的神經網路。 小組使用相同的模型，由用戶端可以儲存在月臺的產品層級定義，用於大型和小型商店。 該小組進一步將模型細分為快速移動和緩慢行動的產品。

數據科學家會在小組發行新程式碼和有新數據可用時，訓練機器學習模型。 定型通常會每周進行。 因此，每個處理回合都牽涉到大量數據。 由於小組會以不同格式從許多來源收集數據，因此需要調理，才能讓數據進入消費性格式，數據科學家才能處理數據。 數據調理需要大量的手動工作，而 CSE 小組將其識別為自動化的主要候選專案。

如前所述，數據科學家在階段 1 試驗實地研究中，將實驗性 Azure 機器學習 模型開發並套用至單一銷售區域，以評估此預測方法的實用性。 CSE團隊判斷，試點研究中商店的銷售提升意義重大。 此成功使解決方案套用至階段 2 的完整生產層級，從 14 個地理區域和數千家商店開始。 然後，小組可以使用相同的模式來新增其他區域。

試驗模型是相應增加解決方案的基礎，但 CSE 小組知道該模型需要進一步精簡，以持續改善其效能。

MLOps 解決方案

隨著 MLOps 概念成熟，小組通常會發現將數據科學和 DevOps 專業領域整合在一起的挑戰。 原因是學科、軟體工程師和數據科學家的主要參與者會以不同的技能集和優先順序運作。

但有相似之處可建置。 MLOps，例如DevOps，是工具鏈所實作的開發程式。 MLOps 工具鏈包含下列專案：

• 版本控制
• 程式碼分析
• 建置自動化
• 持續整合
• 測試架構和自動化
• 整合至 CI/CD 管線的合規性政策
• 部署自動化
• 監視
• 災害復原和高可用性
• 封裝和容器管理

如上所述，解決方案會利用現有的 DevOps 指引，但已增強，以建立更成熟的 MLOps 實作，以符合客戶端和數據科學社群的需求。 MLOps 會以 DevOps 指引為基礎，其中包含下列額外需求：

• 數據和模型版本設定與程式碼版本設定不同： 架構和原始資料變更時，數據集必須有版本設定。
• 數位稽核線索需求： 處理程式碼和客戶端資料時，追蹤所有變更。
• 一般化： 模型與重複使用的程序代碼不同，因為數據科學家必須根據輸入數據和案例來調整模型。 若要針對新案例重複使用模型，您可能需要微調/轉移/學習模型。 您需要定型管線。
• 過時的模型： 模型通常會隨著時間而衰變，而且您需要能夠視需要重新定型模型，以確保它們與生產環境保持相關。

MLOps 挑戰

不成熟的 MLOps 標準

MLOps 的標準模式仍在演進。 解決方案通常會從頭開始建置，並符合特定客戶端或使用者的需求。 CSE 小組已辨識此差距，並試圖在此專案中使用DevOps最佳做法。 他們強化了 DevOps 程式，以符合 MLOps 的其他需求。 小組開發的流程是 MLOps 標準模式看起來應該的樣子的可行範例。

技能集的差異

軟體工程師和數據科學家為小組帶來獨特的技能集。 這些不同的技能集可讓尋找符合每個人需求的解決方案變得困難。 為模型從實驗傳遞至生產環境建置清楚的工作流程非常重要。 小組成員必須分享他們如何將變更整合到系統中，而不會中斷 MLOps 程式。

管理多個模型

針對困難的機器學習案例，通常需要多個模型來解決。 MLOps 的其中一個挑戰是管理這些模型，包括：

• 有一致的版本控制配置。
• 持續評估及監視所有模型。

也需要可追蹤的程式代碼和數據歷程，才能診斷模型問題，並建立可重現的模型。 自定義儀錶板可以理解已部署的模型執行方式，並指出何時進行干預。 小組為此專案建立了這類儀錶板。

需要數據調節

與這些模型搭配使用的數據來自許多私人和公用來源。 由於原始數據已解除組織，因此機器學習模型不可能以原始狀態取用它。 數據科學家必須將數據條件設定為機器學習模型取用的標準格式。

大部分試驗現場測試都著重於調理原始數據，讓機器學習模型可以處理它。 在 MLOps 系統中，小組應該將此程式自動化，並追蹤輸出。

MLOps 成熟度模型

MLOps 成熟度模型的目的是釐清原則和做法，並找出 MLOps 實作中的差距。 這也是向客戶端示範如何以累加方式成長 MLOps 功能的一種方式，而不是嘗試一次完成所有作業。 用戶端應該使用它作為下列指南：

• 估計專案的工作範圍。
• 建立成功準則。
• 識別交付專案。

MLOps 成熟度模型會定義五種技術功能層級：

如需 MLOps 成熟度模型的目前版本，請參閱 MLOps 成熟度模型 一文。

MLOps 進程定義

MLOps 包含從取得原始數據到傳遞模型輸出的所有活動，也稱為評分：

• 數據調理
• 模型訓練
• 模型測試和評估
• 建置定義和管線
• 發行管線
• 部署
• 評分

基本機器學習程式

基本機器學習程式類似於傳統軟體開發，但有顯著的差異。 下圖說明機器學習程式的主要步驟：

實驗階段對數據科學生命週期而言是獨一無二的，這反映了數據科學家傳統上如何執行其工作。 這與程式代碼開發人員執行其工作的方式不同。 下圖更詳細地說明此生命週期。

將此數據開發程式整合到 MLOps 中會帶來挑戰。 在這裡，您會看到小組用來將程式整合到 MLOps 可支援表單的模式：

MLOps 的角色是建立協調程式，以有效率地支持生產層級系統中常見的大規模 CI/CD 環境。 從概念上講，MLOps 模型必須包含實驗到評分的所有程式需求。

CSE 小組精簡 MLOps 程式，以符合用戶端的特定需求。 最值得注意的需求是批處理，而不是實時處理。 隨著團隊開發的擴大系統，他們確定了並解決了一些缺點。 其中最重要的缺點是開發 Azure Data Factory 與 Azure 機器學習 之間的橋樑，小組會使用 Azure Data Factory 中的內建連接器來實作。 他們會建立此元件集，以協助觸發和狀態監視，讓程式自動化能夠運作。

另一個根本性的變化是，數據科學家需要能夠將實驗程序代碼從 Jupyter 筆記本導出到 MLOps 部署程式，而不是直接觸發訓練和評分。

以下是最終的 MLOps 程式模型概念：

MLOps 程式流程

下圖說明如何將 CI/CD 開發和發行工作流程套用至機器學習生命週期：

• 從功能分支建立提取要求時，管線會執行 程式碼驗證測試 ，透過單元測試和程式碼質量測試來驗證程式碼的品質。 為了驗證上游品質，管線也會執行 基本模型驗證測試 ，以使用一組模擬數據的範例來驗證端對端定型和評分步驟。
• 當 PR 合併至主要分支時，CI 管線會執行相同的程式代碼驗證測試和基本模型驗證測試，並增加 Epoch。 然後管線會封裝成品，其中包含程式碼和二進位檔，以在機器學習環境中執行。
• 取得成品之後， 就會觸發模型驗證CD管線 。 它會在開發機器學習環境中執行端對端驗證。 已發行評分機制。 針對批次評分案例，評分管線會發佈至機器學習環境並觸發以產生結果。 如果您想要使用即時評分案例，您可以發佈 Web 應用程式或部署容器。
• 一旦建立里程碑並合併至發行分支，就會觸發相同的 CI 管線和模型驗證 CD 管線。 這一次，他們會針對發行分支的程式代碼執行。

您可以將上面顯示的 MLOps 處理數據流視為專案原型架構，這些架構會做出類似的架構選擇。

程式代碼驗證測試

機器學習的程式代碼驗證測試著重於驗證程式代碼基底的品質。 其概念與任何具有程式碼質量測試（linting）、單元測試和程式代碼涵蓋範圍測量的工程專案相同。

基本模型驗證測試

模型驗證通常是指驗證產生有效機器學習模型所需的完整端對端程式步驟。 它包含如下的步驟：

• 數據驗證： 確保輸入數據有效。
• 定型驗證： 確保模型可以成功定型。
• 評分驗證： 確保小組可以成功使用定型的模型來評分輸入數據。

在機器學習環境中執行這組完整的步驟相當昂貴且耗時。 因此，小組在開發計算機上本機執行基本模型驗證測試。 它執行上述步驟，並使用下列專案：

• 本機測試數據集： 小型數據集，通常是模糊化的數據集，會簽入存放庫並取用作為輸入數據源。
• 本機旗標： 模型程序代碼中的旗標或自變數，指出程式代碼想要在本機執行數據集。 旗標會指示程式代碼略過對機器學習環境的任何呼叫。

這些驗證測試的目標不是評估已定型模型的效能。 相反地，驗證端對端程式的程式代碼品質良好。 它會確保上游推送的程式代碼品質，例如在PR和 CI 組建中納入模型驗證測試。 它也可讓工程師和數據科學家將斷點放入程式代碼中，以供偵錯之用。

模型驗證CD管線

模型驗證管線的目標是使用實際數據來驗證機器學習環境中的端對端模型定型和評分步驟。 產生的任何定型模型都會新增至模型登錄並加上標記，以在驗證完成後等候升階。 針對批次預測，升級可以是發佈使用此模型版本的評分管線。 若要進行即時評分，可以標記模型，以指出該模型已升級。

評分CD管線

評分 CD 管線適用於批次推斷案例，其中用於模型驗證的相同模型協調器會觸發已發佈的評分管線。

開發與生產環境

最好將開發（開發）環境與生產環境區隔開來。 分離可讓系統根據不同的排程觸發模型驗證CD管線和評分CD管線。 針對所述的 MLOps 流程，以開發環境中主要分支為目標的管線，以及以發行分支為目標的管線會在生產環境中執行。

程式代碼變更與數據變更

前幾節主要處理如何處理從開發到發行的程式代碼變更。 不過，數據變更應該遵循與程式碼變更相同的嚴謹性，以在生產環境中提供相同的驗證品質和一致性。 透過資料變更觸發程式或定時器觸發程式，系統可以從模型協調器觸發模型驗證CD管線和評分CD管線，以執行在發行分支生產環境中執行程式代碼變更的相同程式。

MLOps 角色和角色

任何 MLOps 程式的關鍵需求是它符合程式許多使用者的需求。 為了設計目的，請將這些使用者視為個別角色。 針對此專案，小組識別出下列角色：

• 數據科學家： 建立機器學習模型及其演算法。
• 工程師
  • 數據工程師： 處理數據調理。
  • 軟體工程師： 處理資產套件和 CI/CD 工作流程中的模型整合。
• 作業或 IT： 監督系統作業。
• 業務項目關係人： 關心機器學習模型所做的預測，以及其如何協助業務。
• 數據終端使用者： 以某種方式取用模型輸出，以協助制定商務決策。

研究小組必須解決角色和角色研究的三個關鍵發現：

• 數據科學家和工程師在工作中的方法和技能不符。 讓數據科學家和工程師輕鬆地共同作業，是 MLOps 程式流程設計的主要考慮。 它需要所有小組成員取得新的技能。
• 需要統一所有主要角色，而不疏遠任何人。 執行此動作的一種方式是：
  • 請確定他們瞭解 MLOps 的概念模型。
  • 同意將共同合作的小組成員。
  • 建立工作指導方針以達成共同目標。
• 如果商務項目關係人和數據終端使用者需要一種方式來與模型的數據輸出互動，則使用者易記 UI 是標準解決方案。

其他小組一定會在其他機器學習專案中遇到類似的問題，因為它們會相應增加以供生產環境使用。

MLOps 解決方案架構

邏輯架構

數據來自許多不同格式的來源，因此會在數據湖中插入數據湖之前加以設定。 使用以 Azure Functions 運作的微服務來完成調理。 用戶端會自定義微服務以符合數據源，並將其轉換成定型和評分管線取用的標準化 csv 格式。

系統架構

批處理架構

小組設計了架構設計來支援批次數據處理配置。 有替代方案，但使用的任何專案都必須支援 MLOps 程式。 完全使用可用的 Azure 服務是設計需求。 下圖顯示架構：

解決方案概觀

Azure Data Factory 會執行下列動作：

• 觸發 Azure 函式來啟動數據擷取和 Azure 機器學習 管線的執行。
• 啟動耐久函式，以輪詢 Azure 機器學習 管線以完成。

Power BI 中的自定義儀錶板會顯示結果。 透過OpenCensus Python SDK 連線到 Azure SQL、Azure 監視器和 App Insights 的其他 Azure 儀錶板，追蹤 Azure 資源。 這些儀錶板提供機器學習系統健康情況的相關信息。 它們也會產生客戶端用於產品訂單預測的數據。

模型協調流程

模型協調流程會遵循下列步驟：

1. 提交PR時，DevOps會觸發程式代碼驗證管線。
2. 管線會執行單元測試、程式代碼質量測試和模型驗證測試。
3. 合併至main分支時，會執行相同的程式代碼驗證測試，而DevOps會封裝成品。
4. 收集成品的 DevOps 會觸發 Azure 機器學習 來執行：
   1. 資料驗證。
   2. 定型驗證。
   3. 評分驗證。
5. 驗證完成之後，最終評分管線就會執行。
6. 變更數據並提交新的 PR 會再次觸發驗證管線，後面接著最終評分管線。

啟用實驗

如前所述，傳統數據科學機器學習生命週期不支援 MLOps 程式，而不需要修改。 它使用不同類型的手動工具和實驗、驗證、封裝和模型交接，無法輕易地針對有效的 CI/CD 程式進行調整。 MLOps 需要高階的程序自動化。 無論是開發新的機器學習模型還是修改舊的機器學習模型，都需要將機器學習模型的生命週期自動化。 在階段 2 專案中，小組使用 Azure DevOps 來協調和重新發佈 Azure 機器學習 管線以進行定型工作。 長時間執行的主要分支會執行模型的基本測試，並透過長時間執行的發行分支推送穩定版本。

原始檔控制會成為此程式的重要部分。 Git 是用來追蹤筆記本和模型程式碼的版本控制系統。 它也支援程序自動化。 針對原始檔控制實作的基本工作流程會套用下列原則：

• 針對程式代碼和數據集使用正式版本控制。
• 使用分支進行新的程式碼開發，直到程式碼完全開發並驗證為止。
• 驗證新程式代碼之後，即可將其合併到main分支。
• 針對版本，會建立與主要分支分開的永久版本分支。
• 針對已設定定型或取用條件的數據集使用版本和原始檔控制，讓您可以維護每個數據集的完整性。
• 使用原始檔控制來追蹤 Jupyter Notebook 實驗。

與數據源整合

數據科學家會使用許多原始數據源和已處理的數據集來實驗不同的機器學習模型。 生產環境中的數據量可能非常龐大。 若要讓數據科學家試驗不同的模型，他們需要使用 Azure Data Lake 之類的管理工具。 正式識別和版本控制的需求適用於所有未經處理的數據、備妥的數據集和機器學習模型。

在專案中，數據科學家會設定下列數據以輸入模型：

• 自 2017 年 1 月起的歷史每周出貨數據
• 每個郵遞區編碼的歷史和預測每日天氣數據
• 每個商店標識碼的購物者數據

與原始檔控制整合

若要讓數據科學家套用工程最佳做法，必須方便整合它們與 GitHub 等原始檔控制系統搭配使用的工具。 如果小組遇到數據遺失或系統中斷的情況，這種做法可讓機器學習模型版本控制、小組成員之間的共同作業，以及災害復原。

模型合奏支援

此專案中的模型設計是合奏模型。 也就是說，數據科學家在最終模型設計中使用了許多演算法。 在此情況下，模型使用相同的基本演算法設計。 唯一的差異在於他們使用不同的定型數據和評分數據。 模型使用 LASSO 線性回歸演算法和神經網路的組合。

小組探索了但未實作的選項，可將程序轉送至支援在生產環境中執行的許多即時模型，以服務指定的要求。 此選項可以配合 A/B 測試和交錯實驗中的合奏模型使用。

用戶介面

小組開發了使用者UI，用於可觀察性、監視和檢測。 如前所述，儀錶板會以可視化方式顯示機器學習模型數據。 這些儀錶板會以使用者易記的格式顯示下列資料：

• 管線步驟，包括預先處理輸入數據。
• 若要監視機器學習模型處理的健康情況：
  • 您從已部署的模型收集哪些計量？
    • MAPE： 平均絕對百分比錯誤，這是追蹤整體效能的關鍵計量。 （以每個模型的 MAPE 值 <= 0.45 為目標。
    • RMSE 0： 實際目標值 = 0 時，根平均平方誤差 （RMSE）。
    • RMSE All： 整個數據集上的 RMSE。
  • 如何評估模型是否如預期般在生產環境中執行？
  • 是否有辦法判斷生產數據是否偏離預期值太多？
  • 您的模型在生產環境中執行效能不佳嗎？
  • 您有故障轉移狀態嗎？
• 追蹤已處理數據的品質。
• 顯示機器學習模型所產生的評分/預測。

應用程式會根據數據的本質填入儀錶板，以及其處理和分析數據的方式。 因此，小組必須為每個使用案例設計儀錶板的確切配置。 以下是兩個範例儀錶板：

儀錶板的設計目的是要為機器學習模型預測的使用者提供容易使用的資訊。

元件

• Azure Machine Learning
  • Azure Machine Learning Compute
  • Azure 機器學習 Pipelines
  • Azure 機器學習 模型登錄
• Azure Blob 儲存體
• Azure Data Lake 儲存體
• Azure Pipelines
• Azure Data Factory
• 適用於 Python 的 Azure Functions
• Azure 監視器
  • 記錄
  • Application Insights
• Azure SQL Database
• Azure 儀錶板
• Power BI

考量

您可以在這裡找到要探索的考慮清單。 其是以 CSE 小組在專案期間學到的課程為基礎。

環境考慮

• 數據科學家會使用 Python 開發大部分的機器學習模型，通常從 Jupyter 筆記本開始。 實作這些筆記本作為生產程序代碼可能會是一項挑戰。 Jupyter Notebook 更屬於實驗性工具，而 Python 腳本則更適合用於生產環境。 Teams 通常需要花時間將模型建立程式碼重構至 Python 腳本。
• 讓不熟悉 DevOps 和機器學習服務的用戶端知道實驗和生產環境需要不同的嚴謹性，因此最好分開這兩者。
• Azure 機器學習 可視化設計工具或 AutoML 之類的工具，可在用戶端逐步提升標準 DevOps 做法，以套用至解決方案的其餘部分時，讓基本模型生效。
• Azure DevOps 具有可與 Azure 機器學習 整合的外掛程式，以協助觸發管線步驟。 MLOpsPython 存放 庫 有一些這類管線範例。
• 機器學習通常需要功能強大的圖形處理單元 （GPU） 機器進行訓練。 如果用戶端尚未提供這類硬體，Azure 機器學習 計算叢集可以提供有效的路徑，以快速布建符合成本效益的強大硬體來自動調整。 如果用戶端具有進階安全性或監視需求，則還有其他選項，例如標準 VM、Databricks 或本機計算。
• 若要讓用戶端成功，其模型建置小組（數據科學家）和部署小組（DevOps 工程師）必須有強大的通道。 他們可以使用每日站立會議或正式的在線聊天服務來完成這項作業。 這兩種方法都有助於將其開發工作整合在MLOps架構中。

數據準備考慮

• 使用 Azure 機器學習 最簡單的解決方案是將資料儲存在支援的數據記憶體解決方案中。 Azure Data Factory 之類的工具可依排程從這些位置來回輸送數據。

• 客戶端務必經常擷取額外的重新定型數據，使其模型保持在最新狀態。 如果它們還沒有數據管線，建立數據管線將會是整體解決方案的重要組成部分。 使用 Azure 機器學習 中的數據集之類的解決方案，對於版本設定數據有助於追蹤模型很有用。

模型定型和評估考慮

• 對於剛開始進行機器學習旅程的客戶端來說，這是壓倒性的，他們嘗試實作完整的 MLOps 管線。 如有必要，他們可以使用 Azure 機器學習 來追蹤實驗執行，並使用 Azure 機器學習 計算作為定型目標，來輕鬆進行。 這些選項可能會建立較低的進入解決方案屏障，以開始整合 Azure 服務。

• 從筆記本實驗移至可重複的腳本，對於許多數據科學家來說，這是一個粗略的轉換。 您越早就能在 Python 腳本中撰寫訓練程式代碼，讓他們更容易開始建立定型程式代碼的版本設定，並啟用重新定型。

  這不是唯一可能的方法。 Databricks 支援將筆記本排程為作業。 但是，根據目前的客戶端體驗，由於測試限制，這種方法很難使用完整的 DevOps 做法進行檢測。

• 也請務必瞭解使用哪些計量來考慮模型是否成功。 單靠精確度通常不夠好，無法判斷一個模型與另一個模型的整體效能。

計算考量

• 客戶應考慮使用容器來標準化其計算環境。 幾乎所有的 Azure 機器學習 計算目標都支援使用 Docker。 讓容器處理相依性可大幅減少摩擦，特別是當小組使用許多計算目標時。

模型服務考慮

• Azure 機器學習 SDK 提供從已註冊模型直接部署至 Azure Kubernetes Service 的選項，以建立安全性/計量的設定限制。 您可以嘗試尋找更輕鬆的解決方案，讓客戶端測試其模型，但最好是針對生產工作負載開發更強固的 AKS 部署。

下一步

• 深入瞭解 MLOps
• Azure 上的 MLOps
• Azure 監視器視覺效果
• 機器學習 生命週期
• Azure DevOps 機器學習 擴充功能
• Azure Machine Learning CLI
• 根據 Azure Machine Learning 事件來觸發應用程式、程序或 CI/CD 工作流程
• 使用 Azure DevOps 設定模型定型和部署

相關資源

• MLOps 成熟度模型
• 使用 Databricks Notebook 協調 Azure Databricks 上的 MLOps
• 使用 Azure 機器學習 的適用於 Python 模型的 MLOps
• 使用 Azure Databricks 進行數據科學和機器學習
• 使用 Power Platform 的公民 AI
• 在內部部署和邊緣部署 AI 和機器學習運算