Benchmark de rerankers: Top 8 modèles comparés
Nous avons évalué 8 modèles de reranking sur ~145k avis Amazon en anglais afin de mesurer l'amélioration apportée par une étape de reranking à la recherche dense. Nous avons récupéré les 100 meilleurs candidats avec multilingual-e5-base, les avons reclassés avec chaque modèle, et avons évalué les 10 meilleurs 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
Explication des métriques :
ΔHit@1 / ΔHit@10 indique 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 au score de référence de 62.67 %.
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 classe dans le top-K, cela compte comme un succès. Hit@1 est le test le plus strict : le premier résultat provient-il du bon produit ? Hit@10 est plus tolérant : le bon produit apparaît-il quelque part dans les 10 premiers résultats ?
MRR@10 (Mean Reciprocal Rank) moyenne le 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 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 bon produit aussi haut que possible.
nDCG@10 (Normalized Discounted Cumulative Gain) évalue les positions de tous les avis correspondants dans le top-10, et 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, nDCG crédite chacun en fonction de sa position. En pratique, la plupart des produits n'ont que 1 à 2 avis parmi les 100 candidats, donc nDCG et MRR sont très proches.
Recall@10 mesure la proportion d'avis correspondants (même product_id) dans le top-10 parmi tous les avis correspondants de l'ensemble de candidats complet (top-100). Si un produit a 3 avis parmi les 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 presque identiques dans ce benchmark.
Détail de la latence
La latence de reranking mesure le temps nécessaire à chaque cross-encodeur pour évaluer les 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.
Explication des métriques de latence :
Rerank est le temps nécessaire au cross-encodeur pour évaluer les 100 documents candidats par rapport à la requête. C'est là que les modèles diffèrent : une simple passe avant est rapide, tandis que le décodage autorégressif est lent.
P95 est le 95 percentile de latence totale. Certaines requêtes ont des textes d'avis plus longs, ce qui augmente le temps de tokenisation et d'évaluation. P95 montre le pire cas auquel vous devez vous attendre pour 95 % des requêtes.
Principaux résultats
Un modèle de 149M rivalise avec un modèle de 1.2B
gte-reranker-modernbert-base possède 149M paramètres, nemotron-rerank-1b possède 1.2B. Les deux atteignent 83.00 % de Hit@1 en anglais. L'architecture ModernBERT est 8x plus petite et offre une précision globale identique.
Cela ne signifie pas que la taille du modèle n'a pas d'importance. nemotron est légèrement en tête sur MRR@10 (0.8514 vs 0.8483) et Hit@10 (88.33 % vs 88.00 %), ce qui signifie qu'il classe les documents pertinents légèrement mieux dans l'ensemble du top-10. Mais pour la plupart des applications où c'est le 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 possède 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 une modélisation de langage causale avec une approche de logit oui/non. Le modèle lit la paire requête-document et produit la probabilité de « oui, ceci est pertinent ». C'est conceptuellement propre, mais l'inférence est coûteuse en raison du surcoût du décodage autorégressif. Les modèles SequenceClassification (gte_modernbert, bge) et l'approche par modèle 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 à 188ms. nemotron atteint 83.00 % à 243ms. Si vous avez besoin d'une latence totale inférieure à 200ms par requête, Jina est le seul modèle du premier groupe à y parvenir. L'écart de 1.67 point de pourcentage peut ne pas justifier les 55ms supplémentaires dans un système de production servant des milliers de requêtes par seconde.
Un reranker aggrave les résultats
mxbai_rerank_xsmall (70M paramètres) obtient 64.67 % de Hit@1. La référence sans aucun reranker obtient 62.67 %. L'amélioration n'est que de 2 points de pourcentage, ce qui est dans la marge d'erreur pour 300 requêtes. Avec 70M paramètres, le modèle n'a pas la capacité d'évaluer 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 parmi les 100 candidats, aucun reranker ne peut le récupérer. Les 12 % restants de requêtes où tous les rerankers échouent représentent des 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 pool de candidats, ou les deux. Nous avons testé un top-250 candidats et n'avons constaté presque 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-encodeur) 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 n'encodez que 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-encodeur) prend une paire requête-document comme entrée unique. Le modèle traite les deux textes conjointement, capturant des relations que l'encodage indépendant manque. Le coût est que vous devez exécuter le modèle une fois par candidat, vous ne pouvez donc évaluer qu'un petit pool.
Architectures de ce benchmark
Nous avons testé quatre architectures différentes de cross-encodeurs :
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 gabarit 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 solide compréhension du langage.
Les rerankers Qwen3 utilisent une modélisation de langage causale. 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 l'évaluation 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 possède un product_id, un texte d'avis et une note en étoiles.
- Génération des requêtes : Claude Sonnet 4.6 via OpenRouter. 300 requêtes en anglais (5 types : factuelles, opinion, usage, résolution de problèmes, comparaison de fonctionnalités). Chaque requête doit faire référence à des détails précis de son avis source ; les questions génériques (score de spécificité < 4/5) sont filtrées.
- Format du document :
"Review Title: {title}\nReview: {body}" - Pipeline : Récupérer les top-100 candidats avec multilingual-e5-base, les reclasser avec un cross-encodeur, renvoyer le top-10. La référence ignore le reranking et renvoie directement le top-10 du retriever.
- Vérité terrain : correspondance exacte du product_id uniquement. Aucune solution de repli par similarité cosinus. Aucun crédit partiel pour les 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 dans 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 (évaluation par cross-encodeur 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 capacité de chaque reranker à fonctionner avec ce retriever spécifique, et non la qualité du reranker isolément.
Nous avons testé sur des avis de produits Amazon en anglais. Les performances sur d'autres domaines (articles scientifiques, documents juridiques, code) ou dans d'autres langues seront différentes.
Le nombre de candidats est fixé à 100. Certains rerankers pourraient se 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 peuvent se comporter différemment.
300 requêtes constituent une taille d'échantillon modérée. Les trois premiers modèles (nemotron, gte_modernbert, jina) sont séparés par moins de 2 points de pourcentage. Avec un plus grand ensemble de requêtes, ce classement pourrait changer. L'écart entre le premier groupe et le dernier (20 points de pourcentage ou plus) 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 renvoyaient auparavant le mauvais document en premier renvoient désormais le bon. C'est un gain significatif pour un composant qui ajoute moins de 250ms de latence.
L'enseignement le 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 à 1.2B sur le Hit@1. Le modèle Qwen3 de 4B paramètres arrive quatrième. Si vous choisissez un reranker pour un système de production, commencez par les modèles plus petits. Vous n'aurez peut-être jamais besoin des plus grands.
Pour les applications sensibles à la latence, jina-reranker-v3 est l'option la plus solide 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 disposant d'un budget GPU limité, gte-modernbert est le grand gagnant : la même précision que le modèle de 1.2B avec une fraction de l'empreinte mémoire.
Une constante s'est dégagée de toutes les expériences : le retriever fixe le plafond. Aucun reranker n'a fait passer le Hit@10 au-dessus de 88 %, car les 12 % restants de documents corrects ne sont jamais apparus parmi les 100 meilleurs candidats. Investir dans un meilleur retriever produira probablement des gains plus importants que de passer d'un des trois meilleurs rerankers à un autre.
Pour aller plus loin
Explorez d'autres benchmarks RAG, tels que :
- Modèles d'embedding : OpenAI vs Gemini vs Cohere
- Top 16 des modèles d'embedding open source pour le RAG
- Top des bases de données vectorielles 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
- Top 10 des 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 de rerankers: Top 8 modèles comparés}},
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
À lire ensuite
Meilleurs fournisseurs de proxy en France: benchmark et tarification
Best AliExpress Scrapers: Decodo, Nimble & Zyte
Benchmark Agentic Marketing AIM
Top 10 générateurs de documents Word IA: évalués et testés
Exécution de code avec MCP: une nouvelle approche de l'efficacité des agents IA
Surveillance de MySQL: SolarWinds vs New Relic vs Datadog
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.