TTRL：沒有標註答案時，用多數投票當獎勵來做強化學習

TTRL 要解的是獎勵從哪裡來的問題

一般 RLVR 流程需要 ground-truth 答案才能算出 reward，這使得訓練資料必須是有標註的。TTRL 針對的是推論階段：手上只有測試題，沒有答案，卻仍想讓模型在這些題目上更新參數。README 把這個核心困難寫得很直接，reward estimation during inference while not having access to ground-truth information。

它的觀察是，測試時擴展裡常見的多數投票本身就能當獎勵訊號。同一題取樣多次，模型自己最常給出的那個答案被視為偽標籤，與多數一致的軌跡得到正獎勵，偏離的被壓低。這不是新發明的評估方法，而是把既有方法挪去當訓練訊號。

適用對象因此相當明確：做數學與可驗證推理的研究者，需要在不確定標籤的測試集上做線上適應。它不是給一般應用開發者隨手加進推論管線的元件。

多數投票獎勵的實作位置在 reward function

README 的 pseudo-code 段落說明，TTRL 可以透過修改 reward function 快速實作，並指向 figs/ttrl_reward.png 的程式碼片段。也就是說，整體訓練迴圈沿用既有 RL 框架，變動集中在獎勵計算這一步。

資料流大致是：一題 prompt 交給 policy 取樣 n 條回應，解析每條回應的最終答案，統計出現次數，把多數答案當作該題的偽標籤，再逐條給出獎勵。這個獎勵進入 policy gradient 更新。

這裡有個容易忽略的設計後果：獎勵的解析依賴答案格式可被抽取與正規化。程式碼片段本身在 README 中僅以圖片呈現，文字版並未給出，因此具體的答案抽取規則、n 的預設值、多數並列時如何處理，都無法從這份材料確認，需要直接讀 repo 中的實作。

另一個副作用是，這種獎勵會獎勵與多數一致的推理路徑，而非獎勵正確性。當模型整體偏誤時，多數投票會把偏誤固化。

安裝路徑與 verl 的耦合

取得程式碼與環境的步驟，README 給得很具體：

git clone https://github.com/PRIME-RL/TTRL.git cd TTRL/verl conda create -n ttrl python==3.10 conda activate ttrl bash scripts/install_ttrl_deps.sh pip install -e .

注意 cd 進的是 TTRL/verl，而不是 repo 根目錄。TTRL 的實作寄生在 verl 這套 RL 訓練框架裡，README 也直接寫明 for further details regarding the code, please refer to the verl documentation。這代表除錯時你面對的是兩層程式碼：TTRL 的獎勵邏輯，以及 verl 的訓練與分散式排程。

資料格式上，README 指向 verl/data/preprocess.py 把 JSON 轉成 Parquet 才能餵進訓練。多個模型與 benchmark 的執行腳本放在 verl/examples/ttrl 目錄。

版本相容性有一條明確線索：2025-08-17 的公告說在 verl v0.4.1 上只要設定 +ttrl.enable=True 就能啟用。但 repo 的 releases 列表列出的是 verl (v2.0.0) 與 OpenRLHF (v1.0.0)，與該公告提到的 v0.4.1 不一致。實際該用哪個版本，得看 repo 當下的相依檔案，不能只憑公告。

重現 AIME 2024 的指令與硬體前提

README 提供的重現指令只有一行：

bash examples/ttrl/Qwen2.5/aime.sh

對應的模型是 Qwen-2.5-Math-7B，基準是 AIME 2024。硬體前提寫在 Getting Started 段落末尾，所有實驗都在 8 x NVIDIA A100 80GB 上完成。這不是可以縮小規模隨意嘗試的設定，7B 模型加上 n 次取樣與 RL 更新，記憶體與吞吐需求都落在多卡範圍。

README 另外揭露了一件對判讀結果很重要的事：他們用預覽版程式碼跑了三次獨立實驗，兩次得到 pass@1 (greedy) 為 43.3，一次為 46.7。這個變異幅度不小，說明單次跑出來的數字不足以當作穩定結論。

主要結果中提到的數字，Qwen-2.5-Math-7B 在 AIME 2024 上 pass@1 提升約 211%，以及 TTRL 的表現會超過初始模型的 maj@n 上限、接近用 ground-truth 直接訓練的模型。這些是論文與 README 的宣稱，我沒有重跑驗證。

什麼情況下多數投票獎勵會失效

這套方法的前提是題目存在一個可被多數取樣收斂的答案。數學題通常滿足，開放式生成、需要主觀評分、或答案形式自由到無法正規化的任務則不滿足。在後者，多數投票統計的是表述習慣而不是正確性。

第二個失效模式是難度分佈。若某題對當前模型太難，n 次取樣可能全錯或答案極度分散，此時偽標籤沒有意義，訓練會把雜訊當訊號。反之若題目太簡單，取樣幾乎全部一致，獎勵訊號趨近常數，梯度貢獻有限。

第三是回饋迴路。獎勵來自模型自己的多數意見，模型在訓練中往多數靠攏，下一輪的多數又由更新後的模型產生。README 沒有描述任何對抗這種自我強化的機制，例如與外部驗證器交叉檢查。文件在這點上是薄的，這是設計上的取捨而非疏漏，但採用者應該知道自己在接受一個會自我確認的迴圈。

最後是成本。每次評估都變成一次訓練，這與靜態 benchmark 的用法完全不同。

與純測試時擴展方法的分野

最直接的替代方案是純測試時擴展：對同一題取樣多次再投票，不更新任何參數，也就是 maj@n 本身。兩者使用同一套取樣與投票機制，差別在於是否把投票結果回饋成梯度。

這個差別帶來具體後果。純投票的推論成本隨 n 線性成長，但每次評估彼此獨立，可重現，沒有訓練不穩定性。TTRL 則把成本再推高一個層級，換取的是參數層面的適應，README 聲稱這能讓表現超過初始模型的 maj@n 上限。若你的瓶頸只是單次推論品質、且可接受較高的 n，純投票是更省事也更可預測的選擇。

若你確實需要參數更新，另一條路是用 ground-truth 標籤做標準 RLVR。README 自己提到 TTRL 是在朝這個方向接近，但尚未追上。所以當標註資料取得成本不高時，沒有理由繞道用偽標籤。TTRL 的價值集中在標註不可得、而測試資料本身可用的情境。

至於 repo 中列出的 OpenRLHF (v1.0.0) release，README 並未說明它在 TTRL 流程中的角色，無法從材料判斷。

授權、維護與升級成本

授權為 MIT，寬鬆條款，可商用與修改，需保留著作權聲明。這是一般性描述，不構成法律意見，實際使用前應自行確認 repo 內各檔案與其相依套件（特別是 verl）的授權狀態，因為 TTRL 的訓練能力大部分來自上層框架。

維護面上，這是一個研究專案。最後推送時間為 2026-04-15，公告欄顯示持續有後續工作，包括被 ICLR 2026 接受的 Unsupervised RLVR 分支，程式碼放在 urlvr-dev 分支。這表示主線可能與研究分支分岔，採用時要選定分支並記錄版本。

升級成本主要來自 verl 的耦合。TTRL 的啟用方式曾是一個額外參數 +ttrl.enable=True，這種寫法依賴 Hydra 風格的設定覆寫，一旦 verl 調整設定結構或獎勵介面，這行就可能失效。加上前面提到的版本標示不一致，升級前應先確認目標 verl 版本是否仍支援該參數，再決定是否跟進。

文件方面，README 對機制與指令交代得夠用，但對超參數、答案抽取細節、失敗案例的處理都留給程式碼本身。這對願意讀原始碼的研究者是常態，對只想照著指令跑的團隊則是一道門檻。

編輯結論

TTRL 適合手上有一批沒有標註答案的推理題、而且能調度 8 張 A100 80GB 等級算力的團隊；如果你只有單張消費級 GPU，或題目是開放式寫作、主觀評分這類多數投票無法收斂的任務，它幫不上忙。採用前先確認三件事：你的題目答案可以正規化比對，你的模型對同一題取樣 n 次會產生可辨識的多數解，以及你願意接受每次評估都要跑一輪訓練。README 提供的重現指令是 bash examples/ttrl/Qwen2.5/aime.sh，先在這條路徑上跑通，再談換資料集。

官方來源

1. License: MIT
2. PRIME-RL/TTRL on GitHub
3. Project website
4. README
5. Releases