MIT 提出的 Recursive Language 模型，终于讲明白了

MIT 提出的 Recursive Language 模型，终于讲明白了 MIT 提出的 Recursive Language 模型，终于讲明白了 Modified April 27 问题是什么一个模型可以接收 100K+ tokens，并不意味着它就真的能在这么大的上下文上稳定推理。你自己大概率也已经感受过这种现象： • 很长的 Claude Code session 会越来越迟钝 • 拉得很长的 ChatGPT 对话需要你不断重复背景 • 模型并不是在 hallucinate，而是随着上下文变长，真的“变笨了” frontier models 在 needle in a haystack 这类测试里表现很好。但如果你让它们在成千上万条埋得很深的记录里做计数、分类或推理，性能就会迅速崩掉。修复方式：Recursive Language Models（RLMs）核心思想其实很简单：不要强迫模型一次性处理所有内容。让它把上下文拆成更小的片段，然后递归地处理这些片段。这里最关键的变化，是以 context 为中心的分解方式： • Agents 会按照人类预先设计好的步骤去拆任务 • RLMs 则让模型自己去拆上下文本身模型不再像一个临考前死记硬背的学生。它更像一个正在分析数据集的程序员。 RLMs 是怎么工作的？ 1. 把 query 和 context 分开在普通 LLM 调用中，你会把 query 和完整 context 一起发进去。但在 RLM 里，context 更像是存放在 memory 里的一个 Jupyter notebook 变量。模型真正看到的，只有 query，以及一组工具和一个 REPL 环境。 2. 给模型配工具 • Peek：查看上下文的一小段，比如前 2,000 个字符，以理解整体结构 • Grep：用正则筛出相关行 • Partition：把内容进一步切成更小的块 • Recursive Call：在这些更小的块上再次递归调用自己 3. 策略会从任务里自然长出来模型会自己决定如何分解。它可能先 grep，再 partition。也可能先 peek，再 summarize。它不是在执行一个人类预设好的 workflow，而是在过程中自己摸索出更优策略。一个具体例子假设你有 5,000 条客服工单，然后你问： “在用户 12345、67890 和 11111 中，有多少问题与 billing 有关？” 普通 LLM 会把这 5,000 条工单全都吞进去，试图整体扫描，然后在计数时犯错。 RLM 的处理方式则不同： 1. Peek：先看结构，判断“每一行都包含 Date、User ID、Question” 2. Grep：只筛目标用户，把 5,000 行缩到 50 行 3. Recursive call：再递归调用，“把每条记录分类成 billing 或 other” 4. Return：返回最终结果整个过程中，root model 的上下文始终保持很小。没有 rot。为什么这件事重要？ • No context rot：无论文档有多大，准确率都能稳住 • Unlimited context：10M tokens？那就继续切更多层 • Interpretable：你可以清楚看到模型到底做了什么 • Cost efficient：很多次小调用，通常比一次超大 API 调用更划算 • Future proof：随着 LLM 本身变强，RLM 也会自动变强 RLMs 把 context 视为一份可以被程序化探索的数据。模型把代码执行能力和语言推理能力结合了起来。它不是 summarization。也不是一个僵硬固定的 agent。它会根据自己实际发现的信息，决定该如何拆解问题。如果你想进一步读这项工作，我把论文和一个可以直接拿来继续构建的 RLM startup code 一并放在下面： Paper: https://arxiv.org/abs/2512.24601v1 GitHub: https://github.com/alexzhang13/rlm That's a wrap! 如果你喜欢这篇教程： Find me → @ avichawla 我每天都会分享关于 DS、ML、LLMs 和 RAGs 的教程与洞察。问题是什么一个模型可以接收 100K+ tokens，并不意味着它就真的能在这么大的上下文上稳定推理。你自己大概率也已经感受过这种现象： • 很长的 Claude Code session 会越来越迟钝 • 拉得很长的 ChatGPT 对话需要你不断重复背景 • 模型并不是在 hallucinate，而是随着上下文变长，真的“变笨了” frontier models 在 needle in a haystack 这类测试里表现很好。但如果你让它们在成千上万条埋得很深的记录里做计数、分类或推理，性能就会迅速崩掉。修复方式：Recursive Language Models（RLMs）核心思想其实很简单：不要强迫模型一次性处理所有内容。让它把上下文拆成更小的片段，然后递归地处理这些片段。这里最关键的变化，是以 context 为中心的分解方式： • Agents 会按照人类预先设计好的步骤去拆任务 • RLMs 则让模型自己去拆上下文本身模型不再像一个临考前死记硬背的学生。它更像一个正在分析数据集的程序员。 RLMs 是怎么工作的？ 1. 把 query 和 context 分开在普通 LLM 调用中，你会把 query 和完整 context 一起发进去。但在 RLM 里，context 更像是存放在 memory 里的一个 Jupyter notebook 变量。模型真正看到的，只有 query，以及一组工具和一个 REPL 环境。 2. 给模型配工具 • Peek：查看上下文的一小段，比如前 2,000 个字符，以理解整体结构 • Grep：用正则筛出相关行 • Partition：把内容进一步切成更小的块 • Recursive Call：在这些更小的块上再次递归调用自己 3. 策略会从任务里自然长出来模型会自己决定如何分解。它可能先 grep，再 partition。也可能先 peek，再 summarize。它不是在执行一个人类预设好的 workflow，而是在过程中自己摸索出更优策略。一个具体例子假设你有 5,000 条客服工单，然后你问： “在用户 12345、67890 和 11111 中，有多少问题与 billing 有关？” 普通 LLM 会把这 5,000 条工单全都吞进去，试图整体扫描，然后在计数时犯错。 RLM 的处理方式则不同： 1. Peek：先看结构，判断“每一行都包含 Date、User ID、Question” 2. Grep：只筛目标用户，把 5,000 行缩到 50 行 3. Recursive call：再递归调用，“把每条记录分类成 billing 或 other” 4. Return：返回最终结果整个过程中，root model 的上下文始终保持很小。没有 rot。为什么这件事重要？ • No context rot：无论文档有多大，准确率都能稳住 • Unlimited context：10M tokens？那就继续切更多层 • Interpretable：你可以清楚看到模型到底做了什么 • Cost efficient：很多次小调用，通常比一次超大 API 调用更划算 • Future proof：随着 LLM 本身变强，RLM 也会自动变强 RLMs 把 context 视为一份可以被程序化探索的数据。模型把代码执行能力和语言推理能力结合了起来。它不是 summarization。也不是一个僵硬固定的 agent。它会根据自己实际发现的信息，决定该如何拆解问题。如果你想进一步读这项工作，我把论文和一个可以直接拿来继续构建的 RLM startup code 一并放在下面： Paper: https://arxiv.org/abs/2512.24601v1 GitHub: https://github.com/alexzhang13/rlm That's a wrap! 如果你喜欢这篇教程： Find me → @ avichawla 我每天都会分享关于 DS、ML、LLMs 和 RAGs 的教程与洞察。原帖链接：https://x.com/ avichawla/status/2029807609608564917 原帖链接：https://x.com/ avichawla/status/2029807609608564917 MIT 的研究者最近提出了一个很巧妙的方案，用来解决现代 LLM 最大的限制之一：context rot。 context rot 长什么样？你把一份 200 页的文档粘进 ChatGPT。你问了一个很简单的问题。结果答案是错的，尽管相关信息明明就在第 50 页。这并不是因为你超出了 context window。而是因为模型在一次性处理过多内容时，推理能力本身变差了。他们提出的优雅修复方案，叫作 Recursive Language Models。实验结果非常亮眼，而且核心思想其实意外地直观。我们一步一步来理解它。