- LLMOps 擴展了 DevOps 和 MLOps，以管理生產環境中基於 LLM 的應用程式的行為。
- GenAIOps 與 Azure 中的提示流程整合了儲存庫、管道和持續評估，以實現提示流程。
- ChatOps、LLMOps 和 DevOps 的融合實現了對話式、自動化和可觀察的操作。
- 分階段、標準化的推廣實施可以降低安全風險、成本和組織複雜性。
生成式人工智慧和大型語言模式的出現徹底改變了軟體的建置、部署和運作方式。 擁有美好的事物已經遠遠不夠了。 DevOps 管線 也無法透過應用經典的MLOps來實現。當你在方程式中引入 LLM 時，你就進入了一個模型會說話、推理、即興發揮，有時還會以不可預測的方式行事的領域。
在這個新場景中， 團隊需要將 DevOps、AI 和 LLMOps 結合起來，以管理基於 LLM 的應用程式的整個生命週期。從實驗和快速工程到部署、監控、安全性和成本優化，本文將所有這些概念化繁為簡，並一步一步地引導您如何將 ChatOps、DevOps、MLOps、GenAIOps 和 LLMOps 融入現代營運中。
從 DevOps 和 MLOps 到 LLMOps：為什麼模型不再是靜態的
多年來，工程團隊的首要任務是 自動化軟體交付 並減少發展與基礎設施之間的摩擦於是 DevOps 誕生了：持續整合、持續部署、基礎設施即程式碼、可觀測性以及消除部門間無休止交接的協作文化。
當數據成為產品的一部分時，它就出現了。 MLOps 的出現是為了滿足機器學習模型的可重現性和可追溯性需求。資料集版本控制、訓練流程編排、漂移檢測和預測模型的持續評估等實踐已標準化。
問題是 LLM打破了DevOps和MLOps中許多隱含的假設。它們不是靜態 API 或傳回確定性數字的簡單函數：它們以自然語言回應，即時混合上下文、指令、工具和數據，並且可以對相同輸入產生兩種不同的輸出。
這意味著 僅僅改變模型及其權重是不夠的。此外，還需要控制提示、範本、語意安全策略、限制、連接的工具、注入的上下文，甚至控制影響系統行為的業務規則。
LLMOps是什麼？它實際解決了什麼問題？
我們可以將LLMOps視為 此操作框架允許安全、可控且可持續地部署、維護和擴展基於LLM的應用程式。它是 DevOps 實踐、MLOps 和生成模型特有的新功能共存的統稱。
在本質上， LLMOps 不太注重“訓練完美的模型”，而更注重控制模型在生產環境中的行為。它包括如何設計和版本化提示流、LLM 如何連接到內部資料來源、如何監控令牌成本和延遲，以及如何管理語義風險（幻覺、資訊外洩、偏見、有害反應等）。
LLMOps 能夠滿足而 DevOps/MLOps 單獨無法滿足的需求包括： 涉及的方麵包括對話追蹤、回覆品質的自動評估，以及行為變體的 A/B 對比等。我們說的不僅是傳統的準確性，還包括一致性、與業務的一致性以及安全性。
另外， 成本不再僅限於模型的培訓和託管。在商業 API 中，每次提示、每次擴展上下文以及每次並發呼叫都會觸發 GPU 或令牌消耗。如果沒有 LLMOps 層來使這種消耗可見並將其與設備、服務和用例關聯起來，帳單就會不可預測地增長。
ChatOps + LLMOps + DevOps：維運變得對話化
最強勁的趨勢之一是 將 ChatOps 和 LLMOps 融入 DevOps 文化團隊不再局限於儀表板、腳本和管道，而是開始透過 Slack、Microsoft Teams 或 Discord 等聊天頻道來作業系統的大部分功能。
ChatOps 提出日常運維（部署、日誌查詢、重新啟動、設定變更） 由通訊管道內的機器人執行對整個團隊來說都是透明的。每條指令、每一個動作和每一個結果都會記錄在對話中。
當LLM（法學碩士）被引入到這種方法中時，就會出現一個新的智慧層面： 能夠理解自然語言、解讀意圖、執行複雜命令或分析情況的聊天機器人 操作員無需記住每一個確切的腳本或標誌。
這種趨同的典型例子包括： 一個由LLM驅動的機器人讀取Prometheus指標和Loki日誌。 當有人寫道“X 組的服務運行緩慢”，並建議採取諸如增加副本數量、執行回滾或啟動特定測試等操作時，所有操作都用自然語言進行了解釋。
在文化和營運層面，這意味著 更快的決策速度、更少的重複性人工幹預以及更流暢的 DevOps 團隊體驗他們從不斷救火轉變為致力於策略改善。
生產中 LLM 生命週期的關鍵原則
認真攻讀法學碩士學位並非一次性項目，而是長期的過程。 這是一個不斷重複的循環，其中每一次變化都可能改變系統的行為。雖然每個組織都會根據自身實際情況進行調整，但通常有六個主要階段，這些階段會相互影響。
首先是 模型的訓練或適應階段這可以包括直接使用基礎模型，也可以應用微調、LoRa 或其他調優技術，並使用您自己的資料進行測試。這裡重要的不僅是效能，還要留下完整的記錄：資料集、套用的濾波器、超參數、分詞器版本、測試的架構等等。
如果這一階段是即興發揮且沒有記錄， 此模式誕生之初便缺乏治理。之後，幾乎不可能解釋為什麼它會這樣反應，也不可能在審計需要時重現特定結果。
第二階段是部署，模型離開實驗室並進入生產環境。在 LLMOps，這不僅僅是「把它放進容器裡」那麼簡單： 我們必須做出決定 使用哪些硬體如何管理長時間運行上下文的內存，應該採用哪種集群拓撲結構，以及如何根據流量進行擴展 不會造成延遲飆升或成本過高。
這就是事情發揮作用的地方。 持續的行為導向監測僅僅關注 CPU 和 RAM 的使用情況是不夠的；還需要監控響應的語義品質、風格的穩定性、錯誤率、每個標記的成本變化、危險或不連貫響應的出現以及不同使用模式下響應時間的變化。
在後續階段，將進行最佳化和微調任務： 觸摸提示、調整 RAG（紅綠燈）評級、測試模型變體、量化、進行 A/B 測試、更改語義安全策略或完善業務規則這幾乎是一個精細化的過程，數據、工程和業務部門坐下來共同決定優先事項。
最後，這一切都屬於… 多層安全與治理 （存取控制、稽核、洩漏預防、使用限制、法規遵循）並且遵循持續更新的邏輯，其中模型及其生態系統會適應資料、法規和內部需求的變化。
Azure 中的 GenAIOps 和通知流程方法
在LLMOps領域，針對生命週期結構有著非常具體的方案。其中，在企業環境中最為先進的方案之一是： GenAIOps 在 Azure 機器學習上實現了快速流程，並與 Azure DevOps 整合。它提出了一種建立基於LLM的應用程式的系統方法。
提示流程不僅僅是一個提示編輯器；它 一個完整的平台，用於設計、測試、版本控制和部署 LLM 互動流程。從簡單的案例（單一提示）到具有多個節點、外部工具、控制項和自動評估的複雜編排。
一個關鍵特徵是 串流的集中式儲存庫它充當企業圖書館的角色。以前每個團隊的提示資訊都分散在單獨的文件或各自的儲存庫中，現在它們被整合到一個統一管理的儲存庫中，具有清晰的分支、修訂和歷史記錄。
此外，該平台還增加了變異和超參數實驗功能： 可以測試提示、模型、溫度設定或安全策略的不同組合。 在流程的多個節點上，使用清晰的指標來比較結果。
關於部署，GenAIOps 附有通知流程 它產生封裝了工作流程和進程會話的 Docker 映像。這些元件可直接在 Azure 應用程式服務、Kubernetes 或託管流程等環境中運作。基於此，支援 A/B 測試部署，以便在真實環境中比較不同流程版本。
另一個優勢在於資料集和資料流之間關係的管理。 每個評估流程都可以使用多個標準資料集和測試資料集。這樣就可以在將產品交付給最終用戶之前，先驗證不同場景下的行為。
該平台僅在資料集和流程發生實際變更時才自動註冊新版本，並且 它可以產生 CSV 和 HTML 等格式的綜合報告。 支持基於數據而非直覺的決策。
GenAIOps 的四個階段及通知流程
GenAIOps 方法將生命週期分解為四個清晰區分的階段，這有助於避免典型的「我們嘗試用 AI 做事情，看看會發生什麼」的混亂局面。
第一階段，即初始化階段，重點在於 明確定義業務目標並收集具有代表性的數據範例這裡概述了提示流程的基本結構並設計了架構，然後對其進行改進。
在實驗階段，將此流程應用於樣本數據， 對不同的提示、模型和配置方案進行了評估。這個過程會不斷迭代，直到找到滿足最低品質和一致性標準的可接受組合。
接下來是評估和完善階段，在這個階段… 使用更大、更多樣化的資料集來進行嚴格的對比測試只有當流程表現出與既定標準相符的穩定性能時，才能認為流程已準備好進入下一步。
最後，在實施階段，對流程進行最佳化，使其高效運行，並部署到生產環境中。 包括A/B部署選項、監控、使用者回饋收集和持續改善週期一切並非一成不變：流程會根據實際使用情況不斷調整。
該方法論被打包在一個 GenAIOps 儲存庫模板中，其中包含程式碼優先的預先建置管道，並且 用於開發、評估和部署基於LLM的應用程式的本機和雲端執行工具 無需在每個專案中重新發明輪子。
與 Azure DevOps 整合：儲存庫、管道和身份驗證
要將 GenAIOps 從理論層面應用到實際組織中，將其與 Azure DevOps 整合至關重要。典型的模板以以下內容開頭： Azure Repos 中的一個儲存庫，包含兩個主要分支：main 和 development。這反映了不同的環境和程式碼推廣策略。
這個範例儲存庫是從 GitHub 克隆的，並與 Azure Repos 關聯， 我們通常透過從開發中建立特性分支來進行工作。更改透過拉取請求發送，這會自動觸發驗證和實驗流程。
為了使 Azure DevOps 能夠與 Azure 機器學習和其他服務交互，需要進行相應的配置。 Azure 中的服務實體會作為技術標識此身分用於 Azure DevOps 服務連接，因此管道無需以明文形式公開金鑰即可進行驗證。
通常情況下，該實體擁有對機器學習訂閱或工作資源的擁有者權限，因此 管道可以配置端點、註冊模型以及更新金鑰庫中的策略。如果要加強安全性，可以透過調整處理權限的 YAML 步驟，將角色調整為「貢獻者」。
此外，Azure DevOps 中還創建了一組變量， 它會儲存敏感數據，例如服務連接名稱或資源標識符。這些變數以環境變數的形式暴露給管道，避免在程式碼中硬編碼關鍵資訊。
配置本機和遠端儲存庫可讓您： 開發分支受分支策略保護。 這需要先執行拉取請求管線才能允許合併。此流水線處理建構驗證和實驗流程，防止引入破壞性變更。
一旦程式碼進入開發階段，就會觸發一個開發管線。 它包括CI和CD的完整階段。：執行實驗和評估，在 Azure ML 模型登錄中記錄流程，部署終結點和冒煙測試，並整合到新建立的終點。
同樣的模式會複製到與生產環境相連的版本或發布分支。在那裡， 生產環境中的 CI/CD 管線會重複實驗、評估和部署的循環。但對於基礎設施和生產層面的數據，需要更大的控制，必要時還可以進行額外的人工審核。
關鍵細節在於這些流程中包含的「人為流程審查」： CI 階段結束後，CD 將保持鎖定狀態，直到有人手動批准為止。 後續操作將從 Azure Pipelines 介面發起。如果在規定時間內（例如 60 分鐘）未獲得批准，則執行將被拒絕。
本地實施及與LLM提供者的聯繫
並非所有內容都圍繞著管道：GenAIOps 也支持 本地執行以實現快速實驗您可以克隆模板儲存庫，在根目錄中建立一個 .env 文件，並在其中定義與 Azure OpenAI 或其他相容終結點的連接。
這些連線包含諸如 api_key、api_base、api_type 和 api_version 之類的參數， 它們在流程中透過名稱被引用。 （例如，名為「aoai」且具有特定 API 版本的連接）。這樣，無需更改程式碼，即可在本地端和雲端執行相同的流程。
要使用此模式，只需 建立虛擬環境或使用 conda，並安裝必要的依賴項。 （例如 promptflow、promptflow-tools、promptflow-sdk、openai、jinja2、python-dotenv 等）。之後，您可以在本機執行資料夾中編寫測試腳本，並對定義的流程執行實驗。
這種雲端/本地部署的二元模式與成熟的DevOps概念非常契合： 它先在本地小規模進行測試，然後在管線中進行正式驗證，最後推廣到具有控制和稽核的更高層級的環境。所有內容都使用 Git 進行版本控制，並連接到 Azure DevOps。
DevOps 生態系中典型的 AI 和 LLMOps 工具
除了 Azure 的特定產品之外，一個具備 AI 和 LLMOps 的現代 DevOps 生態系統通常依賴 一套涵蓋聊天運作、模型編排、監控和可觀測性的工具集.
在 ChatOps 層，通常會結合使用 Slack 與 Hubot 等機器人配合使用使用基於 Power Virtual Agents 的 Microsoft Teams 代理，或使用 Discord 以及 Botpress 或 Rasa 等框架來建立自訂助手，這些助手可以連接到管道、監控系統和內部服務。
在LLMOps/MLOps平面上，它們很常見。 像 Kubeflow 和 MLflow 這樣的平台 用於管理管道、模型記錄和實驗，以及用於進階指標追蹤、運行比較或深度視覺化的特定工具，例如權重和偏差 (W&B)。
在LLM上建立應用程式時，通常使用 類似 LangChain 或 OpenLLM 類型的框架庫這些解決方案有助於建立提示鏈、連接外部資料、工具和多步驟代理程式。同時，針對LLM特定可觀測性的解決方案也正在湧現，從而能夠監控提示、回應、成本和品質。
在與傳統 DevOps 整合時，像 Jenkins 或 GitLab CI 這樣的工具對於 CI/CD 部分仍然非常重要。 Kubernetes 和 ArgoCD 用於持續的雲端原生部署以及 Prometheus、Grafana 和 Loki 等可觀測性堆疊，用於指標、儀表板和日誌。
挑戰、限制和逐步採用
所有這些實踐和工具的部署都不是免費的。 管理提示、模型版本和流程變體的複雜性 相當可觀，尤其 當多個團隊同時工作時 —建議採用以下方案的情況 諸如 GitOps 之類的策略 協調變更和部署。
此外，ChatOps機器人和LLM本身也具備採取行動的能力。 它們會帶來相當大的安全風險 如果他們在生產環境中擁有過多的權限，或者資料暴露面沒有得到妥善控制。
除此之外 依賴具有敏感授權或商業 API 的開源模型 這可能會改變條件、價格或限制。更糟的是，對生產中的LLM進行穩健評估仍然是一個開放性領域，許多問題仍未得到解答。
因此，在 DevOps 中探討 LLMOps 和 ChatOps 的應用是有意義的。 以循序漸進且可控的方式首先，透過簡單的機器人實現重複性任務的自動化（重啟、日誌查詢、建置標記等）。
之後，它們可以被引入。 LLM 用於支援任務、事件分類或調試協助例如，根據日誌解釋錯誤，或根據內部文件提出緩解措施。
一旦經典的機器學習操作穩定下來，就該… 使用專門的語言模型解決 LLMOps 問題 對於客戶服務、DevSecOps 或 QA 等領域，要充分利用在前幾個階段學到的一切。
所有這些實踐所指向的共同目標是什麼？ 一個對話式、預測式且日益自主的工程環境其中大部分開發和營運都以自然語言表達，人工智慧有助於對部署、擴展或回滾做出主動決策。
有了這套完整的體系——DevOps、ChatOps、MLOps、GenAIOps 和 LLMOps——組織就擁有了 為建構和維護真正創造價值的基於生命週期管理（LLM）的系統提供一個堅實的框架保持對品質、成本、安全和與業務一致性的控制，而不是停留在簡單的原型或孤立的測試階段，這些原型或測試一旦投入生產就會崩潰。
