RAG 檢索品質怎麼看?用白話拆解 recall 與 precision 的取捨

在 RAG 系統裡,recall(召回率)量的是「該找出來的相關文件,你找回了多少比例」;precision(精確率)量的是「你找回的文件裡,真正相關的佔多少比例」。一句話記住:recall 是找得齊,precision 是找得準。

這兩個指標常被混為一談,但它們在生產環境裡幾乎永遠是對立的。你把檢索的候選範圍放寬,找得齊了,雜訊也一起進來,找得準就掉;你把門檻收緊,找得準了,漏掉的相關資料又變多,找得齊就崩。理解這個取捨,是判斷 RAG 檢索品質的起點。

RAG recall 與 precision 到底在量什麼

假設一個知識庫裡,對某個問題真正相關的文件有 10 份。你的檢索器撈回了 8 份,其中 6 份確實相關、2 份是雜訊。

那麼 recall = 6 / 10 = 60%,意思是該找的你只找齊了六成,漏了四份。precision = 6 / 8 = 75%,意思是你撈回的東西裡有四分之一是干擾。

問題來了:這個檢索器算好還是壞?答案是——看你要它做什麼。這也是為什麼我們在客戶現場,從不單獨拿一個數字說「檢索沒問題」。

找得齊 vs 找得準,差別在哪

把兩個指標翻成白話,決策會清楚很多。

關鍵是:低 recall 的錯,使用者看不見。系統漏掉了一份關鍵合約條款,答案讀起來依然通順、依然自信,沒有人會發現少了什麼。低 precision 的錯,使用者看得見——答案開始離題、開始幻覺,大家馬上就抱怨。

所以團隊常常在「優化」看得見的問題,卻讓看不見的漏檢默默累積。這是我們踩過的雷。

不同場景,該優先哪一個

該優先找得齊(recall)的場景:後果不對稱、漏掉會出事的地方。

一家做企業放款的客戶,要用 RAG 幫審查人員把借款人所有相關的財報附註、擔保條款、關聯交易撈出來。這裡漏一份,可能就是一筆壞帳。多撈幾份不相關的?審查人員自己會略過,頂多多花兩分鐘。這種場景我們會刻意把 recall 拉高,寧可多給,不能漏給,再靠後段的 rerank(重排序)和引用標註,讓人快速判斷哪些真的該看。醫療病歷檢索、法遵盡職調查、專利檢索,邏輯都一樣。

該優先找得準(precision)的場景:答案會直接給終端使用者、沒有人做二次把關。

零售客服的 AI Copilot 就是典型。使用者問退貨政策,系統只要把最相關的那一兩段撈準即可。這時候你若為了「找得齊」把二十段模稜兩可的內容全塞進上下文,模型反而會把過期政策、他國政策混進答案,幻覺率飆升。這種場景我們寧可窄一點、準一點,漏掉的邊角問題交給「查無資料,請轉真人」的兜底流程,也不讓它亂答。

判斷原則其實很簡單:下游有人把關,就往 recall 靠;答案直接見客、無人覆核,就往 precision 靠。

怎麼實際去調這個取捨

recall 和 precision 不是只能二選一,中間有很多工程手段可以把兩條曲線一起往上推。

第一,擴大候選再精排。先用向量檢索加關鍵字檢索(hybrid search)把 recall 撐開,例如一次撈 50 份候選,確保該找的都在池子裡;再用 reranker 把最相關的 5 份選出來餵給模型,把 precision 拉回來。這是我們在多數專案的預設架構。

第二,切塊(chunking)策略決定上限。切得太大,一塊裡混太多主題,precision 天生就差;切得太碎,語意被切斷,recall 又會漏。這件事沒有通解,只能拿真實查詢去測。

第三,一定要有評測集。沒有一組標好「這個問題的正確答案該來自哪幾份文件」的黃金題庫,你連 recall、precision 是多少都算不出來,所謂「優化」全是憑感覺。

我們在客戶現場的做法,是先花時間跟業務單位一起標出 50 到 100 題的評測集,把 recall 和 precision 各自量出來,再依這個系統的下游有沒有人把關,決定要往哪一邊調。Demo 裡答對三題不算數;放進真實查詢分布、兩個指標都站得住、業務願意每天用,才算數。

<span style="opacity:0"> </span>