最近，我收到一位才华横溢的学者的电子邮件，询问Botpress 如何与LLMs 接口。
他正在撰写一篇关于避免供应商锁定的论文，并想知道我们是否可能使用 LangChain 或 Haystack 这样的框架。
我非常高兴地与他分享，我们创建了自己的抽象，使Botpress 构建者能够与LLMs 接口。
鉴于人们对这一主题的广泛兴趣，我想公开这一信息。它可能对其他开发人员或我们平台的用户有用。我希望您能像我一样发现它的有趣之处。
Botpress 接口的两种方式LLMs
Botpress 创建了自己的抽象概念，其工作方式有两种：
1.整合
集成具有行动的概念，这些行动有特定的输入和输出类型。
我们在平台上提供开源组件，因此社区可以创建他们自己的集成，这些集成既可以是私有的，也可以供公众使用。
因此，LLM 供应商 -OpenAI 、Anthropic、Groq 等。- 每个供应商都有一个集成。这也是我们的用户可以与它们对接的一种方式。
2.LLM 集成接口
在集成概念的基础上，我们增加了 "接口"。
这些只是标准模式定义，集成可以对其进行扩展。我们为LLMs 创建了一个标准模式。
只要集成扩展了该模式，该集成就会被视为LLM 提供商。因此，它在Botpress 中开箱即用。
以下是Botpress 与不同LLM 提供商集成的一些示例：
我们也有类似的界面，如 text2image、image2text、voice2text、text2voice 等。
型号配置
在Botpress Studio 中，我们有两种通用配置："最佳模式 "和 "快速模式"。我们发现，一般来说，大多数任务都能轻松适应这两种模式中的一种。
但是，除了单纯的模型选择之外，我们还发现不同的供应商在工具调用和信息格式方面存在很大差异，因此无法轻松地将一个模型换成另一个模型，并期望获得良好的性能。
Botpress 推论引擎
正因为如此，我们创建了自己的推理引擎，名为 LLMz，它可以与任何模型配合使用，无需（或只需极少）更改提示。它提供了更好的工具调用，在令牌成本和LLM 往返次数方面通常也有更好的表现。
该引擎在幕后使用 typescript 类型进行工具定义，使用 markdown 作为信息和代码输出格式，并使用LLM 作为推理的原生执行沙箱。
LLMz 提供了许多高级用例所需的优化和调试功能，例如
- 输入令牌压缩
- 智能令牌截断
- 令牌优化的内存到上下文
- 并行和复合工具调用
- 在一次LLM 调用中混合多个信息 + 工具调用
- 完全类型安全工具（输入和输出）
- 通过沙盒序列化实现长期会话
- 工具模拟、包装和跟踪
- 轻量级 V8 隔离程序中的全面执行隔离（可快速、低成本地运行数千个并发执行程序）
- 自动迭代和错误恢复
所有这些都是我们的用例所必需的。但是，使用普通工具调用这些功能要么是不可能的，要么是非常困难的。
反对轻量级路由器型号的理由
长期以来，我们一直在考虑建立一个轻量级的路由器模型，它可以安装在现有模型之上，并根据手头的任务自动选择合适的模型。
但出于多种原因，我们决定不这样做：
1.可预测性
我们的大多数客户都希望获得可靠和可预测的结果，这是可以理解的。
因此，动态模型路由器的想法对于高级代理来说有点可怕。它给LLMs 带来了另一层不可预测性。
2.速度
对于我们的用例来说，延迟非常重要。为了使路由器快速运行，模型必须比它将路由到的模型--可能是传统分类器--非常小（也可以说非常笨）。
虽然它们在特定任务中的表现一般都还不错，但 a) 它们的上下文尺寸较短，这对于长提示来说是个问题；b) 它们无法泛化到训练之外的其他提示。
3.模式至上还是模式平等
虽然基准测试的结果可能与此相反，但在实际使用中，我们很少看到机型的性能超过GPT-4o（到目前为止）。
目前还不清楚，随着时间的推移，LLMs 在任务 X 上的表现是否真的会优于任务 Y，或者是否所有的LLMs 最终都会在大多数事情上表现出色。如果是后者，就不值得费力挑选模型了。
利用反馈意见使LLMs 面向未来
LLMs 几年后，它将成为一种商品，型号选择将不再重要。
出于这些原因，我们决定投入精力，提供一个良好的机制，为LLMs 提供范例。
因此，我们建立了一个获取反馈的系统。它存储 "学习成果"，供未来执行时使用。它还能及时动态地为未来的执行提供最相关的学习成果，以确保随着时间的推移不断取得可靠的改进。
随着LLMs 的性能越来越高，我们已经做好准备，并很高兴为我们平台的用户充分利用它们。
.svg)
