面向 MLOps 從業者的 GenAIOps
本指南適用於已投投入並想擴大 MLOps 投資，以將生成式 AI 納入其工作負載的工作負載團隊 要實作生成式 AI 工作負載，您需要使用 GenAIOps (有時狹義地稱為 LLMOps) 來擴展您的 MLOps 投資。 本文概述了傳統機器學習和生成式 AI 工作負載之間常見的技術模式，以及生成式 AI 的特定模式。 本文可協助您了解可以在哪些方面應用現有的營運投資以及需要在哪些方面擴展這些投資。
生成式 AI 技術模式
生成式 AI 工作負載與傳統機器學習工作負載在以下幾個方面有所不同：
專注於生成模型 - 傳統的機器學習工作負載集中於訓練新模型，這些模型經過訓練以執行特定任務。 生成式 AI 工作負載使用生成模型，這些模型可用於解決更廣泛的使用案例，並且在某些情況下是多模式的。
專注於擴展模型 - 傳統機器學習的關鍵資產是部署的模型。 向一個或多個工作負載中的用戶端程式碼提供對模型的存取權限，但該工作負載不是 MLOps 流程的一部分。 對於生成式 AI 解決方案，解決方案的關鍵方面是向生成模型提供提示。 該提示必須是組合的，並且可以包含來自一個或多個資料儲存的資料。 編排邏輯、呼叫各種後端、產生提示以及呼叫生成模型的系統是生成式 AI 系統的一部分，您必須使用 GenAIOps 來管理該系統。
雖然一些生成式 AI 解決方案使用傳統的機器學習實踐 (例如模型訓練和微調)，但它們都引入了您應該標準化的新模式。 本節概述了生成式 AI 解決方案的三大類技術模式：
- 預訓練和微調
- 提示工程
- 擷取增強生成 (RAG)
訓練和微調語言模型
目前，許多生成式 AI 解決方案使用現有的基礎語言模型，在使用前不需要進行微調。 也就是說，有些使用案例可以而且確實受益於微調基礎模型或訓練新的生成式 AI 模型，例如小語言模型 (SLM)。
訓練新的 SLM 或微調生成基礎模型在邏輯上與訓練傳統機器學習模型的流程相同。 這些流程應使用您現有的 MLOps 投資。
提示工程
提示工程包括產生提示 (作為生成模型的輸入) 所涉及的所有流程。 通常有一個協調器來控制產生提示的工作流程。 協調器可以呼叫任意數量的資料儲存來收集資訊 (例如基礎資料)，並應用所需的邏輯來產生最有效的提示。 然後，編排器被部署為 API 端點，可由智慧型應用程式中的用戶端程式碼存取。
圖 1. 即時的工程架構
此類技術模式可以解決許多使用案例，包括：
- 分類
- 翻譯
- 摘要
- 擷取增強生成，將在下一節中討論
擷取增強世代
擷取增強生成 (RAG) 是一種使用即時工程的架構模式，其目標是使用領域特定資料作為語言模型的基礎資料。 語言模型是針對一組特定的資料進行訓練的。 您的工作負載可能需要對特定於您的公司、客戶或網域的資料進行推斷。 使用 RAG 解決方案，系統會查詢您的資料，並將結果作為提示的一部分提供給語言模型，通常是透過編排層。
常見的 RAG 實作是將文件分解為區塊並將它們與中繼資料一起儲存在向量儲存中。 向量儲存 (例如 Azure AI 搜尋服務) 可讓您執行文字和向量相似性搜尋以傳回上下文相關的結果。 RAG 解決方案還可以使用其他資料儲存來傳回接地資料。
圖 2. 擷取增強生成 (RAG) 架構
擴展 MLOps 以實現生成 AI 技術模式
在本節中，我們將研究生成式 AI 技術模式的內循環和外循環階段的以下關鍵方面，以了解您可以在哪裡應用現有的 MLOps 投資以及在哪裡需要擴展它們：
DataOps
MLOps 和 GenAIOps 都使用 DataOps 的基礎知識來建立可擴展和可重複的工作流程，以確保正確清理、轉換和格式化資料以進行實驗和評估。 工作流程可重複性和資料版本控制是所有技術模式的 DataOps 的重要功能，而資料的來源、類型和意圖則依賴模式。
培訓和微調
此技術模式應充分利用您在 MLOps 實作流程中所做的現有 DataOps 投資。 再現性和資料版本控制可讓您試驗不同的特徵工程資料、比較不同模型的效能並再現結果。
RAG 與即時工程
RAG 解決方案中資料的目的是提供基礎資料，作為提示的一部分呈現給語言模型。 RAG 解決方案通常需要將大型文件處理成大小合適、語義相關的區塊的集合，並將這些區塊保存在向量儲存中。 有關詳細資訊，請參閱設計和開發 RAG 解決方案。 RAG 解決方案的再現性和資料版本控制可讓您嘗試不同的分塊和嵌入策略、比較效能並回滾到先前的版本。
用於分塊文件的資料管線不是傳統 MLOps 中 DataOps 的一部分，因此您必須擴展架構和操作。 資料管線可以從多個不同的來源讀取結構化和非結構化資料。 他們也可以將轉換後的資料寫入不同的目標。 您必須擴展您的架構以包含用於基礎資料的資料儲存。 這些模式的常見資料儲存是向量存儲，例如 Azure AI 搜尋服務。 與訓練和微調一樣，您可以利用 Azure 機器學習管線或其他資料管線工具來編排分塊階段。 您可以利用 Azure Machine Learning 管線中的提示流程以一致且可重複的方式處理和豐富資料。 您還必須擴展操作以保持資料儲存中搜尋索引的新鮮度和有效性。
測試
作為內循環的一部分，實驗是建構、評估 (在下一節中介紹) 和完善解決方案的迭代流程。 以下部分討論常見生成式 AI 技術模式的實驗。
培訓和微調
在微調現有語言模型或訓練小型語言模型時，您可以利用目前的 MLOps 投資。 例如，Azure 機器學習管線提供了一個強大的工具包，可以有效率且有效地進行實驗。 這些管線可讓您管理整個微調流程，從資料預先處理到模型訓練和評估。
RAG 與即時工程
快速工程和 RAG 工作負載的試驗需要擴展您的 MLOps 投資。 對於這些技術模式，工作量並不會隨著模型而結束。 您的工作負載需要一個協調器，該系統知道如何執行邏輯、調用資料儲存以獲取所需資訊 (例如基礎資料)、生成提示、調用語言模型等。 資料儲存和儲存中的索引也是工作負載的一部分。 您的營運必須擴展以管理工作負載的這些方面。
提示工程解決方案有多個維度可供實驗，包括不同的指令、角色、範例、限制和提示連結等先進技術。 當您嘗試 RAG 解決方案時，還需要嘗試其他領域，包括以下領域：
- 分塊策略
- 你應該豐富哪些內容以及如何豐富內容區塊
- 您的嵌入模型
- 搜尋索引的設定
- 要執行的搜尋專案（向量、全文檢索、混合式等等）
正如 DataOps 中所討論的，實驗的關鍵是可重複性和資料版本控制。 良好的實驗架構可讓您儲存輸入 (例如對超參數或提示的變更) 以及評估實驗時要使用的輸出。
與現有的 MLOps 環境一樣，您可以利用 Azure 機器學習管線等架構。 Azure 機器學習管線具有支援索引、與 Azure AI 搜尋服務等向量儲存整合的功能。 您的 GenAIOps 環境可以利用管線的這些功能，並將它們與管理提示工程和自訂預先處理邏輯的提示流程功能結合。
評估與實驗
評估是建構、評估和完善解決方案的迭代實驗流程的關鍵。 對變更的評估為您提供了進行改進或驗證當前迭代是否滿足您的要求所需的回饋。 以下部分討論了常見生成 AI 技術模式的實驗階段的評估。
培訓和微調
經過微調或訓練的生成式 AI 模型的評估應利用您現有的 MLOps 投資。 例如，如果使用 Azure Machine Learning 管線來編排機器學習模型訓練，則可以利用相同的評估功能來微調基礎語言模型或訓練新的小語言模型。 這些功能包括利用評估模型組件來計算特定模型類型的行業標準評估指標並比較模型之間的結果。
RAG 與即時工程
您必須擴展現有的 MLOps 投資來評估生成式 AI 解決方案。 您可以利用提示流程等工具來提供強大的評估架構。 提示流程使團隊能夠定義自訂評估邏輯，指定標準和指標來評估各種提示變體和語言模型 (LLM) 的表現。 這種結構化方法允許並排比較不同的設定，例如超參數微調或架構變化，以確定特定任務的最佳設定。
提示流程中的作業會自動擷取整個實驗流程中的輸入和輸出資料，以建立全面的試驗記錄。 透過分析這些資料，您可以獲得見解並確定有前途的設定，這些設定可以為未來的迭代提供資訊。 您可以透過使用提示流程進行高效、系統化的實驗來加速生成式 AI 解決方案的開發。
無論生成式 AI 解決方案的使用案例為何 (例如分類、摘要、翻譯甚至 RAG)，實驗流程都是相同的。 重要的區別在於您用來評估不同使用案例的指標。 以下是您應根據使用案例考慮的一些指標範例：
- 翻譯：BLEU
- 總結：ROUGE。 BEU、BERTcore、METEOR
- 分類：精確率、召回率、準確率、交叉熵
- RAG：基礎性、相關性
注意
有關評估語言模型和 RAG 解決方案的更多資訊，請參閱 LLM 端到端評估。
一般來說，生成式 AI 解決方案將機器學習團隊的職責從訓練模型擴展到提示工程和管理接地資料。 由於即時工程和 RAG 實驗和評估不一定需要資料科學家，因此很容易與其他角色 (例如軟體工程師和資料工程師) 一起執行這些功能。 當您忽略資料科學家嘗試快速工程和 RAG 解決方案時，您將遇到挑戰。 其他角色通常不會像許多資料科學家那樣接受如何科學評估結果的訓練。 閱讀由七部分組成的文章系列設計與開發 RAG 解決方案，以了解設計生成式 AI 解決方案的複雜性。
投資生成式 AI 解決方案可以減輕資料科學資源的一些壓力。 軟體工程師的作用在這些解決方案中不斷增強。 例如，軟體工程師是管理生成式 AI 解決方案中的編排責任的重要資源，他們擅長在提示流程等工具中設定評估指標。 重要的是，這項工作必須在資料科學家的監督下完成。 資料科學家接受過培訓並擁有經驗，可以了解如何正確評估實驗。
部署
一些生成式 AI 解決方案涉及部署客製化訓練模型或微調現有模型，而其他解決方案則不然。 生成式 AI 解決方案增加了部署協調器和任何資料儲存的額外責任。 以下部分討論常見生成式 AI 技術模式的部署。
培訓和微調
部署生成式 AI 模型和微調基礎模型應使用您現有的 MLOps 投資，並進行一些可能的調整。 例如，為了微調 Azure OpenAI 中的大型語言模型，您需要確保訓練和驗證資料集採用 JSONL 格式，並且需要透過 REST API 上傳資料。 您還需要建立一個微調作業。 部署經過訓練的小語言模型可以利用您現有的 MLOps 投資。
RAG 與即時工程
對於 RAG 和提示工程，您還需要部署其他問題，包括編排邏輯、對資料儲存 (例如索引或架構) 的變更以及資料管線邏輯的變更。 編排邏輯通常封裝在提示流程、語意核心或 LangChain 等架構中。 您可以將 Orchestrator 部署到不同的運算資源，包括您目前可能部署自訂模型的來源。 如需將提示流程部署至 Azure 機器學習 受控在線端點或 Azure App 服務 的範例，請參閱基準 Azure OpenAI 端對端聊天參考架構。 為了部署到 Azure 應用程式服務，基準 Azure OpenAI 聊天體系架構將流程及其相依性打包為容器，這種做法提高了不同環境之間的可移植性和一致性。
資料庫資源的變更 (例如資料模型或索引的變更) 的部署是需要在 GenAIOps 中處理的新職責。 使用大型語言模型時的常見做法是在 LLM 之前使用閘道。
許多使用平台託管語言模型的生成式 AI 架構 (例如 Azure OpenAI 提供的語言模型) 都包含 Azure API 管理等閘道。 閘道使用案例包括負載平衡、身份驗證、監控等。 閘道可以在部署新訓練或微調的模型中發揮作用，使您能夠逐步推出新模型。 使用閘道以及模型版本控制可以讓您在部署變更時最大限度地降低風險，並在出現問題時回滾到先前的版本。
生成式 AI 特定問題 (例如協調器) 的部署應遵循正確的操作程序，例如：
- 嚴格的測試，包括單元測試
- 整合測試
- A/B 測試
- 端對端測試
- 推出金絲雀或藍/綠部署等策略
由於生成式 AI 應用程式的部署職責不僅僅是模型部署，因此您可能需要其他工作角色來管理使用者介面、編排器和資料儲存等內容的部署和監控。 這些角色通常與 DevOps 工程師技能集一致。
推斷和監控
推斷是將輸入傳遞給經過訓練和部署的模型，然後產生反應的流程。 您應該從三個角度監控傳統機器學習和生成式 AI 解決方案：營運監控、從生產中學習和資源管理。
營運監控
執行監控關注的是觀察系統的持續執行，包括資料操作 (DataOps) 和模型訓練。 您正在尋找偏差，包括錯誤、錯誤率的變化以及處理時間的變化。
對於模型訓練和微調，您通常觀察的操作流程是圍繞處理特徵資料、模型訓練和微調的資料操作。 對這些內循環問題的監控應使用您現有的 MLOps 和 DataOps 投資。
為了在生成式 AI 解決方案中進行快速工程，您還需要考慮額外的監控問題。 您必須監視處理接地資料或用於產生提示的其他資料的資料管線。 此處理可能包括資料儲存操作，例如建置或重建索引。
從生產中學習
推斷階段監控的一個關鍵面向是從生產中學習。 對傳統機器學習模型的監控會追蹤準確度、精確度和召回率等指標。 一個關鍵目標是防止預測漂移。 使用生成模型進行預測的解決方案 (例如使用 GPT 模型進行分類) 應使用現有的 MLOps 監控投資。
使用生成模型對基礎資料進行推斷的解決方案使用基礎性、完整性、利用率和相關性等指標。 目標是確保模型完全回答查詢並基於其上下文做出回應。 在這裡，您要防止資料漂移等問題。 您希望確保為模型提供的基礎資料和提示與使用者查詢最大程度地相關。
使用生成模型執行非預測任務的解決方案 (例如 RAG 解決方案) 通常受益於人類回饋來評估終端使用者的有用情緒。 使用者介面可以擷取諸如贊成/反對之類的回饋，並且該資料可用於定期評估回應。
生成式 AI 解決方案的常見模式是在生成模型前面部署閘道。 閘道的使用案例之一是用於監控基礎模型。 閘道可用於記錄輸入提示和輸出。
監控生成解決方案的另一個關鍵領域是內容安全。 目標是調節反應並偵測有害或不良內容。 Azure AI 內容安全工作室是可用於審核內容的範例工具。
資源管理
對於使用作為服務公開的模型 (例如 Azure OpenAI) 的生成解決方案，其資源管理問題與您自己部署的模型不同。 您不關心基礎設施，而是關心服務運輸量、配額和限制。 Azure OpenAI 使用標記的概念進行計費、限制和配額。 您應該監控配額使用情況以進行成本管理和效能效率。 Azure OpenAI 可讓您記錄標記使用情況。
工具
許多 MLOps 從業者已經標準化了一個工具包來組織圍繞自動化、追蹤、部署、實驗等的各種活動，以抽像出這些流程的許多常見問題和實作細節。 一個常見的統一平台是 MLflow。 在尋找支援 GenAIOps 模式的新工具之前，您應該查看現有的 MLOps 工具來評估其對生成 AI 的支援。 例如，MLflow 支援語言模型的廣泛功能。
MLOps 和 GenAIOps 成熟度模型
在目前的 MLOps 投資中，您可能已使用 MLOps 成熟度模型 來評估機器學習作業和環境的成熟度。 當您擴展對生成型 AI 工作負載的 MLOps 投資時，您應該使用 GenAIOps 成熟度模型來評估這些操作。 您可能會嘗試將這兩種成熟度模型結合起來，但我們建議單獨衡量每個模型。 MLOps 和 GenAIOps 將相互獨立發展。 舉例來說，您在 MLOps 成熟度模型中可能處於第四級，但剛開始使用生成式 AI，可能只處於第一級。
摘要
當您開始擴展 MLOps 投資以納入生成式 AI 時，重要的是要了解您不需要重新開始。 您可以將現有的 MLOps 投資用於某些產生的 AI 技術模式。 微調生成模型就是一個很好的例子。 生成式 AI 解決方案的某些領域，例如即時工程和 RAG，是全新的流程，您將必須擴展現有的營運投資並獲得新技能。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
- Paulo Lacerda | 雲端解決方案架構師 - Microsoft
- Marco Aurelio Cardoso | 資深軟體工程師 - Microsoft
- Luiz Braz | 高級技術專家 - Microsoft
- Ritesh Modi | 首席軟體工程師 - Microsoft
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。