怎麼大規模評測 LLM 輸出品質

出貨過 LLM 產品都會撞到同一道牆:人工品質 review 規模化不了。一週讀 50 段對話對 1000/天流量是有意義樣本,到 10 萬/天連失敗都讀不完別說平均案例。你需要自動化。

大規模 LLM 評測是它自己的紀律。2026 年三種有效做法,以及挑選的規則。

三種口味

1. Golden dataset 評測(離線)

固定的輸入集,每個配理想答案(或定義「好」長什麼樣的 rubric)。模型跑完整集,每筆評分,加總。

用途:regression 測試、prompt 迭代、模型比較。

強項:確定性、跨 run 可比、迭代快。

弱項:只跟 dataset 一樣好。小或偏的 golden set 給假信心。真實流量分布漂移反映不到。

2. LLM-as-judge

用強 LLM(Claude Opus、GPT-5)拿你的 rubric 評其他 LLM 輸出。

Prompt:
「你在評一個答案的準確度跟有用度。
問題:{q}
答案:{a}
Rubric:{rubric}
回 JSON:{ score: 1-5, reasoning: string }」

用途:大規模便宜地對輸出打分,特別是主觀品質(有用、語氣、忠實度)精確比對失敗的時候。

強項:百萬輸出便宜地規模化(Haiku 當 judge $0.25/M input)。抓細微品質維度。

弱項:judge 有偏見(偏好冗長、正式語氣、自己的輸出在配對比較中)。模型版本變動時 calibration 會漂。Opus 當 judge 貴($90/M output)。

3. 線上指標(真實使用者)

量使用者行為:讚踩、對話長度、重試率、解決時間、複製率、放棄率。

用途:真實世界品質的 ground truth。使用者實際感受到的數字。

強項:真訊號。沒人造 dataset。抓你沒想到要量的品質維度。

弱項:雜訊大。改變偵測慢。不告訴你哪個 prompt 或模型改動造成 regression。沒法在使用者看到前抓問題。

決策樹

用哪個?看你在測什麼:

「我的 prompt 改有沒有打破什麼?」 → Golden dataset。Before/after 跑,有 regression 擋下。
「GPT-5 在我任務上比 Sonnet 強嗎?」 → 在幾千個真實 query 上跑 LLM-as-judge。
「我的產品是不是在變爛?」 → 線上指標 dashboard。
「我們在哪種問題上失敗?」 → LLM-as-judge 對真實流量打分,然後人工 review 低分輸出。
「這個幻覺率可以接受嗎?」 → Golden dataset 配可驗證答案;補上線上踩號。

規模化的堆疊是三個都要:golden 給 CI、LLM-as-judge 給流量抽樣、線上指標給 ground truth。

蓋好 golden dataset

最常見錯誤:一個工程師一小時寫的 30 題集。偏、窄、分布錯。

好的 golden:

盡可能從真實流量來(去 PII)。真實使用者問你想不到的東西。
分層按類別、難度、領域。30 簡單 + 30 中 + 30 難,不是 90 個隨機。
包含失敗 case,團隊看過的 —— bug 報告、客服工單、抱怨。
有理想答案或 rubric。有些題目沒一個對的答案(創意寫作),rubric(「回答有趣嗎?有事實根據嗎?長度對嗎?」)更彈性。
2+ 人審過才用。單一審者的偏見變團隊偏見。
每季用最近流量補新 example。

大小:單一產品 50-200 個通常夠多。越大不一定越好 —— 5,000 個的 golden 每次 prompt 改完跑半天。

LLM-as-judge 實務

Judge prompt 是最重要的部分,需要:

清楚 rubric。 別說「這個好嗎?」,說「1-5 打分根據(a) 事實準確度、(b) 有沒有回答使用者真正的問題、(c) 長度合理、(d) 安全且尊重的語氣。」
Few-shot example。 給 judge 看 5 分跟 2 分長什麼樣。calibration 大幅改善。
先 reasoning 再分數。 分數要求在 reasoning 之後,不是之前。「先想再下結論」比「先打分再合理化」分數更可靠。
結構化輸出。 用 JSON mode 或 tool use。「這個大概 4 分?」這種字串解不了。

很有用的小提示:用人類校準 judge。拿 100 個輸出,人類打分,judge 打分,比相關性。相關性 < 0.7 代表 rubric 不清楚或 judge 模型太弱。修 rubric 或升級 judge。

LLM-as-judge 常見偏見

已知失敗模式:

冗長偏見。 長答案分數高,即使短的更好。
位置偏見(配對比較)。第一個顯示的答案贏更多。緩解:打亂順序,或兩種順序都跑取平均。
自我偏好。 GPT-5 judge 認為 GPT-5 輸出比較好。避免拿同一模型評它自己。
風格偏見。 正式語氣分數高,不論準確度。
對自信錯答案過度信心。 自信但錯的答案往往比 hedging 但對的分數高。

大部分透過仔細 rubric 設計加人類校準緩解。

有用的線上指標

值得放 dashboard 的四個訊號:

每個回應的讚踩。 加按鈕,別看絕對數字,看時序變化。
重試率。 多少比例對話有使用者重問同一問題(改寫)?上升 = 品質下降。
「任務完成」結局的對話長度。 使用者 2 輪解決還是 8 輪?
特定功能使用(產品內):出貨「複製答案」按鈕,複製率是強訊號。

按 cohort dashboard(模型、prompt 版本、使用者群)。東西變動時你有資料定位 regression。

規模化 pattern:三層評測

認真產品有效的堆疊:

Pre-deploy: 100 題 golden dataset。每次 prompt 改跑。品質掉 > 3% 或幻覺率上升 > 1% 就擋 deploy。CI gate。
即時抽樣: 5% production 流量上 LLM-as-judge,每天打分。週度人工 review < 3/5 分對話。
穩態: 線上指標 dashboard。每模型讚踩率,週度趨勢。

不同延遲抓不同問題:golden 立刻抓明顯 regression,抽樣幾天內抓真實分布漂移,線上指標幾週內抓慢退化。

成本

快速數學,10,000 對話/天的產品:

每 release 跑 golden eval(100 題 × Sonnet eval):$0.50/run。免費。
5% LLM-as-judge 抽樣(500 對話/天 × Haiku judge):$0.20/天 = $73/年。免費。
抽出低分人工 review(每週某人 1 小時):真成本。

品質評測是 LLM stack 上最便宜的投資之一。大部分團隊跳過是因為以為貴,其實不貴。

什麼時候不要評測

MVP 之前。 你還不知道「好」是什麼。先弄出能出貨的東西再評測。
沒流量。 < 100 對話/天人工讀完。
單人內部工具。 直接問那個人。

投資觸發點:prompt 改開始覺得可怕,因為你判斷不出有沒有幫到或傷到。

下一步

G-Eval 跟 Prometheus —— LLM-as-judge calibration 論文。
Ragas、TruLens、DeepEval —— 實務框架。
本 Learn 庫的 RAG evaluation 那篇。
查這些詞:pairwise judging、judge calibration、golden dataset stratification、LLM eval observability。