Recursive Language Models

打破上下文诅咒：递归语言模型（RLM）让GPT-5处理无限长文本

想象一下，如果你的大脑内存只有几秒钟，你该如何阅读一本百万字的小说？

ArXiv URL：http://arxiv.org/abs/2512.24601v1

你会怎么做？你肯定不会试图把整本书背下来。相反，你会拿出一个笔记本，读一段，记一段，遇到不懂的再翻回去查阅，甚至把复杂的任务拆分成几个小问题逐个击破。

这正是今天我们要解读的这篇MIT重磅论文的核心思想。在长文本处理领域，我们一直试图把“书”塞进模型的“脑子”（Context Window）里，但递归语言模型（Recursive Language Models, RLMs） 告诉我们：别塞了，让模型学会自己“翻书”和“做笔记”吧。

核心痛点：上下文“腐烂”

尽管 Gemini 1.5 Pro 已经把上下文做到了 1M 甚至更多，但学术界发现了一个尴尬的现象：Context Rot（上下文腐烂）。

简单来说，随着输入文本长度的增加，即使是 GPT-5 这样的顶级模型，其推理能力也会迅速下降。就像图1展示的那样，在复杂的长文本任务（如 OOLONG-Pairs）中，当 Token 数超过一定阈值（红线区域），GPT-5 的表现几乎是断崖式下跌。

目前的解决方案通常是“压缩上下文”（Context Condensation），比如把前面的对话总结一下。但这有个致命弱点：你怎么知道哪些细节是可以被“遗忘”的？ 对于需要高密度信息的任务，压缩往往意味着丢失关键线索。

RLM 的魔法：把 Prompt 变成“环境”

MIT 的研究人员提出了一种全新的推理范式：Recursive Language Models (RLMs)。

RLM 的核心洞察非常反直觉：不要把超长 Prompt 直接喂给神经网络。

相反，RLM 把 Prompt 视为一个外部环境（External Environment）中的对象。具体来说，它包含以下几个步骤：

1. 环境初始化：RLM 创建一个 Python REPL（交互式编程环境）。

2. 变量存储：原本那个几百万字的超长 Prompt，不再直接进入模型的 Context Window，而是被赋值给一个 Python 变量 \(P\)。

3. 代码交互：模型通过编写 Python 代码来“查看”这个变量。它可以切片（\(P[0:1000]\)）、搜索关键词、或者统计长度。

4. 递归调用：这是最酷的部分。模型可以编写代码，将切片后的文本片段作为新的 Prompt，递归地调用自己（或者其他模型）来处理这些子任务。

如图2所示，这就像给大模型装上了一个“操作系统”，它不再是被动接收信息的接收者，而是变成了主动管理信息、调用自身的管理者。

为什么 RLM 如此强大？

这种设计带来了两个巨大的优势：

1. 无限上下文：理论上，只要你的内存存得下字符串变量，RLM 就能处理。论文中，RLM 成功处理了超出模型上下文窗口 两个数量级 的输入（10M+ Tokens）。

2. 分治算法的智慧：通过递归，RLM 强迫模型将一个巨大的复杂问题（比如“总结这1000个文档”）拆解为可管理的子问题（“分别总结每个文档，然后合并结果”）。这种程序化的分解（Programmatic Decomposition） 比让模型在一段长文本里“大海捞针”要稳定得多。

实验结果：吊打传统方法

研究团队在 GPT-5 和开源模型 Qwen3-Coder 上测试了 RLM。结果令人震惊：

• 性能飞跃：在信息密度极高的 OOLONG 和 CodeQA 任务中，RLM 的表现大幅超越了直接调用 LLM、RAG（检索增强）和传统的 Agent 方法。

• 成本可控：你可能会担心，递归调用会不会很贵？令人意外的是，RLM 的单次查询成本通常与传统方法相当，甚至更低。因为模型学会了只读取“需要”的部分，而不是每次都把几百万字读一遍。

• 抗衰减：在图1中可以看到，当输入长度从 $2^{13}$ 增加到 $2^{18}$ 时，GPT-5 的原生性能一路下滑，而 RLM 却保持了一根坚挺的水平线。

深度思考：模型即算法

RLM 的出现引发了一个有趣的思考：未来的大模型，究竟是一个存储知识的数据库，还是一个执行逻辑的 CPU？

RLM 实际上是将 LLM 降级为推理单元（CPU），而将上下文管理交给了外部代码（RAM）。这种“模型即算法”的思路，或许才是通往 AGI 的正确路径。它不再依赖模型“死记硬背”所有上下文，而是教会模型如何像人类一样，利用工具和逻辑去处理无限的信息。

如果 GPT-5 是一个超级天才，RLM 就是给了这个天才一本无限页的笔记本和一支笔。 这两者的结合，才真正释放了长文本处理的潜力。