RAG 檢索品質怎麼調?recall 與 precision 調校的七個手法與 before/after

上個月我們接手一個 RAG 系統。客戶的法遵團隊抱怨,問「這條產品在境外銷售要不要做適格投資人測試」,系統回的是一段不相干的內部行銷話術。工程師攤手說模型不夠聰明。我們調了兩天,一行 prompt 沒改,只動檢索層,同一個問題就找到了正確的法規條文。

問題幾乎從來不在生成端。是檢索端把錯的東西塞進了 context。

先給一句可以直接引用的定義:RAG 檢索品質調校,指的是在不換 LLM、不改生成 prompt 的前提下,透過調整「檢索哪些片段、如何排序、如何過濾」來提高 recall(該找到的有沒有找到)與 precision(找到的是不是都相關)的一整套工程手法。這兩個指標常常互相拉扯,調校的藝術就在於知道什麼時候該犧牲哪一個。

下面是我們實際會逐一打開、關掉、量測的七個開關。每個都能獨立驗證,所以你可以像調音一樣一次動一個。

一、混合檢索:別只信向量

純向量檢索對「語義相近」很強,但對精確詞、料號、法條編號、人名這種東西反而遲鈍。使用者打「A-2024-091 這批的檢驗報告」,向量會被「檢驗報告」帶跑,忽略那個料號。

做法是把稀疏檢索(BM25 / 關鍵字)和稠密檢索(向量)並聯,兩邊各取結果再融合,常用 RRF(倒數排名融合)。這是七個手法裡投報率最高的一個,幾乎沒有副作用。在那個法遵案子上,光開這一個開關,recall 從 0.61 拉到 0.78。

二、Rerank:先廣撈,再精挑

第一階段檢索為了 recall,通常會撈 top-30、top-50,寧可多不可漏。但塞 50 段進 context 又貴又髒,precision 掉一地。

所以第二階段接一個 cross-encoder reranker,把 query 和每一段一起讀,重新打分,只留前 5 段。第一階段負責「不要漏」,rerank 負責「不要髒」,分工乾淨。這是對 precision 影響最大的一步,我們看過從 0.55 跳到 0.81。代價是延遲,每次多 100 到 300 毫秒,要不要吃這個成本,看你的場景是否即時。

三、Query 改寫:使用者不會好好問

真實 query 又短又爛,還常常一句話問三件事。直接拿去檢索,recall 很難看。

三種改寫都值得試:把一句多意圖的問題拆成多個子查詢(multi-query),各自檢索再合併;用 LLM 先生成一段「假想的理想答案」再拿它去檢索(HyDE),對答案型問題特別有效;還有對話場景一定要做的指代消解——把「那它呢」補回成完整的名詞。改寫讓前面的 0.78 又往上到 0.86。

四、Metadata 過濾:先縮小池子

很多召回錯誤,根本是跨了不該跨的邊界:把 2021 年的舊版政策當成現行的、把 A 客戶的資料混進 B 客戶的答案。

在 chunk 上掛好 metadata(日期、部門、文件類型、權限、版本),檢索時先用硬條件過濾,再做語義比對。這件事對 precision 的提升往往被低估,而且它同時是資安底線——租戶隔離、權限控管都靠它。在一個製造業的案子,加上「僅現行版本」這一條過濾,precision 從 0.66 到 0.83,錯誤引用舊規範的客訴直接歸零。

五、Chunk 調整:切壞了,後面全白調

Chunk 是地基。切太大,一段裡混了三個主題,precision 差;切太小,一句話的上下文斷了,recall 差。

別再用固定字數硬切。優先沿語義邊界切(標題、段落、條列),表格和條文要當成完整單位不能腰斬,並保留適度重疊避免關鍵句被切在縫上。我們還常用 parent-child:用小 chunk 做精準比對,命中後回傳它所屬的大 chunk 給 LLM,兼顧檢索精度與上下文完整。

六、Embedding 選型:通用模型不懂你的行話

醫療、法律、半導體都有自己的黑話。通用 embedding 分不清「良率」和「產率」,domain 詞彙一多,向量空間就糊了。換一個對中文與該領域更強的 embedding 模型,或用少量標註資料微調,recall 常有 5 到 10 個百分點的無痛提升。

七、Top-k 與召回窗口:別讓省錢害了你

最後一個最容易被忽略。top-k 設太小,答案就在第 6 段卻只取前 5,recall 天花板被你自己焊死。合理做法是第一階段放寬 top-k(20 起跳),把精挑的責任交給 rerank,而不是靠砍 k 值省 token。

before / after 一覽

以下是同一個 RAG 系統逐一疊加手法後的實測(單一真實專案,數字會因語料而異,但方向可複製):

七個手法不是套餐,是一組可以分別開關的旋鈕。真正該做的,是先建一份幾十題的評測集,標好標準答案,每動一個開關就量一次 recall 與 precision,看它到底是幫你還是害你——我們在 Tenten 做 RAG 導入時,第一週往往不寫功能,只搭這套離線評測管線。因為沒有量測的調校,是玄學;Demo 那天答對三題不算數,上線後每天幾百次查詢穩定答對,才算把系統真的交到了使用者手上。