Reranking
為什麼重要
深度解析
之所以需要重新排序，是因為快速檢索與準確檢索是兩個不同的問題。RAG 或語意搜尋管線的第一階段，必須在幾毫秒內篩選數百萬個區塊，因此得仰賴近似方法：雙編碼器嵌入模型各自將查詢與每份文件轉為向量，或者由 BM25 在完全不理解語意的情況下，根據關鍵字重疊程度評分。這些方法通常能將正確文件放入前 50 名，卻無法妥善排定這 50 項的先後順序。重新排序器取得這組候選項目後，會套用一個若用於整個語料庫便慢得難以接受的模型——通常是同時讀取查詢與一份文件的交叉編碼器——重新排列清單，讓真正相關的區塊升到最前面。最終的 top-k 通常只有 3–10 個區塊，這些內容才會組成提示詞。
雙編碼器與交叉編碼器
兩個階段的效能差距源自架構。雙編碼器會為每段文字各產生一個向量：查詢嵌入一次，每份文件也各自嵌入一次，通常事先離線完成，而相關性只是兩個點之間的餘弦相似度。搭配近似最近鄰索引時，這種做法速度極快；但模型從未同時查看查詢與文件，因此無法建立一邊的特定字詞與另一邊特定字詞之間的互動關係。交叉編碼器則正好相反：查詢與單一候選文件會串接為一個輸入，再一同送入 Transformer，由模型直接輸出相關性分數。由於兩段文字中的每個 token 都能注意另一段的每個 token，它可掌握否定、精確限制及多步驟措辭等細微差異，而嵌入相似度經常會遺漏這些差異。
問題在於成本。為 50 個候選項目評分，代表要分別進行 50 次前向傳播；由於查詢要到收到請求時才會得知，因此無法事先計算這些配對。這就是交叉編碼器從不用於數百萬份文件的完整語料庫，也是起初要拆成兩個階段的原因：雙編碼器負責召回率，將正確文件放進候選集；交叉編碼器負責精確率，將這些文件排在正確位置。
實務上的重新排序器
加入重新排序器通常有兩種方式。Cohere Rerank、Voyage AI 的 rerank 端點等託管 API，可在單一請求中接收一項查詢與一份文件清單，再傳回分數——不需自行執行基礎設施，但會多一次網路呼叫，且必須按請求計費。開放權重模型則以 BAAI 的 bge-reranker 家族和 Jina AI 的重新排序器為主，均可從 Hugging Face 取得，並在單張 GPU 上執行；候選集較小時，甚至可使用 CPU，既能將資料留在內部，成本也更容易預測。
無論採用哪一種方式，整合模式都相同：先取回較多候選項目，通常是 top 20–100，來源往往是結合向量資料庫與 BM25 的混合搜尋；接著重新排序，僅保留 top 3–10，其餘全部捨棄。有些團隊完全跳過專用模型，直接提示一個大型語言模型，要求它以零樣本方式排列候選項目；這確實可行，清單式 LLM 重新排序器也可能有不錯表現，但針對這項用途打造的交叉編碼器，每次查詢的成本通常低一到兩個數量級。
它救不了糟糕的檢索
常見的誤解，是以為加入重新排序器便能挽救薄弱的搜尋管線。它辦不到，因為重新排序只能改變第一階段已傳回內容的順序：若相關區塊從未進入候選集，重新排序器根本看不到它，再精準的評分也無法將它找回。第一階段為所有下游流程設下了無法突破的召回率上限。這也帶來一項實際的除錯原則：端對端檢索品質不佳時，應分別衡量各個階段。先檢查正確區塊是否出現在前 50 名內；若沒有，就是檢索問題，應修正嵌入、切塊方式，或加入混合搜尋；若有出現卻排名太低，才是重新排序問題。忽略這項區別的團隊，經常花上數週調整重新排序器，最後才發現改善幅度早就受限於第一階段。
延遲預算
重新排序是一項取捨：以額外的延遲和成本，換取更好的排列順序。自行託管的交叉編碼器為 50 組查詢–文件配對評分時，通常會增加數十至數百毫秒，視模型規模與文件長度而定；託管 API 還會再增加一次網路往返。可調整的參數很直接：減少重新排序的候選數量，例如採用 top 20 而非 top 100；評分前截短文件；使用較小模型；或快取重複查詢的分數。
這項取捨是否值得，取決於應用程式。直接服務使用者的助理原本就要花數秒生成答案，額外 100–300 毫秒通常無法察覺，而相關性的改善能直接減少離題上下文造成的幻覺。對於自動完成式搜尋或高 QPS 內部服務，團隊往往只為較困難的查詢重新排序——例如很長、意思不明確，或第一階段信心分數偏低的查詢——簡單查詢則直接通過。在正式環境檢索系統中，務實的預設做法是：一律重新排序，除非能證明成本無法承受。