面向 MLOps 從業者的 GenAIOps
本文為擁有現有機器學習作業（MLOps）投資的工作團隊提供指引，幫助他們擴充這些投資，將生成式 AI 包含於其工作負載中。 若要讓產生式 AI 工作負載運行，您必須以產生式 AI 運營（GenAIOps，有時也稱為 LLMOps）來擴展您的 MLOps 投資。 本文概述傳統機器學習和產生 AI 工作負載通用的技術模式，以及產生 AI 的特定模式。 本文可協助您瞭解在哪些方面將現有投資操作具體化，以及在哪些方面需要擴充這些投資。
生成式 AI 技術模式
生成式 AI 工作負載與傳統機器學習工作負載在以下幾個方面有所不同：
專注於生成模型。 傳統的機器學習工作負載著重於定型以執行特定工作的新模型。 生成式 AI 工作負載會使用可解決更廣泛各種使用案例的生成模型，而在某些情況下是多模式的。
專注於擴充模型。 傳統機器學習中的主要資產是已部署的模型。 模型的存取權會提供給一或多個工作負載中的用戶端程序代碼，但工作負載不是 MLOps 程式的一部分。 使用生成式 AI 解決方案時，解決方案的一個關鍵面向是提供給生成模型的提示。 該提示必須是組合的，並且可以包含來自一個或多個資料儲存的資料。 編排邏輯、呼叫各種後端、產生提示以及呼叫生成模型的系統是生成式 AI 系統的一部分，您必須使用 GenAIOps 來管理該系統。
雖然某些衍生式 AI 解決方案使用傳統機器學習做法，例如模型定型和微調，但它們都會引進您應該標準化的新模式。 本節概述了生成式 AI 解決方案的三大類技術模式：
- 預訓練和微調
- 提示工程
- 擷取增強生成 (RAG)
訓練和微調語言模型
目前，許多生成式 AI 解決方案使用現有的基礎語言模型，在使用前不需要進行微調。 不過，某些使用案例可以受益於微調基礎模型或定型新的產生 AI 模型，例如小型語言模型（SLM）。
訓練新的 SLM 並微調產生基礎模型，在邏輯上與定型傳統機器學習模型的程式相同。 這些流程應使用您現有的 MLOps 投資。
提示工程
提示工程包含產生提示時所涉及的所有程式，該提示會以輸入的形式傳送至產生模型。 通常有一個協調器來控制產生提示的工作流程。 協調器可以呼叫任意數目的數據存放區來收集資訊，例如地面數據，並套用必要的邏輯來產生最有效的提示。 接著，協調器會部署為智慧應用程式中由客戶端代碼存取的 API 端點。
以下示意圖顯示提示工程的架構。
此類技術模式可以解決許多使用案例，包括：
- 分類。
- 譯本。
- 綜述。
- 檢索增強生成技術，將在下一節會討論。
擷取增強世代
檢索增強生成（RAG）是一種架構模式，透過提示工程將特定領域數據作為語言模型的基礎數據。 語言模型是針對一組特定的資料進行訓練的。 您的工作負載可能需要對公司、客戶或網域特定的數據進行推理。 在RAG解決方案中，系統會查詢您的資料，並將結果提供給語言模型作為提示的一部分，通常是透過協調流程層。
常見的 RAG 實作是將文件分解為區塊並將它們與中繼資料一起儲存在向量儲存中。 向量儲存 (例如 Azure AI 搜尋服務) 可讓您執行文字和向量相似性搜尋以傳回上下文相關的結果。 RAG 解決方案還可以使用其他資料儲存來傳回接地資料。
下圖說明 RAG 架構：
擴展 MLOps 以實現生成 AI 技術模式
本節說明產生式 AI 技術模式內部循環和外部循環階段的下列主要方面，並協助您瞭解現有的 MLOps 投資可以應用於哪些領域，以及需要在哪些方面進行擴充：
DataOps
MLOps 和 GenAIOps 都套用 DataOps 的基本概念，以建立可延伸且可重現的工作流程，以確保正確清除、轉換和格式化數據以進行實驗和評估。 工作流程重現性和數據版本控制是所有技術模式的 DataOps 重要功能。 數據的來源、類型和意圖相依於模式。
訓練和微調
此技术模式應充分利用您在 MLOps 實施中現有的 DataOps 投資。 重現性和數據版本控制可讓您試驗不同的特徵工程數據、比較不同模型的效能，以及重現結果。
RAG 與即時工程
RAG 解決方案中數據的意圖是提供在提示中呈現給語言模型的基礎數據。 RAG 解決方案通常需要將大型文件處理成大小合適、語義相關的區塊的集合，並將這些區塊保存在向量儲存中。 有關詳細資訊，請參閱設計和開發 RAG 解決方案。 RAG 解決方案的再現性和資料版本控制可讓您嘗試不同的分塊和嵌入策略、比較效能並回滾到先前的版本。
區塊化文件的數據管線不屬於傳統 MLOps 中的 DataOps，因此您必須擴充架構和作業。 數據管線可以從包含結構化和非結構化數據的不同來源讀取數據。 它們也可以將轉換後的數據寫入不同的目標位置。 您必須擴充架構，以包含用於地面數據的數據存放區。 這些模式的常見數據存放區是像 AI 搜尋這樣的向量存放區。
如同訓練和微調，您可以使用 Azure Machine Learning 管線或其他數據管線工具來協調資料分塊階段。 您可以利用 Azure Machine Learning 管線中的提示流程以一致且可重複的方式處理和豐富資料。 您還必須擴展操作以保持資料儲存中搜尋索引的新鮮度和有效性。
測試
測試是內部迴圈的一部分，是建立、評估和精簡解決方案的反覆程式。 以下部分討論常見生成式 AI 技術模式的實驗。
訓練和微調
當您微調現有的語言模型或定型小型語言模型時，您可以利用目前的 MLOps 投資。 例如，Azure Machine Learning 管線提供工具組，以有效率且有效地進行實驗。 這些管線可讓您管理整個微調程式，從數據前置處理到模型定型和評估。
RAG 與即時工程
進行提示設計和RAG工作負載的實驗需要您加強MLOps的投資。 對於這些技術模式，工作量並不會隨著模型而結束。 工作負載需要協調器，這是可以執行邏輯的系統、呼叫數據存放區以取得必要資訊，例如地面數據、產生提示、呼叫語言模型等等。 資料儲存和儲存中的索引也是工作負載的一部分。 您需要擴充作業，以控管工作負載的這些層面。
您可以從多個角度探索提示工程解決方案，包括不同的操作指示、角色設定、範例、條件約束以及進階技術，例如提示鏈接。 當您 實驗 RAG 解決方案時，您可以探索其他領域：
- 分塊策略
- 什麼和如何擴充區塊
- 您的嵌入模型
- 搜尋索引的設定
- 要執行的搜尋專案（向量、全文檢索、混合式等等）
如 DataOps中所述，重現性和數據版本控制是實驗的關鍵。 良好的實驗架構可讓您儲存輸入，例如超參數或提示的變更，以及 評估實驗時所要使用的輸出。
如同您現有的 MLOps 環境，您可以利用 Azure Machine Learning 管線等架構。 Azure Machine Learning 管線具有功能，可藉由與向量資料庫如 AI 搜尋服務整合來支援索引。 您的 GenAIOps 環境可以利用這些管線功能，並將其與提示流程功能結合，以管理提示工程和自定義前置處理邏輯。
評估與實驗
評估是建構、評估和完善解決方案的迭代實驗流程的關鍵。 變更的評估會提供您所需的意見反饋，使您能夠進行改進，或確認當前版本符合您的需求。 以下部分討論了常見生成 AI 技術模式的實驗階段的評估。
訓練和微調
若要評估微調或定型的衍生式 AI 模型，您應該利用現有的 MLOps 投資。 例如，如果您使用 Azure Machine Learning 管線來協調機器學習模型定型，您可以使用相同的評估功能來微調基礎語言模型，或定型新的小型語言模型。 這些功能包括 評估模型元件，該元件會計算特定模型類型的業界標準評估計量，並跨模型比較結果。
RAG 與即時工程
您需要擴充現有的 MLOps 投資，以評估生成式 AI 方案。 您可以使用像提示流程工具這樣的工具，其提供評估框架。 提示流程可讓小組藉由指定準則和計量來定義自定義評估邏輯，以評估各種 提示變數的效能 和大型語言模型（LLM）。 這個結構化方法可讓您比較不同的組態，例如超參數或架構變化，以識別特定工作的最佳設定。
在 prompt flow 中的任務會在實驗過程中自動擷取輸入和輸出數據，以建立完整的測試記錄。 透過分析這些資料，您可以獲得見解並確定有前途的設定，這些設定可以為未來的迭代提供資訊。 您可以使用提示流程進行有效率且系統化的實驗，加速開發您的產生 AI 解決方案。
不論您產生的 AI 解決方案的使用案例為何，實驗程式都相同。 這些使用案例包括分類、摘要、翻譯，甚至是RAG。 重要的區別在於您用來評估不同使用案例的指標。 以下是根據使用案例選擇的一些指標。
- 翻譯：BLEU
- 總結：ROUGE。 BEU、BERTcore、METEOR
- 分類：精確率、召回率、準確率、交叉熵
- RAG：基礎性、相關性
注意
如需評估語言模型和RAG解決方案的詳細資訊，請參閱 LLM端對端評估。
一般而言，衍生式 AI 解決方案會從訓練模型擴充機器學習小組的責任，以提示工程和管理地面數據。 由於提示工程和RAG實驗和評估不一定需要數據科學家，因此您可能會想要使用軟體工程師和數據工程師等其他角色來執行這些功能。 如果您在進行提示工程和RAG解決方案的過程中省略了數據科學家，您將面臨挑戰。 其他角色通常不會接受科學訓練來評估結果，這與許多接受過此類訓練的數據科學家的情況不同。 閱讀由七部分組成的文章系列設計與開發 RAG 解決方案，以了解設計生成式 AI 解決方案的複雜性。
投資生成式 AI 解決方案可以幫助您減輕數據科學資源的壓力。 軟體工程師的角色會擴展在這些解決方案中。 例如，軟體工程師是管理生成式 AI 解決方案協調責任的絕佳資源，而且他們擅長在 Prompt flow 等工具中設定評估指標。 讓數據科學家檢閱這項工作非常重要。 他們有訓練和經驗，瞭解如何正確評估實驗。
部署
某些衍生式 AI 解決方案牽涉到部署自定義定型模型或微調現有的模型，但有些則不會。 針對生成式 AI 解決方案，您需要納入協調器的部署以及任何資料存放區的部署的其他工作。 下列各節將討論常見生成式 AI 技術方案的部署。
訓練和微調
您應該利用現有的 MLOps 投資，並做一些可能的調整，以部署生成式 AI 模型並微調基礎模型。 例如，若要微調 Azure OpenAI 中的大型語言模型，您必須確定您的定型和驗證數據集是 JSONL 格式，而且您需要透過 REST API 上傳數據。 您還需要建立一個微調作業。 若要部署定型的小型語言模型，您可以利用現有的MLOps投資。
RAG 與即時工程
針對RAG和提示工程，還有其他考慮，包括編排邏輯、索引和架構等數據存放區的變更，以及數據管線邏輯的變更。 協調流程邏輯通常會封裝在提示流程、語意核心或 LangChain 等架構中。 您可以將協調器部署到不同的計算資源，包括您目前可能部署自定義模型的資源。 如需將提示流程部署至 Azure Machine Learning 所管理的在線端點或 Azure App Service 的範例，請參閱 Azure OpenAI 端對端聊天架構。 若要部署至 App Service，Azure OpenAI 聊天架構會將流程及其相依性封裝為容器，以提升不同環境的可移植性和一致性。
部署資料庫資源的變更，例如數據模型或索引的變更，都是需要在 GenAIOps 中處理的新工作。 使用大型語言模型時的常見做法是在 LLM 之前使用閘道。
許多生成式 AI 架構會使用平臺託管的語言模型，例如由 Azure OpenAI 提供的模型，並包括像 Azure API 管理這樣的
部署衍生式 AI 特有的元素，例如協調器，應該遵循適當的作業程式，例如：
- 嚴格的測試，包括單元測試。
- 整合測試。
- A/B 測試。
- 端對端測試。
- 推出策略，例如金絲雀佈署或藍綠（Blue/Green）佈署。
由於產生 AI 應用程式的部署責任超出模型部署，因此您可能需要額外的作業角色來管理部署和監視使用者介面、協調器和數據存放區等專案。 這些角色通常與 DevOps 工程師技能集一致。
推斷和監控
推斷是將輸入傳遞給經過訓練和部署的模型，然後產生反應的流程。 您應該從三個角度監控傳統機器學習和生成式 AI 解決方案：營運監控、從生產中學習和資源管理。
營運監控
運作監控是觀察系統持續運作的過程，包含數據作業（DataOps）和模型訓練。 這種類型的監視會尋找偏差，包括錯誤、錯誤率變更，以及處理時間的變更。
針對模型定型和微調，您通常會觀察處理特徵數據、模型定型和微調的數據作業。 應利用您現有的 MLOps 和 DataOps 投資來監控這些內部迴圈流程。
為了在生成式 AI 解決方案中進行快速工程，您還需要考慮額外的監控問題。 您必須監視處理地面數據或其他用來產生提示的數據管線。 此處理可能包含數據存放區作業，例如建置或重建索引。
從生產中學習
在推斷階段期間，監視的一個關鍵層面是從生產中學習。 監視傳統機器學習模型會追蹤一些指標，例如準確率、精確度和召回率。 關鍵目標是避免預測偏移。 使用生成模型用來進行預測的方案，例如使用 GPT 模型進行分類，應該善加利用您現有的 MLOps 監控投資。
使用生成模型來推理基礎數據的解決方案會使用 度量，例如基礎性、完整性、使用率和相關性。 目標是確保模型能完整回答查詢，並將響應基礎放在其內容上。 在這裡，您必須嘗試防止數據漂移之類的問題。 您要確保為模型提供的基礎數據和提示與用戶查詢具有最大關聯性。
針對非預測性任務使用生成模型的解決方案，例如RAG解決方案，通常會從最終使用者的意見反饋中獲益，以評估使用效益。 使用者介面可以擷取意見，例如按讚或倒讚，然後您可以使用此數據定期評估回應。
生成式 AI 解決方案的常見模式是在生成模型前面部署閘道。 閘道的使用案例之一是用於監控基礎模型。 您可以使用閘道來記錄輸入提示和輸出。
監控生成解決方案的另一個關鍵領域是內容安全。 目標是調節反應並偵測有害或不良內容。 Azure AI Content Safety Studio 是一個可以用來管理內容的範例工具。
資源管理
使用公開為服務之模型的產生解決方案，例如 Azure OpenAI，其資源管理考慮與您自己部署的模型不同。 對於公開為服務的模型，您並不關心基礎結構。 相反地，您擔心您的服務輸送量、配額和節流。 Azure OpenAI 會使用令牌進行計費、節流和配額。 您應該監控配額使用情況以進行成本管理和效能效率。 Azure OpenAI 可讓您記錄令牌使用量。
工具
許多 MLOps 的從業者已經將一套工具包標準化，用於組織各種自動化、追蹤、部署、實驗等的活動，以抽象化這些過程中常見的考慮事項和實施細節。 一個常見的統一平台是 MLflow。 尋找支援 GenAIOps 模式的新工具之前，您應該先檢閱現有的 MLOps 工具，以評估其對產生 AI 的支援。 例如，MLflow 支援語言模型的廣泛功能。
MLOps 和 GenAIOps 成熟度模型
您可能已使用 MLOps 成熟度模型 來評估目前機器學習作業和環境的成熟度。 當您擴展對生成型 AI 工作負載的 MLOps 投資時，您應該使用 GenAIOps 成熟度模型來評估這些操作。 您可能會想要合併這兩個成熟度模型，但建議您個別測量每個模型。 MLOps 和 GenAIOps 將相互獨立發展。 例如，您可能位於 MLOps 成熟度模型中的第四級，但在生成式 AI 的第一級。
摘要
當您開始擴展 MLOps 投資以納入生成式 AI 時，務必瞭解您不需要從頭開始。 您可以將現有的 MLOps 投資用於某些產生的 AI 技術模式。 微調生成模型就是一個很好的例子。 有一些生成式 AI 解決方案的領域，例如提示工程和 RAG，這些是新的流程，因此您需要擴大現有的作業投資並獲得新的技能。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
- Luiz Braz |資深技術專家
- 馬可·奧雷利奧·卡多索 |資深軟體工程師
- 保羅·拉塞爾達 |雲端解決方案架構師
- Ritesh Modi |首席軟體工程師
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。