继2025推理模型之后，2026「递归模型」RLM要火了。

2025年的最后一天， MIT CSAIL提交了一份具有分量的工作。当整个业界都在疯狂卷模型上下文窗口（Context Window），试图将窗口拉长到100万甚至1000万token时，这篇论文却冷静地指出了一个被忽视的真相：这就好比试图通过背诵整本百科全书来回答一个复杂问题，既昂贵又低效。

他们正式提出了递归语言模型（Recursive Language Models, RLM）。聚焦于如何在不重新训练模型的情况下，让现有的模型处理比其物理上下文窗口大几个数量级的信息？在此之前，业界解决长文本主要靠“硬抗”（做大显存、优化 Attention 算法，如Ring Attention）。RLM告诉大家：方向错了。对于超长、超复杂的任务，不要试图把所有东西塞进短期记忆（Context Window），而应该像人类一样，利用外部工具（Python 变量）和笔记，分而治之。

这或将成为2026年最热的方向，因为它太诱人了，这是一种与模型无关 (Model-Agnostic) 的方法。任何公司只要有现成的LLM，套上RLM的壳，就能立刻拥有处理1000万+token的能力。

新年第一个工作日，修猫将为您解读这篇论文。用最直观的逻辑带您理解：为什么RLM可能是2026年大模型应用架构的关键转折点。

当下的核心痛点：光有“大窗口”是不够的

首先，我们需要达成一个共识：物理上的上下文窗口变大，并不等于模型的有效推理能力变强。

“上下文腐烂”现象

尽管现在的模型（如GPT-5）已经支持极长的上下文，但研究者指出，模型依然面临 “上下文腐烂”（Context Rot） 的问题。这就好比虽然能把整本书的内容塞进脑子里，但当书太厚时，开始记不住中间的细节，甚至产生幻觉。

任务复杂度的三个层级

这篇论文最精彩的洞察之一，是根据计算复杂度将长文本任务分为了三类。您会发现，传统的长上下文模型在面对高复杂度任务时，几乎是束手无策的：

• O(1)复杂度任务：大海捞针（S-NIAH）
• 任务描述：在海量文本中找到一个特定的短语或数字。
• 现状：这是目前大多数长文本模型擅长的。因为无论文本多长，答案只有一个，且不需要复杂的逻辑跳跃。目前的GPT-5在这类任务上表现很稳。
• O(N)复杂度任务：线性聚合（OOLONG）
• 任务描述：需要查看文档中的几乎每一行，并对信息进行转换和汇总。
• 现状：基座模型开始吃力。随着文本长度增加，性能会显著下降。
• O(N^2)复杂度任务：两两比较（OOLONG-Pairs）
• 任务描述：这是真正的“模型杀手”。例如，给定一个巨大的用户列表，找出其中所有满足特定条件的“用户对”。这需要将条目A与条目B、C、D... 逐一比较。
• 现状：即便是最先进的GPT-5，在这个任务上面对长文本时，得分也接近 0%。为什么？因为Transformer的注意力机制难以在一次推理中处理这种平方级的计算密度。

理论根基：从“核外算法”汲取灵感

RLM的设计哲学并非凭空产生，而是直接借鉴了计算机科学中经典的Out-of-core Algorithms（核外算法） 思想。

映射关系：LLM的存储层级

在传统的计算系统中，当数据集规模远超主存（RAM）容量时，我们不能一次性加载所有数据，而是需要设计算法，策略性地将磁盘（Disk）上的数据分块调入内存处理。

RLM将这一概念映射到了大模型推理中：

• 主存（Main Memory）  LLM的上下文窗口（Context Window）：虽然物理窗口在增大，但其“有效注意力”是有限且昂贵的。
• 外部存储（External Storage）  Prompt字符串变量：长文本不再是直接输入神经网络的张量，而是作为Python环境中的一个字符串对象（String Object）存在。

范式转移

传统的Long-Context LLM试图通过线性偏置或Ring Attention等技术“扩容内存”。而RLM则是承认内存（注意力窗口）的局限性，转而通过符号化操作（Symbolic Interaction）来管理数据搬运。模型不再是被动接收所有token，而是作为CPU，主动决定何时从“磁盘”（变量）中读取哪些数据块进入“内存”（子模型上下文）。

核心架构：基于REPL的递归环境实现

RLM的技术核心在于它构建了一个Read-Eval-Print Loop (REPL)环境，将自然语言推理转化为代码执行过程。将提示词视为环境的一部分。这就好比不再要求模型“背诵”整本书，而是让模型坐在书桌前，书桌上有一台装了Python环境的电脑。

初始状态与环境注入

关键接口：llm_query()

• 功能：当模型执行这行代码时，系统会挂起当前执行流，实例化一个新的LLM调用（Sub-LM）。
• 参数：子模型的输入是主模型构造的字符串（通常是 context 的切片加上特定的查询指令）。
• 递归深度：理论上支持无限递归。在论文的实验设置中，为了控制开销，研究者主要探索了深度为1的递归（即Root LM调用Sub-LMs，Sub-LMs此时作为标准LLM响应）。

状态持久化与Side Effects

RLM的推理过程本质上是一个状态机。

• 变量驻留：模型在Step t 计算出的中间结果（例如 summary_list = [...]），会作为Python变量驻留在内存中。
• Print观察：模型通过 print() 函数将中间结果输出到标准输出流，RLM架构截获这些输出并将其回传给模型，形成“观察（Observation）”反馈。
• 最终输出：系统强制要求模型使用 FINAL() 或 FINAL_VAR() 标签来封装最终答案，以此区分“思考过程”和“最终结论”。

实验结果

研究者使用了两个前沿模型进行测试：闭源的GPT-5和开源的Qwen3-Coder-480B。在高难度任务上，RLM获得了非常出色的表现。

质变的性能跃升

• 基座GPT-5：面对131k到262k的长度，它的F1分数接近0%。它完全迷失在海量信息的两两比对中。
• RLM (GPT-5)：在同样的设置下，分数飙升到了58.00%。这不仅仅是提升，而是从“不可用”到“可用”的质变。
• Qwen3-Coder：同样，基座模型几乎无法处理，而RLM版本的得分达到了23.11%。

成本分析：并不一定更贵

您可能会担心：递归调用这么多次，成本会不会爆炸？

研究者的发现很有趣：

• 中位数成本更低：对于很多任务，因为RLM懂得“跳读”和“过滤”，它实际处理的Token数反而比把全文塞进上下文窗口要少。例如在BrowseComp-Plus任务中，RLM(GPT-5) 的平均成本是是$0.99，而全量阅读的理论成本可能要$2.75。

为什么RLM能解决算法复杂度问题？

论文中对任务复杂度的形式化分析是理解RLM优势的关键。研究者提出，有效上下文窗口不能脱离任务复杂度独立讨论。

任务特征：需要对文本中的每一个块进行语义转换并聚合。

RLM解法：通过Python的 for 循环遍历切片。

这里，虽然总计算量仍是线性的，但单次LLM调用的上下文长度被压缩到了常数级，规避了长窗口下的注意力衰减。

涌现的系统行为

让研究者感到兴奋的，不是分数的提升，而是模型在没有经过任何微调（Fine-tuning）的情况下，仅通过Prompt Engineering（详见论文附录D）和环境交互，RLM就涌现出了类似高级工程师的调试行为。

基于先验的正则表达式过滤 (Prior-based Regex Filtering)

在GPT-5的RLM轨迹中，观察到模型会利用“正则探针”来优化I/O。

• 模型不直接读取10M tokens。
• 它基于对任务的理解（Model Priors），生成关键词列表（如 keywords = ["festival", "pageant"]）。
• 利用 re.search 扫描 context 变量，仅提取命中位置前后的窗口（Window）文本。
• 技术意义：这实现了非参数化的、基于语义规则的Attention机制，大幅降低了推理成本。

跨越上下文限制的变量传递

传统的RAG（检索增强生成）往往只能检索片段，容易丢失全局信息。而RLM通过Python变量，实现了动态分块与递归 (Dynamic Chunking)，做到了信息的“无损传递”。它可以把前10万字总结成一个变量，传给处理后10万字的步骤，从而实现了真正的全文档理解。

• 在处理日志文件时，RLM会自动识别 \n 为分隔符。
• 在处理长文档时，它会先读取目录或标题，按章节进行分块，并构建递归调用栈。

对于长输出任务（Long Generation），标准模型的最大输出token数往往受限。RLM通过将子结果存入List变量，最后利用Python的 "".join(results)函数将它们拼接成最终答案，一次性输出或分批输出，突破了Output Token Limit。

自我纠错与验证

模型表现出了明显的“慢思考”特征。时在得出答案后，会不仅直接输出，而是再发起一个新的 llm_query，把刚才找到的证据喂回去，问子模型：“这个证据能支撑这个结论吗？”。

种自我验证机制有效地抵抗了长上下文中的幻觉问题。

工程挑战与局限性

尽管原理优雅，但作为2025年底发布的新技术RLM在当前的工程实现上仍存在明显瓶颈，这也是未来优化的方向。研究者诚实地列出了当前的局限性。 

第一是速度问题

当前的实现是同步的（Sequential/Blocking）。当Root LM调用llm_query时，整个进程必须等待HTTP请求返回。在处理大规模分块任务（如处理1000个文档）时，这会导致极高的Wall-clock time（运行时间）。研究者考虑未来引入 async/await 机制，允许LLM发出并行请求。 

第二是模型能力的硬门槛

RLM对基座模型的Code Generation和Instruction Following能力有极高要求。论文指出，小参数模型（如Qwen3-8B）由于无法编写正确的Python逻辑或无法正确管理环境状态，导致任务失败。这是一种“强者恒强”的架构。 

第三是成本的长尾分布

虽然中位数成本较低，但RLM的成本分布具有“长尾效应”。在某些死循环或过度验证（Over-verification）的Case中（例如Qwen3-Coder反复验证5次答案），成本会飙升。这需要通过强化学习（RL）来对齐模型的“搜索/停止”策略。

总结

Recursive Language Models的本质并不是一个新的模型架构，而是一种推理时的操作系统（OS for Inference）。

它通过将Context视为Disk，将LLM视为CPU，将REPL视为RAM，成功地在现有Transformer架构之上，通过软件工程手段解决了无限上下文的难题。

对于AI从业者而言，这篇论文揭示了一个战略方向：在2026年，与其在Training-time死磕昂贵的长窗口训练，不如在Inference-time投资能够编写递归代码的Agentic架构。

文章来自于“AI修猫Prompt”，作者 “AI修猫Prompt”。