BenchIndex

Reading the numbers

方法論

同一個模型、同一個基準,換一組評測設定就能差出十幾個百分點。這頁整理幾個在比較分數之前必須先確認的變數。

1. pass@k 不是可以互相比較的

pass@1 是單次嘗試就答對的機率;pass@10 是十次裡至少一次答對。後者必然高於前者,而且高很多。看到一個亮眼的程式類分數時,先確認它是哪一種 —— 有些報告會用 pass@10 卻只寫「pass rate」。

τ-bench 引入的 pass^k 方向相反:連續 k 次全部成功才算過。這對實際部署更有意義,因為使用者要的是穩定,不是偶爾靈光。

2. 推理預算會直接買到分數

允許模型輸出更長的思考過程、或多次取樣後取多數決,分數幾乎必然上升,數學與程式類尤其明顯。這代表兩件事:

3. 訓練資料污染

公開基準的題目與答案會被複製到部落格、教學文、GitHub,最終進入訓練語料。一旦發生,分數反映的是記憶而非能力。

幾種常見的緩解設計:

做法代表基準原理
題目附時間戳LiveCodeBench只取訓練截止日之後的新題
測試集不公開FrontierMath、SEAL 系列題目本身不進入公開網路
每年產生新題AIME、HMMT比賽本身持續產出新內容
程序化生成部分合成基準每次評測即時產生題目實例

一個實用的檢查方式:同一模型在「訓練截止前」與「截止後」兩個時段的題目上,分數是否有異常落差。

4. 飽和與有效區間

當多數受測模型都落在 95% 以上,剩下的差距多半來自標註錯誤與雜訊,而非能力差異。MMLU、HumanEval、GSM8K 都已進入這個狀態。

飽和的基準仍然有用,只是用途變了 —— 適合當迴歸測試(分數掉下來代表出問題),不適合當排名依據。

5. 樣本數與統計顯著性

這是最常被忽略的一項。以幾個常見基準的單題權重來說:

基準題數單題約值
AIME(單份)156.7 個百分點
GPQA Diamond1980.51 個百分點
SWE-bench Verified5000.20 個百分點
MMLU15,9080.006 個百分點

在 AIME 上「86.7 對 80.0」聽起來像明顯領先,實際上只是多對一題。這種差距在沒有多次取樣與信賴區間的情況下,不足以支撐任何結論。

6. Agent scaffold 的影響

SWE-bench、OSWorld 這類基準測的是「模型 + 外層框架」的整體表現。同一個模型換一套 scaffold,解決率可以差十幾個百分點。引用這類分數時,模型名稱之外還要標註所用框架與工具集,否則比較沒有意義。

一個簡單的自檢清單:這個分數的 pass@k 設定是什麼?取樣幾次?用了哪個子集(完整集還是 Verified/Diamond)?題目有沒有可能在訓練資料裡?樣本數支不支撐這個差距?如果是代理任務,用的是哪套 scaffold?六個問題都答得出來,才適合拿來比較。