檢索回歸測試
AI 知識庫改版後，怎麼做 RAG 檢索回歸測試？
用版本化黃金資料集，比較語料、embedding、切塊、混合檢索或 reranker 改動前後，是否仍找得到預期來源。
文章封包
Workflows
正在更換 AI 知識庫語料、embedding、切塊、混合檢索或 reranker 的開發者
8 分鐘閱讀
01
改檢索前，先固定代表性問題與預期來源。
02
一次改一個因素，先比較檢索，再評估生成回答。
03
逐筆檢查退步案例，原因未釐清前保留回滾能力。
01
先說結論
要驗證 AI 知識庫改版後的檢索品質，先建立一份有版本的黃金資料集：每題記錄自然提問、預期 source ID 或文件、無答案案例與基準設定。改動一項語料或檢索因素後，重跑同一批問題，先比較檢索結果，再檢查遺失或新增的來源，差異能被解釋才接受新版本。
這和引用驗證不同。引用驗證從一個已產生的回答出發，檢查來源是否支持每個主張；檢索回歸測試在生成回答之前，確認改版後是否仍取回原本應該出現的證據。
02
哪些改動之後要重跑？
新增、刪除或更新來源文件，更換 embedding，調整 chunk size、metadata filter、BM25 與向量權重、top-k 或 reranker，都可能讓某些問題變好、另一些問題卻找不到原本的證據。不要只用一題 demo 判定整體成功。
- 收錄常見真實問題、已知失敗、邊界案例，以及知識庫不該回答的問題。
- 每個預期結果旁保留權威來源版本，來源真的改變時才明確更新標籤。
- 新系統與黃金答案不同時，先調查原因，不要直接把新結果 bless 成正確。
03
黃金資料集至少要記什麼？
每個案例需要穩定 ID、使用者自然問題、預期來源、禁止出現的來源、是否允許無答案，以及這題為何重要。語料版本與檢索設定要另外保存，否則兩次結果無法公平比較。
最小黃金案例
version: 1
corpus_revision: docs-2026-08-26
cases:
- id: windows-installer
query: Windows 桌面版應下載哪個檔案？
expected_sources: [release-v0.16.0]
excluded_sources: [runtime-zip]
no_answer: false
- id: enterprise-price
query: 企業版價格是多少？
expected_sources: []
no_answer: true04
固定基準，一次只改一個因素
記錄語料 revision、embedding 模型、切塊參數、filter、混合檢索權重、reranker 版本、top-k 與執行環境。能一次只改一項最好；同時改很多項時，測試可能看得出 drift，卻無法指出原因。
先比較 source-level Recall@k 或 Hit@k；排序重要時再看 MRR 或 NDCG。無答案案例與 latency 要分開保留，不要把所有數字合成一個分數，掩蓋關鍵來源消失。
05
先查檢索失敗，再看回答好不好
對每個失敗案例，依序檢查 query rewrite、取回片段、分數、source ID、filter、融合結果、reranker 與最後排序。把文件缺失、錯誤標籤、擷取失敗、metadata filter、embedding drift、切塊邊界與 reranker 變化分開。
預期來源本身也可能標錯；相反地，整體平均分數很好，也可能漏掉一個高風險問題。只有預期證據確實被取回後，才進一步評估 grounding、回答品質與引用。
06
誠實使用 Wenlan 的 maintainer drift test
Wenlan repository 維護有標籤的檢索 fixtures、只針對 retrieval 的 Recall@5、MRR、NDCG@10 快照、固定 ranking goldens，以及 main canary 使用的 ignored drift test。它偵測的是相對可信基準的漂移，不是絕對正確性。
這是 Wenlan 維護者工作流，不是已發布的 `wenlan eval` 使用者命令，也不是 hosted CI 功能。即使不用 Wenlan，你仍可把黃金資料集、來源版本與回滾決策放在自己的 repository。
僅供 Wenlan repository 維護者使用
cargo test -p wenlan-core --lib \
eval::retrieval_drift::tests::ranking_drift_vs_golden \
-- --ignored --nocapture先固定一份檢索基準
挑選代表性專案問題，記錄預期來源與版本，再開始改 embedding、切塊或 reranker。
FAQ