Benchmark des rerankers: Comparaison des 8 meilleurs modèles
Nous avons évalué 8 modèles de reranking sur environ 145k avis Amazon en anglais pour mesurer l'amélioration apportée par une étape de reranking à la recherche dense. Nous avons récupéré les 100 premiers candidats avec multilingual-e5-base, les avons rerankés avec chaque modèle, et avons évalué les 10 premiers résultats par rapport à 300 requêtes, chacune faisant référence à des détails concrets de son avis source. Le meilleur reranker a fait passer le Hit@1 de 62,67 % à 83,00 % (+20,33pp).
Résultats du benchmark des rerankers
Métriques expliquées :
ΔHit@1 / ΔHit@10 montre l'amélioration par rapport à la référence (sans reranker) en points de pourcentage (pp). Par exemple, +20,33pp signifie que le reranker a amélioré le Hit@1 de 20,33 points de pourcentage par rapport aux 62,67 % de la référence.
Hit@K mesure si un avis avec le bon product_id apparaît dans les K premiers résultats. La vérité terrain est le product_id de l'avis qui a généré la requête. Si un autre avis du même produit se retrouve dans le top-K, cela compte comme un hit. Le Hit@1 est le test le plus strict : le premier résultat provient-il du bon produit ? Le Hit@10 est plus indulgent : le bon produit se trouve-t-il quelque part dans les 10 premiers résultats ?
MRR@10 (Mean Reciprocal Rank) fait la moyenne de 1/rang du premier résultat correct sur toutes les 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. Cela récompense les modèles qui placent le produit correct aussi haut que possible.
nDCG@10 (Normalized Discounted Cumulative Gain) évalue les positions de tous les avis correspondants dans le top-10, pas seulement le premier. Si le même produit a plusieurs avis dans l'ensemble de candidats et que plusieurs se retrouvent dans le top-10, le nDCG crédite chacun selon sa position. En pratique, la plupart des produits n'ont que 1 à 2 avis dans les 100 premiers candidats, donc le nDCG et le MRR évoluent de façon similaire.
Recall@10 mesure la fraction d'avis correspondants (même product_id) dans le top-10 par rapport à tous les avis correspondants dans l'ensemble complet de candidats (top-100). Si un produit a 3 avis dans le top-100 et que le reranker en place 2 dans le top-10, le Recall@10 est de 2/3 pour cette requête. Comme la plupart des produits ont peu d'avis en double dans l'ensemble de candidats, le Recall@10 et le Hit@10 sont quasiment identiques dans ce benchmark.
Détail de la latence
La latence de reranking mesure le temps nécessaire à chaque cross-encoder pour scorer 100 documents candidats par rapport à la requête. Le temps de recherche vectorielle (~20ms) est exclu car il reste constant pour toutes les exécutions et est indépendant du reranker.
Métriques de latence expliquées :
Rerank est le temps nécessaire au cross-encoder pour scorer les 100 documents candidats par rapport à la requête. C'est là que les modèles diffèrent : une seule passe avant est rapide, tandis que le décodage autorégressif est lent.
P95 est le 95e centile de la latence totale. Certaines requêtes ont des textes d'avis plus longs, ce qui augmente le temps de tokenisation et de scoring. Le P95 montre le pire cas auquel vous devez vous attendre pour 95 % des requêtes.
Principales conclusions
Un modèle de 149M égale un modèle de 1,2B
gte-reranker-modernbert-base a 149M paramètres, nemotron-rerank-1b en a 1,2B. Les deux atteignent 83,00 % de Hit@1 en anglais. L'architecture ModernBERT est 8x plus petite et offre une précision de premier rang identique.
Cela ne signifie pas que la taille du modèle est sans importance. nemotron prend l'avantage sur le MRR@10 (0,8514 vs 0,8483) et le Hit@10 (88,33 % vs 88,00 %), ce qui signifie qu'il classe légèrement mieux les documents pertinents sur l'ensemble du top-10. Mais pour la plupart des applications où c'est l'exactitude du premier résultat qui compte, le modèle de 149M est suffisant.
Le plus grand modèle n'est pas le meilleur
qwen3_reranker_4b a 4B paramètres et prend plus d'une seconde par requête. Il atteint 77,67 % de Hit@1, se classant quatrième derrière nemotron (1,2B), gte_modernbert (149M) et jina (560M). Vous payez 4,5x la latence de nemotron pour 5,3 points de pourcentage de précision en moins.
L'architecture de qwen3 utilise la modélisation causale du langage avec une approche logit oui/non. Le modèle lit la paire requête-document et produit la probabilité de « oui, c'est pertinent ». C'est conceptuellement propre, mais l'inférence est coûteuse en raison de la surcharge du décodage autorégressif. Les modèles SequenceClassification (gte_modernbert, bge) et l'approche par template de prompt de nemotron traitent la paire en une seule passe avant, ce qui est fondamentalement plus rapide.
Jina offre le meilleur compromis vitesse-précision
jina_reranker_v3 atteint 81,33 % de Hit@1 en 188ms. nemotron atteint 83,00 % en 243ms. Si vous avez besoin d'une latence totale inférieure à 200ms par requête, Jina est le seul modèle du premier groupe à le permettre. L'écart de 1,67 point de pourcentage peut ne pas justifier les 55ms supplémentaires dans un système en production traitant des milliers de requêtes par seconde.
Un reranker détériore les résultats
mxbai_rerank_xsmall (70M paramètres) obtient 64,67 % de Hit@1. La référence sans reranker obtient 62,67 %. L'amélioration n'est que de 2 points de pourcentage, ce qui est dans la marge de bruit pour 300 requêtes. Avec 70M paramètres, le modèle manque de capacité pour juger de manière fiable la pertinence requête-document sur des textes plus longs ou plus nuancés.
Un reranker n'est pas automatiquement bénéfique. Testez-le sur vos données réelles avant de le déployer.
Le retriever fixe le plafond
Tous les meilleurs rerankers convergent autour de 87-88 % de Hit@10. Ce plafond provient du retriever. Si multilingual-e5-base ne place pas le bon document dans les 100 premiers candidats, aucun reranker ne peut le récupérer. Les 12 % restants de requêtes où chaque reranker échoue représentent les cas où le retriever dense a tout simplement manqué le document pertinent.
Améliorer au-delà de ce plafond nécessite un meilleur retriever, un plus grand ensemble de candidats, ou les deux. Nous avons testé les 250 premiers candidats et n'avons constaté quasiment aucune amélioration par rapport au top-100, ce qui signifie que e5_base épuise ses candidats utiles bien avant le rang 250.
Comment fonctionnent les rerankers
Un retriever dense (bi-encoder) encode les requêtes et les documents indépendamment en vecteurs. La recherche est une recherche des plus proches voisins sur ces vecteurs. C'est rapide car vous encodez uniquement la requête au moment de la recherche, mais le modèle ne voit jamais la requête et le document ensemble, il peut donc manquer des signaux de pertinence nuancés.
Un reranker (cross-encoder) prend une paire requête-document comme une seule entrée. Le modèle traite les deux textes conjointement, capturant des relations que l'encodage indépendant manque. Le coût est qu'il faut exécuter le modèle une fois par candidat, vous ne pouvez donc vous permettre de scorer qu'un petit ensemble.
Architectures dans ce benchmark
Nous avons testé quatre architectures de cross-encoder différentes :
Les modèles SequenceClassification (bge_base, bge_v2_m3, mxbai_xsmall, gte_modernbert) prennent une paire [query, document] en entrée et produisent un score logit unique. C'est l'approche la plus simple et la plus courante.
Nemotron utilise un format de template de prompt : « question:{q} passage:{p} ». L'entrée ressemble à du texte brut plutôt qu'à une paire structurée, mais le modèle produit tout de même un score de pertinence unique via SequenceClassification. Le pré-entraînement LLM (basé sur Llama) lui confère une forte compréhension du langage.
Les rerankers Qwen3 utilisent la modélisation causale du langage. Le modèle lit la paire et génère un jugement oui/non. Le score est log P(oui) / (P(oui) + P(non)). Cela nécessite toute la machinerie autorégressive, 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 utilise l'attention croisée, mais l'interface masque les détails.
Méthodologie du benchmark des rerankers
- GPU : NVIDIA H100 PCIe 80GB via Runpod
- Base de données vectorielle : Qdrant 1.12.0 (binaire local), distance cosinus
- Retriever : multilingual-e5-base (768-dim). Préfixe de requête :
"query: ", préfixe de document :"passage: " - Logiciel : transformers 5.2.0, PyTorch 2.8.0, CUDA 12.8.1
- Jeu de données : Sous-ensemble anglais de Amazon Reviews Multi (Kaggle).1 ~145k avis après filtrage pour un minimum de 100 caractères. Chaque avis a un product_id, un texte d'avis et une note en étoiles.
- Génération de requêtes : Claude Sonnet 4.6 via OpenRouter. 300 requêtes en anglais (5 types : factuelles, d'opinion, d'utilisation, de résolution de problèmes, de comparaison de fonctionnalités). Chaque requête doit faire référence à des détails spécifiques de son avis source ; les questions génériques (score de spécificité < 4/5) sont filtrées.
- Format de document :
"Review Title: {title}\nReview: {body}" - Pipeline : Récupérer les 100 premiers candidats avec multilingual-e5-base, reranker avec le cross-encoder, retourner le top-10. La référence saute le reranking et retourne directement le top-10 du retriever.
- Vérité terrain : Correspondance exacte du product_id uniquement. Pas de recours à la similarité cosinus. Pas de crédit partiel pour des produits sémantiquement similaires.
- Variable contrôlée : Seul le modèle de reranker change entre les expériences. Le retriever, le nombre de candidats, l'ensemble de requêtes et les critères d'évaluation sont identiques pour toutes les exécutions.
- Pas de fine-tuning : Tous les modèles sont évalués en zero-shot avec les poids HuggingFace par défaut.
- Latence : Reranking (scoring par cross-encoder de 100 candidats). Mesurée par requête sur GPU.
Modèles testés
Ajouter comme source préféréeLimites
Ce benchmark utilise un seul retriever (multilingual-e5-base). Un retriever différent produirait des ensembles de candidats différents et pourrait modifier le classement des rerankers. Les résultats reflètent la performance de chaque reranker avec ce retriever spécifique, et non la qualité du reranker de manière isolée.
Nous avons testé sur des avis de produits Amazon en anglais. Les performances sur d'autres domaines (articles scientifiques, documents juridiques, code) ou d'autres langues seront différentes.
Le nombre de candidats est fixé à 100. Certains rerankers pourraient classer différemment avec 20 ou 200 candidats. Nous avons testé 250 candidats et constaté une amélioration négligeable, ce qui suggère que 100 est suffisant pour e5_base, mais d'autres retrievers pourraient se comporter différemment.
300 requêtes est une taille d'échantillon modérée. Les trois meilleurs modèles (nemotron, gte_modernbert, jina) sont séparés par moins de 2 points de pourcentage. Avec un ensemble de requêtes plus large, ces classements pourraient changer. L'écart entre le premier groupe et le dernier groupe (20+ points de pourcentage) est robuste.
Conclusion
Les rerankers fonctionnent. Le meilleur modèle de ce benchmark fait passer le Hit@1 de 62,67 % à 83,00 % (+20,33pp), ce qui signifie que 20 requêtes sur 100 qui retournaient auparavant le mauvais document en premier retournent maintenant le bon. C'est un gain significatif pour un composant qui ajoute moins de 250ms de latence.
La conclusion la plus utile est que la taille du modèle ne détermine pas la qualité du reranker. gte-reranker-modernbert-base avec 149M paramètres égale nemotron-rerank-1b avec 1,2B sur le Hit@1. Le modèle Qwen3 de 4B paramètres termine quatrième. Si vous choisissez un reranker pour un système en production, commencez par les petits modèles. Vous n'aurez peut-être jamais besoin des plus grands.
Pour les applications sensibles à la latence, jina-reranker-v3 est l'option la plus performante sous les 200ms. Pour une précision maximale sans contrainte de latence, nemotron-rerank-1b et gte-reranker-modernbert-base se partagent la première place. Pour les équipes avec un budget GPU limité, gte-modernbert est le vainqueur incontestable : même précision que le modèle de 1,2B pour une fraction de l'empreinte mémoire.
Un motif s'est maintenu dans toutes les expériences : le retriever fixe le plafond. Aucun reranker n'a poussé le Hit@10 au-dessus de 88 %, car les 12 % restants de documents corrects ne sont jamais apparus dans les 100 premiers candidats. Investir dans un meilleur retriever produira probablement des gains plus importants que de passer d'un reranker du top 3 à un autre.
Pour aller plus loin
Explorez d'autres benchmarks RAG, tels que :
- Modèles d'embedding : OpenAI vs Gemini vs Cohere
- Top 16 modèles d'embedding open source pour le RAG
- Meilleure base de données vectorielle pour le RAG : Qdrant vs Weaviate vs Pinecone
- Benchmark de RAG agentique : routage multi-bases de données et génération de requêtes
- Modèles d'embedding multimodaux : Apple vs Meta vs OpenAI
- RAG hybride : Améliorer la précision du RAG
- Top 10 modèles d'embedding multilingues pour le RAG
Citez ce benchmark
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{Benchmark des rerankers: Comparaison des 8 meilleurs modèles}},
year = {2026},
month = feb,
howpublished = {\url{https://aimultiple.com/rerankers}},
note = {AIMultiple. Consulté le 26 Février 2026}
}Résultats et horodatages de 17 points de données. Téléchargez les données utilisées dans cet article sous forme de fichier ZIP contenant 2 fichiers CSV et un README.
Liens de référence
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.