檢索增強生成（RAG）是一種新興的 AI 技術棧，通過爲大型語言模型（LLM）提供額外的“最新知識”來增強其能力。
基本的 RAG 應用包括四個關鍵技術組成部分：
-
Embedding 模型：用於將外部文檔和用戶查詢轉換成 Embedding 向量
-
向量數據庫：用於存儲 Embedding 向量和執行向量相似性檢索（檢索出最相關的 Top-K 個信息）
-
提示詞工程（Prompt engineering）：用於將用戶的問題和檢索到的上下文組合成大模型的輸入
-
大語言模型（LLM）：用於生成回答
上述的基礎 RAG 架構可以有效解決 LLM 產生“幻覺”、生成內容不可靠的問題。但是，一些企業用戶對上下文相關性和問答準確度提出了更高要求，需要更爲複雜的架構。一個行之有效且較爲流行的做法就是在 RAG 應用中集成 Reranker。
01.什麼是 Reranker？
Reranker 是信息檢索（IR）生態系統中的一個重要組成部分，用於評估搜索結果，並進行重新排序，從而提升查詢結果相關性。在 RAG 應用中，主要在拿到向量查詢（ANN）的結果後使用 Reranker，能夠更有效地確定文檔和查詢之間的語義相關性，更精細地對結果重排，最終提高搜索質量。
目前，Reranker 類型主要有兩種——基於統計和基於深度學習模型的 Reranker：
基於統計的 Reranker 會彙總多個來源的候選結果列表，使用多路召回的加權得分或倒數排名融合（RRF）算法來爲所有結果重新算分，統一將候選結果重排。這種類型的 Reranker 的優勢是計算不復雜，效率高，因此廣泛用於對延遲較敏感的傳統搜索系統中。
基於深度學習模型的 Reranker，通常被稱爲 Cross-encoder Reranker。由於深度學習的特性，一些經過特殊訓練的神經網絡可以非常好地分析問題和文檔之間的相關性。這類 Reranker 可以爲問題和文檔之間的語義的相似度進行打分。因爲打分一般只取決於問題和文檔的文本內容，不取決於文檔在召回結果中的打分或者相對位置，這種 Reranker 既適用於單路召回也適用於多路召回。
02.Reranker 在 RAG 中的作用
將 Reranker 整合到 RAG 應用中可以顯著提高生成答案的精確度，因爲 Reranker 能夠在單路或多路的召回結果中挑選出和問題最接近的文檔。此外，擴大檢索結果的豐富度（例如多路召回）配合精細化篩選最相關結果（Reranker）還能進一步提升最終結果質量。使用 Reranker 可以排除掉第一層召回中和問題關係不大的內容，將輸入給大模型的上下文範圍進一步縮小到最相關的一小部分文檔中。通過縮短上下文， LLM 能夠更“關注”上下文中的所有內容，避免忽略重點內容，還能節省推理成本。
上圖爲增加了 Reranker 的 RAG 應用架構。可以看出，這個檢索系統包含兩個階段：
-
在向量數據庫中檢索出 Top-K 相關文檔，同時也可以配合 Sparse embedding（稀疏向量模型）覆蓋全文檢索能力。
-
Reranker 根據這些檢索出來的文檔與查詢的相關性進行打分和重排。重排後挑選最靠前的結果作爲 Prompt 中的Context 傳入 LLM，最終生成質量更高、相關性更強的答案。
但是需要注意，相比於只進行向量檢索的基礎架構的 RAG，增加 Reranker 也會帶來一些挑戰，增加使用成本。
03.使用 Reranker 的成本
在使用 Reranker 提升檢索相關性的同時需要着重關注它的成本。這個成本包括兩方面，增加延遲對於業務的影響、增加計算量對服務成本的增加。我們建議根據自己的業務需求，在檢索質量、搜索延遲、使用成本之間進行權衡，合理評估是否需要使用 Reranker。
Reranker 會顯著增加搜索延遲
未使用 Reranker 的情況下，RAG 應用只需執行低延遲的向量近似最近鄰 (ANN) 搜索，從而獲取 Top-K 相關文檔。例如 Milvus 向量數據庫實現了 HNSW 等高效的向量索引，可實現毫秒級的搜索延遲。如果使用 Zilliz Cloud，還能借助更加強大的 Cardinal 索引進一步提升搜索性能。
但如果增加了 Reranker，尤其是 Cross-encoder Reranker 後，RAG 應用需要通過深度學習模型處理所有向量檢索返回的文檔，這會導致延時顯著增加。相比於向量檢索的毫秒級延遲，取決於模型大小和硬件性能，延遲可能提高到幾百毫秒甚至到幾秒！
Reranker 會大幅度提高計算成本
在基礎架構的 RAG 中，向量檢索雖然需要預先使用深度學習模型處理文檔，但這一較爲複雜的計算被巧妙設計在離線狀態下進行。通過離線索引（Embedding模型推理），每次在線查詢過程只需要付出極低計算成本的向量檢索即可。與之相反，使用 Reranker 會大大增加每次在線查詢的計算成本。這是因爲重排過程需要對每個候選文檔進行高成本的模型推理，不同於前者可以每次查詢都複用離線索引的結果，使用 Reranker 需要每次在線查詢都進行推理，結果無法複用，帶來重複的開銷。這對於網頁搜索、電商搜索等高流量的信息檢索系統非常不適用。
讓我們簡單算一筆賬，看看使用 Reranker 的成本。
根據 VectorDBBench 的數據，一個能負擔每秒鐘 200次 查詢請求的向量數據庫使用成本僅爲每月 100 美元，平攤下來相當於每次查詢成本僅爲 0.0000002 美元。如果使用 Reranker，假設第一階段向量檢索返回 top-100 個文檔，重排這些文檔的成本高達 0.001 美元。也就是增加 Reranker 比單獨執行向量搜索的成本高出了 5000 倍。
雖然很多實際情況中可能只針對少量結果進行重排（例如 10 到 20 個），但是使用 Cross-encoder reranker 的費用仍然遠高於單純執行向量搜索的費用。
從另一個角度來看，使用 Reranker 相當於在查詢時負擔相當於離線索引的高昂成本，也就是模型推理的計算量。推理成本與輸入大小（文本的 Token 數）和模型本身的大小有關。一般 Embedding 和 Reranker 模型大小在幾百 MB 到幾個 GB不等。我們假設兩種模型尺寸接近，因爲查詢的文檔一般遠大於查詢的問題，對問題進行推理成本忽略不計，如果每次查詢需要重排 top-10 個文檔，這就相當於10 倍對於單個文檔離線計算 Embedding 的成本。如果在高查詢負載的情況下，計算和使用成本可能是無法承受的。對於低負載的場景，例如企業內部高價值低頻率的知識庫問答，這一成本則可能完全可以接受。
04.成本比較：向量檢索 v.s. Cross-encoder Reranker v.s. 大模型生成
雖然 Reranker 的使用成本遠高於單純使用向量檢索的成本，但它仍然比使用 LLM 爲同等數量文檔生成答案的成本要低。在 RAG 架構中，Reranker 可以篩選向量搜索的初步結果，丟棄掉與查詢相關性低的文檔，從而有效防止 LLM 處理無關信息，相比於將向量搜索返回的結果全部送進 LLM 可大大減少生成部分的耗時和成本。
舉一個貼近實際的例子：第一階段檢索中，向量搜索引擎可以在數百萬個向量中快速篩選出語義近似度最高的 20 個文檔，但這些文檔的相對順序還可以使用 Reranker 進一步優化。雖然會產生一定的成本，但 Reranker 可以在 top-20 個結果進一步挑出最好的 top-5 個結果。那麼，相對更加昂貴的 LLM 只需要分析這 top-5 個結果即可，免去了處理 20 個文檔帶來的更高成本和注意力“渙散”的問題。這樣一來，我們就可以通過這種複合方案平衡延遲、回答質量和使用成本。
05.哪種情況適合在 RAG 應用中使用 Reranker？
追求回答高精度和高相關性的場景中特別適合使用 Reranker，例如專業知識庫或者客服系統等應用。因爲這些應用中的查詢都具有很高的商業價值，提升回答準確性的優先級遠高於系統性能和控制成本。使用 Reranker 能夠生成更準確的答案，有效提升用戶體驗。
但是在網頁搜索、電商搜索這類場景中，響應速度和成本至關重要，因此不太適合使用代價高昂的 Cross-Encoder Reranker。此類應用場景更適合選用向量檢索搭配更輕量的 Score-based Reranker，從而確保響應速度，在提升搜索質量的同時降低開銷。
06.總結
相比於單獨使用向量檢索，搭配 Reranker 可以通過對第一層檢索結果的進一步精細化排序提高檢索增強生成（RAG）和搜索系統中答案的準確性和相關性。但是使用 Reranker 會增加延時和提高使用成本，因此不適合高頻高併發的應用。考慮是否使用 Reranker 時，需要在回答準確性、響應速度、使用成本間做出權衡。
如果需要在 RAG 應用中使用 Reranker，可以採用最新推出的 pymilvus 模型庫組件調用 Reranker 模型配合 Milvus 的向量檢索。同時 Zilliz Cloud 不僅提供向量數據庫這一關鍵組件，還推出了 Pipelines 功能，通過調用 API 服務一站式完成文本向量化、檢索、重排序，簡化了 RAG 應用的後端架構和降低維護成本。有興趣的讀者可以訪問鏈接(https://docs.zilliz.com/reference/python/Model) 或者瀏覽（https://milvus.io/docs ）瞭解在 Zilliz Cloud Pipelines 或者 Milvus 使用 Reranker 的詳情。