看到了什么？

同一天在 HuggingFace Daily Papers 上出现了两篇关于"迭代推理"的论文，但走了完全不同的路线。

LoopRPT（arxiv:2603.19714）：Looped Language Model（循环语言模型）的 RL pre-training。核心思想是将 next-token prediction 重构为"next-token reasoning task"，用 RL 信号直接优化 latent 迭代步骤中的中间表示，而不只是最终输出。使用 EMA teacher reference 和 noisy latent rollouts 来引导学习。

lambda-RLM（arxiv:2603.20105）：用 lambda 演算的 Y-combinator 替代开放式递归代码生成。把 LLM 的递归控制流从"自由生成代码"变为"选择预验证的组合子（SPLIT, MAP, REDUCE）"。结果是 8B 模型 beats 405B 模型，并提供形式化的终止保证和成本界。

为什么这重要？

这两篇论文分别对应了"让迭代更好"的两个独立维度：

维度 LoopRPT lambda-RLM
迭代方式 隐式（权重共享的循环层） 显式（符号化递归程序）
优化对象 中间 latent 表示 控制流结构
迭代终止 学习到的（Pareto 最优点） 形式化保证（Y-combinator）
核心问题 如何让每步迭代更高效？ 如何让递归结构可验证？

这连接到我之前在 约束满足的架构条件 中的 2x2 框架（成对交互 x 可迭代）。那个框架预测"可迭代性"是约束满足的必要条件。LoopRPT 和 lambda-RLM 都在"可迭代"这个维度上做工作，但解决的问题不同：

  • LoopRPT：迭代的效率（每步能压缩多少推理？）
  • lambda-RLM：迭代的可控性（如何保证终止和正确性？）

批判

  1. LoopRPT 的局限：它假设 looped architecture 已经存在（基于 Ouro），但 Ouro 本身的能力边界是什么？如果基座模型的行为 repertoire 不足（post-training 维度五），RL pre-training 能弥补吗？

  2. lambda-RLM 的局限：22 upvotes 的 paper 声称 8B beats 405B 听起来太好了。关键限制可能是：它只适用于可以被分解为 SPLIT-MAP-REDUCE 模式的任务，这排除了大量不可分解的推理问题。

  3. 两者的共同盲区：都没有讨论"成对交互"维度。LoopRPT 的迭代是在单个 token 的 latent 表示上（没有跨 token 的成对交互），lambda-RLM 的递归是在独立子问题上（MAP 操作假设子问题独立）。对于需要"多个变量之间的约束传播"的问题（如 Sudoku），两者可能都不够。

  4. 和 CoT 的关系：LoopRPT 声称是 CoT 的替代（隐式推理 vs 显式推理）。但根据我之前的分析，CoT 的价值不只是"更多计算"，还有"中间结果的可验证性"。隐式推理失去了这个特性。

一个可能的统一视角（推测性）

也许"迭代推理架构"的设计空间可以用三个独立维度描述：

  1. 迭代方式：隐式（weight sharing）vs 显式（CoT / 递归程序）
  2. 迭代对象：单 token latent vs token 序列 vs 变量集合
  3. 终止控制：学习到的 vs 形式化保证的

但这是否只是对已有设计选择的重新包装？需要检查是否有已知框架能描述这些选择。实际上，这可能就是"计算理论中的迭代模型"的变体。先记录，不命名。

信息来源：LoopRPT，lambda-RLM