OpenGPTs - LangChain 博客

关键链接

大约两个多月前，在 OpenAI 开发者日之后，我们推出了 OpenGPTs：一种对开源 GPT 商店的尝试。它由早期版本的 LangGraph 提供支持 - LangChain 的一个扩展，旨在构建作为图的代理。当时，我们没有过多强调这个新软件包，因为我们尚未公开发布它，并且仍在研究界面。我们终于在两周前发布了 LangGraph，并在过去这个周末更新了 OpenGPTs 以完全使用 LangGraph（并添加了一些新功能）。我们认为现在是对 OpenGPTs 及其驱动力进行技术深入探讨的好时机。

在这篇博客中，我们将讨论

MessageGraph：OpenGPTs 运行在其上的一种特殊类型的图
认知架构：OpenGPTs 支持的 3 种不同类型的认知架构是什么，以及它们有何不同
持久性：持久性如何通过 LangGraph 检查点内置于 OpenGPTs 中。
配置：我们如何使用 LangChain 原语来配置所有这些不同的机器人。
新模型：我们支持哪些新模型
新工具：我们支持哪些新工具
astream_events：我们如何使用这种新方法来流式传输令牌和中间步骤

如果您更喜欢 YouTube 视频，我们也制作了一个视频演示！

MessageGraph

OpenGPTs 在 MessageGraph 上运行，这是一种我们在 LangGraph 中引入的特殊类型的图。此图的特殊之处在于，每个节点都接收消息列表，并返回要附加到消息列表的消息。我们认为这种“消息传递”很有趣，原因有以下几点：

它与新的“聊天完成”模型的 I/O 密切相关，这些模型接收消息列表并返回消息
消息传递是分布式系统中常用的通信方法
它使正在完成的工作的可视化更容易，因为每个工作单元现在都是一种通用类型
它与 OpenAI 引入的 Assistants API 密切相关（消息附加到线程的地方）
从概念上讲，它似乎可以扩展到多代理系统（其中每个代理只是将消息附加到消息列表）

通过使用 MessageGraph，我们对我们创建的代理的输入和输出做出假设，但值得注意的是，我们没有对这些代理的认知架构做出任何假设。正如我们在下面看到的，这可以支持各种各样的认知架构。

认知架构

作为 OpenGPTs 此更新的一部分，我们添加了三种不同的认知架构，让用户在创建机器人时进行选择。

助手：这些助手可以配备任意数量的工具，并使用 LLM 来决定何时使用它们
RAG：这些配备了单个检索器，并且它们始终使用它。
聊天机器人：这些机器人只是通过自定义系统消息进行参数化。

助手

助手可以配备任意数量的工具，并使用 LLM 来决定何时使用它们。这使得它们成为最灵活的选择，但它们在模型较少的情况下也能很好地工作，并且可靠性可能较低。

创建助手时，您需要指定一些内容。

首先，您选择要使用的语言模型。只有少数语言模型可以可靠地使用：GPT-3.5、GPT-4、Claude 和 Gemini。

其次，您选择要使用的工具。这些可以是预定义的工具，也可以是从上传的文件构建的检索器。您可以选择任意数量的工具。

认知架构可以被认为是一个循环。首先，调用 LLM 以确定要采取哪些（如果有）操作。如果它决定采取操作，则执行这些操作并循环返回。如果没有决定采取操作，则 LLM 的响应是最终响应，并且它完成循环。

这可能是一个非常强大且灵活的架构。这可能最接近我们人类的运作方式。但是，这些也可能不是很可靠，并且通常只能与性能更高的模型一起工作（即使这样，它们也可能搞砸）。因此，我们引入了一些更简单的架构。

RAG

GPT 商店的一大用例是上传文件并让机器人了解这些文件。使架构更侧重于该用例意味着什么？

我们添加了一个 RAG 机器人 - 一个以检索为中心的 GPT，具有直接的架构。首先，检索一组文档。然后，将这些文档传递到系统消息中，以便单独调用语言模型，以便它可以响应。

与助手相比，它结构更化（但功能较弱）。它始终查找内容 - 如果您知道自己想要查找内容，这很好，但如果用户只是想进行正常的对话，则可能会浪费资源。同样重要的是，这只查找一次内容 - 因此，如果找不到正确的结果，则会产生不良结果（与助手相比，助手可能会决定再次查找内容）。

尽管这是一个更简单的架构，但它在几个方面都很好。首先，因为它更简单，所以它可以与各种各样的模型（包括许多开源模型）很好地配合使用。其次，如果您有一个用例，您不需要助手的灵活性（例如，您知道用户每次都会查找信息），那么它可以更专注。第三，与下面的最终架构相比，它可以使用外部知识。

聊天机器人

最终的架构非常简单 - 只是调用语言模型，通过系统消息进行参数化。这允许 GPT 扮演不同的角色和人物。这显然远不如助手或 RAG 机器人（它们可以访问外部数据/计算资源）强大 - 但它仍然很有价值！许多流行的 GPT 最终只是系统消息，而 CharacterAI 即使在很大程度上也只是系统消息，但仍然非常成功。

持久性

OpenGPTs 从一开始的一个要求就是持久性，特别是聊天消息的持久性。我们没有为此构建定制的解决方案，而是决定将此功能作为 LangGraph 的一部分添加。具体来说，在创建图时，您可以传递 CheckPoint 对象。然后，此检查点对象将在调用每个节点后保存图的当前状态。

对于 OpenGPTs，我们创建了一个 RedisCheckPointer，它将结果保存到 Redis。目前，此持久性仅用于显示过去对话的消息，但我们将在不久的将来以更高级的方式使用此持久性🙂

配置

OpenGPTs 的另一个要求是配置。我们需要用户能够选择 LLM、系统消息、工具等。我们还需要保存该配置，以便他们将来可以再次使用该聊天机器人。

LangChain 的一个未被充分强调的功能是能够将某些字段标记为可配置。您可以对链的任何字段执行此操作，然后在运行时传入配置选项。

这使我们能够以模块化和一致的方式轻松实现可配置性。首先，我们将不同的字段标记为可配置，然后为了支持不同的架构，我们甚至为整个链提供了可配置的替代方案。然后，当用户创建 GPT 时，我们将保存配置。最后，当与该 GPT 聊天时，我们将使用保存的配置调用链。

查看 OpenGPT 源代码，了解如何执行此操作的一些高级示例，但请记住，所有 LangChain 对象都可以做到这一点！

新模型

我们希望在此次更新中引入一些新模型。首先，我们集成了 Google 的 Gemini 模型。该模型性能良好，并支持函数调用，因此我们将其添加为助手的选项。

我们努力尝试使开源模型足够可靠，可以用作助手，但失败了。即使使用 Mixtral，它仍然有点不可靠。我们非常欢迎社区协助使其可靠地工作！

在无法使其用于助手架构的情况下，我们添加了 Mixtral（通过 Fireworks）作为聊天机器人和 RAG 机器人的选项。它在这些更简单的架构中运行良好！

我们还更新了 OpenAI 代理以使用工具调用而不是函数调用。

新工具

我们还引入了一个新工具 - Robocorp 的 Action Server。Robocorp 的 action server 是一种轻松定义和运行任意 Python 函数作为工具的方法。因此，即使这是一个单一的工具，也可以使用它来定义许多不同的工具！

请关注本周晚些时候对此的更深入探讨

`astream_events`

值得指出的是，我们正在使用我们新的 astream_events 方法来轻松地流式传输所有事件（新令牌，以及函数调用和函数结果），并将它们呈现给用户。我们对这个流进行了一些过滤，以获得相关的消息或消息块，然后在 UI 中很好地呈现它们。如果您不熟悉 astream_events，那么绝对值得在此处查看更多详细信息。