什麼是 RAG 評測 (eval)?上線前你該量的答案品質指標清單

RAG 評測 (RAG eval) 指的是:用一組可量化的指標,系統性地檢驗「檢索增強生成」系統從找資料到寫答案的每一步品質——包括它有沒有找對文件、有沒有照文件說話、答案跟問題貼不貼題——而不是靠人工抽看幾題就宣稱「感覺不錯」。

先講一個我們親手踩過的雷。

有個製造業客戶的內部知識問答系統,Demo 那天答得漂亮,主管當場拍板要上線。我們在部署前跑了一輪 eval,結果忠實度只有 68%。翻成白話:每三題就有一題,模型講的東西在它引用的文件裡根本找不到依據。它不是不會答,是會「自信地編」。如果那天直接上線,第一批踩雷的會是產線工程師,拿著一個查扭力規格的錯誤答案去調機台。

所以我的立場很直接:沒有 eval,就別談上線。

什麼是 RAG eval 評測,它到底在量什麼

要理解什麼是 RAG eval 評測,得先拆開 RAG 的兩段管線。第一段是檢索 (retrieval):使用者問一句話,系統從知識庫撈出最相關的幾段文件。第二段是生成 (generation):模型拿這些文件當根據,寫出一段答案。

這兩段會各自出錯,而且錯法完全不同。檢索撈錯文件,生成再強也是巧婦難為無米之炊;檢索撈對了,但生成階段自由發揮、無中生有,一樣毀掉整個答案。RAG eval 的價值就在於——它能告訴你錯是錯在哪一段。很多團隊調了三週 prompt 卻沒改善,真正的病灶其實在檢索,方向從頭就錯了。

一個能用的 eval,至少要涵蓋三個核心維度。

上線前必量的三個核心指標

忠實度 (Faithfulness)。 答案裡的每一個陳述,是否都能在檢索到的文件裡找到根據?這是幻覺控制的第一道防線。忠實度低,代表模型在編。金融、醫療這類產業,忠實度沒到位就上線,等於把法遵風險外包給機率。

答案相關性 (Answer Relevancy)。 答案有沒有真正回應使用者的問題?模型有時會忠實地引用文件,但答非所問——文件說的是對的,只是跟人家問的無關。忠實度高、相關性低,是很典型的「正確的廢話」。

檢索命中 (Context Recall / Precision)。 該撈進來的關鍵文件有沒有被撈到 (recall)?撈進來的文件裡有多少是真的相關、而非雜訊 (precision)?這一層決定了生成階段手上有沒有好牌。

把它們放在一起會更清楚:

這四個指標交叉看,幾乎能定位所有常見故障。答案爛而忠實度高、命中率低,問題在檢索;命中率高但忠實度低,問題在生成;兩邊都好卻相關性低,通常是 prompt 沒把使用者真正的意圖框住。

怎麼實際跑一輪 eval

光有指標定義不夠,你需要一份「評測集」——一組真實會被問到的問題,配上人工確認過的標準答案與應該被檢索到的來源文件。這份集子不用一開始就上千題,我們通常從 50 到 100 題起步,但每一題都要是產線上真的有人會問的。魔鬼藏在長尾裡,那些冷門但關鍵的查詢,往往是命中率崩盤的地方。

評分方式現在多半用 LLM-as-a-judge：讓另一個模型依據明確的評分準則,逐項打分。它不完美,會有偏誤,所以我們一定會抽一部分讓領域專家對照校準,確認機器打的分跟人的判斷不會系統性地偏離。校準這一步常被跳過,但跳過它,你的分數就只是一個好看卻不能信的數字。

還有一件容易忽略的事:eval 不是上線前跑一次就結束。知識庫會更新、模型會換版、使用者的問法會漂移。我們會把 eval 接進 CI,每次改動都重跑,守住一條分數底線——低於門檻就不准部署。這就是幻覺控制從「一次性檢查」變成「持續維運」的關鍵。

在 Tenten,我們進場交付 RAG 知識系統時,eval 不是驗收前補的文件,是第一週就跟客戶一起定義好的合約。因為對我們來說,Demo 答得漂亮從來不算數;能在評測集上穩定守住忠實度與命中率、而且真的有人天天在用,才算數。