2.1 檢索器在 RAG 中的作用

檢索器決定 LLM 回答前能看到哪些資料。模型再強，如果拿到的是不相關的段落，也只能根據錯的材料作答。因此，RAG 的品質上限往往先由檢索結果決定。

檢索器的工作

檢索器的輸入和輸出很單純：

• 輸入：使用者的問題。
• 輸出：知識庫裡最相關的 k 段內容，通常叫做 top-k。

這個 k 是自己決定的，常見是 3 到 10 之間。太少可能漏掉關鍵資料，太多則會塞進一堆雜訊，也會佔用模型有限的上下文空間。

為什麼不能只用關鍵字搜尋

最直覺的做法是關鍵字比對：問題裡有什麼字，就去找包含這些字的文件。這在很多場合還是很好用，但有一個明顯的問題：同一個意思可以有很多種說法。

使用者問	文件裡寫	關鍵字比對
新進員工什麼時候可以請年假？	年資滿六個月即可請特別休假	幾乎沒有共同的字，找不到
怎麼退費？	申請退款的流程如下	「退費」和「退款」不一樣，可能漏掉

人一看就知道這兩句講的是同一件事，但字面完全不同。我們需要一種看意思、而不是看字的搜尋方式，這就是接下來要講的向量檢索。

兩種檢索方式

	關鍵字檢索（稀疏）	向量檢索（稠密）
比的是什麼	字有沒有出現、出現幾次	整段話的語意
代表做法	BM25	嵌入向量加相似度搜尋
擅長	專有名詞、型號、代號、精確的字	說法不同但意思相近的問題
弱點	同義詞、換句話說	很短的代號、罕見的專有名詞可能找不準

實務上常常把兩種合在一起用（混合檢索），各取所長。不過這一章先專心講向量檢索，因為它是大部分 RAG 系統的核心。

好的檢索器要做到什麼

評估一個檢索器，通常看三件事：

• 準（Precision）：找回來的內容裡，真正有用的比例高不高。
• 全（Recall）：該找到的資料，有沒有都找到。
• 快：知識庫很大時，也要能在極短的時間內回覆。

準和全常常需要取捨。第 6 章會講怎麼用具體的指標去量它們。

向量檢索拆開來看

一套向量檢索流程可以拆成四個部分：

1. 文字怎麼變成向量（2.2、2.3）
2. 怎麼找出最接近的向量（2.4）
3. 向量要存在哪裡、怎麼選（2.5、2.6）
4. 最後用程式實際做一次（2.7）