递归语言模型（Recursive Language Models） | Alex Zhang

作者：Alex Zhang, Omar Khattab | 日期：2025年10月15日

我们提出了递归语言模型（Recursive Language Models，RLMs），这是一种推理策略，使语言模型能够通过 REPL 环境，对无限长度的输入上下文进行分解并递归式交互。

完整论文已发布于此：

https://arxiv.org/abs/2512.24601v1

Recursive Language Models（RLMs）的官方代码仓库位于此：

https://github.com/alexzhang13/rlm

摘要（tl;dr）

我们探索了一类语言模型，它们在给出最终答案之前，会递归地调用自身或其他大语言模型。我们的目标是实现对本质上无限的输入上下文长度和输出长度的处理，并缓解所谓的“上下文腐烂（context rot）”问题。

我们提出了递归语言模型（Recursive Language Models，RLMs），这是一种通用的推理阶段策略，其中语言模型可以将其输入上下文视为一个变量，并与之进行递归式交互。我们设计了一个具体实现，在其中，GPT-5 或 GPT-5-mini 被置于一个 Python REPL 环境中进行调用，该环境会将用户的提示存储在一个变量中。

我们展示了：在我们能找到的最困难的长上下文基准测试之一（OOLONG：Evaluating Long Context Reasoning and Aggregation Capabilities）上，一个使用 GPT-5-mini 的 RLM，在正确回答数量上超过 GPT-5 两倍以上，同时平均每次查询的成本更低。

此外，我们还基于 BrowseComp-Plus 构建了一个新的长上下文 Deep Research 任务。在该任务上，我们观察到 RLMs 的表现优于 ReAct + 测试时索引与检索等方法。令人惊讶的是，当在推理阶段提供 超过 1000 万 token 的上下文时，RLM 的性能并未出现退化。

我们非常兴奋地分享这些仍然非常早期的实验结果，并认为 RLMs 将很快成为一种极具潜力的范式。我们相信，显式训练用于递归推理的 RLMs，很可能代表着继 CoT（Chain-of-Thought）推理模型和 ReAct 式代理模型之后，通用推理阶段扩展（inference-time scaling）的下一个重要里程碑。

我们在原始推文中提供了一个压缩版总结：

https://x.com/a1zhang/status/1978469116542337259

我们还提供了一个最小实现版本，供他人在此基础上进行构建：

https://github.com/alexzhang13/rlm-minimal

图 1：递归语言模型（RLM）调用示例。RLM 的行为形式是从文本到文本的映射，但比标准语言模型调用更为灵活，并且能够扩展到近乎无限的上下文长度。RLM 允许语言模型与一个环境进行交互（在本例中是一个 REPL 环境），该环境存储着（可能极其庞大的）上下文。在此环境中，模型可以递归地对子上下文发起“自我”查询、调用其他语言模型，或调用其他 RLM，从而高效地解析上下文并生成最终响应。

序言：为什么“长上下文”研究如此令人不满意？

在语言模型（LM）中，存在一种众所周知但难以精确定义的现象，被称为“上下文腐烂（context rot）”。Anthropic 将上下文腐烂定义为：“当上下文窗口中的 token 数量增加时，模型从该上下文中准确回忆信息的能力会下降”，但社区中的许多研究者都知道，这个定义并未真正切中要害。

例如，如果我们观察一些流行的“草堆找针”类基准测试，比如 RULER，大多数前沿模型实际上表现得非常好（在一年前的模型上也能达到 90% 以上的准确率）。

我让我的语言模型帮我完成它昨天开始雕刻的南瓜笑话。它回答说：“南瓜？什么南瓜？”——上下文已经完全腐烂了。

但是，人们已经注意到，上下文腐烂是一种很奇怪的现象，它会在你的 Claude Code 历史记录变得臃肿时出现，或者当你和 ChatGPT 聊天聊得很久时出现——几乎就像是，随着对话的推进，模型变得……更笨了？

这是一种大家都知道、却又很难描述的失效模式。由于我们无法对它进行基准化测试，因此我们通常不会在论文中讨论它。一个自然的解决思路大致是：“如果我把上下文拆成两次模型调用，然后在第三次模型调用中将它们合并，也许就能避免这种性能退化问题。”

我们正是以这种直觉为基础，提出了递归语言模型。

递归语言模型（Recursive Language Models, RLMs）

递归语言模型是在语言模型之上的一层轻量封装，它能够为中间计算生成（递归的）语言模型调用——从用户或程序员的角度来看，它的使用方式与一次普通的模型调用是完全一样的。

换句话说，你可以像调用语言模型 API 一样调用一个 RLM，例如，rlm.completion(messages) 可以直接替代 gpt5.completion(messages)。

我们采取的是一种以上下文为中心而非以问题为中心的输入分解视角。这种表述方式保留了我们想要的函数式视图：我们希望系统能够在给定某个查询以及其关联上下文的情况下，返回一个答案。

图 2：一次递归语言模型调用可以替代一次语言模型调用。它为用户提供了“近乎无限上下文”的错觉，而在系统内部，语言模型会负责管理、划分上下文，并根据需要对自身或其他语言模型进行递归调用，从而避免上下文腐烂。

在系统内部，RLM 只会将查询提供给语言模型（我们称之为根语言模型，或深度为 0 的语言模型），并允许该语言模型与一个环境进行交互。这个环境中存储着（可能极其庞大的）上下文。

我们选择的环境是一种循环结构，在其中，语言模型可以向 Python REPL Notebook（类似于 Jupyter Notebook 的环境）中的单元写入代码并读取其输出。该 Notebook 在初始化时会将上下文作为一个变量加载到内存中。

根语言模型可以像调用代码中的函数一样，在这个 REPL 环境中调用一个递归语言模型（或深度为 1 的语言模型），从而自然地查看、划分、grep 上下文，并在其上发起递归的子查询。图 3 展示了带有 REPL 环境的 RLM 如何生成最终答案的一个示例。

图 3：我们对 RLM 框架的一种实现，使根语言模型能够在 Python Notebook 环境中分析上下文，并对存储在变量中的任意字符串发起递归的语言模型调用（深度为 1）。语言模型通过输出代码块与环境交互，并在其上下文中接收（被截断的）执行结果。当它完成推理后，可以使用 FINAL(…) 标签输出最终答案，或者使用 FINAL_VAR(…) 返回代码执行环境中某个变量对应的字符串。

当根语言模型确信自己已经得到了答案时，它可以直接以 FINAL(answer) 的形式输出答案，或者在其 REPL 环境中逐步构建一个答案，并通过 FINAL_VAR(final_ans_var) 返回该变量中的字符串。

这种设置在实践中带来了若干显著的好处：

1. 根语言模型的上下文窗口几乎不会被堵塞——因为它从不直接看到完整上下文，其输入上下文增长得非常缓慢。
2. 根语言模型可以灵活地查看上下文的子集，或者以朴素的方式对上下文分块并递归处理。例如，如果查询是寻找“草堆找针”式的事实或多跳事实，根语言模型可以先使用正则表达式粗略缩小上下文范围，然后再对该上下文发起递归的语言模型调用。这一点在处理任意长度的长上下文输入时尤其有用，因为在推理时动态构建一个检索器的成本是很高的。
3. 理论上，上下文可以是任何能够加载进内存的模态。根语言模型可以完全控制如何查看和变换这些数据，并向递归语言模型发起子查询。

与测试时推理扩展（test-time inference scaling）的关系

我们对这种语言模型视角感到格外兴奋，因为它提供了另一条扩展测试时计算量的维度。语言模型选择如何与其上下文交互、以及如何对其进行递归的轨迹，是完全可以学习的，并且可以像当前前沿模型中的推理过程一样，通过强化学习进行训练。

有趣的是，这种方法并不直接要求训练能够处理超大上下文长度的模型，因为任何一次语言模型调用都不需要真正处理一个巨大的上下文。

带有 REPL 环境的 RLM 非常强大

我们强调，环境的选择是灵活的，并不固定为 REPL 或代码环境，但我们认为这是一个很好的选择。递归语言模型的两个关键设计选择是：

1）将提示视为一个 Python 变量，它可以在任意 REPL 流程中以程序化方式进行处理。这使得语言模型能够在测试时自行决定从长上下文中查看哪些内容，并按需扩展其决策过程（例如，自适应地设计自己的分块与递归方案）。

2）允许该 REPL 环境反向调用语言模型（或更小的语言模型），这一点得益于第（1）点所带来的分解能力与灵活性。

我们受到 CodeAct（Executable Code Actions Elicit Better LLM Agents）工作的启发，并推断，如果在这一系统中加入递归的模型调用，可能会带来显著更强的能力——毕竟，语言模型的函数调用本身就极其强大。

然而，我们认为，RLM 在根本上与以往工作对语言模型使用方式和代码执行方式的理解是不同的：在这里，上下文本身是模型需要理解的对象，而代码执行与递归语言模型调用只是高效理解该上下文的手段。

最后，在我们的实验中，我们只考虑了递归深度为 1 的情况——也就是说，根语言模型只能调用语言模型，而不能调用其他 RLM。将 REPL 环境改为调用 RLM 而不是 LM 是一个相对容易的改动，但我们认为，对于大多数现代“长上下文”基准测试而言，递归深度为 1 已足以解决大多数问题。

不过，在未来对 RLM 的研究中，允许更大的递归深度自然会带来更强大、也更有趣的系统。

形式化定义

考虑一个通用设置：一个语言模型 M 接收一个查询 q，以及某个相关的、可能很长的上下文
C = [c₁, c₂, …, cₘ]。

标准方法是将 M(q, C) 视为一个黑箱函数调用，它接收查询与上下文，并返回一个字符串输出。我们保留这种视角，但在模型之上定义了一层轻量的支架，以提供一个更具表达力、也更易解释的函数调用：
RLM_M(q, C)，其输入与输出空间与 M(q, C) 相同。

形式化地说，一个在环境 𝓔 上运行的递归语言模型 RLM_M(q, C)，同样接收一个查询 q 和一个相关的、可能很长的上下文 C = [c₁, c₂, …, cₘ]，并返回一个字符串输出。

其核心区别在于，我们为模型提供了一个工具调用
RLM_M( q̂ , Ĉ )，
该调用会生成一个隔离的子 RLM 实例，使用新的查询 q̂ 以及一个经过变换的上下文 Ĉ，并在其自身的隔离环境 𝓔̂ 中运行。最终，这个递归被调用实例的输出会被送回原始调用者的环境中。

环境 𝓔 在抽象层面上决定了语言模型 M 是如何被提示、查询和调度以生成最终输出的。在本文中，我们具体探索了一种 Python REPL 环境，该环境将输入上下文 C 作为一个变量存储在内存中。

这种特定的环境选择，使得语言模型能够查看、划分、变换并映射输入上下文，并利用递归语言模型来回答关于该上下文的子问题。与以往那些严格预定义工作流的代理方法不同，RLM 将这些决策完全交由语言模型自身来完成。

最后，我们指出，对环境 𝓔 的具体选择是灵活的，并且它是对基础模型调用的一种泛化：最简单的环境 𝓔₀ 仅仅是使用输入查询 q 和上下文 C 来调用模型 M，并将模型输出作为最终答案返回。

一些早期（而且非常令人兴奋）的结果！

我们一直在寻找能够反映自然长上下文任务的基准测试，例如长时间、多轮的 Claude Code 会话。我们特别希望突出两个限制现代前沿模型的关键属性：

1）上下文腐烂现象，即模型性能会随着上下文长度的增加而下降
2）在系统层面上处理超大规模上下文的能力限制

在实践中，我们发现许多所谓的长上下文基准测试，其上下文其实并没有那么长，而且已经可以被最新一代（甚至前两代）的模型轻松解决。事实上，我们还发现了一些基准，模型甚至在没有上下文的情况下也能回答问题。

幸运的是，我们很快找到了两个现代前沿大模型仍然难以取得良好表现的基准测试。同时，我们也在积极寻求任何其他值得尝试的优秀基准测试推荐。

令人振奋的结果一——应对上下文腐烂

OOLONG 基准测试是一个具有挑战性的新基准测试，用于评估模型在长上下文中针对细粒度信息的推理能力。我们很幸运地在请求后获得了该数据集的一个切分版本（作者为匿名，且与我们无任何隶属关系），从而得以在该基准上运行我们的实验。

实验设置

trec_coarse 切分包含 6 种不同类型的查询，用于在一个巨大的“问题”条目列表上回答分布型查询。例如，其中一个问题如下所示：

For the following question, only consider the subset of instances that are associated with user IDs 67144, 53321, 38876, 59219, 18145, 64957, 32617, 55177, 91019, 53985, 84171, 82372, 12053, 33813, 82982, 25063, 41219, 90374, 83707, 59594. Among instances associated with these users, how many data points should be classified as label 'entity'? Give your final answer in the form 'Answer: number'.

该查询后面紧跟着大约 3000 到 6000 行条目，每一行都包含关联的用户 ID（不一定唯一）以及未显式标注标签的实例（也就是说，模型必须先推断标签，才能回答问题）。这些条目大致如下所示：

Date: Dec 12, 2022 || User: 63685 || Instance: How many years old is Benny Carter ?
Date: Dec 30, 2024 || User: 35875 || Instance: What war saw battles at Parrot 's Beak and Black Virgin ?
Date: Apr 13, 2024 || User: 80726 || Instance: What Metropolis landmark was first introduced in the Superman cartoons of the 1940 's ?
Date: Feb 29, 2024 || User: 59320 || Instance: When was Calypso music invented?
...

评分方式是统计模型正确回答的查询数量；需要注意的是，对于数值型或计数型问题，基准采用连续评分指标。这个基准对于前沿模型和代理系统来说都极其困难，因为模型需要在一次查询中对数千条信息进行语义映射和关联，而且无法进行任何先验计算。

我们评估了以下模型 / 系统：

• GPT-5： 在给定完整上下文和查询的情况下，直接让 GPT-5 给出答案。
• GPT-5-mini： 在给定完整上下文和查询的情况下，直接让 GPT-5-mini 给出答案。
• RLM(GPT-5-mini)： 在给定完整上下文和查询的情况下，让 RLM(GPT-5-mini) 给出答案。GPT-5-mini（作为根语言模型）可以在其 REPL 环境中递归调用 GPT-5-mini。
• 不含子调用的 RLM(GPT-5)： 在给定完整上下文和查询的情况下，让 RLM(GPT-5) 给出答案。GPT-5（根语言模型）不能在其 REPL 环境中递归调用 GPT-5。这是一个消融实验，用于评估“仅使用 REPL 环境而不进行递归”的效果。
• ReAct + GPT-5 + BM25： 我们将每一行切分为一个独立的“文档”，并为 ReAct 循环提供一个 BM25 检索器，每次搜索请求返回 10 行内容。

结果

我们明确关注上下文长度超过 128k token 的问题（约 100 个查询），并同时跟踪模型在该基准上的表现以及每个查询的整体 API 成本。在以下所有结果中（图 4a、4b），完整输入都可以放入 GPT-5 / GPT-5-mini 的上下文窗口中——也就是说，错误预测从未源于截断或上下文窗口大小限制。

图 4a：我们报告了在 OOLONG 基准的 trec_coarse 数据集上、上下文长度为 132k token 的查询中，各方法的总体得分，并与 GPT-5 进行对比。RLM(GPT-5-mini) 的得分比 GPT-5 高出 34 分以上（约提升 114%），且每次查询的成本几乎相同（我们发现中位数查询成本更低，主要是由于少数成本极高的异常查询）。

事实证明，RLM(GPT-5-mini) 在原始得分上比 GPT-5 和 GPT-5-mini 高出 33% 以上（性能提升超过一倍），同时保持了与 GPT-5 每次查询大致相同的总模型 API 成本！在去除递归能力的消融实验中，我们发现 RLM 的性能下降了约 10%，这很可能是因为许多问题要求模型对数据进行语义层面的判断（例如为每个问题打标签）。在图 4b 中，我们看到当上下文规模翻倍至约 263k token 时，这些性能提升在很大程度上仍然成立，尽管存在一定程度的性能退化。

图 4b：我们报告了在 OOLONG 基准 trec_coarse 数据集上、上下文长度为 263k token（接近 GPT-5 / GPT-5-mini 的上限）时，各方法的总体得分，并与 GPT-5 进行对比。RLM(GPT-5-mini) 的得分比 GPT-5 高出 15 分以上（约提升 49%），且平均每次查询的成本更低。

值得注意的是，GPT-5-mini 的性能出现下降，而 GPT-5 的性能则没有明显下降，这表明上下文腐烂现象在 GPT-5-mini 上更加严重。我们还注意到，RLM 方法在上下文长度增加时的性能下降主要出现在计数类问题上——模型在上下文变长时更容易出错；而 GPT-5 在 132k 上下文的情况下就已经在这些问题上大量出错，这也解释了为什么它的性能看起来基本保持不变。最后，尽管 ReAct + GPT-5 + BM25 这一基线在该设置下并不十分合理，我们仍然提供了它的结果，以说明在这里检索是困难的，而 RLM 才是更合适的方法。

太棒了！我们在目标（1）上已经取得了巨大的进展：GPT-5 的上下文窗口刚好可以容纳 263k token 的情况。但目标（2）呢？如果上下文中包含 100 万、1000 万，甚至 1 亿 token，我们还能否将问题当作一次单一的模型调用来处理？

令人振奋的结果二——荒谬规模的超大上下文

我的导师 Omar 是信息检索（IR）领域的超级明星，因此我们也自然想探索：当给 RLM 提供成千上万（甚至更多）文档时，它是否还能良好扩展。OOLONG 基准提供的是一整块难以索引的大文本，因此很难与检索方法直接对比；于是我们转而研究类似 Deep Research 的基准测试，用于评估在大量文档上回答查询的能力。

在超大离线语料上的检索

我们最初关注的是 BrowseComp（一个用于评估浏览型代理的多跳网络搜索基准），随后发现了 BrowseComp-Plus 基准。该基准会预先下载所有查询可能涉及的相关文档，并直接提供一个约 10 万篇文档的列表（平均每篇约 5000 词），而某个查询的答案就散落在这份文档列表之中。

对于评测 RLM 来说，这是一个非常理想的基准：它可以检验我们是否能够直接把荒谬规模的上下文一次性丢进一个 chat.completion(...) 式的 RLM 调用中，而不是构建一个完整的代理系统。

实验设置

我们研究了在上下文中文档数量不断增加时，不同常见文本语料处理方法以及 RLM 的性能变化。

BrowseComp-Plus 上的查询是多跳的：它们要求跨多个不同文档进行信息关联。这意味着，即使你检索到了一个包含正确答案的文档，在没有完成其他关联推理之前，你也无法确认它就是最终答案。

例如，该基准中的第 984 个查询如下所示：

I am looking for a specific card in a trading card game. This card was released between the years 2005 and 2015 with more than one rarity present during the year it was released. This card has been used in a deck list that used by a Japanese player when they won the world championship for this trading card game. Lore wise, this card was used as an armor for a different card that was released later between the years 2013 and 2018. This card has also once been illegal to use at different events and is below the level 8. What is this card?

在实验中，我们考察了：当模型 / 代理 / RLM 能够访问**不同规模（不同文档数量）**的文档子集时，其性能表现如何——唯一的保证是：答案一定包含在该文档集合中。

在实践中，我们发现 GPT-5 在上下文中最多只能容纳约 40 篇文档，就会超过其输入上下文窗口（约 272k token）。这一限制直接影响了我们为各类基线方法选择的常数设置。

我们评估了以下模型 / 系统（与上一节实验类似）：

• GPT-5： 将所有文档与查询一起放入上下文，直接让 GPT-5 给出答案；若超过上下文限制，则不返回结果。
• GPT-5（截断）： 将所有文档与查询一起放入上下文，若超过上下文限制，则从最近的 token 开始截断（相当于随机丢弃文档）。
• GPT-5 + 预查询 BM25： 先使用原始查询通过 BM25 检索前 40 篇文档，再将这 40 篇文档与查询一起交给 GPT-5 回答。
• RLM(GPT-5)： 将所有文档与查询提供给 RLM(GPT-5)。GPT-5（根语言模型）可以在其 REPL 环境中“递归地”调用 GPT-5-mini。
• 不含子调用的 RLM(GPT-5)： 将所有文档与查询提供给 RLM(GPT-5)，但 GPT-5（根语言模型）不能在 REPL 环境中递归调用其他模型。这是一个用于评估“仅使用 REPL、但不使用递归”的消融实验。
• ReAct + GPT-5 + BM25： 将所有文档作为语料，使用一个 ReAct 循环，通过 GPT-5 并结合一个 BM25 检索器（每次检索返回 5 篇文档）来回答问题。

结果

我们需要强调：这些结果并非在整个 BrowseComp-Plus 数据集上得到的，而只是其中的一个小子集。图 5 展示了在 BrowseComp-Plus 上随机抽取的 20 个查询中，当上下文中包含 10、50、100 和 1000 篇文档时，各种方法的表现。

在所有实验中，我们始终确保：语料中包含正确答案对应的“黄金证据文档”，并在可用时加入了难负样本。

图 5：在 BrowseComp-Plus 上，给定不断增长的文档数量（上下文规模），我们绘制了不同方法在 20 个随机查询上的性能与单次查询 API 成本。只有迭代式方法（RLM、ReAct）在 100 篇以上文档的情况下仍能保持合理性能。

这里有几点值得注意：

首先，RLM(GPT-5) 是唯一一个在 1000 篇文档规模下仍能实现并保持完美性能的模型 / 系统；而不含递归的消融版本也能达到约 90% 的性能。

其次，无论采用何种方式对上下文进行条件化，基础 GPT-5 模型都会随着文档数量增加而出现明显的性能下降。

不同于 OOLONG 基准（在小上下文下模型本身就难以解决问题），在 BrowseComp-Plus 中，所有方法在上下文较小（10 篇文档）时都能解决任务，这说明这里的核心难点是找到并关联正确信息，而非处理复杂查询本身。

此外，RLM(GPT-5) 的单次查询成本会随着上下文规模增长而保持在一个合理范围内。

这些实验结果尤其令人兴奋：在不进行任何额外微调、也不修改模型架构的情况下，我们就能够在现实基准上处理超过 1000 万 token 的上下文语料，而且完全不依赖检索器。

需要指出的是，这里的基线方法实际上是按查询动态构建 BM25 索引，这比对完整 10 万文档语料进行一次性索引要更强；即便如此，RLM 仍然能在成本合理的前提下，优于 ReAct + GPT-5 + BM25 这种迭代检索方案。

太棒了！RLM 在我们的两个目标上都给出了非常漂亮的解决方案，并且提供了一种在不显著增加成本的前提下，自然扩展语言模型有效上下文窗口的方法。接下来的内容将聚焦于 RLM 在实际运行中表现出的各种有趣行为。

RLM 在做什么？一些有趣的案例……

RLM 框架的一个显著优势在于：我们能够在一定程度上解释它正在做什么，以及它是如何得出最终答案的。我们即兴编写了一个简单的可视化工具，用来窥探 RLM 的执行轨迹，从而得到了若干非常有意思的示例，可以用来说明 RLM 的实际行为方式。

RLM 自发形成的一些策略

在 RLM 层级上，我们可以完全解释语言模型是如何选择与上下文进行交互的。需要注意的是，在所有情况下，根语言模型在一开始只看到查询本身，以及一个提示：上下文存在于 REPL 环境中的某个变量里，并且它可以与之交互。

窥探（Peeking）

在 RLM 循环的最初阶段，根语言模型根本看不到上下文——它只知道上下文的规模。类似于程序员在分析一个数据集时会先查看几条样本，语言模型也可以“窥探”上下文的一小部分来观察其结构。在下面这个 OOLONG 的示例中，外层语言模型抓取了上下文的前 2000 个字符。

Greping（关键词 / 正则搜索）

为了缩小搜索空间，RLM 在 REPL 环境中可以不依赖语义检索工具，而是直接查找关键词或正则表达式模式，以快速定位感兴趣的行。在下面的示例中，RLM 查找了包含问题和 ID 的行。

分块 + 映射（Partition + Map）

在许多情况下，由于模型正在寻找的内容在语义上具有等价性，它无法直接通过 grep 或检索来定位信息。此时，RLM 常见的一种模式是：将上下文切分为更小的块，并对这些块分别发起多个递归语言模型调用，以提取答案或完成语义映射。在下面这个 OOLONG 的示例中，根语言模型要求递归语言模型为每一个问题打标签，并利用这些标签来回答原始查询。

摘要（Summarization）

RLM 是对常见“基于摘要的上下文管理策略”的一种自然泛化。RLM 经常会先对上下文的某些子集进行摘要，再将这些摘要结果交给外层语言模型用于决策。

超长输入，超长输出

一个特别有趣、同时也非常昂贵的失败场景，是那些需要生成极长输出的任务。例如，你可能把自己的论文列表交给 ChatGPT，让它为每一篇论文生成 BibTeX。类似于超大整数乘法问题，有些人会认为，模型不应该被期望在这类程序化任务上做到完全无误——而在这些情况下，带有 REPL 环境的 RLM 应该可以一次性完成任务。

一个例子是 LoCoDiff 基准测试（LoCoDiff Benchmark），该基准要求语言模型从头到尾追踪一段很长的 git diff 历史，并在给定初始文件的情况下输出最终结果。对于长度超过 75k token 的历史，GPT-5 甚至无法正确解决 10% 的案例。项目网站上给出的一个示例如下：


     
     git log -p 
--cc 
--reverse 
--topo-order 
-- shopping_list.txt

commit 008db723cd371b87c8b1e3df08cec4b4672e581b
Author: Example User
Date:   Wed May 7 21:12:52 2025 +0000


Initial shopping list  


diff --git a/shopping_list.txt b/shopping_list.txt
new file mode 100644
index 0000000..868d98c
--- /dev/null
+++ b/shopping_list.txt
@@ -0,0 +1,6 @@
+# shopping_list.txt
+apples
+milk
+bread
+eggs
+coffee

commit b6d826ab1b332fe4ca1dc8f67a00f220a8469e48
Author: Example User
Date:   Wed May 7 21:12:52 2025 +0000


Change apples to oranges and add cheese  


diff --git a/shopping_list.txt b/shopping_list.txt
index 868d98c..7c335bb 100644
--- a/shopping_list.txt
+++ b/shopping_list.txt
@@ -1,6 +1,7 @@

# shopping_list.txt

-apples
+oranges
milk
bread
eggs
coffee
+cheese
…

我们尝试使用 RLM(GPT-5) 来观察会发生什么，结果发现，在某些情况下，它会选择以程序化方式一次性处理整段 diff 序列来完成任务。语言模型在执行程序化任务方面存在许多可以基准化评估的能力（例如超大整数乘法、diff 跟踪等），但 RLM 提供了一种完全绕开这些能力需求的框架。

更多模式……？

我们预计，随着时间推移，会出现更多行为模式，尤其是在以下两种情况下：
1）模型能力持续增强
2）模型被专门训练或微调以适应这种工作方式

这一研究方向中一个尚未被充分探索的领域，是语言模型在与 REPL 环境交互时，究竟能做到多高效。我们相信，这些目标（例如速度、效率、性能等）都可以作为标量奖励进行优化。

局限性

我们并未对 RLM 的实现进行速度优化，这意味着每一次递归语言模型调用都是阻塞式的，并且没有利用任何前缀缓存机制。根据根语言模型所采用的分块策略，这种缺乏异步性的设计，可能导致单次查询耗时从几秒到数分钟不等。

此外，尽管我们可以通过增加最大迭代次数来控制 RLM 的长度或“思考时间”，但目前仍然无法对单次调用的总 API 成本或总运行时间提供强有力的保证。对于系统领域的研究者来说（咳咳，尤其是 GPU MODE 社区），这反而是个好消息：这里存在大量触手可及的优化空间，而要让 RLM 在规模化场景中运行，势必需要重新思考推理引擎的设计。

我们目前的思考与未来方向

语言模型的长上下文能力，最初被视为一个模型架构问题（例如 ALiBi、YaRN 等）。随后，社区又认为这是一个系统问题，因为“注意力机制是二次复杂度的”；但后来人们发现，真正的瓶颈往往出现在 MoE 层 上。如今，这个问题已经演变成了两者的结合，同时还叠加了这样一个事实：越来越长的上下文，并不很好地落在语言模型的训练分布之内。