73^{-1} mod 74 的答案是 73，因為 73 乘上自己，除以 74 會餘 1。模型對這個題目共回答了八次，八個答案都剛好不同。其中一個候選答案答對了 73，只是它一路寫到 256 tokens 的上限；另一個候選只花七個 tokens，乾淨地交出 \boxed{17}，今天加入的 selector 最後選了 17，以 token 效率的角度來看是有道理的選擇，但答案也選錯了。

當我們談論 Best-of-N 的時候，預期讓模型針對同一個題目多想幾次，再從 N 個候選答案裡挑出一個。乍聽之下像是替模型增加答題機會，實際跑完也確實如此：當每題有八個候選時，64 題裡有 23 題至少出現過一次正解，然而多數決最後只答對 13 題。即使推理模型已經找到答案，要如何從候選池中找到正解?誰來決定 Best-of-N 後的選法？

最方便的方法自然是交給 verifier，讓它逐一檢查答案，形式化後是否符合數學公理，但我們在這專案裡的數學 verifier 是透過讀取標準答案，再把檢查結果交給 selector，等於答題模型寫完八份答案以後，先翻解答再決定交哪一份。若繼續用這方法，結果數字當然會很好看，但也失去實驗的意義。

因此，今天使用的 selector 看不到標準答案，也不知道每個候選答案的對錯。它只能觀察候選本身：答案有沒有成功擷取、相同答案出現幾次、格式是否正確、是否在 token 上限以前完成。如果兩份答案看起來一樣可靠，就選較早生成的那份。我們另外測試了一個更重視輸出品質的 selector。它優先選擇格式完整、答案可以擷取，而且在 token 上限前完成的候選，用來看看「寫得像答案」的候選答案會否更容易被選中。

結果可以觀察到 Best-of-N 的選擇困難之處：

每題候選數                 1       2       4       8
多數決答對題數             5       5       9      13
加入候選品質的 selector     5       9      11      11
候選池裡曾出現正解          5      12      20      23

候選答案只有兩個時，加入品質訊號很有用。64 題裡有 60 題形成一比一平手，多數決只好選第一個答案。前一天看過的不等式題就是一例：模型先答 1，寫到 256 tokens 還沒有好好收尾；第二次答出 \boxed{2}，在 184 tokens 內完成。兩個答案都只有一票，selector 選了後者，也把這題救了回來。算完整批結果，它改對 5 題，同時誤判 1 題，答對數從 5 題增加到 9 題。

候選答案增加到八個以後，結果卻相反了過來。多數決答對 13 題，selector 只答對 11 題。開頭那道模逆題正好說明原因：八個答案各得一票，票數完全派不上用場；答對的 73 寫得又長又亂，答錯的 17 短、完整，還有方框。Selector 忠實執行規則，於是被一份外表更像標準解答的錯誤答案說服。

每題八個候選時，多數決選出 4 份符合嚴格格式的答案；加入候選品質後增加到 14 份；若把格式放在更前面，甚至可以增加到 21 份，答對題數仍是 11 題。方框可以幫程式找到答案，提早停止也能節省 tokens，兩者都不會替數學內容背書。

所以，23/64 這個比例意味著：模型在八次嘗試裡曾經解出 23 題，目前的選擇方法只帶回其中 11 題。生成與選擇是兩種能力，候選愈多，碰到正解的機會上升，混在旁邊的錯誤答案也跟著增加。最後那一步若沒有變聰明，多想幾次留下的成果便可能消失在候選池裡。我們採用的候選答案花費了 136,623 tokens，計算成本和成果相比：更多正解確實進入候選池，但系統最終只撈回其中一部分的正確答案。

2026 年的 Learning Generative Selection for Best-of-N 乾脆把 selection 當成一項需要訓練的能力：給模型一組同時含有正解與錯解的候選，再用 reinforcement learning 學習怎麼選。實務上是，Best-of-N 之後也需要真正的判斷，一條或數條簡單規則很難代勞；當生成模型愈來愈會探索，選擇模型也得跟著學會閱讀、比較與判斷。

鐵人賽目前走到一半，我們從 next-token prediction 和戲稱推理模型為隨機鸚鵡，一路走到多條推理路徑、答案擷取、成本與候選選擇。模型多想幾次，確實更容易得到正解，但整個答題系統該如何選出正確答案呢?縱使我們的候選池曾經存在正確答案，過於在乎答題品質的 selector 選了 17 而非 73，那麼最終正解沒有被選中也是枉然。