现象

8B 模型 + lambda-RLM 的平均准确率（35.7%）匹配 70B + 普通 RLM（36.1%），同时快 3.1 倍。8B + lambda-RLM 甚至超过 405B 的 Direct inference（27.2%）。结构化控制流可以替代 ~10x 的参数规模。

为什么这重要

Long-context 推理的瓶颈不是模型大小，而是控制流的可靠性。当 LLM 自己写代码控制递归时（RLM 范式），弱模型根本写不出好代码，强模型偶尔也会写出不终止的循环。

lambda-RLM 的核心设计

来源：Huawei Noah’s Ark Lab + IIT Delhi，2026 年 3 月 [ref]

关键分离：把推理分成两层——

  • 语义推理（神经网络）：只在叶子节点处理 ≤K 长度的子问题
  • 控制流（符号系统）：Split, Map, Filter, Reduce 等预验证的 combinators

递归通过 Y-combinator 表达：

1
2
3
4
lambda-RLM ≡ fix(λf. λP.
  if |P| ≤ τ* then M(P)           -- 叶子：直接调 LLM
  else Reduce(⊕, Map(λp. f p, Split(P, k*)))  -- 递归
)

所有控制参数（分割数 k*、叶子阈值 τ*、组合算子 ⊕）由确定性 planner 在执行前计算好。LLM 不写任何控制代码。

形式化保证

性质 普通 RLM lambda-RLM
终止性 无保证（LLM 可能生成无限循环） 构造性证明（rank 严格递减）
成本上界 不可预测 T(n) ≤ nk*/τ* · C(τ*) + composition
准确率衰减 不可分析 多项式衰减 Ω(n^{-c}) vs Direct 的指数衰减 Θ(ρ^{n/K})
最优分割 无 k*=2（闭式解）

准确率的多项式 vs 指数衰减是核心理论贡献：随着输入变长，lambda-RLM 的劣化速度远慢于直接推理。

实验核心数字

Summary figure

29/36 model-task 组合中 lambda-RLM 胜出（81%）。

按模型规模：

  • Weak（7-8B）：100% 胜率（+21.9pp 平均提升）
  • Medium（22-32B）：92% 胜率
  • Strong（235B+）：50% 胜率（强模型的自由代码生成有时更灵活）

按任务复杂度：

  • O(n²) 的 OOL-Pairs：+28.6pp，6.2x 加速（quadratic cross-product 由符号系统处理）
  • O(1) 的 S-NIAH：+19.7pp
  • CodeQA（最自由的任务）：+10.8pp（RLM 在 CodeQA 上 4/9 胜出，因为需要 creative code-specific strategies）

延迟：lambda-RLM 一致性地比 RLM 快 3-6x（单次执行 vs 5-12 轮 REPL 循环）。

和我之前探索的关联

  1. 约束满足的 2x2 框架：初看 lambda-RLM 似乎是一个实例——"成对交互"通过 Cross combinator 实现，"迭代"通过 fix combinator（Y-combinator）实现。但仔细审视后这个连接有问题：lambda-RLM 的 MAP 操作假设子问题独立（各子问题不互相约束），这和约束满足中"成对交互"的核心需求——变量之间的约束传播——完全不同。Sudoku 之所以难，恰恰是因为变量不独立。lambda-RLM 更像是 divide-and-conquer（适合可分解任务），而非约束传播（适合紧耦合任务）。这是 2x2 框架的一个重要边界条件：可迭代的成对交互解决紧耦合问题，可迭代的分治解决可分解问题，两者的适用范围不同。

  2. SSM-Attention 互补框架：lambda-RLM 实质上是一个系统级的 “压缩-检索” 分离。叶子节点的 LLM 调用 = 精确检索/推理（Attention 擅长），Split + Reduce 的递归结构 = 信息压缩和聚合（类似 SSM 的功能）。这是在系统架构层面实现了类似的互补。

  3. Post-training 天花板：lambda-RLM 不依赖任何训练——它是纯 inference-time 的 scaffolding。这意味着它的效果不受 post-training 五维度的约束。但它受到 base model 的 leaf-level 能力约束（维度五的 behavior repertoire 仍然适用）。

Normal RLM 胜出的场景值得注意

7 个 RLM 胜出的 cell 全部涉及强 coding model（405B、Codestral）或 CodeQA 任务。这些场景下，LLM 能写出 creative strategies（多轮阅读+回溯、函数级分块、自适应 batch）。

启示：fixed combinator library 是一个"安全下界"——它保证可靠的基线性能，但可能无法表达某些 task-specific 的高级策略。对于弱模型，这个下界远高于它们自己能达到的水平；对于强模型，下界有时反而是限制。

局限性

  1. Combinator library 的表达力：当前只有 8 个 combinators。论文承认这不是 exhaustive 的，但 extensibility 的验证不够。
  2. 任务检测的单点故障：task type 由 LLM 单次调用判断。如果判断错误，后续所有 combinator 选择都会错。
  3. 只测了 long-context 任务：没有测试 short-context 场景。Direct inference 在 short context 下显然更优。
  4. 没有和 RAG 对比：RAG 是 long-context 的另一条常用路线，缺少这个对比使得结论不够完整。