LLM-as-Judge 與其打總分，不如拆解成 Yes/No 檢核清單

如果你正在開發 LLM-as-Judge，最近有兩篇獨立的研究蠻值得參考，它們從不同方向得出了同一個結論: 與其讓 judge 用一個籠統的 prompt 對答案打 1-5 分，不如把「什麼叫好答案」拆解成一份逐項檢核清單 (checklist)，每一條都是可以獨立驗證的 Yes/No 小問題，逐項判斷後再加總成分數。

第一篇是 Cameron Wolfe 的 Rubric-Based Rewards for RL，整理了近期用 rubric 當 RL 獎勵訊號的一系列研究。第二篇是 Ask, Don’t Judge: Binary Questions for Interpretable LLM Evaluation and Self-Improvement，直接把「拆解優於整體打分」當成核心命題來驗證。有意思的是兩篇的出發點完全不同: 前者是要產生 RL 訓練用的獎勵訊號，後者是純評估場景，最後卻收斂到同一個做法。文章後半再補上兩個產業案例 (Netflix 和法律 AI 公司 Harvey)，看這套做法實際用在產品上會遇到什麼問題。

為什麼單一總分不可靠

傳統 LLM-as-Judge 讓模型直接輸出一個整體分數，問題大家應該都遇過:

• 偏差一堆: 位置偏差、冗長偏差 (偏好長答案)、自我增強偏差 (偏好自己生成的答案) 等等
• 分數不透明: 拿到一個 3 分，你不知道是哪裡扣的分，沒辦法 debug
• 分數擠在高分區間: 拉不開差距 (ceiling effect)，跟人類實際的分數分布對不起來
• 不同 judge 模型打出來的分數落差很大: 一致性低、變異大

根本原因是「好答案」本身是多維度的概念，硬要壓縮成一個數字，模型只能憑整體印象打分。而整體印象恰好最容易被表面特徵 (長度、格式、語氣) 帶偏，這跟 reward model 容易被鑽漏洞是同一類問題。

兩篇研究的共同解法: 拆解

Rubric-Based Rewards 這篇整理的做法是: 把想要的模型行為拆解成一份 rubric。單獨看每一條 criterion，都是相對客觀、可以獨立驗證的小問題;但整份清單合起來，涵蓋的是主觀、開放式的品質維度，也就是原本要靠人類偏好標籤才能捕捉的東西。文章形容 rubric 是「介於二元正確性訊號和粗粒度偏好排序之間的中間地帶」: 既保有 RLVR 那種可驗證的可靠性，又能延伸到沒有標準答案的領域。

實務上的設計規範:

• 每份 rubric 約 7-20 條自包含的 criteria，條目之間不要互相依賴
• 每條附上權重，可以用類別 (Essential / Important / Optional / Pitfall) 或數值
• 針對每個題目量身訂做的 criteria，效果遠勝通用型 rubric: 實驗發現預先定義的通用 rubric 表現很差
• rubric 的生成要有專家參考答案或人類指導當依據，純合成的 rubric 可靠性明顯下降

Ask, Don’t Judge 這篇則是把評估拆成「原子級的二元問題」: 先用 meta-prompt 從評估標準生成一組細粒度的 Yes/No 問題，讓 LLM 對每個輸出獨立回答，再聚合成多維度的分數。

這個 meta-prompt 分兩步: 先把任務要求「總結」成一組明確的需求，再把每個需求「分解」成一個以上的二元問題。paper 沒有公開完整的 prompt 原文，以下是小編根據 paper 描述推測的示意版:

以下是一個任務 prompt:

<task_prompt>
{{使用者的任務 prompt}}
</task_prompt>

請分兩步，產生一份評估回答品質用的二元問題清單。

第一步 (總結): 分析這個任務 prompt，列出一個好的回答必須滿足
的需求。包括明確寫出的要求，也包括沒有明說但重要的品質面向
(例如事實正確、沒有捏造內容)。

第二步 (分解): 為每個需求生成一個以上的 Yes/No 評估問題，規則:
- 每個問題只檢查一件事，不要把多個條件併在同一題
- 每個問題都可以獨立回答，不依賴其他題的答案
- 措辭上「Yes」一律代表符合需求
- 附上一個簡短的違規範例，說明什麼情況該答 No

輸出格式: 逐題列出「問題 / 對應的需求 / 違規範例」。

以摘要任務的「事實一致性」維度為例，paper 附錄中實際生成出來的二元問題長這樣: 「摘要中的每個主張都有原文支持嗎?」「有沒有捏造原文沒有的內容?」「人名等實體正確嗎?」「數字正確嗎?」「因果關係有被保留嗎?」。原本一個籠統的「一致性 1-5 分」，就這樣變成一組具體到幾乎不需要主觀判斷的小問題。

效果方面，在 SummEval、Topical-Chat、QAGS 這些基準上，這個做法追平或超越 UniEval 和 G-Eval 等強基線，事實一致性的評估尤其突出，而且分數分布更貼近人類 (不會全部擠在高分)。

這篇還多走了一步: 每個問題的 Yes/No 結果都是可解釋的，哪一條 fail 一目了然，所以這些「問題層級的回饋」可以直接拿去迭代改進生成端的 prompt，形成 self-improvement 的回饋迴路。換句話說，評估不再只是打分數，還能告訴你「要改哪裡」。

不只這兩篇: 拆解式評估已經有不少支持證據

擴大搜尋了一圈，發現這個做法已經累積了一整條研究線。細節就不展開了，直接列每篇能學到的 insight:

• TICK (2024): 拆解不只讓模型評得更準，把清單拿給「人類」標註者用，人類之間的一致性也會提升。拆解真正對齊的是「標準」，對人對模型都有效
• CheckEval (EMNLP 2025): judge 打分不一致的病因是「主觀標準 + Likert 量表」的組合。拆解成 Yes/No 後，換不同模型當 judge 結果也穩定，你的 eval 才有可重現性
• RocketEval (ICLR 2025): 拆解可以降低對 judge 模型能力的要求，把「需要強模型才能做的整體判斷」轉換成「小模型也答得出來的具體問題」。實務上代表大規模評估可以改用便宜的小模型跑，省下大量成本
• LLM-Rubric (ACL 2024): 逐項分數怎麼聚合成總分，不必手工定權重，可以用少量人類標註資料學出來
• Checklists Are Better Than Reward Models (2025): 拆解出來的訊號品質好到不只能拿來「量測」，還能直接當 RL 獎勵拿去「訓練」，在指令遵循上勝過 reward model
• HealthBench (OpenAI, 2025): 262 位醫師為每個案例寫專屬 rubric，是「實例特定 rubric」的大規模實踐。高風險領域的 criteria 要由領域專家把關，不能全靠模型自動生成

持保留意見的研究: 它到底反對什麼

也有一篇點出限制的研究值得認真看: Are Checklists Really Useful for Automatic Evaluation of Generative Tasks? (2025)。

先說明他們檢視的流程。上面 TICK 和 Ask, Don’t Judge 這類做法，清單都不是人寫的，而是分兩段全自動: 先把題目丟給 LLM，自動生成這一題的檢核清單，judge 再拿著清單對答案逐項回答 Yes/No 加總。這篇檢視的就是第一段「清單怎麼生出來的」: 他們比較了六種自動生成策略 (直接生成、生成前先考慮可能的回答、清單縮短或加長、先生成再自我修正等)，搭配八種不同規模的 judge 模型，同時測「成對比較 (pairwise)」和「直接評分 (direct scoring)」兩種設定。

要先講清楚: 這篇反對的不是「拆解成清單來評」這個方向，而是「清單全自動生成、不經篩選拿來就用，一定會更準」這個假設。具體有三個發現:

1. 在直接評分的設定下，加 checklist 沒有統計顯著的改善。作者推測是模型直接打分時，其實已經隱含考慮了那些清單要素，再明文列出來的邊際效益有限。checklist 的效益主要出現在 pairwise 比較的設定
2. checklist 要「挑時機用」而不是無腦全用: 他們發現只在 judge 意見分歧大的題目上 (多次評估的投票不一致、或分數標準差高) 才套用 checklist，效果比每題都用更好。也就是說 checklist 比較像意見分歧時的仲裁工具，簡單題目直接判就好
3. 自動生成的清單裡，約四成的項目跟人類判斷呈負相關。但弔詭的是，這些「壞項目」經人工審查後，超過 85% 其實是合理的評估標準，而且大多跟人類自己寫的清單重疊。作者的解讀是: 問題不在清單，而在人類評估本身就不一致，因為評估標準的定義太模糊

所以這篇的結論繞回了同一個地方: 該做的是「更明確地定義客觀的評估標準」，讓人類和自動評估都有所依據。這其實跟前面幾篇的主張並不衝突，反而互補: 拆解是對的方向，但自動生成的清單品質參差，項目要篩選、要人工把關，不是拆了就自動變準。

值得注意的是，兩條研究線對「人工把關」的態度並不一樣。RL 那條線是有實驗數據支持的: 純合成、沒有專家參考答案的 rubric 可靠性明顯下降，HealthBench 更是直接請醫師手寫。反而是評估那條線 (TICK、Ask Don’t Judge)，賣點恰恰是「全自動、免訓練」，清單從生成到使用都不需要人介入，而這篇質疑的正是這個假設。整合起來，「拆解」兩條線都支持，「清單要人工把關」則是 RL 線從正面、這篇從反面，各自給了證據。

產業案例一: Netflix 怎麼評估數十萬份劇情簡介

Netflix 四月發表的 Evaluating Netflix Show Synopses with LLM-as-a-Judge 是一個很完整的實務案例，從人類標註怎麼校準一路講到系統怎麼設計。順帶一提，作者之一正是前面 Rubric-Based Rewards 那篇的 Cameron Wolfe。

背景是這樣: Netflix 有數十萬份劇情簡介 (synopsis)，同一部戲通常還有好幾個版本，會針對不同會員投放不同版本。簡介寫得好，會員可以快速判斷這部戲要不要看; 寫得差就會誤導人，讓會員看沒多久就放棄。問題是要靠專業寫手一份一份審，不可能覆蓋整個片庫。

第一步不是做 judge，是先把人類的評分標準校準好。 他們找創作寫手標了約 1,000 份簡介，每份都由三位寫手各自評分並說明理由，結果一開始三個人的意見一致性很低。他們用三個做法把一致性拉起來:

• 改用二元分數，不用 1-4 分的 Likert 量表
• 讓寫手評分時可以參考過去標好的案例
• 維護一份可搜尋的常見錯誤分類表

經過八輪校準 (每輪約 50 份)，寫手之間的一致性拉到約 80%。接著他們再加一道手續讓標籤更穩定: 多位寫手各自評分之後，交給一個 LLM 依 rubric 彙整成最終標籤，意見分歧特別大的案例則交回人工複核。最後產出約 600 份的黃金資料集，每一份都帶有 criteria 層級的二元分數和說明，這就是後面用來對齊 LLM judge 的依據。

這段正好從實務端佐證了前面那篇質疑研究的結論: 人類評估之所以不一致，病因是評估標準定義太模糊。而 Netflix 的處理方式就是把標準寫明確、改用二元判斷。順序也很清楚: 先把人的標準校準好，才有東西可以拿來對齊 judge。

用一個 prompt 評所有維度，效果明顯較差。 他們一開始就發現，把所有品質維度放在同一個 prompt 裡評，模型的負擔太重，改成每個維度各用一個獨立的 judge 才有好結果。這些 judge 共通的設計是: 都用同一個 LLM、都先輸出解釋再給分、分數都是二元。二元還帶來一個額外好處，要衡量 judge 本身準不準變得很單純: 答案只有對錯兩種，直接算它在黃金資料集上的正確率就好。

事實查核再往下拆一層: Agents-as-a-Judge。 簡介的事實錯誤有四類: 劇情講錯、metadata 講錯 (類型、地點、上映日期)、演職人員講錯、獎項講錯。這四類要核對的佐證資料完全不同，查劇情要有情節摘要或劇本，查獎項要有得獎清單。所以他們讓每個 agent 只負責查一個面向，也只給它那一類需要的 context。四個 agent 判完之後取最小值當最終分數，也就是任一項沒過，事實性就是 fail; 四個 agent 的理由再交給一個 LLM 彙整成一份總說明。

他們的結論是「簡單帶來可靠: context 太多或 criteria 太多都會傷害準度」。而取最小值這個聚合方式，其實就是下面 4️⃣ 權重規則的極端版本: 所有條目都算 Essential，一條沒過就整體不通過。

解釋要寫多長，是準度和可讀性的取捨。 他們發現 judge 的解釋寫得越長，判斷越準，但邊際效益遞減。麻煩的是長篇解釋人類看不下去，而這些解釋本來就是要給創作專家看、當作判斷依據的。解法是分層解釋 (tiered rationales): judge 內部推理不限長度，但輸出前必須把推理過程濃縮成精簡摘要，再給最終分數。tone 這個維度的二元準確率因此從 86.55% 提升到 87.85%。

重複跑同一個 judge 取共識 (consensus)，不是加了就有用。 先解釋一下這個做法: 它跟 prompt 無關，而是同一份簡介、同一個 prompt，讓 judge 重複跑 5 次 (temperature 不為 0，每次的解釋和分數會有出入)，再把 5 次的分數平均、四捨五入回二元。這就是常見的 self-consistency，純粹用多花的呼叫次數換準度。

Netflix 的結果是: tone 和 clarity 這兩個用長解釋的維度有明顯提升，但 precision 這個只用短 CoT 的維度完全沒差。原因是短解釋每次跑出來的分數幾乎都一樣，根本沒有變異可以平均掉，跑 5 次就是白花 5 倍成本。所以要不要加 consensus，有個很簡單的判斷方式: 先拿同一題重複跑幾次，看分數變異大不大，變異小就別加。

同樣的成本考量也出現在模型選擇上。他們測過真正的推理模型配 5 次 consensus，推理強度拉越高準度越好，最高強度甚至贏過分層解釋，但最終系統還是沒有採用，因為成本上升很多，換來的增益卻有限。

驗證分兩步: 先確認 judge 準不準，再確認這套標準本身有沒有用。

第一步是拿 judge 判的結果，跟創作寫手標好的黃金資料集比對，一致性 85% 以上。多數團隊做到這裡就算完成了。

第二步是 Netflix 額外做的: 檢查 LLM 給的分數能不能預測會員的實際行為。行為指標有兩個，take fraction (看到簡介的人裡，有多少比例真的開始看) 和 abandonment rate (開始看之後很快就放棄的比例)，這兩個指標都經過 A/B test 驗證過，可以當作長期留存的短期代理指標。

做法是利用同一部戲有多份簡介的特性，在同一部戲內部比較「這份簡介的 LLM 分數比其他份高多少」和「它的實際表現好多少」。之所以要限制在同一部戲內部比較，是因為不同戲的先天熱門程度差太多，跨戲比較會被戲本身的吸引力蓋過，看不出簡介的效果。結果是 precision 和 clarity 最能預測會員行為，加權總分則跟「較高的 take、較低的 abandonment」有統計上有用的關聯。

小編覺得第二步才是這個案例最值得學的地方。judge 跟專家一致，只證明你成功複製了專家的判斷，並不證明專家這套標準本身是有價值的。Netflix 多做的這一步，是拿下游的實際指標回頭檢查評估標準站不站得住。而做到這個程度的實際好處是: 一部戲上線前幾週甚至幾個月，就能先找出並修掉會影響表現的問題。

產業案例二: 拆解的執行成本與取捨

拆解式評估在實務上有一個現實問題: 每條 criterion 都獨立呼叫一次 LLM，規模一大成本很可觀。LangChain 和法律 AI 公司 Harvey 合作的研究 Designing Efficient Verifiers for Legal Agents 正面處理了這件事，是很好的參考案例。

背景是 Harvey 開源的法律 agent benchmark LAB，驗證方式正是本文講的拆解式: 每個任務有一組 criteria (很多任務超過 50 條)，每條由 LLM verifier 獨立判 pass/fail。他們這次實驗跑了 40 個任務，加起來有 2,348 條 criteria 要判。如果每條都用 frontier 模型呼叫一次，做一輪評估還勉強可以，但拿去跑 RL post-training 成本就負擔不起了，因為每個任務還要乘上多次 rollout。

他們測了兩個省成本的方向:

• 一次判整份清單 (batch): 原本一條 criterion 呼叫一次，改成一次呼叫就把整份清單判完，逐條輸出結果。省下的主要是重複的輸入 token (逐條呼叫時，題目和 agent 的長答案每次都要重新附上)，同一個模型可以便宜一個數量級。代價是準度: 在他們的實驗裡，batch 跟基準的一致性全面低於逐條獨立判。不過要注意，合併的只是「執行方式」，評估標準還是那份拆解好的清單，並沒有退回打一個總分
• 換便宜的模型: 開源模型 (DeepSeek) 判的結果跟 Opus 高度接近，成本卻低了幾個數量級。這呼應前面 RocketEval 的 insight: 拆解後的具體小問題，不需要最強的模型來答。但也不是隨便挑一個便宜模型都行: Haiku 雖然便宜，卻明顯太寬鬆，大量把該 fail 的判成 pass。在法律這種高風險領域，這是錯誤的失敗方向: 誤判成 fail 頂多多送一次人工複核，把該擋的放過去才是真正的事故
• 掉的準度可以用 prompt 補救: 他們分析便宜模型判錯的原因，發現是一條 criterion 內部往往包含多個要件，模型看到答案「相關」就放行，沒有逐一核對。修正方式是在 prompt 裡要求 verifier 把每條 criterion 再拆成更細的 checklist 逐項確認，資訊不明確時保守判 No，false-pass 率就降下來了。連救回準度的方法都還是「再多拆一層」，跟 Netflix 那邊用 agent 拆事實查核是同一個方向

編按: 那評估到底該「逐條獨立呼叫」還是「一次判整份清單」?其實前面提到的研究兩種都有人用: TICK 是逐條獨立呼叫，同一題還可以問多次做多數決;RocketEval 則是一次判整份清單，效率本來就是它的賣點。Rubric RL 那篇把這兩種做法稱為「顯式聚合」(逐條評完再加權加總) 和「隱式聚合」(整份丟給模型綜合判)，而 RaR 的實驗結果甚至是隱式略優，跟 Harvey 這裡 batch 較差的結果方向相反。Netflix 的經驗則跟 Harvey 同方向: 用單一 prompt 評所有維度效果明顯較差。哪種比較準目前沒有定論，建議在自己的任務上實測，別直接套任何一邊的結論。

這篇還有一個跟前面呼應的發現: 連 GPT-5.5 和 Opus 這種等級的模型，逐條判的一致性也只有 95.7%。作者的解讀是部分 criteria 本身寫得不夠明確，模型無法像專家一樣穩定套用。繞回同一件事: 清單的品質是一切的前提。

給 AI Engineer 的共通建議

把這些研究的結論收斂一下，開發 LLM-as-Judge 時:

1️⃣ 用 Yes/No 二元判斷取代 1-5 分: 每個小問題越客觀、越可獨立驗證越好。judge 回答「這個回答有沒有引用來源」比回答「這個回答好不好」可靠太多了

2️⃣ criteria 要針對任務甚至針對單一題目設計: 通用型的「正確性、流暢性、相關性」這種維度效果最差。可以用強模型從參考答案或專家指導生成 instance-specific 的清單

3️⃣ 條目要自包含、不互相依賴: 這樣每一條才能獨立驗證，也才能平行化評估

4️⃣ 用權重表達優先序: 不是每條都一樣重要，Essential 沒過可以直接判不通過，Optional 只是加分

5️⃣ 把 fail 的條目當 debug 訊號: 拆解式評估最大的好處是可解釋性，哪條 fail 直接告訴你 prompt 或系統要改哪裡，甚至可以自動化這個改進迴路

6️⃣ 先校準人類的標準，再談對齊 judge; 驗證盡量做兩層: Netflix 是先花八輪把寫手之間的一致性拉到 80%，才有黃金資料集可以拿來對齊 LLM。而 judge 跟專家一致只是第一層，條件允許的話，最好再拿下游的實際指標回頭驗證這套標準真的有價值

這跟 ihower 在上的 AI Evals 課程 (Hamel Husain 與 Shreya Shankar 開的) 一直強調的原則也蠻呼應的: judge 盡量用二元的 pass/fail 判斷，不要用 Likert 量表打分，因為人類自己都無法穩定區分 3 分和 4 分的差別，模型當然也不行。Netflix 那邊八輪校準的第一個介入措施就是改二元，算是實務上的佐證。

小編覺得這件事的本質是: 評估的難度不會消失，只會轉移。你省掉的「打分」難度，其實是轉移到了「事先把好答案的標準想清楚、寫下來」這件事上。而這件事恰好是值得做的，因為寫清單的過程會逼你把模糊的品質直覺變成明確的規格，這份規格不只能交給 judge 用，也能回頭改進你的 prompt 和產品需求文件。