OpenAI's Bet on a Cognitive Architecture

OpenAI 对认知架构的押注

阅读时长 10 分钟

三周前，OpenAI 举办了一场备受期待的开发者日活动。他们发布了大量新功能。对我而言，最有趣的两个是 Assistants API 和 GPTs。在我看来，这些功能代表着同一个赌注——押注于一种特定的、类似代理的、封闭的“认知架构”。它们吸引着不同的最终用户，但都体现了 OpenAI 将应用程序朝着这种特定认知架构方向发展的雄心壮志。在 LangChain，我们相信一个由大型语言模型 (LLM) 驱动类似代理的系统能够带来真正变革的世界。但是，我们认为实现这一目标的途径是让公司能够控制自己的认知架构。您现在就可以使用像 OpenGPTs 这样的项目来做到这一点——OpenGPTs 是 Assistants API（和 GPTs）的开放、可编辑和可配置版本。

GPTs 和 Assistants API

在这两者中，GPTs 可能是互联网上讨论得更多的一个。它们提供了一种（很大程度上）无需代码的方式来创建您自己的“GPT”。这些 GPT 可以使用自定义指令、自定义知识和自定义函数进行定制。这些 GPT 似乎是在应用程序商店方面进行的第二次尝试，继插件（用 Sam Altman 本人的话说，插件并未找到产品市场契合点）之后。

Assistants API 是这个想法更侧重于开发者的版本。Assistants API 是一个有状态的 API，允许存储之前的消息、上传文件、访问内置工具（代码解释器），并且可以用于控制其他工具（通过函数调用，开发人员指定要调用的函数，然后可以在客户端执行该函数）。

认知架构

在底层，这两者都代表着类似类型的“认知架构”。在这里，我使用认知架构来描述 LLM 应用程序的编排。我第一次听到 Flo Crivello（Lindy 的创建者，Lindy 是一家自主代理初创公司）使用这个术语，我认为这是一个非常棒的术语。

💡
大多数有趣的 LLM 应用程序都可以描述为上下文感知推理应用程序。这里有两个主要组成部分：（1）如何向应用程序提供上下文，（2）应用程序如何“推理”。这两个组件共同构成了应用程序的认知架构。

在 LangChain，我们已经思考认知架构有一段时间了。在最近的一次 TedAI 演讲中（视频尚未发布），我谈到了我们看到开发人员构建的不同级别的认知架构。其中包括

  1. 单个 LLM 调用，仅确定应用程序的输出
  2. 一系列 LLM 调用，仍然仅确定应用程序的输出
  3. 使用 LLM 作为路由器，选择要使用的哪个操作（工具、检索器、提示）
  4. 状态机——使用 LLM 在步骤之间进行路由，以某种循环方式，但允许的转换选项仍在代码中枚举
  5. 代理——移除很多脚手架，以便转换选项完全由 LLM 确定
一个展示我们当前认知架构思维模型的表格。

代理

Assistants API 和 GPTs 都是上述“代理”认知架构的例子。Sam Altman 在宣布这些功能时甚至使用了这个确切的术语（“代理”）。虽然代理可能是一个含义丰富的术语，用于描述各种不同的应用程序，但 OpenAI 对该术语的使用与我们的理解基本一致：仅使用 LLM 来定义转换选项。

在实践中，此类应用程序是什么样子的？这最好理解为一个循环。给定用户输入，将进入此循环。然后调用 LLM，从而导致对用户的响应或要采取的操作。如果确定需要响应，则将其传递给用户，并且该循环结束。如果确定需要采取操作，则采取该操作，并进行观察（操作结果）。该操作和相应的观察结果将被添加回提示中（我们称之为“代理便笺”），然后循环重置，即再次调用 LLM（使用更新后的代理便笺）。

“代理”架构概述

从高层次来看，这就是 GPTs 的工作原理。当它们调用您提供的工具（或像检索或代码解释器这样的内置工具）时，您可以在屏幕上看到一个旋转的小部件。这表示正在执行操作，并且 GPT 正在等待观察结果。在某个时刻，它只是用文本进行响应——无需采取任何操作——循环结束。

Assistants API 也是一样的。唯一的区别在于，API 不会为您调用工具——除非是像检索或代码解释器这样的内置工具。相反，它会响应特定类型的消息，告诉您应该调用哪些工具（以及这些工具的输入是什么），然后等待您在客户端调用工具并将结果传回。

这种“代理”认知架构在过去一年半的时间里一直在发展。AI21 Labs 在一年半前发布了他们的 MRKL 论文。 ReAct 提示策略（一年多前发布）是一种特定类型的提示策略，能够实现这种架构。我们在近一年前将 ReAct 集成到 LangChain 中，并迅速扩展到更通用的零样本提示策略。 AutoGPT 大约九个月前横空出世，使用了相同的认知架构，但赋予了它更多工具、更持久的内存以及通常要完成的任务更大。

OpenAI 正在进行的押注

我非常感兴趣地看到 OpenAI 在代理方面投入了多少精力，因为从各方面来看，这种认知架构对于严肃的应用程序来说还不可靠。他们拥有最好的条件来让它发挥作用——毕竟他们控制着底层模型。但这仍然是一个**赌注**。他们押注的是，随着时间的推移，困扰代理的问题将会消失。

我们看到的几乎所有真正有用的“自主代理”在两个关键方面都存在差异。

首先，许多实际上并不是这种“代理”认知架构，而是更复杂的链或更类似于“状态机”。GPT-Researcher 和 Sweep.dev 是这两个很好的公开例子。

我们曾多次 撰写 关于 GPT-Researcher 的文章，并在上周与他们合作发布了 LangChain 模板。它们是为数不多的能够产生有价值结果的复杂 LLM 驱动的应用程序之一，但它们的认知架构更像是一个复杂的链。如果我们查看下面的图表，我们可以看到它沿一个方向流动。它执行了许多复杂步骤，但以一种定义明确的方式：它首先生成子问题，然后获取每个问题的链接，然后总结每个链接，然后将摘要组合成一份研究报告。

GPT-Researcher 的认知架构，取自其 GitHub 代码库。

Sweep.dev 是另一个很好的例子。他们在夏季撰写了一篇 博文 描述了他们的认知架构，其中包含一个很棒的图表。

Sweep.dev 的认知架构，取自其博文。

存在明确定义的转换和步骤。首先进行搜索。然后生成计划。然后对计划执行操作。然后进行验证步骤：如果通过，则创建 PR 并完成 Sweep。如果失败，则制定新计划。这是一个非常清晰的状态机，其中不同状态之间存在明确定义的转换。

我们合作的许多其他构建者和团队都使用复杂的链/状态机为其应用程序提供支持。

💡
这些认知架构的好处很简单：更多控制权。没有两个问题是一样的，选择适合问题空间的适当认知架构对于提供良好的体验至关重要。

对于确实使用更类似于这种代理架构的应用程序，它们在另一个方面与 GPTs 不同：如何向代理提供上下文。

我正在与 Flo Crivello 讨论认知架构，他提出了代理架构的一个区别在于如何向代理提供上下文。请记住，我们描述大多数有趣 LLM 应用程序的方式是“上下文感知推理应用程序”。

💡
上下文可以通过拉取或推送来提供。在大多数性能良好且可靠的代理中，我们看到大量上下文通过推送提供。

代理**拉取**上下文的含义是什么？这意味着代理决定它需要什么上下文，然后请求它。这通常通过工具来实现。例如，一个创建用于与 SQL 数据库交互的代理可能需要知道 SQL 数据库中存在哪些表。因此，我们可以为它提供一个返回数据库中表列表的工具，它可以在一开始调用该工具。

相反，当上下文**推送**到语言模型时，它被编码到应用程序的逻辑中，即应该获取特定上下文并将其插入到提示中。在上面的 SQL 代理示例中，这对应于提前自动获取 SQL 表并将它们插入到提示中。

大多数确实使用代理架构的应用程序都包含大量的推送上下文。例如，LangChain 中的 SQL 和 Pandas 代理将表架构作为系统消息的一部分。再举一个例子，Rubrics 团队为 Cal.com 构建的代理 在 提示中推送了大量用户信息。

这种上下文的**推送与拉取**再次为开发人员提供了更多控制权。它使我们能够在决定要做什么时强制执行与 LLM 相关的上下文。具体来说，了解哪些上下文最相关、如何获取这些上下文以及如何提供这些上下文是一些看似微小的决策，但可以对质量和性能产生重大影响。

GPT 和某种程度上 Assistant API 大多赋予应用程序一种不受约束的代理架构，这种架构更依赖于根据需要提取上下文。这对于快速入门或执行简单任务非常有用，但对于更复杂的用例，没有什么能替代控制适合当前问题的认知架构。

开放与封闭

除了认知架构的选择之外，Assistant API 和 GPT 的另一个显著特征是认知架构本身是**封闭的**。我们不知道幕后发生了什么。我们不知道确切的算法。我们不知道如何管理聊天历史的上下文。我们不知道检索是如何进行的。

现在我们可以对这两者进行猜测。但是，随着它们添加越来越多的功能，并且变得越来越复杂，它将变得越来越像一个黑盒。

💡
许多关于开源与闭源的讨论都围绕着模型本身展开。但还有另一个因素需要考虑：开源认知架构与闭源认知架构。

随着时间的推移，我敢打赌，这将成为比模型本身更大的讨论话题。一年前，大多数新功能（我敢打赌，内部的大部分重点）都集中在改进模型上。现在，核心模型改进与如何以代理方式连接它们似乎各占 50%。作为这一重要性的更多证据，Karpathy 的 Twitter 帖子（所有 AGI 相关内容的权威阅读清单）越来越倾向于将 LLM 视为操作系统的想法。上周末，他发布了一个关于此主题的精彩视频。

我完全预计这种趋势将持续下去，OpenAI（以及其他一些实验室）将更多地投资于模型相关的平台和工具，而不是仅仅投资模型本身。通往 AGI 的道路并非（仅仅）在于更好的模型——还在于将其与周围环境连接起来。随着这些实验室的重点转移，我预计——也希望——关于开放与封闭的讨论不仅会发生在模型上，还会发生在认知架构上。

认知架构能让你的啤酒更好喝吗？

杰夫·贝索斯有一句名言，他说要只做那些能让你的啤酒更好喝的事情。这指的是早期的工业革命时期，当时啤酒厂也自己发电。啤酒厂酿造好啤酒的能力实际上并不取决于其电力有多么与众不同——因此，那些将电力生产外包并更多地专注于酿造的啤酒厂获得了优势。

认知架构也是如此吗？控制自己的认知架构真的能让你的啤酒更好喝吗？目前，我认为答案是肯定的，原因有两个。首先：让复杂的代理真正发挥作用非常困难。如果你的应用程序依赖于代理的工作，并且让代理工作具有挑战性，那么几乎可以肯定的是，如果你能很好地做到这一点，你将比竞争对手更有优势。第二个原因是，我们经常看到 GenAI 应用程序的价值与认知架构的性能密切相关。许多现在的公司都在销售用于编码的代理、用于客户支持的代理。在这些情况下，认知架构就是产品本身。

最后一个原因也是我难以相信公司愿意锁定到由单一公司控制的认知架构的原因。我认为这与云或甚至 LLM 不同形式的锁定。在这些情况下，你正在使用云资源和 LLM 来构建或为特定应用程序提供动力。但是，如果认知架构越来越接近成为一个完整的应用程序——你不太可能希望将其锁定。

LangChain 如何融入其中

在 LangChain，我们相信一个 LLM 为真正具有变革性的代理式系统提供动力的世界。但是，我们认为实现这一目标的途径是让公司能够控制自己的认知架构。

💡
根据我们与交付 LLM 驱动的应用程序的团队合作的所有经验，让代理式系统可靠地工作真的非常困难。你可以使用通用代理架构制作演示，也许还可以制作简单的玩具应用程序。但是，当需要提高性能和规模化运行时，你需要根据你的应用程序和用例对其进行定制。

这需要大量的工程工作。我们正在构建工具来帮助解决这个问题。使用LCEL，我们有一种灵活的方法来组合链。使用 LangChain，我们拥有超过 600 个集成，从而能够在使用的模型/向量存储/数据库方面拥有完全的灵活性。使用LangSmith，我们明确地专注于提供尽可能好的调试体验（因为大多数团队都处于这个阶段），但我们也添加了管理工具（回归测试、监控、数据标注、提示中心）来帮助你在系统进入生产环境后对其进行管理。

我们最近还发布了OpenGPTs。这是尝试重现与 Assistant API 和 GPT 相同的体验（我们对 GPT 的实现只是一个简单的 Assistant API UI）。这是开源的，目前可以使用四种不同的模型提供程序进行配置，并且使用的确切检索方法可以轻松修改。

这仅仅是一个开始。