RAG 評測 eval 框架怎麼設計?黃金測試集與答案品質度量教學

先講一個我們踩過的雷。

有個製造業客戶的內部知識問答做得很漂亮,工程規範、料號、SOP 全進了向量庫,Demo 那天問十題答對十題。上線三週,產線主管截圖丟到群組:系統把「A 產線的鎖付扭力值」講成了 B 產線的規格。追下去才發現,那十題 Demo 問題,是工程師挑過的。真正的使用者問法五花八門,而我們手上根本沒有一個能量測「答錯了幾題」的機制。

這就是為什麼要先建 RAG eval 評測框架,再談優化。沒有度量,你的每一次調 prompt、換 embedding、改 chunk 大小,都只是在憑感覺賭博。

RAG eval 評測框架:先定義你在量什麼

一個可用的 RAG eval 評測框架,本質是把「答得好不好」拆成可獨立觀測的維度。RAG 的錯誤有兩個源頭:檢索錯(retrieval)和生成錯(generation)。混在一起看,你永遠不知道該修知識庫還是修模型。所以第一步是拆開。

檢索端看兩件事。召回率(recall):該被找到的正確段落,有沒有進到 top-k?這是幻覺的最大溫床——資料根本沒撈到,模型只好編。上下文精確度(context precision):撈進來的段落裡,有多少是真正相關的?雜訊太多,模型會被帶偏。

生成端也看兩件事。忠實度(faithfulness):答案裡的每一個陳述,是否都能在檢索到的上下文裡找到依據?這是控幻覺的核心指標,忠實度低就代表模型在無中生有。答案相關性(answer relevancy):回答有沒有真的對準使用者的問題,而不是答非所問地背了一段正確但無關的規範。

這四個維度,構成最小可用的評測骨架。

黃金測試集:整個框架的地基

沒有黃金測試集(golden set),上面所有指標都是空談。它是一組人工確認過的「問題 → 標準答案 → 應命中的來源段落」三元組,是你回歸測試的唯一真相。

建立時我們的原則有三個。第一,問題要來自真實使用者,不是工程師的自嗨題。上線前沒有真實流量,就去翻客服工單、內部提問紀錄、Slack 提問。第二,要涵蓋難例:多跳推理、需要跨文件彙整的、答案是「資料裡沒有」的(這類最能測出模型會不會硬掰)。第三,規模先求質不求量,50 到 100 題扎實標註,勝過 1000 題含糊的。標註時務必連「正確來源段落」一起記,否則召回率無從算起。

黃金測試集要進版控,跟程式碼一起 review。每次知識庫更新、模型換版,就跑一遍,看指標有沒有回退。這就是「可回歸」的意思。

LLM-as-judge:讓評分能規模化

忠實度、相關性這種語意判斷,人工標成本太高。現在的主流做法是 LLM-as-judge——用一個強模型當裁判,依 rubric 給每個答案打分。

要讓裁判可信,關鍵在提示工程:給明確評分準則、要求逐句比對上下文、輸出結構化分數與理由,而不是一句「還不錯」。我們的經驗是,判斷型任務(答案有沒有依據)比評分型任務(1-5 分打幾分)穩定得多,所以盡量把問題設計成二元或三元判斷。裁判本身也要驗:抽 20% 給人工複核,對齊裁判與人類的一致率,低於門檻就重寫 rubric。

順帶一提,裁判模型選型會直接影響成本與穩定度,值得先跑一輪小規模比較再定案。

一張可直接抄的評測指標範本

門檻不是抄了就對,要照場景校準——醫療、金融的忠實度門檻該逼近滿分,內部問答可以放寬。重點是先把數字釘在牆上,每次改動都對照。

把 eval 變成上線維運的一部分

評測不是上線前跑一次的驗收關卡,而是持續運行的儀表板。我們的做法是把黃金測試集接進 CI:每次改 prompt、換模型、更新知識庫,自動跑全套指標,任何維度回退就擋下部署。同時在線上抽樣真實對話,持續回灌新難例進黃金測試集,讓它跟著業務長大。

回到開頭那個製造業案子。我們補上這套流程後,第一次全量回歸就抓出忠實度只有 0.78——問題出在 chunk 切太碎,料號和扭力值被切散了。調完切分策略,忠實度拉到 0.96,產線的錯誤截圖才真正停了。

在 Tenten,我們幫客戶導入 RAG 知識系統時,黃金測試集和 eval 流程是跟著工程師一起進場的第一批交付物,不是事後補的文件。Demo 很美不算數,能被量測、能回歸、產線上有人天天在用,才算真的上線。