/
#RAG#檢索增強生成

RAG 技術中的 Reranking（重排序）

向量搜尋找得快，但找得不夠準——Reranking 就是那個在最後把最重要的資料推到前排的裁判。

先說結論

讀完這篇，你會搞懂三件事：

  1. 為什麼 RAG 系統光靠向量搜尋還不夠，需要 Reranking 這第二關
  2. Bi-Encoder（嵌入模型）與 Cross-Encoder（重排序模型）的本質差異
  3. 在實際 RAG Pipeline 中，Reranking 要擺在哪裡、怎麼用

從類比開始

想像你在考前去圖書館找資料。

你先去館藏目錄系統搜尋「量子力學」，系統秒回你 200 本書的書名清單——速度飛快，但這 200 本裡有入門科普、有哲學探討、有數學公式大全，良莠不齊。

你沒時間讀 200 本，所以你拿起清單，逐一翻開前幾頁，真正比對「這本書的內容跟我的考試方向有多契合？」

翻了 20 本後，你挑出最相關的 5 本帶回座位。

這就是 RAG + Reranking 的運作邏輯：

核心概念

1. RAG 的第一關：向量搜尋（Bi-Encoder）

RAG 的基本原理是：把知識庫裡的每一段文字，預先用**嵌入模型（Embedding Model）**轉成一個向量，儲存在向量資料庫。

當使用者提問時，把問題也轉成向量，然後找「方向最接近」的那些文件——這就是向量搜尋。

為什麼快？ 因為所有文件的向量是預先算好的，查詢時只要把問題向量跟資料庫向量做比較（類似餘弦相似度），速度極快，即使面對數千萬筆資料也能在 100ms 內回應。

代價是什麼？ 每一段文字必須被「壓縮」成一個固定大小的向量。這個壓縮過程會丟失細節。更致命的是：這些向量是在「還不知道使用者問題」的情況下預先計算的，所以向量代表的是文件的「通用語意」，而非「針對這個問題的相關性」。

2. 向量搜尋的盲點：Lost in the Middle

向量搜尋會傳回很多候選文件（通常 top-50 或 top-100），全部塞進 LLM 的 context window。

但研究發現，LLM 對放在 context 中間段的資訊記憶力最差，對開頭和結尾最好——這個現象叫做 "Lost in the Middle"。

所以就算搜到了正確資料，但如果它被排在第 37 個，LLM 很可能視而不見。

Reranking 的使命就是解決這個問題：把真正相關的文件推到前幾名，讓 LLM 看到最重要的內容。

3. 第二關：Reranking（Cross-Encoder）

Reranking 模型（又稱 Cross-Encoder）的工作方式完全不同：

它把「問題」和「每一篇候選文件」拼在一起，送進一個 Transformer 模型，讓模型同時看到兩者，輸出一個相關性分數（0 到 1）。

Cross-Encoder 輸入格式：
[問題] + [文件內容] → Transformer → 相關性分數

為什麼這樣更準？

因為模型在計算的當下，同時知道「問題是什麼」和「文件說了什麼」，可以做細粒度的語意比對。舉例：

問題：「蘋果公司的市值是多少？」 文件 A：「蘋果（Apple Inc.）2024 年市值突破三兆美元」 文件 B：「蘋果是富含維生素 C 的水果」

Bi-Encoder 可能因為「蘋果」這個詞的通用向量，給 B 不低的分數。 Cross-Encoder 看到「蘋果公司 + 市值」這個完整脈絡，會直接給 B 接近 0 分。

代價是什麼？ 慢。Cross-Encoder 無法預先計算，每次查詢都要即時跑一遍模型。如果資料庫有 4000 萬筆，全部跑一遍要 50 小時以上——完全不可行。

4. 兩段式漏斗架構

這就是為什麼現代 RAG 採用兩段式（Two-Stage）架構：

使用者問題
    ↓
[第一段] Bi-Encoder 向量搜尋 → 快速找出 top-100 候選文件
    ↓
[第二段] Cross-Encoder Reranking → 精準重排序，取 top-5
    ↓
送進 LLM 生成回答

第一段廣撒網、求召回率；第二段精挑細選、求精準度。兩者各司其職，缺一不可。

5. Reranking 的幾種型態

類型代表模型特色
Cross-EncoderBGE Reranker、ms-marco-MiniLM準確、輕量、開源
多向量模型ColBERT兼顧速度與精準，適合大規模部署
LLM-based RerankerRankGPT、RankLLaMA最準確，但成本高
API 服務Cohere Rerank易整合，免自行維運

實務上最常見的是直接用 Cross-Encoder 開源模型（如 BGE Reranker v2）或 Cohere Rerank API。

流程圖

常見誤解

誤解一：「Reranking 很貴，直接把 top-k 調大就好」

有人以為只要多撈幾筆文件、把 top_k=50 改成 top_k=200，LLM 自然會找到答案。

錯誤。 塞越多資料進 context 不代表效果越好。LLM 的注意力有限，"Lost in the Middle" 問題只會更嚴重；而且 token 費用也會爆炸。Reranking 的目的是精選而非擴量。

誤解二：「有了 Reranking 就可以拿掉向量搜尋，直接用 Reranker 搜全庫」

Cross-Encoder 的計算量是 O(文件數 × 查詢次數)。對一個有百萬筆資料的知識庫，這是完全無法實用的。

正確做法：一定是兩段式漏斗——先用向量搜尋把候選範圍縮到幾十~幾百筆，再用 Reranker 精排。

誤解三：「Reranking 只是排序，不影響最終答案品質」

實際資料說明一切：Databricks 研究顯示 Reranking 可讓檢索品質提升高達 48%；企業搜尋場景中，Mean Reciprocal Rank（MRR）可提升 40%，LLM 的離題率可降低 25%。Reranking 絕對不是可有可無的附加步驟。

延伸思考

  1. Hybrid Search（混合搜尋）：結合 BM25 關鍵字搜尋與向量搜尋的 first-stage，能進一步提升 Reranking 的候選品質，值得深入研究。

  2. ColBERT Late Interaction：介於 Bi-Encoder 和 Cross-Encoder 之間的架構，用多向量表示文件，在速度與準確度間取得更好的平衡——是下一代檢索架構的重要選項。

  3. LLM-as-Reranker（RankGPT）：直接用 GPT-4 或本地 LLM 做 Reranking，準確度極高但成本也高，適合對精準度要求最嚴苛的場景。

  4. Contextual Retrieval（Anthropic, 2024）：在文件 chunk 前加入「上下文前綴」再做嵌入，從源頭改善向量品質，搭配 Reranking 效果更佳。

  5. 評估指標：NDCG@K、MRR、Recall@K——理解這些指標才能客觀衡量 Reranking 是否真的有效，而不只是「感覺比較好」。

參考來源

專業審核評語 (Professional Review)

總結評分：95/100

分享