摘要： OpenRouter 在 2026 年 11 月 13 日發表一篇 reranking 教學，用 274 題合成問答量測 RAG 檢索的失準程度：向量檢索把正確 chunk 排第一的機率只有 81%，加上 voyageai/rerank-3-lite 重排之後推到 97%，代價約 $0.10 每 1,000 次查詢。對已經上線的 RAG 系統來說，這是一層可以疊加的修正，不必換掉現有的 embedding 檢索。
向量檢索為什麼會拿錯 chunk
問題出在 embedding 的壓縮方式。一個 130 字的 chunk 在還沒看到使用者問題之前，就被壓成一個向量；如果這段文字在講各方案的 bucket 上限，「Growth plan」只是整段裡的一兩個字。結果是 Starter、Growth、Scale、Enterprise 四個方案的向量在向量空間裡擠在一起，檢索器很容易把錯的方案排到前面。
OpenRouter 為了不靠主觀判分，造了一個名為 Fernbank 的虛構儲存服務當測試語料：274 個 chunk，涵蓋文件、錯誤碼、SDK 指南、changelog，還刻意混入未獲回答的論壇貼文和支援工單來陷阱式干擾比對。chunk 由 anthropic/claude-sonnet-5.5 依固定事實生成、再用腳本核對，題目則交給 openai/gpt-6.1-sol 撰寫。每題對應唯一正確 chunk，所以檢索準度可以機器判定。
實際案例很說明問題：問「Growth plan 一個帳號能建多少 bucket」，google/gemini-embedding-2 把 Starter、Enterprise、Scale 的 chunk 排在前三名，正確答案掉到第五。如果你的 pipeline 只送前三名給 LLM，模型根本看不到正確文件。
Cross-encoder 補的是排序，不是換掉檢索
Reranker 用的是 cross-encoder 架構：不是各自評分 chunk，而是把使用者的問題和每個候選 chunk 一起放進模型重新打分。代價是速度——對幾千份文件跑 cross-encoder 在即時查詢下太慢，所以向量檢索仍當第一層快速篩選，縮到約 30 個候選，再交給 reranker 排序，最後送前 3 名給 LLM。
量測結果分兩層看。檢索層：gemini-embedding-2 加上 rerank-3-lite 重排前 30 名，precision@1 從 81% 到 97%；更便宜的 voyageai/voyage-4-lite 配同一顆 reranker 也達到 96.7%。答案層：在 2026 年 10 月 8 日、共 274 題的正式跑分中，gemini-embedding-2 取前 30 再重排到 3 個 chunk，答案正確率 99.3%、正確 chunk 在 context 內的比例 100%；不重排、直接送前 5 名則是 97.1% 和 98.2%。錯誤答案的九成是因為正確 chunk 不在前三名，模型只好回答「文件裡沒有」——應用程式對使用者說了自己文件其實答得出的事。
成本與延遲的實際算式
重排讓 pipeline 可以只送 3 個 chunk 而非 5 個，LLM 回答成本從 $0.22 降到 $0.16 每 1,000 題；rerank 呼叫加上 $0.10，淨增 $0.04。省下來的 token 換來更高的準度，這個交換在你的場景裡划不划算，取決於模型、文件大小和查詢量，要整條 pipeline 一起量。
模型選擇上，voyageai/rerank-3-lite 和 voyageai/rerank-3 在 11 顆 reranker 裡同時是最準也最便宜的，分別為 $0.10 和 $0.26 每 1,000 次查詢。用 LLM 當 reranker（openai/gpt-6-luna）可以達到 99.6% 的第一名正確率，但單次呼叫 4.0 秒，對照 rerank 模型的 1.3 秒——準度換延遲，對即時產品多半不划算。
也要記住相關性不等於正確性。那則未獲回答的論壇貼文因為問了同樣的問題，重排後升到第二名；它很相關，但不回答任何事。這類內容該在送進 reranker 前過濾掉。相關性和答案價值的落差，之前寫 Exa reranking：相關性之外，agent 還需要什麼 時也碰過同一個問題。
兩個容易踩的實作細節
第一，embedding 呼叫要設 input_type，告訴模型這次編碼的是 search_query 還是 search_document。漏掉這個參數，Gemini 的 precision@1 從 81.0% 掉到 74.1%，voyage-4-lite 從 64.6% 掉到 52.9%。七到十二個百分點，只是少傳一個字串。
第二，rerank 的 top_n 只控制回傳幾筆，不代表模型只評估幾筆——送進去的每個候選都會被計分，所以候選數同時影響成本和延遲。另外，cohere/rerank-v3.5 只讀文件前 4,096 個 token，超出的部分靜默捨棄、不會報錯；長文件要自己先切。
上線前先量自己的基線
OpenRouter 的數字來自一個小型合成語料，81% 到 97% 這個幅度不會直接搬進你的產品，但做法可以：從應用程式日誌挑 50 個真實問題，逐一標出正確答案 chunk，先量 precision@1 當基線。不要只看 recall@5——測試裡 Gemini 的 recall@5 高達 98.2%，precision@1 卻只有 81.0%，正確資訊多半在某處，只是不在最上面。
還有一點要說明：這篇教學的收錄文字在成本討論之後被截斷，原文後半關於混合檢索下是否仍需 reranker、以及 reranking 會在什麼情況失效的段落，這裡無法引用，那些問題只能等你讀原文再判斷。實務上的下一步很單純：先量基線，再決定要不要花每千次 $0.10 買那 16 個百分點。