《12-錢譽-Ai Agent在運維體系中的探索與實踐.pdf》由會員分享,可在線閱讀,更多相關《12-錢譽-Ai Agent在運維體系中的探索與實踐.pdf(13頁珍藏版)》請在三個皮匠報告上搜索。
1、Ai Agent在運維體系中的探索與實踐錢譽Zenlayer GFS Monitoring Automation 負責人大綱 Zenlayer在運維體系中對Copilot&Agent理解 Zenlayer在私域數據嘗試:FT or RAG(Baseline&Graph)場景實現案例 實踐預期 未來展望Zenalyer在運維體系中對Copilot&Agent理解傳統的 AIOps 在異常檢測和根因分析上嚴重依賴于標注數據,這限制了算法的泛化能力,因為它們需要在有監督的環境下進行訓練。而大語言模型能夠學習更多的通用知識,減少對標注數據的依賴,從而降低訓練成本。運維團隊積累的專家經驗很難編碼到算法模
2、型中。通常,這些經驗會被簡化為閾值或復雜的規則,不僅難以維護,也難以傳承。Copilot&Agent通過大語言模型,將專家經驗轉化為模型可以理解和推理的形式,從而提升了故障處理的能力。傳統 AIOps 的接入和維護成本較高,需要業務和算法團隊深入理解業務邏輯和算法模型。此外,私域數據的處理和定制化開發也增加了成本。Copilot&Agent 框架采用集成學習的概念,通過模塊化設計,使得系統能夠像搭積木一樣動態編排。在傳統 AIOps 中,未遇到過的故障很難被解決,因為它們超出了模型的訓練范圍。大語言模型展現出了強大的推理能力,能夠基于通用知識和訓練中學到的關鍵字,推斷出未知故障的性質,即使沒有
3、相似的訓練數據。傳統的 AIOps 解決方案需要用戶理解模型并精確地傳遞參數,而 Copilot&Agent框架支持自然語言交互,使得非技術用戶也能輕松地與系統交互,提高了用戶體驗,并有潛力開放給更廣泛的用戶群體Zenlayer在私域數據的嘗試:FT or RAG(Baseline&Graph)OneKE/DeepKE:對高度碎片化,非結構化,的信息進行抽取,構建一個高質量的知識圖譜并建立知識要素間的邏輯關系,實現可解釋的推理決策并提升穩定性1.RE(Relation Extraction)-關系抽取。這是一個任務,旨在從文本中識別實體之間的關系。例如,從句子“北京是中華人民共和國的首都”中,
4、抽取“北京”與“中華人民共和國”之間的“是首都”的關系。2.NER(Named Entity Recognition)-命名實體識別。這個任務的目標是從文本中識別出具有特定意義的實體,如人名、地名、組織機構名等。例如,在句子“約翰史密斯在紐約工作”中,識別出“約翰史密斯”和“紐約”分別為人名和地名。3.EE(Event Extraction)-事件抽取。這個任務是從文本中抽取事件信息,包括事件類型、觸發詞、參與實體以及它們的角色。例如,從句子“蘋果公司昨天宣布了新產品”中,抽取事件類型為“產品發布”,觸發詞為“宣布”,參與實體為“蘋果公司”,角色為“發布者”。4.EET(Event Entit
5、y Type)-事件實體類型。這可能是指在事件抽取中,識別參與事件的實體的類型,如上述例子中的“蘋果公司”被識別為“公司”這一實體類型。5.EEA(Event Entity Argument)-事件實體論元。這涉及到事件抽取中的更深層次分析,即識別實體在事件中扮演的具體角色。例如,在“蘋果公司昨天宣布了新產品”中,“新產品”被識別為“對象”這一論元。6.KG(Knowledge Graph)-知識圖譜。知識圖譜是一種以圖的形式表示實體及其關系的數據結構,能夠幫助理解復雜的實體關系網絡。在NLP中,構建或完善知識圖譜通常涉及從文本中抽取實體和關系信息。Zenlayer在私域數據的嘗試:FT or
6、 RAG(Baseline&Graph)Neo4J:結構化知識表示:通過圖結構來表示知識,GraphRAG可以更好地理解和利用知識之間的關系,這對于運維場景中理解復雜的系統架構和故障傳播路徑非常有幫助。增強推理能力:基于圖的結構,模型可以進行更復雜的推理,比如在運維場景中預測故障的影響范圍或推薦解決方案 當今的 RAG 應用中,從大型文本語料庫中檢索準確且具有上下文信息的能力至關重要。傳統的向量相似性搜索方法雖然功能強大,但有時會在嵌入較長的文本時忽略特定的上下文。通過將較長的文檔拆分為較小的向量并對其進行相似性索引,我們可以提高檢索準確率,同時保留父文檔的上下文信息以生成答案。同樣,我們可以
7、使用 LLM 生成假設問題或文本摘要。然后,LLM 為這些問題和摘要編制索引,以更好地表示特定概念,同時仍返回父文檔中的信息Zenlayer的場景實現案例一場景實現案例二場景實現案例實踐預期未來展望基于 LLM 的 RCA-Agent 構建目標是先將基于大語言模型的根因診斷(RCA)Agent 框架落地應用,因為根因診斷是所有運維團隊面臨的一個主要挑戰,它占用了大量的時間和精力,日常的On Call 問題定位也給團隊成員帶來了沉重的負擔。我們希望專注于解決這些實際問題,真正緩解同事的痛點。我們決定定義了一些工具和插件,是在出現故障時用來進行檢測的工具。除了工具和插件,我們還設計了工作流編排,以
8、自動化和優化故障處理流程。我們構建了一個知識庫,它包含了歷史故障數據、專家經驗和故障處理策略,這些都是進行有效根因分析的關鍵資源知識庫/知識圖譜的構建構建知識庫方面所做的工作主要包括以下幾個部分,并且我們計劃未來會引入更多用戶原始文檔、歷史 On Call 記錄等不同類型的數據。排障專家經驗:這部分是根據根因診斷的場景特別設計的,目的是讓業務團隊的成員能夠管理和記錄他們的知識和經驗。定義的每一個經驗都是一組根因故障,包括故障發生時的描述和一些止損措施的組合。這些信息將被用來訓練大語言模型推理。故障場景 SOP 文檔:我們希望用戶輸入的是一些 SOP 文檔。這種方式給組件團隊提供一種靈活管理知識
9、的方法。選擇這種半規范化文檔的形式,是因為當前大語言模型的能力還有局限,需要通過文檔梳理來幫助模型更好地理解。歷史故障信息:建立維護一個歷史故障信息庫,記錄每一次通過大語言模型檢測到的故障,這些記錄會用來對組件團隊進行訓練和打標?;A工具的構建在構建框架的基礎工具方面,我們參考了 OpenAI GPTs 將工具集成到平臺時所遵循的規范。我們將運維場景中的一些關鍵指標和基礎工具進行了統一管理,把傳統的異常檢測方法統一成一個工具,用戶只需要維護他們需要進行異常檢測的指標即可。用戶可以自定義檢測項,包括指標名稱、指標的標簽或指標描述,以及定義何為異常表現。因為是用戶自定義的工具,所以可以根據具體需求
10、設置檢測標準。實現了一個變更事件查詢工具,當出現故障時,用戶可以通過調用這個接口來確定是否由線上變更導致。我們在平臺上部署的組件配置了一些工具,例如異常檢測、變更和事件查詢等,還包括了自然語言的意圖理解和大語言模型的根因推理功能。工作流的構建(SOP)構建工作流,目前這一過程仍然需要用戶自行配置,這主要是由于大語言模型當前能力的限制所做出的妥協。不過,我們正在探索一種新的方法,即允許用戶在其 SOP 文檔中預先設定工作流,例如,文檔中可以指明首先需要檢查哪些指標,以及根據這些指標的結果接下來應該檢查哪些指標。我們希望能夠訓練大語言模型,使其能夠直接根據用戶的 SOP 文檔生成工作流。最終,運維團隊能夠向大語言模型提供一個簡單的文檔,甚至是未經格式化的文本,而模型能夠根據文檔中的指標或檢測項動態地編排診斷步驟,并根據每一步的檢測結果,智能地調度后續的執行流程。彩蛋-Neo4J-RAG感謝聆聽Thank you for listening