一、引言

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

最近在做 LangChain4j 項(xiàng)目時，碰到了一個經(jīng)典又棘手的問題：RAG 召回結(jié)果的質(zhì)量太不穩(wěn)定了！

你是不是也遇到過這些坑？

• 相似度Top5的文檔里，真正相關(guān)的就一兩個；
• 大模型明明可以回答問題，但一旦RAG召回錯了方向，結(jié)果就是答非所問；
• 想用 rerank 但又不知道從哪下手，或者性能堪憂？

于是，我開始研究 LangChain4j 的 結(jié)果重排機(jī)制，終于搞懂了兩個超核心的武器：RRF（Reciprocal Rank Fusion）和 Reranker（重排序器）。

今天，就讓我用講故事的方式帶大家一起搞懂：RAG結(jié)果重排的正確姿勢！

二、RRF：復(fù)古又強(qiáng)大的重排算法

故事要從一次開會說起。

那天我們組在review項(xiàng)目搜索效果的時候，老板語重心長地說：

“召回你調(diào)得再好，排序沒調(diào)好一切白搭。你看看人家用RRF，多個召回融合一下，效果甩你幾條街?！?/p>

我當(dāng)場尷尬地笑了笑，暗地里狂查資料。于是，我遇見了 RRF ——一個“古早”但非常有用的重排方法。

1. RRF的基本概念

RRF，全稱是 Reciprocal Rank Fusion，翻譯過來就是“倒數(shù)排名融合”。

它最早是用在信息檢索（IR）領(lǐng)域的，比如TREC競賽中用來融合多個搜索系統(tǒng)的結(jié)果。

那它為啥對RAG也管用？

因?yàn)樵赗AG中，我們也常常需要從多個維度去檢索文檔，比如：

• 向量相似度排序；
• BM25 關(guān)鍵詞召回；
• 混合召回后的初始排序結(jié)果。

這些排序可能各有優(yōu)劣，有的文檔在向量里排第一，但在關(guān)鍵詞里排第十，咋辦？

RRF就來幫你綜合考慮這些排序的“相對位置”，不靠絕對分?jǐn)?shù)，而是用位置的倒數(shù)來融合。

2. RRF的計(jì)算過程

來看一個例子！

假設(shè)你有兩個候選列表：

• List A（向量召回）: doc1, doc2, doc3
• List B（關(guān)鍵詞召回）: doc3, doc2, doc4

RRF 計(jì)算是這樣的，每個文檔在每個列表中根據(jù)排名位置算一個分?jǐn)?shù)：

公式如下：

圖片

其中 k 是一個調(diào)節(jié)參數(shù)（通常為 60），避免排名靠后的影響太小。

我們計(jì)算一下 doc2 的得分：

• 在A中排名2 → 1 / (60 + 2) = 1 / 62 ≈ 0.0161
• 在B中排名2 → 1 / 62 ≈ 0.0161
• 總分 ≈ 0.0322

最后，對所有文檔按得分排序，就是融合后的新順序。

好處：

• 不依賴具體分?jǐn)?shù)（比如embedding相似度可能不好比）；
• 鮮明地獎勵那些多個列表都出現(xiàn)的文檔；
• 不需要訓(xùn)練，計(jì)算簡單，適合輕量級場景。

三、Reranker：大模型時代的重排利器

雖然 RRF 很好，但我們終究活在“大模型時代”，還是想讓模型多干點(diǎn)活。

于是我又開始摸索 LangChain4j 提供的 Reranker 能力。

說白了，它就是讓大模型參與到文檔排序中，甚至能做到“語義上最匹配”而不是“向量最接近”。

那它怎么用？我們繼續(xù)看。

1. 基本用法：幾行代碼就能跑起來

假設(shè)你已經(jīng)用了 LangChain4j 的 RAG 模板：

圖片

就這么簡單！你只需要包裹原始 Retriever，讓它用 Reranker 再排一次。

從現(xiàn)在開始，返回的 top-5 不再僅僅是向量相似度，而是“結(jié)合語義和上下文”的“模型判定最相關(guān)”的文檔。

是不是很酷！

2. 關(guān)鍵組件說明

要搞懂這個 reranker，是啥在“做決定”呢？關(guān)鍵在這幾個類：

• Reranker: 接口，代表“重排序器”的統(tǒng)一標(biāo)準(zhǔn)；
• OpenAiReranker: 用 OpenAI 實(shí)現(xiàn)的一個具體版本；
• RerankingRetriever: 將任意 Retriever 包裹成帶重排能力的新 Retriever。

你也可以實(shí)現(xiàn)你自己的 Reranker，比如用 HuggingFace 上的 bge-reranker 模型。

LangChain4j 的好處就是高度模塊化，你可以自定義任何一個部分。

3. 使用注意事項(xiàng)

說到這里，我也要潑點(diǎn)冷水：

• 性能問題：每一次重排都要發(fā)起多次 API 請求或模型推理，尤其是調(diào)用大模型的時候，開銷不?。?/li>
• token 限制：有些 reranker 模型是基于 cross-encoder，需要一次性編碼 query 和文檔對；
• 延遲較高：如果你對響應(yīng)時間很敏感，可能就不適合實(shí)時使用；
• 調(diào)參很重要：你要調(diào) topK（重排數(shù)目），以及原始Retriever返回的數(shù)量。

我踩過的坑里最大的是：

retriever返回了20條，reranker只排top5，結(jié)果大模型常常 miss 掉關(guān)鍵文檔。

后來我才意識到：文檔召回足夠廣、rerank才有用武之地。

4. 進(jìn)階使用：結(jié)合評分、多階段重排

有了基礎(chǔ)能力，我們也可以玩點(diǎn)花的。

多階段重排：

• 你可以先用向量召回Top30 → RRF融合Top15 → 再用Reranker重排Top5。
• 這樣可以兼顧速度與語義質(zhì)量。

返回帶分?jǐn)?shù)的文檔：

• LangChain4j的 Reranker 其實(shí)會生成“相關(guān)性得分”，你可以把它加權(quán)計(jì)算，甚至用于日志分析、調(diào)試評估。

本地模型加速：

• 你可以把 HuggingFace 的 bge-reranker-large、cohere-rerank 模型部署在本地，然后自定義實(shí)現(xiàn) Reranker 接口，提升性能，節(jié)省成本。

四、RRF vs Reranker：到底該選誰？

終于來到壓軸對比啦！

圖片

小米的建議：

• 輕量場景（知識庫問答、前端展示、離線處理）：先用 RRF 提高召回質(zhì)量；
• 精度優(yōu)先（法律文書、醫(yī)療對話、學(xué)術(shù)搜索）：配合 reranker 精排，提升回答質(zhì)量；
• 二者結(jié)合使用：多源召回 + RRF融合 + Reranker精排，是目前效果最好的一種組合。

五、尾聲：從“召回”走向“理解”

故事說到這里，可能你已經(jīng)意識到了：

在 RAG 任務(wù)中，光有Retriever還不夠，我們還需要能理解語義、判斷價(jià)值的排序機(jī)制。

RRF讓我們在多個角度中找到共識，Reranker則讓大模型的“智商”參與決策。