如何仅使用 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

要运行这个演示，你需要一个具有足够 token 额度的 API 密钥。如果你的配额用完无法运行演示，可以在 https://jina.ai/reranker 生成新的密钥。每个新密钥都有 100 万个免费 token。

tag实现

实现非常简单：为了找到 jina.ai/news/ 上给定文章的最相关文章，我们使用当前正在阅读的文章作为查询，并将我们新闻网站上的其他 230+ 篇文章（使用它们的全文！）作为文档，当然要排除当前这篇。然后我们将这个 $(q, d_1, d_2, \cdots, d_{230})$ 作为负载发送给 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 管道中最繁琐和启发式的部分，在这里却不是问题。然而，更长的上下文确实会消耗更多的 token，这是我们 API 的付费用户可能需要考虑的。在这个例子中，因为我们使用了所有 233 篇文章的全文，一次重排序查询消耗超过 30 万个 token。
原始数据与清洗后数据对质量的影响。添加数据清洗确实可能带来改进。例如，我们观察到仅仅移除 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+ 篇文章的庞大目录中找出最相关的文章——这个挑战的灵感来自于 LLMs 中的"大海捞针"。下面，我们用绿色突出显示了这些"针"以便清晰展示。

Screenshot of a table ranking articles on search technology relevance, featuring titles, excerpts, and 'More Like' or 'Not Li — 我们研究的完整结果详见这份电子表格。

tag总结

基于测试结果，我们得出了一些观察和总结：

结合标题和摘要可以获得最佳的重排序结果，其中摘要在提升重排序质量方面发挥了重要作用。
加入"提示"式指令并没有带来任何改进。
重排序模型目前无法有效处理正面或负面限定词。诸如"更多类似"、"更少类似"或"不要类似"这样的术语，重排序器无法理解。

第 2 点和第 3 点的见解为重排序器的未来改进提供了有趣的方向。我们认为，通过启用即时提示来改变排序逻辑，可以显著扩展重排序器的功能，从而开启个性化内容策划/推荐等新的潜在应用。