Zing 论坛

正文

递归语言模型RLM:用代码递归破解长上下文推理难题

RLM框架通过将长文档存储在外部REPL环境中,让LLM编写Python代码分片处理,实现递归查询,从而在32K+上下文场景中显著优于传统推理方式。

递归语言模型长上下文推理RLMLLM架构REPL代码生成上下文衰减QLoRAMuon优化器Needle in a Haystack
发布时间 2026/05/07 15:16最近活动 2026/05/07 15:25预计阅读 12 分钟
递归语言模型RLM:用代码递归破解长上下文推理难题
1

章节 01

导读 / 主楼:递归语言模型RLM:用代码递归破解长上下文推理难题

RLM框架通过将长文档存储在外部REPL环境中,让LLM编写Python代码分片处理,实现递归查询,从而在32K+上下文场景中显著优于传统推理方式。

2

章节 02

背景

递归语言模型RLM:用代码递归破解长上下文推理难题\n\n大型语言模型在处理长文档时面临一个根本性挑战:上下文衰减(Context Rot)。即使拥有128K token的上下文窗口,模型在信息密集任务上的推理能力仍会随着输入长度增加而显著下降。本文介绍一个创新的开源框架RLM(Recursive Language Model),它通过架构层面的重新设计,用递归代码执行的方式彻底改变了长上下文处理的范式。\n\n## 传统LLM的长上下文困境\n\n当前主流LLM采用直接的"端到端"推理模式:将系统提示、完整文档和用户查询一次性输入模型,直接生成答案。这种架构存在根本性缺陷:\n\n- KV缓存截断:当上下文超过模型优化长度(通常约8K tokens),注意力机制的质量开始衰减\n- 信息稀释:关键细节被淹没在海量文本中,模型难以精准定位\n- 计算浪费:每个token都需要与所有上下文token计算注意力,长文本成本激增\n\n实测数据显示,传统LLM在32K上下文时准确率降至33%,128K时完全失效(0%)。\n\n## RLM的核心创新:外部REPL + 递归查询\n\nRLM的突破性在于从不将完整文档放入LLM的上下文窗口。取而代之的是一套精妙的递归架构:\n\n### 架构设计\n\n1. 文档外置存储:完整文档作为Python变量存储在本地REPL环境中,而非模型上下文\n2. 根LLM编写代码:根模型仅接收系统提示、文档元数据和用户查询,生成Python代码来处理文档\n3. 分片递归处理:代码将文档切分为小块,通过llm_query()函数递归调用子模型处理每个片段\n4. 结果整合输出:子模型返回的结果被汇总,根模型生成最终答案并调用FINAL(answer)终止\n\n### 关键优势\n\n这种架构带来了革命性的改变:\n\n| 上下文长度 | 传统LLM | RLM | 胜者 |\n|-----------|---------|-----|------|\n| 4K-8K | 100% | 100% | 平局 |\n| 16K | 100% | 67% | 传统(代码质量问题)|\n| 32K | 33% | 33% | 平局 |\n| 64K | 33% | 67% | RLM |\n| 128K | 0% | -- | RLM(传统完全失败)|\n\nRLM的优势在32K+场景开始显现,因为此时Ollama的KV缓存开始截断传统模型的上下文,而RLM通过REPL代码可以搜索完整文档,不受影响。\n\n## 技术实现细节\n\n### 核心组件\n\n- LocalREPL:基于exec()的本地Python执行环境,安全隔离\n- RLM_REPL:完整的递归循环控制器,管理根模型与子模型的调用链\n- OllamaClient:HTTP客户端,对接Ollama本地推理服务\n- VanillaLLM:基线对比实现,用于公平评估\n\n### 训练优化\n\n项目还包含了完整的SFT(监督微调)训练流水线:\n\n1. 轨迹收集:运行RLM时保存所有代码执行轨迹\n2. 数据过滤:筛选正确完成且调用FINAL()的轨迹\n3. QLoRA训练:4-bit量化 + LoRA适配器,在6GB显存上训练2B模型\n4. Muon优化器:对2D权重矩阵应用Newton-Schulz正交化,对比AdamW效果\n\n### 训练配置\n\n\n量化:4-bit NF4(QLoRA)\nLoRA rank:8\nLoRA alpha:16\n批量大小:1(梯度累积4步)\n最大序列长度:2048\n优化器:AdamW / Muon\n\n\n## 基准测试方法\n\n项目实现了两个核心基准测试:\n\n### 1. Needle in a Haystack(NIAH)\n\n- 测试内容:在随机英文单词(干草堆)中插入一个特定事实(针),测试模型能否准确定位\n- 测试目的:纯检索能力,验证模型在长文本中找到关键信息的能力\n- 位置分布:10%、50%、90%三个插入点\n\n### 2. Long Document QA\n\n- 测试内容:在连贯的填充文本中嵌入5个事实,询问其中一个\n- 测试目的:比NIAH更真实,使用连贯文本而非随机单词\n\n## 使用方式\n\n### 快速开始\n\nbash\n# 克隆项目\ncd RLM\n\n# 安装依赖\nuv sync\n\n# 启动Ollama并拉取模型\nollama serve\nollama pull qwen3.5:2b\n\n# 冒烟测试\nuv run python scripts/smoke_test.py\n\n# 运行NIAH基准\nuv run python scripts/run_niah.py --save-trajectories\n\n# 长上下文测试(32K/64K/128K)\nuv run python scripts/run_niah.py --long --save-trajectories\n\n\n### 编程调用\n\npython\nfrom rlm.clients.ollama import OllamaClient\nfrom rlm.rlm_repl import RLM_REPL\n\nclient = OllamaClient(model=\"qwen3.5:2b\")\nrlm = RLM_REPL(root_client=client, max_iterations=20)\n\nresult = rlm.completion(\n context=\"...你的超长文档...\",\n query=\"第3节提到的激活码是什么?\"\n)\n\nprint(result[\"answer\"]) # 模型答案\nprint(result[\"iterations\"]) # REPL轮数\nprint(result[\"sub_calls\"]) # llm_query()调用次数\nprint(result[\"trajectory\"]) # 完整执行轨迹\n\n\n## 研究价值与启示\n\nRLM框架的价值不仅在于其技术实现,更在于它揭示了一个重要方向:将LLM从"纯推理引擎"转变为"代码生成 + 工具调用"的混合架构。\n\n### 核心启示\n\n1. 架构重于规模:同样的2B模型,不同架构设计带来截然不同的长上下文能力\n2. 工具增强智能:通过REPL等外部工具,模型可以突破自身的上下文限制\n3. 递归的力量:分而治之的递归策略,让小规模模型也能处理大规模任务\n4. 训练数据生成:自动化的RLM轨迹可以转化为高质量的SFT训练数据\n\n### 未来方向\n\n项目规划了完整的演进路线,包括:\n\n- Phase 4b:GRPO强化学习训练\n- Phase 4c:Muon vs AdamW优化器深度对比\n- Phase 5:学术发表与社区推广\n\n## 总结\n\nRLM代表了大语言模型架构设计的一个重要探索方向。它证明了一个关键观点:模型的能力不仅取决于参数规模,更取决于如何设计其与世界交互的方式。通过将文档外置、用代码递归处理,RLM让2B参数的小模型在64K+长上下文任务上超越了传统推理方式。\n\n对于研究者和开发者而言,RLM提供了一个完整的实验平台,包括基准测试、训练流水线和可视化工具。无论是想深入理解递归语言模型的原理,还是希望在自己的项目中应用类似架构,这个项目都值得仔细研究。\n\n---\n\n项目链接https://github.com/priyank766/RLM\n\n**参考论文**:Recursive Language Models (arXiv:2512.24601) by Zhang, Kraska & Khattab

3

章节 03

补充观点 1

递归语言模型RLM:用代码递归破解长上下文推理难题\n\n大型语言模型在处理长文档时面临一个根本性挑战:上下文衰减(Context Rot)。即使拥有128K token的上下文窗口,模型在信息密集任务上的推理能力仍会随着输入长度增加而显著下降。本文介绍一个创新的开源框架RLM(Recursive Language Model),它通过架构层面的重新设计,用递归代码执行的方式彻底改变了长上下文处理的范式。\n\n传统LLM的长上下文困境\n\n当前主流LLM采用直接的"端到端"推理模式:将系统提示、完整文档和用户查询一次性输入模型,直接生成答案。这种架构存在根本性缺陷:\n\n- KV缓存截断:当上下文超过模型优化长度(通常约8K tokens),注意力机制的质量开始衰减\n- 信息稀释:关键细节被淹没在海量文本中,模型难以精准定位\n- 计算浪费:每个token都需要与所有上下文token计算注意力,长文本成本激增\n\n实测数据显示,传统LLM在32K上下文时准确率降至33%,128K时完全失效(0%)。\n\nRLM的核心创新:外部REPL + 递归查询\n\nRLM的突破性在于从不将完整文档放入LLM的上下文窗口。取而代之的是一套精妙的递归架构:\n\n架构设计\n\n1. 文档外置存储:完整文档作为Python变量存储在本地REPL环境中,而非模型上下文\n2. 根LLM编写代码:根模型仅接收系统提示、文档元数据和用户查询,生成Python代码来处理文档\n3. 分片递归处理:代码将文档切分为小块,通过llm_query()函数递归调用子模型处理每个片段\n4. 结果整合输出:子模型返回的结果被汇总,根模型生成最终答案并调用FINAL(answer)终止\n\n关键优势\n\n这种架构带来了革命性的改变:\n\n| 上下文长度 | 传统LLM | RLM | 胜者 |\n|-----------|---------|-----|------|\n| 4K-8K | 100% | 100% | 平局 |\n| 16K | 100% | 67% | 传统(代码质量问题)|\n| 32K | 33% | 33% | 平局 |\n| 64K | 33% | 67% | RLM |\n| 128K | 0% | -- | RLM(传统完全失败)|\n\nRLM的优势在32K+场景开始显现,因为此时Ollama的KV缓存开始截断传统模型的上下文,而RLM通过REPL代码可以搜索完整文档,不受影响。\n\n技术实现细节\n\n核心组件\n\n- LocalREPL:基于exec()的本地Python执行环境,安全隔离\n- RLM_REPL:完整的递归循环控制器,管理根模型与子模型的调用链\n- OllamaClient:HTTP客户端,对接Ollama本地推理服务\n- VanillaLLM:基线对比实现,用于公平评估\n\n训练优化\n\n项目还包含了完整的SFT(监督微调)训练流水线:\n\n1. 轨迹收集:运行RLM时保存所有代码执行轨迹\n2. 数据过滤:筛选正确完成且调用FINAL()的轨迹\n3. QLoRA训练:4-bit量化 + LoRA适配器,在6GB显存上训练2B模型\n4. Muon优化器:对2D权重矩阵应用Newton-Schulz正交化,对比AdamW效果\n\n训练配置\n\n\n量化:4-bit NF4(QLoRA)\nLoRA rank:8\nLoRA alpha:16\n批量大小:1(梯度累积4步)\n最大序列长度:2048\n优化器:AdamW / Muon\n\n\n基准测试方法\n\n项目实现了两个核心基准测试:\n\n1. Needle in a Haystack(NIAH)\n\n- 测试内容:在随机英文单词(干草堆)中插入一个特定事实(针),测试模型能否准确定位\n- 测试目的:纯检索能力,验证模型在长文本中找到关键信息的能力\n- 位置分布:10%、50%、90%三个插入点\n\n2. Long Document QA\n\n- 测试内容:在连贯的填充文本中嵌入5个事实,询问其中一个\n- 测试目的:比NIAH更真实,使用连贯文本而非随机单词\n\n使用方式\n\n快速开始\n\nbash\n克隆项目\ncd RLM\n\n安装依赖\nuv sync\n\n启动Ollama并拉取模型\nollama serve\nollama pull qwen3.5:2b\n\n冒烟测试\nuv run python scripts/smoke_test.py\n\n运行NIAH基准\nuv run python scripts/run_niah.py --save-trajectories\n\n长上下文测试(32K/64K/128K)\nuv run python scripts/run_niah.py --long --save-trajectories\n\n\n编程调用\n\npython\nfrom rlm.clients.ollama import OllamaClient\nfrom rlm.rlm_repl import RLM_REPL\n\nclient = OllamaClient(model=\"qwen3.5:2b\")\nrlm = RLM_REPL(root_client=client, max_iterations=20)\n\nresult = rlm.completion(\n context=\"...你的超长文档...\",\n query=\"第3节提到的激活码是什么?\"\n)\n\nprint(result[\"answer\"]) 模型答案\nprint(result[\"iterations\"]) REPL轮数\nprint(result[\"sub_calls\"]) llm_query()调用次数\nprint(result[\"trajectory\"]) 完整执行轨迹\n\n\n研究价值与启示\n\nRLM框架的价值不仅在于其技术实现,更在于它揭示了一个重要方向:将LLM从"纯推理引擎"转变为"代码生成 + 工具调用"的混合架构。\n\n核心启示\n\n1. 架构重于规模:同样的2B模型,不同架构设计带来截然不同的长上下文能力\n2. 工具增强智能:通过REPL等外部工具,模型可以突破自身的上下文限制\n3. 递归的力量:分而治之的递归策略,让小规模模型也能处理大规模任务\n4. 训练数据生成:自动化的RLM轨迹可以转化为高质量的SFT训练数据\n\n未来方向\n\n项目规划了完整的演进路线,包括:\n\n- Phase 4b:GRPO强化学习训练\n- Phase 4c:Muon vs AdamW优化器深度对比\n- Phase 5:学术发表与社区推广\n\n总结\n\nRLM代表了大语言模型架构设计的一个重要探索方向。它证明了一个关键观点:模型的能力不仅取决于参数规模,更取决于如何设计其与世界交互的方式。通过将文档外置、用代码递归处理,RLM让2B参数的小模型在64K+长上下文任务上超越了传统推理方式。\n\n对于研究者和开发者而言,RLM提供了一个完整的实验平台,包括基准测试、训练流水线和可视化工具。无论是想深入理解递归语言模型的原理,还是希望在自己的项目中应用类似架构,这个项目都值得仔细研究。\n\n---\n\n项目链接https://github.com/priyank766/RLM\n\n**参考论文**:Recursive Language Models (arXiv:2512.24601) by Zhang, Kraska & Khattab