上下文窗口卷到1亿Token也没用？MIT教大模型像程序员一样写代码，轻松处理千万级文本

MIT开发的递归语言模型(RLMs)解决了大模型处理长文本的瓶颈问题。该方法将长文本视为外部变量，让模型通过编写Python代码分块读取、检索并递归调用自身处理信息，而非直接塞入上下文窗口。这种"像程序员一样思考"的架构使模型能主动管理信息，在保持成本优势的同时，显著提升了在超长文本任务中的性能表现，为长文本处理提供了全新思路。

Python_金钱豹

850人浏览 · 2026-01-10 17:21:24

Python_金钱豹 · 2026-01-10 17:21:24 发布

算泥社区是集 “AI 大模型开发服务 + 算法 + 算力” 于一体的开源生态社区，欢迎关注！

MIT计算机科学与人工智能实验室（CSAIL）的研究人员刚刚颠覆了我们对长文本处理的认知。

他们不再试图把整本书塞进大模型的脑子里，而是教大模型像程序员一样把长文本变成代码里的变量来处理。

把提示词变成变量，让大模型学会递归调用自己。

大模型处理长文本的能力正在遭遇瓶颈，单纯扩大上下文窗口不仅成本高昂，还会导致模型在海量信息中迷失方向。

研究人员提出的递归语言模型（Recursive Language Models, RLMs）通过引入Python交互环境，让模型学会写代码去分块读取、检索并递归调用自身处理信息，成功在千万级Token的超长文本任务中实现了性能与成本的双重突破。

长文本处理的本质是内存管理问题

现在的语言模型开发，我们在疯狂卷上下文窗口的长度，从几千到几万，再到百万甚至上亿Token。

但即使是最顶尖的模型，在面对真正巨大的信息量时，依然会表现出上下文腐烂（Context Rot）的现象。

这就好比一个人的记性再好，如果你让他一口气背下一整部百科全书，他不仅背不下来，连原本能记住的第一页内容也会忘得精光。

即使是GPT-5这样的前沿模型，随着输入长度的增加和任务复杂度的提升，性能也会呈断崖式下跌。

MIT的研究团队从经典的核外算法（Out-of-Core Algorithms）中找到了灵感。

在计算机科学的早期，当内存（RAM）不足以装下整个数据集时，程序员会把数据留在硬盘上，只把当前需要处理的一小部分调入内存。

这种古老而朴素的智慧被完美移植到了大模型上。

与其把长达数千万Token的提示词（Prompt）直接喂给神经网络，不如把它看作外部环境的一部分。

在RLM的架构中，提示词不再是输入流，而是一个存储在Python环境中的字符串对象。

大模型不需要一次性看见所有内容，它只需要知道这个字符串存在，并且可以通过写代码去操作它。

这不仅解决了显存限制的问题，更重要的是它改变了模型处理信息的方式。

模型从被动接收信息的阅读者，变成了主动检索和管理信息的操作者。

这种转变让模型能够处理的文本长度在理论上变得无限大，受限的不再是模型的瞳孔（上下文窗口），仅仅是外部存储的大小。

像程序员一样递归调用自身

RLM的核心机制在于一个简单的Python读取-求值-输出循环（REPL）。

当用户输入一个超长问题和相关文档时，RLM并不会把文档塞进Prompt里，而是将其赋值为一个Python变量P。

下图清晰地展示了这个过程。模型进入一个编程环境，它知道变量P包含了这次任务的所有文本数据，也知道P的长度。

在这个环境中，模型展现出了惊人的能动性。

它会编写Python代码来偷看文本的片段，比如print(prompt[:100])来了解开头讲了什么。更关键的是，它拥有了分而治之的能力。

遇到复杂任务时，模型会把长字符串切分成若干小块，然后针对每一小块再次调用一个新的大模型实例（Sub-LM）。

这个子模型就像是主模型的一个分身，专门负责处理那一小块数据，并把处理结果返回给主模型。

这种设计使得RLM具备了极强的逻辑推理能力。

比如在处理需要跨越多个章节寻找线索的小说阅读任务时，主模型会写代码遍历每一个章节，让子模型去寻找特定的关键词或情节，最后将所有子模型的发现汇总起来，形成最终答案。

这个过程完全由模型自己生成的代码控制。

它可以选择使用正则表达式（Regex）来快速过滤无关信息，也可以选择精细的语义切片。

这种灵活性是传统的RAG（检索增强生成）或者上下文压缩（Context Compaction）技术所无法比拟的。

RAG往往受限于检索算法的准确性，容易漏掉关键信息；而上下文压缩则像是有损压缩图片，在不断摘要的过程中丢失了细节。

RLM则完整保留了原始数据，直到模型决定去读取它的那一刻。

极高复杂度中的压倒性优势

为了验证RLM的实战能力，研究团队设计了一系列不仅考验长度，更考验信息密度的变态任务。

除了常见的大海捞针（S-NIAH），他们还引入了OOLONG和OOLONG-Pairs这两个极具挑战性的基准测试。

OOLONG任务要求模型处理的每一个文本片段都对最终答案有贡献，这意味着随着文本长度增加，计算量呈线性增长。

而OOLONG-Pairs更是变态，它要求模型聚合文本中几乎所有可能的片段对，计算复杂度随长度呈二次方增长。

下表的数据展示了RLM与现有主流方法的正面交锋。

在CodeQA、BrowseComp-Plus（多文档问答）以及OOLONG系列任务上，RLM均取得了显著的领先优势。

在Qwen3-Coder-480B模型上，RLM在CodeQA任务中达到了56.00%的准确率，远超CodeAct（24.00%）和Summary agent（50.00%）。

在最难的OOLONG-Pairs任务中，基础模型几乎完全失效（0.06%），而RLM依然保持了23.11%的F1分数。

更令人印象深刻的是在GPT-5上的表现。

在BrowseComp-Plus任务中，处理600万到1100万Token的超大规模输入时，基础版GPT-5因为上下文限制根本无法运行，而RLM不仅跑通了，还拿下了91.33%的惊人高分，完爆Summary agent的70.47%。

单纯把窗口做大并没有解决根本问题。当任务需要高密度的推理和跨段落的信息整合时，模型需要的是一种能够逻辑化管理信息的机制，而不是一个更大的胃。

RLM通过代码赋予了模型这种逻辑管理能力，让它能够在海量数据中游刃有余。

值得注意的是，表中还展示了一个RLM (no sub-calls)的变体，即禁止模型进行递归调用，只允许它用代码操作字符串。

即使在被捆住手脚的情况下，这种方法依然在很多任务上优于直接输入长文本。

这证明了将提示词作为外部变量处理这一思路本身的优越性。它避免了把无关的Token塞进注意力层，减少了干扰。

成本更低且更加智能的推理策略

人们通常认为，让模型反复调用自己会大幅增加成本。

但实验结果却给出了相反的结论。

下图展示了不同方法的API成本分布。在很多情况下，RLM的成本甚至低于直接把长文本喂给模型。

这就像当你需要在一本书里找一句话，直接读整本书是最笨也是最贵的办法。

RLM通过编写正则表达式进行初步筛选，或者只读取目录和特定章节，实际上大大减少了需要真正经过神经网络处理的Token数量。

在上图中，我们看到了RLM在实际运行中展现出的智能行为。

它能够利用正则表达式（Regex）快速定位包含特定关键词（如festival）的段落，利用模型内部的先验知识（如知道La Union是一个地名）来缩小搜索范围。

这种先过滤，后阅读的策略极大地节省了算力。

此外，不同的模型在扮演RLM时展现出了不同的性格。

GPT-5表现得非常谨慎，它倾向于做更多的检查和确认；而开源的Qwen3-Coder则表现得更加激进，倾向于通过大量的子调用来解决问题。

例如在OOLONG任务中，Qwen3-Coder甚至会为文本的每一行都发起一个子模型调用来进行语义转换。

虽然这听起来很疯狂，但在处理需要极高精度的密集型任务时，这种策略被证明是有效的。

RLM并不是一个僵化的框架，它赋予了模型自由裁量权，让模型根据任务的难度和自身的特点来决定最佳的解题路径。

这种通过代码进行显式推理的过程，实际上是将原本在大模型内部黑盒中进行的注意力分配，外化为了可观察、可调试的代码逻辑。

这不仅提高了性能，也为我们理解模型的决策过程提供了绝佳的窗口。

RLM让我们开始教模型如何使用外部存储和工具，不再执着于把所有信息都塞进模型的短期记忆里。

未来的模型训练很可能会专门针对RLM架构进行优化。

我们可以训练模型更聪明地编写检索代码，更高效地进行递归调用，甚至学会如何在成本和精度之间做权衡。

这种推理时计算（Inference-time Compute）的扩展，为突破现有的硬件瓶颈提供了一条全新的、纯软件层面的路径。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述