【2026 最新】Dream-RSI 是什麼？20 棵 Trace 零重跑 Replay Simulator

2026 年 9 月，Dream-RSI arXiv v1 正式發布；但如果你以為模型正在偷偷重訓自己的權重，方向就看反了。它真正改的是模型外面的探索 policy：下一輪該開哪條分支、同時跑幾個嘗試、何時停手。Dream-RSI 論文把這層控制器寫成程式，再用舊的 discovery tree 離線回放、挑出新版。

這篇專為完全沒有技術背景的讀者寫：先用研究主管分配人力的比喻講懂 Dream-RSI，再把 20 棵合成 Agent trace tree 做成一個零模型重跑的 Replay Simulator。你會看到一個 policy 在調整集看似完勝，到了 holdout 卻翻車，也會知道什麼情況才有資格把它送進下一輪 fresh online rollout。

先說結論：Dream-RSI 是探索主管自我改版，不是模型大腦重訓

🧭 記憶把手：Dream-RSI ＝舊探索樹（世界）＋離線重播（夢）＋新版搜尋 policy（下一輪）。

• 有改進：探索控制器的 branch、parallelism 與 stopping rule 可以被另一個 Agent 改寫。
• 沒改權重：論文固定 discovery agent、policy-development agent、evaluator 與執行介面；變動的是 exploration-policy code。
• 不是預知：replay 只能揭露歷史樹已記錄的 child，不能生成沒走過的結果。
• 不是零成本：離線階段不新增 discovery-agent／evaluator 執行，仍有政策開發 LLM、CPU、I/O 與時間；下一輪 online exploration 也會重新產生成本。

把它放回完整系統會更清楚：AI Agent Harness負責工具、記憶、評估與控制流程；Dream-RSI 改的是其中一小塊「怎麼分配探索資源」。這是一種有邊界的 harness-level self-improvement，與模型權重層的自我改進不是同一件事。

Dream-RSI 真正改的是哪三個旋鈕？

想像四組研究員同時找更快的演算法。研究員本身沒換人，評審標準也沒變；自我改版的是研究主管。它主要轉三個旋鈕：

1. Branching｜下一筆算力投哪裡？ 從 root 開全新方向，或延伸目前某個 leaf。操作上，policy 只從當下合法候選挑節點；驗收看它是否真的探索多個 branch，而非一直鑽同一路徑。
2. Parallelism｜一回合同時送幾個？ 最多送到 worker 上限 W。這代表批次排程，不等於實測牆鐘時間會線性加速；驗收應分開記 decision rounds、calls 與真實 latency。
3. Stopping｜何時不要再燒？ 本文 toy policy 有 success、patience 與 cost-budget 三種模式；官方形式化則以空 batch／round limit（replay 另含 tree exhausted）終止。兩者都應同時看 reward 與 cost，不能只追最高分。

這與 AlphaEvolve 的層級也不同：AlphaEvolve 主要演化被搜尋的程式；Dream-RSI 則站在上面，改「下一步讓誰去找」。若想把 trace、eval 與停止條件接成一個可維護系統，可搭配建立 Agent Harness 實作指南。

第一步：把 20 棵合成 discovery-tree traces 編碼成 JSON

官方定義的 discovery tree，root 是初始工作區；每個非 root node 對應一次 attempt，保存產物、評估診斷與分數，並有一個主要 parent。為了讓 replay 的資料邊界看得見，我們建立 20 棵合成樹，每棵 29 個節點：root 有 4 個 child，depth-1／depth-2 node 各有 2 個 child，depth-3 是 leaf。總計 580 個節點，其中 560 筆非 root 記錄都有 branch、outcome 與 cost。

{
  "trace_id": "trace-01",
  "split": "tune",
  "root_id": "trace-01-root",
  "nodes": [{
    "id": "trace-01-b1-d1",
    "parent_id": "trace-01-root",
    "branch_id": "b1",
    "action": "refactor",
    "observable": {"hint": 0.3278, "novelty": 0.3729},
    "outcome": {"reward": 0.3828, "success": false},
    "cost": {"units": 0.8198, "calls": 1},
    "children": ["trace-01-b1-p0-d2", "trace-01-b1-p1-d2"]
  }]
}

JSON 裡雖然存有所有已記錄結果，policy 在選擇前只能拿到 id、parent_id、branch_id、depth、action、hint、novelty 與已知 cost，另可讀先前已觀測 parent 的結果；未揭露 child 的 reward、success 與 status 必須等選中後才出現，duration 則留在原始 log 供稽核／統計，不會透過 ObservedNode 提供給 policy。CandidateView 讓本文內建 policy 在選擇前讀不到答案；這是軟體介面邊界，不是惡意 policy 的安全沙箱。

本文驗收設計：以整棵樹為最小切分單位

20 棵樹先分成 12 棵 tune、8 棵 holdout，trace ID 與 node ID 完全不重疊。在這種 history-conditioned policy 設計裡，若把同一棵樹的上半部放 tune、下半部放 holdout，shared prefix 與 branch signal 會跨 split，形成結構性洩漏風險。這和建立 AI Evals時避免把高度相似題放進訓練與測試兩邊，是同一個原則。

第二步：寫一個零模型重跑的 Replay Simulator

Replay 的重點不是「跑得快」，而是outcome transition 只查詢由 JSON 載入的 logged node，不呼叫模型或 evaluator。每次從 root 重設，root 的 child 成為 frontier；policy 先鎖定這一回合要選的整批候選，之後才揭露結果，避免第 2 個 worker 偷看第 1 個 worker 剛回來的答案。

def replay(tree, policy):
    by_id = index_nodes(tree.nodes)
    observed = {tree.root_id: by_id[tree.root_id]}
    frontier = public_stubs(by_id[tree.root_id].children)
    spent, calls, rounds = 0, 0, 0

    while (frontier and rounds < policy.max_rounds
           and not policy.should_stop(observed, spent)):
        batch = policy.choose(frontier, max_items=policy.workers)
        if not batch:
            break
        assert all(x.parent_id in observed for x in batch)
        assert sum(x.cost for x in batch) <= policy.remaining_budget(spent)

        # 先決策，後揭露；這一行只是讀舊 JSON，不呼叫模型
        revealed = [tree.logged_lookup(x.id) for x in batch]
        spent += sum(x.cost for x in batch)
        calls += len(batch)
        observed.update({x.id: x for x in revealed})
        frontier = update_frontier(frontier, revealed)
        rounds += 1

    reward = max(x.reward for x in observed.values())
    success = any(x.success for x in observed.values())
    utility = reward + 0.12*success - 0.035*spent \
              + 0.012*(calls / max(1, rounds))
    return reward, success, spent, utility, rounds

這段教學偽代碼刻意省略型別、壞檔處理與惡意 policy 隔離；真正驗收至少要 assert 樹是無環、parent 已觀測、選擇都在 frontier、cost 精確加總、結果在選中前不可見。我們的 dependency-free Python 3 測試版以 AST 檢查確認 generate_data.py 與 replay.py 未匯入網路、模型 SDK 或 subprocess；這不是惡意 policy 的安全沙箱。10 項 invariant tests 全數通過。

官方 Replay 與這個玩具介面有一個重要差別

論文的 policy 選 root 或目前已觀測的 leaf，replay 再揭露它在歷史中的 recorded continuation；我們讓 policy 直接選 logged frontier child，方便新手檢查 support。兩者共同點是都不產生歷史樹之外的新 outcome，但不能因此宣稱玩具程式重現了官方實作。

第三步：讓 branching、parallelism、stopping 真的改變軌跡

只改 policy 名稱沒有用。這次把 5 種 ranker（深挖、廣搜、看 hint、平衡、利用）乘上 1／2／4 workers、2 種 budget、3 種停止模式，共得到 90 個固定候選。每個候選都在同一批 12 棵 tune tree 上重播，依以下教學 utility 排名：

utility = best_reward
          + 0.12 * success
          - 0.035 * cost_units
          + 0.012 * (calls / max(1, decision_rounds))

最後一項只是「每回合平均排了幾筆」的 proxy，不是 wall-clock speedup。四個係數也是教學選擇，不是自然定律；換一組風險或成本偏好，優勝者可能翻轉。正確操作是先把 objective 與 tie-break 寫死，再封存 holdout，不能看到結果後補規則。

實驗結果：tune 內穩定，跨分布仍可能翻車

90 個候選中有 4 個同為 tune utility co-winner；預先固定的 cost、worker 數與名稱 tie-break 選出一個 serial policy。它在 12 棵 tune tree 的平均 utility 是 1.0044、成功率 100%，對 8 棵 holdout 評估後，utility 降到 0.4956、成功率 0%；holdout 最高 utility 則由另外 3 個 co-winners 共享。逐次拿掉一棵 tune tree 時，依同一 tie-break 選出的 winner 12／12 次相同，仍擋不住分布偏移。

這個落差是我們刻意反轉 holdout hint 關係做出的分布偏移壓力測試，不能拿來估計 Dream-RSI 的真實成效，也不是一般選擇過擬合的證據。selection key 只讀 tune；把所有 holdout outcome 改掉的 mutation test 顯示優勝者不變。不過同一份診斷報表會替全 grid 計算 holdout 指標，所以這個玩具 run 不是人類盲測或「物理封存、只開一次」的正式流程。這個刻意設計的案例只示範：whole-tree split 與 tune-only selection 能在此處揭露跨分布失效；同一分布內很穩，不代表跨分布可靠。接到真實 Agent 時仍要另做 fresh online rollout，不能拿圖上的數字當產品 benchmark。

Dream-RSI Replay 最聰明、也最危險的假設

官方專案頁把累積 history 稱為它已抵達之搜尋空間的 exact simulator。這句話要加完整邊界：它可以精確重播已實現的 tree，不是環境的因果模型。舊 policy 沒開過的 branch，它看不到；同一 state 下模型本來可能抽到另一個 child，它也估不到。

更棘手的是，Agent 往往會讀到前面 proposal、兄弟 branch、score 與 error。若新版 policy 改了順序或 batching，真實模型看到的 context 也可能改變；但離線 replay 還是交回舊順序下的 recorded child。因此，若把 replay score 解讀成新 rollout 的反事實估計，arXiv v1 未提供無偏性證明或校準實驗；這是本文的風險判讀。它也不同於會學習 dynamics、在 latent state 想像新 transition 的 Dreamer world model。

論文把現行 policy 一起放入候選，所以在同一份固定 replay history上，挑出的平均分不會比現行版本低；這是 in-sample selection guarantee，不是下一次 stochastic rollout 保證。arXiv v1 也未描述把獨立 replay holdout 專門留給 policy selection。本文的 12／8 切分，是針對這個風險加上的簡化示意 gate，不是論文原有結果，也沒有重現論文會反覆改寫 policy 的完整 adaptive-selection 流程。

論文結果該怎麼讀，才不會被「RSI」帶走？

Dream-RSI v1 報告 8 個可由機器給單一分數的任務，跨演算法工程、數學最佳化與 GPU kernel 三類。它確實展示了：在部分設定中，改探索控制器能用較少 discovery-agent calls 達到相近或更好的結果。以 Lasso 的同-backbone fixed-exploration 對照來看，Pro／Flash 的 discovery-call reduction 分別約 1.74×／1.70×；KernelBench 另在單一公開軌跡的選定 operating points 報告 VGG16 2.43×、LayerNorm 1.79×。162× 與數學題的 >50× 則是跨系統／不同模型的 generation-count 比較，不能全當成同模型公平決賽。

也不是每題都贏：論文中的 Circle Packing 與 fixed policy 平手，Autocorrelation 略差；KernelBench 實驗涵蓋 4 個 tasks。我們檢查的 arXiv v1 未報告獨立多 seed、confidence interval、error bar，也未報告 cross-task controller-transfer 實驗。公平結論是「這個 meta-exploration 方法值得追蹤」，不是「通用 AI 已能無界自我升級」。若想延伸理解外圈如何改內圈，可再讀Harness 自動最佳化與Loop Engineering。

本文額外驗收 Gate（非論文原流程）：只讓勝出 policy 進一輪 fresh rollout

1. 怕 holdout 被偷用？先封存。 在任何 policy 調整前，以整棵 tree 切分並寫下 hash；只有選擇規則凍結後才讀 holdout。驗收：trace/node 交集必須是 0。
2. 怕挑到偶然高分？先定門檻。 操作上預先寫下 baseline、最低 reward、最高 cost 與容許落差，不用 holdout 反覆調參。驗收：失敗就退回現行 policy，而不是換一個剛好贏的 holdout oracle。
3. 怕 replay 騙你？先跑一輪 challenger。 固定模型、evaluator、budget 與 seed protocol，進行一輪 fresh online rollout。驗收：比較預註冊指標並保留完整新 trace；這只能當 falsification／smoke gate，不能證明普遍有效。
4. 怕新資料污染？分開記帳。 先完成這輪評估，再把新 tree 加進下一代 history；不能倒回來重寫這輪結論。驗收：每一代 policy、history hash 與 rollout 結果都可追溯。

若把本文的純離線 toy 接到真實 Agent，fresh rollout 才會新增 discovery-agent／evaluator calls；對官方 Dream-RSI 而言，每一輪 online exploration 本來就有這筆成本，離線階段也已花政策開發 LLM、CPU、I/O 與時間。若一輪 fresh rollout 沒改善，這是一筆反證訊號；可能來自 replay ranking 外部效度不足、隨機變異、task shift、評估噪音或實作差異，單次結果不能辨認原因。這種 challenger gate 比不限輪次自動部署更保守，也更容易回滾與稽核；完整練習可放進 AlphaLab AI 課程與實作路線的 eval 與 observability 模組。

截至 2026 年 9 月 17 日，官方程式碼到哪裡？

我們重新檢查了 Dream-RSI 官方 GitHub 的 main commit 4149ea9、branch、tag 與 release。README 的 Release Plan 仍把 discovered programs、full codebase、reproduction scripts 標為「Being prepared」；repository 目前有 README、論文、圖、引用資訊等資產，未見 controller runtime 與完整 reproduction scripts，也沒有 tag 或 release。論文附錄則已提供 prompt 與 Lasso solver listing，因此精準說法是「完整重現資產尚待發布」，不是「什麼 code 都沒有」。

這個狀態可能隨時改變，日期很重要。本文不假裝重現官方數字，也不把合成 simulator 當作官方實作；它只示範一個簡化心智模型：logged tree 可以拿來比較排程，但 support、反事實有效性與 holdout 仍是硬邊界。

常見問題 FAQ

1. Dream-RSI 會修改模型權重嗎？

不會。論文固定底層 agents、evaluator 與介面，改寫的是 exploration-policy code。把完整 model＋harness 視為 deployed policy 時，可以叫 harness-level self-improvement；不能說成權重自我重訓。

2. 「零重跑」代表完全零成本嗎？

不是。它只表示離線 replay 不重新呼叫 discovery agent 與 evaluator。政策開發 LLM、讀取 history、CPU／記憶體與 wall-clock 仍有成本，下一輪 online rollout 更不是免費。

3. Replay 能預測舊樹沒出現的 branch 嗎？

不能。它只能重新排序、分組、節選與停止已記錄的 support；logger 沒探索的路沒有 outcome 可查。想知道新 branch 會怎樣，仍要 online 執行。

4. Dream-RSI 的「Dream」就是 Dreamer world model 嗎？

不是。Dreamer 學 dynamics 並在 latent model 裡產生想像軌跡；Dream-RSI 回放的是 realized discovery tree，不會生成 unseen transition。「夢」是很有記憶點的比喻，不是同一種技術。

5. 論文能保證下一輪 policy 一定進步嗎？

不能。現行 policy 在候選集中，所以固定 history 的最佳 replay score 不會較低；新 online rollout 會有隨機性、分布偏移與 context 改變，仍可能退步。

6. 為什麼不能把同一棵 tree 的 nodes 隨機切分？

因為有結構性洩漏風險。在本文的相依樹資料裡，同一 tree 的 prefix、branch signal 與局部結果高度相關；node-level random split 會把這些訊號分到兩邊，因此本文以完整 trace tree 為最小切分單位。

7. workers 設成 4，就會快 4 倍嗎？

不一定。在本文 toy simulator 裡，workers=4 只代表每個 decision round 最多排 4 筆 logged lookup；官方 W 並不固定為 4。真實時間還受 straggler、rate limit、GPU contention、失敗重跑與同步成本影響，必須另外量 wall-clock。

8. 現在可以直接部署官方 Dream-RSI 嗎？

目前不能靠官方 repo 完整重現。截至 2026 年 9 月 17 日，README 仍說完整 codebase 與 reproduction scripts 正在準備。你可以先實作本文的 logged-tree replay 與 holdout gate，但不要冒充官方系統。

給新手的 5 個帶走重點

1. Dream-RSI 改搜尋控制器，不改模型權重。
2. Replay 省的是重跑舊探索的 execution，不是所有運算與金錢成本。
3. 歷史樹是 logged world，不是能想像未見結果的 world model。
4. 在本文這種相依 tree 設計裡，調整集與 holdout 應按完整 tree 切開，holdout 不能拿來重選政策。
5. 本文建議的最後一關是一輪預先定義指標的 fresh online challenger；一次 pilot 仍不能證明普遍有效。