📢 转载信息
原文链接：https://machinelearningmastery.com/everything-you-need-to-know-about-recursive-language-models/
原文作者：Bala Priya C
在本文中，您将了解递归语言模型是什么，它们对于长输入推理为何重要，以及它们与标准的长上下文提示、检索和代理系统有何不同。
我们将涵盖的主题包括：
- 为什么长上下文本身并不能解决对非常大的输入进行推理的问题
- 递归语言模型如何使用外部运行时和递归子调用来处理信息
- 这种方法的主要权衡、局限性和实际用例
让我们直接开始。
递归语言模型：您需要了解的一切
图片来源：Editor
引言
如果您在这里，您可能已经听说过关于递归语言模型的最新研究。这个想法在 LinkedIn 和 X 上非常流行，促使我更深入地研究了这个主题并与您分享我的学习心得。我想我们都同意，在过去的几年里，大型语言模型（LLMs）取得了飞速的进步，尤其是在处理大型输入的能力方面。这种进步让许多人认为长上下文在很大程度上已经是一个已解决的问题，但事实并非如此。如果您尝试向模型输入接近或等于其上下文窗口的非常长的输入，您可能会注意到它们的可靠性下降。它们经常会忽略提供的信息中的细节，与早期陈述相矛盾，或者产生肤浅的答案，而不是进行仔细的推理。这个问题通常被称为“上下文腐烂”，这是一个非常有趣的名字。
递归语言模型（RLMs）是对这个问题的回应。RLMs 没有将越来越多的文本推入语言模型的单次前向传递中，而是改变了模型与长输入交互的方式。在本文中，我们将探讨它们是什么，它们如何工作，以及它们旨在解决的问题类型。
为什么长上下文还不够
如果您已经理解了引言中的动机，可以跳过本节。但如果您感到好奇，或者第一次没有完全理解这个想法，让我进一步分解。
这些 LLMs 的工作方式相当简单。我们希望模型考虑的所有内容都作为单个提示提供给它，并基于该信息，模型会逐个 token 生成输出。当提示很短时，这效果很好。然而，当提示变得非常长时，性能就会开始下降。这不一定是因为内存限制。即使模型可以看到完整的提示，它也常常无法有效地使用它。以下是一些可能导致这种行为的原因：
- 这些 LLMs 主要基于 transformer 模型，并带有注意力机制。随着提示的增长，注意力会变得更加分散。当模型需要关注数万甚至数十万个 token 时，它难以清晰地聚焦于重要的内容。
- 另一个原因是混合了异构信息，例如日志、文档、代码、聊天历史和中间输出。
- 最后，许多任务不仅仅是检索或在大量内容中查找相关片段。它们通常涉及跨整个输入的聚合信息。
由于上述问题，人们提出了诸如摘要和检索等想法。这些方法在某些情况下确实有帮助，但它们并非普遍的解决方案。摘要在设计上是会丢失信息的，而检索假设在推理开始之前就可以可靠地识别出相关性。许多现实世界的任务都违反了这些假设。这就是为什么 RLM 提出了不同的方法。它们不是强迫模型一次性吸收整个提示，而是让模型主动探索和处理提示。现在我们有了基本背景，让我们更仔细地看看它是如何工作的。
递归语言模型实际如何工作
在 RLM 设置中，提示被视为外部环境的一部分。这意味着模型不会直接读取整个输入。相反，输入位于模型外部，通常作为一个变量，模型只接收关于提示的元数据以及如何访问它的指令。当模型需要信息时，它会发出命令来检查提示的特定部分。这种简单的设计即使在底层输入非常大的情况下，也能保持模型的内部上下文小而集中。为了更具体地理解 RLM，让我们一步一步地 percorrer 一个典型的执行过程。
步骤 1：初始化持久性 REPL 环境
在 RLM 运行开始时，系统会初始化一个运行时环境，通常是一个 Python REPL。该环境包含：
- 一个持有完整用户提示的变量，该提示可能任意大
- 一个允许系统在选定的文本片段上调用其他语言模型调用的函数（例如，
llm_query(...)或sub_RLM(...)）
从用户的角度来看，界面保持简单，只有文本输入和输出，但在内部，REPL 作为支持可扩展推理的脚手架。
步骤 2：仅使用提示元数据调用根模型
然后调用根语言模型，但它不接收完整的提示。相反，它接收：
- 关于提示的恒定大小的元数据，例如其长度或简短的前缀
- 描述任务的指令
- 通过 REPL 环境与提示交互的访问说明
通过隐藏完整的提示，系统迫使模型有意地与输入交互，而不是被动地将其吸收到上下文窗口中。从这一点开始，模型将间接与提示交互。
步骤 3：通过代码执行检查和分解提示
模型可能首先检查输入的结构。例如，它可以打印前几行，搜索标题，或根据分隔符将文本分成块。这些操作通过生成代码来执行，然后将在环境中执行。这些操作的输出会在显示给模型之前被截断，以确保上下文窗口不会过载。
步骤 4：在选定的片段上发出递归子调用
一旦模型理解了提示的结构，它就可以决定如何进行。如果任务需要对某些部分进行语义理解，模型可以发出子查询。每个子查询都是一个独立的语言模型调用，作用于提示的一个较小片段。这正是“递归”部分实际发挥作用的地方。模型反复分解问题，处理输入的部分，并存储中间结果。这些结果存在于环境中，而不是模型本身。的上下文中。
步骤 5：组装并返回最终答案
最后，在收集和处理了足够的信息后，模型会构建最终答案。如果输出很长：
- 模型在 REPL 变量（如
Final）中逐步构建它 - 一旦设置了
Final，RLM 循环就会终止 Final的值作为响应返回
这种机制允许 RLM 生成超出单个语言模型调用令牌限制的输出。在整个过程中，没有任何一个语言模型调用需要看到完整的提示。
RLMs 与代理和检索系统的区别
如果您在 LLM 领域花费时间，您可能会将这种方法与代理框架或检索增强生成（RAG）混淆。然而，这些是不同的概念，即使区别可能感觉微妙。
在许多代理系统中，完整的对话历史或工作内存会被反复注入到模型的上下文中。当上下文变得过大时，旧信息会被摘要或丢弃。RLMs 从一开始就将提示保持在外部，完全避免了这种模式。相比之下，检索系统依赖于在推理开始之前识别一小组相关块。当相关性稀疏时，这效果很好。RLMs 专为相关性密集且分散，并且需要跨输入多个部分进行聚合的场景而设计。另一个关键区别是递归。在 RLM 中，递归并非比喻。模型实际上在代码生成的循环中调用语言模型，从而以可控的方式使工作量与输入大小成比例。
成本、权衡和局限性
也值得强调这种方法的一些缺点。RLMs 并不能消除计算成本。它们只是转移了成本。您不是为一次非常大的模型调用付费，而是为许多较小的调用以及代码执行和编排的开销付费。在许多情况下，总成本与标准的长上下文调用相当，但方差可能更高。实际挑战也存在。模型必须能够编写可靠的代码。约束不佳的模型可能会生成过多的子调用或无法干净地终止。输出协议必须仔细设计，以区分中间步骤和最终答案。这些是工程问题，而不是概念上的缺陷，但它们仍然很重要。
结论和参考资料
一个实用的经验法则是：如果您的任务仅仅因为输入变长而变得更难，并且如果摘要或检索会丢失重要信息，那么 RLM 值得考虑。如果输入很短且任务很简单，通常的标准语言模型调用会更快、更便宜。如果您想更深入地探索递归语言模型，以下资源是很好的起点：
- 论文： Recursive Language Models
- 官方 RLM 代码库： alexzhang13/rlm
- 作者博客文章概述： “Recursive Language Models” (Alex Zhang)
- OOLONG 基准（长上下文聚合基准）： Bertsch 等人，arXiv
- Anthropic 上下文工程视角： 关于代理为何难以处理长历史记录的有用背景信息
- 上下文腐烂报告和工具包： Chroma “Context Rot” 报告
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区