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）的扩展，为突破现有的硬件瓶颈提供了一条全新的、纯软件层面的路径。
参考资料：
https://arxiv.org/pdf/2512.24601
