递归语言模型 Recursive Language Models
通过递归调用和环境变量突破LLM上下文限制的新范式
前置知识
上下文窗口
上下文窗口是指Transformer模型在推理时能够处理的最大token序列长度，这个限制主要来源于自注意力机制的二次计算复杂度和训练时使用的位置编码。当输入超过这个长度时，必须被截断、压缩或通过其他方式处理，这会导致信息丢失。例如，论文中使用的GPT-5模型具有272K token的上下文窗口限制，这对于处理百万级别的代码库或大型文档集合来说远远不够。虽然现代模型不断扩展上下文窗口，但硬件成本和训练复杂度使得单纯增加窗口长度并非可持续的解决方案。理解上下文窗口限制的物理和计算基础对于理解为什么需要像RLM这样的推理时架构至关重要。
理解上下文窗口限制的来源对于理解RLM的设计动机至关重要。Transformer的自注意力机制复杂度是二次的，这意味着处理长序列的计算成本会迅速增长，这从根本上限制了模型的上下文窗口大小。同时，训练时使用的位置编码也有固定的长度，这意味着模型在训练时从未见过超过这个长度的序列。RLM的整个设计哲学就是绕过这些根本性的限制，通过推理时架构而不是模型架构来解决长上下文问题。如果不理解这些根本限制，就难以理解为什么RLM选择将提示视为外部环境而不是直接喂入模型，以及为什么这是一个更可持续的解决方案。
上下文退化
上下文退化是指一种现象，即在模型的理论上下文窗口范围内，随着输入长度增加，模型性能显著下降，而非简单地在窗口边界处突然失效。这种退化并非由于模型容量不足，而是模型在处理长序列时难以保持对早期关键信息的关注能力，注意力分散导致信息丢失。论文中Figure 1清晰展示了GPT-5在不同任务长度下的性能下降曲线，可以看到在更复杂的任务上性能下降更为迅速。例如，在S-NIAH任务上GPT-5还能在较长输入下保持较好性能，但在OOLONG和OOLONG-Pairs任务上性能急剧下降。理解上下文退化现象对于理解为什么单纯增加上下文窗口长度不能完全解决问题非常关键。
这解释了为什么单纯增加上下文窗口长度不能完全解决问题，RLM需要解决的核心挑战之一就是缓解这种退化现象。上下文退化表明即使有足够的容量，模型也难以有效利用长上下文中的信息。这是一个更深层的问题，可能涉及到注意力机制的固有缺陷或训练数据的分布偏差。RLM通过允许模型程序化地探索和分解输入，而不是一次性处理所有内容，从根本上改变了信息处理的方式。这种设计让模型能够专注于当前相关的信息部分，而不是被大量不相关的信息淹没。理解上下文退化对于理解为什么RLM的设计选择是有效的非常重要。
REPL环境
REPL是Read-Eval-Print Loop的缩写，是一种交互式编程环境，用户可以逐个输入代码片段，立即执行并获得反馈，然后继续输入下一段代码。在RLM中，REPL被用作持久化环境，用户的输入被存储为环境中的变量，LLM可以在这个环境中编写Python代码来探索、分解和操作输入。与传统的将所有token都输入模型的方式不同，REPL允许LLM通过编程方式而非纯token流来处理信息，这意味着LLM可以编写循环、条件判断、函数调用等程序结构来智能地处理输入。理解REPL如何作为环境载体以及LLM如何与这个环境交互对于理解整个RLM方法的工作原理至关重要。
这是RLM架构的基础，理解REPL如何作为环境载体以及LLM如何与这个环境交互对于理解整个方法的工作原理至关重要。传统的LLM调用是纯函数式的：给定输入产生输出，没有状态。而REPL提供了一个持久化的状态空间，LLM可以在这个空间中存储中间结果、定义函数、编写循环等。这从根本上扩展了LLM的能力，使其能够执行复杂的算法而不仅仅是模式匹配。REPL还提供了一个自然的接口让LLM与自身交互，通过递归调用来分解问题。不理解REPL的作用就难以理解RLM相对于传统方法的优势在哪里。
任务复杂度缩放
任务复杂度缩放是指任务难度随着输入长度增长而增长的速率，这是理解为什么不同方法在不同长上下文任务上表现差异巨大的关键概念。论文将任务分为三个复杂度类别：常数复杂度如S-NIAH，需要的信息量是O(1)，因为needle的数量不随haystack大小变化；线性复杂度如OOLONG，需要的信息量是O(|P|)，因为答案依赖于输入中的几乎每一行；二次复杂度如OOLONG-Pairs，需要的信息量是O(|P|^2)，因为需要考虑输入中所有条目对。论文的核心假设是有效上下文窗口不能独立于具体任务来理解，更复杂的任务会在更短的输入长度下就表现出性能下降。理解任务复杂度如何随输入缩放对于理解RLM的优势所在非常重要。
论文的一个核心假设是有效上下文窗口不能独立于具体任务来理解，理解任务复杂度如何随输入缩放对于理解RLM的优势所在非常关键。不同任务对上下文长度的敏感度不同，常数复杂度的任务如S-NIAH即使在海量输入下也能保持较好性能，因为needle的相对位置不变。但线性或二次复杂度的任务需要在整个输入中密集地处理信息，这使得长上下文的问题更加突出。RLM的优势在更复杂的任务上更加明显，因为它能够程序化地处理相关信息而不是被无关信息淹没。理解任务复杂度缩放有助于理解为什么RLM在不同任务上的表现差异如此巨大，以及为什么这是一个通用的解决方案而不是任务特定的方法。
研究动机
现有前沿推理模型（如GPT-5）的上下文窗口有限，即使在这些限制内，也存在严重的上下文退化问题。Figure 1清晰展示了GPT-5性能随着输入长度增加而急剧下降的现象，特别是在复杂任务上。例如，在S-NIAH（常数复杂度）任务上，GPT-5还能在较长输入下保持较好性能，但在OOLONG（线性复杂度）和OOLONG-Pairs（二次复杂度）任务上，性能下降非常迅速。当输入达到2的20次方tokens（约1M tokens）时，GPT-5在OOLONG-Pairs任务上几乎完全失败。现有的长上下文处理方法要么是任务特定的（如检索增强），要么使用有损的上下文压缩策略（如compaction），这会丢失密集任务所需的关键细节。当前的coding agents和检索agents虽然可以访问外部数据源，但仍然受到底层LLM上下文窗口的限制。论文观察到GPT-5在OOLONG任务上相比compaction方法中位数提升26%，相比CodeAct with sub-calls提升130%，相比Claude Code提升13%。
本文的目标是论文的目标是提出一个通用的推理范式，能够让大语言模型处理任意长度的提示，同时保持高质量的性能输出。具体来说，作者希望实现三个核心目标：一是突破模型上下文窗口的硬性限制，能够处理超过模型窗口一个数量级以上的输入；二是在较短输入下也能显著优于vanilla前沿模型和常见的长上下文脚手架；三是保持与基线方法相当或更低的推理成本。作者还探索了在较小规模上训练原生递归语言模型的可行性，证明了RLM可以通过简单的训练配方快速改进。RLM-Qwen3-8B在四个评估任务上中位数提升28.3%，甚至在三个长上下文任务上接近vanilla GPT-5的质量。论文还展示了RLM在长推理任务如LongCoT-mini上的能力，解决率从38.7%提升到65.6%，证明了RLM范式不仅适用于长上下文问题，也能帮助模型解决需要复杂推理的挑战性任务。
与已有工作不同的是，本文的独特切入角度是从推理时计算扩展的角度来解决长上下文问题，而不是通过改变模型架构或训练过程。受推理模型成功经验的启发，作者认为上下文应该被模型视为外部环境的一部分，而不是直接喂入神经网络。这与现有的方法形成鲜明对比：Compaction方法直接将提示放入上下文窗口然后压缩，当窗口满时进行有损压缩，丢失密集任务所需的细节；coding agents将提示作为文件处理但仍然有输出长度限制，因为输出是在模型上下文窗口中生成的；sub-agent delegation允许子调用但只能通过自然语言描述而非程序化生成，限制了子调用的数量和灵活性。RLM的核心创新是将提示作为REPL环境中的变量，允许LLM通过编程方式递归调用自身，从而实现无语义地平线限制的推理。这种设计让RLM能够执行线性的甚至二次的语义工作，通过在循环中递归调用来处理输入的所有相关部分。
核心方法
递归语言模型的核心思想是将任意长度的用户提示不直接喂入神经网络，而是作为外部环境的一部分，让语言模型能够符号化地与这个环境交互。整个系统对外表现为一个无上下文限制的抽象语言模型：接受任意结构的字符串提示并产生字符串响应。具体实现上，RLM初始化一个Python REPL环境，将用户提示设置为环境中的变量，然后让LLM在这个环境中编写代码来探索、分解和处理输入。LLM可以递归调用自身来处理提示的子片段，将中间结果存储为新的变量，最终通过设置一个Final变量来返回答案。这种方法的关键在于LLM不是在token空间中处理所有信息，而是在代码执行空间中通过编程方式进行推理。每次迭代只向M的上下文添加固定大小的元数据，强制M依赖变量和子调用来管理长字符串。这使得RLM能够在有限的上下文窗口内执行无限的语义工作。
RLM与现有方法有三个本质区别，这三个区别在Algorithm 1和Algorithm 2的对比中清晰展现。第一个关键设计是给底层LLM一个符号化句柄来访问用户提示P，这样模型可以操作提示而不必将文本复制到根上下文窗口中。相比之下，Algorithm 2直接将P放入上下文窗口hist，继承了M的窗口限制，当超出限制时只能回退到compaction等启发式方法。第二个关键设计是输出通过变量返回而不是直接生成，这使得输出可以超过上下文窗口的限制。Algorithm 2通过Finish动作直接生成输出，这意味着输出不能超过M的上下文窗口。第三个，也是最重要的设计是符号化递归，即环境中运行的代码可以以编程方式构造提示的变换来调用M，可以在任意大的循环中存储中间结果。Algorithm 2虽然有单独的代码执行动作和子LM动作，但不能程序化地调用子LLM，因而只能委托几个显式描述的任务而不是编写可以在循环中启动线性或二次进程的短程序。
方法步骤详情
RLM的工作流程可以描述为以下几个步骤。步骤1：初始化持久化REPL编程环境，创建一个包含用户提示P作为字符串的变量，以及一个用于调用子RLM的函数。步骤2：准备历史记录hist，只包含关于用户提示的元数据，如长度、短前缀以及如何访问其部分的信息，而不是提示本身。步骤3：进入RLM循环，使用底层神经模型M生成代码，这些代码帮助M理解、转换提示的各个部分，并将中间值和最终响应构建成新变量，可能通过在循环中调用子RLM。步骤4：在REPL中执行代码，更新REPL状态（中间变量），并从stdout收集任何打印的文本。只将stdout的元数据（如短前缀和长度）附加到M的历史记录中用于下一次迭代。步骤5：当RLM在REPL中设置Final变量时，迭代停止，将Final中的值作为响应返回。整个过程的关键在于每次迭代只向M的上下文添加固定大小的元数据，这强制M依赖变量和子调用来管理长字符串。原则上，如果每次迭代将历史截断为c个token，我们最多有K/c次根迭代，每次迭代可以启动任意多的子调用。
技术新颖性
RLM的技术新颖性体现在多个方面。首先，它提出了一种全新的视角来看待长上下文问题：不是通过扩展模型的物理上下文窗口，而是通过推理时架构设计来创造一个抽象的无限制界面。这种视角的转变让作者能够重新思考整个问题，将长上下文处理从硬件和训练限制中解放出来。其次，RLM是第一个真正实现符号化递归调用的通用框架，之前的工作要么只能在对话中显式地描述几个子任务，要么只能在单次生成中产生带有子调用的程序而无法从错误中恢复。RLM的持久化REPL环境允许模型通过执行反馈迭代改进其递归策略。第三，RLM通过简单的训练配方证明了可以快速训练原生递归语言模型，RLM-Qwen3-8B在1000个不相关域的样本上训练后，在四个评估任务上中位数性能提升28.3%，甚至在三个长上下文任务上接近vanilla GPT-5的质量。这表明RLM轨迹可以被视为一种推理形式，可以通过自举现有模型来训练。最后，论文的实验设计也很有创新性，特别是将任务按复杂度随输入长度的缩放行为进行分类，揭示了不同方法在不同任务类型上的性能差异的根本原因。
实验结果
论文的实验结果非常全面且令人印象深刻。首先，RLM能够成功处理超过模型上下文窗口限制一个数量级以上的输入。在BrowseComp-Plus任务上，输入长度为6M-11M tokens，远超GPT-5的272K token上下文窗口，但RLM(GPT-5, depth=1)达到了91.3%的准确率，显著优于compaction agent的70.5%。在OOLONG任务上，RLM(depth=1)使用GPT-5比基线模型提升27.3%，使用Qwen3-Coder提升33.3%。在最困难的OOLONG-Pairs任务上，基线F1分数都低于0.1%，而RLM(depth=1)分别达到58.0%和23.1%。训练的RLM-Qwen3-8B相比基础Qwen3-8B中位数提升28.3%。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| CodeQA | 准确率(%) | 62.0 | 24.0 (GPT-5 base) | 158%提升 |
| BrowseComp+ (1K) | 准确率(%) | 91.3 | 0.0 (GPT-5 base) | 从无法处理到91.3% |
| OOLONG | 准确率(%) | 56.0 | 44.0 (GPT-5 base) | 27.3%提升 |
| OOLONG-Pairs | F1分数(%) | 58.0 | 0.1 (GPT-5 base) | 580倍提升 |
| LongCoT-mini | 解决率(%) | 65.6 | 38.7 (GPT-5.2 base) | 69.5%提升 |
| OOLONG (训练模型) | 准确率提升(%) | 28.3中位数 | Qwen3-8B base | 训练后的显著改进 |
局限与改进
作者坦诚地讨论了几个主要局限性。首先，RLM在更困难和自然的长上下文处理任务上的评估仍然不足，最佳的实现保护机制也尚未充分探索。论文主要集中在四个特定的基准任务上，这些任务虽然覆盖了不同的复杂度类别，但可能不能完全代表真实世界中的长上下文任务。其次，RLM在现有LLM之上增加了一层复杂性，可能导致意想不到的副作用，如子调用成本的爆炸式增长。论文发现虽然RLM的中位数运行比中位数基线运行更便宜，但由于异常轨迹的平均运行更昂贵，这使得成本控制成为一个开放问题。第三，论文主要关注评估使用现有前沿模型的RLM，只在Qwen3-8B上展示了初步的训练证据。虽然训练显示了快速的性能改进，但更大规模的原生RLM训练仍需进一步研究。作者还指出，虽然代码可用，但完整的实现细节和更多实验结果在附录中，可能影响完全复现。从观察来看，RLM(Qwen3-Coder)的轨迹包含显著更多的语法错误，这解释了为什么更高递归深度对于Qwen3-Coder的RLM平均表现更差。这表明RLM的成功可能高度依赖于基础模型的代码生成能力，这对于较小的模型可能是一个挑战。
独立分析的弱点
论文存在几个可以改进的弱点。首先，RLM的性能差异在不同模型间很大。GPT-5作为RLM时表现优异，而Qwen3-Coder的RLM表现不如GPT-5，特别是在更高递归深度时。这可能是因为Qwen3-Coder更频繁地产生语法错误。改进方向可以是：针对RLM训练更好的代码纠错机制，或者在REPL中添加语法检查和自动修复功能。其次，成本控制仍然是一个开放问题。虽然RLM的中位数运行更便宜，但由于异常轨迹的平均运行更昂贵。改进方向可以是：添加预算限制机制，当成本接近阈值时切换到更简单的策略。
未来方向
作者提出了几个有前景的未来研究方向。首先，异步子调用和沙箱化REPL可以显著降低RLM的运行时和推理成本。当前的实现所有LM调用都是阻塞/顺序的，引入异步可以大幅减少等待时间，特别是在需要大量子调用的任务上。其次，训练原生RLM被证明是一个快速改进的新轴。作者假设RLM轨迹可以被视为一种推理形式，可以通过自举现有模型来训练。更系统的RLM训练研究可以带来更大的性能提升，包括在大规模模型上训练和探索更有效的训练目标。第三，更好的实现保护机制对于实际部署至关重要。这包括成本限制、安全约束、和错误处理机制。当前实现可能导致子调用成本的爆炸式增长，需要设计有效的预算管理和错误恢复策略。第四，探索更多RLM的应用场景，不仅限于长上下文和长推理任务。RLM的递归和符号化处理能力可能在其他领域也有价值，比如代码生成、数学证明、科学推理等。最后，理解RLM的行为模式有助于指导更好的训练。作者观察到RLM轨迹在不同域之间有共同行为，如探测输入和在较短上下文上递归子调用。更深入地理解这些模式可以帮助设计更有效的训练数据和训练目标。
复现评估
论文的复现性情况良好但仍有改进空间。代码在https://github.com/alexzhang13/rlm上可用。论文提供了详细的系统提示示例在附录C中，这对于复现非常重要。实验使用了标准基准如S-NIAH、BrowseComp-Plus、OOLONG等，这些数据集都是公开可用的。作者清楚地描述了评估设置，包括使用的模型和采样参数。成本计算也是透明的，基于OpenAI、Fireworks和Anthropic的公开定价。然而，一些细节可能在完整的论文或附录中，这可能影响完全复现。训练RLM-Qwen3-8B的细节在附录A中，但主要论文中只提到了使用1000个样本。使用的前沿模型可能不是所有研究者都能访问的，这限制了完全复现。
论文图表
这张图有两个子图。子图(a)研究了RLM对系统提示中in-context examples的敏感性。通过改变提供的decomposition examples，观察RLM在OOLONG上的性能和第一次分解尝试。数据显示in-context RLM轨迹显著提高整体性能和初始分解尝试，即使示例与实际任务无关。子图(b)报告了Table 1中RLM(depth=1)运行中，按正确或错误rollout分桶，包含至少一个语法错误的RLM轨迹的百分比。发现RLM(Qwen3-Coder)轨迹包含显著更多的语法错误，即使对于正确轨迹也是如此，这解释了为什么更高递归深度对于Qwen3-Coder表现更差。
这张图提供了对RLM行为的重要洞察。子图(a)展示了系统提示设计的重要性，提示了如何通过更好的prompting来改进RLM。子图(b)揭示了不同模型作为RLM时的差异，特别是代码生成能力对性能的影响。