Analyse comparative des modèles de reclassement : Comparaison des 8 meilleurs modèles

Nous avons évalué huit modèles de reclassement sur environ 145 000 avis Amazon en anglais afin de mesurer l'amélioration apportée par une étape de reclassement à la recherche dense. Nous avons extrait les 100 meilleurs résultats à l'aide de la base de données multilingue e5, les avons reclassés avec chaque modèle, puis avons évalué les 10 meilleurs résultats sur 300 requêtes, chacune faisant référence à des détails précis de l'avis source. Le meilleur modèle de reclassement a permis d'augmenter le taux de réussite en première position (Hit@1) de 62,67 % à 83,00 % (+20,33 points de pourcentage).

Résultats de référence du Reranker

Explication des indicateurs :

Le rapport ΔHit@1 / ΔHit@10 indique l'amélioration par rapport à la situation de référence (sans réévaluation) en points de pourcentage (pp). Par exemple, +20,33pp signifie que le réévaluation a amélioré le taux de réussite à 1 (Hit@1) de 20,33 points de pourcentage par rapport à la situation de référence (62,67 %).

Hit@K vérifie si au moins un avis contenant le bon product_id figure parmi les K premiers résultats. La référence est le product_id de l'avis ayant généré la requête. Si un autre avis concernant le même produit apparaît parmi les K premiers résultats, cela compte comme une occurrence. Hit@1 est le test le plus strict : le premier résultat correspond-il au bon produit ? Hit@10 est plus permissif : le bon produit figure-t-il parmi les 10 premiers résultats ?

Le MRR@10 (Mean Reciprocal Rank) calcule la moyenne de 1/rang du premier résultat correct pour l'ensemble des requêtes. Si le premier product_id correspondant est au rang 1, le score est de 1,0. Au rang 2, il est de 0,5. Au rang 10, il est de 0,1. Ce système favorise les modèles qui placent le produit correct le plus haut possible dans les résultats.

Le nDCG@10 (Gain Cumulatif Actuel Normalisé) évalue le classement de tous les avis correspondants parmi les 10 premiers, et non seulement du premier. Si un même produit compte plusieurs avis dans l'ensemble des candidats et que plusieurs d'entre eux figurent parmi les 10 premiers, le nDCG attribue un crédit à chacun en fonction de son classement. En pratique, la plupart des produits ne comptent qu'un ou deux avis parmi les 100 premiers candidats ; par conséquent, le nDCG et le MRR sont étroitement corrélés.

Le rappel à 10 % (Recall@10) mesure la proportion d'avis correspondants (même identifiant de produit) figurant parmi les 10 premiers résultats, sur l'ensemble des avis correspondants dans l'ensemble des résultats candidats (100 premiers). Si un produit compte 3 avis parmi les 100 premiers et que le système de reclassement en place 2 parmi les 10 premiers, le rappel à 10 % (Recall@10) est de 2/3 pour cette requête. Étant donné que la plupart des produits ont peu d'avis en double dans l'ensemble des résultats candidats, le rappel à 10 % (Recall@10) et le taux de réussite à 10 % (Hit@10) sont quasiment identiques dans ce test de performance.

Analyse de la latence

La latence de réordonnancement mesure le temps nécessaire à chaque encodeur croisé pour évaluer 100 documents candidats par rapport à la requête. Le temps de recherche vectorielle (~20 ms) est exclu car il reste constant d'une exécution à l'autre et est indépendant de l'encodeur de réordonnancement.

Explication des mesures de latence :

Le réordonnancement correspond au temps nécessaire à l'encodeur croisé pour évaluer les 100 documents candidats par rapport à la requête. C'est là que les modèles diffèrent : un passage unique avant est rapide, tandis que le décodage autorégressif est lent.

P95 correspond au 95e centile de la latence totale. Certaines requêtes comportent des textes de description plus longs, ce qui augmente le temps de tokenisation et de scoring. P95 représente le scénario le plus défavorable auquel vous pouvez vous attendre pour 95 % des requêtes.

Principales conclusions

Un modèle 149M correspond à un modèle 1.2B

gte-reranker-modernbert-base possède 149 millions de paramètres, tandis que nemotron-rerank-1b en compte 1,2 milliard. Les deux atteignent un taux de réussite de 83 % (Hit@1) en anglais. L'architecture ModernBERT est huit fois plus compacte et offre une précision globale identique.

Cela ne signifie pas que la taille du modèle soit sans importance. Nemotron surpasse légèrement MRR@10 (0,8514 contre 0,8483) et Hit@10 (88,33 % contre 88,00 %), ce qui signifie qu'il classe les documents pertinents un peu mieux dans le top 10. Mais pour la plupart des applications où l'obtention du premier résultat correct est primordiale, le modèle de 149 millions d'éléments est suffisant.

Le plus grand modèle n'est pas forcément le meilleur.

qwen3_reranker_4b possède 4 milliards de paramètres et prend plus d'une seconde par requête. Son taux de réussite à la première requête (Hit@1) atteint 77,67 %, le plaçant en quatrième position derrière nemotron (1,2 milliard), gte_modernbert (149 millions) et jina (560 millions). Sa latence est 4,5 fois supérieure à celle de nemotron, pour une précision inférieure de 5,3 points de pourcentage.

L'architecture de qwen3 utilise la modélisation causale du langage avec une approche logit binaire (« oui/non »). Le modèle lit la paire requête-document et calcule la probabilité que « oui, ceci est pertinent ». Conceptuellement simple, cette approche est cependant coûteuse en raison du surcoût lié au décodage autorégressif. Les modèles SequenceClassification (gte_modernbert, bge) et l'approche par modèle d'invite de nemotron traitent la paire en une seule passe, ce qui est fondamentalement plus rapide.

Jina offre le meilleur compromis vitesse-précision

Jina_reranker_v3 atteint 81,33 % de réussite (Hit@1) à 188 ms. Nemotron atteint 83,00 % à 243 ms. Si vous avez besoin d'une latence totale inférieure à 200 ms par requête, Jina est le seul modèle haut de gamme à répondre à cette exigence. L'écart de 1,67 point de pourcentage ne justifie peut-être pas les 55 ms supplémentaires dans un système de production traitant des milliers de requêtes par seconde.

Un seul outil de reclassement aggrave les résultats.

Le modèle mxbai_rerank_xsmall (70 millions de paramètres) atteint un taux de réussite de 64,67 % (Hit@1). Le modèle de référence, sans reclassement, obtient un score de 62,67 %. L'amélioration n'est que de 2 points de pourcentage, ce qui est négligeable pour 300 requêtes. Avec 70 millions de paramètres, le modèle ne permet pas d'évaluer de manière fiable la pertinence entre les requêtes et les documents sur des textes plus longs ou plus nuancés.

Un outil de reclassement n'est pas forcément bénéfique. Testez-le sur vos données réelles avant de le déployer.

Le retriever fixe le plafond

Tous les meilleurs algorithmes de reclassement convergent vers un taux de réussite de 87 à 88 % (Hit@10). Ce plafond est déterminé par le moteur de recherche. Si multilingual-e5-base ne place pas le document pertinent parmi les 100 premiers résultats, aucun algorithme de reclassement ne peut le retrouver. Les 12 % de requêtes restantes, pour lesquelles aucun algorithme de reclassement n'a d'échec, correspondent à des cas où le moteur de recherche dense a tout simplement manqué le document pertinent.

Pour dépasser ce plafond, il faudrait un meilleur outil de recherche, un plus grand nombre de candidats, ou les deux. Nous avons testé les 250 meilleurs candidats et n'avons constaté quasiment aucune amélioration par rapport aux 100 meilleurs, ce qui signifie que e5_base épuise ses candidats utiles bien avant le 250e rang.

Comment fonctionnent les systèmes de reclassement ?

Un modèle de recherche dense (bi-encodeur) encode les requêtes et les documents indépendamment dans des vecteurs. La recherche s'effectue par la méthode du plus proche voisin sur ces vecteurs. Ce processus est rapide car seule la requête est encodée au moment de la recherche, mais le modèle ne voit jamais la requête et le document ensemble, ce qui peut l'amener à manquer des signaux de pertinence subtils.

Un réordonnanceur (encodeur croisé) prend une paire requête-document comme entrée unique. Le modèle traite les deux textes conjointement, identifiant des relations que l'encodage indépendant ne permet pas de déceler. En contrepartie, il doit être exécuté une fois par candidat, ce qui limite le nombre de candidats pouvant être évalués.

Architectures dans ce référentiel

Nous avons testé quatre architectures d'encodeurs croisés différentes :

Les modèles de classification de séquences (bge_base, bge_v2_m3, mxbai_xsmall, gte_modernbert) prennent en entrée une paire [requête, document] et produisent en sortie un score logit unique. Il s'agit de l'approche la plus simple et la plus courante.

Nemotron utilise un format de modèle d'invite : « question :{q} passage :{p} ». L'entrée se présente sous forme de texte brut plutôt que de paires structurées, mais le modèle produit tout de même un score de pertinence unique grâce à la classification de séquences. Le pré-entraînement LLM (basé sur Llama) lui confère une solide compréhension du langage.

Les réorganisateurs Qwen3 utilisent la modélisation causale du langage. Le modèle analyse la paire et génère un jugement par oui ou par non. Le score est log P(oui) / (P(oui) + P(non)). Ceci requiert l'ensemble du mécanisme autorégressif, ce qui explique la latence plus élevée.

Jina v3 utilise une API personnalisée (model.rerank()) qui gère la tokenisation et le scoring en interne. L'architecture sous-jacente repose sur l'attention croisée, mais l'interface masque les détails techniques.

méthodologie de référence du reranker

• GPU : NVIDIA H100 PCIe 80 Go via Runpod
• Base de données vectorielles : Qdrant 1.12.0 (binaire local), distance cosinus
• Récupérateur : multilingue-e5-base (768-dim). Préfixe de requête : "query: ", préfixe de document : "passage: "
• Logiciels : Transformers 5.2.0, PyTorch 2.8.0, CUDA 12.8.1
• Ensemble de données : sous-ensemble anglais d'Amazon Reviews Multi (Kaggle). ¹ 145 000 avis après filtrage par longueur minimale de 100 caractères. Chaque avis comprend un identifiant de produit, un texte et une note (nombre d'étoiles).
• Génération des requêtes : Claude Sonnet 4.6 via OpenRouter. 300 requêtes en anglais (5 types : factuelles, d’opinion, d’usage, de résolution de problèmes, de comparaison de fonctionnalités). Chaque requête doit faire référence à des détails précis tirés de son analyse de la source ; les questions génériques (score de spécificité < 4/5) sont éliminées.
• Format du document : "Review Title: {title}\nReview: {body}"
• Pipeline : Récupérer les 100 meilleurs candidats avec multilingual-e5-base, les réordonner avec cross-encoder, puis renvoyer les 10 meilleurs. La méthode de base ignore le réordonnancement et renvoie directement les 10 meilleurs candidats obtenus par le récupérateur.
• Vérification de référence : correspondance exacte uniquement avec l’identifiant du produit. Pas de solution de repli basée sur la similarité cosinus. Aucun crédit partiel pour les produits sémantiquement similaires.
• Variable contrôlée : seul le modèle de reclassement change d’une expérience à l’autre. Le système de recherche, le nombre de candidats, l’ensemble de requêtes et les critères d’évaluation sont identiques pour toutes les exécutions.
• Aucun réglage fin : tous les modèles ont été évalués sans aucun exemple avec les pondérations par défaut de HuggingFace.
• Latence : Réordonnancement (score inter-encodeurs de 100 candidats). Mesurée par requête sur GPU.

Modèles testés

Limites

Ce test de performance utilise un seul outil de récupération (multilingual-e5-base). Un autre outil générerait des ensembles de candidats différents et pourrait modifier le classement des outils de reclassement. Les résultats reflètent la performance de chaque outil de reclassement avec cet outil spécifique, et non la qualité intrinsèque de chaque outil.

Nos tests ont été effectués sur des avis clients en anglais provenant d'Amazon. Les performances sur d'autres domaines (articles scientifiques, documents juridiques, code) ou dans d'autres langues peuvent varier.

Le nombre de candidats est fixé à 100. Certains outils de réordonnancement peuvent donner des résultats différents avec 20 ou 200 candidats. Nous avons testé avec 250 candidats et constaté une amélioration négligeable, ce qui suggère que 100 candidats suffisent pour e5_base. Cependant, d'autres outils d'extraction peuvent se comporter différemment.

Un échantillon de 300 requêtes représente une taille modérée. Les trois meilleurs modèles (nemotron, gte_modernbert et jina) sont séparés par moins de 2 points de pourcentage. Avec un ensemble de requêtes plus important, ce classement pourrait évoluer. L'écart entre le haut et le bas du classement (plus de 20 points de pourcentage) est significatif.

Pour en savoir plus

Explorez d'autres indicateurs RAG, tels que :

• Modèles d'intégration : OpenAI vs Gemini vs Cohere
• Les 16 meilleurs modèles d'embeddings open source pour RAG
• Meilleure base de données vectorielles pour RAG : Qdrant vs Weaviate vs Pinecone
• Analyse comparative d'Agentic RAG : routage multi-bases de données et génération de requêtes
• Modèles d'intégration multimodaux : Apple vs Meta vs OpenAI
• Hybrid RAG : Amélioration de la précision RAG
• Les 10 meilleurs modèles d'intégration multilingues pour RAG

Liens de référence

1.

&#x270F;&#xFE0F; Amazon Reviews Multi | Kaggle

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA chez AIMultiple, spécialisé dans l'automatisation intelligente, les GPU, les agents IA et les frameworks RAG.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire