從《紅樓夢》的視角看大模型知識庫 RAG 服務的 Rerank 調優

背景介紹

在之前的文章有道 QAnything 源碼解讀中介紹了有道 RAG 的一個主要亮點在于對 Rerank 機制的重視。

從目前來看，Rerank 確實逐漸成為 RAG 的一個重要模塊，在這篇文章中就希望能講清楚為什么 RAG 服務需要 Rerank 機制，以及如何選擇最合適的 Rerank 模型。最終以完整的《紅樓夢》知識庫進行實踐。

至于為什么要用紅樓夢，答案就是作為讀了很多遍《紅樓夢》的忠實粉絲，問題的答案是不是靠譜一眼就能判斷，問題相關的片段也能快速定位，就像定位 bug 一樣快。

Rerank 是什么

以有道 QAnything 的架構來看 Rerank 在 RAG 服務中所處的環節
在這里插入圖片描述
可以看到有道 QAnything 中的 Rerank 被稱為為 2nd Retrieval, 主要作用是將向量檢索的內容進行重新排序，將更精準的文章排序在前面。通過向大模型提供更精準的文檔，從而提升 RAG 的效果。

在目前的 2 階段檢索（Embedding + Rerank）設計下，Embedding 模型只需要保證召回率，從海量的文檔中獲取到備選文檔列表，不需要保證順序的絕對準確。而 Rerank 模型負責對少量的備選文檔列表的順序進行精調，優中選優確定最終傳遞給大模型的文檔。

打個簡單的比方，目前的 Embedding 檢索類似學校教育篩選中的實驗班，從大量的學生中撈出有潛質的優秀學生進行培養。而 Rerank 則從實驗班中對學生進一步精細排序，選出少數能上清北的重點培養。

為什么不能一步到位

Embedding 檢索時會獲得問題與文本之間的相似分，以往的 RAG 服務直接基于相似分進行排序，但是事實上向量檢索的相似分是不夠準確的。

原因是 Embedding 過程是將文檔的所有可能含義壓縮到一個向量中，方便使用向量進行檢索。但是文本壓縮為向量必然會損失信息，從而導致最終 Embedding 檢索的相似分不夠準確。參考 Pipecone 對應的圖示如下所示:

在這里插入圖片描述

可以看到 Embedding 過程包含兩步：

運行單個 Transformer 計算以創建查詢向量。
將查詢向量與具有余弦相似性的文檔向量進行比較，獲取相似文檔。

而 Rerank 階段不會向量化，而是將查詢與匹配的單個文檔 1 對 1 的計算相似分，沒有向量化帶來的信息損失，必然會得到更好的效果，對應的過程如下所示：

在這里插入圖片描述

那直接執行 Rerank 是否可行呢？肯定也是不行的，Rerank 需要 1 對 1 計算相似分的，在海量的文檔中一一比對查找文檔，效率肯定是不能接受的。

除了這個原因以外，拆分 Rerank 階段也提供了更加靈活的篩選文檔的能力，比如之前介紹過的 Ragflow 就是在 Rerank 中使用 0.3 * 文本匹配得分 + 0.7 * 向量匹配得分 加權得出綜合得分進行排序，Rerank 階段可以提供類似這種靈活的選擇手段。

支持超大上下文的模型是否可以避免 Rerank

我們之所以需要提供準確的文檔，一般是因為大模型提供的窗口有限，無法塞入過多的文檔。但是目前有模型提供了更大的上下文窗口，重排是否就可有可無了呢。

Pipecone 提供的曲線圖可以看到 GPT 3.5 中存在如下所示現象：
在這里插入圖片描述

隨著塞入大模型上下文的文檔數增加，大模型從文檔中召回信息的準確性會下降。

以我實際碰到的一個例子來看，兩次檢索與重排得到的都是同樣順序的文本內容，而且需要召回的信息都出現在排名第一的位置上。當我選擇加入大模型上下文中的文檔數量為 10 時，大模型最終的回答如下所示：
在這里插入圖片描述

但是減少加入上下文的數量為 5 時，大模型最終的答案如下所示：
在這里插入圖片描述

可以看到，加入大模型的文檔過多，召回信息的準確性確實會下降。所以超大上下文窗口并不是解決所有問題的靈丹妙藥。

Rerank 模型的選擇

目前開源的 Rerank 模型選擇不如 Embedding 模型那么多，主要是下面幾個：

智源提供的 BGE 系列
有道提供的 BCE 模型
Cohere 提供的 CohereRerank 系列

由于主要考慮開源可使用的模型，因此先排除了 CohereRerank 系列模型，結合搜索的信息確定備選的模型如下所示：

bce-reranker-base_v1 有道 BCE 系列只提供了這一款 Rerank 模型，上個月 huggingface 下載量 8.7k
bge-reranker-large 這一款為 BGE 系列的經典 Rerank 模型，評價比較高，上個月 huggingface 下載量 33.2k
bge-reranker-v2-m3 這一款為智源目前推薦的多種場景的建議模型，上個月 huggingface 下載量 69.4k

參考的信息源主要是：

有道 QAnything 測評
智源的 Rerank 測評
llamaIndex 測評文章
ninehills 的博客

那個模型表現最好呢？

有道在網站上放出來的測評結果如下所示：
在這里插入圖片描述

可以看到測評得到的結果是 bce-reranker-base_v1 是略勝一籌的，當然大家都知道各家官方上給出的都是對自己有利的測評結果，但是其中對友商的測評結果大概率還是可以相信的，可以看到 bge-reranker-v2-m3 小幅領先 bge-reranker-large

另外一個測評是來自于智源網站提供的
在這里插入圖片描述

可以看到表現最好是 bge-rerank-v2-minicpm-28, 但是看了下 hugggingface 上模型大小為 10G 左右，相對 2G 左右的 bge-reranker-large 資源開銷大太多了。

綜合下載量和測評結果，bge-reranker-v2-m3 看來是當前最佳選擇，bge-reranker-large 和 bce-reranker-base_v1 可以作為備選。實際表現如何還需要進一步驗證。

動手實踐

具體的實現可以直接參考 langchain-chatchat 中的 Rerank 模塊。

此模塊主要實現的就是加載 Rerank 模型，然后計算文檔塊與問題的相似分，之后根據此相似分進行重排。

接下來的實踐過程相對簡單，將完整的《紅樓夢》導入知識庫，分片向量化，為了方便在本地的普通 CPU 筆記本上運行，我接入了百度提供的在線大模型 API 進行測試。而 Embedding 模型我使用的是 stella-base-zh-v3-1792d。

在本次測試中，我主要驗證了兩種場景：

多 Rerank 模型的效果比較，主要關注同樣的文檔使用 Rerank 模型排序后的順序差異，看哪個 Rerank 排序的結果最符合人的預期；
選擇 Rerank 模型的優勝者和無 Rerank 情況進行比較，確認是否吊打無 Rerank 的情況；

多 Rerank 模型比較

實際基于 Kimi 生成了 15 個問題，具體的問題如下所示：

紅樓夢中，賈寶玉和林黛玉第一次見面是在哪一年？
請列舉《紅樓夢》中賈府的四位主要女性角色。
《紅樓夢》中，王熙鳳為什么被稱為“鳳姐”？
賈寶玉的通靈寶玉有什么特殊之處？
林黛玉的詩作中，有一首描寫春天的詩，請找出并描述其內容。
在《紅樓夢》中，賈母為何偏愛賈寶玉？
描述《紅樓夢》中薛寶釵的性格特點。
請找出《紅樓夢》中關于“大觀園”的描述，并說明其在故事中的意義。
《紅樓夢》中，賈寶玉和林黛玉的關系是如何發展的？
請列出《紅樓夢》中提到的幾種不同的茶。
紅樓夢中，林黛玉的死因是什么？
請列舉《紅樓夢》中賈府的幾位仆人，并描述他們的角色。
《紅樓夢》中，賈寶玉和薛寶釵的婚姻是如何安排的？
紅樓夢中，賈元春的封號是什么？
請描述《紅樓夢》中賈寶玉的人生觀和價值觀。

測試中除了 Rerank 模型外，其他部分都保持一致，最終測試下來，結論如下：

bge-reranker-v2-m3 模型表現最好，bce-reranker-base_v1 和 bge-reranker-large 在不同問題中各有勝負。
bge-reranker-large 的相似分很容易出現接近 1 的高分，與實際人的直覺不完全一致
bce-reranker-base_v1 的相似分相對更均衡，經常在 0.4 ~ 0.7 之間，與常規的人的直覺更接近

當然這個測試偏向簡單驗證，有一定的主觀判斷，而且問題的數量不夠多，如果進行模型選型還是需要根據自己的數據集和問題進行進一步測試。

部分的問題的結果展示如下，下面測試結果中的第一個百分比為 Rerank 模型給出的相似分，第二個百分比為原始 Embedding 模型給出的相似度評分，可以看到其中的判斷差異：

問題 1. 紅樓夢中，賈寶玉和林黛玉第一次見面是在哪一年？

bce-reranker-base_v1
在這里插入圖片描述