Comment créer des recommandations d'articles avec l'API Jina Reranker uniquement

Nous avons lancé l'API Reranker il y a deux semaines, la positionnant comme une solution de reranking leader sur le marché. Jina Reranker surpasse les références populaires dans divers benchmarks, démontrant une augmentation significative jusqu'à +33% du taux de succès par rapport aux résultats BM25. Bien que les performances soient impressionnantes, ce qui m'enthousiasme vraiment, c'est le potentiel de l'API Reranker. Son interface simple permet d'entrer une liste de requêtes-documents et renvoie directement les k meilleurs résultats reclassés. Cela signifie qu'en théorie, on pourrait construire un système de recherche ou de recommandation en utilisant uniquement le Reranker—éliminant ainsi le besoin de BM25, d'embeddings, de bases de données vectorielles ou de pipelines, obtenant ainsi une fonctionnalité de bout en bout.

Ce concept m'a tellement intrigué que j'ai ressenti le besoin de l'expérimenter. Donc voilà : maintenant en naviguant sur n'importe quelle page d'actualités de notre site web, comme celle que vous lisez actuellement, appuyez sur la touche @ et cliquez sur le bouton "get top 5 related articles", vous recevrez les cinq articles les plus pertinents par rapport à l'article actuel en environ 5 secondes, en utilisant le modèle jina-reranker-v1 (un peu plus long pour le modèle jina-colbert-v1). Tous les calculs sont effectués en ligne et entièrement gérés par l'API Reranker. Voici une vidéo démontrant son fonctionnement :

tagImplémentation

L'implémentation est très simple : pour trouver les articles les plus liés à un article donné sur jina.ai/news/, nous utilisons l'article actuellement lu comme requête et tous les autres 230+ articles (en utilisant leur texte intégral !) sur notre site d'actualités comme documents, excluant bien sûr l'article actuel. Ensuite, nous envoyons ce $(q, d_1, d_2, \cdots, d_{230})$ comme payload à l'API Reranker. Une fois la réponse reçue, nous utilisons l'index de document trié pour afficher les résultats. Ainsi, le code sous-jacent est le suivant :

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);
}
Copier

Reranker API

Maximize the search relevancy and RAG accuracy at ease

Et voilà, vous verrez les résultats, qui sont assez prometteurs pour une première itération, particulièrement compte tenu du fait que le processus d'implémentation prend environ 10 minutes.

Bien que les lecteurs puissent avoir des préoccupations concernant cette implémentation, certaines critiques peuvent être surestimées, tandis que d'autres peuvent être valides :

• Les inquiétudes concernant les textes trop longs et la nécessité du découpage peuvent être surestimées : le modèle jina-reranker-v1 peut traiter des requêtes jusqu'à 512 en longueur et des documents de longueur arbitraire, tandis que le modèle jina-colbert-v1 peut gérer jusqu'à 8192 pour les requêtes et les documents. Par conséquent, l'entrée du texte intégral dans l'API Reranker est probablement inutile. Les deux modèles gèrent efficacement les longs contextes, il n'y a donc pas lieu de s'inquiéter. Le découpage, bien qu'il soit peut-être l'aspect le plus fastidieux et heuristique du pipeline embedding-vector-search-rerank, est moins problématique ici. Cependant, des contextes plus longs supposent plus de tokens, ce que nos utilisateurs payants de l'API devront peut-être prendre en compte. Dans cet exemple, parce que nous utilisons le texte intégral de tous les 233 articles, une requête de reranking coûte plus de 300K tokens.
• L'impact des données brutes versus nettoyées sur la qualité. L'ajout du nettoyage des données pourrait effectivement conduire à des améliorations. Par exemple, nous avons observé que la simple suppression des balises HTML (c'est-à-dire docs.map(item => item.html.replace(/<[^>]*>?/gm, '')) améliore significativement la qualité des recommandations pour le modèle jina-reranker-v1, bien que l'effet soit moins prononcé pour le modèle jina-colbert-v1. Cela suggère que notre modèle ColBERT a été entraîné pour être plus tolérant aux textes bruités que le modèle jina-reranker-v1.
• L'influence de différentes constructions de requêtes sur la qualité. Dans l'implémentation ci-dessus, nous avons directement utilisé le titre et l'extrait de l'article actuel comme requête. Est-ce l'approche optimale pour construire la requête ? L'ajout d'un préfixe tel que "What is the most related article to..." ou"Je vous donnerai 20 $ de pourboire si vous recommandez le meilleur article," similaire aux prompts utilisés avec les grands modèles de langage, serait-il bénéfique ? Cela soulève une question intéressante, probablement liée à la distribution des données d'entraînement du modèle, que nous prévoyons d'explorer davantage.
• En nous appuyant sur le point précédent concernant la construction des requêtes, il serait intéressant d'étudier plus en profondeur les capacités compositionnelles de la requête, comme l'utilisation de l'historique de navigation récent d'un utilisateur pour des recommandations personnalisées. Il est particulièrement intéressant de considérer si le système pourrait comprendre non seulement les exemples positifs dans la requête mais aussi les négatifs, par exemple les opérateurs NOT_LIKE, "Ne me recommandez pas d'article comme celui-ci" ou "Je veux en voir moins comme celui-ci". Nous approfondirons ce sujet dans la section suivante.

tagÉtude empirique sur la rédaction des requêtes

Dans notre exploration des différentes méthodes de rédaction de requêtes avec la Jina Reranker API, en nous concentrant sur les 10 premiers résultats, nous avons mené une évaluation qualitative par étiquetage humain (c'est-à-dire évaluée par nous-mêmes), ce qui est logique puisque nous avons une connaissance complète de tout le contenu publié sur notre site web. Les stratégies de rédaction de requêtes que nous avons examinées comprenaient :

• L'utilisation du Titre, de l'Extrait, et d'une combinaison Titre + Extrait de l'article.
• L'adoption d'instructions de type "Prompt" comme "plus comme ceci," "pas comme ceci," et "quel est l'article le plus étroitement lié ?"

Pour tester l'efficacité du reranker, nous avons sélectionné deux articles non triviaux comme sujets de requête, visant à identifier les articles les plus pertinents parmi notre vaste catalogue de plus de 200 articles—un défi inspiré de "l'aiguille dans une botte de foin" dans les LLM. Ci-dessous, nous avons mis en évidence ces "aiguilles" en vert pour plus de clarté.

tagRésumé

Sur la base des résultats des tests, nous avons fait quelques observations et résumés :

1. La combinaison du Titre et de l'Extrait donne les meilleurs résultats de reclassement, l'Extrait jouant un rôle significatif dans l'amélioration de la qualité du reclassement.
2. L'incorporation d'instructions de type "prompt" n'entraîne aucune amélioration.
3. Le modèle de reranker ne traite pas efficacement les qualificatifs positifs ou négatifs actuellement. Les termes tels que "plus comme", "moins comme", ou "pas comme" ne sont pas compréhensibles par le reranker.

Les observations des points 2 et 3 offrent des directions intéressantes pour les améliorations futures du reranker. Nous pensons que permettre le prompting à la volée pour modifier la logique de tri pourrait considérablement étendre les capacités du reranker, débloquant de nouvelles applications potentielles comme la curation/recommandation de contenu personnalisée.