递归语言模型

Recursive Language Models

递归语言模型

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

摘要：

本文从推理时扩展（inference-time scaling）视角研究如何使大语言模型（LLMs）处理任意长度的提示。我们提出递归语言模型（RLMs），一种通用推理策略：将长提示视为外部环境的一部分，使LLM能以程序化方式检视、分解提示片段并递归调用自身。实验表明，RLMs可成功处理超出模型上下文窗口两个数量级的输入；即便对于较短提示，在四项多样化长上下文任务中，其质量亦显著优于基础LLM及常见长上下文框架，且单次查询成本相当或更低。

引言

尽管推理与工具使用能力快速进步，现代语言模型的上下文长度仍受限，且即使在此限制内，亦不可避免地表现出“上下文腐化”（context rot）现象（Hong et al., 2025）——如图1左侧所示，即便是GPT-5等前沿模型，其性能亦随上下文增长而迅速下降。尽管我们预期通过训练、架构与基础设施的改进，上下文长度将持续提升，但我们关注的是：是否有可能将通用大语言模型的上下文规模提升数个数量级。这一问题日益紧迫，因LLM正被广泛应用于长周期任务，需常规处理数千万乃至数亿个token。

我们从扩展推理时计算（inference-time compute）的视角研究此问题。我们的灵感广泛来源于核外算法（out-of-core algorithms）：具备小而快主存的数据处理系统，可通过巧妙管理数据载入内存的方式处理远超内存容量的数据集。针对本质上属于长上下文问题的推理时方法已十分常见，但通常局限于特定任务。该领域中一种通用且日益流行的方法是上下文压缩（context condensation/compaction）（Khattab et al., 2021; Smith, 2025; OpenAI, 2025; Wu et al., 2025），即当上下文超过长度阈值时对其进行重复摘要。遗憾的是，对于需要密集访问提示多处细节的任务，压缩方法的表达能力往往不足，因其本质上预设了提示早期出现的某些细节可被安全遗忘，以为新内容腾出空间。

我们提出递归语言模型（Recursive Language Models, RLMs），一种通用推理范式，可显著扩展现代LLM的有效输入与输出长度。其核心洞见在于：长提示不应直接输入神经网络（如Transformer），而应被视为LLM可通过符号方式交互的外部环境的一部分。

如图2所示，RLM对外暴露与LLM相同的接口：接受任意结构的字符串提示并生成字符串响应。给定提示 P P，RLM初始化一个读取-求值-打印循环（REPL）编程环境，其中 P P被设为某变量的值。随后，RLM向LLM提供关于REPL环境的通用上下文信息（如字符串 P P的长度），并允许其编写代码以窥探、分解 P P，并迭代观察执行产生的副作用。关键在于，RLM鼓励LLM在其生成的代码中以程序化方式构建子任务，并可对这些子任务递归调用自身。

通过将提示视为外部环境中的对象，RLM这一简洁设计克服了众多先前方法（Anthropic, 2025; Sentient, 2025; Schroeder et al., 2025; Sun et al., 2025）的根本局限——这些方法虽聚焦于任务的递归分解，却无法使其输入规模突破底层LLM的上下文窗口限制。

我们使用前沿闭源模型（GPT-5; OpenAI 2025）与前沿开源模型（Qwen3-Coder-480B-A35B; Team 2025），在四项复杂度各异的多样化任务上评估RLM：深度研究（Chen et al., 2025）、信息聚合（Bertsch et al., 2025）、代码仓库理解（Bai et al., 2025），以及一项连前沿模型亦会灾难性失败的合成成对推理任务。我们将RLM与直接调用LLM、上下文压缩、检索工具调用智能体及代码生成智能体进行比较。结果表明，RLM即使在1000万+ token规模下仍表现出极强性能，在长上下文处理任务中显著优于所有其他方法，多数情况下性能提升达两位数百分比，同时保持相当或更低的成本。特别如图1所示，RLM在更长上下文与更复杂任务中表现出远为轻微的性能退化。

2 长上下文任务的扩展

近期研究（Hsieh et al., 2024; Goldman et al., 2025; Hong et al., 2025）已成功论证：LLM的有效上下文窗口通常远小于模型物理上支持的最大token数量。进一步地，我们假设LLM的有效上下文窗口无法脱离具体任务而独立理解。换言之，更“复杂”的问题将在更短的长度上即出现性能退化。因此，我们必须依据任务复杂度如何随提示长度缩放来刻画任务特性。

例如，"大海捞针"（needle-in-a-haystack, NIAH）问题在扩展提示长度时通常保持"针"的内容不变。因此，尽管早期模型在NIAH任务上表现挣扎，前沿模型在RULER（Hsieh et al., 2024）中即使面对100万+ token的设置亦能可靠解决此类任务。然而，同一模型在OOLONG（Bertsch et al., 2025）任务上即便面对更短上下文亦表现困难——该任务的答案明确依赖于提示中几乎每一行内容。

2.1 任务

基于此直觉，我们在经验评估中设计了若干任务，不仅能够变化提示长度，亦可考察问题复杂度的不同缩放模式。我们粗略地以信息密度（即智能体为回答任务所需处理的信息量，及其如何随输入规模缩放）来刻画每项任务。

S-NIAH。沿用RULER（Hsieh et al., 2024）中的单针大海捞针任务，我们考虑一组50个单针任务，要求在大量无关文本中查找特定短语或数字。此类任务无论输入规模如何均只需查找单一答案，因此其处理成本相对于输入长度近似恒定缩放。

BrowseComp-Plus（1K文档）（Chen et al., 2025）。面向DeepResearch（OpenAI, 2025）问题的多跳问答基准，要求对多个不同文档进行推理。该基准提供一个经验证的离线语料库（含10万文档），保证每个任务均包含黄金答案文档、证据文档与困难负例文档。参照Sun et al. (2025)，我们使用150个随机采样任务作为评估集；向模型或智能体提供1000个随机选择的文档，其中保证包含黄金答案与证据文档。我们报告正确答案的百分比。每项任务需拼接来自多个文档的信息，因此尽管同样只需恒定数量的文档作答，其复杂度仍高于S-NIAH。

OOLONG（Bertsch et al., 2025）。一项长推理基准任务，要求对输入的语义块进行检视与变换，再聚合这些块以形成最终答案。我们采用原论文的评分方式：数值答案评分为，其他答案采用精确匹配。我们特别聚焦于trec coarse划分，该划分包含50个任务，基于带有语义标签的问题数据集。每项任务需使用数据集中近乎全部条目，因此其处理成本相对于输入长度呈线性缩放。

OOLONG-Pairs。我们手动修改OOLONG的trec coarse划分，加入20个新查询，这些查询明确要求聚合成对的语义块以构建最终答案。附录E.1中明确列出了该基准的所有查询。我们报告答案的F1分数。每项任务需使用数据集中近乎全部条目对，因此其处理成本相对于输入长度呈二次方缩放。

LongBench-v2 CodeQA（Bai et al., 2025）。LongBench-v2中面向代码仓库理解的多选题划分，对现代前沿模型颇具挑战性。我们以正确答案百分比作为评分。每项任务需对代码库中固定数量的文件进行推理以找出正确答案。

2.2 方法与基线

我们将RLM与其它常用的任务无关方法进行比较。针对以下每种方法，我们使用两个当代语言模型：具备中等推理能力的GPT-5（OpenAI, 2025），采用默认采样参数；以及Qwen3-Coder-480B-A35B（Yang et al., 2025），采用Team (2025)所述的采样参数。二者分别代表商业与开源前沿模型。除在所有任务上评估基础模型外，我们还评估以下方法与基线：

带REPL的RLM。我们实现了一种RLM，将其上下文作为字符串加载至Python REPL环境的内存中。该REPL环境同时加载一个模块，使其能够在环境中查询子语言模型。系统提示词在所有实验中保持固定（见附录D）。在GPT-5实验中，我们对递归调用使用GPT-5-mini，对根调用使用GPT-5，因该选择在RLM能力与递归调用成本之间取得了良好权衡。

带REPL但无子调用的RLM。我们提供本方法的消融实验：REPL环境虽加载了上下文，但无法使用子语言模型调用。在此设定下，语言模型仍可在REPL环境中与其上下文交互，之后再提供最终答案。

摘要智能体。参照Sun et al. (2025)、Wu et al. (2025)与Yu et al. (2025)，我们考虑一种迭代式智能体，当上下文被填满时即对其进行摘要。例如，给定文档语料库，该智能体会迭代浏览文档并在填满时进行摘要。当提供上下文超出模型窗口时，智能体会将输入分块以适配模型上下文窗口，并在这些分块上应用相同策略。对于GPT-5，鉴于处理大token输入的极高成本，我们使用GPT-5-nano进行压缩，使用GPT-5提供最终答案。

CodeAct（+ BM25）。我们直接与CodeAct（Wang et al., 2024）智能体进行比较，该智能体可在ReAct（Yao et al., 2023）循环内执行代码。与RLM不同，它不将提示卸载至代码环境，而是直接提供给语言模型。此外，参照Jimenez et al. (2024)与Chen et al. (2025)，我们为该智能体配备BM25（Robertson & Zaragoza, 2009）检索器，对适用任务将其输入上下文建立索引。

3 结果与讨论

我们在表1中聚焦于§2.1所述的基准测试开展主要实验。此外，我们在图1中探究了前沿模型与RLM的性能如何随输入上下文增长而退化。

观察1：RLM可扩展至1000万+ token规模，且在长上下文任务上优于基础语言模型及现有任务无关的智能体框架。在所有任务中，RLM在远超前沿语言模型有效上下文窗口的输入任务上均展现出强劲性能，相较基础模型与常见长上下文框架，性能提升最高达2倍，同时保持相当或更低的平均token成本。值得注意的是，RLM的成本可良好扩展至基础模型上下文窗口的理论扩展成本——在BrowseComp-Plus（1K）任务上，GPT-5-mini处理600–1100万输入token的成本为1.50–2.75美元，而RLM(GPT-5)的平均成本仅为0.99美元，且性能较摘要与检索基线分别提升逾29%。

此外，在处理成本随输入上下文缩放的任务上，即便任务完全适配模型上下文窗口，RLM相较基础模型仍取得显著改进。在OOLONG任务上，采用GPT-5与Qwen3-Coder的RLM分别较基础模型提升28.4%与33.3%。在OOLONG-Pairs任务上，GPT-5与Qwen3-Coder基础模型几乎无进展（F1分数<0.1%），而采用这些模型的RLM则分别达到58.00%与23.11%的F1分数，凸显RLM处理极高信息密度任务的涌现能力。

观察2：REPL环境对处理长输入必不可少，而RLM的递归子调用在信息密集型输入上带来显著增益。RLM的关键特征是将上下文作为变量卸载至模型可交互的环境 E E中。即便不具备子调用能力，我们的RLM消融实验仍能突破模型上下文限制，在多数长上下文场景下优于基础模型及其他任务无关基线。在Qwen3-Coder的CodeQA与BrowseComp+任务上，该消融版本甚至分别较完整RLM提升17.9%与3%。

在OOLONG或OOLONG-Pairs等信息密集型任务上，我们观察到若干递归语言模型子调用必不可少的情形。在§3.1中可见，RLM(Qwen3-Coder)通过递归子调用逐行执行必要的语义变换，而无子调用的消融版本则被迫依赖关键词启发式方法求解此类任务。在所有信息密集型任务上，RLM相较无子调用的消融版本性能提升10%–59%。

观察3：语言模型性能随输入长度与问题复杂度增加而退化，而RLM性能缩放表现更优。基准测试S-NIAH、OOLONG与OOLONG-Pairs在长度范围为的上下文中包含固定数量的任务。此外，每项基准可依据输入上下文相对于长度的处理成本（分别近似为常数、线性与二次方）进行粗略分类。在图1中，我们直接比较了使用GPT-5的RLM与基础GPT-5在各项任务上的表现——我们发现，对于更复杂的任务，GPT-5性能退化显著更快，而RLM性能虽亦退化，但速率慢得多，这与Goldman et al. (2025)的发现一致。当上下文长度超过时，RLM持续优于GPT-5。

此外，RLM成本与任务复杂度成比例缩放，但仍保持与GPT-5同数量级（见附录C中图9）。在§3.1中，我们探讨了RLM在此类设置中所做的选择如何导致成本差异。最后，在此设置下，我们亦观察到基础语言模型在小规模输入上下文场景中优于RLM。从构造上看，RLM的表征能力严格强于语言模型：选择调用根语言模型的环境等价于基础语言模型；然而实践中我们观察到，RLM在较小输入长度下性能略逊，表明在何时使用基础语言模型与何时使用RLM之间存在权衡点。

观察4：RLM的推理成本与基础模型调用相当，但因轨迹长度差异而呈现高方差。RLM迭代式地与其上下文交互直至找到合适答案，导致迭代长度因任务复杂度不同而产生巨大差异。在图3中，我们绘制了表1中除BrowseComp-Plus（1K）外所有实验中各方法的成本四分位数（因基础模型无法将任何此类任务纳入上下文）。对于GPT-5，RLM运行的中位成本低于基础模型运行的中位成本，但许多RLM运行的异常值显著高于任何基础模型查询。然而，相较于需摄入全部输入上下文的摘要基线，RLM因能够选择性查看上下文，在所有任务上成本最高可降低3倍，同时保持更强性能。

我们还在附录C的图5、6中报告了各方法的运行时间，但需注意若干重要限制。与API成本不同，这些数值高度依赖于实现细节，如所用机器、API请求延迟及语言模型调用的异步性。在我们的基线与RLM实现中，所有语言模型调用均为阻塞式/串行执行。尽管如此，与成本类似，我们仍观察到运行时间范围广泛，尤其对于RLM。

观察5：RLM是一种模型无关的推理策略，但不同模型在上下文管理与子调用方面表现出不同的整体决策。尽管GPT-5与Qwen3-Coder-480B作为RLM均相对其基础模型及其他基线展现出强劲性能，但二者在所有任务上亦表现出不同的性能与行为。尤其在BrowseComp-Plus任务上，RLM(GPT-5)几乎解决了所有任务，而RLM(Qwen3-Coder)仅能解决约半数任务。我们注意到，RLM系统提示词在各模型的所有实验中保持固定，且未针对任何特定基准进行调优。GPT-5与Qwen3-Coder之间提示词的唯一差异在于：RLM(Qwen3-Coder)的提示词中额外增加了一行警告，提示避免过多使用子调用（见附录D）。我们在示例B.3中明确展示了这一差异：RLM(Qwen3-Coder)在OOLONG任务中对每行执行语义变换时均作为独立的子语言模型调用，而GPT-5则对子查询语言模型持保守态度。

3.1 RLM轨迹中的涌现模式

即便未经显式训练，RLM亦展现出有趣的上下文管理与问题分解行为。我们选取若干RLM轨迹片段示例，以理解其如何解决长上下文问题及可改进之处。此处讨论若干有趣行为的典型示例，更多示例见附录B。

基于模型先验、利用代码执行过滤输入信息。RLM抽象之所以能在处理超大输入时维持强劲性能而不导致成本爆炸，其关键直觉在于：语言模型无需显式查看即可过滤输入上下文。此外，模型先验使RLM能够缩小搜索空间，从而处理更少的输入token。例如，如图4a所示，我们观察到RLM(GPT-5)使用正则表达式查询，在原始提示中搜索包含关键词（如" festival"）及模型具备先验知识的短语（如"La Union"）的语义块。在多数轨迹中，我们观察到的一种常见策略是：先向根语言模型打印回显若干行以探查上下文，再基于观察结果进行过滤。

分块与递归子调用语言模型。RLM将本质上无界长度的推理链推迟至子（R）LM调用中执行。分解方式的选择会极大影响任务性能，尤其对于信息密集型问题。在我们的实验中，除均匀分块或关键词搜索外，未观察到更复杂的划分策略。如图4b所示，RLM(Qwen3-Coder)在OOLONG任务中对包含1000余行的上下文按换行符进行分块。

通过小上下文的子LM调用进行答案验证。我们观察到RLM通过子LM调用进行答案验证的若干实例。其中部分策略隐式地通过子LM执行验证以规避上下文腐化（见示例B.1），另一些则单纯利用代码执行以程序化方式验证答案正确性。然而在某些情况下，答案验证是冗余的，会显著增加单任务成本——在示例B.3中，我们观察到OOLONG任务上的一条轨迹：模型在最终选择错误答案前，曾五次以上尝试复现其正确答案。

通过变量传递递归LM输出以处理长输出任务。RLM能够通过将REPL中的变量作为输出返回，生成远超基础语言模型限制的、本质上无界的token。借助REPL环境，RLM可迭代地构建这些变量，将其作为程序化操作与子（R）LM输出调用的混合结果。我们在OOLONG-Pairs任务的轨迹中大量观察到该策略：RLM将针对输入的子LM调用输出存储于变量中，再将其拼接形成最终答案（见图4c）。

4 相关工作

长上下文语言模型系统。语言模型系统中的长上下文管理主要沿两个正交方向发展：1）直接修改基础语言模型的架构并重新训练以处理更长上下文（Press et al., 2022; Gu et al., 2022; Munkhdalai et al., 2024）；2）在语言模型周围构建脚手架以隐式处理上下文——RLM聚焦于后者。此类策略中广受欢迎的一类是有损上下文管理，即通过摘要或截断压缩输入上下文，代价是可能丢失细粒度信息。例如，MemWalker（Chen et al., 2023）为输入构建树状数据结构，供语言模型在回答长上下文问题时导航；ReSum（Wu et al., 2025）则为多轮智能体周期性压缩上下文而添加摘要工具。另一类策略在智能体脚手架中实现显式记忆层次结构（Packer et al., 2024; Chhikara et al., 2025; Zhang et al., 2025）。RLM与先前工作的不同之处在于：所有上下文窗口管理均由语言模型自身隐式处理。

通过子LM调用进行任务分解。许多基于语言模型的智能体（Guo et al., 2024; Anthropic, 2025）利用多次精心安排的语言模型调用来解决问题，但其中许多调用基于人工设计的工作流。ViperGPT（Surís et al., 2023）、THREAD（Schroeder et al., 2025）、DisCIPL（Grand et al., 2025）、ReDel（Zhu et al., 2024）、Context Folding（Sun et al., 2025）与AgentFold（Ye et al., 2025）等若干方法已探索将子LM调用的选择权交予语言模型本身。这些技术强调通过递归语言模型调用进行任务分解，但无法处理超出基础语言模型长度限制的长上下文输入。相比之下，RLM得益于一个极为简洁的直觉（即将提示视为外部环境的一部分），从而能够符号化操作任意长度的字符串，并通过持久化REPL环境的执行反馈迭代优化其递归过程。

5 局限性与未来工作

尽管RLM在合理推理成本下对超出现有语言模型上下文窗口限制的任务展现出强劲性能，其实现RLM的最优机制仍有待探索。我们聚焦于Python REPL环境内的同步子调用，但需指出：涉及异步子调用与沙箱化REPL的替代策略有望显著降低RLM的运行时间与推理成本。此外，我们选择最大递归深度为1（即子调用为语言模型）；尽管在现有长上下文基准测试中取得了强劲性能，我们认为未来工作应探究更深层次的递归。最后，我们的实验聚焦于使用现有前沿模型评估RLM。显式训练专用于RLM的模型（如作为根模型或子模型）或可带来额外性能提升——正如§3.1中所发现，当前模型在上下文决策方面效率低下。我们假设RLM轨迹可视为一种推理形式（OpenAI et al., 2024; DeepSeek-AI et al., 2025），可通过引导现有前沿模型进行训练（Zelikman et al., 2022; 2024）。

6 结论

我们提出了递归语言模型（Recursive Language Models, RLMs），一种通用的语言模型推理框架：该框架将输入上下文卸载至外部环境，并使语言模型能够在输出前递归地子查询其他语言模型。我们探索了该框架的一种具体实现：将上下文作为内存中的变量卸载至Python REPL环境，使语言模型能够通过代码与递归语言模型调用对其上下文进行推理，而非仅在token空间中操作。我们在多种设置与模型上的实验结果表明，RLM是一种有效的任务无关范式，既适用于长上下文问题，亦适用于一般性推理任务。我们期待未来工作能显式训练模型以RLM方式推理，这或将成为下一代语言模型系统的又一扩展维度。

原文链接：https://arxiv.org/pdf/2512.24601v1