檢索增強生成（RAG）是一個被過度使用的術語。它承諾了很多，但在開發了一個RAG管道之後，許多人都在想為什麼它的效果不如我們預期的那麼好。
就像大多數工具一樣，RAG易於使用，但難以精通。事實上，RAG不僅僅是將文件放入向量資料庫並在頂部添加LLM。這樣做可能有效，但並非總是如此。
這本電子書旨在告訴您，當開箱即用的 RAG 無法 正常工作時該怎麼辦。在本章中，我們將探討對於次優 RAG 流程來說通常是最簡單且最快實施的解決方案 — 我們將學習有關 rerankers 的知識。
本章的視頻輔助資料。
回憶 vs. 上下文視窗
在著手解決問題之前，讓我們先來談談問題。使用 RAG，我們正在對許多文本文件進行「語義搜索」——這些文件可能有數以萬計，甚至數十億份。
為了確保在大規模情況下進行快速搜索，我們通常使用向量搜索——也就是將文本轉換為向量，將它們全部放入向量空間，並使用餘弦相似度等相似度度量標準來比較它們與查詢向量的接近程度。
為了使向量搜索正常運作，我們需要向量。這些向量基本上是將某些文本背後的“含義”壓縮成（通常為）768或1536維的向量。由於我們將這些信息壓縮成單個向量，因此會有一些信息損失。
由於這種資訊損失，我們常常看到前三（例如）的向量搜索文件會遺漏相關資訊。不幸的是，檢索結果可能會在我們的 top_k 截止值以下返回相關資訊。
如果在較低位置有相關資訊可以幫助我們的LLM制定更好的回應，我們該怎麼辦？最簡單的方法是增加我們返回的文件數量（增加top_k），並將它們全部傳遞給LLM。
我們要衡量的指標是 召回率 — 意思是「我們檢索到多少相關文件」。召回率不考慮檢索到的總文件數 — 所以我們可以操縱指標，通過返回 所有東西 來達到 完美 的召回率。