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 訓練用的獎勵訊號，後者是純評估場景，最後卻收斂到同一個做法。

為什麼單一總分不可靠

傳統 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>

</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 線從正面、這篇從反面，各自給了證據。

給 AI Engineer 的共通建議

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

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

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

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

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

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

這跟 ihower 在上的 AI Evals 課程 (Hamel Husain 與 Shreya Shankar 開的) 一直強調的原則也蠻呼應的: judge 盡量用二元的 pass/fail 判斷，不要用 Likert 量表打分，因為人類自己都無法穩定區分 3 分和 4 分的差別，模型當然也不行。

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