上一篇說，RAG 出問題時要把檢索和生成分開評。這篇就打開檢索那一端，看看裡面有哪些旋鈕可以轉。

Chunking。 把文件切成 Chunk，像替一本厚書貼索引標籤。切得太大，一個片段裡塞進太多無關內容；切得太小，一段完整說明可能被攔腰拆開。判準不是「越小越好」，而是回答這類問題需要多少上下文——如果答案往往要跨兩三段才說得清楚，那些漂亮的小片段就沒有用。

Retrieval。 同一個問題，把 Top-k 從 3、5 調到 10，可能撈回更多相關片段，也可能把雜訊一起搬上桌。搜尋結果第一頁有十筆，不代表十筆都值得看。

還有一個常被跳過的旋鈕：混合檢索。上一篇提過語意相似不等於正確，而料號、錯誤碼、版本號、人名這類東西，Embedding 特別容易把它們糊成一片，關鍵字檢索（BM25）則不會。兩路各撈一批再合併，實務上往往比反覆調 Chunk 大小有效，成本也低。

Reranking。 先由 Retriever 快速撈出候選，再讓更精細的模型重新排序，把真正貼近問題的片段往前推。

這裡會冒出一個合理的疑問：既然有更準的模型，為什麼不一開始就用它？答案在 Nogueira 與 Cho 那篇論文的做法裡——BERT reranker 是把問題和段落成對一起讀進去再打分，所以分數沒辦法事先算好，每一組「問題 × 段落」都得跑一次模型。向量檢索剛好相反：文件端的向量可以離線算完、建成索引，查詢時只比對距離，百萬筆也能秒回。

一個快但粗，一個準但貴。兩段式架構就是從這個取捨長出來的，不是因為多疊一層比較高級。

要怎麼知道轉哪個旋鈕有用？固定同一批問題，一次只動一個變因——Chunk 大小、Top-k、有沒有 Rerank——再看正確答案所在的片段有沒有被撈出來。這就是 Day 08 的 Golden Dataset 套在檢索上，指標通常叫 recall@k。

而且檢索有個生成沒有的好處：它通常是確定性的。同一個問題丟兩次，結果一樣，不必像評生成那樣重複跑很多次才看得出真實表現。改了馬上知道有沒有變好——這也是為什麼遇到 RAG 出錯時，先修檢索幾乎總是最划算的一步。

延伸閱讀

• Nogueira & Cho, Passage Re-ranking with BERT, 2019（arXiv:1901.04085）。把 BERT 當成讀「問題—段落」配對的二元分類器來重新排序，在 MS MARCO passage retrieval 排行榜登頂，MRR@10 相對前一個 SOTA 提升 27%，TREC-CAR 上也創下當時最佳。
• RAG 的原始論文見 Day 10。