一、引言

大家好呀～我是小米，一個在知識工程和大模型圈里“打怪升級”的技術搬磚人。

最近在做 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則讓大模型的“智商”參與決策。