Dream-RSI: Recursive Self-Improvement through Evolving Worlds

术语速查

所有术语用同一个贯穿全文的例子解释：任务 = 自动写出一个比 sklearn 更快的 Lasso solver Python 程序。

研究动机

• 问题：想要自动发现高质量算法（RSI），需要跑成千上万次"写代码→测试→改进"循环。怎么搜索才不浪费算力？这个"怎么搜索"的策略本身很难优化——测一个搜索策略的好坏，要等完整跑完一轮才知道，代价巨大。
• 现有方法的问题：
  • 固定策略（AlphaEvolve、SimpleTES）：搜索策略写死，第 5 轮和第 1 轮用一样的策略，学不到任何东西
  • 在线优化策略（EvoX）：要测试新策略就得真的跑一整轮，一轮可能要几百次 LLM 调用，太贵
• 核心 insight：历史树已经把所有执行结果存好了——测试新策略根本不用重新跑，直接在历史树上"走一遍"就能得到分数。这把"测试策略"的成本从几百次 LLM 调用降到零。

核心方法（逐步拆解）

Step 1：一轮 Online Exploration 长什么样

当前 policy π（一段 Python 代码）控制 coding agent 跑任务，产出一棵 discovery tree：

# policy 代码示例（Round 1 初始策略）
class OptimalPolicy:
    def solve(self, question, budget=None):
        # 并行开 10 个全新方向（从 root 出发）
        roots = question.legal_roots()[:10]
        question.probe_batch(roots)          # 触发 10 次 coding agent 调用
        # 对每个方向，继续 refine 最多 11 次
        for step in range(11):
            leaves = question.legal_actions()
            question.probe_batch(leaves)

每次 probe_batch 在 online 阶段 = 真实调用 coding agent（LLM 写代码 + 评测器计时），结果存入树节点。

跑完后产出：

T₁（Round 1 的树）：
Root
├── Node A: 代码=LARS算法,        分数=3500ms, 文件快照已存
│   └── Node A1: 代码=LARS+warmstart, 分数=3100ms, 文件快照已存
│       └── Node A2: 代码=LARS+调参,   分数=2900ms, 文件快照已存
├── Node B: 代码=坐标下降,        分数=4200ms, 文件快照已存
│   └── Node B1: 代码=坐标下降+向量化, 分数=3800ms, 文件快照已存
└── Node C: 代码=active set,      分数=2600ms, 文件快照已存
    └── Node C1: 代码=active set+KKT, 分数=2200ms ← 本轮最优

Step 2：Dreaming——在历史树上测试新 policy

Online 结束，T₁ 存入历史池 H₁ = {T₁}。现在 policy developer（LLM）想测试一个新 policy："先并行看 3 个 branch，分差的立刻剪掉"。

把这个候选 policy 代码在 T₁ 上 replay：

# replay 时 probe_batch = 读树里存好的结果，不调用任何 LLM
question.probe_batch([A, B, C])   → 立刻返回 3500, 4200, 2600（从 T₁ 读出）
# policy 看 B 最差，剪掉；继续 A 和 C
question.probe_batch([A1, C1])    → 立刻返回 3100, 2200（从 T₁ 读出）
# policy 决定停止

replay score = 最优(2200ms换算分数) - 成本惩罚(用了5个节点) + 并发奖励

整个过程：0 次 LLM 调用，0 次代码执行，耗时毫秒级。

policy developer 可以这样测试几十个候选 policy 变体，选出平均 replay 分最高的，作为 π₂ 用于下一轮 online。

Step 3：完整多轮循环

flowchart LR
  A["Online"] -->|"new tree T_t"| B["History Pool"]
  B -->|"replay all trees"| C["Dreaming"]
  C -->|"pick best"| D["New Policy"]
  D -->|"next round"| A
          

历史树越积越多 → replay 的参考越来越丰富 → policy 改进信号越来越准。

Step 4：Replay 打分公式

最终选出在所有历史树平均 replay 分最高的 policy，保证不比当前策略差。

三类组件各自的 prompt / 代码

主要实验结果

对比：Dream-RSI（每轮更新 policy）vs. Recursive Fixed Exploration（policy 固定不变），其余完全相同。

算法工程 — Lasso Regularization Path（5 轮）

Dream-RSI 用 SimpleTES 约 1/162 的调用次数达到更好性能。同样用 Gemini-3.1-Pro，Dream-RSI 比 Fixed 少用 42% 调用（550→317），且结果更好（3587→2931ms）。

数学优化 — 三个问题（10 轮）

GPU Kernel 工程 — KernelBench

深入分析

为什么不直接把历史总结成文字注入 prompt？

对比实验：把历史树压缩成"方向性建议"文字，注入 coding agent 的 prompt（"之前试过 LARS，建议探索 active set 方向"）。结果：这样反而更差，在 Fixed 和 Dream-RSI 两种范式下均不如不注入。

原因：文字建议会过度缩小搜索空间，让 agent 都往同一个方向走，失去多样性。而 replay 不告诉 agent 往哪走——它只改变 policy 决定"何时停、怎么分配并发"，agent 本身仍自由探索。

Policy 演化行为（ConvDiv 案例，9 轮）

Policy 呈现自适应模式——不是固定策略，而是根据当前进展动态调整：

1. E0→E4：性能快速提升（0.427→1.488），policy 主动减少 attempt 数（110→80→50），省算力
2. E4→E5：性能停滞（1.488→1.499），policy 察觉瓶颈，增加 attempt 数（50→92）
3. E6→E8：重新突破（1.770→1.898），policy 再次优化并发策略

局限与展望

• 已知局限：
  • Replay simulator 只覆盖历史上真正跑过的节点——历史探索质量差，simulator 参考价值有限
  • Policy 想探索历史树从未走过的方向，replay 给不了反馈，只能等下一次 online 才知道
  • 每轮 online 仍需完整执行成本，节省来自减少后续轮次总量，不是单轮加速
  • AutoCorrelation 任务上与 SimpleTES 仍有差距
• 研究趋势：Dream-RSI 把 RSI 拆成两层——底层 coding agent（不变）+ 上层 exploration policy（自我改进）。类比 Dreamer RL：想象里训练 policy，现实里部署。未来方向：更多 rounds 继续积累历史；用更强 policy developer LLM；与 harness-level token 优化（如 SoL-Pi）结合。

对 policy π^m 在历史树 T_i 上的 replay：

V_i^m = max_{v ∈ revealed_nodes} score(v)   # 最优解分数
       - β₁ × N_i^m                          # 惩罚 reveal 节点总数
       + β₂ × N_i^m / max(1, 轮数)           # 奖励并发（每轮 reveal 越多越好）

policy 总分 = 对所有历史树的平均 V_i^m