LLM Judge 的 Yes/No 清單在成對比較最有證據，直接打分未必

週報上，LLM Judge（負責替回答評分的模型）給客服回答的平均分從 3.8 變成 3.9。PM 問你：「這 0.1 是 prompt 改好了，還是 judge 今天心情比較好？」你打開那 200 筆 4 分，想找出哪一筆其實有問題，卻只看得到一個數字，看不到它在哪一條要求上失分。

有研究把這個 1–5 分換成一串彼此獨立的 Yes/No 題目（checklist，清單）。

快速回答 把 1–5 分改成逐條 Yes/No 清單，多數公開研究發現能讓 judge 更一致，也看得出失分在哪一條。例如 TICK 把 LLM 與人類偏好的完全一致率從 46.4% 提高到 52.2%。但 2025 年 EMNLP 的 Furuhashi 等人發現，比較兩個回答優劣（成對比較）時，只在 judge 前後判斷不一致的題目加清單才有統計顯著的幫助，直接打分沒有。所以先用自己的人工標註量一致率；查完整度時，比較拆回答、拆參考答案與整體 rubric。

卡上每條結論都附一個原文數字，例如 Furuhashi 等人的 48 組比較中有 20 組顯著。

七份研究各自怎麼做、效果多少、限制在哪？

七份研究都拆成逐條 Yes/No，效果多為一致率或成本，限制在清單來源與驗證範圍。

爭點一：單一分數不穩，清單真的比較穩嗎？

多數研究發現清單讓 judge 更一致，但 Furuhashi 等人只在成對比較量到顯著改善，直接打分沒有。

支持方的說法。 CheckEval 的作者認為，評分不一致來自「主觀的評分標準加上 Likert 量表（1–5 級）」。他們的做法是讓人先定義評分項目，再展開成一串 Yes/No 題，讓 judge 只回答是或否。在 12 個評估模型、多個資料集上，不同 judge 之間的平均一致性提高 0.45，分數的變異也縮小。

TICK 從另一個方向走到同一個地方。牛津大學 Jonathan Cook 等人（研究在 Cohere 實習期間完成）指出，偏好判斷會把多面向的好壞壓成單一排名，所以改讓 LLM 為每個指令生成專屬的 Yes/No 清單。結果是 LLM 與人類偏好的完全一致率從 46.4% 升到 52.2%，連人類標註者拿到清單之後，彼此的一致性也從 0.194 升到 0.256。

Netflix 的經驗更接近日常。三位寫手標了約 1,000 則劇情簡介，一開始彼此很不一致。他們換成二元分數、允許參考過去的標註，並維護可搜尋的錯誤類型表，做了八輪、每輪約 50 則的校準，寫手之間的一致性升到約 80%。

反方的說法。 東北大學的 Momoka Furuhashi 等四位作者在 EMNLP 2025 問了一個比較難聽的問題：清單真的有用嗎？他們用六種方式生成清單，在八個 judge 模型（開源 7B 到 32B，外加 GPT-4o）上測試。成對比較時，只在 judge 對同一組答案前後選出的較佳答案不同時才加清單，常常比「全不用」或「全用」更準，在 48 組比較中有 20 組達到統計顯著差異。直接打分時，同樣的做法沒有任何一組達到統計顯著。所以在他們的實驗裡，清單的顯著改善只出現在成對比較。

工程上的意思。 成對比較先試清單，只在前後不一致的樣本上開；直接打分先用人工標註量差距。

爭點二：清單要自動生成，還是請專家寫？

自動生成的清單換到低成本，專家撰寫的準則換到專業判斷，七份研究沒有直接比較兩者。

自動生成派。 RocketEval 把重點放在成本：為每題生成清單後，讓只有 20 億參數的 Gemma-2-2B 逐條回答，再依人類標註調整各條權重。在 MT-Bench 和 WildBench 上，它與人類偏好的相關達到 0.965，與 GPT-4o 當 judge 相當，成本低 50 倍以上。TICK 也是讓模型自己生成清單。RocketEval 的作者還提出一個解釋：小模型當 judge 準度低，主因是不確定性高、對答案出現的位置有偏好，而且加上思維鏈（chain-of-thought）也補不起來；把評分改成一串針對該題的小問題之後，小模型才跟得上。

專家撰寫派。 HealthBench 走相反的路。OpenAI 請 262 位醫師，為 5,000 段多輪對話各自寫評分條件，累積 48,562 條準則。論文說明，準則涵蓋該回覆應包含的具體事實、溝通是否清楚、對常見迷思的處理，也包含像「請使用者補充膝蓋疼痛的細節，才能縮小診斷範圍」這類該有的行為。每條準則有 −10 到 10 的分數，負分代表不該出現的行為，每段對話的準則最少 2 條、最多 48 條，中位數 11 條。判定時，模型 grader 對每一條獨立判斷，符合就計入該條的分數（正分或負分），不符合記零分，加總後除以所有正分準則的總和。GPT-4.1 當評分模型時，在共識準則（多位醫師同意的準則）上與醫師判定的一致程度，7 個主題中有 5 個高於醫師平均；這個驗證只做在共識準則上。論文也承認，專屬準則各由一位醫師撰寫，除了共識準則，都沒有其他醫師複核。

反方的證據。 Furuhashi 等人檢查了自動生成清單的品質。他們先找出拉低與人類分數相關的清單（稱為負面清單），再逐條檢查其中的條目。在 LLMBar 中，這些清單共含 9,157 個條目，其中 42.0%（3,847 條）單獨拿掉後相關反而上升；InFoBench 是 1,472 個條目中的 40.7%（599 條）。但在被人工複核的條目中，超過 85% 其實合理可用。作者的結論是：問題在於「什麼算好」本來就定義得模糊，連人類寫的標準也互相不一致。

工程上的意思。 自動生成的清單，抽 50–100 條請領域的人讀過再剔除。

爭點三：整份清單一次問，還是逐條問？

整包問比逐條問便宜約一個數量級，一致率卻在每個受測模型上都比較低。查完整度時，拆參考答案在 ASQA 上比整體 rubric 準，拆候選答案反而較差。

Harvey 與 LangChain 的做法很具體：Harvey 開源的法律 agent 基準 LAB，每題有一組必須全部通過的準則，不少題超過 50 條。他們用 Kimi K2.6 在約 40 題上產出答案，共 2,348 條 pass/fail 準則，以 Opus 4.7 逐條判定的結果當基準，比較其他 verifier。

結果有兩個方向。一方面，整包一次問（batch）在每個測試的模型上，和基準的一致率都比逐條問低，但因為共用輸入，成本約低一個數量級。另一方面，同一份清單，GPT-5.5 與 Opus 之間也只有 95.7% 一致，作者認為有些準則本身寫得不夠明確，95.7% 可能已接近上限。

便宜模型的錯法最值得注意。Haiku 4.5 比 Opus 和 Sonnet 便宜，卻太寬鬆，假通過（judge 判通過，基準卻判不通過）的比例見下表。作者稱這是法律驗證最不能接受的錯誤方向，因為判錯的失敗項還能轉給人複查，判錯的通過項通常不會。DeepSeek-V4-Flash 則和 Opus 相當接近，成本低約三個數量級。作者拿它當實驗對象，把每條準則拆成明確的子檢查，並在資訊不清時採保守判定，假通過率下降。

Netflix 的結論和 Harvey 方向一致：一個 prompt 同時判所有評分項目，表現比每個評分項目一個 judge 差。Netflix 還實測了兩個常被當成預設的技巧。讓 judge 先長篇推理、再把理由濃縮後給分（分層說明），語氣的二元準確率從 86.55% 升到 87.85%。同一則簡介取樣 5 次再平均（共識評分），對語氣和清晰度有幫助，對精確度沒有，精確度的 judge 用的是短理由。事實查核再往前一步，用四個 agent 分別檢查劇情、中繼資料、演職員和獎項，最後取最低分，任何一個失敗整則就失敗。

反方的證據來自任務類型。 Xinran Zhang 的單一作者研究在 2026 年 3 月首次發表，9 月 30 日更新到第二版，已被 AACL-IJCNLP 2026 主會議接受，是本篇裡最新的資料點。作者用同一個 judge、同樣的輸入，比較四種單次呼叫的設計，標籤有三類：支持、部分支持、不支持。結果是：把「候選答案」拆成原子事實（一條只含單一主張的陳述）逐一驗證，在需要判斷完整度的 ASQA 和 QAMPARI 兩個資料集上，每個 judge 都比整體 rubric 差，而且 token 更多。反過來，把「參考答案」拆開，在 ASQA 上比整體 rubric 高 12.5 到 21.3 個百分點，代價是多用 28% 到 29% 的 token。在 TruthfulQA 的迷思題上，拆候選答案則有競爭力；在一個 60 筆、標籤比嚴格完整度更寬鬆的子集上，拆候選答案甚至對每個 judge 都領先。作者的結論是：該拆什麼，取決於標籤在量什麼。

這篇的限制是只有三個 QA 資料集，每個 200 題。

工程上的意思。 verifier 同時支援逐條與整包，先用逐條跑基準，再看整包省多少、掉多少一致率。

爭點四：清單全過了，產品真的變好了嗎？

清單全過不保證產品變好；Netflix 把 judge 分數對照點選與放棄率，只能支持預測關係，無法確認因果。

Netflix 的做法有兩層。第一層，judge 對照人工標註的黃金集（約 600 則），要求一致率達 85% 以上。第二層，檢查 judge 的分數能不能預測觀眾行為：在同一部劇的不同簡介之間，比較 LLM 分數的變化與「被點選比例」和「放棄率」的變化。結果是精確度和清晰度的預測力最強，各評分項目加權後的總分也能預測更高的點選與更低的放棄。Netflix 也說明這個分析沒有乾淨的實驗設計，只能支持預測關係，無法確認因果。

Harvey 的 LAB 要求每題的所有準則都通過才算完成，因為律師工作中，漏掉一個重大風險不能用八成完成來折算。HealthBench 則走加權：每條準則有正負分，扣分項直接抵銷得分。兩者都是 Yes/No 清單，但聚合方式決定了你在量什麼。

HealthBench 論文自己也列出限制：分數與回覆長度有微弱相關，評估範圍限於單一回覆，沒有涵蓋完整臨床流程。

工程上的意思。 每條準則的 pass/fail 與說明都留著，失分才能定位。

回到那個 0.1

這些研究沒有一份說「分數永遠比清單差」，分歧在比較方式與任務類型，目前沒有人定案。

我的做法先問任務類型。成對比較的 judge，加選擇性清單，因為這是目前證據最一致的組合；直接打分的 judge，先量清單版與分數版各自跟 50 筆人工標註的一致率，差距在誤差範圍內，就選比較便宜、比較好除錯的那個。採用清單版時，自動生成準則、人工抽查，每條準則的 pass/fail 都存下來。清單條數沒有研究給出通用答案（HealthBench 中位數 11 條），我建議先從 5 到 10 條可獨立判斷的準則開始。高風險或影響營收的 judge，再比照 Netflix 把分數對照下游行為指標，並定期用新的人工標註樣本重新量測與人工標註的一致率。

我最放不下心的是假通過。Harvey 的數字顯示，Haiku 4.5 的假通過率逐條問是 48.4%、整包問是 34.7%，而這種錯在週報上看起來就是分數漂亮。所以我會在換任何 judge 之前，先拿一批已知有問題的回答，看它放過幾筆；這一步是我從 Harvey 的結果推出來的，研究沒有直接要求。

回到週報上的 3.8 變 3.9。若這個 judge 當初是一串 Yes/No，PM 問起時你可以直接翻出（以下數字是假設的例子）：「第 4 條『有沒有引用訂單編號』從 71% 升到 78%，其他條沒變。」這句話比 0.1 的分數差，PM 聽得懂，也修得動。

常見問題

Yes/No 清單要寫幾條才夠？

沒有哪份研究給出通用的數字。HealthBench 的每段對話中位數是 11 條，範圍 2 到 48 條；Harvey 的 LAB 有不少題超過 50 條。我建議先從 5 到 10 條可獨立判斷的準則開始，量過 judge 與人工標註的一致率，再決定增減。

小模型可以當 judge 嗎？

可以，但要校準。RocketEval 用 Gemma-2-2B 搭配清單與人類標註校正的權重，與人類偏好的相關達到 0.965。Harvey 以 Opus 為基準、約 40 題逐條判定的實驗則顯示，Haiku 4.5 太寬鬆，假通過（judge 判通過、基準判不通過）的比例高達 48.4%。換小模型之前，先量假通過率。

清單生成後，怎麼知道哪些準則有問題？

抽樣檢查。Furuhashi 等人檢查拉低與人類分數相關的清單（負面清單），發現其條目中約四成單獨拿掉後相關反而上升，但在被人工複核的條目中，超過 85% 仍合理，所以不要只看相關性就刪，要請領域的人讀過內容，確認不合理的才剔除。

一定要做行為驗證嗎？

不一定。Netflix 把 judge 分數與點選比例、放棄率對照，確認分數有預測力。我建議高風險或影響營收的 judge 才做；沒有下游指標時，至少定期用新的人工標註樣本重新量測與人工標註的一致率。

延伸閱讀

• AI Demo 很成功，為什麼一上線就出事？五條失敗路徑一次看懂（2026）
• Loop Engineering 是什麼？怎麼讓 AI 自己把事情做完再叫你？（2026 實戰教學）

參考資料

• Jonathan Cook, Tim Rocktäschel, Jakob Foerster, Dennis Aumiller, Alex Wang, TICKing All the Boxes: Generated Checklists Improve LLM Evaluation and Generation, arXiv:2410.03608, 2024-10-04。查證日 2026-10-23。 https://arxiv.org/abs/2410.03608
• Yukyung Lee 等, CheckEval: A reliable LLM-as-a-Judge framework for evaluating text generation using checklists, arXiv:2403.18771（v1 2024-03-27，v3 2025-10-31），EMNLP 2025。 https://arxiv.org/abs/2403.18771
• Tianjun Wei 等, RocketEval: Efficient Automated LLM Evaluation via Grading Checklist, arXiv:2503.05142, ICLR 2025。 https://arxiv.org/abs/2503.05142
• Rahul K. Arora 等, HealthBench: Evaluating Large Language Models Towards Improved Human Health, arXiv:2505.08775, 2025-05-13。 https://arxiv.org/abs/2505.08775
• Gabriela Alessio, Cameron Taylor, Cameron R. Wolfe, Evaluating Netflix Show Synopses with LLM-as-a-Judge, Netflix Technology Blog, 2026-04-10。 https://netflixtechblog.com/evaluating-netflix-show-synopses-with-llm-as-a-judge-6269251e6f28
• Vivek Trivedy 等（LangChain Labs 與 Harvey）, Designing Efficient Verifiers for Legal Agents, 2026-06-02。 https://www.langchain.com/blog/designing-efficient-verifiers-for-legal-agents
• Momoka Furuhashi, Kouta Nakayama, Takashi Kodama, Saku Sugawara, Are Checklists Really Useful for Automatic Evaluation of Generative Tasks?, arXiv:2508.15218, 2025-08-21，EMNLP 2025 Main。 https://arxiv.org/abs/2508.15218
• Xinran Zhang, Atomic and Holistic LLM Judges for Reference-Grounded Support Labels: A Prompt-Controlled Comparison, arXiv:2603.28005（v1 2026-03-30，v2 2026-09-30），AACL-IJCNLP 2026 主會議。 https://arxiv.org/abs/2603.28005