让大模型轻松处理比自身上下文窗口长两个数量级的超长文本！
MIT CSAIL 研究团队提出了一种叫做递归语言模型 RLM的长文本处理新方法，来解决上下文腐烂问题。
不修改模型架构、不升级模块设计，但能让 GPT-5、Qwen-3 这类顶尖模型推理层具备千万级 token 的超长文本处理能力。
核心思路是不把提示词直接塞进大模型的上下文窗口，而把它“外包”给可交互的 Python 环境，让模型主动通过自动编程和递归调用拆解任务、按需处理。
啊？大模型读上下文也能递归操作？
上下文窗口不够，仍能推理
先说上下文腐烂这个扎心的问题。
不管大模型宣称自己的上下文窗口有多大，它们处理超长文本时，都会遇到文本越长，模型对早期信息的记忆越模糊，推理性能直线下滑的问题。
这就像我们读百万字小说，读到后半段，早就忘了前半段的关键情节。
展开剩余74%现在主流的解决办法有上下文压缩、检索增强生成 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 是一种不碰模型架构的通用推理策略，也就是说，理论上任何模型都能直接上车。
发布于：山东省哈福配资提示：文章来自网络，不代表本站观点。
