Aptible AI 的工程團隊在過去約 4 個月內建立了一個 AI 代理,以幫助我們的 SRE 團隊調查和解決生產問題。因為我們已經與許多早期測試人員和設計合作夥伴進行了交談,他們正在為類似的目的構建自己的代理,所以我們決定編寫一個指南來解釋我們使用自己的代理所做的事情以及如何構建一個你自己。
在以下逐步教學中,我們將向您展示如何:
但首先,有一些注意事項和專業提示。
? 注意事項:如果你不需要建造新的東西,那麼你就不應該。有這樣的。許多。市面上的工具。根據您的具體用例,您也許能夠找到適合您的一個。
Aptible 搜尋和最終開發我們自己的事件回應的動力是我們與知識孤島作鬥爭,並且每當我們遇到特定係統的問題時都傾向於依賴三到四個主題專家。
因此,我們開始使用名為 Danswer 的開源工具來改善資訊檢索(類似於其流行的商業競爭對手 Glean)。它直接插入 Slack,可以從各種資訊來源檢索自然語言問題的答案。問題是它僅限於索引資料(即,只有我們的文件和聊天歷史記錄)。
⚒️ 我們建構的:我們需要的是一個可以與我們所有其他系統(不僅僅是文件和 Slack)整合的工具。我們需要檢索日誌和指標、應用程式運行狀況,並在事件結束後產生報告和事後分析。因此,我們設計了一個人工智慧代理,它本質上是建立在一系列整合的基礎上的,可以讓您連接即時數據和索引數據。稍後會詳細介紹!
? 專業提示:在決定建造自己的產品之前,請先了解現有的產品。一個很好的起點可能是從 Reddit 眾包想法(查看這個帖子)或查看一些開源工具(如果您正在專門尋找事件響應工具,那麼 github 是一個很好的起點) )。還有一長串開源 AI 代理程式可供您明天開始使用。
? 注意事項:如上所述,這裡最大的考慮因素是:您需要您的代理商存取哪些類型的資訊?您也許可以簡單地透過 API 將其與第三方提供者集成,但如果您需要集成更具體地滿足您的需求,那麼您需要更仔細地考慮集成的工作方式。
透過在開始建造之前仔細考慮需要整合的內容,您將在以後避免一些頭痛。您是否需要代理程式能夠執行自訂腳本來查詢資料庫?您是否需要即時檢索日誌和指標?您將如何設計代理來檢索該資訊?它會返回來源連結嗎?它會傳回一大堆您仍然需要手動篩選的日誌行,還是能夠推斷出異常可能在哪裡?
⚒️ 我們建構的內容: Aptible AI 的核心是建立在一系列整合之上。整合不僅僅是與第三方提供者的連接,它還是我們團隊使用該提供者的獨特配置的集合。例如,Aptible AI 支援同一提供者的多個集成,因為我們可能希望以不同的方式使用該提供者。不同的團隊使用 Datadog 的方式不同,專注於不同的指標或使用不同的標籤,因此每個團隊都可以按照自己需要的方式使用與相同工具的整合。
Aptible AI 支援一系列常見的 SRE 工具,包括:
這些整合的實際實作符合可自訂性的三個類別之一:
對於初學者來說,您有一個不需要自訂的基本整合(PagerDuty 就是一個例子)。由於它只是從 PagerDuty 中提取資料並將其添加到 AI 上下文中,因此每個利用 PagerDuty 整合的團隊都以相同的方式使用它。
接下來,我們有更多可自訂的整合(如先前的 Datadog 範例),這些整合建構在通用 InfluxDB 整合之上,但針對查找容器指標和查找重啟活動的特定用例進行了客製化。
最後,有一些完全自訂的工具可能對 Aptible 以外的任何人都沒有意義(這裡的一個例子是我們為應用程式取得容器的整合)。這些完全特定於我們運行基礎設施的方式,可以透過輕量級 PubSub 介面或基於 Websocket 的「安全」代理來實現。
? 專業提示:少即是多!如果你給模型太多的工具可供選擇,它可能會開始選擇不正確的工具並使自己感到困惑。下一節將詳細介紹
? 注意事項:這是模型的問題…每天都會出現新的模型,在選擇模型時需要記住幾個注意事項(主要與您的特定用例有關)。您應該自行託管嗎?您需要您的代理是對話式的還是基於任務的,或者兩者兼而有之?它將執行簡單還是複雜的任務?您需要即時效能嗎?
我們沒有必要遍歷所有存在的模型,因為內容已經遍布各處(如果您想深入了解,這是一個很好的資源),但我們可以遍歷我們所做的決定在構建Aptible AI 時要做的事情以及我們考慮的選項。
這是一個棘手的過程,因為你無法真正避免權衡。如果你需要你的 Agent 來執行複雜的任務,那麼你就必須在速度和成本上做出一些犧牲。
模型的大小、功能和架構在很大程度上取決於任務是否需要簡單的分類或高度複雜的推理和互動。如果簡單,一個較小的、輕量級的模型(如決策樹、隨機森林或簡單的神經網路)就足夠了。如果更複雜,那麼您可以考慮更強大的模型,例如 GPT-4、BERT 或類似的基於 Transformer 的架構。
如果您選擇自架以避免安全問題,您可能不得不犧牲特性和功能,因為您的自架版本將落後於託管選項。
如果您需要您的代理商接受特定領域知識的培訓,那麼您需要策劃或建立自己的資料集以進行微調。看看您是否可以使用已經在大型資料集上訓練過的預訓練模型來避免資料品質問題(儘管這可能是不可能的,具體取決於您需要代理存取的資料)。
⚒️ 我們建造的內容:我們目前正在將 GPT-4o 用於 Aptible AI,因為我們相信它最有可能為我們提供最高品質的答案。但是,我們認識到使用 Aptible AI 的客戶可能希望使用自己的模型(包括自架模型)。因此,我們在構建時牢記這一點。
? 專業提示:您的代理商的聰明程度取決於您提供的資訊。法學碩士需要幫助了解如何以及何時使用您提供的信息,如果您不向其提供如何解釋信息的說明,它只會編造一些東西。預先花費真正的精力來整理您提供給法學碩士的資訊!
? 注意事項:您可能會想要檢索盡可能多的資料(文件、Slack 對話、程式碼儲存庫、問題追蹤器等),將其全部丟到RAG 應用程式中*、 * 並向它提問。但根據我們的經驗,幾乎總是會出現太多噪音,以至於無法發揮作用。這就是快速工程的用武之地。
我們已經提到過這一點,但提示工程是這裡難題的關鍵部分(有關提示技術的詳細概述,請查看此內容)。你的即時工程越好,你的特工就越好。
就上下文而言,以下是我們在建造 Aptible AI 時(隨著時間的推移)考慮的一些內容:
零次提示:這是大多數人在與 ChatGPT 交談時所做的;他們只是問一個問題然後得到答案。如果反應不好,那麼他們只是以不同的方式提出問題。
少量提示:這是稍微有經驗的人在與 ChatGPT 交談時所做的事情;他們向它提出一個問題,並提供他們想要的輸出的範例。您可以使用零次和/或幾次提示來執行底層模型已經知道如何執行的非常簡單的任務。
檢索增強生成(RAG):這是一種允許模型檢索額外上下文並用它來回答問題的技術。這對於人工智慧驅動的文件搜尋特別有用(另請參閱:Glean 和 Danswer)。
ReAct:此技術允許代理以迭代方式產生「想法」並採取「行動」來解決問題,最類似於人類推理。 ReAct 非常適合中等複雜的問題,例如透過文件和工具即時導航參考以撰寫答案。
需要記住的重要一點是,您可以混合搭配這些技術(接下來我們將介紹多代理方法)。這就是我們所做的......
⚒️ 我們建構的:因為 Aptible AI 具有多代理結構(稍後將詳細介紹),所以我們根據任務/問題的複雜性實現了 ReAct 和 RAG 的混合。
因此,當您向人工智慧提出問題時,我們會將所有整合(以及如何使用它們的說明)交給人工智慧。然後,人工智慧根據其可用的信息決定調用哪些工具。每次整合呼叫後,人工智慧可以選擇確定它有足夠的資訊來提供答案,或者確定其他整合是相關的並且可能會產生其他資訊。
在整個過程中,我們試圖透過幾種不同的機制來幫助人工智慧更好地決定要利用哪些整合:
針對集成的廣泛提示工程,以確保真正清楚何時以及如何使用每個集成,以及如何解釋輸出。
我們建構了一個自我評估系統,要求人工智慧對整合回應的價值進行自我評估。即使人工智慧在調用整合時做出了愚蠢的決定(或提供了錯誤的輸入),如果您要求它自我評估整合的輸出是否有用,它通常也能夠在事後認識到這一點。然後我們可以用它來影響特定輸出對響應的影響程度。如果人工智慧持續做出錯誤的決定,我們也可以阻止它繼續進行。
我們根據過去的經驗實作了樸素貝葉斯。例如,如果大多數時候您呼叫整合 A,然後呼叫 B,並且這會產生有用的結果,那麼繼續這樣做可能會很有用。代理還可以使用諸如與先前的類似事件進行比較之類的方法來進一步縮小整合的有用範圍以及在特定場景中何時有用的範圍。
? 專業提示:為了避免聽起來正確但實際上並非如此的無意義答案,請務必退後一步,考慮對於您嘗試使用人工智慧解決的問題,最有用的信息通常來自哪裡– 然後基於此設計你的代理商。
? 注意事項: 多代理方法變得越來越流行,但根據您的用例,它們可能很複雜且可能沒有必要。讓一個代理團隊使用不同的技術一起工作來解決複雜的問題是非常有用的。
例如,如果您在Slack 中向機器人詢問一個與您的特定基礎設施無關的問題(也許您只是想知道誰贏得了1995 年世界職業棒球大賽),您可以擁有一個基於零樣本構建的代理提示您只需充當與您的Slack(或您擁有的任何地方)整合的ChatGPT。
但是,如果您的問題或需求很複雜,那麼擁有一個代理團隊基本上就像您的小研究團隊一樣,以智能的方式收集和分析來自不同來源的數據會很有用。
⚒️ 我們建構的內容: Aptible AI 使用多代理方法,從確定需要解決什麼類型的問題或任務的代理代理開始。
? 專業提示:重構為多代理方法比重構更容易!因此,在開始以這種方式建立代理之前,請確保您需要它。
? 注意事項:這是我們與 Aptible AI 早期用戶聊天時經常出現的話題。大多數工程團隊在實施新工具時最終都必須面對他們的安全團隊,確保資料安全至關重要(特別是如果您在高度監管的行業中工作)。因此,您要做的第一件事就是了解組織的 AI 安全策略,然後您可以採取一些措施來防止潛在的資料外洩或外部威脅。
⚒️ 我們建立的內容: 對於初學者,我們使用的模型不訓練我們的資料。我們仍在圍繞客戶對安全的需求進行大量探索,無論是自託管還是其他!請繼續關注。
? 專業提示: 請謹慎對待您授予 AI 存取權限或包含在提示中的數據,尤其是不應與最終用戶共享該數據的情況下!如果您需要包含不可預測的資料(例如日誌),請考慮使用像 Nightfall 這樣的工具,以確保傳遞給 LLM 和最終用戶的內容已清理
哦,當然,它必須可用!
? 注意事項:您打算如何使用您的代理商?它需要有 UI 嗎?它會在整個組織中使用嗎?
當涉及機器人的使用者體驗時,您可能不需要花時間重新發明輪子。 Chainlit、Gradio 和 Streamlit 等框架為您提供了開箱即用的工具,用於建立使用者介面和/或與 Slack 等其他工作流程工具整合。使用這些工具之一開始,這樣您就可以專注於從您的代理商那裡獲得好的答案!
⚒️ 我們建構的: 因為我們的 Agent 是專門為事件回應而建構的,並且因為我們在 Slack 中處理事件,所以我們主要使用 Slack 作為我們的 UI。不過,它有其局限性,因此我們盡力解決這些問題(即,機器人不是通過模仿 ChatGPT 中的打字來顯示代理正在響應,而是用“?”表情符號對 Slack 中的問題做出反應)。我們還設計了一個用於配置、報告、審核和分析的 Web UI。
? 專業提示: 請確保您的 LLM 程式碼盡可能解耦,以便在需要時可以輕鬆重構為另一個 UX。
好吧,讓我們繼續理論討論模型、技術和框架!是時候開始動手建立自己的代理了。
在我們深入研究建造 AI 的無盡兔子洞之前,我們將透過建立 Chainlit,一個用於建立對話助理介面的流行框架來為成功做好準備。
Chainlit 提供了一組用於建模對話互動的自以為是的構建塊(例如線程、訊息和步驟),以及用於與 LLM 互動的類似 ChatGPT 的使用者介面。
它還提供與Slack 和Teams 等流行聊天工具的開箱即用集成,以及與React 和FastAPI 等流行工具接口的庫,因此您可以根據需要將其構建到更大的應用程序中.
簡而言之:Chainlit 將為我們消除大量腳手架和繁瑣的工作,以便我們可以專注於開發 AI 助理並獲取用戶的反饋,而不是擺弄 UI 和配置。
在本實驗結束時,您將擁有一個可以運行的 Chainlit 應用程序,它可以簡單地回顯您所說的內容。我們將在下一篇文章中討論人工智慧整合。
在我們開始之前,您需要進行一些設定:
設定完成後,繼續。
首先,設定您的項目,並將 chainlit 新增為依賴項:
mkdir roger cd roger poetry init --no-interaction poetry add chainlit
接下來,在專案的根目錄中建立一個 app.py 文件,其中包含以下內容:
import chainlit as cl @cl.on_message async def handle_message(message: cl.Message) -> None: # Echo the message back to the user. await cl.Message( content=f"Received: {message.content}", ).send()
上面的程式碼是向Chainlit註冊handle_message函數,這樣每當收到訊息時,這個函數就會運行。
目前,我們的函數只是將訊息回顯給用戶,並以「已接收:」為前綴。
最後,旋轉起來!當您進行變更時,您可以使用 --watch 熱重新載入程式碼。
poetry run chainlit run app.py --watch
執行此命令將啟動您的 Chainlit 應用程式並將瀏覽器開啟到其 UI,您可以在其中發送訊息並獲取回應:
透過我們的 Chainlit 應用程式支架,我們可以將其連接到 LLM,以便我們可以與其交談並獲得類似人類的回應。
為了簡單起見,我們將使用 OpenAI 的託管 gpt-4o 模型,但使用其他提供者只是語法問題。
在本文結束時,您將能夠提示 gpt-4o 模型並獲得回應,類似於與 ChatGPT 互動的方式。我們還將確保機器人維護對話上下文,以便您可以提出後續問題。
開始之前,您需要:
一個 OpenAI 帳戶和一個 API 金鑰
首先,我們將設定一個 API 用戶端以與 OpenAI 的 API 進行互動。將以下程式碼加入 app.py 的頂部:
mkdir roger cd roger poetry init --no-interaction poetry add chainlit
接下來,我們需要更新我們的handle_message函數來將使用者的訊息傳送到OpenAI並獲得回應,而不是只回顯它。將您的handle_message 函數替換為以下函數:
import chainlit as cl @cl.on_message async def handle_message(message: cl.Message) -> None: # Echo the message back to the user. await cl.Message( content=f"Received: {message.content}", ).send()
現在,如果您執行應用程式(或使用 --watch 標誌讓它運行),您將能夠提出問題並獲得回應。
如果您玩過一些遊戲並提出了後續問題,您可能會注意到機器人不會「記住」您談論過的任何內容。例如:
發生這種情況是因為每次我們發送訊息時,我們只向 LLM 發送一條訊息,預設情況下沒有「對話」的概念。
為了治癒這種健忘症,我們需要在每次發送新訊息時發送對話中的所有訊息。
Chainlit 透過提供 cl.chat_context.to_openai() 幫助器讓我們輕鬆實現這一點,它以 OpenAI(和大多數其他提供者)期望的格式方便地為我們提供迄今為止交換的所有訊息。
更新你的handle_message函數以將歷史訊息加入最新消息之前:
poetry run chainlit run app.py --watch
現在我們可以提出後續問題了!
完成第 1 部分的前幾個步驟後,您可能已經註意到,當您提出需要長時間答复的問題時,在看到任何內容之前會出現延遲。
這可能會導致糟糕的使用者體驗(尤其是在第 3 部分的後面,當我們開始添加長時間運行的工具呼叫時),所以讓我們解決這個問題。
在此步驟結束時,您將能夠即時看到您的機器人「輸入」內容,類似於 ChatGPT。
為了獲得即時訊息更新,我們需要更新我們的實作以使用「流」。基本上,每當我們收到一條訊息時,我們都會立即回覆一條空訊息,使用 LLM 啟動一個串流,並在每次從串流中收到新的回應區塊時更新我們的空訊息。
這聽起來可能很複雜,但其實非常簡單!更新你的handle_message函數如下:
mkdir roger cd roger poetry init --no-interaction poetry add chainlit
? ? 所以,這是迄今為止的完整程式碼:
import chainlit as cl @cl.on_message async def handle_message(message: cl.Message) -> None: # Echo the message back to the user. await cl.Message( content=f"Received: {message.content}", ).send()
現在,當您提出問題時,您應該會看到您的機器人即時「打字」!
至此,我們已經建構了 ChatGPT 的輕量級克隆。這很酷,但我們真正想要的是一個能夠幫助我們執行特定任務的助手:在這種情況下,我們希望它能像 SRE 一樣解決事件問題。
為了實現這一目標,我們首先將代理重構為自訂 OpenAI 助手,這將使我們能夠控制系統提示(以及讓 LLM 能夠存取檔案搜尋和函數呼叫等工具,我們稍後會介紹)。
到這一步驟結束時,您將把您的機器人重構為自訂“助手”,並自訂其係統提示以賦予其自己的“個性”。您的程式碼還將使用“線程”,它將使用 OpenAI API 保存訊息,而不必每次收到新訊息時都發送所有訊息。
建立助理很簡單:我們只需要呼叫 OpenAI Assistants API 即可。但是,我們只想在應用程式啟動時執行一次此操作,因此我們不能將該 API 呼叫放在handle_message 函數中。
相反,我們將使用另一個 Chainlit 鉤子 - on_chat_start,它只會在應用程式首次啟動時運行一次 - 來設定我們的助手。
將其新增至您的 app.py:
poetry run chainlit run app.py --watch
注意:技術上可以透過在handle_message的訊息歷史記錄中提供初始系統類型訊息來為助理提供自訂系統提示。然而,我們正在重構一個具有自訂指令的助手,因為它解鎖了我們將在不久的將來使用的其他幾個功能。
現在我們有了一個用於對話的助手和一個線程,我們可以重構我們的訊息處理程序來使用它們。
首先,我們需要一個 AssistantEventHandler 來告訴我們的新 Assistant 物件如何處理對話期間發生的各種事件。
將以下內容加入您的 app.py:
import os from openai import AsyncOpenAI ## # Settings # try: OPENAI_API_KEY = os.environ["OPENAI_API_KEY"] except KeyError as ex: raise LookupError(f"Missing required environment variable: {ex}") client = AsyncOpenAI(api_key=OPENAI_API_KEY) # ...
現在,我們只需要調整我們的handle_message函數就可以使用我們所有的新玩具了!將您的handle_message函數更新為以下內容:
# ... @cl.on_message async def handle_message(message: cl.Message) -> None: # Retrieve the response from the LLM response = await client.chat.completions.create( messages=[{"content": message.content, "role": "user"}], model="gpt-4o", ) await cl.Message(content=response.choices[0].message.content).send()
? ? 現在這是迄今為止的完整程式碼:
mkdir roger cd roger poetry init --no-interaction poetry add chainlit
現在我們正在使用助手和線程,我們可以開始自訂行為。首先,我們將授予 Google 助理存取一些內部文件的權限,以便它可以提供更適合我們的用例的回應。
在本節結束時,您的機器人將能夠在回應提示時搜尋文件集合(例如,您的 SRE 運作手冊和其他內部文件)。
為了簡單起見,我們將其實作為一個充滿文件的資料夾,這些文件上傳到向量儲存並提供給我們的助手。
我們需要做的第一件事是建立一個向量儲存並將其提供給我們的助理。
首先,更新我們的handle_chat_start函數的開頭以包含以下內容:
import chainlit as cl @cl.on_message async def handle_message(message: cl.Message) -> None: # Echo the message back to the user. await cl.Message( content=f"Received: {message.content}", ).send()
接下來,更新對 client.beta.assistants.update() 的調用,以使助手能夠存取向量儲存並啟用 file_search 工具。
poetry run chainlit run app.py --watch
最後,我們需要上傳我們希望助手在回答提示時參考的文件。
首先,我們需要建立一個資料夾來放置文件:
import os from openai import AsyncOpenAI ## # Settings # try: OPENAI_API_KEY = os.environ["OPENAI_API_KEY"] except KeyError as ex: raise LookupError(f"Missing required environment variable: {ex}") client = AsyncOpenAI(api_key=OPENAI_API_KEY) # ...
接下來,我們將收集文件並將其放入該資料夾中。出於測試目的,我已將以下虛假文件添加到我的資料夾中:
# ... @cl.on_message async def handle_message(message: cl.Message) -> None: # Retrieve the response from the LLM response = await client.chat.completions.create( messages=[{"content": message.content, "role": "user"}], model="gpt-4o", ) await cl.Message(content=response.choices[0].message.content).send()
最後,我們將更新 handle_chat_start 函數,以自動將文件上傳到我們先前建立的向量儲存中。在我們創建向量儲存的位置之後加入以下程式碼:
# ... @cl.on_message async def handle_message(message: cl.Message) -> None: # Retrieve the response from the LLM response = await client.chat.completions.create( messages=[ # Prepend all previous messages to maintain the conversation. *cl.chat_context.to_openai(), {"content": message.content, "role": "user"} ], model="gpt-4o", ) await cl.Message(content=response.choices[0].message.content).send()
ℹ️ 注意: 目前,我們僅支援 .md 文件,但 OpenAI 支援許多不同的文件類型,因此請隨意將 glob 模式更新為對您的用例有意義的任何內容!
這將自動上傳 ./docs 資料夾中的所有檔案並將它們新增至我們的向量儲存。
檔案搜尋有時可能需要一段時間,尤其是對於較大的資料集。在這些情況下,您可能想讓用戶知道發生了什麼,這樣他們就不會感到沮喪。
幸運的是,Chainlit 透過提供 Step 類別讓這一切變得簡單,我們可以用它來告訴使用者後台正在發生什麼事情。我們可以將 Step 類別與我們先前建立的 MessageEventHandler 結合使用,並在任何呼叫工具時新增指示器。
將以下內容新增至您的 MessageEventHandler:
# ... @cl.on_message async def handle_message(message: cl.Message) -> None: # Send an empty initial message that we can update with a streaming # response. message = cl.Message(content="") await message.send() # Stream the response from the LLM stream = await client.chat.completions.create( messages=[ # Prepend all previous messages to maintain the conversation. *cl.chat_context.to_openai(), {"content": message.content, "role": "user"} ], model="gpt-4o", stream=True, ) # Update the existing (initially-empty) message with new content # from each "chunk" in the stream. async for chunk in stream: if token := chunk.choices[0].delta.content: await message.stream_token(token) # Send a final update to let the message know it's complete. await message.update()
現在您已經上傳了一些自己的文檔,請嘗試提出一些更具體於您的用例的問題,看看您會得到什麼!
對於我們的測試案例,當被問及客戶資料庫上的高 CPU 使用率時,它正確引用了我們的運行手冊:
? ? 作為參考,這是迄今為止的完整程式碼:
mkdir roger cd roger poetry init --no-interaction poetry add chainlit
我們的代理現在可以從我們精選的內部文檔中檢索數據,如果您有良好的文檔,這將非常有用。然而,事件管理的大量時間通常花在調查文件未涵蓋的事情上:掃描警報、讀取日誌、解釋指標等。
對於這些事情,我們希望讓我們的助手能夠呼叫外部 API - 更廣泛地說,執行我們定義的函數 - 以便它可以根據需要收集更多上下文。
為此,我們將利用模型的「函數呼叫」功能來執行我們定義的函數。
在本節結束時,您將讓您的機器人在回答提示時使用外部工具(一個假的 PagerDuty 工具)來檢索資訊。
首先,讓我們在 app.py 中新增一個名為 get_pagerduty_alert_details 的新函數。
import chainlit as cl @cl.on_message async def handle_message(message: cl.Message) -> None: # Echo the message back to the user. await cl.Message( content=f"Received: {message.content}", ).send()
接下來,我們要告訴LLM如何呼叫我們的工具。 OpenAI 需要 JSONSchema 格式的工具定義。
更新對 client.beta.assistants.update() 的調用,以在我們已有的 file_search 工具之後包含新的工具定義。
poetry run chainlit run app.py --watch
我們的 MessageEventHandler 目前處理來回訊息事件,但呼叫工具需要一些特殊處理。
在回應您的提示時,LLM 將決定應呼叫哪些工具(如果有),並在回應負載中傳回一個或多個「工具呼叫」定義,並告訴您該回應「需要採取行動」。為了實際執行函數,我們需要處理這些“需要操作”響應。
我們可以透過更新 MessageEventHandler 類別來實作 on_event 方法,以及用於執行函式呼叫並將結果新增至正在執行的執行緒的新的 handle_requires_action 方法來實現此目的:
import os from openai import AsyncOpenAI ## # Settings # try: OPENAI_API_KEY = os.environ["OPENAI_API_KEY"] except KeyError as ex: raise LookupError(f"Missing required environment variable: {ex}") client = AsyncOpenAI(api_key=OPENAI_API_KEY) # ...
提醒法學碩士應該在適用時嘗試使用您提供的工具通常會很有幫助。在提示符號末尾新增以下一行:
使用提供的工具收集有關事件的其他背景資訊(如果適用)。
配置好工具後,您將能夠在提示中包含 PagerDuty 鏈接,LLM 將在回答之前使用這些工具收集上下文:
? ? 完整程式碼如下:
mkdir roger cd roger poetry init --no-interaction poetry add chainlit
現在您已經準備好為您的 SRE 團隊建立一個有用的 AI 代理程式了!如果您對本指南中介紹的任何內容有任何疑問,請聯絡我們,我們將很樂意為您提供協助。同時,如果有任何遺漏或您想學習任何其他與 AI Agent 相關的內容,請告訴我們!
如果您想親自嘗試 Aptible AI 而不是建立自己的 Agent,可以造訪 www.aptible.ai 進行註冊。
以上是指南:如何為 SRE 團隊建立 AI 代理的詳細內容。更多資訊請關注PHP中文網其他相關文章!