Ajouter un reranker à son pipeline

#Reranker : à quoi il sert dans un pipeline RAG

Un reranker prend la question et un passage, les lit ensemble et renvoie un score de pertinence ; on trie ensuite les candidats par score décroissant et on ne transmet au modèle de langage que les meilleurs. Dans un pipeline RAG local, on l'insère entre la base vectorielle (ChromaDB, Qdrant, Weaviate) et le LLM : la recherche vectorielle rapatrie par exemple 30 passages, le reranker en retient 5. La fiche officielle de BAAI le décrit ainsi : contrairement à un modèle d'embedding, le reranker reçoit la question et le document en entrée et produit directement une similarité, au lieu d'un vecteur. Le gain est le plus net quand la bonne réponse se trouve dans les candidats mais pas en tête : des passages qui parlent du bon sujet général sans répondre à la question précise occupent les premières places, et le modèle génère alors une réponse à côté ou inventée. Si la bonne réponse n'est pas dans les candidats, un reranker ne peut rien : il ne cherche pas, il trie.

Un embedding produit un vecteur pour chaque document, indépendamment de la question posée, et la distance mesure une proximité globale de sujet. Deux passages sur le même thème peuvent donc obtenir des scores voisins alors qu'un seul contient la réponse. Le cross-encoder regarde le couple en entier : il voit si la date, le nom ou la condition demandés figurent dans le passage. C'est plus précis sur ce jugement local, et plus coûteux, parce qu'il faut un passage dans le transformer par couple au lieu d'un seul calcul par document.

#Bi-encoder et cross-encoder : pourquoi on combine les deux

Bi-encoder (embedding)

Encode la question et chaque document séparément ; les vecteurs des documents sont calculés une fois à l'indexation, la recherche se réduit à une comparaison de vecteurs. Rapide, adapté à des millions de passages.

Cross-encoder (reranker)

Encode la question et le passage ensemble et sort un score. Aucun calcul n'est réutilisable : il faut le refaire pour chaque question et chaque candidat. Précis, mais impossible à appliquer à tout le corpus.

La documentation de Sentence Transformers énonce le raisonnement : évaluer des milliers ou des millions de couples serait plutôt lent, on utilise donc le retriever pour produire un ensemble de candidats, par exemple une centaine, que le cross-encoder réordonne. Le schéma en deux étages est le même que celui des moteurs de recherche classiques. Il explique aussi le réglage principal : le nombre de candidats récupérés pilote à la fois le rappel (plus on prend large, plus on a de chances de contenir la bonne réponse) et la latence (chaque candidat supplémentaire coûte un passage dans le cross-encoder).

#Quel modèle de reranking choisir en français

Le choix se joue sur trois critères : la langue, la licence et la mémoire. Les chiffres de taille ci-dessous viennent des fiches Hugging Face ; notez que la taille du fichier dépend de la précision des poids, F32 pour bge-reranker-v2-m3 (environ 4 octets par paramètre), F16 pour mxbai.

La fiche de bge-reranker-v2-m3 le présente comme un reranker léger, doté de fortes capacités multilingues, facile à déployer et rapide en inférence ; la fiche de bge-reranker-v2-gemma le destine aux contextes multilingues, avec de bons résultats en anglais comme en multilingue. Deux corrections utiles par rapport à ce qu'on lit souvent : le fichier de bge-reranker-v2-m3 pèse plus de 2 Go, pas 560 Mo (568 millions de paramètres en F32), et mxbai-rerank-large-v1 est un modèle anglophone, à ne pas retenir pour des documents en français. Une fois chargé en demi-précision, le modèle m3 occupe environ 1,1 Go pour les poids (568 millions de paramètres × 2 octets, calcul de ce guide), auxquels s'ajoutent les activations du lot traité.

#La pipeline avant et après reranker

AVANT :
  Question → Embedding → Base vectorielle (top-5) → LLM

APRÈS :
  Question → Embedding → Base vectorielle (top-20 à top-50)
                       → Reranker (top-5) → LLM

On récupère large, puis on ordonne finement.

Deux paramètres gouvernent l'ensemble : k_retrieve, le nombre de candidats que la base vectorielle renvoie, et k_final, le nombre de passages transmis au LLM. Un k_final de 3 à 5 convient à la plupart des modèles locaux de 7 à 14 milliards de paramètres ; au-delà, on remplit la fenêtre de contexte sans gain net, et le temps de traitement du prompt augmente. Le k_retrieve dépend de la difficulté du corpus : 20 est un bon premier essai, 50 à 100 si les questions sont vagues ou si le corpus contient beaucoup de passages voisins. Le guide sur la fenêtre de contexte détaille ce que coûtent des passages supplémentaires dans le prompt.

#Implémentation : sentence-transformers, FlagEmbedding, llama.cpp

#Avec sentence-transformers

La classe CrossEncoder charge le modèle et évalue des couples. Sa méthode rank accepte directement la question et la liste des documents et renvoie les meilleurs ; le paramètre top_k limite le nombre de résultats (sans lui, tous les documents sont renvoyés).

from sentence_transformers import CrossEncoder

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

def retrieve_and_rerank(question, k_retrieve=20, k_final=5):
    # 1. Récupération par embedding (ChromaDB, Qdrant, etc.)
    candidats = embedding_search(question, top_k=k_retrieve)  # liste de textes

    # 2. Scoring par le cross-encoder, tri et coupe en une seule étape
    resultats = reranker.rank(question, candidats, top_k=k_final, batch_size=16)
    # resultats = [{'corpus_id': 3, 'score': 0.91}, ...]
    return [candidats[r['corpus_id']] for r in resultats]

#Avec FlagEmbedding, la bibliothèque des auteurs du modèle

La fiche du modèle utilise la bibliothèque FlagEmbedding. Elle précise que le score brut peut être ramené entre 0 et 1 par une fonction sigmoïde avec normalize=True, et que use_fp16=True accélère le calcul au prix d'une légère baisse de qualité. Retenez que le score brut est une valeur sans échelle absolue, souvent négative pour les passages hors sujet ; seul l'ordre compte, sauf si vous fixez un seuil.

from FlagEmbedding import FlagReranker

reranker = FlagReranker('BAAI/bge-reranker-v2-m3', use_fp16=True)
score = reranker.compute_score(['ma question', 'un passage'], normalize=True)  # entre 0 et 1

#Avec llama.cpp, sans Python

Le serveur llama.cpp propose un point d'accès de reranking, désactivé par défaut. La documentation indique qu'il exige un modèle de reranking, cite bge-reranker-v2-m3 en exemple, et se lance avec les options --embedding et --pooling rank. Il faut une version GGUF du modèle. C'est l'option à retenir si votre pile est déjà construite autour de llama.cpp et que vous voulez éviter d'installer PyTorch. Vérifiez l'option exacte dans la version installée : la documentation prévient que ce point d'accès pourrait évoluer.

llama-server -m bge-reranker-v2-m3-Q8_0.gguf --embedding --pooling rank --reranking --port 8081

#Avec LlamaIndex

from llama_index.core.postprocessor import SentenceTransformerRerank

reranker = SentenceTransformerRerank(model="BAAI/bge-reranker-v2-m3", top_n=5)

query_engine = index.as_query_engine(
    similarity_top_k=20,
    node_postprocessors=[reranker],
)

#Coût : latence, mémoire, longueur des passages

Aucun chiffre de latence n'est garanti : elle dépend de la carte, de la précision (FP16 ou FP32), du nombre de candidats et de la longueur des passages. Retenez les proportions. Le temps de reranking croît linéairement avec le nombre de couples : passer de 20 à 100 candidats multiplie le travail par cinq. Il croît aussi avec la longueur du passage, puisque chaque couple est encodé en entier. Mesurez sur votre machine avec vos passages plutôt que de vous fier à un chiffre de blog : chronométrez cent requêtes réelles, et regardez le temps médian et le pire cas.

Nombre de candidats

Premier levier. Commencez à 20, mesurez le rappel, montez à 50 seulement si des bonnes réponses restent hors du lot.

Précision

use_fp16=True (FlagEmbedding) ou un chargement en demi-précision réduit la mémoire et accélère le calcul, avec, selon la fiche du modèle, une légère baisse de performance.

Taille de lot

La méthode rank de sentence-transformers traite 32 couples par lot par défaut. Baissez à 8 ou 16 si la mémoire manque, montez si le GPU est sous-utilisé.

Longueur maximale

512 tokens par couple (valeur max_length des exemples officiels). Un passage plus long est tronqué : si vos chunks dépassent cette taille, la fin du passage n'est pas lue. Raccourcissez les chunks avant d'augmenter la limite.

CPU ou GPU

Sur CPU, le reranker fonctionne, mais chaque requête de 20 à 50 candidats se paie en secondes ; c'est acceptable pour un assistant documentaire interne, moins pour un chat interactif.

#Reranker et découpage : les deux réglages interagissent

Un cross-encoder juge un passage entier. Si le passage mélange trois sujets, son score sera moyen pour les trois questions correspondantes ; s'il est trop court, il perd le contexte qui permettrait de le reconnaître comme réponse. Le découpage en passages de taille moyenne, avec un léger recouvrement, donne au reranker de la matière sans dépasser sa longueur maximale. Si vous changez la taille des chunks, refaites le test de rappel : le meilleur k_retrieve et le gain du reranker changent avec lui. Le guide sur les stratégies de chunking détaille ces choix.

Autre interaction : la recherche hybride. Lorsque la recherche par mots-clés (BM25) et la recherche vectorielle sont fusionnées, le lot de candidats est plus varié, ce qui laisse au reranker plus de chances de retrouver une bonne réponse que chaque méthode seule aurait ratée. Le reranker est le dernier étage, l'hybride le second : ils se complètent plutôt qu'ils ne se remplacent.

#Mesurer le gain sur vos documents

Le gain annoncé dans les blogs varie du simple au quintuple selon le corpus, et aucune valeur générale ne vaut pour le vôtre. Sur un corpus très structuré (documentation technique propre), le vectoriel seul est déjà bon ; sur un corpus bruité (courriels, notes, PDF mal extraits), l'écart est plus marqué. Le seul moyen de le savoir est d'évaluer.

1. 01
   Constituer 30 à 50 questions

   Prenez de vraies questions d'utilisateurs, avec pour chacune le passage qui contient la réponse (un identifiant suffit).
2. 02
   Mesurer le rappel à 5 sans reranker

   Pour chaque question, regardez si le bon passage figure dans les 5 premiers résultats de la base vectorielle.
3. 03
   Mesurer le rappel à 5 avec reranker

   Récupérez 20 candidats, reclassez-les, et comptez de nouveau les bons passages dans les 5 premiers.
4. 04
   Comparer aussi la latence

   Notez le temps médian de bout en bout. Un gain de quelques points de rappel ne justifie pas forcément une seconde d'attente supplémentaire.
5. 05
   Regarder les échecs

   Pour chaque question ratée, vérifiez si la bonne réponse était dans les 20 candidats. Si non, le problème est en amont : découpage, embeddings ou extraction du texte.

def rappel_a_k(pipeline, questions, cibles, k=5):
    ok = 0
    for q, cible in zip(questions, cibles):
        ok += cible in [p.id for p in pipeline(q)[:k]]
    return ok / len(questions)

sans = rappel_a_k(pipeline_sans_reranker, questions, cibles)
avec = rappel_a_k(pipeline_avec_reranker, questions, cibles)
print(f"Sans : {sans:.0%}   Avec : {avec:.0%}")

#Faut-il un reranker ? Repères de décision

#Questions fréquentes sur le reranking

• Recherche hybride : BM25 + vectoriel
• Stratégies de chunking
• Les meilleurs modèles d'embeddings FR
• Comprendre la fenêtre de contexte
• RAG en local avec ChromaDB et Ollama

• Source : fiche Hugging Face de BAAI/bge-reranker-v2-m3
• Source : fiche de BAAI/bge-reranker-v2-gemma
• Source : Sentence Transformers, Retrieve & Re-Rank
• Source : documentation du serveur llama.cpp