Reranking RAG : cross-encoder, ColBERT ou LLM ?

Le reranking, c’est quoi ? (et pourquoi ce n’est pas “du luxe”)

Un système RAG classique fait :

1. retrieve : retrouver des passages (rapide, approximatif)
2. generate : générer une réponse à partir des passages (cher, sensible au contexte)

Le problème : si vos passages sont “à peu près” bons, votre réponse le sera aussi.
Et “à peu près” n’est pas une stratégie, c’est une façon polie d’écrire “incident”.

Le reranking insère une étape :

• retrieve (rapide) → rerank (plus précis) → generate

Pourquoi ça marche ? Parce qu’on accepte un principe simple :

On ne peut pas être à la fois ultra‑rapide, ultra‑cheap, et ultra‑précis sur tout le corpus.

Donc on fait un entonnoir : large et rapide d’abord, fin et précis ensuite.

Le vrai job d’un reranker : sauver votre top‑k (pas votre ego)

On voit souvent des équipes passer des semaines à :

• changer de modèle d’embedding,
• retuner un index ANN,
• augmenter k (“si on prend 40 passages, on finira bien par tomber sur le bon…”),

…alors que le problème est plus simple :

Les bons passages sont dans les candidats, mais pas au bon rang.

Le reranker fait exactement ça : il prend une requête + une liste de candidats et il les remet dans l’ordre.

Et ça change tout :

• votre contexte devient plus court (donc moins cher),
• votre réponse devient plus stable,
• vos métriques end‑to‑end montent sans “magie”.

Deux minutes de théorie (juste pour comprendre le gain)

Bi-encoder (embeddings) : rapide, mais “indirect”

Un bi‑encoder encode la requête et le document séparément (embeddings).
On compare ensuite des vecteurs. C’est efficace, scalable… et parfois approximatif.

Cross-encoder (reranker) : plus lent, mais plus “lucide”

Un cross‑encoder lit la requête et le passage ensemble. Il peut donc capter des interactions fines :

• négations,
• contraintes (“uniquement si…”, “sauf…”),
• correspondances précises (nom de produit, condition contractuelle),
• subtilités de formulation.

C’est aussi pour ça qu’il coûte plus cher : il fait plus de calcul.

La doc Sentence‑Transformers résume bien ce pattern et son usage en pratique.¹

Les 3 familles de reranking en 2026 (avec leurs compromis)

1) Cross-encoder : la précision “sans pitié”

Ce sont les rerankers les plus simples à comprendre :

• input : (query, passage)
• output : score de pertinence

Avantages :

• excellente précision,
• facile à intégrer (on score, on trie),
• très bon ROI quand vos passages se ressemblent.

Inconvénients :

• latence et coût (surtout si vous rerankez trop de candidats),
• throughput limité si vous n’optimisez pas (batching, cache).

Outils :

• open source : cross‑encoders Sentence‑Transformers,¹
• open weights : BGE reranker v2‑m3 (multilingue) est une option courante,²
• API : Cohere Rerank, Voyage reranker.³⁴

2) ColBERT : “late interaction”, un compromis élégant

ColBERT propose une idée intermédiaire : au lieu de compresser tout un passage en un seul vecteur, on garde des représentations token‑level et on calcule une similarité via une interaction tardive (late interaction).⁵

Traduction :

• plus précis qu’un bi‑encoder “pur”,
• souvent plus scalable qu’un cross‑encoder sur de très grands volumes,
• très intéressant quand vous devez reranker beaucoup de candidats.

Mais :

• c’est plus complexe à opérer,
• ce n’est pas “juste un modèle”, c’est un système de retrieval (indexation, scoring).

3) LLM reranker : flexible… donc à cadrer

Un LLM reranker prend la requête et une liste de passages, puis ordonne (ou choisit) les meilleurs.

Approches :

• scoring passage par passage,
• pairwise (A vs B),
• listwise (ordonner une liste).

RankLLM formalise des approches listwise basées sur des LLMs.⁶

Avantages :

• très flexible (vous pouvez intégrer des critères : récence, source, type de doc),
• utile pour des corpus hétérogènes où les signaux sont multiples.

Inconvénients :

• latence et coût (beaucoup plus variables),
• risque de “raisonnement” instable si vous ne verrouillez pas le format,
• observabilité plus délicate (pourquoi ce passage ?).

Le pattern prod qui évite les extrêmes

Le meilleur compromis, très souvent :

1. retrieval hybride (BM25 + vecteurs) pour obtenir 50–200 candidats
2. reranking cross‑encoder (ou API) sur ces candidats
3. top‑k final (5–20 passages) injecté au LLM

Pourquoi 50–200 ?

• en dessous : vous ratez parfois les “bons” candidats,
• au‑dessus : vous payez cher pour reranker du bruit.

Ce n’est pas une loi physique, c’est un bon point de départ.
L’important : itérer avec des métriques (retrieval + end‑to‑end).

Si vous n’avez pas encore votre retrieval hybride, commencez ici : Recherche hybride (BM25 + vecteurs).

Open source vs API : comment décider sans religion

Quand l’open source est un excellent choix

Vous avez intérêt à self‑host un reranker si :

• vous avez des contraintes de données (on‑prem, confidentialité),
• vous voulez maîtriser les coûts,
• vous avez de la charge (batching, GPU) et une équipe capable d’opérer.

Exemples :

• cross‑encoders Sentence‑Transformers,¹
• BGE reranker v2‑m3 pour du multilingue/usage général.²

Quand l’API est le meilleur move

Vous avez intérêt à utiliser un reranker API si :

• vous voulez avancer vite (time‑to‑value),
• vous avez une charge modérée,
• vous voulez un SLA et une intégration “clean”.

Exemples :

• Cohere Rerank (modèles “fast” et “pro”),³
• Voyage reranker (modèles rerank‑2 / rerank‑2.5).⁴

La table qui vous fait gagner une réunion (comparatif simple)

Les pièges classiques (et comment les éviter)

Piège 1 — Reranker sur des chunks “mal découpés”

Un reranker n’est pas un chirurgien. Si vos passages sont :

• trop longs,
• mal structurés,
• remplis de bruit (headers, footers, OCR sale),

…il peut scorer “correctement” des candidats… qui restent inutilisables pour le LLM.

Le reranking n’est pas une excuse pour ignorer le chunking.
Guide : Chunking RAG.

Piège 2 — Reranker sans filtres (ACL, tenant, produit)

Si vous rerankez des candidats que l’utilisateur n’a pas le droit de voir, vous créez :

• des fuites potentielles,
• des réponses instables (“je sais que ça existe… mais je ne peux pas te le montrer”),
• des coûts inutiles.

Appliquez les filtres au retrieval/candidate generation, ou au pire avant rerank, mais pas après génération.

Guide : ACL & métadonnées en RAG.

Piège 3 — Reranker trop gourmand (et p95 qui explose)

Le reranking est une couche “multiplicative” :

• plus de candidats → plus de coût,
• plus de tokens par passage → plus de coût,
• plus de requêtes → plus de coût.

Solutions :

• réduire les candidats (hybride + RRF),
• batcher,
• cacher (cache sur requêtes fréquentes, ou cache sur pairs query‑passage),
• monitorer p95.

Guide : Latence & caching.

Méthode : ajouter un reranker en 2 heures (et le rendre prod en 2 semaines)

1

Choisissez un budget de latence (p95) et un top‑k cible

Exemple : “le retrieval + rerank doit tenir en 250ms p95” et “je veux 8 passages max”. Sans contrainte, on reranke tout… puis on se plaint du coût.

2

Fixez un protocole d’évaluation (retrieval + end‑to‑end)

Mesurez sur un set de requêtes réel. Le reranker doit améliorer la pertinence du top‑k, puis la groundedness des réponses. Guide : Évaluation chatbot IA.

3

Commencez par une API ou un cross‑encoder simple

Le but est d’obtenir un gain visible vite. Ensuite, vous optimisez (batching, quantization, etc.) si la charge le justifie.

4

Rerankez 50–200 candidats (pas 2000)

Si vous avez besoin de reranker 2000 candidats, votre retrieval est trop bruité. Réparez le retrieval (hybride, filtres, query handling) avant de payer un reranker XXL.

5

Industrialisez : cache, batching, logs

C’est là que le reranking devient “gratuit” à l’usage : vous amortissez le coût sur les requêtes récurrentes et vous gardez la latence stable.

FAQ — Reranking RAG

Questions frequentes

Reranking vs embeddings : c’est redondant ?+

Non. Les embeddings servent à retrouver vite des candidats (approx). Le reranking sert à trier finement ces candidats (précis). Ils sont complémentaires.

Cross-encoder ou ColBERT ?+

Cross‑encoder si vous voulez la précision “plug‑and‑play” sur un nombre de candidats raisonnable. ColBERT si vous avez un gros volume et un besoin de précision sans exploser le coût, au prix d’une complexité ops plus élevée.⁵

LLM reranker : bonne idée ?+

Oui si vous avez des critères multiples et un corpus hétérogène, et si vous pouvez cadrer la latence/coût. RankLLM décrit des approches utiles, mais en prod il faut verrouiller format, budget et observabilité.⁶

Cohere / Voyage : ça vaut quoi ?+

Ce sont des rerankers API conçus pour ce job : bonne qualité, intégration simple, pay-as-you-go. À challenger sur vos données et vos langues.³⁴

Je reranke des chunks PDF : ça marche ?+

Oui, mais seulement si l’extraction/structure est propre. Sinon le reranker score du bruit. Voir : /blog/chatbot/technique/visual-rag-pdf-documents-longs-ocr-layout-vlm et /blog/chatbot/technique/chunking-rag-decouper-documents-strategie.

Le reranking peut-il réduire les hallucinations ?+

Indirectement, oui : il augmente la qualité du contexte injecté au LLM, donc la groundedness. Mais ce n’est pas un garde‑fou : vous devez aussi gérer prompt injection, filtres, refus, etc.

Sources et references

1. [1]Sentence‑Transformers, “Cross-Encoder” (documentation).
2. [2]Hugging Face, “BAAI/bge-reranker-v2-m3”.
3. [3]Cohere, “Rerank” (documentation).
4. [4]Voyage AI, “Reranker” (documentation).
5. [5]Khattab & Zaharia, “ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT” (SIGIR 2020).
6. [6]Pradeep et al., “RankLLM: Scaling LLMs for Ranking” (arXiv).