LLM 評審別只看平均分

LLM-as-judge 已經是很多生成式系統的常見評估方式。問題是，大家常看的是整體分數，卻很少問一個更關鍵的事：這個評審在「單一輸入」上到底可不可靠？Diagnosing LLM Judge Reliability: Conformal Prediction Sets and Transitivity Violations 就是在補這個洞。它不是只看平均分，而是把 LLM 評審拆開來觀察，檢查它在每個文件上的一致性與不確定性。

這篇摘要的核心訊息很直接：如果你拿 LLM 來評摘要、輸出品質，或其他 NLG 系統，單一 rating 可能不夠。你可能更需要知道，評審什麼時候會猶豫、什麼時候會前後矛盾，以及這些不穩定是不是跟輸入本身有關，而不是隨機波動。

這篇論文想解的痛點

LLM 評審之所以受歡迎，是因為它能把原本需要人工看的評估流程自動化。這對團隊很有吸引力，尤其是當你要快速比較不同模型、不同 prompt、不同版本時。但自動化不等於可信。某個 judge 可能在整體上看起來表現不錯，卻在個別案例上出現明顯不一致。

論文作者要處理的，就是這個「平均起來看不出來」的問題。摘要明確指出，per-instance reliability 目前還沒有被充分理解，但 LLM-as-judge 已經越來越常被拿來做自動化 NLG 評估。換句話說，業界正在大量使用這種工具，卻不一定知道它在單筆資料上的穩定程度。

這篇研究不是要宣稱人類評估可以被完全取代。它更像是提供一套診斷工具，讓開發者知道：哪些輸入比較容易讓 judge 出現搖擺，哪些評估面向比較脆弱，哪些結果應該保留更多懷疑。

方法到底怎麼運作

作者用了兩個診斷角度。第一個是 transitivity 檢查。白話來說，如果 A 比 B 好，B 比 C 好，那通常 A 也應該比 C 好。這種關係如果常常被打破，就會出現 directed 3-cycle，也就是三個對象之間形成互相矛盾的偏好鏈。論文用這種方式看 judge 的比較結果有沒有邏輯上的不一致。

第二個是 split conformal prediction sets，而且是套在 1 到 5 的 Likert 分數上。不要把它想成單純輸出一個分數；它輸出的是一組「合理分數集合」，並且有理論上的 coverage 保證，至少是 1-α。集合越窄，代表 judge 越有把握；集合越寬，代表它越不確定。作者把這個 set width 當成 per-instance reliability 的訊號。

這裡有個重點。set width 不是那種模糊的「我覺得有信心」文字敘述，而是可以實際量化的訊號。論文報告，prediction set width 和 reliability 有正相關，而且這個關係在不同 judges 之間都能看到。也就是說，這個寬度看起來比較像是輸入本身難不難，而不是某個模型的偶然偏差。

作者也把這套診斷放到不同 evaluation criteria 上比較。這樣做的好處是，你不只是在問「哪個 judge 比較好」，而是在問「哪一種評估任務比較容易被 judge 穩定處理」。這對實務其實更有用，因為很多時候瓶頸不是模型本身，而是評估標準本來就很主觀。

論文實際證明了什麼

第一個結果是 transitivity 真的會出問題，但問題不是只看整體平均就看得出來。論文報告的 aggregate violation rate 不高，平均 ρ 落在 0.8% 到 4.1% 之間；可是換到文件層級來看，33% 到 67% 的文件至少出現一次 directed 3-cycle。這代表什麼？代表整體數字看起來不嚴重，但很多單筆輸入其實已經有矛盾判斷了。

第二個結果是 conformal prediction sets 的寬度，確實能當作可靠性訊號。跨所有 judges 來看，set width 和 reliability 的相關係數是 rs = +0.576，N = 1,918，p < 10-100。這個數字很強，至少在這份研究的設定裡，寬度越大，judge 越不可靠的趨勢非常明顯。

更有意思的是，這個訊號不是只在單一模型上成立。論文還觀察到不同 judges 對 set width 的判斷有一定程度的一致性，平均相關大約在 0.32 到 0.38 之間。這支持一個解讀：set width 反映的可能是輸入的難度或歧義，而不是某個 judge 自己的怪脾氣。

第三個結果是，criteria 之間的差異比 judge 之間更重要。摘要指出，relevance 是最可靠的，平均 set size 大約 3.0；coherence 居中，平均 set size 約 3.9；fluency 和 consistency 最弱，平均 set size 約 4.9。因為分數範圍是 1 到 5，set size 越大，代表 judge 留下越多可能性，也就是越不敢下結論。

這裡的訊息很實際：不是所有評估面向都一樣容易。某些面向，像 relevance，LLM judge 比較能穩定處理；但像 fluency、consistency 這類面向，judge 可能更常陷入模糊地帶。對做產品的人來說，這會直接影響你能不能把自動評分當成主要依據。

對開發者有什麼影響

如果你在做摘要評估、排序、或其他 NLG 檢查，這篇論文的建議其實很務實：不要只看一個分數。你應該把 judge 當成一個有不確定性的工具，而不是一個永遠正確的裁判。平均分數可以幫你做粗略篩選，但不能保證每個樣本都值得信任。

更具體地說，這篇研究暗示幾個實作上的方向：

• 把 per-example uncertainty 納入流程，不要只存 aggregate average。
• 除了最終分數，也檢查 pairwise comparison 是否有矛盾。
• 不同 criteria 的難度可能差很多，不要假設所有評估項目都一樣穩。
• 如果你需要跨 judge 通用的可靠性訊號，set width 這種穩定指標值得保留。

對團隊而言，這不只是研究上的小修正，而是評估流程的思維轉向。當 conformal set 很寬時，最合理的解讀通常不是「模型壞掉了」，而是「這筆輸入本來就很難判」或「這個 criterion 本身就很模糊」。這種資訊可以幫你決定要不要送人工複核，也可以幫你設計更保守的自動化門檻。

如果你把 LLM judge 用在產品上，這種診斷尤其重要。因為使用者通常不在乎你的平均準確率有多漂亮，他們在乎的是：當系統真的要對某個內容下判斷時，它會不會亂來。這篇論文就是在提醒大家，真正該盯的不是平均值，而是單筆決策的穩定度。

限制與還沒解完的問題

這份研究的範圍主要放在 SummEval。摘要沒有說它已經在更廣泛的資料集、領域或 prompt 設計上驗證過同樣的結果，所以不能直接把這些數字外推到所有場景。也就是說，這篇論文提供的是一個很有用的診斷框架，但不是一個萬用結論。

另外，摘要沒有公開完整 benchmark 細節，也沒有宣稱這些診斷能把評估品質從頭到尾解決。它更像是在告訴你：你至少可以先知道 judge 在哪裡不穩，然後再決定要怎麼處理。這跟「直接得到絕對正確的自動評分」是兩回事。

conformal prediction sets 還有一個天然限制：它能告訴你不確定，但不會直接告訴你為什麼不確定。集合很寬，可能是輸入真的難、標準太主觀，或 judge 校準得不好。摘要裡提到跨 judge 的一致性，表示這個訊號不是亂飄，但它還沒把原因完全拆開。

即便如此，這篇論文的價值還是很清楚。它把 LLM 評審從「只看分數」推進到「看分數，也看一致性與不確定性」。對開發者來說，這種轉變很重要，因為它讓自動評估更像一個可監控的系統，而不是黑箱裁判。

作者也提到他們釋出了 code、prompts 和 cached results。對想重現或改造這套診斷流程的人來說，這會比單純的理論描述更有用。畢竟真正能落地的，不是另一個 judge，而是知道 judge 什麼時候可能不可靠的能力。