Rerankers open source : la brique souvent oubliée pour doubler la précision de son RAG

Rerankers open source : la brique souvent oubliée pour doubler la précision de son RAG

La plupart des pipelines RAG auto-hébergés se contentent d’un seul étage de recherche : une base vectorielle renvoie les k passages les plus proches de la requête et on les injecte tels quels dans le prompt. Cette approche fonctionne, mais elle laisse beaucoup de qualité de côté. Le reranker est la deuxième étape qui relit, rescore et réordonne les candidats avant de les transmettre au LLM. Dans la plupart des cas, c’est l’amélioration qui a le meilleur rapport effort / gain mesurable.

Pourquoi les embeddings seuls ne suffisent pas

Un embedding (bi-encoder) compresse un texte en un unique vecteur. Pour que la recherche soit scalable, requête et document sont encodés indépendamment, puis comparés par similarité cosinus. C’est extrêmement rapide, mais cela force le modèle à deviner à l’avance quelles dimensions sémantiques seront utiles pour n’importe quelle question. Résultat courant : des passages thématiquement proches remontent en tête alors qu’ils ne répondent pas vraiment à la question posée.

Un reranker (cross-encoder) prend en même temps la requête et un passage candidat, les concatène, et produit un score de pertinence directement conditionné à la paire. Il voit les deux textes ensemble, ce qui permet de capturer des signaux qu’un bi-encoder ne peut pas modéliser : négations, conditions, co-occurrences précises, nuances de reformulation.

L’architecture à deux étages

Le pattern qui s’impose en production est simple :

1. Retrieval large : la base vectorielle (pgvector, Qdrant, etc.) renvoie 50 à 200 candidats avec un embedding rapide.
2. Reranking : un cross-encoder rescore ces candidats un à un et on ne garde que les 3 à 10 meilleurs.
3. Génération : ces passages de haute précision sont injectés dans le prompt du LLM.

On combine ainsi le meilleur des deux mondes : le rappel du retrieval dense et la précision du cross-encoder, avec un coût maîtrisé puisque le reranker ne voit qu’une centaine de documents, pas toute la base.

Les modèles open source à retenir

• BGE-reranker-v2-m3 (BAAI) : multilingue, licence MIT, excellent rapport qualité/taille. Le choix par défaut pour le français.
• Jina Reranker v2 : multilingue également, très rapide, bon sur les contextes longs et les paires de code.
• Mixedbread mxbai-rerank-large-v1 : solide sur l’anglais, performances proches des modèles commerciaux fermés.
• ColBERT / ColPali : approche dite late interaction, un compromis entre bi-encoder et cross-encoder, intéressant quand on veut reranker des milliers de candidats.

Ces modèles s’exécutent très bien sur une seule carte graphique grand public, voire en CPU pour les plus petits. Ils peuvent aussi être servis via un endpoint dédié (Text Embeddings Inference de Hugging Face, ou sentence-transformers derrière une API FastAPI).

Intégration minimale

Côté Python, quelques lignes suffisent pour ajouter un reranker à un pipeline existant :

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")

# candidates = liste de passages renvoyés par la base vectorielle
pairs = [(query, passage) for passage in candidates]
scores = reranker.predict(pairs)

top = [p for _, p in sorted(zip(scores, candidates), reverse=True)][:5]

Dans une architecture de service, on préférera isoler le reranker derrière sa propre API, il consomme plus de GPU que l’encoder d’embedding, et l’isoler permet d’appliquer une politique de cache et de batch distincte.

Ce qu’on gagne, ce qu’on paie

Sur des benchmarks publics comme BEIR ou MTEB, ajouter un reranker au-dessus d’un retrieval dense fait généralement gagner 5 à 15 points de NDCG@10 ; un saut de qualité équivalent à changer de modèle d’embedding pour un modèle bien plus gros. En pratique, sur un corpus métier, la perception utilisateur est encore plus nette : les réponses hallucinées diminuent parce que le LLM reçoit enfin les bons extraits.

Le coût : une latence supplémentaire de 50 à 300 ms pour 100 candidats selon le modèle et le matériel. Pour une application conversationnelle, c’est négligeable. Pour une recherche plein-texte à très haut QPS, il faudra réduire le nombre de candidats rerankés ou mettre en cache les paires requête/document fréquentes.

Quand le reranker n’apporte rien

Trois cas où l’ajout d’un cross-encoder est inutile ou contre-productif : quand la base est trop petite (moins de quelques centaines de documents, le retrieval dense suffit souvent), quand les requêtes sont déjà très proches du vocabulaire des documents (un bon BM25 couplé à un embedding standard peut suffire), et quand les documents sont si courts que la distinction bi-encoder / cross-encoder se dilue. Dans tous les autres cas, tester un reranker est probablement le meilleur investissement en temps pour améliorer un RAG en production.

À retenir

Le reranker n’est pas un luxe : c’est un étage d’architecture à part entière qui sépare le rappel (où l’on cherche large et vite) de la précision (où l’on valide finement). Dans une stack IA auto-hébergée, c’est probablement la brique la plus simple à ajouter pour un gain de qualité tangible, et elle s’intègre avec tout ce qu’on déploie déjà : pgvector, Qdrant, LangGraph, Dify ou un service maison.