Accueil › Glossaire › Reranking

Reranking (Reclassement)

Le reranking est une étape de post-traitement dans un pipeline de recherche d’information qui reclasse les résultats initiaux d’un retriever en utilisant un modèle plus précis, typiquement un cross-encoder, pour améliorer la pertinence du classement final.

Le problème est simple : votre recherche vectorielle ou votre hybrid search renvoie 50 candidats, mais le classement n’est pas optimal. Des documents vaguement liés se retrouvent avant des documents très pertinents parce que les embeddings compressent le sens en un seul vecteur, ce qui cause inévitablement une perte d’information. Le reranker corrige ce problème en analysant chaque paire requête-document de façon beaucoup plus fine. C’est la différence entre un tri approximatif rapide et un tri précis lent. Le pipeline à deux étages (retrieval rapide → reranking précis) combine le meilleur des deux.

Pourquoi le reranking est nécessaire

Le problème du bi-encoder

Les systèmes de recherche vectorielle utilisent des bi-encoders pour encoder séparément la requête et les documents en vecteurs. C’est rapide : les documents sont pré-encodés une seule fois, et seule la requête doit être encodée à chaque recherche. Mais cette vitesse a un coût. Compresser tout le sens d’un document de 500 mots en un seul vecteur de 768 ou 1024 dimensions implique une perte d’information significative.

Concrètement, un bi-encoder ne voit jamais la requête et le document en même temps. Il produit un vecteur « générique » du document qui doit fonctionner pour toutes les requêtes possibles. C’est un compromis raisonnable pour chercher parmi des millions de documents en quelques millisecondes, mais insuffisant pour un classement précis des top résultats.

Des études empiriques montrent que les bi-encoders atteignent typiquement 65 à 80% de précision sur les requêtes complexes. Cela signifie que 20 à 35% de l’information envoyée au LLM dans un pipeline RAG est bruitée ou non pertinente. Le reranking corrige ce problème en poussant la précision à 85-90% sur les top résultats.

L’avantage du cross-encoder

Un cross-encoder fonctionne différemment. Il prend la requête et le document concaténés en entrée et les traite ensemble dans un Transformer. Chaque token de la requête peut « voir » chaque token du document via le mécanisme d’attention. Le modèle produit un score de pertinence unique entre 0 et 1.

Cette architecture capture des relations sémantiques fines que le bi-encoder rate. Par exemple, si la requête est « impact du recycling sur la réduction des risques sanitaires », un bi-encoder peut renvoyer des documents sur le recyclage en général. Un cross-encoder comprend le lien causal entre « recyclage » et « réduction des risques sanitaires » et classe mieux les documents qui traitent spécifiquement de cette relation.

Le revers : un cross-encoder doit évaluer chaque paire requête-document séparément. Pour 50 candidats, c’est 50 passages dans le modèle. C’est beaucoup trop lent pour chercher dans des millions de documents, mais parfaitement faisable sur un ensemble de 20 à 100 candidats pré-filtrés. D’où le pipeline à deux étages.

Le pipeline à deux étages : retrieval + reranking

C’est l’architecture standard de tout système de recherche sérieux en production. Deux étapes complémentaires, chacune optimisée pour un objectif différent.

Étage 1 : Retrieval (rapide, large)

Un bi-encoder ou un hybrid search (BM25 + vecteurs) récupère rapidement les top 50 à 100 candidats parmi des millions de documents. L’objectif est le recall : ne pas rater de documents pertinents. La vitesse est critique, typiquement moins de 50 ms.

Étage 2 : Reranking (lent, précis)

Un cross-encoder ou un modèle de reranking évalue chaque candidat par rapport à la requête et produit un nouveau classement. L’objectif est la precision : s’assurer que les top 3-5 résultats sont les plus pertinents. La latence est de l’ordre de quelques centaines de millisecondes pour 50 candidats.

Ce pattern existe depuis longtemps en search engineering, bien avant les LLM. Google l’utilise depuis des années (retrieval rapide puis re-scoring fin). Son adoption massive dans les pipelines RAG est la tendance marquante de ces dernières années.

Les différents types de rerankers

Cross-encoders

Le type le plus courant. Le cross-encoder encode la requête et le document ensemble dans un Transformer et produit un score de pertinence. Le modèle open source le plus utilisé est cross-encoder/ms-marco-MiniLM-L-6-v2 de Sentence Transformers, entraîné sur le dataset MS MARCO de Bing. Il est léger (environ 22M de paramètres), rapide sur CPU, et offre un bon rapport qualité-latence pour la plupart des cas d’usage.

Les modèles BGE Reranker (de BAAI) sont aussi très populaires en open source, avec des variantes de tailles différentes. bge-reranker-v2-m3 est le modèle recommandé pour un usage multilingue.

Late interaction (ColBERT)

ColBERT (Contextualized Late Interaction over BERT) représente un compromis entre bi-encoder et cross-encoder. Il encode séparément la requête et le document en matrices de vecteurs au niveau des tokens (pas un seul vecteur), puis calcule la similarité via une opération MaxSim entre chaque token de la requête et chaque token du document. L’avantage : les embeddings de documents peuvent être pré-calculés, ce qui rend ColBERT beaucoup plus rapide qu’un cross-encoder classique tout en capturant des interactions fines.

Jina ColBERT v2 est la version multillingue la plus récente, supportant 89 langues avec des contextes jusqu’à 8192 tokens. Jina Reranker v3 pousse le concept plus loin avec son architecture « last but not late interaction » (LBNL) qui traite requête et documents dans la même fenêtre de contexte.

LLM-based rerankers (RankGPT)

Une approche plus récente consiste à utiliser un LLM pour classer les documents. RankGPT utilise GPT-4 (ou un autre LLM) pour évaluer et classer une liste de documents par pertinence. L’avantage est un excellent zero-shot performance : pas besoin de modèle spécialisé. L’inconvénient : c’est nettement plus lent et plus coûteux qu’un cross-encoder dédié. Google Vertex AI RAG Engine permet aussi d’utiliser Gemini comme reranker via son API.

RankZephyr est une alternative open source basée sur Mistral-7B, fine-tuné pour le reranking par distillation de RankGPT. Il offre un bon compromis entre la qualité d’un LLM reranker et le coût d’un modèle plus petit.

FlashRank (léger et rapide)

FlashRank est une bibliothèque Python optimisée pour le reranking rapide sur CPU, utilisant des modèles ONNX compacts. Elle est conçue pour les cas où la latence est critique et les ressources GPU limitées. Le gain de pertinence est moindre qu’un gros cross-encoder, mais significatif par rapport à l’absence de reranking. C’est l’option « mieux que rien » la plus simple à déployer.

Les modèles de reranking en production

Implémenter le reranking : exemples concrets

Avec un cross-encoder open source (Python)

from sentence_transformers import SentenceTransformer, CrossEncoder, util

# 1. Retrieval initial avec un bi-encoder
bi_encoder = SentenceTransformer('all-MiniLM-L6-v2')
corpus = [
    "Guide pour protéger vos plantes du gel hivernal",
    "Recette de confiture de fraises maison",
    "Comment isoler votre jardin contre le froid",
    "Les meilleures variétés de tomates résistantes",
    "Protéger les cultures sensibles au gel : méthodes",
]
corpus_embeddings = bi_encoder.encode(corpus, convert_to_tensor=True)

query = "protéger mon jardin du gel"
query_embedding = bi_encoder.encode(query, convert_to_tensor=True)

# Top-5 par recherche vectorielle
hits = util.semantic_search(query_embedding, corpus_embeddings, top_k=5)[0]

# 2. Reranking avec un cross-encoder
cross_encoder = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-6-v2')
rerank_pairs = [(query, corpus[hit['corpus_id']]) for hit in hits]
rerank_scores = cross_encoder.predict(rerank_pairs)

# 3. Trier par score du cross-encoder
results = sorted(
    zip(rerank_scores, [corpus[h['corpus_id']] for h in hits]),
    reverse=True
)
for score, doc in results:
    print(f"Score: {score:.3f} | {doc}")

Ce code illustre le pattern complet : le bi-encoder récupère rapidement les candidats, puis le cross-encoder les reclasse avec une bien meilleure précision. En production, remplacez le bi-encoder par un hybrid search (BM25 + vecteurs) pour un recall encore meilleur.

Avec Cohere Rerank (API)

import cohere

co = cohere.Client("YOUR_API_KEY")

query = "protéger mon jardin du gel"
documents = [
    "Guide pour protéger vos plantes du gel hivernal",
    "Recette de confiture de fraises maison",
    "Comment isoler votre jardin contre le froid",
]

results = co.rerank(
    model="rerank-v3.5",  # ou rerank-v4-pro quand disponible
    query=query,
    documents=documents,
    top_n=3
)

for result in results.results:
    print(f"Index: {result.index} | Score: {result.relevance_score:.3f}")
    print(f"  {documents[result.index]}")

Avec LangChain (intégration pipeline RAG)

from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import FlashrankRerank
from langchain_community.vectorstores import Chroma

# Retriever initial (vectorstore)
vectorstore = Chroma.from_documents(documents, embeddings)
base_retriever = vectorstore.as_retriever(search_kwargs={"k": 20})

# Ajouter le reranking avec FlashRank
compressor = FlashrankRerank(top_n=5)
reranking_retriever = ContextualCompressionRetriever(
    base_compressor=compressor,
    base_retriever=base_retriever
)

# Utilisation
docs = reranking_retriever.invoke("protéger mon jardin du gel")
# Retourne les 5 documents les plus pertinents après reranking

LangChain et LlamaIndex offrent des abstractions qui rendent le reranking trivial à intégrer dans un pipeline RAG existant. ContextualCompressionRetriever wrappe n’importe quel retriever et ajoute un reranker transparent.

Bonnes pratiques du reranking

Récupérez large, rerankez serré. Réglez votre retriever pour renvoyer 50 à 100 candidats, puis laissez le reranker sélectionner les 5 à 10 meilleurs. Plus vous donnez de candidats au reranker, plus il a de chances de trouver les documents réellement pertinents que le bi-encoder a mal classés.

Le reranking ne compense pas un mauvais retrieval. Si vos documents pertinents ne sont pas dans les 100 premiers candidats du retriever, le reranker ne peut rien y faire. Optimisez d’abord votre retrieval (hybrid search, chunking, modèle d’embedding adapté) avant d’ajouter un reranker.

Mesurez l’impact. Comparez les métriques avant et après reranking sur un jeu de test : precision@k, NDCG@10, MRR. Le gain doit justifier la latence supplémentaire. Sur la majorité des datasets, le reranking améliore le NDCG@10 de 20 à 40%.

Batch processing pour la performance. Envoyez toutes les paires requête-document en un seul batch au cross-encoder plutôt qu’une par une. Cela améliore significativement l’utilisation GPU et réduit la latence totale.

Choix du modèle selon vos contraintes. GPU disponible et budget API ? Cohere Rerank 4 ou Jina Reranker v3 via API. CPU-only avec latence serrée ? FlashRank ou ms-marco-MiniLM. Corpus multilingue ? BGE Reranker v2-m3 ou Jina ColBERT v2. Pipeline RAG simple ? ms-marco-MiniLM est le baseline le plus solide.

Reranking vs autres approches d’amélioration

Le reranking n’est pas la seule façon d’améliorer la qualité du retrieval. Voici comment il se compare aux alternatives.

Reranking vs meilleur modèle d’embedding : Un modèle d’embedding plus puissant (passer de MiniLM à text-embedding-3-large) améliore le retrieval initial mais ne remplace pas le reranking. Le cross-encoder capture des interactions que même le meilleur bi-encoder ne peut pas modéliser. Les deux sont complémentaires.

Reranking vs hybrid search : Le hybrid search améliore le recall (trouver plus de documents pertinents dans les candidats). Le reranking améliore la precision (classer les candidats par ordre de pertinence). Les deux sont des étapes différentes du pipeline et s’additionnent. Le pipeline optimal est : hybrid search → reranking.

Reranking vs fine-tuning de l’embedding : Fine-tuner votre modèle d’embedding sur votre domaine améliore à la fois recall et precision du retrieval initial. C’est plus complexe à mettre en place mais peut réduire la dépendance au reranking. En pratique, les deux se combinent bien : un embedding fine-tuné + un reranker donne les meilleurs résultats.

Verdict

Le reranking est le levier d’amélioration le plus simple et le plus efficace pour tout pipeline de recherche ou de RAG. Si vous n’utilisez pas de reranker aujourd’hui, c’est probablement la prochaine étape qui vous donnera le meilleur ROI en qualité de résultats. L’ajout d’un cross-encoder open source comme ms-marco-MiniLM prend quelques lignes de code et améliore la précision des top résultats de 20 à 40% en moyenne.

Pour la production à grande échelle, Cohere Rerank 4 est le choix le plus complet (performance, multilingue, self-learning, contexte 32K). Pour le self-hosted, BGE Reranker v2-m3 ou Jina Reranker v3 offrent un excellent rapport qualité-coût. Pour le prototypage rapide, FlashRank ou ms-marco-MiniLM suffisent largement.

Le pipeline standard en 2026 est clair : hybrid search (BM25 + vecteurs) → fusion RRF → reranking cross-encoder → top résultats vers le LLM. Chaque étape apporte une amélioration mesurable, et le reranking est celle qui a le meilleur ratio effort/gain.