使用 Knative 的 LLM 代理：演示 ¶

发布时间：2024-07-26

使用 Knative 的 LLM 代理：演示¶

作者：Calum Murray，红帽软件工程实习生

在关于 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://127.0.0.1:8080，您现在将能够看到正在运行的聊天应用程序，并向它询问我们的简单问题。当我编写这篇博文时尝试过，交互方式如下

Calum

在过去几个月里，我的应用程序的平均资源消耗（CPU、内存）趋势如何变化，这对我的成本有何影响？

LLM 代理

您能提供过去几个月的应用程序的平均资源消耗（CPU、GPU、内存）数据吗？

如果您尝试一下，您可能会注意到您的 LLM 代理的回复类似，并且 UI 会在任务列表中指示一个名为“human”的任务。这是 LLM 调用我们示例应用程序中唯一一个手工编码的工具：一个在继续回答问题之前向用户（人）索取更多信息的工具。

从这种交互中，我们可以看到 LLM 还没有能力回答我们的问题：它没有关于资源消耗或与该资源消耗相关的成本的信息。为了赋予 LLM 这些能力，我们需要告诉它我们在示例应用程序设置中部署到集群中的两个 Knative 函数：average-resource-consumption 和 resource-cost-calculator。为此，我们需要将描述这些函数期望的契约的两个 EventType 应用到我们的集群中

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"

这两个 EventType 都引用了我们在之前运行的安装脚本中部署的函数。一个函数返回过去几个月的模拟使用数据，另一个函数能够计算特定月份特定资源类型的使用成本。

我们构建的 LLM 代理被编程为在每次新用户会话开始时获取集群中的所有 EventType，并将这些 EventType 映射到它可以使用的工具。在应用了这两个 EventType 并刷新浏览器之后，我们可以尝试再次询问我们的原始问题

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 代理的开发和部署解耦了！

现在，我们可以通过 EventType 的粘合剂将这两个组件声明性地绑定在一起，但是构建 LLM 代理的人员无需担心它将可以使用哪些工具或它将如何调用它们，而制作工具的团队可以向它提供其工具的访问权限，而无需学习 LLM 代理的代码库。此外，由于我们所做的只是向 LLM 提供有关服务的元数据，因此我们现在可以创建 EventType 来描述我们已经构建的现有服务，LLM 代理将能够 *无需代码更改* 成功地与这些系统进行交互。

这种通过使用元数据自动发现 LLM 代理的工具的概念，是我们正在努力构建的核心概念。在下一篇博文中，我们将讨论我们对此的愿景将如何发展。如果您有兴趣帮助我们在云中构建 LLM 代理的未来，请在 CNCF Slack 实例上给我们留言！