共用方式為

機器學習作業

  • 發行項

本文主要說明三種適用於機器學習作業的 Azure 架構，這些作業具有端對端持續整合和持續傳遞 (CI/CD) 管線和重新定型管線。 這些 AI 應用程式的架構：

  • 傳統機器學習
  • 電腦視覺 (CV)
  • 自然語言處理

這些架構是 MLOps v2 專案的成果。 它們結合解決方案架構設計人員在開發各種機器學習解決方案的過程中，所識別的最佳做法。 結果是可部署、可重複且可維護的模式。 這三個架構都會使用 Azure Machine Learning 服務。

如需有關使用 MLOps v2 的範例部署範本實作，請參閱 Azure MLOps v2 解決方案加速器。

潛在使用案例

  • 傳統機器學習：表格式結構化資料的時間序列預測、回歸和分類是此類別中最常見的使用案例。 範例包含：

    • 二進位和多標籤分類。

    • 線性、多項式、ridge、lasso、分位數和貝氏迴歸。

    • ARIMA、自動回歸、SARIMA、VAR、SES、LSTM。

  • CV：本文的 MLOps 架構主要著重於分割和影像分類的 CV 使用案例。

  • 自然語言處理：您可以使用此 MLOps 架構來實作：

    • 具名實體辨識：

    • 文字分類

    • 文字產生

    • 情感分析

    • 翻譯

    • 問題解答

    • 摘要

    • 句子偵測

    • 語言偵測

    • Part-of-speech 標記

本文並未說明 AI 模擬、深度增強式學習和其他形式的 AI。

架構

MLOps v2 架構模式具有 MLOps 生命週期的四個主要模組化元件或階段：

  • 資料資產
  • 系統管理和設定
  • 模型開發或內部迴圈階段
  • 模型部署或外部迴圈階段

前述元件、它們之間的連接，以及涉及的典型角色，都是跨所有 MLOps v2 案例架構的標準。 每個元件詳細資料的變化取決於案例。

機器學習的 MLOps v2 基本架構是表格式資料的傳統機器學習案例。 CV 和 NLP 架構建置在此基底架構上，並可進行修改。

MLOps v2 涵蓋本文所述之下列架構：

傳統機器學習架構

顯示傳統機器學習架構的圖表。

下載此架構的 Visio 檔案。

傳統機器學習架構的工作流程

  1. 資料資產

    此元件說明組織的資料資產，以及資料科學專案的潛在資料來源和目標。 資料工程師是 MLOps v2 生命週期中此元件的主要擁有者。 此圖表中的 Azure 資料平台並非詳盡或規定性。 綠色核取記號表示以客戶使用案例為基礎的建議最佳做法的資料來源和目標。

  2. 系統管理和設定

    此元件是 MLOps v2 加速器部署的第一個步驟。 它包含與專案關聯的資源和角色的建立和管理相關的所有工作。 例如，基礎結構小組可能會：

    1. 建立專案原始碼存放庫。
    2. 使用 Bicep 或 Terraform 建立 Machine Learning 工作區。
    3. 建立或修改模型開發和部署的資料集和計算資源。
    4. 定義專案小組使用者、其角色，以及其他資源的存取控制。
    5. 建立 CI/CD 管線。
    6. 建立監視元件，以收集及建立模型和基礎結構計量的警示。

    與此階段相關聯的主要角色是基礎結構小組，但組織可能也有資料工程師、機器學習工程師或資料科學家。

  3. 模型開發 (內部迴圈階段)

    內部迴圈階段包含反覆的資料科學工作流程，可在專用且安全的 Machine Learning 工作區內執行。 上圖顯示一般工作流程。 此程序從資料擷取開始，根據探勘資料分析、實驗、模型開發和評估後再付諸行動，然後註冊模型以供生產環境使用。 MLOps v2 加速器中實作的這個模組化元件，與資料科學小組用來開發模型的程序無關，而且是可以調整的。

    與此階段相關聯的角色，包括資料科學家和機器學習工程師。

  4. Machine Learning 登錄

    在資料科學小組開發可部署到生產環境的模型之後，他們會在 Machine Learning 工作區登錄中註冊模型。 由模型註冊自動觸發的 CI 管線，或透過封閉式人機互動核准後自動觸發的 CI 管線，將模型和其他任何模型相依性提升至模型部署階段。

    與此階段相關聯的角色，通常是機器學習工程師。

  5. 模型部署 (外部迴圈階段)

    模型部署或外部迴圈階段包含生產前預備和測試、生產部署，以及模型、資料和基礎結構的監視。 當模型符合組織和使用案例的準則時，CD 管線會透過生產、監視和潛在重新定型來提升模型和相關資產。

    與此階段相關聯的角色，主要是機器學習工程師。

  6. 預備和測試

    預備和測試階段會根據客戶做法的不同，而有所不同。 此階段通常包括重新定型和測試生產資料上的模型候選項目、端點效能測試部署、資料品質檢查、單元測試，以及模型和資料偏差的負責任 AI 檢查等作業。 此階段會在一或多個專用且安全的 Machine Learning 工作區中執行。

  7. 生產部署

    在模型通過預備和測試階段之後，機器學習工程師可以使用人機互動門控審核，將其推廣至生產。 模型部署選項包括適用於批次案例的受控批次端點，或是用於 Azure Arc 線上、近乎即時案例的受控線上端點或 Kubernetes 部署。 生產通常會在一或多個專用且安全的 Machine Learning 工作區中執行。

  8. 監視

    機器學習工程師會監視預備、測試和生產環境中的元件，以收集模型、資料和基礎結構效能變更的相關計量。 他們可以使用這些計量來採取行動。 模型和資料監視可能包括檢查模型和資料漂移、新資料的模型效能，以及負責任的 AI 問題。 基礎結構監視可能會識別端點回應緩慢、計算容量不足或網路問題。

  9. 資料和模型監測：事件和動作

    根據模型和資料準則，例如計量閾值或排程，自動化觸發程式和通知可以實作可採取的適當行動。 例如，觸發程式可能會重新定型模型以使用新的生產資料，然後將模型回送至預備和測試生產前評估。 或者，模型或資料問題可能會觸發需要回送至模型開發階段的動作，讓資料科學家可以調查問題，並可能開發新的模型。

  10. 基礎結構監視：事件和動作

    自動化觸發程式和通知可以根據基礎結構準則實作適當的動作，例如端點回應延遲或部署計算不足。 自動觸發程式和通知可能會觸發回送至設定和管理階段，讓基礎結構小組可以調查問題，並可能重新設定計算和網路資源。

Machine Learning CV 架構

顯示電腦視覺架構的圖表。

下載此架構的 Visio 檔案。

CV 架構的工作流程

Machine Learning CV 架構是以傳統機器學習架構為基礎，但它具有特定於受監督 CV 案例的修改。

  1. 資料資產

    此元件展示組織的資料資產，以及資料科學專案的潛在資料來源和目標。 資料工程師是 MLOps v2 生命週期中此元件的主要擁有者。 此圖表中的 Azure 資料平台並非詳盡或規定性。 CV 案例的影像可能來自各種資料來源。 如需使用 Machine Learning 開發和部署 CV 模型的效率，我們建議採用 Azure Blob 儲存體和 Azure Data Lake Storage。

  2. 系統管理和設定

    此元件是 MLOps v2 加速器部署的第一個步驟。 它包含與專案關聯的資源和角色的建立和管理相關的所有工作。 針對 CV 案例，MLOps v2 環境的管理和設定大致與傳統機器學習相同，但包含額外的步驟。 基礎結構小組會使用 Machine Learning 或其他工具的標籤功能，來建立影像標籤和註釋專案。

  3. 模型開發 (內部迴圈階段)

    內部迴圈階段包含反覆的資料科學工作流程，可在專用且安全的 Machine Learning 工作區內執行。 此工作流程與傳統機器學習案例的主要差異在於，影像標籤和註釋是此開發迴圈的重要元件。

  4. Machine Learning 登錄

    在資料科學小組開發可部署到生產環境的模型之後，他們會在 Machine Learning 工作區登錄中註冊模型。 由模型註冊自動觸發的 CI 管線，或透過封閉式人機互動核准後自動觸發的 CI 管線，將模型和其他任何模型相依性提升至模型部署階段。

  5. 模型部署 (外部迴圈階段)

    模型部署或外部迴圈階段包含生產前預備和測試、生產部署，以及模型、資料和基礎結構的監視。 當模型符合組織和使用案例的準則時，CD 管線會透過生產、監視和潛在重新定型來提升模型和相關資產。

  6. 預備和測試

    預備和測試階段會根據客戶做法的不同，而有所不同。 此階段通常包含端點效能測試部署、資料品質檢查、單元測試，以及模型和資料偏差的負責任 AI 檢查等作業。 針對 CV 案例，機器學習工程師不需要重新定型模型候選項目，因為資源和時間限制。 資料科學小組可以改用生產資料進行模型開發。 針對從開發迴圈註冊的候選模型進行生產評估。 此階段會在一或多個專用且安全的 Machine Learning 工作區中執行。

  7. 生產部署

    在模型通過預備和測試階段之後，機器學習工程師可以使用人機互動門控審核，將其推廣至生產。 模型部署選項包括適用於批次案例的受控批次端點，或是用於 Azure Arc 線上、近乎即時案例的受控線上端點或 Kubernetes 部署。 生產通常會在一或多個專用且安全的 Machine Learning 工作區中執行。

  8. 監視

    機器學習工程師會監視預備、測試和生產環境中的元件，以收集模型、資料和基礎結構效能變更的相關計量。 他們可以使用這些計量來採取行動。 模型和資料監視可能包括檢查新影像上的模型效能。 基礎結構監視可能會識別端點回應緩慢、計算容量不足或網路問題。

  9. 資料和模型監測：事件和動作

    MLOps 用於自然語言處理的資料和模型監測和事件和動作階段，是傳統機器學習的主要差異。 當偵測到新影像上的模型效能降低，通常不會在 CV 案例中完成自動化重新定型。 在此情況下，需要人機互動程序，才能檢閱並註釋效能不佳之模型的新文字資料。 下一個動作通常會回到模型開發迴圈，以使用新的映像來更新模型。

  10. 基礎結構監視：事件和動作

    自動化觸發程式和通知可以根據基礎結構準則實作適當的動作，例如端點回應延遲或部署計算不足。 自動觸發程式和通知可能會觸發回送至設定和管理階段，讓基礎結構小組可以調查問題，並可能重新設定環境、計算和網路資源。

Machine Learning 自然語言處理架構

自然語言處理架構的圖表。

下載此架構的 Visio 檔案。

自然語言處理架構的工作流程

Machine Learning 自然語言處理架構是以傳統機器學習架構為基礎，但有特定於 NLP 案例的一些修改。

  1. 資料資產

    此元件展示組織資料資產，以及資料科學專案的潛在資料來源和目標。 資料工程師是 MLOps v2 生命週期中此元件的主要擁有者。 此圖表中的 Azure 資料平台並非詳盡或規定性。 綠色核取記號表示以客戶使用案例為基礎的建議最佳做法的來源和目標。

  2. 系統管理和設定

    此元件是 MLOps v2 加速器部署的第一個步驟。 它包含與專案關聯的資源和角色的建立和管理相關的所有工作。 針對自然語言處理案例，MLOps v2 環境的管理和設定基本上與傳統機器學習相同，但有一個額外的步驟：使用 Machine Learning 或其他工具的標籤功能建立影像標籤和註釋專案。

  3. 模型開發 (內部迴圈階段)

    內部迴圈階段包含反覆的資料科學工作流程，可在專用且安全的 Machine Learning 工作區內執行。 典型的 NLP 模型開發迴圈與傳統機器學習案例不同，因為此案例的典型開發步驟包括句子和標記化、正規化，以及文字資料的內嵌。

  4. Machine Learning 登錄

    在資料科學小組開發可部署到生產環境的模型之後，他們會在 Machine Learning 工作區登錄中註冊模型。 由模型註冊自動觸發的 CI 管線，或透過封閉式人機互動核准後自動觸發的 CI 管線，將模型和其他任何模型相依性提升至模型部署階段。

  5. 模型部署 (外部迴圈階段)

    模型部署或外部迴圈階段包含生產前預備和測試、生產部署，以及模型、資料和基礎結構的監視。 當模型符合組織和使用案例的準則時，CD 管線會透過生產、監視和潛在重新定型來提升模型和相關資產。

  6. 預備和測試

    預備和測試階段會根據客戶做法的不同，而有所不同。 此階段通常包括重新定型和測試生產資料上的模型候選項目、端點效能測試部署、資料品質檢查、單元測試，以及模型和資料偏差的負責任 AI 檢查等作業。 此階段會在一或多個專用且安全的 Machine Learning 工作區中執行。

  7. 生產部署

    在模型通過預備和測試階段之後，機器學習工程師可以使用人機互動門控審核，將其推廣至生產。 模型部署選項包括適用於批次案例的受控批次端點，或是用於 Azure Arc 線上、近乎即時案例的受控線上端點或 Kubernetes 部署。 生產通常會在一或多個專用且安全的 Machine Learning 工作區中執行。

  8. 監視

    機器學習工程師會監視預備、測試和生產環境中的元件，以收集模型、資料和基礎結構效能變更的相關計量。 他們可以使用這些計量來採取行動。 模型和資料監視可能包括檢查模型和資料漂移、新文字資料的模型效能，以及負責任的 AI 問題。 基礎結構監視可能可以找出問題，例如端點回應緩慢、計算容量不足和網路問題。

  9. 資料和模型監測：事件和動作

    至於 CV 架構，MLOps 用於自然語言處理的資料和模型監測和事件和動作階段，是傳統機器學習的主要差異。 當偵測到新文字的模型效能降低時，通常不會在自然語言處理案例中完成自動重新定型。 在此情況下，需要人機互動程序，才能檢閱並註釋效能不佳之模型的新文字資料。 下一個動作通常是回到模型開發迴圈，以使用新的文字資料來更新模型。

  10. 基礎結構監視：事件和動作

    自動化觸發程式和通知可以根據基礎結構準則實作適當的動作，例如端點回應延遲或部署計算不足。 自動觸發程式和通知可能會觸發回送至設定和管理階段，讓基礎結構小組可以調查問題，並可能重新設定計算和網路資源。

元件

  • Machine Learning 是一種雲端服務，可供用來定型、評分、部署和管理大規模機器學習模型。

  • Azure Pipelines 是以 Azure DevOps 為基礎的建置和測試系統，可用於建置和發行管線。 Azure Pipelines 會將這些管線分割成稱為工作的邏輯步驟。

  • GitHub 是版本控制、共同作業和 CI/CD 工作流程的程式碼裝載平台。

  • Azure Arc 是使用 Azure Resource Manager 管理 Azure 資源和內部部署資源的平台。 這些資源可以包含虛擬機器、Kubernetes 叢集和資料庫。

  • Kubernetes 為開放原始碼系統，可用於自動執行部署、調整和管理容器化應用程式。

  • Azure Data Lake Storage 是與 Hadoop 相容的檔案系統。 它具有整合式階層命名空間，以及 Blob 儲存體的超大規模和經濟性。

  • Azure Synapse Analytics 是一項無限制的分析服務，可將資料整合、企業資料倉儲和巨量資料分析整合在一起。

  • Azure 事件中樞是擷取用戶端應用程式產生的資料流擷取服務。 然後，它會內嵌並儲存串流資料，保留收到事件的序列。 客戶可以連線到中樞端點，以擷取處理訊息。 此架構使用 Data Lake 儲存體整合。

其他考量

上述 MLOps v2 架構模式有數個重要元件，包括角色型存取控制 (RBAC)，可配合商務利害關係人、有效率的套件管理和健全的監視機制。 這些元件共同為成功實作和管理機器學習工作流程作出貢獻。

角色型 RBAC

您必須管理機器學習資料和資源的存取權。 RBAC 提供健全的架構，協助您管理誰可以執行特定動作，並存取解決方案內的特定區域。 設計身分識別分割策略，以配合 Machine Learning 中機器學習模型的生命週期，以及程序中涵蓋的角色。 每個角色都有一組特定的責任，這些責任會反映在其 RBAC 角色和群組成員資格中。

範例角色

若要在機器學習工作負載中支援適當的分割，請考慮下列通知身分型 RBAC 群組設計的常見角色。

資料科學家和機器學習工程師

資料科學家和機器學習工程師會在專案的軟體開發生命週期中執行各種機器學習和資料科學活動。 其職責包括探勘資料分析和資料前置處理。 資料科學家和機器學習工程師負責訓練、評估和部署模型。 這些角色的責任也包括機器學習模型、套件和資料中斷修正活動。 這些職責已脫離平台技術支援小組的範圍。

類型：人員
特定專案： 是

資料分析師

資料分析師提供資料科學活動的必要輸入，例如執行商業智慧的 SQL 查詢。 此角色的責任包括使用資料、執行資料分析，以及支援模型開發和模型部署。

類型：人員
特定專案： 是

模型測試人員

模型測試人員會在測試和預備環境中進行測試。 此角色提供與 CI/CD 程序的功能性隔離。

類型：人員
特定專案： 是

業務利害關係人

業務利害關係人與專案相關聯，例如行銷經理。

類型：人員
特定專案： 是

專案負責人或資料科學負責人

資料科學負責人是 Machine Learning 工作區的專案管理角色。 此角色也會針對機器學習模型和套件執行中斷修正活動。

類型：人員
特定專案： 是

專案或產品擁有者 (商務擁有者)

業務利害關係人會根據資料擁有權負責 Machine Learning 工作區。

類型：人員
特定專案： 是

平台技術支援

平台技術支援是負責跨平台中斷修正活動的技術支援人員。 此角色涵蓋基礎結構或服務，但不包括機器學習模型、套件或資料。 這些元件仍屬於資料科學家或機器學習工程師角色，而且是專案負責人的責任。

類型：人員
專案特定： 否

模型終端使用者

模型終端使用者是機器學習模型的終端使用者。

類型： 人員或程序
特定專案： 是

CI/CD 程序

CI/CD 跨平台環境處理發行或復原變更。

類型：程序
專案特定： 否

Machine Learning 工作區

Machine Learning 工作區會使用受控識別與 Azure 的其他部分互動。 此角色代表組成 Machine Learning 實作的各種服務。 這些服務會與平台的其他部分互動，例如與開發資料存放區連線的開發工作區。

類型：程序
專案特定： 否

監視處理序

監視處理序即為計算處理序，可根據平台活動來監視和警示。

類型：程序
專案特定： 否

資料治理流程

資料控管程序會掃描機器學習專案和資料存放區以進行資料控管。

類型：程序
專案特定： 否

Microsoft Entra 群組成員資格

當您實作 RBAC 時，Microsoft Entra 群組會提供彈性且可調整的方式來管理不同角色的存取權限。 您可以使用 Microsoft Entra 群組來管理需要對資源 (例如可能受限的應用程式和服務) 具有相同存取權和許可權的使用者。 您無須將特殊權限新增至個別使用者，而可以建立一個群組，將特殊權限套用至該群組的每個成員。

在此架構模式中，您可以將這些群組與 Machine Learning 工作區設定結合，例如專案、小組或部門。 您可以為使用者與特定群組建立關聯，以定義更細微的存取原則。 原則會根據工作函式、專案需求或其他準則，授與或限制各種 Machine Learning 工作區的權限。 例如，您可以有一個群組，用於授與所有資料科學家針對特定使用案例存取開發工作區的存取權。

身分識別 RBAC

請考慮如何使用下列內建 Azure RBAC 角色，將 RBAC 套用至生產和生產階段前環境。 針對本文的架構，生產環境包括預備、測試和生產環境。 生產前環境包括開發環境。 下列 RBAC 角色是以本文稍早所述之角色為基礎。

標準角色

元件特定角色

這些 Azure RBAC 角色縮寫對應下表。

生產環境
角色 Machine Learning 工作區 Azure Key Vault Container Registry Azure 儲存體帳戶 Azure DevOps Azure Artifacts Log Analytics 工作區 Azure 監視器
資料科學家 R LAR MR
資料分析師
模型測試人員
業務利害關係人 MR
專案負責人 (資料科學負責人) R R, KVR R LAR MR
專案/產品擁有者 MR
平台技術支援 O O, KVA DOPCA O O O
模型終端使用者
CI/CD 程序 O O, KVA AcrPush DOPCA O O O
Machine Learning 工作區 R C C
監視處理序 R LAR MR
資料治理流程 R R R R R
預先生產環境
角色 Machine Learning 工作區 金鑰保存庫 Container Registry 儲存體帳戶 Azure DevOps Azure Artifacts Log Analytics 工作區 Azure 監視器
資料科學家 ADS R, KVA C C C C LAC MC
資料分析師 R C LAR MC
模型測試人員 R R, KVR R R R R LAR MR
業務利害關係人 R R R R R
專案負責人 (資料科學負責人) C C, KVA C C C C LAC MC
專案/產品擁有者 R R MR
平台技術支援 O O, KVA O O DOPCA O O O
模型終端使用者
CI/CD 程序 O O, KVA AcrPush O DOPCA O O O
Machine Learning 工作區 R, KVR C C
監視處理序 R R R R R R LAC
資料治理流程 R R R

注意

每個角色都會保留專案持續時間的存取權，但平台技術支援除外，其具有暫時或 Just-In-Time Microsoft Entra Privileged Identity Management (PIM 存取權。

RBAC 在保護及簡化 MLOps 工作流程方面扮演極重要角色。 RBAC 會根據指派的角色限制存取，並防止未經授權的使用者存取敏感資料，進而降低安全性風險。 敏感資料包括訓練資料或模型，以及重要的基礎結構，例如生產管線。 您可以使用 RBAC 以確保符合資料隱私權法規。 RBAC 也提供清楚的存取權和許可權記錄，可簡化稽核流程，讓您輕鬆識別安全性差距，並追蹤使用者活動。

套件管理

在 MLOps 生命週期中，各種套件、程式庫和二進位檔的相依性皆很常見。 這些相依性由社群開發且快速發展，通常需要主題專家知識才能正確使用和理解。 您必須確保適當的人員能夠安全存取各種資產，例如套件和程式庫，但也必須防止漏洞。 資料科學家在為機器學習解決方案組合特製化建置組塊時，會遇到這個問題。 傳統的軟體管理方法成本非常高，效率又差。 其他方法能提供更多價值。

若要管理這些相依性，您可以使用以隔離模式為基礎的安全、自助、套件管理處理序。 您可以設計此處理序，允許資料科學家從精心策劃的套件清單中自行提供服務，確保套件安全，且符合組織標準。

此方法包含安全列出三個業界標準機器學習套件存放庫：Microsoft 成品登錄、Python 套件索引 (PyPI) 和 Conda。 安全清單可從個別 Machine Learning 工作區自助。 然後在部署期間使用自動化測試程序來掃描產生的解決方案容器。 失敗會簡潔地結束部署程式，並移除容器。 下圖和處理序流程示範此處理序：

顯示安全 Machine Learning 套件方法的圖表。

程序流程

  1. 在具有網路組態的 Machine Learning 工作區中工作的資料科學家，可以從機器學習套件存放庫隨選自助機器學習套件。 其他所有專案都需要例外狀況處理序，方法是使用私人儲存體模式，這是透過使用集中式函式來植入和維護的。

  2. Machine Learning 以 Docker 容器的形式提供機器學習解決方案。 隨著這些解決方案的開發，這些解決方案會上傳至 Container Registry。 適用於容器的 Microsoft Defender 會產生容器映像的弱點評估。

  3. 解決方案部署會透過 CI/CD 處理序進行。 適用於 DevOps 的 Microsoft Defender 會跨堆疊使用，以提供安全性狀態管理和威脅防護。

  4. 只有在解決方案容器通過每個安全性處理序時才會部署。 如果解決方案容器未通過安全性處理序，部署會失敗，並出現錯誤通知和完整稽核記錄。 解決方案容器會遭捨棄。

先前的處理序流程可為資料科學家提供安全、自助、套件管理程序，並確保套件安全且符合組織標準。 若要平衡創新和安全性，您可以授與資料科學家在生產前環境中通用機器學習套件、程式庫和二進位檔的自助存取權。 對於較不通用的套件，需要例外狀況。 此策略可確保資料科學家在開發期間保持生產力，以避免在傳遞期間發生重大瓶頸。

為了簡化發行程序，請將環境容器化，以方便用於生產環境。 容器化環境可降低弱點掃描，並可確保持續的安全性。 此處理序流程提供可重複的方法，讓您跨使用案例使用到傳遞時間。 如此可降低在企業內建置和部署機器學習解決方案的整體成本。

監視

在 MLOps 中，監視對於維護機器學習系統的健全運作情況和效能至關重要，並確保模型保持有效且符合業務目標。 監視支援內部循環階段的治理、安全性和成本控制。 在外部迴圈階段部署解決方案時，能提供效能、模型降低和使用方式的可檢視性。 監視活動與角色相關，例如資料科學家、業務利害關係人、專案負責人、專案擁有者、平台技術支援、CI/CD 處理序和監視程序`。

根據您的 Machine Learning 工作區設定選擇您的監視和驗證平台，例如專案、小組或部門。

模型效能

監視模型效能，以儘早偵測模型問題和效能降低現象。 追蹤效能，以確保模型保持精確、可靠且符合業務目標。

資料漂移

資料漂移透過將模型輸入資料與模型的訓練資料，或最近的過去生產資料進行比較，以追蹤模型輸入資料分佈的變化。 這些變更是市場動態、特徵轉換變更或上游資料變更的結果。 這類變更可能會降低模型效能，因此請務必監視漂移以確保及時補救。 若要執行比較，資料漂移重構需要最近的生產資料集和輸出。

環境：生產
Azure 促進：Machine Learning – 模型監測

預測漂移

預測漂移會透過與驗證、測試標記或最近的生產資料比較，追蹤模型預測輸出分佈的變化。 若要執行比較，資料漂移重構需要最近的生產資料集和輸出。

環境：生產
Azure 促進：Machine Learning – 模型監測

資源

使用數個提供端點計量的模型以指出品質與效能，例如 CPU 或記憶體使用量。 這種方法可協助您從生產環境中學習，協助推動未來的投資或變更。

環境：全部
Azure 促進： 監視 - 線上端點計量

使用量指標

監視端點的使用方式，確保符合組織特定或工作負載特定的關鍵效能指標、追蹤使用模式，以及診斷和矯正使用者遇到的問題。

用戶端要求

追蹤模型端點的用戶端要求數目，以了解端點的作用中使用量設定檔，這可能會影響調整或成本最佳化的成效。

環境：生產
Azure 促進： 監視 - 線上端點計量，例如 RequestsPerMinute。 注意：

  • 您可以根據 T 恤大小或異常情況調整可接受的閾值，以滿足您的工作負載需求。
  • 從生產環境中淘汰不再使用的模型。
節流延遲

節流延遲會在資料傳輸的要求和回應中變慢。 節流會在 Resource Manager 層級和服務層級發生。 追蹤兩個層級的計量。

環境：生產
Azure 促進：

  • 監視 - 資源管理員，RequestThrottlingDelayMs、ResponseThrottlingDelayMs 的總和。
  • Machine Learning - 若要檢查端點要求的相關資訊，您可以啟用線上端點流量記錄。 您可以使用 Log Analytics 工作區來處理記錄。

注意：將可接受的閾值與工作負載的服務層級目標 (SLO) 或服務層級協定 (SLA) 和解決方案的非功能需求 (NFR) 調整成一致。

產生的錯誤

追蹤回應碼錯誤，協助測量服務可靠性，並確保服務問題的早期偵測。 例如，500 個伺服器錯誤回應突增，可能表示有需要立即注意的嚴重問題發生。

環境：生產
Azure 促進：Machine Learning - 啟用線上端點流量記錄以檢查您要求的相關資訊。 例如，您可以使用 ModelStatusCode 或 ModelStatusReason 檢查 XRequestId 的計數。 您可以使用 Log Analytics 工作區來處理記錄。
注意：

  • 400 和 500 範圍中的所有 HTTP 回應碼都歸類為錯誤。

成本最佳化

雲端環境中的成本管理和最佳化非常重要，因為它們可協助工作負載控制費用、有效率地配置資源，以及將其雲端服務的價值最大化。

工作區計算

當每月營運費用達到或超過預先定義的金額時，請根據工作區設定界限，產生警示以通知相關利害關係人，例如專案負責人或專案擁有者。 您可以根據專案、小組或部門相關界限來確定工作區設定。

環境：全部
Azure 促進： Microsoft 成本管理 - 預算警示
注意：

  • 根據初始 NFR 和成本估計值來設定預算閾值。
  • 使用多個閾值層。 多個閾值層級可確保利害關係人在超過預算之前收到適當的警告。 根據組織或工作負載，這些利害關係人可能包括業務潛在客戶、專案擁有者或專案潛在客戶。
  • 一致的預算警示也可能是重構以支援更高需求的觸發程序。
工作區過期

如果 Machine Learning 工作區不會根據預定使用案例的相關計算使用量顯示使用中現象，則如果指定專案不再需要工作區，專案擁有者可能會解除委任工作區。

環境：預先生產
Azure 促進：

注意：

  • 透過計數彙總，作用中核心數應等於零。
  • 將日期閾值與專案排程調成一致。

安全性

監視以偵測與適當安全性控制項和基準的偏差，確保 Machine Learning 工作區符合組織的安全性原則。 您可以使用預先定義和自訂定義原則的組合。

環境：全部
Azure 促進：Machine Learning 的 Azure 原則

端點安全性

若要了解關鍵業務 API，請實作所有 Machine Learning 端點的目標安全性監視。 您可以調查並改善 API 安全性態勢、排定弱點修正的優先順序，以及快速偵測作用中的即時威脅。

環境：生產
Azure 促進： 適用於 API 的 Microsoft Defender 會為 API 提供廣泛的生命週期保護、偵測和回應涵蓋範圍。 注意：適用於 API 的 Defender 會為在 Azure API 管理中發佈的 API 提供安全性。 您可以在適用於雲端的 Microsoft Defender 入口網站或 Azure 入口網站的 API 管理執行個體中加入適用於 API 的 Defender。 您必須將 Machine Learning 線上端點與 API 管理整合。

部署監視

部署監視可確保您所建立的任何端點都遵守您的工作負載或組織原則，且不受困於弱點。 此處理序會要求您在部署前後對 Azure 資源強制執行合規性原則、透過弱點掃描提供持續的安全性，並確保服務在運作時能符合 SLA。

標準與治理

監視以偵測與適當標準之間的偏差，確保您的工作負載遵守護欄。

環境：全部
Azure 促進：

注意：如需詳細資訊，請參閱 Machine Learning 法規合規性的 Azure 指引。

安全性掃描

在自動化整合及部署程序中實作自動化安全性掃描。

環境：全部
Azure 促進：適用於 DevOps 的 Defender
注意：您可以使用 Azure Marketplace 中的應用程式來擴充這個非 Microsoft 安全性測試模組的程序。

持續服務

監視 API 的持續服務，以取得效能最佳化、安全性和資源使用。 確保及時偵測錯誤、有效率的疑難排解，並且符合標準。

環境：生產
Azure 促進：

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

其他投稿人：

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

下一步