適用於 Azure 上 AI 工作負載的 MLOps 和 GenAIOps
AI 工作負載作業是以數據進行策展和取用該數據為中心。 作業可確保達到和維護您優先處理工作負載的品質、可靠性、安全性、道德和其他標準的效率。
工作負載工作可分為三個主要領域：應用程式開發、數據處理和 AI 模型管理。 每個類別都應該採用業界證明的操作方法，例如 DevOps、DataOps、MLOps和 GenAIOps。
DevOps 活動涵蓋整個 應用程式開發生命週期管理 ，透過自動化持續整合和持續部署 （CI/CD） 管線和監視。 不過，針對 AI 工作負載，數據管線是其中一個核心元件。 DataOps 是 DevOps 的特製化，其著重於 簡化數據擷取、轉換和載入等程式來管理數據生命週期 （ETL/ELT）。 DataOps 從業者通常會測量數據流效能，以及數據清理的效力，以及監視管線是否有異常狀況。
AI 工作負載本質上不具決定性。 許多 AI 模型很容易在推斷期間為相同的查詢產生不同的答案。 這些工作負載需要能夠管理和適應 AI 輸出不可預測性的程式。 DataOps 延伸至 MLOps，其 可運作機器學習工作流程 以進行模型定型和測試。 GenAIOps 是 MLOps 的特製化子集，以產生 AI 解決方案為目標。 它牽涉到模型探索和精簡預先定型模型與擴充數據等工作。
作業活動通常會重疊，而且不同的方法會套用到不同程度。 例如，在歧視 AI 中，DataOps 扮演主要角色，而 DevOps 活動則不太突出。 相反地，在產生的 AI 中，營運卓越比 DataOps 更依賴 DevOps。
不管怎樣，整體目標是在開發生命週期中以有效率的作業提供功能。 預期的結果如下：
- 具有一致結果的可重複進程。
- 經過一段時間的模型持續正確性。
- 將風險降到最低的有效治理。
- 變更適應模型漂移的管理程式。
自動化和監視是達成這些目標的關鍵作業策略 。
您也需要 為 AI 元件、例行、非計劃性及緊急作業建立標準化程式，並備妥適當的追蹤機制。 如果沒有這些程式，您就會執行下列風險：
- 數據處理、模型裝載、地面數據管理和其他工作中的重複錯誤和非重現性。
- 用於模型定型和精簡的低品質或過時數據。
- 影響使用者對系統的信心，在最壞的情況下導致法律、合規性或安全性問題。
您必須使用 正確的工具集來實作已建立的程式。 特製化工具可用於管理跨環境的 AI/機器學習工作流程。
本文著重於作業的設計策略，並提供工具建議。
建議
以下是本文所提供的建議摘要。
| 建議 | 描述 |
|---|---|
| 設計有效率的工作負載作業生命週期。 | 根據您的 AI 工作負載元件，不同的作業階段將套用至其生命週期。 請務必瞭解與案例相關的最佳做法，以及可供您實作這些最佳做法的工具。 花時間瞭解並實作工作負載所有元件的主要建議。 ▪ DataOps ▪ MLOps ▪ GenAIOps ▪ 監測 |
| 自動化所有專案。 | 自動化可確保工作負載生命週期的重複性和效率。 雖然 DevOps 程式是其中的重要參與者，但您需要採取其他步驟，以有效率地建置、測試、驗證及部署模型。 ▪ 自動化 |
| 盡可能利用部署管線。 | 部署管線可協助您提供可重複的基礎結構部署，或持續整合程序代碼。 它們也是建立和/或驗證模型，然後再將其提升至生產環境的絕佳工具。 實作部署管線可協助您改善工作負載的可靠性及整體用戶體驗。 ▪ 部署管線 |
| 防止模型中的漂移和衰變。 | 您必須防範模型衰變和漂移，同時具有結構化程式，可協助您以受控制的方式接受新的模型變更。 遵循模型維護的相關建議，可協助您保持合規、避免非預期的用戶體驗，並提供更最新的服務。 ▪ 模型維護 |
工作負載作業生命週期
此影像說明 AI 模型的作業階段，包括資料收集、清除數據以消除不一致或錯誤，以及將數據轉換成可分析的格式。 這些階段與定型辨別模型和產生模型中的基礎數據相關。 不過，此影像中並未描述定型產生模型的特定使用案例。 該使用案例超出本文的範圍。
MLOps 和 GenAIOps 的階段很類似。 主要差異在於，在 GenAIOps 的情況下，焦點會從定型轉向選取正確的模型、提示工程，以及透過微調或實作擷取增強產生（RAG）來納入領域特定知識。
即使是部署和監視的階段也相當類似。
下列各節說明常見的作業作法。 它們涵蓋生命週期的每個階段，從生產階段到生產階段。
DataOps
數據會從各種生產數據源匯總，然後預先處理以移除錯誤和不一致，以及處理遺漏值。 最後，它會轉換成適合用於定型或擴充的格式，並將其正規化。 設計的各個層面會描述於定型數據和地面數據文章中。
此階段中的數據作業程序應該有效率，因為 處理來自多個來源和複雜數據管線的大量數據 可能會很困難。 您必須採取的方法，以確保此階段 會產生高質量的數據。 監視此階段，以追蹤可接受的品質列進度。
您也必須確定數據是安全的，因為數據來自生產環境。 請確定開發/測試等較低環境與生產環境一樣安全，以協助防止任何安全性問題。
注意
在初始階段投資大量數據清理，以解決品質不佳的數據。 利用已知分析模式，例如獎章、數據網格和功能存放區，來執行上游處理工作。 如果上游階段無效，您必須在下游階段改善品質，這會導致工作負載成本增加，因為數據準備會在每個階段進行。
如需數據處理工作的相關信息，請參閱下列文章：
工具
建議您標準化工作負載的數據協調流程工具。 這些工具應該能夠提供可分組活動且具有內建自動化的數據管線。
Azure Data Factory 管線可以是初始選擇。 它可以有效率地連線及處理許多數據源。 您也可以考慮 Azure Synapse Analytics，其結合了巨量數據和數據倉儲，並支援 Data Lake、Apache Spark 和 Azure Synapse SQL。 它也與 Data Factory for ETL 整合。
為了準備定型數據，Azure 機器學習 管線提供特殊功能，可將數據收集和處理等工作自動化。
如 Pandas（用於數據準備）和報廢等開放原始碼技術是熱門選擇。
MLOps
模型定型是選取適當演算法的程式，並提供預先處理的歷程記錄數據和觀察，讓模型能夠學習模式並進行預測。
定型模型（特徵工程）和超參數微調是反覆的程式，而且成本很高。 在每個反覆專案期間，數據科學家會使用數據、程式代碼和參數的組合來追蹤結果。 使用可重複的管線，以最少的手動努力追蹤實驗 ，直到達到正確的精確度層級為止。
另一個作業挑戰是布建和調整 進行實驗的特製化計算資源 。 此外，您應該 有效率地封裝和發佈模型 。
Teams 可以從UI型開發開始，以減少挑戰，而且隨著挑戰變得更自信，轉換為以程式代碼為基礎的方法。
工具
建議您使用可 藉由擷取程式代碼版本、環境、參數、執行和結果等詳細數據來追蹤機器學習實驗 的工具。 MLflow 是一個這類開放原始碼架構。 請考慮使用與 MLflow 相容的 Azure 機器學習 工作區，並提供簡化的工作流程，讓數據科學家能夠管理其專案中的生產力和重現性。 若要使用原始檔控制追蹤來管理程式碼開發，請將機器學習管線與 GitHub 等原始檔控制整合，或使用檔案共用。
裝載計算也可以影響您所選擇的工作流程協調器。 如果您的應用程式裝載在 Azure Kubernetes Service （AKS），請考慮使用 Kubeflow。
如果您考慮 Azure 機器學習，建議您從 Azure 架構良好的架構觀點開始，機器學習，以確保您了解產品如何協助您解決工作負載的架構良好架構質量考慮。
程式的一部分優點是將個人時間優化。 數據科學家通常需要特定的工具和 SDK，才能從工作站有效地進行探勘數據分析（EDA）和實驗。 評估 Azure 機器學習 中預先建置的選項是否合適。 如果沒有，請儲存工作站設定，或維護此工作的已核准 VM 映射。 您可以作為起點使用的映像範例之一是 資料科學虛擬機器 （DSVM） 。
在某些情況下，原則可能會不允許使用 VM。 尋找替代方案，例如新增 Microsoft Dev Box 和 Azure 虛擬桌面。 您也可以考慮使用 Docker 來啟動包含預先建置映像的機器。
不過，當這個階段成熟且您需要擴充實驗時，請移至受控計算實例，並偏好將整合為工作流程的一部分的選項。 評估您是否可以使用 Azure 機器學習 計算實例來進行開發和測試的定型和推斷。 計算叢集可以處理大型數據集和複雜模型。
Azure 機器學習 透過 SDK 和低程式代碼選項提供程式碼型解決方案，例如自動化機器學習和可視化設計工具。 Python SDK 提供多種方式來定型模型，每個模型都有不同的功能。 機器學習 也支援進階優化和分散式運算技術，例如 ONNX 運行時間訓練的 ORTModule、DeepSpeed 和 LoRA，以加速定型程式。
GenAIOps
此階段的主要活動從 探索和評估現有的模型 開始，以識別預先定型的特定使用案例。 這是反覆的程式。 找到適合的模型之後，可能會受益於針對領域特定基礎進行精簡，這也牽涉到反覆步驟，而且需要特定層級的協調流程。
整合和部署模型需要超越傳統 MLOps 功能的特殊工具和做法，包括協調模型、向量索引、提示和程式碼區塊。
工具
若要解決探索工作，請利用包含來自各種提供者之模型的模型目錄。 Azure AI Studio 中的模型目錄可讓您從策劃的集合中評估，並有效率地部署模型。
Azure 機器學習 提示流程可協助開發協調流程程式代碼、啟用原型設計、實驗、反覆運算和提示工程。 這些流程可以部署到 Azure 機器學習 受控端點。 評估您是否可以使用現有的 CI/CD 管線技術來執行和部署流程。
部署
在此階段中，模型會部署到裝載和推斷平臺或 AI 工作負載服務層。 API 必須封裝為可調整的容器。 容器平臺可以是受控計算或自定義裝載平臺。 作業做法應確保安全部署並啟用復原。
從平臺即服務 （PaaS） 和無伺服器解決方案開始，例如 Azure OpenAI 服務，以簡化採用和管理。 請考慮使用 Azure 機器學習 無伺服器 API 來匯總端點存取。 受控計算叢集是進階需求的可行選項。 AKS 上的自我裝載是另一個選項。 請確定您的計算大小正確，並維持與其他工作負載的適當隔離。 您也可以考慮將模型完全裝載為基礎結構即服務的選項（IaaS）。 IaaS 提供彈性，但可以增加作業負擔。 這些選項會在應用程式平台中說明。
此階段提供將模型移至生產環境之前攔截問題的最後機會。 測試程式應該包含驗證步驟，以確保模型已設定為如預期般提供預測。
您應該遵循 漸進式曝光程式並使用並存部署，將模型整合到現有的生產環境。 Canary 模型是推出新模型的常見方式。 使用此方法時，使用者基底會逐漸增加。 藍綠部署是另一種方法。
工具
您可以使用 Azure 機器學習 管線或 Azure Pipelines 來部署模型以進行推斷。 機器學習 提供數個簡化作業的功能，包括節點布建、OS 更新、自動調整、監視和隔離的虛擬網路。
機器學習 也支援藍綠部署，允許單一端點包含多個部署。
如果您使用其他裝載平臺，例如 Azure Container Apps 或 Azure App 服務，您必須負責作業，包括布建和調整。 在這些情況下，請使用 Azure DevOps、GitHub 管線或您選擇的 CI/CD 技術。
監視
監視是一項關鍵策略，而且會在所有階段套用。 這是一個持續的過程，並可作為品質網關的輸入，以確保 AI 工作負載經過嚴格測試，以在整個開發生命週期中維持一致性和可靠性。 模型必須從操作和數據科學的觀點進行監視。
強烈建議您有 DataOps 內部循環監視程式，可測量接近驗收品質列的鄰近性，並檢查異常狀況。
對於預先定型的模型，監視數據漂移和效能也很重要，主要著重於相關性。 評估輸入（提示）和輸出（完成），以確保它們相關且準確。 此外，請注意安全性風險，例如嘗試透過惡意提示操作模型的行為。 請確定有徹底的缺點 帳篷模式 檢查雙向數據，並篩選出不適當的內容。 這些考慮會在 ResponsibleAI 設計區域中說明。
部署之後，需要監視作業來解決模型衰變之類的問題。 模型可能會因為數據變更或外部變更而過時，導致模型產生不相關的結果。 作為主動式量值，請使用自動化程式進行持續監視，並評估及重新定型，以維持精確度和相關性。 此外，您需要監視基礎結構和工作負載計量，就像使用任何其他工作負載一樣，以協助確保最佳效能和可靠性。 如需詳細資訊，請參閱 測試模型衰變。
工具
投資工具，以便更輕鬆地從推斷端點收集計量，例如 Azure 機器學習 數據收集器。
您也需要模型效能、數據漂移，以及產生 AI 的安全性和品質的可觀察性。
如需詳細資訊，請參閱下列文章：
自動化
AI 工作負載很複雜，因為整體生命周期牽涉到許多角色、頻繁變更和相互關聯的步驟。 手動程式很容易發生錯誤和不一致。 數據處理模型裝載中的自動化有助於確保 可重複性和效率。 自動化並非總是必要，但這是管理這些複雜度的有效方式。 以下是一些自動化可以降低風險的使用案例：
與傳統程式代碼部署不同，AI/機器學習中的非決定性模型和解決方案需要反覆的實驗和定型。 當多個小組共同作業、自動化時，以強制執行標準化程式的方式，可協助維護數據科學家、工程師和作業小組之間的一致性、重現性和有效共同作業。
模型生命週期牽涉到兩種主要類型的定型：
在線定型會經常將最近的數據併入模型，有時每天，以確保決策是以最新資訊為基礎。 此定型會整合到工作負載中，讓模型在一般程式中持續更新。
離線定型會較不頻繁地定型模型，以在更新之間產生較長的差距。 定型程式與主要工作負載分開，並以異步方式完成。 新的模型準備就緒之後，即會整合至系統。
如果更新不常發生，可靠性可能會遭到入侵。 如果遺漏更新，可能會延遲，而不會發生重大問題。 此概念也適用於基礎數據。 例如，如果您使用RAG，則必須決定是否需要使用最近的數據，或稍微舊的數據是否足夠。 這兩種案例都牽涉到平衡最新資訊的需求與更新頻率的實際性。 您應該透過自動化執行在線訓練，因為需要的頻率和可靠性。 針對離線訓練，因為需要的頻率，您需要藉由執行成本效益分析來證明自動化的合理性。 此外，您可以使用成本較低的資源來執行離線訓練，例如離線硬體。
傳統的DevOps程式通常會受到結構變更的影響。 不過，在 AI 和機器學習中，模型會根據生產數據定型。 模型衰變會造成重大風險，如果未受到監視，可能會導致效能隨時間降低。 需要自動收集和分析效能計量、警示和模型重新定型，才能維持模型效力。 使用自動化的方式可協助您 偵測數據與模型相依性的 變更，以隨時清楚瞭解目前的狀態。
模型可以使用兩種不同的方法來定型。
- 模型會以完整的生產數據 在開發環境中定型，而且只會透過環境升級成品。 這種方法可以降低計算成本，但需要更嚴格的安全性來處理較低環境中的生產數據，而且可能不可能在所有組織中執行。
- 模型會在每個環境中定型。 程式代碼升級可能有助於穩定性，因為訓練程式代碼是在較低環境中檢閱和測試，但會增加計算成本。
這兩種方法各有利弊。 選擇正確的方法取決於您組織的優先順序和工作負載的軟體開發生命週期 （SDLC） 做法。 不論方法為何，在生產部署之前對模型進行徹底測試和評估都是不可或缺的
您的自動化程式代碼應 納入數據譜系，以提供清楚的數據處理階段記錄來支援稽核性 。 此記錄可協助您管理期望，並讓您示範決策的制定方式，以便解決任何對結果的擔憂。
部署管線
在 AI /機器學習工作負載中，模型開發牽涉到 建立、驗證及將模型提升至模型 裝載平臺。 請務必讓部署管線簡化與數據處理、特徵工程、模型定型或擴增相關的複雜工作流程，以及部署到生產環境。 假設 AI 具有不具決定性的本質，讓流程變得不透明，您必須 在發行管線 和監視系統中納入定性測試。
雖然 MLOps 和 GenAIOps 可能需要不同的 AI 活動和核心技術，但基礎概念仍與 DevOps 的概念類似。 建議您從現有的 DevOps 程式套用最佳做法。 將 AI 活動整合到您工作負載的現有管線中。
一般而言，AI 工作負載牽涉到傳統的程式代碼部署。 您可以選擇與程式代碼一起處理模型部署，或在自己的生命週期中個別處理。 較佳的做法。 準備使用工作負載部署來封裝模型和推斷端點，讓 AI 作業主要著重於數據準備、定型/微調、基礎數據管理和監視。
重新評估下列資產如何量身打造，以涵蓋整個 MLOps 和 GenAIOps 生命週期，從生產階段到生產環境：
- 基礎結構即程序代碼 （IaC） 工具
- CI/CD 管線
- 追蹤和識別問題的可觀察性堆疊
工具
您可以將通常用於 CI/CD 的 Azure Pipelines 和 GitHub Actions 工作流程延伸至機器學習模型。 它們可協助部署機器學習基礎結構、自定義工作負載元件、協調流程程式代碼和模型。 將 Azure 機器學習 管線與 Azure DevOps 或 GitHub 管線結合。 如需詳細資訊，請參閱搭配使用 Azure Pipelines 搭配 Azure 機器學習。
兩個主要因素會影響您選擇正確的工具組合：使用案例和功能。 例如，Azure 機器學習 管線非常適合數據科學家所執行的協調流程。 它具有豐富的功能集，可支援重複使用、快取等等。 如需工具選擇，請參閱 我應該使用哪個 Azure 管線技術？。
模型維護
AI/ML 環境具有持續創新競爭力。 新模型經常出現，探索新的使用案例，並可使用新的數據源。 因此，模型衰變是常見的挑戰。
若要防止模型效能降低或隨著時間漂移，您必須實作自動化程式以進行持續監視、評估和重新定型。 例如：
維護模型目錄。 自動化探索新模型和更新目錄的程式。
適應新的使用案例。 隨著新的使用案例新增至工作負載需求，請預期查詢並據以調整數據處理邏輯。
併入新的數據源。 如果新的數據源可能會增強模型的預測能力或相關性，請更新數據擷取管線以連線至這些來源並從中提取數據。
評估法規需求的合規性。 當您適應新功能時，請確定變更在組織或外部合規性標準的限制內保持有效。
實作追蹤持續改善的正式程式，並將自我改進納入該週期內的子流程。
持續演進
定期檢閱和改進作業，並鼓勵創新。
MLOps 成熟度模型會從手動程序進行到完全自動化。 從手動建置和監視開始，並納入自動化應用程式組建、定型環境，以及依完整計量合理進行階段的部署。 如需詳細資訊，請參閱 MLOps 成熟度模型。
GenAIOps 成熟度層級會從基本模型移至結構化部署，以漸進方式使用自動化優化技術。 如需詳細資訊，請參閱 進階 GenAIOps 的成熟度層級。