RAG 結果太水？用 RRF + Reranker 重排，效果翻倍提升！
一、引言
大家好呀～我是小米，一個在知識工程和大模型圈里“打怪升級”的技術搬磚人。
最近在做 LangChain4j 項目時，碰到了一個經典又棘手的問題：RAG 召回結果的質量太不穩定了！
你是不是也遇到過這些坑？
- 相似度Top5的文檔里，真正相關的就一兩個；
- 大模型明明可以回答問題，但一旦RAG召回錯了方向，結果就是答非所問；
- 想用 rerank 但又不知道從哪下手，或者性能堪憂？
于是，我開始研究 LangChain4j 的 結果重排機制，終于搞懂了兩個超核心的武器：RRF（Reciprocal Rank Fusion）和 Reranker（重排序器）。
今天，就讓我用講故事的方式帶大家一起搞懂：RAG結果重排的正確姿勢！
二、RRF：復古又強大的重排算法
故事要從一次開會說起。
那天我們組在review項目搜索效果的時候，老板語重心長地說：
“召回你調得再好，排序沒調好一切白搭。你看看人家用RRF，多個召回融合一下，效果甩你幾條街。”
我當場尷尬地笑了笑，暗地里狂查資料。于是，我遇見了 RRF ——一個“古早”但非常有用的重排方法。
1. RRF的基本概念
RRF，全稱是 Reciprocal Rank Fusion，翻譯過來就是“倒數排名融合”。
它最早是用在信息檢索（IR）領域的，比如TREC競賽中用來融合多個搜索系統的結果。
那它為啥對RAG也管用？
因為在RAG中，我們也常常需要從多個維度去檢索文檔，比如：
- 向量相似度排序；
- BM25 關鍵詞召回；
- 混合召回后的初始排序結果。
這些排序可能各有優劣，有的文檔在向量里排第一，但在關鍵詞里排第十，咋辦？
RRF就來幫你綜合考慮這些排序的“相對位置”，不靠絕對分數，而是用位置的倒數來融合。
2. RRF的計算過程
來看一個例子！
假設你有兩個候選列表：
- List A（向量召回）: doc1, doc2, doc3
- List B（關鍵詞召回）: doc3, doc2, doc4
RRF 計算是這樣的，每個文檔在每個列表中根據排名位置算一個分數：
公式如下：
圖片
其中 k 是一個調節參數（通常為 60），避免排名靠后的影響太小。
我們計算一下 doc2 的得分：
- 在A中排名2 → 1 / (60 + 2) = 1 / 62 ≈ 0.0161
- 在B中排名2 → 1 / 62 ≈ 0.0161
- 總分 ≈ 0.0322
最后，對所有文檔按得分排序，就是融合后的新順序。
好處：
- 不依賴具體分數（比如embedding相似度可能不好比）；
- 鮮明地獎勵那些多個列表都出現的文檔；
- 不需要訓練，計算簡單，適合輕量級場景。
三、Reranker：大模型時代的重排利器
雖然 RRF 很好，但我們終究活在“大模型時代”，還是想讓模型多干點活。
于是我又開始摸索 LangChain4j 提供的 Reranker 能力。
說白了，它就是讓大模型參與到文檔排序中，甚至能做到“語義上最匹配”而不是“向量最接近”。
那它怎么用？我們繼續看。
1. 基本用法：幾行代碼就能跑起來
假設你已經用了 LangChain4j 的 RAG 模板：
圖片
就這么簡單！你只需要包裹原始 Retriever，讓它用 Reranker 再排一次。
從現在開始，返回的 top-5 不再僅僅是向量相似度，而是“結合語義和上下文”的“模型判定最相關”的文檔。
是不是很酷！
2. 關鍵組件說明
要搞懂這個 reranker，是啥在“做決定”呢？關鍵在這幾個類：
- Reranker: 接口，代表“重排序器”的統一標準；
- OpenAiReranker: 用 OpenAI 實現的一個具體版本；
- RerankingRetriever: 將任意 Retriever 包裹成帶重排能力的新 Retriever。
你也可以實現你自己的 Reranker，比如用 HuggingFace 上的 bge-reranker 模型。
LangChain4j 的好處就是高度模塊化，你可以自定義任何一個部分。
3. 使用注意事項
說到這里，我也要潑點冷水：
- 性能問題：每一次重排都要發起多次 API 請求或模型推理，尤其是調用大模型的時候，開銷不小；
- token 限制：有些 reranker 模型是基于 cross-encoder，需要一次性編碼 query 和文檔對；
- 延遲較高：如果你對響應時間很敏感，可能就不適合實時使用；
- 調參很重要：你要調 topK（重排數目），以及原始Retriever返回的數量。
我踩過的坑里最大的是：
retriever返回了20條，reranker只排top5，結果大模型常常 miss 掉關鍵文檔。
后來我才意識到：文檔召回足夠廣、rerank才有用武之地。
4. 進階使用：結合評分、多階段重排
有了基礎能力，我們也可以玩點花的。
多階段重排：
- 你可以先用向量召回Top30 → RRF融合Top15 → 再用Reranker重排Top5。
- 這樣可以兼顧速度與語義質量。
返回帶分數的文檔：
- LangChain4j的 Reranker 其實會生成“相關性得分”，你可以把它加權計算，甚至用于日志分析、調試評估。
本地模型加速：
- 你可以把 HuggingFace 的 bge-reranker-large、cohere-rerank 模型部署在本地，然后自定義實現 Reranker 接口，提升性能，節省成本。
四、RRF vs Reranker：到底該選誰？
終于來到壓軸對比啦！
圖片
小米的建議：
- 輕量場景（知識庫問答、前端展示、離線處理）：先用 RRF 提高召回質量；
- 精度優先（法律文書、醫療對話、學術搜索）：配合 reranker 精排，提升回答質量；
- 二者結合使用：多源召回 + RRF融合 + Reranker精排，是目前效果最好的一種組合。
五、尾聲：從“召回”走向“理解”
故事說到這里，可能你已經意識到了：
在 RAG 任務中，光有Retriever還不夠，我們還需要能理解語義、判斷價值的排序機制。
RRF讓我們在多個角度中找到共識，Reranker則讓大模型的“智商”參與決策。
