怎麼老實評測你的 RAG 系統

大部分 RAG 系統的評測流程長這樣:團隊蓋好,創辦人問五個問題,答案看起來不錯,出貨。三個禮拜後客戶開始抱怨答案有錯,團隊完全沒法判斷是哪一段管線壞掉。

認真做 RAG 評測不是選配。它決定了你出貨的是「平均看起來能跑」的系統,還是「真實長尾問題不會爛」的系統。

這篇是實務 playbook:兩條評測軸線、一份 golden dataset、真的能抓到 bug 的指標。

為什麼「答案看起來不錯」不夠

RAG 至少有三種不同的失敗模式,從外面看一模一樣:

1. 檢索失敗。 對的文件根本沒進 top-K,模型靠自己的參數記憶亂答(常常錯)。
2. 檢索成功,但生成沒理它。 對的文件在 context 裡,模型還是用自己原本的偏見回答。
3. 檢索成功、生成有用,但文件本身是錯的 / 過時的。 這是內容問題,不是系統問題。

當創辦人只是用眼睛看五個答案,他根本看不出來是哪一種模式在失敗。每一種要修的東西都不一樣。所以你必須分開評測檢索跟生成。

先建 golden dataset

沒這個其他都不重要。RAG 的 golden dataset 就是一串三元組:

{ question, ideal_answer, ideal_source_document_ids }

最小可用:30 題。甜蜜點:100-300 題。內容混搭:

• 簡單題。 單文件、字面比對。(健全測試。)
• 中等。 多文件整合、需要改寫。(真實使用主體。)
• 難題。 多跳推理、矛盾來源、時效相關。(暴露系統極限。)
• 超出範圍。 你的 corpus 無法回答的題目。系統應該說「不知道」,不能瞎掰。

寫這些很煩,也是整個專案 ROI 最高的工作。沒 golden 集的團隊就是矇眼飛行。

從哪裡來:真實使用者 log、客服工單、現有 FAQ。如果還沒使用者,就坐在 corpus 前面自己寫 30 題。

檢索評測:對的文件回來了嗎?

這部分最被低估。把每題只跑檢索(不跑生成),檢查理想來源 ID 有沒有出現在 top-K。

三個指標:

• Recall@K。 K 筆結果裡,對的文件有沒有出現?如果 recall@5 = 60%,在 LLM 還沒看到問題之前你就已經損失 40% 答案了。
• Precision@K。 K 筆裡有幾筆是相關的?precision 低 = LLM 在垃圾堆裡找東西。
• MRR(Mean Reciprocal Rank)。 對的文件在第 1 位 = 1.0,第 2 位 = 0.5,第 5 位 = 0.2。抓「排多前面」。越接近 1.0 越好。

2026 年,在乾淨的 corpus 上 recall@10 低於 80% 代表檢索要修了 —— 大概率是 chunk 大小、embedding 模型、或要加 hybrid search。

生成評測:給對的文件,答得對嗎?

把生成獨立出來:直接餵理想來源文件給模型(不是檢索回來的),看輸出。這告訴你 LLM 能不能用「絕對正確」的 context。

三軸要打分:

• 忠實度(Faithfulness)。 答案是不是只包含文件支持的主張?幻覺在這裡是毀滅性的。用 LLM 當 judge:「給這些文件跟這個答案,每個事實主張是不是都在文件裡?回 YES / NO 並說明理由。」
• 答案相關性。 答案有沒有回答問題?「退費政策是什麼?」答「我們有 30 天視窗」—— 相關。答「我們重視客戶」—— 不相關。
• 完整度。 有沒有涵蓋理想答案的所有要點?用部分得分:把理想答案的關鍵主張抽出來,看模型答案命中幾個。

一旦把檢索跟生成分開,你就能定位 bug。檢索壞了?修 chunking、reranking、query expansion。檢索 OK 但生成爛?換更強模型或改 system prompt。

端到端指標

除了階段性指標,還要追蹤:

• 端到端準確率。 LLM judge 自動打或人工 review。你真正在意的數字。
• 幻覺率。 每 100 答有幾個包含文件裡沒有的主張。目標 < 2%。
• 超出範圍時的拒答率。 corpus 答不出來的問題,系統有沒有說?應該 > 95%。
• 延遲 p50 / p95。 真實使用者對延遲比對 5% 準確率提升敏感得多。
• 每次 query 成本。 對 unit economics 很關鍵。

已經幫你做好的工具

你不需要從零蓋框架。2026 年現況:

• Ragas。 開源,事實標準。有 faithfulness、answer relevance、context precision/recall。pip install 指向你的資料就拿到分數。
• TruLens。 範圍類似,更 dashboard 化。
• Promptfoo。 通用 LLM eval 工具但 RAG 支援很好。
• DeepEval。 pytest 風格的 LLM 輸出斷言,適合 CI。
• Langfuse / LangSmith。 tracing + eval 一條龍,如果你已經在用做 observability 順便用。

真產品做法:Ragas 或 TruLens 跑批次評測,加上一份 30 題回歸集,每次改 prompt 或換模型都跑一次。在使用者抓到之前先抓到。

什麼時候不適合投資評測

• MVP 之前。 還在搞清楚 RAG 是不是對的方法,評測過頭了。先把第一版難看版本跑起來,再評測。
• 內部三人在用的工具。 直接問使用者。
• corpus 每天變,你沒時間更新 golden。 改追真實流量的聚合指標 —— 拒答率、引用來源、使用者讚踩 —— 跳過靜態 eval set。

真的能抓 regression 的 CI pattern

實務上這個流程有用:

1. 把 30 題回歸集存成版本控制裡的 JSON 檔。
2. 每次有意義的變動(新 chunking、新模型、新 prompt),跑一次回歸集。
3. 把它當 deploy gate:如果準確率掉 > 5% 或幻覺率上升 > 1%,擋下來查。
4. 每季用真實使用者投訴新增 10 題。

這個用 20% 的力氣抓到 80% 的 regression。

下一步

• Ragas 論文跟文件。
• RAG vs Fine-tuning —— Microsoft research 文章。
• 查這些詞:chunking 策略、hybrid search、reranking、LLM-as-judge calibration。