Reranking en RAG : cross-encoder vs. bi-encoder

Le reranking est la deuxième étape de récupération dans un pipeline RAG : un cross-encoder réévalue les meilleurs candidats trouvés par le bi-encoder rapide et les classe selon leur pertinence réelle pour la requête. Selon Anthropic, le reranking réduit nettement le taux d'erreur de récupération par rapport à une récupération purement vectorielle, au prix d'une latence plus élevée. Le reranking n'a donc rien d'un bonus facultatif : dans les systèmes en production, c'est le levier le plus fiable entre « sémantiquement proche » et « réellement pertinent ».

• Ce qu'il fait : le reranking réordonne les candidats trouvés par la première récupération avant qu'ils n'arrivent dans le prompt du LLM.
• Pourquoi deux étapes : le bi-encoder rapide assure le rappel sur des millions de chunks, le cross-encoder précis assure la précision sur le top-k final.
• Effet concret : Anthropic fait état d'une réduction allant jusqu'à 67 % du taux d'erreur de récupération top-20 lorsque Contextual Retrieval est combiné au reranking.

Pourquoi une récupération en une seule étape ne suffit pas

La récupération vectorielle classique repose sur un bi-encoder. Celui-ci encode à l'avance chaque chunk de document dans un vecteur et le stocke dans un index ANN (le plus souvent HNSW). Au moment de la requête, celle-ci est projetée dans le même espace vectoriel, et la similarité est calculée via la distance cosinus. C'est extrêmement rapide et cela passe à l'échelle sur des millions d'entrées, mais c'est une approximation. La requête et le document ne se « voient » jamais ensemble ; le modèle compare seulement deux condensés produits indépendamment.

Il en résulte un anti-pattern typique : les résultats top-k sont sémantiquement proches, mais pas forcément pertinents pour la question posée. C'est précisément là qu'intervient le reranking. Il s'agit d'une étape post-récupération qui applique un mécanisme plus précis, mais plus lent, à un petit ensemble de candidats plutôt qu'à l'ensemble du corpus.

Bi-encoder vs. cross-encoder : la différence fondamentale

Le cœur architectural du reranking, c'est le passage du bi-encoder au cross-encoder.

Un bi-encoder traite la requête et le document séparément. Chacun est encodé dans un vecteur, et la pertinence ne découle qu'ensuite de la distance entre ces vecteurs. Comme les embeddings des documents peuvent être calculés et indexés à l'avance, le bi-encoder est le seul choix praticable pour la récupération initiale sur de grands corpus.

Un cross-encoder traite la requête et le document ensemble, en un seul forward pass. Le modèle voit les deux textes simultanément et peut tenir compte des interactions mot à mot, des négations et des nuances de sens. Le résultat est une évaluation de pertinence nettement plus précise, mais le calcul doit être fait pour chaque paire requête-document. Sur des millions de chunks, ce serait d'un coût prohibitif ; sur 50 à 100 candidats préfiltrés, c'est acceptable.

Entre les deux se trouve l'approche late interaction (ColBERT) : elle stocke des embeddings au niveau des tokens pour chaque document et calcule la pertinence via une opération MaxSim entre les tokens de la requête et ceux du document. Elle offre plus de précision qu'un bi-encoder classique et passe mieux à l'échelle qu'un cross-encoder complet, mais consomme nettement plus de mémoire pour les vecteurs de tokens.

Position dans le pipeline et stratégie top-k

Le reranking est une étape bien définie du chemin de requête. L'agencement canonique est le suivant :

```
[Récupération hybride, top_k = 50-100]
-> [Cross-Encoder Reranker (Cohere Rerank / BGE / Jina)]
-> [top_k = 5-10]
-> [Prompt + citation des sources]
-> [LLM]
```

Le point décisif : le reranker n'intervient qu'après le rappel peu coûteux du bi-encoder. La récupération hybride initiale (recherche dense plus BM25, fusionnées par Reciprocal Rank Fusion) fournit délibérément un pool généreux de 50 à 100 candidats afin de maximiser le rappel. Le cross-encoder réduit ensuite ce pool aux 5 à 10 chunks vraiment pertinents qui entrent dans le prompt.

Ce resserrement n'est pas qu'une question de coûts. Un top-k trop large transmis au LLM provoque l'effet « Lost-in-the-Middle » : les informations pertinentes situées au milieu d'un long contexte sont moins bien traitées, et les coûts en tokens augmentent. Le reranking associé à un top-k serré de 5 à 10 est la parade standard, avec une consigne supplémentaire : placer les chunks les plus importants en tête du prompt.

Panorama des modèles de reranking (octobre 2026)

Pour les scénarios européens avec des exigences de souveraineté, le BGE-Reranker v2-m3 est l'option on-premise la plus évidente : il est sous Apache 2.0, multilingue et peut tourner à des fins commerciales dans ton propre centre de données ou dans une région de l'UE. L'ancien modèle bge-reranker-large (licence MIT) ne couvre que le chinois et l'anglais, selon sa fiche de modèle. Les Jina Reranker v2, v3 et v3.5 (publié le 27.07.2026) ont certes des poids ouverts, mais sont sous CC BY-NC 4.0. Pour un usage commercial on-premise, il te faut une licence de Jina AI ; sinon, il te reste l'API Jina, Elastic Inference Service ou les offres sur AWS, Azure et Google Cloud. Jina AI est basée à Berlin, mais appartient à Elastic depuis octobre 2025.

Si tu acceptes une API et que tu as besoin d'une qualité multilingue, allemand compris, tu choisiras en pratique Cohere Rerank. L'alternative Voyage appartient à MongoDB depuis février 2025 ; ses modèles actuels sont rerank-3 et rerank-3-lite. Selon le billet de lancement du 30.09.2026, Voyage a testé rerank-3 sur 95 jeux de données issus de 9 domaines, dont 51 multilingues couvrant 31 langues. L'approche LLM-as-Judge (par exemple le LLMRanker de Haystack) est la plus flexible, mais la plus chère par requête, et ne devrait être utilisée que là où la qualité du reranking est critique et le budget de latence confortable.

Compromis latence/qualité

Le reranking est l'étape la plus coûteuse de la partie récupération du chemin en ligne (avant la génération par le LLM), car le cross-encoder effectue un calcul par candidat. Dans les systèmes en production, la latence totale de la récupération hybride et du reranking se situe généralement autour de 100 à 800 millisecondes. Cette fourchette se pilote directement :

• Taille du pool d'entrée : reranker 100 candidats coûte plus cher que 30. Selon le corpus, un pool plus petit suffit souvent.
• Choix du modèle : les rerankers en API comme Cohere sont optimisés pour le débit ; un LLM-as-Judge est nettement plus lent.
• Matériel : les rerankers auto-hébergés profitent fortement de l'inférence GPU ; sur CPU, la latence augmente considérablement.

Le compromis n'est donc pas « reranking ou pas », mais « combien de candidats pour quel budget de latence ». Pour la plupart des cas d'usage en entreprise, le gain de précision vaut la latence supplémentaire.

Exemple chiffré : gain de précision

Dans la publication « Introducing Contextual Retrieval » (19.09.2024), Anthropic a mesuré des chiffres concrets sur ses propres benchmarks (code, fiction, articles ArXiv, science) ; Cohere servait de reranker. C'est à lire comme l'évaluation d'un fournisseur, donc intéressée, mais documentée sur le plan méthodologique :

• Base (récupération seule) : taux d'erreur de récupération top-20 de 5,7 %.
• Contextual Embeddings seuls : réduction de 35 %, à 3,7 %.
• Contextual Retrieval (embeddings plus BM25) : réduction de 49 %, à 2,9 %.
• Contextual Retrieval plus reranking : réduction de 67 %, à 1,9 %.

Concrètement : sur 1 000 documents pertinents, 57 manquent au départ dans le top-20, contre seulement 19 avec le pipeline complet. Le reranking seul, soit le passage de 2,9 à 1,9 %, élimine dans cette configuration environ un tiers supplémentaire des erreurs restantes. Pour un système RAG en production, chaque erreur de récupération évitée, c'est un chunk de moins qui pousse le LLM vers une réponse fausse ou non étayée. C'est précisément pour cela que la pratique RAG classe « pas de reranking » parmi les anti-patterns évidents : les top-k sont alors sémantiquement proches, mais pas pertinents.

Pour les agences et les décideurs B2B

Si tu mets en place un système RAG en production en Europe, prévois le reranking dès le départ comme une étape fixe du pipeline, pas comme un réglage après coup. Le levier est important, l'effort d'implémentation limité : un appel API supplémentaire (Cohere) ou un reranker auto-hébergé sous licence ouverte comme BGE v2-m3, entre la récupération et le LLM. Pour les agences qui construisent des assistants de connaissances ou des moteurs de recherche internes pour leurs clients, le reranking offre le meilleur rapport entre gain de qualité et effort, et un argument mesurable en pitch, car le gain de précision se démontre dans des frameworks d'évaluation comme RAGAS (Context Precision). Blck Alpaca conçoit ce type d'architectures de récupération en deux étapes, avec un choix de modèles conforme aux exigences de l'UE et une budgétisation de la latence. Fais vérifier si, dans ton pipeline RAG actuel, les bons chunks arrivent vraiment en tête.