長時程任務的環境與 judge 設計

080Rayan Garg（Theta Software）21:142026-08-01 上架

Rethinking Environments for Long-Horizon Work — Rayan Garg, Theta Software

Theta Software 的 CEO Rayan Garg 與 CTO 合講：long horizon 到底怎麼量、RL 環境的複雜度與模糊性怎麼設計、寫不出確定性驗證器時 judge 與 rubric 怎麼用，最後檢視金融類 benchmark 的缺口。

這場講了什麼

• long horizon 是連續尺度：它比較像一個 scalar metric，適合比較兩個任務哪個比較長，很難切成「是」或「不是」。一年前算長的任務，今天未必還算。
• 人類工時與模型單位要並用：METR 以人類做同一件事要多久為準，模型端則看 token、步數、tool call 數。兩邊各有雜訊，只看一邊得不到完整的圖像。
• 環境複雜度看三件事：要協調多少工具、過程中環境狀態變了多少、起始資訊有多模糊。把不相干的任務串起來只是人工拉長，真正的長時程是早期的決定會影響後面的決定。
• verifier 改用 judge 與 rubric：軟體這類經濟價值高的工作，很多寫不出確定性驗證器，要靠 judge 看環境的最終狀態與整段軌跡，同時抓 reward hacking。
• judge 本身也要是 agent：它要能用跟受訓 agent 一樣的環境工具，但權限要唯讀；軌跡太長不能直接塞進 context，要整理成可以查詢的形式。
• 現有金融 benchmark 偏短又偏窄：Rayan 指出幾個主要 benchmark 的平均人類工時遠低於 METR 定義的長時程，已經相當飽和，涵蓋的範圍也窄。

影片從哪一段開始看16 段

1. 00:12開場與自我介紹兩位共同創辦人上台，一位是 CTO，另一位是 CEO Rayan；Rayan 之前在 Deep Silicon 當 founding engineer，做 ternary model 的研究。今天談長時程任務裡的 RL 環境。
2. 00:45long horizon 是連續尺度agent 能自主工作的時間增長得很快，「長」的定義跟著一直變，所以它只適合拿來比較任務的相對長短。
3. 01:52人類時間尺度METR 用人類完成任務的時間當基準，例如模型在 50% 門檻達到 16 小時，代表它能以 50% 成功率完成人類要花 16 小時的任務。
4. 02:23模型端的單位token、步數、tool call 數會隨模型與 harness 變動，雜訊很大；但耗用的 token 量很能說明任務對自主 agent 有多難，例如要靠 compaction 撐過長軌跡。
5. 04:36兩種尺度要並用人類覺得耗時的事（例如整理 Excel 格式）模型寫個 Python script 就解決；人類工時的量法也影響很大，任務愈接近頂尖 10%、1%、0.1% 的人才做得到，估計愈不準，所以兩種指標都要看。
6. 06:43環境複雜度：工具協調從只讀一份或一組檔案的低複雜度世界，變成要在 Grafana、GitHub、AWS CloudWatch、資料庫之間搬資訊。
7. 07:49狀態變化：平行與序列拆給 sub-agent 分析大型程式碼庫容易平行；要用 dashboard 或 log 的序列任務裡，一次錯誤的查詢會一路連鎖到後面的步驟。
8. 09:15模糊性起始資訊不完整才貼近人類真正的工作，也才測得到探索能力；代價是可能的路徑與正確答案變多，標準化評估跟著變難。
9. 10:02為什麼 verifier 最難CTO 接手談 verifier：早期 RL 集中在數學與資料結構題這類好驗證的領域，現在要面對無法靠測試或證明判斷對錯的工作，於是引入 judge model。
10. 11:37用 judge 與 rubric 的原因很多問題的確定性驗證器不實際、太脆弱或根本寫不出來；judge 也要看軌跡，抓跳出 sandbox、偷看隱藏測試這類 reward hacking。
11. 12:42別把路徑框太死拿參考答案或範例軌跡逐步比對，在開放式任務上行不通，還會壓縮 agent 探索的空間。
12. 13:34judge 與 agent 共用 harness以部署失敗的任務為例，judge 要能查 GitHub 與 AWS 的紀錄確認修好了沒，但權限要唯讀，免得事後誤動環境。
13. 15:32judge 本身要是 agent長軌跡不能整串塞進 context，要存進資料庫、拆成階段、用 sub-agent 補充資訊，讓軌跡可以查詢、找得到失敗點。
14. 16:33可學習性與 rubric 密度reward signal 的密度主要來自 rubric；rubric 塞得太密，在前沿問題上 judge 很難一致地套用；任務分佈與底層資料也要顧，不然算力會浪費在模型學不到的題目上。
15. 17:21rubric 模式與 QA確定性驗證器沒死，可以跟 judge 搭配；也可以在評估時動態產生 rubric 給部分分數。接著 Rayan 說明每份 rubric 都要跑 gold、no-op 等測試，AI 參與愈多，測試要愈多。
16. 18:26金融 benchmark 的缺口Rayan 檢視 GDPval、BankerToolBench、APEX-Agents：平均人類工時遠低於 METR 的長時程標準、已經相當飽和、範圍集中在 Excel 或投資銀行，reward signal 也不夠細。

值得記的話5 句

• long horizon is really kind of a scalar metric.long horizon 其實比較像一個連續尺度的指標01:18

• all long horizon tasks aren't equal.長時程任務並不都一樣07:49

• a bad early query or a misread can cascade into these downstream steps早期一個糟糕的查詢或一次讀錯，會一路連鎖影響後面的步驟08:58

• we can't just run a Python script or run test cases or write a proof我們沒辦法只跑個 Python script、跑測試或寫證明就判斷對錯10:49

• we need to make the trajectory itself queryable.我們得讓軌跡本身可以被查詢16:02

名詞與人物8 個

Rayan Garg

Theta Software 的共同創辦人兼 CEO，負責收尾的 rubric 測試與金融 benchmark 那一段

Theta Software

Rayan 與 CTO 共同創辦的公司，這場談它做長時程任務環境與資料的方法

METR

這場引用的時間視野 benchmark 出自這裡，以人類完成任務所需的時間衡量模型

judge model（critic model）

沒有確定性驗證器時，用來判斷環境最終狀態與軌跡是否正確、並給 reward 的模型

rubric

judge 評分用的準則，每個 criteria 底下再分多個 sub-criteria

reward hacking

agent 鑽漏洞拿分，例如跳出 sandbox，或看到不該看的隱藏測試

gold 與 no-op variants

驗證 rubric 的基本測試，Rayan 說不管怎樣都該對 verifier 做

GDPval、BankerToolBench、APEX-Agents

Rayan 檢視的三個以金融為主的 benchmark

提到但沒有展開

• 談 token 數的雜訊時舉的例子：Codex 系列模型通常被認為比 Claude 的模型省 token，所以一個任務在 GPT 模型上用掉 500,000 token，換到 Claude 模型上要實際跑過才知道。
• Rayan 收尾給了自家金融資料的數字：50 個任務的樣本，人類平均要 15 小時完成一題；模型要花很長時間做，在各個金融領域仍然吃力。

評估研究模型Agent

在 YouTube 看原片 ↗