Recursive Language Models
递归语言模型 - 让模型决定如何处理海量上下文
RLM提出了一种革命性的推理策略：让语言模型递归地调用自己来处理几乎无限长度的上下文。 RLM(GPT-5-mini)的表现超越了GPT-5本身， 在最困难的长上下文基准测试中，正确答案数量是后者的两倍多， 同时成本更低，且即使处理10M+ tokens也不会性能退化。
2×+
性能提升倍数
更低
查询成本
10M+
tokens无退化
无限
上下文长度
%20call.png)
递归语言模型调用示例 - 展示RLM如何递归处理长上下文
🔍 问题背景
什么是"Context Rot"（上下文腐烂）？
Anthropic将"context rot"定义为：随着上下文窗口中的token数量增加，
模型从上下文中准确召回信息的能力会下降。但有趣的是，在RULER等"大海捞针"基准测试中，
大多数前沿模型表现出色（90%+准确率），但在实际使用中（如长时间对话），模型似乎会"变笨"。
这是一个人人都知道但难以精确描述和基准测试的失效模式。
直觉的解决方案
"如果我把上下文分成两个模型调用，然后在第三个调用中合并它们，是不是就能避免这种退化问题？"
RLM正是基于这个直觉构建的。 通过递归分解上下文处理任务，让每个单独的模型调用都不需要处理巨大的上下文。
RLM正是基于这个直觉构建的。 通过递归分解上下文处理任务，让每个单独的模型调用都不需要处理巨大的上下文。
💡 核心概念
API层面的抽象
RLM是对语言模型的一层轻量封装，可以生成（递归的）中间计算调用。
从用户或程序员的角度来看，它与普通模型调用完全一样：
使用方式完全相同，但内部会智能地进行递归处理。
rlm.completion(messages) 替代 gpt5.completion(messages)
使用方式完全相同，但内部会智能地进行递归处理。
以上下文为中心的视角
RLM采用以上下文为中心而非以问题为中心的输入分解方式：
- 只将查询(query)提供给根LM（深度=0的LM）
- 将上下文(context)存储在环境(environment)中
- 根LM可以与环境交互，递归地调用子LM
递归语言模型调用替代传统语言模型调用 - API层面的对比
REPL环境：让LM与上下文互动
RLM选择了Python REPL Notebook作为环境（类似Jupyter Notebook）：
- 上下文作为变量：巨大的上下文被预加载为Python变量存储在内存中
- 灵活交互：根LM可以在REPL中编写和读取代码单元格的输出
- 递归调用：根LM可以像调用函数一样调用递归LM，对上下文进行查看、分区、grep搜索和启动子查询
REPL环境中的递归语言模型 - 展示RLM如何与环境交互
1
交互
根LM输出代码块，接收执行结果（截断版本）。
可以读取变量、执行计算、使用正则表达式搜索等。
2
递归
根LM可以对存储在变量中的任何字符串启动递归LM调用（深度=1）。
子LM可以进一步递归调用更深层的LM。
3
输出答案
直接输出：
或使用环境变量：
FINAL(answer)
或使用环境变量：
FINAL_VAR(final_ans_var)
🚀 三大核心优势
1. 根LM的上下文窗口很少阻塞
因为它从不直接看到整个上下文，输入上下文增长缓慢。
传统方法：整个上下文 → 模型
RLM方法：查询 → 模型 ← 按需访问上下文片段
传统方法：整个上下文 → 模型
RLM方法：查询 → 模型 ← 按需访问上下文片段
2. 灵活的上下文访问策略
根LM可以：
- 查看上下文的子集
- 对上下文块进行朴素递归
- 使用
regex粗略缩小上下文范围 - 对缩小后的上下文启动递归LM调用
3. 多模态潜力
理论上，上下文可以是任何能加载到内存中的模态。
根LM拥有完全控制权来查看和转换数据，并对其提出子查询。
这为处理图像、音频、视频等多模态数据提供了可能。
与测试时推理扩展的关系
RLM提供了另一个扩展测试时计算的维度：
- LM选择与上下文交互和递归的轨迹是完全可学习的
- 可以像当前训练推理能力一样进行强化学习
- 不需要直接训练处理巨大上下文的模型——因为任何单个LM调用都不需要处理巨大上下文
📊 实验结果
OOLONG基准测试：翻倍的性能提升
在最困难的长上下文基准测试OOLONG上：
使用更小、更便宜的模型，获得更好的结果！
| 模型 | 正确答案数 | 成本/查询 |
|---|---|---|
| GPT-5 | 基准 | 更高 |
| RLM(GPT-5-mini) | 2倍+ | 更低 |
BrowseComp-Plus深度研究任务
在这个新构建的长上下文深度研究任务上，RLM表现优于：
- ReAct + 测试时索引
- 提示检索方法
无退化特性
惊人发现：RLM在处理10M+ tokens时性能不会退化
这验证了核心假设：通过将上下文管理委托给模型本身，可以规避传统长上下文的退化问题。
这验证了核心假设：通过将上下文管理委托给模型本身，可以规避传统长上下文的退化问题。
🎯 实际应用模式
1
自适应分区和递归
场景：在大量文档中查找多跳事实
RLM的做法：
RLM的做法：
- 使用regex粗略定位相关区域
- 对这些区域启动递归LM调用
- 合并结果，得出最终答案
2
一次性处理编程任务
场景：给定论文列表，生成所有BibTeX引用
传统LM的问题：输出太长容易出错，类似大型乘法问题，容易计算失误
RLM的解决方案：在REPL环境中编程处理，一次性正确完成任务，避免人工逐个处理的痛苦
传统LM的问题：输出太长容易出错，类似大型乘法问题，容易计算失误
RLM的解决方案：在REPL环境中编程处理，一次性正确完成任务，避免人工逐个处理的痛苦
3
LoCoDiff基准测试
任务：跟踪长达75k+ tokens的git diff历史，输出最终文件状态
GPT-5性能：<10%成功率
RLM(GPT-5)表现：选择编程方式逐步处理diff序列，显著提高成功率， 展示了将"应该是编程任务"的问题交给代码环境的威力
GPT-5性能：<10%成功率
RLM(GPT-5)表现：选择编程方式逐步处理diff序列，显著提高成功率， 展示了将"应该是编程任务"的问题交给代码环境的威力
⚙️ 技术细节
为什么选择REPL环境？
1. 提示作为Python变量
2. REPL环境中的递归LM调用
- 可以通过编程方式在任意REPL流程中处理
- LLM在测试时决定查看长上下文的哪些部分
- 可以扩展任何决策（如自适应分块和递归方案）
2. REPL环境中的递归LM调用
- 由选择(1)的分解和多功能性促成
- 允许灵活的子查询策略
- 受CodeAct设计启发，增强递归能力
RLMs vs. 其他方法
不同于Agent：
不同于简单总结：
- Agent：基于人类/专家直觉分解问题，使其适合LM处理
- RLMs：让LM自己决定如何分解问题
不同于简单总结：
- 总结方法：固定的上下文压缩策略
- RLMs：动态、自适应的上下文管理，由模型决定
⚠️ 当前局限性
速度优化不足
实现未针对速度优化：
- 每个递归LM调用都是阻塞的
- 不利用任何前缀缓存
- 查询时间：几秒到几分钟不等
成本和运行时保证
- 无法严格控制最大迭代次数带来的"思考时间"
- 对总API成本没有强保证
- 对总运行时间没有强保证
优化空间巨大
好消息：有大量低垂果实等待优化！
- 异步调用
- 前缀缓存
- 硬件感知优化
- 需要重新思考推理引擎设计
🔮 未来展望
训练专用RLM
RLM的训练潜力巨大：
- 固定格式的价值：CoT、ReAct、指令微调都表明，预测格式能显著提升性能
- 可学习的递归轨迹：如何与上下文交互、何时递归、如何分块——都可以学习
- 强化学习：效率、速度、性能都可以作为标量奖励优化
不需要解决Context Rot
核心洞察：RLM框架允许我们绕过而非解决context rot问题
- Context rot可能是训练分布不足导致的（长序列稀缺、高熵）
- RLM让任何单个LM调用都无需处理巨大上下文
- 随着基础模型能力提升，RLM能力同步提升
下一个里程碑
作者认为RLM可能代表通用推理时扩展的下一个里程碑：
- ✅ CoT风格推理模型
- ✅ ReAct风格Agent模型
- 🚀 显式训练递归推理的RLM
根本性赌注
"RLMs are a fundamentally different bet than modern agents. Agents are designed based on human / expert intuition on how to break down a problem to be digestible for an LM. RLMs are designed based on the principle that fundamentally, LMs should decide how to break down a problem to be digestible for an LM."
Agent：人类决定如何分解问题
RLM：语言模型决定如何分解问题
💎 核心思想总结
五大核心要点
- 上下文作为变量：将海量上下文存储在环境中，而非直接塞给模型
- 递归分解：让模型自己决定如何查看、分割和递归处理上下文
- REPL赋能：代码环境提供了灵活性和精确性
- 性能悖论：更小的模型+RLM框架 > 更大的模型
- 可扩展性：随着基础模型提升，RLM能力同步提升
