递归语言模型 RLM 推理范式深读

一句话结论

Recursive Language Models（RLM）不是一种新的模型架构，而是一种推理时的脚手架（inference-time scaffold）：它把长 prompt 当作 REPL 环境里的一个变量，让根 LLM 通过写 Python 代码去切片、检索、并递归地把片段交给子 LLM 处理，最终再把答案聚合回来。它和 Mixture-of-Recursions（MoR）等"递归 Transformer 架构"是两类完全不同的工作，常被混淆。

来源：Alex L. Zhang、Tim Kraska、Omar Khattab，MIT CSAIL，arXiv:2512.24601（v1 2025-12-31，v3 2026-05-11）；同名博文 2025-10。

递归语言模型 RLM 推理脚手架图

问题背景：为什么"长上下文"研究让人不满意

社区里有一个"context rot"的提法，Anthropic 给出的口径是：随着上下文 token 数增长，模型从上下文中准确召回信息的能力会下降。但 RLM 论文一开篇就指出，这个口径并不完全描述真实痛点：

在 needle-in-the-haystack 类的检索基准（如 RULER）上，前沿模型早就能拿到 90%+。这类基准并没揭示真实退化。
真实退化体现在另一种场景：和 Claude Code 持续对话直到 history 膨胀、和 ChatGPT 长对话之后，模型像"变笨了"。这种退化既难以基准化，也很难在论文里量化。

RLM 把这个问题重新定义：长 prompt 本来就不该被一股脑塞进 Transformer 的 context window，它应该被当作"环境的一部分"，由模型用程序化的方式去交互。

RLM 的形式化定义

给定一个底层语言模型 $\mathcal{M}$ ，最大上下文长度为 $K$ 。一个 RLM 是围绕 $\mathcal{M}$ 的推理时脚手架，对外暴露的函数签名与一次普通 LLM 调用完全一致：

# 普通 LLM 调用
gpt5.completion(messages)

# RLM 调用 —— 同样的签名，但底层支持任意长度的 prompt
rlm.completion(messages)

形式上，给定任意长 prompt $P \in \Sigma^{\star}$ ，RLM 在外部维护一个持久 REPL 环境 $\mathcal{E}$ ，最终返回字符串响应 $Y \in \Sigma^{\star}$ 。理想目标是三个"无界"：

输入 token 无界： $|P| \gg K$
输出 token 无界
语义计算无界：可以在 prompt 上做 $\Omega(|P|)$ 甚至 $\Omega(|P|^2)$ 量级的语义工作

来源：arXiv:2512.24601 v3 §2。

核心算法：根 LLM + REPL + 子 RLM 调用

论文给出的 Algorithm 1 可以浓缩成下面这套循环：

初始化一个 REPL 环境，把整个用户 prompt $P$ 作为一个 Python 变量装进去。
在该环境里注入一个函数 sub_RLM(prompt)，可被根模型作为工具调用。
根模型 $\mathcal{M}$ （深度=0）只看到 prompt 的元数据：长度、前缀、访问方式说明。它永远看不到完整 prompt。
进入主循环：
- 根模型生成一段代码（例如 len(P)、re.findall(r"User: \d+", P)、sub_RLM("总结这一段：" + P[100000:200000])）。
- REPL 执行代码、更新中间变量、收集 stdout。
- 只有 stdout 的常量级元数据（短前缀 + 长度）被追加进根模型的对话历史，进入下一轮。
当根模型把答案写入特殊变量 Final 时，循环停止，返回 Final 内容。

这一步是 RLM 的关键约束：每一轮根模型实际新增的上下文是常量大小。如果每轮裁剪到 $c$ tokens，根模型最多迭代 $K/c$ 轮，但每一轮都可以发起任意多次子 RLM 调用，每次子调用都拥有自己独立的 REPL 与上下文。这就是它在保持单次模型调用 prompt 短的前提下，仍然可以处理 10M+ tokens 输入的原因。

graph TB
    User[用户 prompt P]
    Root[根 LM depth=0 只看到 P 的元数据]
    REPL[REPL 环境 P 作为变量]
    Sub1[子 RLM depth=1 处理 P 的某个切片]
    Sub2[子 RLM depth=1 处理 P 的另一个切片]
    Final[Final 变量]

    User --> REPL
    REPL --> Root
    Root --> REPL
    REPL --> Sub1
    REPL --> Sub2
    Sub1 --> REPL
    Sub2 --> REPL
    REPL --> Final
    Final --> Root

三个看似相似但本质不同的设计选择

论文用 Algorithm 2 故意写出一个"看起来差不多但弱很多"的算法来对比，凸显 RLM 的三个核心选择。

第一，prompt 作为变量，不是作为 token 流。普通 ReAct 风格的 agent 把 prompt 直接灌进根模型的 context window；compaction（Claude Code、Codex 的做法）则是定期对历史做摘要再继续。RLM 让 prompt 成为 REPL 里一个名为 P 的字符串变量，根模型通过写代码（切片、grep、正则、分块）来"看"它，而不是被它撑爆 context。

第二，递归发生在 REPL 中，由代码驱动。Anthropic 的 sub-agent 委托、Sentient 的自委托一类工作，是让根模型在生成 token 时"自然语言地"召出一个子调用，再把子调用的输出 autoregressive 地拼回来。这种做法被根模型自身的输出长度卡死。RLM 让递归调用以函数调用形式发生在 REPL 里，根模型只产出代码，子调用的具体参数（包括把哪一段 1M tokens 的 slice 传给子调用）由代码决定。

第三，中间值在变量里，不在上下文里。所有 sub-RLM 的输出、所有 grep 命中的片段、所有阶段性总结，都先落到 REPL 的变量里，根模型只通过元数据（长度、前缀）来观察它们。需要再处理时，再写代码进一步切。这是 RLM 能扛住 10M+ token 输入的根本原因。

设计维度	普通 LLM 调用	ReAct 子委托	Compaction	RLM
Prompt 形态	token 流，全量进 context	token 流，全量进 context	token 流 + 周期性摘要	REPL 变量，根模型只看元数据
递归形式	无	自然语言 autoregressive	无	Python 函数调用
中间值存放	模型自身上下文	模型自身上下文	摘要后的上下文	REPL 变量
处理 10M token	不可行	不可行	信息损失严重	可行

REPL 环境的实际样貌

参考实现把环境做成一个 Jupyter 风的 Python notebook，根模型每一轮输出一个 cell（代码块），REPL 执行后把（截断的）输出回填给根模型。当根模型确信已经得到答案时，可以走两条路收尾：

FINAL(answer)：直接把答案以字符串形式终止。
FINAL_VAR(var_name)：把 REPL 中某个变量名指定为最终答案，由 RLM 框架读出该变量的字符串值。后者适合答案本身需要由代码组装（比如 1000 条命中纪录的列表）的情况。

REPL 在工程实现上是可替换的，作者的开源仓库支持 7 种环境：local（同进程 exec）、ipython（in-process 或子进程隔离）、docker、modal、prime、daytona、e2b。生产环境推荐 isolated sandbox 以避免恶意 prompt 触发主机执行风险。

来源：github.com/alexzhang13/rlm README。

# 安装
# pip install rlms

from rlm import RLM

rlm = RLM(
    backend="openai",
    backend_kwargs={"model_name": "gpt-5-nano"},
    verbose=True,
)

resp = rlm.completion("Print me the first 100 powers of two, each on a newline.")
print(resp.response)

Prime Intellect 在自己的 verifiers 仓库里复现了 RLM，并加了几条工程性增强：

llm_batch(prompts) 函数允许根模型在 REPL 中并行发起一批子调用。
工具（web、file system 等）只对子 LLM 可见，根 LLM 不直接持有工具。理由是工具回调通常会产生大量 token，把这些 token 留在子调用里、不污染根的上下文。
答案以一个 answer = {"content": "", "ready": False} 字典存放，根模型可以多轮迭代修改 content，直到把 ready 置为 True 才结束 rollout。这等价于把答案生成做成"在推理过程中扩散式构造"。

来源：primeintellect.ai/blog/rlm。

实验结果与定量数据

论文用 GPT-5 作为闭源基线、Qwen3-Coder-480B-A35B 作为开源基线，sub-RLM 调用使用 GPT-5-mini，跨四个长上下文任务评测：

BrowseComp-Plus（深度研究 + 多跳检索，1000 文档）
OOLONG（合成式信息聚合，要求对 input chunk 做变换+聚合，复杂度随上下文线性增长）
LongBench-v2 CodeQA（代码仓库理解）
一个新构造的成对推理任务（即使前沿模型也会大幅崩溃）

关键结论按定量给出：

跨四个基准、相对 GPT-5 系列的中位增益：vs context compaction +26%，vs CodeAct + sub-calls +130%，vs Claude Code +13%，且总成本可比。
在 OOLONG 最难分片上，使用 GPT-5-mini 的 RLM 答对题目数超过 vanilla GPT-5 的 2 倍，单 query 成本反而更低。
在 BrowseComp-Plus 上，10M+ token 输入下 RLM 仍不出现明显退化。S-NIAH、OOLONG、OOLONG-Pairs 三条任务上把上下文长度从 $2^{13}$ 一路扫到 $2^{20}$ ，GPT-5 单调下滑，RLM 几乎平。
后训练实验：从 1000 条与目标任务无关领域的样本上做 SFT，得到的 RLM-Qwen3-8B 比未训练的 Qwen3-8B 在四个任务上中位提升 28.3%，并在三个任务上接近 vanilla GPT-5。

来源：arXiv:2512.24601 v3 Abstract + §3 + §4。

对比项	中位增益（基于 GPT-5）
RLM vs context compaction	+26%
RLM vs CodeAct + sub-calls	+130%
RLM vs Claude Code	+13%
RLM-Qwen3-8B vs Qwen3-8B	+28.3%

与 Mixture-of-Recursions（MoR）的彻底区分

中文社区常把"递归语言模型"和"递归 Transformer"混为一谈。两者完全不在一个层面上，必须分清。

MoR（Bae 等，arXiv:2507.10524，KAIST × Google DeepMind × Mila，NeurIPS 2025）是模型架构层的工作。它的核心机制：

共享一组 Transformer 层，让 token 在同一组层上反复执行多步（递归深度），实现参数共享。
通过轻量级 router，对每个 token 动态分配不同的递归深度，等价于 token 级别的"自适应计算"。
配合 KV 共享变体，进一步降低显存。
实验在 135M – 1.7B 规模下相对 vanilla 与已有递归基线建立了新的 Pareto 前沿。

MoR 属于训练时改架构的方法，RLM 属于推理时不改架构的脚手架。MoR 在解决"如何用更少参数训出同等能力"，RLM 在解决"在不重训模型的前提下如何处理超长上下文"。两者甚至可以叠加：RLM 的根模型本身可以是一个 MoR 训练出来的递归 Transformer。

维度	MoR（递归 Transformer 架构）	RLM（递归推理脚手架）
工作层面	模型架构 + 训练	推理时调度
是否改模型	是，层共享 + token-level router	否，黑盒 LLM API 即可
解决问题	参数效率 + 自适应计算	长上下文 + context rot
实验规模	135M – 1.7B	调用 GPT-5 / Qwen3-Coder-480B
输出	新的 base model 架构族	一个 `rlm.completion()` API
论文	arXiv:2507.10524	arXiv:2512.24601

与 ReAct、RAG、Compaction 的横向对比

范式	上下文是	检索粒度	对超长输入	典型代表
普通长上下文	token 流	全量进窗	context rot 严重	GPT-5 直接调用
Compaction	token 流 + 周期摘要	摘要后再用	信息有损	Claude Code、OpenAI Codex
RAG	token 流 + 外部检索拼接	文档 chunk 进窗	检索质量决定上限，长文档仍会撑爆窗	大多数生产 RAG
ReAct / agent	token 流 + 工具调用	工具结果进窗	工具回放堆积	LangChain agent
Context-folding	token 流 + 自总结分支	分支返回后保留摘要	仍有信息损失	AgentFold、Context-Folding
RLM	REPL 变量	代码切片 + 子 RLM 调用	10M+ token 不退化	rlms（MIT CSAIL）

需要强调一点：RLM 与 RAG 不是替代关系。RLM 内部完全可以让子 RLM 调用一个 retriever。区别在于"信息流"的方向——RAG 把检索结果灌回根模型的上下文，根模型直接看；RLM 让根模型通过代码间接看，根模型自身的窗口始终保持稀疏。

一个有用的隐喻：推理时的操作系统

知乎社区里有人把 RLM 比喻成"推理时的操作系统"，这个比喻和论文论述高度契合：

Context = Disk：长 prompt 是被持久化的"磁盘数据"，不该常驻"内存"。
根 LLM = CPU：调度者，决定何时把哪一段 disk 数据加载进自己的"register"（短暂上下文）。
子 RLM = 进程：每次子调用是隔离的子进程，有自己的环境、自己的退出值。
REPL = 系统调用接口：CPU 通过这个接口对 disk 做 read/write/exec。

这个隐喻有助于理解为什么作者团队认为 RLM 是"继 reasoning model（CoT）和 ReAct agent 之后的下一个 inference-time scaling 范式"——它给出了一种可学习的调度策略：根模型何时切片、切多大、何时调子模型，都是可以通过 RL 训练的轨迹。

局限与争议：递归本身是不是关键？

Apple 在 2026-03 的 arXiv:2603.15653（“Recursive Language Models Meet Uncertainty”）里提了一个重要质疑：递归本身可能并不是 RLM 性能的主要驱动因素。该工作的核心实证：

提出 SRLM（Self-Reflective Program Search），在 RLM 同样的 REPL 环境下做不确定性引导的程序搜索（self-consistency、verbalized confidence、reasoning trace length 三种信号），同 wall-clock 预算下相对 RLM 提升最多 22%。
在 GPT-5 backbone 下，去掉递归子调用的 RLM 变体在多数情况下反而胜过带递归的版本。
RLM 的递归过程对上下文长度敏感：在底层模型原生 context window 内（短上下文），RLM 多数情况下不如直接调用 base model；优势主要体现在超出 native window 之后。

这一争议把 RLM 的核心贡献定位推到了一个更谨慎的位置：在底层模型 context 还能撑得住的时候，递归带来的开销可能不划算；真正不可替代的优势在 $|P| \gg K$ 区间。论文作者在 v3 里也承认递归不是 always-on 的银弹，并给出了相应的 fail-mode 分析。

来源：arXiv:2603.15653 v1 §1。

工程含义

对于真正在生产中处理长上下文的团队，RLM 提供了几条具体可落地的启示：

接口同构是一个被低估的优点。rlm.completion() 与 llm.completion() 函数签名一致，意味着它可以作为一个 drop-in 替换嵌入现有 agent 框架，而无需改造 prompt 模板、消息协议、tool calling schema。

Sandbox 选型决定生产可用性。论文的开源实现默认 in-process exec，便于 benchmark；生产场景必须用 docker / modal / e2b / daytona 这类隔离 sandbox，否则用户 prompt 中的指令可能驱动根模型生成 RCE 代码。

子调用并行化与工具下沉。Prime Intellect 的 llm_batch + 工具仅对 sub-LLM 可见这一组合是值得借鉴的工程默认值：根模型保持稀疏的上下文，工具 IO 的脏 token 留在子调用里。

后训练成本极低，但需要强基模。1000 条无关领域 SFT 即可把 Qwen3-8B 提升 28.3%，但前提是基模本身的"代码生成 + 工具调用"能力已经过关。8B 以下、缺乏 code agent 能力的模型即便嵌入 RLM 框架也难有显著提升，论文中已经做了这一对照。

适用场景判断：当输入长度持续超过 base model 窗口的 1.5 – 2 倍以上时，RLM 的边际收益开始大于其调度开销；如果 prompt 始终在 native window 内，直接调用 base model 通常已足够，引入 RLM 反而可能引入 SRLM 工作中观察到的退化。

一些容易被混淆的术语对照

Recursive Language Models（RLM）：本文主角，推理时脚手架，arXiv:2512.24601。
Recursive Transformer：广义概念，指 Transformer 层共享 / 重复执行架构族。
Mixture-of-Recursions（MoR）：Recursive Transformer 的一种具体实现，token-level 自适应递归深度，arXiv:2507.10524。
Recursive Self-Improvement（RSI）：AGI 语境下的"模型反复自我改造代码"假说，与本文无直接关系，常被混入搜索结果。
ReAct：Reason + Act 的 agent 范式（Yao 等 2022），是 RLM 论文中作为 baseline 比较的对象之一。
DSPy：Khattab 主导的 LLM 程序框架，与 RLM 同一作者群，可以把 RLM 视为 DSPy 思想在长上下文场景下的产物。

参考资料

Recursive Language Models（原始博文，Alex L. Zhang，2025-10）

Recursive Language Models（arXiv:2512.24601 v3，2026-05-11）

arXiv:2512.24601 v3 HTML 版（含算法 1/2 与全部图表）

github.com/alexzhang13/rlm —— 官方推理库 rlms

Recursive Language Models: the paradigm of 2026（Prime Intellect blog）

Mixture-of-Recursions（arXiv:2507.10524，KAIST × Google DeepMind × Mila，NeurIPS 2025）

Recursive Language Models Meet Uncertainty（arXiv:2603.15653，Apple，2026-03）

BrowseComp-Plus benchmark（OpenReview）

Oolong benchmark（Bertsch et al. 2025，arXiv:2511.02817）