最近我收到一位才华横溢的学者发来的邮件，询问 Botpress 如何与大语言模型（LLM）集成。
他正在撰写一篇关于如何避免供应商锁定的论文，想知道我们是否使用了像 LangChain 或 Haystack 这样的框架。
我很高兴地告诉他，我们开发了自己的抽象层，使 Botpress 构建者能够与 LLM 进行接口对接。
鉴于大家对这个话题的广泛兴趣，我决定将这些信息公开。也许对其他开发者或我们平台的用户会有帮助。希望你们觉得这和我开发时一样有趣。
Botpress 与 LLM 对接的两种方式
Botpress 创建了自己的抽象层，主要有两种方式：
1. 集成
集成包含了具有特定输入和输出类型的动作概念。
我们在平台上提供了开源组件，因此社区可以创建自己的集成，这些集成可以是私有的，也可以公开使用。
因此，LLM 提供商——如 OpenAI、Anthropic、Groq 等——每家都有一个集成。这是我们用户与它们对接的一种方式。
2. LLM 集成接口
在集成的基础上，我们又增加了“接口”这一概念。
这些只是集成可以扩展的标准模式定义。我们为大语言模型（LLM）创建了一个标准模式。
只要某个集成遵循这个架构，它就被视为 LLM 提供方，因此可以在 Botpress 中直接使用。
以下是 Botpress 针对不同 LLM 提供商的部分集成示例：
我们还为 text2image、image2text、voice2text、text2voice 等提供了类似的接口。
模型配置
在 Botpress Studio 内部，我们有两个通用配置：“最佳模型”和“极速模型”。我们发现大多数任务通常适合这两种模式之一。
但除了单纯的模型选择外，我们还发现，不同的提供商在工具调用和消息格式上差异太大，无法轻松地切换模型并期望获得良好的性能。
Botpress 推理引擎
因此，我们开发了自己的推理引擎 LLMz，它可以兼容任何模型，几乎无需修改提示词。同时，它在工具调用和令牌成本、LLM 往返次数等方面通常表现更优。
该引擎在底层使用 typescript 类型定义工具，采用 markdown 作为消息和代码输出格式，并通过 LLM 原生执行沙箱进行推理。
LLMz 提供了许多优化和调试功能，适用于高级场景，例如：
- 输入令牌压缩
- 智能令牌截断
- 令牌优化的内存上下文管理
- 并行与复合工具调用
- 在一次 LLM 调用中混合多条消息和工具调用
- 完全类型安全的工具（输入与输出）
- 通过沙箱序列化实现长时间会话
- 工具模拟、包装与追踪
- 在轻量级 V8 隔离环境中完全隔离执行（可快速且低成本地并发运行数千次执行）
- 自动迭代与错误恢复
这些功能都是我们实际需求所必需的，但用常规工具调用方式很难甚至无法实现。
关于轻量级路由模型的思考
我们曾经考虑过开发一个轻量级路由模型，作为现有模型之上的一层，自动为每个任务选择合适的模型。
但我们最终没有这样做，原因有以下几点：
1. 可预测性
我们的大多数客户——可以理解——都希望获得可靠且可预测的结果。
因此，动态模型路由器的想法对于高阶智能体来说有点令人担忧。它会为 LLM 增加一层不可控性。
2. 速度
延迟对我们的应用场景非常重要。为了让路由器足够快速，模型必须非常小（可能也更简单），通常会比它所路由到的模型更基础——很可能是传统的分类器。
虽然这些模型在针对特定任务训练时表现尚可，但 a）它们的上下文长度太短，难以处理长提示词，b）它们无法很好地泛化到训练集之外的提示。
3. 模型优劣还是模型平等
虽然基准测试可能显示不同，但在实际应用中，我们很少看到有模型能超越 GPT-4o（目前为止）。
目前还不清楚 LLM 是否会在某些任务上持续优于其他任务，还是最终所有 LLM 都能在大多数任务上表现极佳。如果是后者，模型选择就没有太大意义了。
用反馈让 LLM 面向未来
几年后，LLM 会变成一种普通商品，模型选择将不再是问题。
基于这些原因，我们决定投入精力，提供一种为 LLM 提供示例的优质机制。
因此我们构建了一个反馈采集系统。它会为后续执行存储“学习内容”，并在提示时动态提供最相关的学习内容，从而确保结果长期可靠、持续优化。
随着各类 LLM 不断提升性能，我们已经准备好，也很期待为平台用户充分发挥它们的价值。
.webp)
