我第一次叫 AI 幫忙評答案，指令只有這樣：
請評估這個答案的品質，給 1 到 5 分。
它很配合地給了 4 分，理由也寫得很順。問題是我看完還是不知道這個 4 分能拿來做什麼。
「品質」到底是事實正確、答到問題、語氣自然，還是字數剛好？同一批答案隔幾天再跑，分數也可能變。換另一個模型當評審，更像連尺都一起換掉。
我後來才把順序反過來：先別急著叫 AI 打分，先做一把人看得懂、AI 也照得下去的尺。這把尺通常叫 rubric，也就是評分表。
一個總分不夠我找問題
假設我在測一個根據內部文件回答問題的 RAG 系統。它的答案可能同時有三種狀況：
數字都有根據，但答得太長。
直接答到問題，卻多編了一個原文沒有的日期。
完全沒有亂編，只是一直繞圈，沒有回答使用者真正問的事。
把這三種答案都壓成一個 1 到 5 分，資訊會不見。我真正想知道的是它壞在哪裡，下一版要改檢索、Prompt，還是輸出長度。
所以我把評分拆成三個面向：
| 面向 | 我在看什麼 |
|---|---|
| 有沒有亂編 | 每個事實能不能在參考資料找到根據 |
| 有沒有答到 | 是否直接處理使用者的問題 |
| 會不會囉嗦 | 有多少內容刪掉也不影響答案 |
面向不用多。我的經驗是先抓 2 到 5 個，太多反而會互相重疊。「清楚」和「邏輯通順」如果連人都分不開，AI 評審也不會突然比較懂。
每一分都要長得不一樣
只有面向還不夠。另一個坑是把評分標準寫成這樣：
| 分數 | 說明 |
|---|---|
| 1 | 很差 |
| 3 | 普通 |
| 5 | 很好 |
這張表看起來有規則，其實還是靠感覺。
我現在會把每一分寫成可以檢查的狀態。以「有沒有亂編」為例：
| 分數 | 可以觀察到的狀態 |
|---|---|
| 1 | 關鍵事實是憑空編的，主要內容找不到根據 |
| 2 | 大方向推得出來，但多個細節無法溯源 |
| 3 | 主要內容有根據，仍有少數次要細節對不上 |
| 4 | 每個主要說法都能對應到參考資料 |
| 5 | 每個說法都有根據，而且答案主動標出處 |
這裡最花時間的不是寫字，而是找邊界。3 分和 4 分到底差在哪，最好拿真實答案讓熟悉業務的人各自評一次。大家意見差很大時，不要急著怪評審模型，通常是尺還沒刻清楚。
我不再從空白頁想評分面向
一開始我也會坐在會議室裡想：「好答案應該具備哪些特質？」最後很容易列出完整、正確、清楚、專業、友善之類漂亮但重疊的詞。
後來我改看失敗案例。
先撈一批真的答壞過、被退回或被抱怨的答案，再按失敗原因分群。假設 80 個案例裡有 31 個答非所問、18 個太長、12 個編了不存在的內容，那評分面向自然就浮出來了。
這些數字只是做法示意，實際使用時要換成自己的資料，不能把別人的比例當成門檻。
我會照這個順序做：
說清楚這個 AI 的工作，以及最不能接受的失敗。
收集真實的失敗答案，不只挑好看的範例。
把失敗分成 2 到 5 群，變成評分面向。
用代表案例寫出每個分數的邊界。
先讓 2 到 3 位懂業務的人各自試打，再比較 AI 的結果。
第 5 步不能省。人類彼此都沒有共識時，追求 AI 跟人類一致沒有意義。
給評審的指令，我會要求留下理由
實際送給評審模型的內容，大致長這樣：
你要評估一個文件問答系統的答案。
使用者問題：{question}
參考資料：{context}
待評答案：{answer}
面向：有沒有亂編
1 = 關鍵事實找不到任何根據
2 = 多個細節無法溯源
3 = 主要內容有根據，少數細節對不上
4 = 每個主要說法都能對應到參考資料
5 = 每個說法都有根據，而且主動標出處
請只輸出 JSON：
{
"score": 1,
"reason": "給這個分數的具體原因",
"unsupported_claims": []
}
我會要求它列出理由和找不到根據的說法，不只回一個數字。這樣分數異常時，我才知道是答案真的有問題，還是評審理解錯了。
JSON 也要驗證 schema。AI 偶爾還是會多包一層 Markdown code fence，或把整數寫成字串。這些是程式能明確檢查的事，不需要再找另一個 AI 猜。
分數很穩，不代表它評得準
有一段時間，同一批答案的分數很穩，我就以為評估可以用了。後來抽查理由才發現，評審把「回答很長」當成「內容很完整」，即使裡面多了沒有根據的細節，還是給高分。
症狀是分數漂亮，人工抽查卻常看到長答案壓過短而正確的答案。原因不是模型故障，而是我沒有把「內容長度不代表品質」寫進規則，也沒有把「囉嗦」拆成獨立面向。
我做了三個修正：
把事實根據和文字長度分開評。
固定一組人工已經評過的案例，每次換模型或改 Prompt 都重跑。
重要樣本保留人工抽查，不讓 AI 評審變成唯一裁判。
AI 評審還可能受答案順序、模型偏好和隨機性影響。評分表只能把問題縮小，不能把這些偏差變不見。
有些事情直接跑程式比較準
如果結果有明確答案，我不會硬找 AI 評：
| 要驗什麼 | 我會用什麼 |
|---|---|
| JSON 欄位是否齊全 | Schema validation |
| 程式碼能不能跑 | 編譯與自動化測試 |
| 金額算得對不對 | 直接比對預期值 |
| 是否包含禁用字詞 | 規則或字串檢查 |
| 回答是否有根據、是否切題 | AI 評審加人工抽查 |
AI 評審最適合放在機械檢查和人工審查中間。它可以替我把覆蓋範圍放大，但不能替我定義什麼叫好，也不能替最後上線的人負責。
我現在看到一個 4.2 分，第一個反應已經不是「看起來不錯」，而是先問：這把尺怎麼刻的？誰拿真實案例校過？這兩題答不出來，那個小數點只是讓猜測看起來比較精密而已。