很感謝夜鶯提供如此優質的平臺能和行業內頂尖技術大佬做面對面的交流，在這個會議中又學習到了很多有趣有深度的內容，給我在未來探索的道路上提供了一些新的指引方向。同時感謝夜鶯社群的邀請，在此再做一次關於AI方面的交流文章，由於目前我也是在AI這條賽道上的探索者，如果有不專業的地方還希望各位手下留情，同時希望能結識更多的同行，一起在AI這條賽道上做一些更高階更有趣的事情。
在會議現場，我分享了 Zenlayer 在 AI 方向的一些實踐效果，有些基礎知識、選型思考等，並未在大會現場展開，這裡我會在這篇文章中進行一些補充，希望能夠給大家帶來一些啟發。更多的是提供一種思路和需要了解的實現背景的邏輯，而不是給出固定化的實現方式，也是希望能夠有更多活躍思考。
構建AI化需要的知識體系
Semantic Kernel
Semantic Kernel是Microsoft推出的一個開源框架，旨在幫助開發者構建和部署AI應用，特別是那些需要理解和生成自然語言的應用。它提供了一種結構化的方式來定義和管理技能（Skills），這些技能可以是簡單的函式呼叫，也可以是複雜的AI模型互動。
核心元件
- Kernel: Semantic Kernel的核心，負責技能的管理和執行。
- Skills: 定義了應用可以執行的一系列操作，可以是本地函式，也可以是遠端服務呼叫。
- Prompt Templates: 用於生成和修改自然語言的模板，支援變數和函式呼叫。
- Memory: 提供了儲存和檢索應用狀態的能力，可以是簡單的鍵值對，也可以是複雜的圖資料庫。
LangChain
LangChain是一個開源框架，專注於構建應用，這些應用可以利用大型語言模型（LLMs）來執行各種任務，如回答問題、生成文字、執行程式碼等。它提供了一種靈活的方式來組合和呼叫不同的LLMs，以及管理與這些模型的互動。
核心元件
- Chains: 定義了模型呼叫的邏輯流程，可以是簡單的單步呼叫，也可以是複雜的多步流程。
- Prompts: 用於指導模型生成特定型別輸出的模板。
- Memory: 提供了儲存和檢索應用狀態的能力，可以用於上下文理解和歷史記錄。
- Agents: 可以自動執行任務的實體，基於給定的目標和約束。
總結
Semantic Kernel和LangChain都是為了簡化AI應用的開發，但它們的側重點不同。Semantic Kernel更注重技能的定義和管理，而LangChain則更側重於大型語言模型的組合和呼叫。選擇哪個框架取決於具體的應用場景和需求。
在我們的場景裡我們更多的是考慮使用semantic kernel的方式來構建，不是說langchain不好，只是langchain的程式碼側抽象的東西太厲害，本身架構也比較重，對於後期開發的運維和迭代成本比較高，我們現在的體量還太小，感覺自身玩不太動。
大模型的應用架構
典型的業務架構
技術架構
純Prompt
就像和一個人對話，你說一句，ta回一句，你再說一句，ta再回一句 
agent + FC (Function calling)
- Agent：AI 主動提要求
- Function Calling：AI 要求執行某個函式
場景舉例：你問過年去哪玩，ta 先反問你有幾天假
RAG(Baseline)= Embeddings + 向量資料庫
- Embeddings：把文字轉換為更易於相似度計算的編碼。這種編碼叫向量
- 向量資料庫：把向量存起來，方便查詢
- 向量搜尋：根據輸入向量，找到最相似的向量
- 場景舉例：考試時，看到一道題，到書上找相關內容，再結合題目組成答案。然後，就都忘了
目前我們還使用了rerank model對RAG的結果進行重排序，使得得到更精準的答案
Fine-Tuning
努力學習考試內容，長期記住，活學活用
目前傳統的FT對於在運維體系中，特別是抽象物件的訓練達不到一個很好的效果，所以我們也在嘗試基於DeepKe的抽象方式做運維體系中的資料，文字做FT，看是不是能把抽象的物件直接關係能理解清楚
Prompt的工程:提升LLM理解與響應能力
Prompt設計原則
為什麼要說Prompt，其實有了架構，但如何讓LLM理解你的推理依據，那就需要Prompt提示工程來解決，不同的LLM的chat_template的模版也是完全不同的，也就會導致不同的模型你用同一種Prompt的方式無法得到一樣的答案，甚至於同一個模型多次重複同一個問題也會存在差異的現象。
從我的個人實踐來說，總結主要有以下幾條原則：
- Write clear instructions（寫出清晰的指令）
- Provide reference text（提供參考文字）
- Split complex tasks into simpler subtasks（將複雜的任務拆分為更簡單的子任務）
- Give the model time to “think”（給模型時間“思考”）
- Use external tools（使用外部工具）
- Test changes systematically（系統地測試變更）
具體實現的方式
1.把話說詳細
儘量多的提供任何重要的詳細資訊和上下文，說白了，就是把話說明白一點，不要一個太籠統。 比如：不要說：“總結會議記錄” 而是說：“用一個段落總結會議記錄。然後寫下演講者的 Markdown 列表以及他們的每個要點。最後，列出發言人建議的後續步驟或行動專案（如果有）。”
2.讓模型充當某個角色
你可以把大模型想象成一個演員，你要告訴他讓他演什麼角色，他就會更專業更明確，一個道理。 比如：充當一個喜歡講笑話的喜劇演員，每當我請求幫助寫一些東西時，你會回覆一份文件，其中每個段落至少包含一個笑話或有趣的評論。
3.使用分隔符清楚地指示輸入的不同部分
三引號、XML 標籤、節標題等分隔符可以幫助劃分要區別對待的文字節。可以幫助大模型更好的理解文字內容。我最喜歡用"““把內容框起來。 比如：用50個字元總結由三引號分隔的文字。“““在此插入文字”””
4.指定完成任務所需的步驟
有些任務能拆就拆，最好指定為一系列步驟。明確地寫出這些步驟可以使模型更容易去實現它們。 比如：使用以下分步說明來響應使用者輸入。 步驟1 - 使用者將為您提供三引號中的文字。用一個句子總結這段文字，並加上字首“Summary:”。 步驟2 - 將步驟1中的摘要翻譯成西班牙語，並新增字首“翻譯：”。
5.提供例子
也就是經典的少樣本提示，few-shot prompt，先扔給大模型例子，讓大模型按你的例子來輸出。 比如：按這句話的風格來寫XX文章：“““落霞與孤鶩齊飛，秋水共長天一色。漁舟唱晚，響窮彭蠡之濱”””
6.指定所輸出長度
可以要求模型生成給定目標長度的輸出。目標輸出長度可以根據單詞、句子、段落、要點等的計數來指定。中文效果不明顯，同時你給定的長度只是個大概，多少個字這種肯定會不精準，但是像多少段這種效果就比較好。 比如：用兩個段落、100個字元概括由三引號分隔的文字。“““在此插入文字”””
提示框架應用
是不是遵循著一套方式就可以一路梭了呢，顯然不是，對於不同的任務背景其實還需要使用不同的提示詞框架來做具體任務的實現，由於涉及到具體內容太過冗長，我這裡也就直接給出有哪些框架和實現的框架邏輯
TAG框架
- 任務（Task）：描述您所要求完成的具體任務。
- 行動（Action）：細緻描述所需採取的動作。
- 目標（Goal）：明確您追求的最終目的。
SPAR框架
- 情境（Scenario）：勾勒出背景藍圖。
- 問題（Problem）：闡釋所面臨的難題。
- 行動（Action）：詳細說明所需實施的策略。
- 結果（Result）：描繪期待的成果。
TRACE框架
- 任務（Task）：確定並明確具體的任務。
- 請求（Request）：表述所希望請求的具體事項。
- 行動（Action）：描述必須實施的行動。
- 背景（Context）：提供相關背景或情境。
- 示例（Example）：用例項來闡明您的見解。
SCOPE框架
- 情境（Scenario）：描寫當前狀況或情景。
- 複雜情況（Complications）：討論任何潛在的複雜因素。
- 目標（Objective）：描述預期的目標。
- 計劃（Plan）：闡述實現目標所需的策略。
- 評估（Evaluation）：講述如何評估成功的標準。
APE框架
- 行動（Action）：說明所完成的具體工作內容。
- 目的（Purpose）：講解行動背後的意圖或目標。
- 期望（Expectation）：闡明所期待的結果或成功的標準。
SAGE框架
- 情況（Situation）：描述背景或當前情況。
- 行動（Action）：詳細說明所需進行的行動。
- 目標（Goal）：明確目標所在。
- 預期（Expectation）：闡明您所期望獲得的結果。
RTF框架
- 角色（Role）：定義LLM的角色定位。
- 任務（Task）：詳述特定的任務內容。
- 格式（Format）：說明您所期望的答案形式。
ROSES模型
- 角色（Role）：界定GPT所扮演的角色。
- 目標（Objective）：明確您的意圖。
- 情境（Scenario）：描述具體情境與環境。
- 解決方案（Solution）：設定所期望的結果。
- 步驟（Steps）：諮詢解決問題的具體步驟。
CARE框架
- 背景（Context）：界定討論的場景或上下文環境。
- 行動（Action）：說明期望完成的行動。
- 結果（Result）：闡明期待的結果。
- 示例（Example）：提供一個例證以闡述您的觀點
以上不同的提示框架對於具體實際的應用場景中需要靈活的去實現，天下沒有一招鮮的武功，要用好大模型提升助力，底層的邏輯實現與框架的瞭解是必不可少的，否則LLM只是一個聊天工具，並不能為你的工作帶來質的提升
讓LLM理解邏輯推理：從CoT到ReAct
上面幾個KeyPoint解釋了在LLM中實現應用的主要的技術或者方式，但真正要讓LLM作為一個AGENT或者Copilot存在，還需要有一個關鍵的點，那就是如何讓LLM知道你的推理方式，其實LLM解決只是技術差距的問題，但它無法解決提出問題的源頭，所以其實在LLM的今天，對於大家來說有想法且邏輯清楚的人，有了LLM的加持可能真的會一飛沖天，如果你能提出好的問題，那麼就能得到一個好的答案。
那麼推理架構有具體哪些呢，我在這裡只說一些相對用的比較多的，特別是在運維運營場景中比較容易落地的方式。
CoT（chain-of-thought prompting）思維鏈
提示透過中間推理步驟實現了複雜的推理能力。您可以將其與少樣本提示相結合，以獲得更好的結果，以便在回答之前進行推理的更復雜的任務.對於解決資料等具體落地問題，可以顯著提高大模型的推理方面的能力。
區別於傳統的 Prompt 從輸入直接到輸出的對映 <input——>output> 的方式，CoT 完成了從輸入到思維鏈再到輸出的對映，即 <input——>reasoning chain——>output>。
例如，如果問題是“紐約到洛杉磯的距離是多少？”，模型可能首先檢索紐約和洛杉磯的座標，然後計算兩點之間的距離，最後給出答案。在這個過程中，模型不僅提供了答案，還展示了其推理過程，增強了答案的可信度。
Auto-CoT 自動思維鏈
即利用 LLMs “讓我們一步一步地思考” 提示來生成一個接一個的推理鏈。這種自動過程仍然可能在生成的鏈中出現錯誤。為了減輕錯誤的影響，演示的多樣性很重要。這項工作提出了Auto-CoT，它對具有多樣性的問題進行取樣，並生成推理鏈來構建演示。
Auto-CoT 主要由兩個階段組成：
- 階段1：問題聚類：將給定問題劃分為幾個聚類
- 階段2：演示抽樣：從每組陣列中選擇一個具有代表性的問題，並使用帶有簡單啟發式的 Zero-Shot-CoT 生成其推理鏈
例如，如果問題是“如果一個蘋果的重量是150克，那麼10個蘋果的總重量是多少？”，Auto-COT模型可能會生成這樣的思維鏈：“10個蘋果的總重量 = 10 * 150克 = 1500克”。這樣，使用者不僅得到了答案，還了解了模型是如何得出這個答案的。
在運維的告警源頭判斷做輔助，或者故障處理建議等方面可以產生不錯的效果，也降低新人工技能培訓的投入，更容易讓運維人員統一視角與標準。
TOT（Tree of Thought） 思維樹
這裡我可能需要特別說一下思維樹這個框架，“TOT思維樹"並不是一個廣泛認可或標準的術語，因此其具體定義可能在不同的上下文或領域中有所變化。但我們可以基於“思維樹”的概念來理解它可能的含義。
思維樹（Tree of Thoughts）是一種用於表示和組織思考過程的結構化方法，它以樹狀圖的形式展示思考的層次和分支。在決策制定、問題解決、創意生成等場景中，思維樹可以幫助人們系統地探索各種可能性，評估不同選項，從而做出更明智的決策。
在思維樹中：
- 根節點：通常代表問題或決策的起點，即需要解決的核心問題。
- 分支：從根節點開始，每個分支代表一個可能的思考方向或解決方案。分支可以進一步細分，形成更詳細的子分支，代表更具體的思考步驟或子問題。
- 葉節點：樹的末端，代表思考過程的最終結果或結論。
透過構建思維樹，人們可以：
- 系統地探索：確保所有可能的思考方向都被考慮，避免遺漏重要的資訊或解決方案。
- 評估和比較：透過比較不同分支的結果，評估各種選項的優劣，做出更合理的決策。
- 增強理解：透過視覺化思考過程，增強對問題的理解，使複雜的決策過程變得清晰。
目前針對TOT我們還沒有得到特別好的效果，可能是在構建當中還有不合理的定義或者解析問題不精準的存在。但從對於資源的合理性投入，供應鏈的管理，提高決策質量和效率它應該是有天然的優勢存在，如果有哪位大佬對TOT有深度嘗試並有合理化建議的，請給出更多的好的建議，在此先謝過了。
ReAct （Retrieval-Augmented Generation for Thinking and Acting）
其實對於這個框架，我個人總結來看，可以理解為是一種結合了推理和行動的新型人工智慧框架，主要用於增強AI系統在複雜環境中的決策能力和執行效率。ReAct框架的核心思想是透過實時檢索相關資訊和執行基於這些資訊的行動，來輔助AI系統進行更準確的推理和決策。
在ReAct框架中，AI系統不僅依賴於其預訓練的知識，還會在遇到新情況時，主動檢索外部資訊（如資料庫、網路資源等），並將這些資訊整合到其決策過程中。這一過程可以看作是AI系統在“思考”（Reasoning）和“行動”（Acting）之間的迴圈，其中：
- 思考（Reasoning）：AI系統基於當前狀態和目標，進行推理和規劃，確定下一步需要採取的行動或需要檢索的資訊。
- 行動（Acting）：根據推理結果，AI系統執行相應的行動，如檢索資訊、執行任務等。
- 反饋：AI系統根據行動的結果，更新其狀態和知識，然後再次進入思考階段，形成一個閉環。
ReAct框架的優勢在於，它使AI系統能夠適應不斷變化的環境，處理之前未見過的情況，而不僅僅是依賴於預訓練資料。透過實時檢索和整合新資訊，AI系統可以做出更準確、更靈活的決策，提高其在複雜任務中的表現。
總結來說：ReAct 是Reason + Action，而Cot、ToT 則只是 Reason。ReAct 與 CoT和ToT 的本質區別，就是ReAct不止在推理，還在利用外部工具實現目標，我不知道這裡解釋大家是不是能明白..
運維場景應用
- 告警分析與故障處理：利用CoT與Auto-CoT輔助故障診斷，提供決策支援。
- 資源管理與最佳化：TOT框架幫助系統化分析資源分配，提升運維效率。
- 動態決策與執行：ReAct框架在複雜運維場景中，實現基於實時資訊的決策與行動
透過深度探索與實踐，我們正逐步構建基於LLM的運維體系，旨在提升運維效率與可觀測性。未來，我們將繼續探索更多創新場景，推動AI技術在運維領域的廣泛應用，期待與更多同行攜手，共同開創運維智慧化的新篇章。
本文旨在分享AI在運維領域的實踐與思考，透過Semantic Kernel、LangChain、RAG、Fine-Tuning等技術，結合Prompt工程與推理架構，探索如何有效提升運維效率與可觀測性。期待與更多技術探索者和實踐者共同推動AI在運維領域的創新與發展
本文源自第二屆 CCF·夜鶯開發者創新論壇，夜鶯是一個開源監控系統，近 1 萬 github star，專案地址： https://github.com/ccfos/nightingale 收藏備用