RAG 準不準不要靠感覺：你需要一份會打臉自己的評估集
你丟幾份文件進去，問三個你早就知道答案的問題。它答得很順，還會引用來源。大家覺得可以上線。
然後真實使用者開始問：
「如果我是年繳但第三個月取消呢？」
「Enterprise 的資料保留是不是跟 Pro 一樣？」
「你們現在支援 HIPAA 嗎？我看到 blog 說在 roadmap 裡。」
系統開始亂。它引用舊文件、拿相似但不相關的段落、把 roadmap 說成已支援、資料不足時還硬答。
這時你才會發現，你根本沒有評估 RAG。你只是被幾個漂亮回答安撫了。
RAG 評估要拆成兩層
不要直接問「答案好不好」。
要拆成：
- retrieval 有沒有找對資料
- generation 有沒有根據資料回答
這兩件事要分開看。
如果 retrieval 沒找出正確 chunk，模型回答錯很正常。這時你該修 chunk、metadata、query rewrite、rerank，不是一直改 prompt。
如果 retrieval 找到了正確 chunk，但模型仍然亂總結，才是 prompt、模型能力或答案格式的問題。
這也是 RAGAS 那篇 RAGAS: Automated Evaluation of Retrieval Augmented Generation 值得看的原因。它把 RAG 評估拆成 context precision、context recall、faithfulness、answer relevancy 這類面向。你不一定要照抄它的框架，但至少要接受一件事：RAG 不是單一分數能講完。
先做 50 題，不要幻想一步到位
第一版評估集不用大。
30 到 50 題就夠你看到很多問題。
題目不要由工程師坐在那裡幻想。要從真實場景拿：客服 ticket、sales objection、Discord / Slack 討論、站內搜尋紀錄、產品文件常見問題、業務最常被問的問題。
每題至少要標：
{
"question": "Pro plan 年繳後第三個月取消，可以退剩下月份嗎？",
"expected_answer": "標準政策下不能自動退剩餘月份，但 Enterprise 合約可能例外。",
"must_retrieve": ["pricing_policy_2026_06#refund#003"],
"must_not_use": ["pricing_policy_2025_09#refund#002"],
"answer_type": "policy_with_exception",
"should_refuse": false
}
重點是 must_retrieve。
很多人只寫 expected answer，結果完全看不到 retrieval 有沒有找對。
題型要故意刁鑽
如果你的評估集全是「免費版有幾個 seat」這種單點查詢，分數一定很好看。
但真實使用者不會這麼乖。
至少放幾種題型。
單點題
例如：「免費版支援幾個 project？」
這測基本 retrieval。
比較題
例如：「Pro 和 Enterprise 的 SSO 差在哪？」
這測 multi-hop retrieval。它需要同時找到兩個 plan 的資料。
版本題
例如：「現在的退款政策是什麼？」
這測 updated_at 和 status filter。如果模型引用 2024 舊文件，答案再順都算錯。
拒答題
例如：「CEO 私人電話是多少？」或「幫我猜客戶合約裡沒寫的折扣」。
資料裡沒有，就要拒答。拒答題一定要有，不然你測不出幻覺。
陷阱題
例如：「你們是不是已經支援 HIPAA？」但文件只寫「正在評估 HIPAA」。
這種題可以抓出模型把 roadmap 說成 shipping 的毛病。SEO 內容也常犯這個錯：把「可能」、「正在測」、「即將支援」寫成「已支援」。短期看起來比較有吸引力，長期是信任炸彈。
人工評分先用四級就好
不要一開始就搞太精緻。
我會先用 0 到 3 分：
- 3 分：答案正確、來源正確、沒有多餘推測
- 2 分：答案大致正確，但來源不完整或語氣有點過度
- 1 分：找到部分資料，但答案容易誤導
- 0 分：錯誤、引用錯來源、該拒答沒拒答
Retrieval 另外算：
- correct chunk in top 1
- correct chunk in top 5
- correct chunk after rerank
- retrieved outdated source or not
只要跑幾輪，你就會看到很清楚的模式。
如果 correct chunk 常常不在 top 20，先修資料和 retrieval。
如果 correct chunk 在 top 5，但答案仍然亂，修 prompt 或換模型。
如果答案正確但 citation 對不上，修輸出格式和 citation checking。
自動評估可以用，但不要迷信
LLM-as-judge 很方便。OpenAI 也有 agent evals guide，LangSmith、LlamaIndex、RAGAS 都有評估工具。
但如果你的內容涉及法律、醫療、金融、價格政策、合約條款，不要完全交給 judge model。
它也會看錯。
比較穩的做法是：自動評估負責初篩，人工 review 負責關鍵題和低分題。尤其是拒答題和陷阱題，一定要人工看。
評估要接進部署流程
RAG 每次改 chunk size、embedding model、reranker、prompt、資料來源，都可能讓表現變好或變壞。
所以要有一個很土的規則：
- 改 retrieval，跑 retrieval eval
- 改 prompt，跑 answer eval
- 更新文件，跑版本題和拒答題
- 分數低於門檻，不部署
一開始用 spreadsheet 都行。不要等有完美平台才開始。
結論
RAG 準不準，不能靠感覺。
你需要一份會打臉自己的評估集，裡面要有真實問題、正確來源、拒答題、版本題和陷阱題。
RAG 沒有 eval，就只是比較貴的猜答案機器。
有了 eval，你才知道自己是在改善系統，還是在把錯誤包裝得更像真的。