LLM-as-judge 可信嗎 — 2026 研究量出 62.3% 判決不一致與 5 個對策
模型輸出不穩，所以大家改派 LLM 當評審。但 2026 的論文量出評審自己更不穩：把回答反轉只有 37.7% 會跟著翻判決、光讀 rubric 不看回答就能猜中八成。這篇整理那三篇研究的數字、我自己的守門變成假綠燈的真實案例，以及 5 個讓 eval 穩下來的做法與該有的順序。
本文是我把 2026 三篇 LLM-as-judge 研究跟自己站上守門出包的經驗對起來的整理。給已經在跑 eval、但開始懷疑 eval 數字的 QA 與工程師。
前言
有人問我：「我們的 LLM 功能已經有 eval 了，CI 也綠的，為什麼上線還是出事？」
短答：你的 eval 自己就是一個沒被測過的非決定性系統。長答在下面。
這篇給你三件事：2026 三篇論文量出來的 judge 不穩定數字、我自己站上「守門變成假綠燈」的真實案例，以及 5 個讓 eval 穩下來的具體做法。
小提示
- 如果你還沒有 eval，先看 llm-evaluation-testing 把架構搭起來再回來看這篇。
- 這篇不談模型選型，只談「你怎麼知道評估結果能信」。
不穩定的不只是被測的模型
常見的演進路線是這樣：字串比對測 LLM 會一直紅 → 改成語意相似度 → 還是不夠細 → 改派另一個 LLM 當評審（LLM-as-judge）。
問題是這條路線把「不確定性」往上搬了一層，沒有消掉它。評審模型一樣是機率模型，一樣會受 prompt 措辭影響，而且它的不穩定沒有人在測。
2026 下半年有三篇研究把這件事量出來了。
2026 研究量出來的三件事
下面數字都標了出處與擷取日期，你可以自己去對：
| 發現 | 量出來的數字 | 出處 | 對 QA 的意思 |
|---|---|---|---|
| 把候選回答反轉，judge 應該翻判決 | 只有 37.7% 真的翻 → 62.3% 不一致 | arXiv 2609.02942（2026-08-31） | judge 對「回答變了」沒有想像中敏感 |
| 把 rubric 標準反轉，judge 應該翻判決 | Gemma 16.8%／LLaMA 32.2% | 同上 | 改 rubric 不一定改得動判決 |
| 只拿 rubric 文字猜 judge 判決 | 準確率 78-90%（balanced 0.801-0.881） | 同上 | 判決有一部分是 rubric 寫法決定的，不是回答 |
| 同一條 rubric 跟不同標準綁在一起評 | 分數會跟著整組標準跑 | arXiv 2608.14684（2026-08） | eval set 增刪一條，舊分數就不可比 |
小提示
- 第三列是我覺得最該記住的：分類器完全沒看到候選回答，光讀評分標準就能猜中八成判決。
為什麼 temperature=0 也救不了
把溫度設 0（greedy decoding）是每次都挑機率最高的 token，直覺上應該完全可重現。實際上不是。
不同硬體的浮點數差異會偶爾翻掉「誰是最高機率」那個判定，尤其是前兩名機率很接近的時候。跨 GPU 型號、跨雲端區域跑同一份 eval，結果就可能不同。
另外現在不少推理型模型直接不接受 temperature / top_p 參數，你連這個旋鈕都沒有。
注意事項
不要把「CI 上綠過一次」當成 eval 通過。單次結果在非決定性系統裡沒有統計意義。
5 個讓 eval 穩下來的做法（照這個順序做）
順序有講究：先把噪音降下來，再改斷言的形狀，最後才用重複執行去平均。倒過來做會很貴又沒效。
-
›
1. 先降噪
temperature=0、pin 住模型版本與 judge 版本。版本沒 pin 的話你分不出是 code 改壞還是模型換了
-
›
2. 斷言改成語意而不是字串
embedding 餘弦相似度對 gold set 比對，門檻取 0.80 起跳，再依你的資料調
-
›
3. 給指標容忍帶
寫成 assert accuracy >= baseline - 0.02 這種形狀，容忍度要大於你實測的 run-to-run 噪音
-
›
4. 同一題跑多次取共識
CI 快取跑 3-5 次投票就夠，更大的 N 留給週期性深跑或高風險案例
-
›
5. 分開看 pass@k 與 pass^k
pass@k 是 k 次至少一次過，pass^k 是 k 次全過。對可靠度有要求的功能要看後者
小提示
- 容忍帶的數值不要用猜的。先把 baseline 連跑 10 次記下最大最小差，容忍度設得比它大一點。
- rubric 每次增刪都當成一次 breaking change，舊分數不要拿來跟新分數比。
我在自己站上遇到的假綠燈
這不是 LLM eval，但失效模式一模一樣，而且更容易發生在你身上。
我的站有一份 e2e 守門，其中一條檢查「頁面上不該出現超過 12px 的圓角」。2026-09 有幾天它隨機轉紅，查下去發現是 AdSense 的 Auto Ads 會間歇性注入自己的節點，帶著 20px 圓角。那是第三方腳本的樣式，我改不到，而且時有時無 —— 同一頁隔幾分鐘再測就乾淨。
更驚險的是修它的時候。排除第三方節點的條件寫在一個 for...of 迴圈裡，如果寫成 return 而不是 continue，掃到第一個廣告元素就會直接結束整個檢查函式，那支測試從此永遠是綠的。假綠燈比紅燈危險，因為沒有人會去看它。
把這件事對回 LLM eval：judge 分數穩定地落在門檻之上，不代表它在評估你的回答 —— 也可能是 rubric 寫法本身就把它推到那裡（見上面那個 78-90% 的數字）。
小提示
- 每個新加的排除條件都問一次：它如果把整個檢查提早結束，我看得出來嗎？
- 定期做一次「故意弄壞」的演練，確認守門真的會紅。
我踩過的 4 個坑
公開記下這幾個我自己犯過的錯誤。
-
›
❌ 用單次 eval 結果決定要不要上線
同一份 eval 我後來連跑 5 次，pass rate 在 3 個百分點內晃。單次那個數字等於擲骰子。現在一律跑 3 次取共識再看
-
›
❌ rubric 加了一條就直接跟舊分數比
分數掉了 4 個百分點，我以為是 prompt 改壞，追了半天才想到是評分標準變了。現在改 rubric 就重建 baseline
-
›
❌ 沒有 pin judge 的模型版本
供應商靜默更新之後 eval 分數整體位移，而 code 一行都沒動。現在版本寫進設定檔，跟著 code 一起進版控
-
›
❌ 排除條件寫成 return 而不是 continue
差一個字就會讓整支檢查永遠綠燈。這個是我在自己 repo 真的差點放行的，靠 review 擋下來。現在這類迴圈一律在原地註明為什麼不能 return
注意事項
eval 的門檻值一旦調鬆就很難調回來。調鬆之前先確認是噪音而不是真的退步，否則你只是把警報關掉。
最後
評估不是拿來證明系統對，是拿來偵測系統變了。把它當成前者，你就會不斷把門檻調到剛好能過。
明天可以做的第一件事：把你現有的 eval 連跑 5 次，把最大最小差記下來。那個數字就是你的噪音下限，任何小於它的「進步」或「退步」都不用解讀。
這幾篇研究都還很新，judge 的穩定性做法應該會持續變。我會隨著新的論文回來更新這篇。
資料來源與擷取日期
這篇的數字都來自下面幾個一手來源，擷取日期都標了，你可以自己去對：
- Judging LLM-as-a-Judge: Concerning Rubric Artifacts in LLM-based Automated Text Generation Evaluation（arXiv 2609.02942v1，2026-09-30 擷取）
- Mitigating Rubric Interference in LLM Judges via On-Policy Self-Distillation（arXiv 2608.14684，2026-09-30 擷取）
- Taming LLM Non-Determinism & Flaky Evals (2026 Guide)（2026-09-30 擷取）
論文與工具做法變得很快，這篇我會隨版本更新回來改。
- 1 arXiv 2609.02942（2026-08-31）把候選回答反轉後，judge 只有 37.7% 給出應該翻的判決，等於 62.3% 不一致。
- 2 同一篇發現：只拿 rubric 文字去訓分類器、完全看不到回答，就能猜中 judge 判決 78-90%。
- 3 rubric 不是獨立的 —— 同一條標準跟不同標準綁在一起評，分數會跟著跑（arXiv 2608.14684）。
- 4 temperature=0 不等於決定性：不同硬體的浮點差異仍會翻掉最高機率的那個 token。
- 5 止血順序是先降噪（temperature=0、pinned 版本）、再改斷言（語意相似度、容忍帶）、最後才是多跑幾次投票（3-5 次）。
先把四層評估架構搭起來，再回來處理這篇講的穩定性問題。
確定性系統的斷言設計。這篇是它在非決定性輸出上的延伸。
同樣在談「綠燈不等於有測到」，角度是 AI 產出的測試。
傳統 flaky 的根治流程，跟這篇的降噪順序可以對照著看。
評估之外的另一半：主動攻擊而不是被動量測。
2026 QA 趨勢實戰：我看到的 5 個轉變（AI、Shift-Left、Observability）
從手動 QA 到 AI 輔助、從測試金字塔到測試獎盃。這篇分享我這 10+ 年看 QA 從「測完才知道」到「shift-left + AI」的真實觀察。
AI / LLM 功能 Spec Review — 幻覺 / 評估 / 成本 / 法遵 8 個必問
AI 功能 spec review 完整指南。LLM 不確定性處理、評估指標、Prompt versioning、成本控制、安全護欄、法遵（EU AI Act / GDPR）、Fallback、人工 review 流程。
AI Agent 系統測試 — 自主執行 / 工具呼叫 / 多步推理的 QA 策略
測試 AI Agent 完整方法。Tool calling 驗證、Trajectory 評估、Failure mode 分類、無限迴圈防止、成本上限、安全 sandbox、Multi-agent 協作測試。
一般聲明
本站提供之資訊僅供參考，不保證其完整性與正確性。使用者應自行判斷資訊之適用性。