如何僅使用 Jina Reranker API 建立文章推薦系統

我們在兩週前推出了 Reranker API，將其確立為市場上領先的重排序解決方案。Jina Reranker 在各種基準測試中優於其他主流基準，相較於 BM25 的結果，命中率提高了高達 +33%。雖然性能令人印象深刻，但真正令我興奮的是 Reranker API 的潛力。它的簡單介面允許輸入查詢文檔列表，並直接輸出重新排序後的 top-k 結果。這意味著，理論上可以僅使用 Reranker 構建搜索或推薦系統—無需 BM25、embeddings、向量資料庫或任何管道，從而實現端到端的功能。

這個概念讓我非常感興趣，以至於我覺得必須要進行實驗。所以現在，當你瀏覽到我們網站的任何新聞頁面（比如你現在正在閱讀的這一頁），按下 @ 鍵並點擊"get top 5 related articles"按鈕，你將在大約 5 秒內收到與當前文章最相關的五篇文章，這是使用 jina-reranker-v1 模型的結果（使用 jina-colbert-v1 模型則需要稍長時間）。所有計算都是在線完成，並完全由 Reranker API 管理。以下是展示其運作方式的影片：

0:00

/0:33

要運行這個演示，你需要一個還有足夠 tokens 的 API 金鑰。如果你用完了配額無法運行演示，你可以在 https://jina.ai/reranker 生成一個新的金鑰。每個新金鑰都附帶 100 萬個免費 tokens。

tag實作方法

實作非常簡單：為了找到 jina.ai/news/ 上特定文章最相關的文章，我們使用當前正在閱讀的文章作為查詢，並將我們新聞網站上的所有其他 230+ 篇文章（使用它們的全文！）作為文檔，當然要排除當前這篇。然後我們將這個 $(q, d_1, d_2, \cdots, d_{230})$ 作為 payload 發送給 Reranker API。一旦收到回應，我們使用排序後的文檔索引來顯示結果。因此，底層程式碼如下：

const getRecommendedArticles = async () => {
  
  const query = `${currentNews.title} ${currentNews.excerpt}`;
  const docs = newsStore.allBlogs.filter((item) => item.slug !== currentNews.slug);
  
  const data = {
    model: modelName,
    query: query,
    documents: docs,
    top_n: 5,
  }

  const rerankUrl = 'https://api.jina.ai/v1/rerank';
  const headers = {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${apiKey}`,
  };
  const modelName = 'jina-reranker-v1-base-en';
  
  const res = await fetch(rerankUrl, {
    method: 'POST',
    headers: headers,
    body: JSON.stringify(data),
  });

  const resp = await res.json();

  const topKList = resp.results.map((item) => {
    return docs[item.index];
  });

  console.log(topKList);
}

要獲取 API 金鑰，只需訪問我們的 Reranker API 頁面並導航到 API 部分。如果你已經擁有我們 Embedding API 的 API 金鑰，你可以在此重複使用它。

就這樣，你會看到結果，這對於第一次迭代來說相當有前途，特別是考慮到實作過程只花了大約 10 分鐘。

雖然讀者可能會對這個實作有一些疑慮，但有些批評可能過於擔心，而其他則可能是有效的：

對於過長全文和分塊需求的擔憂可能是過慮了：jina-reranker-v1 模型可以處理長度達 512 的查詢和任意長度的文檔，而 jina-colbert-v1 模型可以處理查詢和文檔最多 8192 的長度。因此，向 Reranker API 輸入全文可能是不必要的。兩個模型都能有效管理長上下文，所以不用擔心。分塊，雖然可能是 embedding-vector-search-rerank 管道中最麻煩和啟發式的部分，在這裡並不是一個大問題。然而，更長的上下文確實會消耗更多 tokens，這是我們 API 的付費用戶可能需要考慮的。在這個例子中，因為我們使用了所有 233 篇文章的全文，一次重排序查詢需要消耗 300K+ tokens。
原始資料與清理後資料對品質的影響。添加資料清理確實可能帶來改進。例如，我們觀察到，僅僅移除 HTML 標籤（即 docs.map(item => item.html.replace(/<[^>]*>?/gm, '')）就能顯著提高 jina-reranker-v1 模型的推薦品質，但對 jina-colbert-v1 模型的影響較小。這表明我們的 ColBERT 模型在訓練時已經被設計成比 jina-reranker-v1 模型更能容忍雜訊文本。
不同查詢構造對品質的影響。在上述實作中，我們直接使用當前文章的標題和摘要作為查詢。這是構造查詢的最佳方法嗎？添加前綴如 "What is the most related article to..." 或"如果你推薦最好的文章，我會給你 20 美元小費，"類似於用於大語言模型的提示，會有幫助嗎？這引發了一個有趣的問題，可能與模型的訓練數據分佈有關，我們計劃進一步探討。
延續前面關於查詢構建的觀點，深入研究查詢的組合能力將會很有趣，例如使用用戶最近的瀏覽歷史來提供個性化推薦。特別值得思考的是，系統是否不僅能理解查詢中的正面例子，還能理解負面例子，例如 NOT_LIKE 運算符、"不要給我推薦這樣的文章"或"我想看到更少這樣的"。我們將在下一節深入探討這一點。

tag查詢編寫的實證研究

在我們使用 Jina Reranker API 探索不同查詢編寫方式時，我們專注於前 10 個結果，通過人工標註（即由我們自己評估）進行了定性評估，這很合理，因為我們完全了解我們網站上發布的所有內容。我們研究的查詢編寫策略包括：

使用文章的標題、摘要，以及標題 + 摘要的組合。
採用類似"提示"的指令，如"更多類似這樣的"、"不要類似這樣的"和"最相關的文章是什麼？"

為了測試重排序器的效果，我們選擇了兩篇非平凡的文章作為查詢主題，目標是在我們超過 200+ 篇文章的龐大目錄中找出最相關的文章——這一挑戰靈感來自大語言模型中的"大海撈針"。下面，我們用綠色突出顯示了這些"針"。

Screenshot of a table ranking articles on search technology relevance, featuring titles, excerpts, and 'More Like' or 'Not Li — 我們研究的詳細結果在這個電子表格中。

tag總結

基於測試結果，我們做出了一些觀察和總結：

將標題和摘要結合使用能獲得最佳的重排序結果，其中摘要在提升重排序質量方面發揮了重要作用。
加入類似"提示"的指令並沒有帶來任何改進。
重排序模型目前無法有效處理正面或負面的限定詞。諸如"更多類似"、"更少類似"或"不要類似"等術語對重排序器來說是不可理解的。

第 2 點和第 3 點的見解為重排序器的未來改進提供了有趣的方向。我們相信，通過啟用即時提示來改變排序邏輯，可以顯著擴展重排序器的功能，從而釋放個性化內容策劃/推薦等新的潛在應用。