你的 AI 評分標準，真的「驗收」過了嗎？

為什麼「PRD 裡寫好 Criteria」不等於建立了 AI Evals？

許多團隊認為，只要在 PRD 裡寫好評估標準（Criteria），並導入 LLM 協助評分，就算是建立了 AI Evals 流程。

但這套負責判斷 AI 表現的標準與評分機制，本身可能還沒被驗證過。換句話說：不只 AI 產品需要被驗收，用來判斷產品表現好壞的評估標準，也需要被驗收。

核心問題

寫在 PRD 裡的評估標準，通常只能反映團隊當下已經說得出來的品質要求。

但在實際開發流程中，很多「什麼算好答案、什麼不能接受」的判斷，往往要等團隊實際看過 AI 回答後，才能被具體說清楚。

UC Berkeley 的研究《Who Validates the Validators?》就點出了這個難題。研究團隊找來 9 位有 LLM 開發或應用經驗的實務者，觀察他們如何替一個 LLM 任務建立評估標準；同時也請參與者檢視 AI 回答，判斷哪些回答符合期待、哪些不能接受。

關鍵洞察：評估標準漂移（Criteria Drift）

研究發現，這些參與者並非一開始就能精準說明所有評估標準。相反地，他們常常是在看過更多 AI 回答之後，才發現原來選擇的標準不夠精確，於是開始新增、修改標準，甚至回頭調整之前給予 AI 回答的評分。

這個現象，研究裡稱作評估標準漂移（Criteria Drift）。

換句話說，人類不是先把「什麼算好答案」完整定義好，才開始評分——這件事本來就很難一步到位。很多時候，是在實際看見 AI 回答後，才發現原先沒設想到、卻會影響評斷的品質要求。

Catch-22 困境：標準與評分互相定義

研究中，參與者通常需要先有評分標準，才能替 LLM 輸出打分數；但在替實際輸出打分數的過程中，又會反過來幫助參與者釐清評分標準。

研究者將這種矛盾稱為 Catch-22 困境，並將隨之產生的標準變動現象命名為評估標準漂移。

這對企業團隊意味著什麼

這個研究結果提醒企業團隊：PRD 裡的 Criteria 很可能只是團隊當下說得出來的品質要求，還不是經過驗證的最終標準。

當 AI 真的開始產出回答，團隊才會看見哪些錯誤類型原本沒有被寫進標準，哪些看似通過的回答其實仍然有業務、客服或法務風險。

同理，如果評估標準本身會在看見真實使用場景中的 AI 回答後被修正，那麼在大規模採用 LLM-as-a-Judge 前，團隊就應該先用一批貼近實際情境的 AI 回答來校準標準，並確認 LLM Judge 的判斷是否和團隊的品質期待一致。只有當這套標準先被校準，LLM-as-a-Judge 才能把團隊已經確認過的判斷標準，穩定套用到更多回答上。

也就是說，LLM Judge 的價值在於「擴大」人類判斷的規模，協助團隊自動化那些已經被討論過、校準過、對齊過的標準；至於「什麼算好、什麼不能接受」，仍然需要團隊先從真實回答中判斷清楚。否則，LLM 只是看似有效率地，把一套尚未驗證的標準套用到更多回答上，進一步加速錯誤判斷的擴散。

所以，PRD 裡的 Criteria 到底算不算數？

如果團隊期待的是「先寫下一份 Criteria 清單，就能一勞永逸地拿它評分所有 AI 輸出」，這樣的期待可能還太早。

但如果團隊願意把 Criteria 當成一份會隨著實際案例持續修正的活文件——先定義、先觀察、再校準、再擴大自動化規模——那麼 PRD 裡的標準就能從「團隊當下的猜測」，逐步變成「被驗收過的判斷依據」。

這也是為什麼，當團隊開始規劃 AI 專案的測試方式時，第一個需要釐清的問題，是要用哪些案例與標準判斷系統表現。如果一開始沒有先定義清楚測試案例、評估指標與通過標準，等到後續真的拿到測試結果時，團隊只能看到分數高低，卻說不清楚這些分數是否足以支持下一步決策，或是無法用分數定位問題根因。

金句啟發

「評估標準本身，也需要被驗收——在你相信任何一個分數之前，先確認打分數的人（或 LLM）看得懂你要的是什麼。」

延伸閱讀

[1] Who Validates the Validators?（Shankar et al., UIST 2024）

重點整理

什麼是評估標準漂移（Criteria Drift）？

指團隊在替 AI 輸出建立評分標準時，往往無法一開始就完整定義所有標準，而是在看過更多實際回答後，才不斷新增、修改標準，甚至回頭調整先前的評分。

為什麼 PRD 裡寫好的 Criteria 還不夠？

因為 PRD 裡的標準通常只反映團隊當下說得出來的品質要求，很多「什麼算好答案」的判斷，要等實際看過 AI 回答後才能具體化，寫在文件裡的版本並非經過驗證的最終標準。

導入 LLM-as-a-Judge 之前，團隊該做什麼準備？

應先用一批貼近實際情境的 AI 回答來校準標準，確認 LLM Judge 的判斷是否和團隊的品質期待一致。只有標準先被校準過，LLM-as-a-Judge 才能把已確認的判斷穩定套用到更多回答上，而不是擴散一套尚未驗證的標準。

如果沒有先定義測試案例與標準，會發生什麼問題？

團隊在拿到測試分數時，只能看到分數高低，卻說不清楚這些分數是否足以支持下一步決策，也無法用分數定位問題根因。