廉价模型能超越前沿模型吗？用 Codex 重建递归语言模型

Dev.to ML 2026-08-10T00:33:01.246011

大语言模型现在拥有巨大的上下文窗口。但这并不意味着它们能可靠地利用全部上下文。随着提示词越来越长，模型可能会遗漏细节、丢失关系追踪，或者给出一个貌似合理的摘要，而不是真正完成问题所要求的彻查工作。递归语言模型（Recursive Language Models，简称 RLM）论文提出了一种不同的接口：把大上下文放在模型外部，作为持久化编程环境中的一个变量暴露出来，让模型自己检查、切分，并递归查询较小的片段。我们用一个不寻常的约束重建了这套方法：不用 OPENAI_API_KEY，用 Codex CLI 作为模型后端，gpt-5.4-mini 同时充当 RLM 根模型和每一次子调用，而只把直接调用前沿模型作为独立的基准对照。结果令人鼓舞，也很昂贵，而且比“廉价模型等于前沿模型”这个说法要微妙得多。

RLM 改变了什么

普通模型调用大致是这样：

大提示词 -> 模型 -> 答案

而 RLM 则把关于输入的元数据交给根模型，并提供一个装载了真实上下文的 Python REPL：

问题
|
根模型
|
持有上下文的持久化 REPL
|-- 用代码检查和搜索
|-- 将上下文切分为有用的块
|-- 在这些块上调用较小的语言模型
|-- 验证并汇总结果

-- return the final answer

关键之处在于，根模型不需要把每份文档、记录、工具结果和部分答案都塞进自己的上下文窗口。大型中间值可以留在 REPL 变量里。子调用接收的是聚焦的、局部易于理解的任务。这让 RLM 不再像一个更大的提示词，而更像一个把中间数据放在内存之外处理的数据系统——只是它的语义运算单元恰好是个语言模型。

我们实际测试了什么

我们使用了 RLM 工作中协议描述的一个 OOLONG trec_coarse 验证示例。输入是一个 308,367 字符的上下文，包含 3,182 个常识问题。每个问题隐式地属于六种答案类型之一：数值、实体、人物、地点、缩写、描述和抽象概念。标签并未出现在上下文中。任务是推断出这些标签，并找出最稀少的类别。

我们比较了两种方案：

直接的前沿模型调用回答了「缩写」，得分为 0。只用 mini 的 RLM 回答了「数值」，与标准答案一致。

方法 结果 模型调用次数 耗时
直接前沿模型调用 错误 1 40.1 秒
仅用 gpt-5.4-mini 的 RLM 正确 至少 238 6,120.3 秒

RLM 的根调用首先检查了上下文的结构，然后对分块进行分类、重试格式错误的响应、缩小分块大小、使用结构化 JSON 输出重新对所有 3,182 个问题分类、检查覆盖是否完整，最后计算出最少出现的类别。这正是直接模型调用通常会蒙混过去、而递归程序能强迫自己完成的工作。

令人不适但有用的核查

最终答案正确，并不代表每一个中间判断都正确。我们把 mini 模型推断的计数与验证过的标签做对比：

标签 真实计数 Mini 推断值
数值 398 402
实体 521 623
人物 544 488
地点 571 493
缩写 571 560
描述和抽象概念 577 616

模型在行级别的分类上出现了大量错误。

它仍然找出了正确的最小值，因为该数值比次小的真实类别高出了 123 项。这一差别至关重要。本次运行说明，任务分解改变了结果，让一个便宜模型解决了直接调用前沿模型时漏掉的问题。当然，这不能证明便宜模型精确还原了数据，单行结果也不足以说明两个系统总体等价。更严谨的说法是：在合适的长上下文任务上，RLM 内部的便宜模型可以媲美甚至超越直接调用前沿模型。

RLM 研究已经验证了四类有用的任务形态：

  1. 语义聚合：OOLONG 任务要求对分散在大型输入中的信息进行标注和聚合。实际应用包括：客户反馈分析、支持工单分类、调查汇总、事件与应用日志分析、文本记录的质量控制统计。本次实验就属于这一类。

  2. 多文档研究：BrowseComp-Plus 要求在一个非常大的离线语料库中跨文档拼接证据。类似应用包括：文献综述、技术文档调研、合同与政策比对、尽职调查资料库、有据可查的竞品研究。

  3. 代码库级理解：论文包含 LongBench-v2 CodeQA，其中的问题需要跨代码库文件进行推理。可能用途包括：架构映射、迁移影响分析、依赖与许可证审计、安全分诊、定位缺失测试、对照文档检查实现。

  4. 跨记录与成对推理：OOLONG-Pairs 要求系统在记录组合之间建立关系。应用场景可能包括：实体解析、策略冲突检测、按约束条件匹配候选对象、查找相关事件、识别不兼容配置，以及跨档案的关系发现。

这些任务的计算量可能呈平方级增长，因此需要严格的预算控制和确定性的后处理。

一个实际的新用例：读懂智能体会话档案

在翻看本机 Claude Code 的历史记录时，我们发现单份会话记录就有 242 MB，包含 39,570 条 JSONL 记录。所有项目会话记录合计约占 3.6 GB。这份大体积的会话并非 242 MB 的有用对话：其中约 176 MB 是附件记录，约 29 MB 是助手事件，约 20 MB 是用户和工具结果事件，约 12 MB 是文件历史快照。

这正是典型的 RLM 型问题。第一遍可以用确定性脚本流式读取 JSONL：对重复附件做哈希去重、重建父子事件关系、合并子智能体日志，并抽取消息、命令、文件变更、测试、提交、错误和结果。随后，RLM 可以分析规范化后的事件片段，并递归构建：跨会话的项目时间线、决策记录、尝试过又放弃的方案图谱、反复出现的失败模式、未完成的任务，以及带证据链的“实际交付了什么”摘要。最终报告应引用会话 ID、事件 ID、时间戳、命令和 Git 提交；否则，它不过是又一份“看起来合理”的摘要而已。

其他可能用例

同样的分解模式可以迁移到：从日志、工单和聊天记录中拼出长事件时间线；跨论文和实验记录做科学证据抽取；合规控制点与证据的映射；大型会议、邮件或项目文档归档；按细粒度评分标准给记录排序；图过滤与多跳关系发现；调和多个来源中相互矛盾的说法；从异质文本构建结构化数据集。

这里反复出现的要求并不是单纯的“输入很长”。一个好的 RLM 任务应具备四个属性：上下文可以被程序化地切分或检索；较小的语义子任务对便宜模型仍然可理解；中间结果能以结构化形式保存；最终结果可以被验证或重新计算。

RLM 不适合哪些场景

RLM 在以下默认情况下表现不佳：

我们成功的那一轮大概花了 102 分钟。这个时长可以接受用于研究运行或隔夜审计，但没法用在交互式端点上。

可复用包应该是什么形态

有用的抽象不是 OOLONG 运行器，也不是一个万能提示词，而是一种上下文计算运行时，附带一小套可复用的方案：run(

输入为 context、objective、recipe、answer_schema、verifier、budget，输出为 answer、evidence、validation、trajectory、usage。初始的分解方法（recipe）可以包括：aggregate_records（记录聚合）、evidence_synthesis（证据综合）、repository_analysis（代码库分析）、cross_record_join（跨记录连接）、timeline（时间线）、candidate_ranking（候选排序）。

在我们规划的配置中，Codex 后端会把根调用和子调用都锁定在 gpt-5.4-mini 上。前沿模型只会在评估环节出现，绝不进入 RLM 的调用树内部。要用于生产环境，还需要隔离的执行环境、调用次数与 token 上限、结构校验、脱敏处理、提示注入防御、可恢复的运行机制，以及每个重要结论对应的源码级证据。

下一步

这一行结果只证明了机制可行，还谈不上基准测试上的胜利。接下来要回答的研究问题主要有：

查看原文