递归语言模型：让长输入处理超越上下文窗口

MIT 研究人员的一篇论文介绍了递归语言模型（RLM），用以处理比模型自身上下文窗口长得多的提示。在我看来，这是一个令人兴奋的脚手架例子：围绕语言模型构建的软件，可以让模型以新的方式运用现有能力。这项技术并没有消除底层模型的上下文限制，也不能保证无限且准确的处理能力。

研究人员在上下文增长时难度也会增加的任务上，比较了普通 GPT-5 和 RLM。视频强调，普通模型在单个“大海捞针”检索任务中表现出色，但在 OOLONG 和 OOLONG-Pairs 上弱得多。画面中的实验显示 RLM 表现更稳定，不过它在较难任务上的分数远未达到完美。

上下文窗口限制了模型在单次调用中可以接收的信息量。即使在这个限制以内，随着输入变长，寻找细节和关联信息也可能更加困难。这种表现下降通常称为上下文退化，其程度取决于模型和任务。

问题在于，我们能否不修改模型本身，就处理大得多的材料集合。这对长期任务、文档集合和大型代码库都很重要。[论文](https://arxiv.org/html/2512.24601v1)测试的是特定基准和输入，其中包括一个 600 万至 1100 万 token 的文档集合；它没有证明实践中可以无限扩展。

一种常见的替代办法是压缩上下文：当先前上下文过长时，对它进行摘要。这很有用，但会造成信息损失。先总结一个故事，再反复总结这个摘要，可能会丢掉后续问题恰好需要的细节。

论文提出的方法则把长提示放到外部编程环境中。模型编写代码检查和操作保存的文本，并有选择地将片段放入调用。它在选择性访问方面类似检索，但模型还可以通过程序拆分工作，并对片段调用语言模型。

在论文的例子中，Python REPL 将长输入保存为一个变量。根模型可以把它分成几个部分，就选定片段询问模型，再合并返回结果。这些都是针对部分材料、受到限制的模型调用，并不是在一个扩大的窗口中同时关注全部输入。

想象一本很长的书，以及一个关于灾难前制造的物品的问题。系统可以检查章节，把相关段落交给子调用，再汇总答案。这避免了必须先为整本书生成一份摘要，但该方法仍可能遗漏证据、犯错或给出不完整的结果。

这体现了模型习得的能力与围绕它构建的工具之间的区别。我对添加记忆、代码执行和其他脚手架很有热情。我认为现有模型足以满足几乎所有用例，这是个人观点，并非这项研究得出的结论。

本视频由 Zapier 赞助。Berman 结合自己使用该平台的经历，介绍了 Zapier Agents、工作流集成，以及通过 MCP 与 Claude 的集成。这些是他和赞助商的产品说法，并非 RLM 研究的发现。

论文作者使用了多种长上下文测试。简单的“大海捞针”测试要求模型从大量文本中找出预先植入的事实。在某一此类检索测试中表现出色，并不能证明模型能够可靠处理每一种“大海捞针”测试，或能在长输入中进行复杂推理。

更难的评估包括：用于多文档问题的 BrowseComp-Plus、考查语义处理与聚合的 OOLONG、考查成对聚合的 OOLONG-Pairs，以及来自 LongBench v2 的代码问答。它们测试的是检索、推理和综合能力的不同组合，而不仅仅是定位一个事实。

模型宣传的最大输入长度，并不总等同于它在特定任务中的有效上下文长度。比较输入中相距很远的文档内容，可能比检索一个明确的值困难得多。研究人员评估了任务复杂度和长度如何影响表现。

例如，在简单的“大海捞针”测试中，研究人员把密码嵌入无关文本，再要求模型找出密码。Berman 说前沿模型在这类任务上表现很好；这不应理解为模型在所有条件下都能完美检索。

BrowseComp-Plus 要求利用多个文档的信息回答问题。OOLONG 要求模型解读并聚合长输入的各个片段，OOLONG-Pairs 则进一步要求将片段成对组合，提高了难度。这些任务区分了单纯检索与要求更高的证据处理和组合工作。

在代码理解方面，研究人员使用 LongBench v2 的 CodeQA 子集。一个关于代码仓库的问题可能需要追踪不同文件中函数之间的关系，因此只看一个片段可能不够。评估衡量的是所选基准上的表现，而非所有真实代码库。

主要比较使用 GPT-5 和 Qwen3-Coder-480B-A35B，以及多种方法：基础模型、带检索的 CodeAct、摘要智能体、RLM，以及没有递归子调用的消融版本。配置细节很重要：没有子调用的 RLM 仍然可以使用 REPL 检查外部输入。

论文表格中，使用 RLM 的 GPT-5 在报告的四项任务上都优于列出的 GPT-5 基线。结果会随底层模型变化：对于 Qwen，无子调用版本在 CodeQA 和 BrowseComp-Plus 上胜过递归版本。因此，递归并非在每次比较中都是最优选择。

论文报告，RLM GPT-5 在 BrowseComp-Plus 上得到 91.33 分，摘要智能体得到 70.47 分；平均 API 成本分别为 0.99 美元和 0.57 美元。在这项具体比较中，RLM 得分更高，但成本并不更低。这些是特定价格和配置下的研究测量结果。

作者还将平均 0.99 美元的成本，与假设 GPT-5-mini 完整读取 600 万至 1100 万 token 时估算的 1.50 至 2.75 美元作比较。这是通过线性外推得到的理论完整输入成本，并不是实际运行了具备该上下文容量的模型。不应将它误认为普遍存在的成本节省。

消融实验表明，将输入放进 REPL 有助于处理超出基础窗口的文本，而递归模型调用可能有助于 OOLONG-Pairs 等信息密集型任务。这并不意味着系统总能找到所有有用上下文：该方法仍依赖模型的选择和执行环境。

研究还报告说，表现会随输入长度和问题复杂度变化。在实验中，普通 GPT-5 在较难任务上退化更快，而 RLM 退化得更慢。论文指出，基础模型在较短输入上可能表现更好，因此增加脚手架也有取舍。

成本是另一项取舍。子调用的数量和长度因任务而异，部分较长的执行路径会产生高成本异常值。例如，论文报告 GPT-5 RLM 在 OOLONG-Pairs 上的平均成本为 0.33 美元，基础模型则为 0.16 美元；延迟和实现方式也很重要。

该框架设计为与具体模型无关，但这是设计属性，并不能证明它对每个模型都同样有效。GPT-5 和 Qwen3-Coder 作出了不同选择，也取得了不同结果。在 BrowseComp-Plus 上，GPT-5 RLM 得到 91.33 分，Qwen RLM 得到 44.66 分。

成本图比较了不同方法在第 25、50、75 和 95 百分位的成本。部分 RLM 运行仍然便宜，但尾部成本急剧上升。只看成本也会忽略不同方法之间的质量差异。

论文展示了 RLM 可能编写的代码：搜索和筛选上下文，再就有用片段查询模型并合并结果。关键词搜索和正则表达式只是示例，不能保证找出所有相关段落。

我认为这篇论文很有说服力，因为它表明在模型本身不断进步的同时，围绕模型构建的工具也有改进空间。这是一种很有前景的研究方法，但测试工作负载有限、成本会波动，可靠性也仍有待解决；它并没有证明上下文无限。