專業級語意搜尋最佳化：利用 Cohere AI、BGE 及 Jina 實作精準結果重排

2024-09-04科技

專業級語意搜尋最佳化：利用 Cohere AI、BGE Re-Ranker 及 Jina Reranker 實作精準結果重排

1. 簡介

1.1 RAG

在說重排工具之前，我們要先了解一下 RAG。

檢索增強生成（RAG）是一種新興的 AI 技術棧，透過為大型語言模型（LLM）提供額外的「最新知識」來增強其能力。

基本的 RAG 套用包括四個關鍵技術組成部份：

Embedding 模型 ：用於將外部文件和使用者查詢轉換成 Embedding 向量

向量數據庫 ：用於儲存 Embedding 向量和執行向量相似性檢索（檢索出最相關的 Top-K 個資訊）

提示詞工程（Prompt engineering） ：用於將使用者的問題和檢索到的上下文組合成大模型的輸入

大語言模型（ LLM ）：用於生成回答

上述的基礎 RAG 架構可以有效解決 LLM 產生「幻覺」、生成內容不可靠的問題。但是，一些企業使用者對上下文相關性和問答準確度提出了更高要求，需要更為復雜的架構。一個行之有效且較為流行的做法就是在 RAG 套用中整合 Reranker。

語意搜尋提供基於文本段落的上下文含義的搜尋功能。它解決了替代方法（關鍵字搜尋）的局限性。
例如我們來查詢：「吃飯的地方」。使用語意搜尋模型就能夠自動將其與「餐館」聯系起來，因為它們的含義相似。而透過關鍵字搜尋卻無法做到這一點，因為搜尋結果將局限於「地點」、「去」和「吃」等關鍵字。
這就像是與搜尋引擎進行一場對話，它不僅理解你詢問的內容，還理解你為什麽要詢問。這正是自然語言處理、人工智能和機器學習的魅力所在。它們共同努力理解使用者的查詢、查詢的上下文以及使用者的意圖。語意搜尋研究單詞之間的關系或單詞的含義，以提供比傳統關鍵詞搜尋更準確、更相關的搜尋結果。

1.2 Reranker

Reranker 是資訊檢索（IR）生態系中的一個重要組成部份，用於評估搜尋結果，並進行重新排序，從而提升查詢結果相關性。 在 RAG 套用中，主要在拿到向量查詢（ANN）的結果後使用 Reranker，能夠更有效地確定文件和查詢之間的語意相關性，更精細地對結果重排，最終提高搜尋質素。

目前， Reranker 類別主要有兩種 ——基於統計和基於深度學習模型的 Reranker：

基於統計的 Reranker 會匯總多個來源的候選結果列表，使用多路召回的加權得分或倒數排名融合（RRF）演算法來為所有結果重新算分，統一將候選結果重排。這種類別的 Reranker 的優勢是計算不復雜，效率高，因此廣泛用於對延遲較敏感的傳統搜尋系統中。

基於深度學習模型的 Reranker，通常被稱為 Cross-encoder Reranker。由於深度學習的特性，一些經過特殊訓練的神經網絡可以非常好地分析問題和文件之間的相關性。這類 Reranker 可以為問題和文件之間的語意的相似度進行打分。因為打分一般只取決於問題和文件的文本內容，不取決於文件在召回結果中的打分或者相對位置，這種 Reranker 既適用於單路召回也適用於多路召回。

1.3 Reranker 在 RAG 中的作用

將 Reranker 整合到 RAG 套用中可以顯著提高生成答案的精確度，因為 Reranker 能夠在單路或多路的召回結果中挑選出和問題最接近的文件。此外，擴大檢索結果的豐富度（例如多路召回）配合精細化篩選最相關結果（Reranker）還能進一步提升最終結果質素。使用 Reranker 可以排除掉第一層召回中和問題關系不大的內容，將輸入給大模型的上下文範圍進一步縮小到最相關的一小部份文件中。透過縮短上下文， LLM 能夠更「關註」上下文中的所有內容，避免忽略重點內容，還能節省推理成本。

上圖為增加了 Reranker 的 RAG 套用架構。可以看出，這個檢索系統包含兩個階段：

在向量數據庫中檢索出 Top-K 相關文件，同時也可以配合 Sparse embedding（稀疏向量模型）覆蓋全文檢索能力。

Reranker 根據這些檢索出來的文件與查詢的相關性進行打分和重排。重排後挑選最靠前的結果作為 Prompt 中的 Context 傳入 LLM，最終生成質素更高、相關性更強的答案。

但是需要註意，相比於只進行向量檢索的基礎架構的 RAG，增加 Reranker 也會帶來一些挑戰，增加使用成本。

1.4. 使用 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 的成本。

根據 VectorDB Bench 的數據，一個能負擔每秒鐘 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 的成本。如果在高查詢負載的情況下，計算和使用成本可能是無法承受的。對於低負載的場景，例如企業內部高價值低頻率的知識庫問答，這一成本則可能完全可以接受。

1.5 成本比較：向量檢索 v.s. Cross-encoder Reranker v.s. 大模型生成

雖然 Reranker 的使用成本遠高於單純使用向量檢索的成本，但它仍然比使用 LLM 為同等數量文件生成答案的成本要低。 在 RAG 架構中，Reranker 可以篩選向量搜尋的初步結果，丟棄掉與查詢相關性低的文件，從而有效防止 LLM 處理無關資訊，相比於將向量搜尋返回的結果全部送進 LLM 可大大減少生成部份的耗時和成本。

舉一個貼近實際的例子：第一階段檢索中，向量搜尋引擎可以在數百萬個向量中快速篩選出語意近似度最高的 20 個文件，但這些文件的相對順序還可以使用 Reranker 進一步最佳化。雖然會產生一定的成本，但 Reranker 可以在 top-20 個結果進一步挑出最好的 top-5 個結果。那麽，相對更加昂貴的 LLM 只需要分析這 top-5 個結果即可，免去了處理 20 個文件帶來的更高成本和註意力「渙散」的問題。這樣一來，我們就可以透過這種復合方案平衡延遲、回答質素和使用成本。

1.6. Reranker 使用場景

追求回答高精度和高相關性的場景中特別適合使用 Reranker，例如專業知識庫或者客服系統等套用 。因為這些套用中的查詢都具有很高的商業價值，提升回答準確性的優先級遠高於系統效能和控制成本。使用 Reranker 能夠生成更準確的答案，有效提升使用者體驗。

但是在 網頁搜尋、電商搜尋 這類場景中，響應速度和成本至關重要，因此不太適合使用代價高昂的 Cross-Encoder Reranker。 此類套用場景更適合選用向量檢索搭配更輕量的 Score-based Reranker，從而確保響應速度，在提升搜尋質素的同時降低開銷。

相比於單獨使用向量檢索，搭配 Reranker 可以透過對第一層檢索結果的進一步精細化排序提高檢索增強生成（RAG）和搜尋系統中答案的準確性和相關性。但是使用 Reranker 會增加延時和提高使用成本，因此不適合高頻高並行的套用。考慮是否使用 Reranker 時，需要在回答準確性、響應速度、使用成本間做出權衡。

重排器在提高檢索相關性的同時，也會增加延遲和計算成本。因此，在檢索質素、搜尋延遲、使用成本之間進行權衡之後，當前可選擇的重排工具並不多， 下面介紹三款：Cohere Rerank 、 BGE Re-Ranker、Jina Reranker。

2.Cohere AI

公司介紹

Aidan Gomez（行政總裁）、Nick Frosst 和 Ivan Zhu 於 2019 年創立了 Cohere。
其中 Aidan Gomez 於 2017 年 6 月與人合著論文【Attention Is All You Need】，這個的分量大家都知道，在此不贅述。 2023 年初，YouTube 前財務長 Martin Kon（總裁兼營運總監）加入團隊。

目標：構建大模型基礎設施

Gomes : 「剛開始時，我們並不真正知道我們想要構建什麽產品… 我們只是專註於構建基礎設施，以使用我們可以獲得的任何計算在超級電腦上訓練大型語言模型。很快在我們啟動 Cohere 後，GPT-3 出現了，這是一個巨大的突破時刻，非常有效，並給了我們 [一個指示]，表明我們正在走上正確的道路。」

2.1 產品功能

Cohere 為各種閱讀和寫作任務訓練大型語言模型 (LLMs)，例如摘要、內容建立和情感分析。
其語言模型針對三個主要用例進行了最佳化：

檢索文本（retrieving text）Embed（嵌入）Semantic Search（語意搜尋）Rerank（重新排名）

生成文本（generating text）Summarize（總結）Generate（生成）Command Model：遵循業務應用程式的使用者命令

分類文本（ classifying text）

根據您的私密 / 安全要求，有多種方式可以存取 Cohere：

Cohere 的 API：這是最簡單的選擇，只需從儀表板中獲取一個 API 鍵，並開始使用 Cohere 托管的模型。

雲人工智能平台：此選項提供了易用性和安全性的平衡。您可以在各種雲人工智能平台上存取 Cohere，如 Oracle 的 GenAI 服務、AWS 的 Bedrock 和 Sagemaker 平台、谷歌雲和 Azure 的 AML 服務。

私有雲部署：Cohere 的模型可以在大多數虛擬私有雲（VPC）環境中進行私有部署，提供增強的安全性和最高程度的客製。有關資訊，請聯系銷售人員。

2.2 商業模式

Cohere 承擔著構建每個模型的大量前期成本和持續的推理成本。
它透過基於使用量的定價來收回成本，並提供三種不同的定價等級：

免費：存取所有 Cohere API 端點，並限速使用，用於學習和原型設計。

產品：增加對所有 Coheres API 端點的存取速率限制、增強客戶支持以及根據提供的數據訓練自訂模型的能力。
Cohere 根據其所有 API 端點的 Token 數量（Token 基本上是數碼、字母或符號）進行收費，端點的價格各不相同，從每個 Token 0.0000004 美元（嵌入）到 0.001 美元（重新排序）不等。

企業：專用模型例項、最高級別的支持和自訂部署選項。企業級的定價未公開。

2.3 Cohere Rerank 3

Cohere Rerank 是在業界被廣泛使用的重排工具，它通常整合在 LangChain 和 LlamaIndex 框架中，使用相對簡單。

其背後公司 Cohere 的來頭不簡單。Cohere 成立於 2019 年，由曾在 Google Brain 和 Cortex 工作的研究人員和工程師創立，其聯合創始人之一 Aidan Gomez，是 Transformers 架構的作者之一。

根據不完全統計，Cohere 累計融資已經超過 4.45 億美元。今年 3 月，還爆出 Cohere 的新一輪融資已進入後期談判階段，籌集超 5 億美元資金，估值有望達到 50 億美元。

今年 4 月， Cohere 釋出了 Rerank 3，各方面都提升了不少，包括：

4k 上下文長度可顯著提高較長文件的搜尋質素

能夠搜尋多方面和半結構化數據，如電子郵件、發票、JSON 文件、程式碼和表格

覆蓋 100 多種語言

改善延遲並降低總體擁有成本 (TCO)

不過，它是商業閉源的。原本每 1000 次搜尋，使用者需要花費 1 美元，在升級到 Rerank 3 之後，每 1000 次搜尋，需要 2 美元。

2.4 Cohere 使用

Cohere 為各種閱讀和寫作任務訓練大型語言模型 (LLMs)，例如摘要、內容建立和情感分析。其語言模型針對三個主要用例進行了最佳化：檢索文本（retrieving text）、生成文本（generating text）和分類文本（ classifying text）。

Cohere 為企業提供 API 端點，以利用其 LLMs 和許多部署選項，使企業能夠透過 AWS 等雲合作夥伴或 Cohere 的托管雲安全地儲存數據。為了更高效地幫助其 LLMs 客戶，Cohere 還提供客製模型培訓服務。

官網 : https://cohere.com

github : https://github.com/cohere-ai/cohere-python

文件：https://docs.cohere.com

基於 Cohere AI 實作語意搜尋

準備
1、安裝庫

pip install cohere

2、獲取秘鑰

https://dashboard.cohere.ai/

import cohereimport numpy as npimport reimport pandas as pdfrom tqdm import tqdmfrom datasets import load_datasetimport umapimport altair as altfrom sklearn.metrics.pairwise import cosine_similarityfrom annoy import AnnoyIndeximport warningswarnings.filterwarnings('ignore')pd.set_option('display.max_colwidth', None)

api_key = ''co = cohere.Client(api_key)

獲取問題分類數據集
這裏將使用 trec 數據集來演示，trec 數據集由問題及其類別組成。

# 獲取數據集 dataset = load_dataset( "trec" , split= "train" ) # 將其匯入到pandas的dataframe中，只取前1000行 df = pd.DataFrame(dataset)[:1000] # 預覽數據以確保已正確載入 df.head(10)

文件嵌入

可以使用 Cohere 對問題文本進行嵌入。
使用 Cohere 庫的 embed 函數對問題進行嵌入。生成一千個這樣長度的嵌入大約需要 15 秒鐘。

# 獲取嵌入 embeds = co.embed(texts=list(df['text']), model= "large" , truncate= "RIGHT" ).embeddings # 檢查嵌入的維度 embeds = np.array(embeds) embeds.shape

使用索引和最近鄰搜尋進行搜尋
使用 annoy 庫的 AnnoyIndex 函數，一種最佳化快速搜尋的方式儲存嵌入。
在給定集合中找到距離給定點最近（或最相似）的點的最佳化問題被稱為最近鄰搜尋。
這種方法適用於大量的文本（其他選項包括 Faiss、ScaNN 和 PyNNDescent）。

構建索引後，我們可以使用它來檢索現有問題的最近鄰，或者嵌入新問題並找到它們的最近鄰。

# 建立搜尋索引，傳入嵌入的大小 search_index = AnnoyIndex(embeds.shape[1], 'angular' ) # 將所有向量添加到搜尋索引中 for i in range(len(embeds)): search_index.add_item(i, embeds[i]) search_index.build(10) # 10 trees search_index.save( 'test.ann' )

尋找數據集中範例的鄰居
如果我們只對數據集中的問題之間的距離感興趣（沒有外部查詢），一種簡單的方法是計算我們擁有的每對嵌入之間的相似性。

# 選擇一個範例（我們將檢索與之相似的其他範例） example_id = 7 # 檢索最近的鄰居 similar _item_ ids = search _index.get_ nns _by_ item(example_id,10, include_distances=True) # 格式化並打印文本和距離 results = pd.DataFrame(data={'texts': df.iloc[ similar_item_ids[0 ]]['text'], 'distance': similar_item_ids[1]}).drop(example_id) print(f"問題：'{df.iloc[ example_id ][ 'text' ]}'\n最近的鄰居:") results

尋找使用者查詢的鄰居

我們可以使用諸如嵌入之類的技術來找到使用者查詢的最近鄰居。
透過嵌入查詢，我們可以衡量它與數據集中專案的相似性，並確定最近的鄰居。

query = "世界上最高的山是什麽?" # 獲取查詢的嵌入 query_embed = co.embed(texts=[query], model= "large" , truncate= "RIGHT" ).embeddings # 檢索最近的鄰居 similar_item_ids = search_index.get_nns_by_vector(query_embed[0],10, include_distances=True) # 格式化結果 results = pd.DataFrame(data={'texts': df.iloc[similar_item_ids[0]]['text'], 'distance': similar_item_ids[1]}) print(f"問題:'{query}'\n最近的鄰居:") results

參考連結：

矽谷科技評論：Cohere，為企業提供大模型
https://mp.weixin.qq.com/s/H-FNecz6rhfVkWg_ayoKKg

如何使用 Cohere AI 文本嵌入技術實作語意搜尋
https://mp.weixin.qq.com/s/wWeYopgO3t6vyjHlA85sBQ

每個人都能做 NLP 開發：cohere 及開源平替測試
https://www.bilibili.com/video/BV1ov4y1U7Au/

3.BGE Re-Ranker v2.0

近日，智源團隊再度推出新一代檢索排序模型 BGE Re-Ranker v2.0，同時擴充套件向量模型 BGE 的「文本 + 圖片」混合檢索能力。

BGE Re-Ranker v2.0 支持更多語言，更長文本長度 ，並在英文檢索基準 MTEB、中文檢索基準 C-MTEB、多語言檢索基準 MIRACL、LLaMA-Index Evaluation 等主流基準上取得了 state-of-the-art 的結果。

BGE Re-Ranker v2.0 借助分層自蒸餾策略進一步最佳化推理效率 ，適度的開銷即可換取顯著的效能收益。

BGE-v1.5、BGE-M3 以融入 visual token 的方式進一步新增「文本 + 圖片」混合檢索能力 ，同時保持優異的文本檢索效能。

上述模型現已透過 Hugging Face、Github 等平台釋出，采用免費、商用特許的開源協定：

https://github.com/FlagOpen/FlagEmbedding

https://huggingface.co/BAAI

3.1技術亮點

圖 1 RAG pipline

如圖 1 所示，檢索排序模型是資訊檢索及 RAG pipeline 中的重要組成部份。與向量模型與稀疏檢索模型相比，檢索排序模型會利用更加復雜的判定函數以獲得更加精細的相關關系。通常，系統會首先借助向量模型（BGE-M3-Dense）與稀疏檢索模型（BGE-M3-Sparse）分別從向量數據庫與倒排索引中初步獲取粗力度的候選文件（coarse-grained candidates）。緊接著，系統會進一步利用排序模型（BGE Re-Ranker）進一步過濾候選集，並最終獲得精細的文件集（fine-grained candidates），以支持下遊大語言模型完成檢索增強任務（RAG）。

圖 2

BGE Re-Ranker v2.0 系列排序模型采用了兩種不同尺寸的模型基座：
BGE Re-Ranker v2-LLM（如圖 2A） ：基於 MiniCPM-2B，Gemma-2B 等效能卓越的輕量化大語言模型。
BGE Re-Ranker v2-M3（如圖 2B） ：基於效能出色、參數量更小的 BGE-M3-0.5B 速度更快 。
所有模型均透過多語言數據訓練產生，具備多語言檢索的能力 。例如：BGE Re-Ranker v2-MiniCPM-2B 大幅提升了中英文檢索能力 ，而 BGE Re-Ranker v2-Gemma-2B 與 BGE Re-Ranker v2-M3 則在多語言檢索任務中取得了最佳的檢索效果（註：BGE Re-ranker v2.0 系列模型訓練數據配比見 GitHub 倉庫說明）。
為了進一步提升模型推理效率，BGE Re-Ranker v2.0 采取了分層自蒸餾訓練策略（如圖 2C） 。具體而言，模型最終排序得分（S(0)）被用作教師訊號，利用知識蒸餾的方式，模型的各中間層也被學習並賦予了排序能力。 在實際套用中，使用者可以基於具體場景的算力條件及時延限制靈活選擇排序模型的層數 。
BGE 系列向量模型擴充套件「文本 + 圖片」混合檢索功能 。透過引入由 CLIP 模型所生成的 visual token，BGE 得以獲得「文本 + 圖片」混合建模能力。值得註意的是，擴增 visual token 的訓練僅僅作用在 visual tokenizer 之上，而原本的 BGE 模型（BGE v1.5，BGE M3）參數保持不變。 因此，在獲得混合建模能力的同時，BGE 模型出色的文本檢索能力得以完全保持 。

3.2效能評測

BGE Re-Ranker v2.0 系列模型在英文、中文、多語言主流基準的檢索效能評測結果如下：

1. 英文檢索評測基準

英文評測 MTEB/Retrival 結果如下（表 1）：

BGE Re-Ranker v2 首先對 BGE-v1.5-large 的 top-100 候選集進行重排。實驗結果顯示，BGE Re-Ranker v2-Gemma-2B 取得了最為出色的效果，檢索精度得 以大幅提升 6% 。與此同時，透過分層自蒸餾策略獲得的中間層排序結果（BGE Re-Ranker v2-MiniCPM-28 vs. BGE Re-Ranker v2-MiniCPM-40）很好的保持了最終層的檢索精度。此外，在切換至效能更為出色的向量模型 E5-Mistral-7B 之後（仍舊重拍其 top-100），檢索精度獲得了進一步提升，平均檢索等分（NGCG@10）達到了 60.4 ，相較原本的 embedding-only 的結果 56.85 提升了近 4%，這一結果也是目前 BEIR 基準上的最佳評測結果。[1][2]。

2. 中文檢索評測基準

在中文評測 C-MTEB/Retrival 中，BGE Re-Ranker v2 同樣對 BGE- v1.5-large 的 top-100 候選集進行重排。與英文結果相類似，BGE Re-Ranker v2-MiniCPM-2B 取得了最優檢索質素，且中間層排序結果（BGE Re-Ranker v2-MiniCPM-2B-layer 28）仍舊充分保持最終層的檢索精度。

3. 多語言檢索評測基準

在多語言評測 MIRACL 中（表 3），BGE Re-Ranker v2 對 BGE-M3 的 top-100 候選集進行重排。與先前結果不同的是，BGE Re-Ranker v2-Gemma-2B 綜合效果位居首位，而 BGE Re-Ranker v2-M3 則以較小的模型尺寸（0.5B）取得了與之相近的效果。上述結果也反映了各個預訓練模型基座在不同語言下的效能差異。

4. RAG 評測基準

在 Llama Index 所提供的 RAG 評測基準中 [3]，我們使用 BGE Re-Ranker v2 及多種 baseline re-ranker 對不同的 embedding 模型 (bge v1.5 large, bge-m3, openai-te3, mxbai-embedding) 的召回結果進行重排。如下表所示（表 4），BGE Re-Ranker v2 可以大幅提升各個 embedding model 在 RAG 場景下的精度。同時，BGE Re-Ranker v2 搭配 bge-m3 可以獲得最佳的端到端檢索質素。

5. 「文本 + 圖片」混合評測基準

最後，在「文本 + 圖片」混合檢索的任務中（表 4），Visualized BGE 在 WebQA、CIRR、FashionlQ、OVEN-QS、ReMuQ 等五個常用評測基準上取得了對比 CLIP baseline 的顯著優勢。

3.3BGE 社區生態

得益於 BGE 出色的效能與良好的通用性，行業內主流的向量數據庫紛紛跟進 BGE 的各個模型版本。此前備受歡迎的 BGE-M3 模型已被 Vespa、Milvus 等框架整合，為社區使用者快速搭建「三位一體的」（稠密檢索、稀疏檢索、重排序）檢索流水線帶來的極大便利。

1. Vespa 使用範例（詳見 [4]）

2. Milvus 使用範例（詳見 [5]）

參考資料：

[1] MTEB Leaderboard, https://huggingface.co/spaces/mteb/leaderboard

[2] SFR-Embedding-Mistral, https://blog.salesforceairesearch.com/sfr-embedded-mistral/

[3] Llama-Index Evaluation, https://docs.llamaindex.ai/en/latest/optimizing/evaluation/evaluation.html

[4] Vespa for BGE M3, https://github.com/vespa-engine/pyvespa/blob/master/docs/sphinx/source/examples/mother-of-all-embedding-models-cloud.ipynb

[5] Zilliz for BGE, https://github.com/FlagOpen/FlagEmbedding/tree/master/FlagEmbedding/BGE_M3

4.Jina Reranker

網址：https://jina.ai/reranker/

Jina Reranker 是由神經搜尋公司 Jina AI 開發。2022 年，Jina AI 完成 A 輪融資，融資總額已經超過 2 億人民幣。其開發的神經搜尋框架 Jina 多次登上 GitHub 全球 Trending 排行榜第一名。

Jina Reranker v2 在今年 6 月釋出，在速度、多語言支持和功能上都有顯著提升，尤其適用於檢索增強生成（RAG）場景。

4.1Jina Reranker v2 的主要優勢：

多語言支持：在 100 多種語言中提供更相關的搜尋結果，效能超過 bge-reranker-v2-m3；

代理能力：具備最先進的函數呼叫和文本到 SQL 轉換能力，適用於代理 RAG 場景。

程式碼檢索：在程式碼檢索任務上表現最佳；

極速：推理速度比上一代產品快 6 倍，比同類產品 bge-reranker-v2-m3 快 15 倍。

不同 Reranker 模型在 ToolBench 數據集上的 Recall@3 分數報告。如圖所示，Jina Reranker v2 基本達到了最先進的效能水平，並且模型體積減半，速度提升了近 15 倍。

4.2Jina Reranker v2 的特性：

創新需求：彌補嵌入模型在檢索精度上的不足。

多語言支持：在 MKQA、BEIR 和 AirBench 等基準測試中表現優異。

套用場景：在結構化數據查詢、函數呼叫和程式碼檢索方面的套用。

推理速度：模型尺寸更小、采用了 Flash Attention 2 技術。

訓練過程：分四個階段進行，包括使用英語數據預訓練、添加跨語言數據、微調等。

4.3Jina Reranker v2 的套用方式：

透過 Reranker API：使用 Jina Reranker v2 最快捷的方式是透過其 API，無需部署模型，就能輕松提升搜尋的相關性和 RAG 的準確性。

透過 RAG/LLM 框架整合：Jina Reranker 與現有的 LLM 和 RAG 編排框架整合，只需使用模型名稱即可快速整合。

Huggingface：Jina AI 開放了（在 CC-BY-NC-4.0 下）對 Hugging Face 上的 jina-reranker-v2-base-multilingual 模型的存取，以用於研究和評估目的。

私有雲部署：Jina Reranker v2 的預構建私有部署包即將在 AWS Marketplace 和 Azure Marketplace 上線，方便 AWS 和 Azure 使用者部署。

Jina Reranker 也是收費的，不過前 100 萬個 token 可以免費。10 億個 token 是 20 美元，110 億個 token 要 200 美元。

4.4 Jina Reranker 快速使用

a. 透過 Reranker API

使用 Jina Reranker v2 最快捷的方式是透過其 API，無需部署模型，就能輕松提升搜尋的相關性和 RAG 的準確性。

範例 1：對函數呼叫進行排名

要對最相關的外部函數或工具進行排序，按以下格式組織查詢和文件（函數架構）。

curl -X 'POST' \ 'https://api.jina.ai/v1/rerank' \ -H 'accept: application/json' \ -H 'Authorization: Bearer <YOUR JINA AI TOKEN HERE>' \ -H 'Content-Type: application/json' \ -d '{ "model": "jina-reranker-v2-base-multilingual", "query": "I am planning a road trip from Berlin to Munich in my Volkswagen VII. Can you calculate the carbon footprint of this trip?", "documents": [ "{'\''Name'\'': '\''getWeather'\'', '\''Specification'\'': '\''Provides current weather information for a specified city'\'', '\''spec'\'': '\''https://api.openweathermap.org/data/2.5/weather?q={city}&appid={API_KEY}'\'', '\''example'\'': '\''https://api.openweathermap.org/data/2.5/weather?q=Berlin&appid=YOUR_API_KEY'\''}", "{'\''Name'\'': '\''calculateDistance'\'', '\''Specification'\'': '\''Calculates the driving distance and time between multiple locations'\'', '\''spec'\'': '\''https://maps.googleapis.com/maps/api/distancematrix/json?origins={startCity}&destinations={endCity}&key={API_KEY}'\'', '\''example'\'': '\''https://maps.googleapis.com/maps/api/distancematrix/json?origins=Berlin&destinations=Munich&key=YOUR_API_KEY'\''}", "{'\''Name'\'': '\''calculateCarbonFootprint'\'', '\''Specification'\'': '\''Estimates the carbon footprint for various activities, including transportation'\'', '\''spec'\'': '\''https://www.carboninterface.com/api/v1/estimates'\'', '\''example'\'': '\''{type: vehicle, distance: distance, vehicle_model_id: car}'\''}" ]}'

預期結果如下：

{ "model": "jina-reranker-v2-base-multilingual", "usage": { "total_tokens": 383, "prompt_tokens": 383 }, "results": [ { "index": 2, "document": { "text": "{'Name': 'calculateCarbonFootprint', 'Specification': 'Estimates the carbon footprint for various activities, including transportation', 'spec': 'https://www.carboninterface.com/api/v1/estimates', 'example': '{type: vehicle, distance: distance, vehicle_model_id: car}'}" }, "relevance_score": 0.5422876477241516 }, { "index": 1, "document": { "text": "{'Name': 'calculateDistance', 'Specification': 'Calculates the driving distance and time between multiple locations', 'spec': 'https://maps.googleapis.com/maps/api/distancematrix/json?origins={startCity}&destinations={endCity}&key={API_KEY}', 'example': 'https://maps.googleapis.com/maps/api/distancematrix/json?origins=Berlin&destinations=Munich&key=YOUR_API_KEY'}" }, "relevance_score": 0.23283305764198303 }, { "index": 0, "document": { "text": "{'Name': 'getWeather', 'Specification': 'Provides current weather information for a specified city', 'spec': 'https://api.openweathermap.org/data/2.5/weather?q={city}&appid={API_KEY}', 'example': 'https://api.openweathermap.org/data/2.5/weather?q=Berlin&appid=YOUR_API_KEY'}" }, "relevance_score": 0.05033063143491745 } ]}

範例 2：對 SQL 查詢進行排名

要獲取使用者查詢與數據庫表結構的相關性得分，可以使用以下 API 呼叫範例。

curl -X 'POST' \ 'https://api.jina.ai/v1/rerank' \ -H 'accept: application/json' \ -H 'Authorization: Bearer <YOUR JINA AI TOKEN HERE>' \ -H 'Content-Type: application/json' \ -d '{ "model": "jina-reranker-v2-base-multilingual", "query": "which customers bought a summer outfit in the past 7 days?", "documents": [ "CREATE TABLE customer_personal_info (customer_id INT PRIMARY KEY, first_name VARCHAR(50), last_name VARCHAR(50));", "CREATE TABLE supplier_company_info (supplier_id INT PRIMARY KEY, company_name VARCHAR(100), contact_name VARCHAR(50));", "CREATE TABLE transactions (transaction_id INT PRIMARY KEY, customer_id INT, purchase_date DATE, FOREIGN KEY (customer_id) REFERENCES customer_personal_info(customer_id), product_id INT, FOREIGN KEY (product_id) REFERENCES products(product_id));", "CREATE TABLE products (product_id INT PRIMARY KEY, product_name VARCHAR(100), season VARCHAR(50), supplier_id INT, FOREIGN KEY (supplier_id) REFERENCES supplier_company_info(supplier_id));" ]}'

預期的響應是：

{ "model": "jina-reranker-v2-base-multilingual", "usage": { "total_tokens": 253, "prompt_tokens": 253 }, "results": [ { "index": 2, "document": { "text": "CREATE TABLE transactions (transaction_id INT PRIMARY KEY, customer_id INT, purchase_date DATE, FOREIGN KEY (customer_id) REFERENCES customer_personal_info(customer_id), product_id INT, FOREIGN KEY (product_id) REFERENCES products(product_id));" }, "relevance_score": 0.2789437472820282 }, { "index": 0, "document": { "text": "CREATE TABLE customer_personal_info (customer_id INT PRIMARY KEY, first_name VARCHAR(50), last_name VARCHAR(50));" }, "relevance_score": 0.06477169692516327 }, { "index": 3, "document": { "text": "CREATE TABLE products (product_id INT PRIMARY KEY, product_name VARCHAR(100), season VARCHAR(50), supplier_id INT, FOREIGN KEY (supplier_id) REFERENCES supplier_company_info(supplier_id));" }, "relevance_score": 0.027742892503738403 }, { "index": 1, "document": { "text": "CREATE TABLE supplier_company_info (supplier_id INT PRIMARY KEY, company_name VARCHAR(100), contact_name VARCHAR(50));" }, "relevance_score": 0.025516605004668236 } ]}

b. 透過 RAG/LLM 框架整合

Jina Reranker 與現有的 LLM 和 RAG 編排框架整合，只需使用模型名稱即可快速整合。詳情請存取各自的文件頁面了解如何整合 Jina Reranker v2：jina-reranker-v2-base-multilingual。

Haystack by deepset ：在 Haystack 中，可以使用 JinaRanker 類整合 Jina Reranker v2: https://docs.haystack.deepset.ai/docs/jinaranker

from haystack import Documentfrom haystack_integrations.components.rankers.jina import JinaRankerdocs = [Document(content="Paris"), Document(content="Berlin")]ranker = JinaRanker(model="jina-reranker-v2-base-multilingual", api_key="<YOUR JINA AI API KEY HERE>")ranker.run(query="City in France", documents=docs, top_k=1)

LlamaIndex ：Jina Reranker v2 可作為 JinaRerank 節點後處理器模組使用。https://docs.llamaindex.ai/en/stable/examples/node_postprocessor/JinaRerank/

import osfrom llama_index.postprocessor.jinaai_rerank import JinaRerankjina_rerank = JinaRerank(model="jina-reranker-v2-base-multilingual", api_key="<YOUR JINA AI API KEY HERE>", top_n=1)

Langchain ：利用 JinaRerank 模組，在現有應用程式中整合 Jina Reranker 2，需要使用正確的模型名稱來初始化 JinaRerank 模組。具體參考：https://python.langchain.com/v0.2/docs/integrations/document transformers/jina rerank/

from langchain_community.document_compressors import JinaRerankreranker = JinaRerank(model="jina-reranker-v2-base-multilingual", jina_api_key="<YOUR JINA AI API KEY HERE>")

Huggingface

我們還開放了（在 CC-BY-NC-4.0 下）對 Hugging Face 上的 jina-reranker-v2-base-multilingual 模型的存取，以用於研究和評估目的。

要從 Hugging Face 下載並執行模型，請安裝 transformers 和 einops：

pip install transformers einopspip install ninjapip install flash-attn --no-build-isolation

使用 Hugging Face token 登入到您的 Hugging Face 帳戶：

huggingface-cli login --token <"HF-Access-Token">

下載預訓練模型：

from transformers import AutoModelForSequence classificationmodel = AutoModelForSequence classification.from_pretrained( 'jinaai/jina-reranker-v2-base-multilingual', torch_dtype="auto", trust_remote_code=True,)model.to('cuda') # or 'cpu' if no GPU is availablemodel.eval()

定義查詢和要重新排序的文件：

query = "Organic skincare products for sensitive skin"documents = [ "Organic skincare for sensitive skin with aloe vera and chamomile.", "New makeup trends focus on bold colors and innovative techniques", "Bio-Hautpflege für empfindliche Haut mit Aloe Vera und Kamille", "Neue Make-up-Trends setzen auf kräftige Farben und innovative Techniken", "Cuidado de la piel orgánico para piel sensible con aloe vera y manzanilla", "Las nuevas tendencias de maquillaje se centran en colores vivos y técnicas innovadoras", "針對敏感肌專門設計的天然有機護膚產品", "新的化妝趨勢註重鮮艷的顏色和創新的技巧", "敏感肌のために特別に設計された天然有機スキンケア製品", "新しいメイクのトレンドは鮮やかな色と革新的な技術に焦點を當てています",]

構建句子對並計算相關性分數：

sentence_pairs = [[query, doc] for doc in documents]scores = model.compute_score(sentence_pairs, max_length=1024)

所得的得分將以浮點數列表形式呈現，每個數值對應著一個文件與查詢間的相關性程度，數值越大，表明相關性越強。

rerank 能夠將長文本分解為若幹小部份，對每個部份與查詢的匹配度進行單獨評分，最後，將各部份的得分綜合起來，形成完整的重排序輸出。在這個過程中，max query length 和 max_length 參數用於控制文本分割的長度和細度。

results = model.rerank( query, documents, max_query_length=512, max_length=1024, top_n=3)

該函數不僅返回每個文件的相關性分數，還返回它們的內容和在原始文件列表中的位置。