La plupart des pipelines RAG déçoivent en production pour une seule raison : la recherche vectorielle seule remonte souvent les mauvais documents en tête de liste. Les cinq meilleurs résultats contiennent bien l’information pertinente, mais pas forcément aux positions 1 et 2 — et c’est précisément ce que le LLM lit en priorité. Le reranking intercepte le top-K renvoyé par la recherche vectorielle et le re-score avec un modèle plus précis mais plus coûteux, pour garantir que les meilleurs documents remontent effectivement en tête. En production, l’ajout d’une couche de reranking bien calibrée améliore généralement la pertinence du RAG de 15 à 35 % mesurée en nDCG@5. L’enjeu technique est de choisir le bon modèle de reranking et de l’intégrer sans dégrader la latence. LLM — Modèles de Langage : guide complet
À retenir en 30 secondes : le reranking utilise un cross-encoder (ou un LLM) qui prend en entrée la paire (requête, document) et produit un score de pertinence. Il opère sur un ensemble restreint de candidats (10 à 50) remontés par un retriever rapide (recherche vectorielle). Les modèles dédiés comme bge-reranker-v2 ou Cohere Rerank 3 offrent un excellent rapport performance/coût. L’intégration ajoute 50 à 200 ms de latence sur l’ensemble de la requête, un coût acceptable dans la plupart des contextes production. Long-context LLMs : techniques et limites pour exploiter réellement 1 million de tokens en production
Pourquoi la recherche vectorielle seule atteint ses limites
Un retriever vectoriel calcule un embedding de la requête, puis trouve les documents dont les embeddings sont les plus proches en similarité cosinus. Cette approche est rapide — recherche sublinéaire sur des millions de vecteurs — mais elle encode chaque document indépendamment de la requête. L’embedding d’un document doit « deviner » toutes les requêtes auxquelles il peut répondre, ce qui limite sa précision contextuelle. En pratique, la recherche vectorielle est excellente pour le rappel (ne pas rater les documents pertinents) mais médiocre pour la précision du classement (ordonner finement les candidats). Le reranking répare exactement cette faiblesse. Fine-tuning d'embeddings : adapter un modèle de retrieval à votre domaine métier
L’architecture bi-encodeur / cross-encodeur
Le retriever vectoriel est un bi-encodeur : il encode séparément la requête et chaque document en vecteurs, puis compare par similarité. L’avantage : les embeddings de documents sont pré-calculés une fois, la recherche est très rapide. Le reranker est un cross-encodeur : il prend simultanément la requête et un document en entrée, et produit un score de pertinence conditionnel. L’avantage : la précision contextuelle est bien supérieure. L’inconvénient : il faut appeler le modèle N fois (une fois par candidat), ce qui est trop coûteux pour scanner toute la base — mais parfaitement acceptable sur 10 à 50 candidats pré-filtrés. L’architecture optimale combine donc les deux étages : bi-encodeur pour le rappel, cross-encodeur pour la précision.
Choisir son modèle de reranking
Trois familles de solutions dominent en 2026. Les cross-encoders open source (bge-reranker-v2-m3, jina-reranker-v2, mxbai-rerank-large) sont déployables sur CPU ou GPU modeste, performent très bien en français et offrent un contrôle total. Les APIs managées de reranking (Cohere Rerank 3, Voyage AI Rerank, Mistral Rerank) externalisent l’infra et offrent une qualité élevée, au prix d’une dépendance externe et d’un coût à la requête. Les LLM généralistes utilisés comme reranker (via un prompt « note la pertinence de ce document pour cette requête ») offrent la meilleure précision pour les cas les plus complexes, mais à un coût de latence et d’inférence prohibitif pour la plupart des workloads production. Le choix par défaut qui donne le meilleur rapport effort/gain en 2026 est bge-reranker-v2-m3 déployé en interne.
Intégrer un reranker dans un pipeline RAG existant
Le pattern d’intégration est quasi standard. Étape 1 : la recherche vectorielle remonte top-K candidats (typiquement K entre 20 et 50). Étape 2 : chaque candidat est soumis au reranker avec la requête originale pour obtenir un score. Étape 3 : les candidats sont réordonnés par score, et les top-N (typiquement N entre 3 et 10) sont effectivement injectés dans le contexte du LLM. Cette architecture s’intègre naturellement dans LangChain, LlamaIndex ou Haystack via leurs modules dédiés, ou dans un pipeline maison en quelques dizaines de lignes. L’ajout de latence est généralement compris entre 50 et 200 ms selon le modèle et le batching — à comparer aux 500 à 2000 ms d’inférence LLM qui suivent.
Mesurer l’impact : les métriques qui comptent
L’évaluation du reranking nécessite un jeu de données annoté : des paires (requête, documents) avec des labels de pertinence (idéalement gradués 0-3). Les métriques standards sont le nDCG@K (normalized Discounted Cumulative Gain, qui pondère la pertinence par la position), le MRR (Mean Reciprocal Rank, qui mesure la position du premier document pertinent), et la précision@K. Mesurer ces métriques avant et après l’ajout du reranking donne une image quantitative de l’amélioration. Au-delà des métriques, une évaluation qualitative de bout en bout (le RAG final répond-il mieux ?) via le processus d’évaluation d’un LLM avant déploiement complète l’analyse technique.
Variantes avancées : hybrid search et fusion de scores
Au-delà du reranking classique, deux techniques prolongent l’approche. L’hybrid search combine à l’étage de retrieval des scores de recherche vectorielle et des scores BM25 (recherche lexicale), avec une fusion par Reciprocal Rank Fusion (RRF). Cela améliore sensiblement le rappel sur les requêtes contenant des termes rares ou des codes produits. La fusion de scores reranking + métadonnées ajoute dans le classement final des signaux hors contenu (fraîcheur du document, autorité de la source, préférences utilisateur). Ces variantes sont à ajouter uniquement après avoir mesuré l’impact du reranking de base — l’erreur fréquente est de superposer trop de couches sans mesure incrémentale. Pour un comparatif approfondi des bases vectorielles qui supportent nativement l’hybrid search, consultez notre guide sur comment choisir une base vectorielle pour un RAG en production.
Pour aller plus loin sur les techniques de recherche hybride et les benchmarks, le site de Cohere documente de manière détaillée les gains observés en production et reste une référence utile.
Mon point de vue d’expert
En consulting, le reranking est l’optimisation que je recommande en priorité quand une équipe me dit « notre RAG ne trouve pas la bonne réponse ». Dans 80 % des cas, l’information est dans le top-10 remonté par la recherche vectorielle, mais pas dans le top-3 effectivement injecté au LLM. Ajouter un reranker open source bien calibré règle ce problème pour un coût d’intégration marginal (quelques jours de développement, quelques dizaines de millisecondes de latence ajoutées). Mon conseil aux équipes françaises : commencez par bge-reranker-v2-m3 sur CPU, mesurez l’amélioration en nDCG@5, puis investissez dans un modèle plus performant ou une API managée seulement si le gain est insuffisant. L’ingénierie prématurée sur ce composant est une des erreurs les plus courantes des équipes RAG qui démarrent.
FAQ : reranking RAG en production
- Combien de candidats faut-il reranker ?
- Entre 20 et 50 candidats en entrée est le compromis typique. Moins, et vous risquez de rater les documents pertinents absents du top-10 vectoriel. Plus, et la latence du reranker devient significative. Mesurez le gain marginal sur votre workload : si passer de 20 à 50 n’améliore pas nDCG@5, restez à 20.
- Faut-il reranker à chaque requête ?
- Pour les requêtes utilisateur en interaction directe, oui — le gain qualitatif justifie largement l’overhead. Pour les requêtes batch à faible stake (indexation, catégorisation automatique), un bi-encodeur plus performant peut suffire sans reranker, pour économiser le coût d’inférence. Cette décision se prend au cas par cas.
- Un reranker peut-il remplacer un meilleur modèle d’embedding ?
- Partiellement, mais pas totalement. Un bon modèle d’embedding améliore le rappel (quels documents sont dans le top-K) ; un bon reranker améliore la précision du classement final. Les deux sont complémentaires et non substituables. Si vos documents pertinents ne remontent pas du tout, c’est l’embedding qu’il faut améliorer. S’ils remontent mais mal classés, c’est le reranker qui apportera le gain.
- Les rerankers fonctionnent-ils bien sur du contenu en français ?
- Les modèles multilingues modernes (bge-reranker-v2-m3, jina-reranker-v2-base-multilingual, Cohere Rerank 3) sont tous entraînés sur du français parmi d’autres langues et offrent d’excellentes performances sur du contenu francophone. Un modèle purement anglais appliqué à du français perd 15 à 25 % de qualité et doit être évité.