文章目录
- 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(日)