让大模型轻松处理比自身上下文窗口长两个数量级的超长文本！ MIT CSAIL 研究团队提出了一种叫做 递归语言模型 RLM 的长文本处理新方法，来解决上下文腐烂问题。 不修改模型架构、不升级模块设计，但能让 GPT-5、Qwen-3 这类顶尖模型推理层具备千万级 token 的超长文本处理能力。 核心思路是不把提示词直接塞进大模型的上下文窗口，而把它"外包"给可交互的 Python 环境，让模型主动通过自动编程和递归调用拆解任务、按需处理。 啊？大模型读上下文也能递归操作？ 上下文窗口不够，仍能推理 先说上下文腐烂这个扎心的问题。 不管大模型宣称自己的上下文窗口有多大，它们处理超长文本时，都会遇到文本越长，模型对早期信息的记忆越模糊，推理性能直线下滑的问题。 这就像我们读百万字小说，读到后半段，早就忘了前半段的关键情节。 现在主流的解决办法有 上下文压缩、检索增强生成 RAG，或者对模型进行架构级优化 。 比如，GPT-5.2-Codex 采用的就是窗口内的原生上下文压缩技术，在持续数周的大型代码仓库协助任务中保持全上下文信息。 同时，GPT 系列、Claude、Qwen 等企业级版本原生集成 RAG 功能也是行业共识。 而架构级优化的例子，有社区普遍猜测的 Gemini 3 的环形注意力等。 现在的 RLM 和这些直接在模型上"硬磕"的方法不同， 它把上下文处理给"外包"了 。 RLM 给模型搭了一个 可交互的 Python 编程环境 REPL 。 开始处理上下文前，它先启动 Python REPL 交互式编程环境，将超长提示词作为字符串变量存入环境； 接着模型像程序员一样编写代码，对文本变量进行关键词筛选、局部探查、逻辑拆分等操作，通过「编写代码-观察结果」的交互循环减少无效信息摄入； 随后模型将复杂任务拆解为若干子任务，递归调用自身或轻量化子模型处理拆分后的文本片段，所有子任务输出均存储为新变量回流到 REPL 环境； 最后主模型编写代码读取并整合所有子任务结果变量，进行逻辑拼接或语义处理，形成最终输出。 全程由模型自主决策，实现按需处理，彻底解耦输入文本长度与模型上下文窗口的绑定。 实验显示， RLM 有效处理规模已突破千万级 Token ，超过 GPT-5 等前沿模型原生上下文窗口的两个数量级。 在复杂长文本任务中，RLM 的优势也比较显著。面对要求聚合成对信息、复杂度呈二次方增长的 OOLONG-Pairs 任务，基础 GPT-5 和 Qwen3-Coder 的 F1 分数不足 0.1%； 采用 RLM 方案后，两款模型分别取得 58.00% 和 23.11% 的 F1 分数。 在 600 万至 1100 万 Token 规模的 BrowseComp-Plus（1K）多文档推理任务中，RLM（GPT-5）的正确率高达 91.33%，大幅超越其他长文本处理方案； 即便在要求线性扫描并处理几乎所有信息的 OOLONG 任务中，RLM 也实现了双位数的性能提升。 从调用成本上看，在 50 分位数这个指标上，RLM 的成本和其他长文本处理方案处于同一水平，甚至更低。 这说明在大多数常规任务场景中，RLM 的性价比是很有优势的。 但到了 95 分位数这类高百分位区间时，RLM 的成本会出现明显飙升。 主要是因为 RLM 的推理过程是动态的，会根据任务复杂度自主决定代码编写、文本拆分和递归调用的次数，额外的步骤会增加 API 调用次数。 最后再划个小重点，RLM 是一种不碰模型架构的通用推理策略，也就是说，理论上任何模型都能直接上车。 论文地址： https://arxiv.org/abs/2512.24601 参考链接： https://x.com/MatthewBerman/status/2012701592756383893 本文来自微信公众号： 量子位（ID：QbitAI） ，作者：闻乐，原标题《真 · 开外挂！MIT 新研究：架构 0 改动，让大模型解锁千万级上下文》