RLM：AI 的终极进化？递归语言模型

发布: 3天前 (2026年1月14日 GMT+8 01:52)

11 min read

原文: Dev.to

Source: Dev.to

简单版

如果让 AI 再次行动，结果可能会非常显著。

为什么当前的“更大上下文”竞争仍不足

上下文窗口军备竞赛
- Gemini：窗口规模达数百万 token
- GPT 系列：窗口持续扩展
- Llama：目标是数千万 token
问题——更大的窗口并不保证模型能够阅读并记住所有内容。
检索增强生成（RAG）
1. 将长文档切分为块。
2. 将块存入向量数据库。
3. 为查询检索相关块并将其输入模型。
优点：避免一次性喂入整篇文档。
缺点：效果依赖检索质量；在需要全面信息的提问上表现不佳。
常见缺陷——这些方法都把模型视为被动的。模型必须等待人类（或流水线）组织、切分并喂入信息。真正的智能不应受此限制。

MIT的颠覆性想法：递归语言模型（RLM）

“为什么不让模型读取它自己？自行查找？自行切片？自行调用？”

核心洞见

将上下文从 “输入” 转变为 “环境”。
模型不再只接收一串长 token。
而是像程序一样，将整个上下文视为 REPL（Read‑Eval‑Print Loop）环境中的变量，从而可以 随时查看、切片、搜索、过滤，并递归调用自身。

它不再是“被喂入信息”，而是“主动探索信息”。

类比

之前：“这里有一本书给你阅读。”
现在：“这里有一个图书馆供你搜索、剖析、总结，并使用你自己的助手。”

这种方法：

绕过了 Transformer 架构的上下文限制。
让模型首次具备 过程式访问世界 的能力。

实时演示（视频）

观看演示视频

任务： “打印前 100 个 2 的幂，每个占一行。”

聊天机器人所做的工作

探索与检查
- 打印上下文的小片段。
- 检查结构，寻找标题、模式或重复短语。
- 使用字符串切片和正则表达式来理解数据组织。
程序化过滤与索引
- 应用 Python 方法，如 split()、find()、re.findall()、循环和条件语句。
- 将庞大的输入缩小到重要部分，提前剔除噪声。
任务分解
- 将主要问题拆解为更小、定义明确的子任务，使其能够舒适地适应普通模型的上下文窗口。
- 分解 由模型自行决定，基于其探索结果。
递归自调用
- 对每个子任务，模型调用自身（或调用一个更小的辅助模型）。
- 这些调用形成一个 推理树，而非单一链条。
- 每次调用返回部分结果，存储在 REPL 变量中。
聚合与综合
- 使用 Python 逻辑合并摘要、比较结果、计算成对关系，或组装结构化输出（列表、表格、长文档）。
验证与自检
- 可能重新运行分析的部分，使用另一次递归调用交叉检查结果，或通过代码验证逻辑。
- 提供类似人类双重检查的多遍推理。
最终输出构建
- 在变量中逐步构建答案，然后返回组装好的结果。
- 实现 极长、结构化的输出，这是传统 LLM 无法完成的。

什么让 RLM 与众不同？

按回车键或点击查看完整尺寸图片

(图片占位符 – 在此插入相应图形。)

主动解决问题者 而非被动阅读者。
将输入视为 工作空间，可以使用代码进行探索、搜索和拆分。
决定 阅读什么、如何切分 信息，以及 何时再次调用自身 以获取更小的片段。
通过利用 编程访问、递归和自检，避免因长或复杂输入导致的混乱，并在任务难度提升时保持稳定。

结果： RLM 能处理 大规模上下文、高复杂度推理 和 长结构化输出——这些是传统语言模型根本无法匹配的能力。

Source: …

RLM到底是如何工作的？

按回车或点击查看完整尺寸图片

(图片占位符 – 在此插入相应的图示。)

传统 LLM 工作流

输入一长串 token。
单次前向推理 生成答案。

当上下文长度超过模型的窗口时，模型要么截断输入，要么依赖外部检索，这两者都会重新引入被动阅读的限制。

RLM 工作流（对比）

步骤	传统 LLM	RLM
输入处理	单一的 token 序列	输入是一个可变环境（REPL 变量）
阅读方式	被动、线性扫描	主动探索（切片、搜索、正则表达式）
推理方式	单一思考链	递归树的自调用
记忆	固定的上下文窗口	通过变量实现的无限工作区
输出	受 token 预算限制	增量组装任意长度的结果
验证	可选的事后检查	内置自检，通过重新执行实现

TL;DR

递归语言模型 将模型转变为一个 交互式代理，能够 读取、搜索、切片并按需调用自身。
这种范式 突破了上下文窗口的限制，并实现了 程序化、多步骤推理 的大规模应用。
其结果是一个 更稳健、可扩展且更智能 的系统，用于处理庞大且复杂的任务。

RLM 的方法

在处理数十万甚至数百万个 token 时，传统方法就像让人一次性读完《战争与和平》再回答问题——必然会崩溃。

RLM（检索增强语言模型）走的是完全不同的路线。

将整个长上下文加载到 Python REPL 中，作为变量，例如 context。
模型不再直接“吃”这些 token，而是 通过编写代码来访问它们，就像程序员一样。

这是模型第一次拥有“工具”。它可以：

查看特定片段
```
print(context[:500])
```
搜索关键词
```
re.findall("festival", context)
```

按章节拆分

part1, part2 = context.split("Chapter 2")

构建子任务

sub_answer = llm_query(f"Please summarize {part1}")

递归调用自身
```
result = rlm_query(sub_prompt)
```

这让模型拥有了“手”和“眼”。它不再是被动的语言生成器，而是一个 智能代理，能够主动探索、拆解并规划。

论文中的示例生动直观：

模型首先打印前 100 行以检查结构，然后决定如何切分。
它使用关键词过滤可能相关的段落。
它将任务拆分为多个子问题，并递归调用自身来解决。

底线： 这不是提示工程，而是 程序工程。

RLM 的局限是什么？

局限性	说明
开销与复杂度	对于短输入或简单任务，基础模型更快、更高效，因为 RLM 增加了环境交互和递归调用的开销。
同步、阻塞的子模型调用	增加了端到端延迟，可能导致响应变慢。
固定的系统提示	未针对不同任务类型进行定制，导致性能提升受限。
安全与可靠性问题	允许模型在 REPL 中编写并执行代码会带来隔离、安全性和可预测性方面的工程挑战。

简而言之： RLM 在处理困难的大规模问题时表现出色，但对于简单任务而言，它比标准模型更笨重、慢且复杂。

My Impression

RLM 代表了一种从“我们如何压缩上下文？”到 “我们如何教模型像熟练的开发者一样主动管理上下文？” 的转变。

与其通过更大的窗口或有损的摘要来对抗上下文限制，RLM 拥抱这一约束 并学习在其中工作——以程序化的方式进行委派、过滤和聚焦。这是一种随学习而扩展的脚手架，而不仅仅是工程手段。

支持与联系

Patreon:
预约:
Buy Me a Coffee（支持内容）:
订阅新闻通讯（免费）: