Rerank et fusion de signaux

Pourquoi le rerank change la donne

Un pipeline RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire minimal fonctionne selon un schéma simple : la requête est encodée en vecteur, on récupère les k passages les plus proches dans un index vectorielbase vectorielleIABase spécialisée qui indexe des embeddings pour retrouver rapidement les passages les plus proches d'une requête (cœur du RAG).Voir dans le glossaire, puis on les injecte tels quels dans le promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire du modèle de génération. Ce schéma produit des résultats corrects tant que le corpus est petit et homogène. Il s'effondre progressivement à mesure que le corpus grossit, se diversifie, ou que les requêtes deviennent ambiguës — parce qu'il repose entièrement sur la qualité d'un retrieval initial dont la précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire a un plafond structurel.

Ce plafond vient du bi-encoder utilisé pour l'indexation vectorielle : il doit résumer un document entier et une requête, indépendamment l'un de l'autre, en un seul vecteur de dimension fixe. Cette compression perd nécessairement de l'information fine. Deux passages peuvent se retrouver proches dans l'espace vectoriel sans être réellement pertinents pour la requête posée, et à l'inverse, un passage très pertinent peut se classer en position 40 simplement parce que sa formulation lexicale s'éloigne du vecteur de la requête. Le rerank existe pour corriger cette approximation avant que les documents n'atteignent le modèle de génération.

Le rerank n'améliore pas le rappel (recallrappelIAProportion des cas positifs réels effectivement détectés par un modèle. Sur un jeu déséquilibré, c'est un indicateur bien plus parlant que l'exactitude globale.Voir dans le glossaire) : il ne peut pas faire remonter un document absent du jeu retourné par le retrieval initial. Il améliore la précision du classement à l'intérieur de ce jeu, en réordonnant les k candidats selon un score de pertinence plus fin. Un retrieval initial médiocre — mauvais chunkingChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire, embeddingsembeddingIAReprésentation numérique dense d'un texte, d'une image ou d'un objet dans un espace vectoriel, utilisée pour la similarité et la recherche sémantique.Voir dans le glossaire mal choisis, index incomplet — ne sera jamais rattrapé par un excellent reranker en aval.

Bi-encoders et cross-encoders : deux architectures, deux usages

Le terme « embedding de recherche » recouvre en réalité deux familles de modèles aux propriétés très différentes.

Le bi-encoder encode la requête et chaque document séparément, dans deux passes indépendantes. Le score de pertinence est ensuite calculé a posteriori par un produit scalaire ou une similarité cosinus entre les deux vecteurs. Cette séparation est ce qui rend l'indexation possible : les vecteurs des documents sont calculés une fois, stockés dans un index (HNSW, IVF, etc.), et la requête n'a plus qu'à être comparée à cet index déjà construit. C'est rapide — quelques millisecondes pour interroger des millions de vecteurs — mais l'absence d'interaction entre requête et document au moment de l'encodage limite la finesse du score.

Le cross-encoderCross-encoderIAModèle qui encode conjointement une requête et un document pour produire un score de pertinence, plus précis qu'un bi-encodeur mais plus coûteux à l'inférence.Voir dans le glossaire, à l'inverse, concatène la requête et le passage candidat en une seule séquence d'entrée et laisse les mécanismes d'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire du transformeur calculer une interaction complète, terme à terme, entre les deux textes. Le score produit est un score de pertinence directe — pas une distance géométrique entre deux points figés à l'avance. Cette interaction fine coûte cher : il faut une passe complète du modèle par paire (requête, document), ce qui interdit toute indexation préalable. On ne peut appliquer un cross-encoder qu'à un nombre restreint de candidats, généralement entre 20 et 300.

Cette complémentarité — large et rapide d'un côté, étroit et précis de l'autre — est le principe fondateur de toute architecture de retrieval augmenté en production.

Fusion de signaux : au-delà du score unique

En production, on dispose rarement d'un seul signal de pertinence. On combine le plus souvent :

• un score de recherche lexicale (BM25 ou équivalent), robuste sur les termes rares, les codes produits, les identifiants ;
• un score de similarité dense (bi-encoder), robuste sur le sens et les reformulations ;
• un score de rerank (cross-encoder), le plus précis mais appliqué à un sous-ensemble restreint ;
• parfois des signaux métier : fraîcheur du document, autorité de la source, taux de clic historique.

La difficulté est que ces scores ne vivent pas sur la même échelle. Un score BM25 peut varier de 0 à 40 selon la longueur du document, un score cosinus est borné entre -1 et 1, un score de cross-encoder peut être un logit non borné. Les additionner ou les moyenner sans normalisation produit un classement dominé arbitrairement par le signal à la plus grande amplitude.

Deux approches dominent :

Fusion par score normalisé. On ramène chaque score sur une échelle commune (min-max, z-score) puis on calcule une somme pondérée. Cette méthode conserve l'information de magnitude mais est sensible aux valeurs aberrantes et nécessite un recalibrage si la distribution des scores change — nouveau corpus, nouveau modèle d'embedding.

Reciprocal Rank Fusion (RRF). On ignore les valeurs de score et on ne conserve que le rang de chaque document dans chaque classement. Le score fusionné d'un document est la somme de 1/(k + rang) pour chaque classement où il apparaît, k étant une constante d'amortissement souvent fixée à 60. RRF est robuste par construction : il n'exige aucune normalisation ni aucune calibration, et se comporte bien même quand les échelles de score sont incompatibles entre elles.

Sauf besoin spécifique de pondérer un signal plus qu'un autre, RRF est le point de départ recommandé pour fusionner retrieval lexical et retrieval dense. Il est simple à implémenter, ne nécessite pas de jeu de validation pour calibrer des poids, et se dégrade rarement mal — contrairement à une fusion pondérée mal calibrée qui peut produire un classement pire que chacun des signaux pris séparément.

Budget de latence : où va le temps

Le rerank est l'étage le plus coûteux en latence du pipeline de recherche, et de loin.

Le rerank représente souvent 10 à 30 % du temps total perçu par l'utilisateur avant génération, pour un gain de pertinence qui, lui, peut être déterminant sur la qualité finale de la réponse.

Reranker 300 candidats avec un cross-encoder de taille moyenne peut ajouter 300 à 500 ms de latence à chaque requête. Sur un produit où le budget total tolérable est de 1 à 2 secondes, ce choix doit être arbitré explicitement — il ne doit jamais être un défaut de configuration hérité d'un tutoriel. Réduire le nombre de candidats rerankés (par exemple 50 au lieu de 300) est souvent le levier le plus efficace pour retrouver de la marge, sans perte de qualité mesurable au-delà d'un certain seuil.

Choisir un reranker

Un moteur de recherche interne récupère 200 candidats via retrieval dense en 20 ms, puis rerank les 30 premiers avec bge-reranker-v2 hébergé sur une instance GPU partagée : 90 ms supplémentaires. Le classement final combine ce score de rerank avec un signal de popularité (ventes des 30 derniers jours) via une fusion pondérée simple, calibrée sur un jeu de 200 requêtes annotées manuellement. Latence totale de la phase de recherche : environ 130 ms, largement sous le budget de 300 ms fixé par l'équipe produit.

Pièges fréquents

• Reranker hors domaine. Un modèle entraîné sur des données génériques (MS MARCO, anglais, web) appliqué tel quel sur un domaine spécialisé — juridique, médical, catalogue technique — sans évaluation préalable produit des gains illusoires, voire une dégradation.
• Mauvais dimensionnement du top-K reranké. Un jeu de candidats trop petit reproduit les erreurs du retrieval initial : si le bon document n'y figure pas, le rerank ne peut rien y faire. Un jeu trop grand fait exploser la latence sans gain de qualité mesurable au-delà d'un certain seuil.
• Absence de fallback. Si l'appel au service de rerank échoue ou dépasse le timeout, le pipeline doit pouvoir retomber sur l'ordre du retrieval initial plutôt que de faire échouer toute la requête.
• Aucune mesure de l'impact réel. Déployer un reranker sans mesurer le gain sur des métriques de pertinence (NDCG, MRR) sur un jeu de testjeu de testIAPartie des données réservée à l'évaluation finale, à n'utiliser qu'une seule fois. Ajuster le modèle d'après ses résultats sur ce jeu lui ôte toute valeur de mesure indépendante.Voir dans le glossaire annoté revient à ajouter de la latence sur la foi d'une intuition.
• Ordre final ignoré au moment du prompt. Un bon classement obtenu après rerank perd une partie de sa valeur si l'ordre n'est pas respecté lors de la construction du contexte envoyé au modèle de génération.

Plusieurs études montrent que les modèles de génération accordent une attention inégale aux positions dans un contexte long : les passages en début et en fin de contexte sont mieux exploités que ceux situés au milieu. Un bon rerank ne sert à rien si l'ordre obtenu n'est pas ensuite respecté au moment de construire le prompt — placez les passages les plus pertinents en tête, et envisagez de dupliquer le signal le plus critique en fin de contexte sur les prompts longs.

Checklist de déploiement

• Le nombre de candidats retrievés en amont (top-K) est validé empiriquement, pas fixé arbitrairement à 10.
• Un reranker adapté au domaine et à la langue du corpus a été sélectionné et évalué sur un jeu de test annoté.
• Le budget de latence ajouté par le rerank est mesuré en conditions réelles (charge, taille moyenne des documents).
• Une méthode de fusion (RRF ou score normalisé) est explicitée si plusieurs signaux de retrieval sont combinés.
• Un mécanisme de fallback existe en cas d'échec ou de timeout du service de rerank.
• L'ordre final des passages dans le prompt tient compte du phénomène de perte d'attention au milieu du contexte.
• Des métriques de pertinence (NDCG@k, MRR) sont suivies dans le temps, pas seulement au moment du déploiement initial.

En résumé

Le rerank n'est pas une optimisation cosmétique ajoutée en fin de pipeline : c'est l'étage qui transforme un retrieval approximatif en un contexte réellement exploitable par le modèle de génération. Sa valeur dépend entièrement de trois arbitrages assumés — le nombre de candidats traités, le choix d'un modèle adapté au domaine, et la manière dont les signaux sont fusionnés avant d'atteindre le prompt. Traité comme un défaut de configuration copié d'un tutoriel, il ajoute de la latence sans garantie de gain. Traité comme un composant mesuré et calibré, il devient souvent le levier individuel le plus rentable pour améliorer la qualité perçue d'un système RAG en production.