使用 Knative 的 LLM 代理:一個演示 ¶
發佈於:2024-07-26
使用 Knative 的 LLM 代理:一個演示¶
作者:Calum Murray,Red Hat 軟體工程實習生
在先前關於 LLM 代理的部落格文章中,我們討論了什麼是 LLM 代理、LLM 如何呼叫工具,以及如何使用 Knative 來自動化 LLM 代理的工具呼叫流程。在這篇部落格文章中,我們將探討一個具體的範例,說明如何使用 Knative 來建置 LLM 代理應用程式,以處理工具呼叫和探索,並解釋此方法與建置 LLM 代理的其他常見方法有何不同。
使用 Knative 的 LLM 代理範例¶
為了展示使用 Knative 處理工具探索和呼叫的 LLM 代理的強大功能,我們將建置一個簡單的聊天應用程式,該應用程式能夠回答關於我們正在執行的虛構應用程式所使用資源成本的問題。具體來說,在我們的應用程式中,我們有興趣準確回答以下問題:
在過去幾個月中,我的應用程式的平均資源消耗量(CPU、記憶體)趨勢如何變化?這將對我的成本產生什麼影響?
首先,我們將按照 https://github.com/keventmesh/llm-tool-provider 中的 README 說明,將 Knative LLM 工具提供者示範部署到我們有權存取的叢集中。從此儲存庫部署聊天應用程式後,我們可以透過執行下列方式存取它:
kubectl port-forward svc/chat-app-service 8080:8080
如果您在瀏覽器中存取 https://#:8080
,您現在就可以看到正在執行的聊天應用程式,並提出我們的簡單問題。當我在撰寫這篇部落格文章時嘗試時,互動是:
Calum
在過去幾個月中,我的應用程式的平均資源消耗量(CPU、記憶體)趨勢如何變化?這將對我的成本產生什麼影響?
LLM 代理
您能否提供我過去幾個月您的應用程式平均資源消耗量(CPU、GPU、記憶體)的資料?
如果您嘗試執行此操作,您可能會注意到您的 LLM 代理回覆類似,並且 UI 將在任務清單中指示一個名為「human」的任務。這是 LLM 呼叫我們範例應用程式中唯一手動編碼的工具:一個要求使用者(人類)提供更多資訊,然後再繼續回答問題的工具。
從這次互動中,我們可以發現 LLM 尚未能回答我們的問題:它沒有關於資源消耗或與資源消耗相關聯的成本的資訊。為了讓 LLM 具備這些功能,我們需要告訴它關於我們在範例應用程式設定中部署到叢集中的兩個 Knative 函式:average-resource-consumption
和 resource-cost-calculator
。若要執行此操作,我們需要將兩個 EventTypes 套用至我們的叢集中,這兩個 EventTypes 描述了這些函式預期的合約
apiVersion: eventing.knative.dev/v1beta2
kind: EventType
metadata:
name: average.resource.consumption
spec:
reference:
apiVersion: serving.knative.dev/v1
kind: Service
name: average-resource-consumption
description: "This tells you the average resource consumption for recent months"
type: "average.resource.consumption"
---
apiVersion: eventing.knative.dev/v1beta2
kind: EventType
metadata:
name: resource.cost.calculator
spec:
reference:
apiVersion: serving.knative.dev/v1
kind: Service
name: resource-cost-calculator
description: "This calculates the cost for a given resource kind and average usage over a month. Use this tool whenever there is a question about the cost of any cloud resources"
schemaData: '{"resourceKind":{"type":"string","description":"The type of resource you would like to calculate the cost of"},"usage":{"type":"float","description":"The average usage of the resource"},"unit":{"type":"string","description":"The unit of the resource usage"}}'
type: "resource.cost.calculator"
這兩個 EventTypes 都參考了我們稍早執行的安裝腳本中部署的函式。一個函式傳回過去幾個月的一些模擬使用資料,另一個函式能夠計算特定月份特定資源類型的使用成本。
我們建置的 LLM 代理程式會程式設計為在新的使用者會話開始時擷取叢集中的所有 EventTypes,並將其對應到它可以使用的工具中。在套用兩個 EventTypes 並重新整理我們的瀏覽器後,我們可以再次嘗試提出我們最初的問題
Calum
在過去幾個月中,我的應用程式的平均資源消耗量(CPU、記憶體)趨勢如何變化?這將對我的成本產生什麼影響?
LLM 代理
您的應用程式在過去幾個月的平均資源消耗量趨勢如下
- 3 月:CPU - 21.33 核心,記憶體 - 8200 MiB
- 4 月:CPU - 27.56 核心,記憶體 - 8117 MiB
- 5 月:CPU - 33.17 核心,記憶體 - 9217 MiB
- 6 月:CPU - 34.51 核心,記憶體 - 10117 MiB
為了確定對您成本的影響,我將根據每種資源在一個月內的平均使用量來計算 CPU 和記憶體的成本。讓我們繼續進行成本計算。根據過去幾個月您的應用程式的平均資源消耗量,對您成本的估計影響如下
- CPU 成本:$448.28
- 記憶體成本:$161.87
這些成本是根據 CPU 和記憶體資源的每月平均使用量計算得出的。如果您有任何其他問題或需要進一步協助,請隨時提問!
查看工具視窗,我們可以發現 LLM 呼叫了我們提供給它的兩個工具,而且答案顯然更精確且品質更高!
我們剛才所做的事情真正強大的地方並不在於 LLM 能夠使用工具更準確地回覆使用者,而是 LLM 能夠在*不重新部署 LLM 應用程式* 的情況下使用工具更準確地回覆使用者。我們已將工具的開發和部署與 LLM 代理的開發和部署解耦!
現在,我們能夠透過事件類型 (EventTypes) 這個媒介,以宣告式的方式將這兩個元件綁定在一起。建構大型語言模型 (LLM) 代理程式的人員不需要擔心它可以存取哪些工具或如何調用它們,而工具開發團隊可以在不了解 LLM 代理程式程式碼庫的情況下,讓它存取他們的工具。此外,由於我們只提供了關於服務的中繼資料給 LLM,我們現在可以建立事件類型來描述我們已經建好的現有服務,LLM 代理程式將能夠在無需變更程式碼的情況下,成功地與這些系統互動。
LLM 代理程式透過使用中繼資料自動發現工具的概念,是我們正在努力建構的核心概念。在下一篇部落格文章中,我們將討論我們對此概念未來發展的願景。如果您有興趣協助我們建構雲端 LLM 代理程式的未來,請在 CNCF Slack 頻道 上與我們聯繫!