為什麼開放式輸出需要評審
讓兩個聊天模型「向好奇的青少年解釋熵」，沒有任何答案鍵可供評分。像 BLEU 與 ROUGE 的字串重疊指標是為翻譯與摘要而建，與人類對「有幫助的開放式答案」的判斷相關性很差。於是我們轉向比較式評估：不孤立地為一個答案評分，而是問兩個答案中哪個更好。對評分者而言，比較比絕對評分更容易也更可靠——這正是 RLHF 蒐集成對偏好而非數值評分的同一個理由。
勝率：成對的基本單位
勝率（win-rate）是最簡單的比較指標：在相同提示上跑模型 A 與固定基線 B，讓評分者為每一對挑出勝者，回報 A 獲勝的提示比例。對基線 50% 勝率代表平手；70% 代表 A 在多數提示上更受偏好。它直觀且有界，但完全取決於哪個基線與哪些提示——對弱基線拿到 90% 勝率幾乎毫無意義。長度是惡名昭彰的混淆因子：評分者傾向偏好較長的答案，因此務必檢查勝率增益在控制長度後是否仍存在。
規模化的群眾偏好：Elo 競技場
Chatbot Arena 把勝率變成一個全域排名。匿名使用者輸入提示、收到兩個來自未公開模型的回應、為較好者投票，投完才看見模型名稱。用 Elo（或 Bradley–Terry）評分彙總數百萬筆這類成對投票，產生一個立基於真實提示上真實人類偏好的排行榜——這是它的最大強項，因為沒有任何靜態基準涵蓋人們實際會問的東西。
Elo 模型：评分差决定预期胜率，每一次投票都会微调评分。
用模型當評審
人類投票既慢又貴，於是我們把評分者換成強模型：LLM 作為評審（LLM-as-a-judge）。給一個能幹的模型提示、兩個候選答案與評分指示；它回傳判決與理由。在規格明確的任務上，強評審與人類多數投票的一致程度，大致和兩位人類彼此一致的程度相當——便宜到每小時能評上千次比較，也是 MT-Bench、AlpacaEval 等自動排行榜背後的引擎。同一套機制放大後，正是我們處理大到無法人工評分之系統的可規模化監督（scalable oversight）之道。
judge_prompt = f"""You are grading two assistant answers to the same question.
Question: {q}
[A]: {answer_a}
[B]: {answer_b}
Decide which answer is more helpful and correct.
First reason step by step, then end with exactly: VERDICT: A | B | TIE"""
# Mitigation: run twice with A/B swapped; keep the verdict only if it is
# consistent across both orders, else record TIE (controls position bias).評審是有偏誤的
模型評審本身也是一個模型，因此承襲了各種失效模式。研究最多的是位置偏誤（position bias）：面對相同的兩個答案，許多評審系統性地偏好排在前面（有時是後面）的那個。其他還包括冗長偏誤（較長看起來較好）、自我偏好（評審偏愛自己風格或同家族產出的文字）與諂媚（sycophancy）（附和提示中的斷言）。若不加控制，這些偏誤可能淹沒你想量測的真實品質差異。
对两种呈现顺序的判定取平均，可消除一阶位置偏差。
- 交換 A/B 順序取平均，或只保留順序一致的判決，以抵銷位置偏誤。
- 控制長度：在配對長度下報告勝率，或使用去長度偏誤的估計式。
- 用數百筆人類標註校準評審，並把評審與人類的一致度當成一個數字報告出來。
- 用與受測模型不同家族的模型當評審，以鈍化自我偏好。
評分量表：讓判斷可讀
模糊的指示給出嘈雜的判決。基於量表的評估（rubric-based evaluation）把「哪個較好」換成明確標準——事實正確性、完整度、安全性、格式遵循——各自對照書面標準分開評分，常附上 1、3、5 分各長什麼樣的參考點。量表提高評分者間的一致度，揭露一個答案為何獲勝，並讓你依應用所需加權。它是本篇偏好文化與你將在第 5 篇建立之有紀律、可稽核套件之間的橋樑。