文章目录
- MessageGraph 消息图
- 认知架构
- Assistants
- RAG
- ChatBot
- 持久化
- 配置
- 新模型
- 新工具
- `astream_events`
- 总结
关键链接：
- OpenGPT GitHub 存储库
- YouTube 上的 OpenGPT 演练
- LangGraph：Python、JS
两个多月前，在 OpenAI 开发日之后，我们推出了 OpenGPT：类似于开源 GPT 商店。
它由LangGraph的早期版本提供支持，LangGraph 是 LangChain 的扩展，旨在将代理构建为图表。
当时，我们并没有过多强调这个新软件包，因为我们还没有公开发布它并且仍在研究界面。
两周前，我们终于开始启动 LangGraph，并在上周末更新了 OpenGPT 以充分使用 LangGraph（并添加了一些新功能）。
我们认为现在是对 OpenGPT 及其驱动因素进行技术深入研究的最佳时机。
在这篇博客中，我们将讨论：
- MessageGraph：OpenGPT 运行的一种特定类型的图
- 认知架构：OpenGPT 支持的 3 种不同类型的认知架构是什么，以及它们有何不同
- 持久性：如何通过 LangGraph 检查点在 OpenGPT 中实现持久性。
- 配置：我们如何使用 LangChain 原语来配置所有这些不同的机器人。
- 新模型：我们支持哪些新模型
- 新工具：我们支持哪些新工具
astream_events：我们如何使用这种新方法来流式传输令牌和中间步骤
如果 YouTube 视频更符合您的风格，我们还制作了视频演练！
MessageGraph 消息图
OpenGPT 运行在 上MessageGraph，这是我们在 LangGraph 中引入的一种特殊类型的图。
该图的特殊之处在于 每个节点接收消息列表 并返回消息 以附加到消息列表。
我们认为这种“消息传递”很有趣，原因如下：
- 它与新的“聊天完成”模型的 I/O 密切相关，该模型接收消息列表并返回消息
- 消息传递是分布式系统中常用的通信方法
- 它使正在完成的工作的可视化变得更容易，因为每个工作单元现在都是通用类型
- 它与 OpenAI 引入的 Assistants API 密切相关（其中消息附加到线程）
- 从概念上讲，它似乎可以扩展到多代理系统（其中每个代理只是将消息附加到消息列表中）
通过使用，MessageGraph我们对我们创建的代理的输入和输出做出假设，但值得注意的是，我们没有对这些代理的认知架构做出任何假设。
如下所示，这可以支持多种认知架构。
认知架构
作为 OpenGPT 更新的一部分，我们添加了三种不同的认知架构，以便用户在创建机器人时进行选择。
- Assistants：可以配备任意数量的工具，并使用LLM 来决定何时使用它们
- RAG：它们配备了一个猎犬，并且他们总是使用它。
- ChatBot：这些只是通过自定义系统消息进行参数化。
Assistants
助理可以配备任意数量的工具，并使用LLM 来决定何时使用它们。
这使它们成为最灵活的选择，但它们适用于较少的模型，并且可靠性较差。
创建助手时，您需要指定一些内容。
首先，您选择要使用的语言模型。
只有少数语言模型可以可靠地使用：GPT-3.5、GPT-4、Claude 和 Gemini。
其次，您选择要使用的工具。
这些可以是预定义的工具或从上传的文件构建的检索器。您可以选择任意数量。
认知架构可以被认为是一个循环。
首先，LLM 被要求确定要采取什么（如果有）行动。如果它决定采取行动，那么这些行动就会被执行并循环回来。
如果决定不采取任何行动，则 LLM 的响应是最终响应，并且结束循环。
这可能是一个非常强大且灵活的架构。这可能最接近我们人类的运作方式。
然而，这些也可能不是超级可靠，并且通常只适用于性能更高的模型（即使如此，它们也可能会搞砸）。
因此，我们引入了一些更简单的架构。
RAG
GPT 存储的主要用例之一是 上传文件 并向机器人提供这些文件的知识。
让架构更加关注该用例意味着什么？
我们添加了一个 RAG 机器人 - 一个以检索为中心的 GPT，具有简单的架构。
首先，检索一组文档。
然后，这些文档在系统消息中传递给对语言模型的单独调用，以便它可以做出响应。
与助手相比，它更加结构化（但功能较弱）。
它总是会查找一些东西——如果你知道你想查找东西，这很好，但如果用户只是想进行正常的对话，这可能会造成浪费。
同样重要的是，这只会查找一次 - 因此，如果它找不到正确的结果，那么它将产生一个糟糕的结果（与助手相比，助手可能会决定再次查找内容）。
尽管这是一个更简单的架构，但它的优点有几个。
首先，因为它更简单，所以它可以很好地与更广泛的模型（包括许多开源模型）一起工作。
其次，如果您有一个不需要助手灵活性的用例（例如您知道用户每次都会查找信息），那么它可以更加集中。
第三，与下面的最终架构相比，它可以使用外部知识。
ChatBot
最终的架构非常简单——只需调用由系统消息参数化的语言模型。
这使得 GPT 能够呈现出不同的角色和性格。
这显然远不如助手或 RAGBot（可以访问外部数据/计算源）强大 - 但它仍然很有价值！
许多流行的 GPT 归根结底只是系统消息，而 CharacterAI 正在粉碎它，尽管很大程度上也只是系统消息。
持久化
从一开始，OpenGPT 的一个要求就是持久性，特别是聊天消息的持久性。
我们没有为此构建定制解决方案，而是决定为此添加功能作为 LangGraph 的一部分。
具体来说，在创建图形时，您可以传递 CheckPoint 对象。
该检查点对象将在调用每个节点后保存图的当前状态。
对于 OpenGPT，我们创建了一个 RedisCheckPointer，它将结果保存到 Redis。
目前，这种持久性仅用于显示过去对话的消息，但我们很快就会以更高级的方式使用这种持久性 🙂
配置
OpenGPT 的另一个要求是配置。
我们需要用户能够选择什么 LLM、什么系统消息、什么工具等。
我们还需要保存该配置，以便他们将来可以再次使用该聊天机器人。
LangChain 的一项不太突出的功能是 能够将某些字段 标记为可配置。
您可以对链的任何字段执行此操作，然后在运行时传入配置选项。
这使我们能够以模块化和一致的方式轻松实现可配置性。
首先，我们将不同的字段标记为可配置，然后为了支持不同的架构，我们甚至提供了整个链的可配置替代方案。
然后，当用户创建 GPT 时，我们将保存配置。
最后，当与该 GPT 聊天时，我们将使用保存的配置调用链。
查看 OpenGPT 源代码，了解如何执行此操作的一些高级示例，但请记住，它适用于所有 LangChain 对象！
新模型
作为本次更新的一部分，我们希望引入一些新模型。
首先，我们集成了Google的Gemini模型。该模型性能非常好并且支持函数调用，因此我们将其添加为助手的选项。
我们努力尝试获得一个足够可靠的开源模型来用作助手，但失败了。
即使有了 Mixtral，它仍然有点不可靠。
我们希望得到社区的帮助，让其可靠地工作！
由于无法使其适用于 Assistant 架构，我们添加了 Mixtral（通过Fireworks）作为 ChatBot 和 RAGBot 的选项。它与这些更简单的架构配合得很好！
我们还更新了 OpenAI 代理以使用工具调用而不是函数调用。
新工具
我们还推出了一个新工具 - Robocorp 的 Action Server。
Robocorp 的操作服务器是一种 将任意 Python 函数定义和运行作为工具的简单方法。
因此，即使这是一个单一的工具，也可以使用它来定义许多不同的工具！
请留意本周晚些时候对此进行更深入的探讨
astream_events
值得指出的是，我们正在使用新astream_events方法轻松流回所有事件（新令牌以及函数调用和函数结果）并将其呈现给用户。
我们对此流进行一些过滤以获取相关消息或消息块，然后在 UI 中很好地呈现它们。
如果您不熟悉astream_events，绝对值得在这里更详细地查看它。
总结
我们希望这能为 OpenGPT 提供更合适的技术深入探讨。
有几个领域可以从社区援助中受益：
- 促使助理架构与开源模型可靠工作的策略
- 支持其他工具（包括任意 OpenAPI 规范）
OpenGPT 背后的所有内容也通过 API 端点公开，因此请随意分叉并仅使用后端。
如果您是一家希望在内部部署 OpenGPT 的企业，请联系 gtm@langchain.dev。
伊织 2024-04-07（日）
白话之个人理解（学习记录）)
