Recherche hybride et reranking : pourquoi la similarité vectorielle seule échoue

La recherche vectorielle a un défaut qu'on préfère taire : elle est excellente pour le sens, médiocre pour le littéral. Demandez-lui de retrouver un document parlant de « résiliation anticipée de contrat », elle brillera. Demandez-lui le code produit XR-4420-B ou l'acronyme exact DSP2, et elle peut passer complètement à côté. C'est pour cette raison que les systèmes RAG sérieux n'utilisent presque jamais la similarité vectorielle seule. Ils combinent recherche hybride et reranking.

Voici pourquoi, et comment les assembler — avec les chiffres, les arbitrages et les réglages qui font la différence en production.

Le point aveugle de la similarité vectorielle

Un embedding capture le sens d'un passage dans un espace continu. Deux formulations différentes d'une même idée se retrouvent proches. C'est la force du dense retrieval — et sa limite.

Car certaines requêtes ne portent pas sur le sens, mais sur des correspondances exactes :

• codes produits, références, numéros de version (v2.14.0) ;
• noms propres, acronymes, identifiants (SIREN, IBAN) ;
• termes rares ou jargon métier absent des données d'entraînement de l'embedding.

Sur ces cas, un modèle d'embedding peut juger « proches » des passages qui partagent le thème mais pas le terme exact recherché. Le mécanisme est simple à comprendre : un tokenizer subword découpe XR-4420-B en fragments (XR, -, 44, 20…) qui n'ont aucune signification stable, et le vecteur résultant se range à côté de n'importe quelle autre référence alphanumérique. Pour l'embedding, XR-4420-B et XR-4420-C sont quasi indiscernables ; pour votre utilisateur, ce sont deux pièces différentes. Résultat : le bon document, celui qui contient littéralement la référence, ne remonte pas — ou remonte en 30ᵉ position, hors du contexte transmis au LLM.

La recherche dense comprend ce que vous voulez dire ; la recherche lexicale trouve ce que vous avez écrit. Un bon RAG a besoin des deux.

Un exemple concret où le vectoriel seul échoue

Prenons une base documentaire de support technique. La requête : « erreur E-1042 après mise à jour v2.14.0 ». Le seul document utile est une note de version qui mentionne mot pour mot E-1042 et v2.14.0.

• Dense seul : le modèle remonte cinq articles parlant d'« erreurs après une mise à jour », de « problèmes de migration », de « régressions de version » — sémantiquement voisins, mais aucun ne contient le code exact. La vraie note arrive 18ᵉ.
• Lexical (BM25) : E-1042 et v2.14.0 sont des tokens rares, à très fort poids IDF. Le document qui les contient tous les deux sort en tête immédiatement.
• Hybride : le document est repéré par BM25 et jugé thématiquement pertinent par le dense → la fusion le propulse en tête, et le reranker confirme. Le LLM reçoit la bonne note de version dès le top-5.

C'est exactement le type de requête — fréquente en support, juridique, finance, R&D — où l'on perd un client si le RAG répond à côté.

BM25 : pourquoi le lexical capte le littéral

BM25 (Best Matching 25) est l'algorithme de référence du retrieval lexical, hérité de la famille TF-IDF. Il classe un document par rapport à une requête à partir de trois ingrédients :

1. TF (term frequency) — plus un terme de la requête apparaît dans le document, plus le score monte, mais avec saturation : la 10ᵉ occurrence pèse beaucoup moins que la 2ᵉ (paramètre k1, typiquement ~1.2–2.0).
2. IDF (inverse document frequency) — un terme rare dans le corpus (comme E-1042) vaut beaucoup plus qu'un mot courant (le, mise, jour). C'est ce qui rend BM25 chirurgical sur les identifiants et le jargon.
3. Normalisation par longueur — on évite qu'un document très long marque mécaniquement plus de points (paramètre b, typiquement ~0.75).

La force de BM25 tient à l'IDF : un token qui n'apparaît que dans un seul document du corpus devient un signal quasi déterministe. Aucune généralisation sémantique, aucun « à peu près » — c'est précisément ce que le dense ne sait pas faire. En contrepartie, BM25 est aveugle aux synonymes (« résiliation » ≠ « rupture ») et à la reformulation. D'où la complémentarité, pas la concurrence.

Le dense generalise, BM25 discrimine. L'un trouve le document qui parle du même sujet, l'autre trouve le document qui contient le bon mot. Les fusionner, c'est cesser de choisir.

La recherche hybride : dense + lexical

La recherche hybride combine ces deux moteurs complémentaires :

• Dense (vectoriel) — capture la similarité sémantique.
• Lexical (type BM25 / mots-clés) — capture les correspondances de termes exacts.

On lance les deux en parallèle, puis on fusionne les classements. La méthode la plus robuste est le RRF (Reciprocal Rank Fusion) : elle combine les rangs (et non les scores, difficilement comparables entre moteurs) pour produire un classement unifié.

Requête
   ├──► recherche dense (pgvector / HNSW) ──► top-k_dense
   └──► recherche lexicale (BM25)         ──► top-k_lexical
                       │
                  fusion RRF
                       │
              candidats unifiés (top-N large)

Comment fonctionne le RRF, en chiffres

Le RRF ne regarde pas les scores bruts — un score de distance cosinus (entre 0 et 1) et un score BM25 (non borné, dépendant du corpus) ne sont pas comparables. Il ne garde que le rang de chaque document dans chaque liste, et applique :

score_RRF(d) = Σ  1 / (k + rang_i(d))
              listes i

où k est une constante d'amortissement (valeur usuelle : 60) qui empêche le tout premier rang d'écraser tous les autres. Prenons trois documents A, B, C et deux moteurs :

Doc	Rang dense	Rang BM25	Calcul (k=60)	Score RRF
A	1	4	1/61 + 1/64	0,0320
B	3	1	1/63 + 1/61	0,0323
C	2	30	1/62 + 1/90	0,0272

Lecture du résultat : B passe en tête bien qu'il ne soit premier que d'un seul moteur, parce qu'il est bien classé dans les deux. A, fort en dense et correct en BM25, suit de très près. C, brillant en dense (rang 2) mais quasi absent en BM25 (rang 30), tombe en dernier : un seul moteur ne suffit pas à le porter. C'est tout l'intérêt du RRF — un consensus entre moteurs prime sur un pic isolé, sans qu'on ait à calibrer des poids fragiles entre des échelles de scores incompatibles.

Le RRF récompense l'accord entre moteurs. Un document que dense et BM25 jugent pertinent remonte fort ; un document porté par un seul reste candidat sans dominer. C'est ce qui rend la fusion robuste sans réglage fin.

Le reranking : récupérer large, trancher fin

La fusion produit une liste de candidats — mettons les 50 meilleurs. Mais 50, c'est trop pour le contexte du LLM, et l'ordre n'est pas encore optimal. C'est le rôle du reranking.

Bi-encoder vs cross-encoder

La distinction est centrale. Un bi-encoder — c'est ce que sont vos embeddings — encode la requête et chaque document séparément, en deux vecteurs, puis compare par produit scalaire ou cosinus. Avantage : on précalcule tous les vecteurs documents à l'indexation, la requête ne coûte qu'un encodage + une recherche d'index. Inconvénient : la requête et le document ne « se voient » jamais ; toute l'interaction est écrasée dans une distance entre deux points.

Un cross-encoder — c'est le reranker — concatène la requête et le candidat dans une seule entrée ([requête] [SEP] [document]) et laisse l'attention du transformer croiser chaque mot de la requête avec chaque mot du document. Il produit directement un score de pertinence. C'est beaucoup plus fin : il « comprend » que le v2.14.0 de la requête correspond exactement au v2.14.0 du document, et que le contexte les relie. Le prix : on ne peut rien précalculer, puisque le score dépend de la paire. Il faut un passage modèle par couple (requête, candidat) au moment de la requête.

D'où l'architecture en deux temps : le bi-encoder (rapide, précalculé) filtre des millions de documents vers quelques dizaines ; le cross-encoder (lent, précis) réordonne ces quelques dizaines.

Le pattern gagnant :

1. Récupérer large (hybride, top-50) — privilégier le rappel.
2. Reranker ces candidats — privilégier la précision.
3. Garder le top-k fin (top-5 à top-8) pour le LLM.

Modèles de reranking matures en 2026 : Cohere Rerank 3, bge-reranker-v2-m3 (open, multilingue), Voyage rerank, le reranker de Jina.

candidats (top-50) ──► reranker cross-encoder ──► top-8 ──► LLM
        (rappel)              (précision)

Récupérer large puis reranker fin : c'est le compromis rappel/précision le plus rentable du RAG. La similarité vectorielle sert de filtre grossier ; le reranker fait le tri qui compte.

Latence et coût : les ordres de grandeur

Le reranking n'est pas gratuit, mais il est largement abordable si l'on respecte l'entonnoir. Ordres de grandeur prudents à attendre en 2026 :

• Reranker hébergé (API) — type Cohere Rerank 3, Voyage, Jina : reranker 50 candidats ajoute typiquement 50 à 200 ms de latence (un seul appel réseau, traitement batché côté fournisseur). Côté coût, ces API se facturent à la « recherche » (un appel = 1 requête + N documents), souvent de l'ordre du dollar pour quelques milliers de recherches — négligeable face au coût du LLM en aval.
• Reranker open auto-hébergé — bge-reranker-v2-m3 sur GPU : compter quelques millisecondes par paire, soit quelques dizaines de ms pour 50 candidats batchés. Pas de coût marginal par requête, mais une instance GPU à provisionner et à maintenir.
• Ce qui dérape : reranker 500 candidats au lieu de 50 multiplie le coût/latence par ~10 pour un gain marginal quasi nul. La discipline sur le top-N est le principal levier.

Comparé à la génération LLM (souvent plusieurs centaines de ms à plusieurs secondes), le surcoût du reranking est presque toujours un bon investissement : il améliore la précision du contexte, donc la qualité de la réponse, donc réduit les itérations.

Pourquoi ne pas tout reranker ?

Parce que le cross-encoder est coûteux : il faut un passage modèle par paire (requête, candidat). Reranker 10 000 documents à chaque requête serait inabordable en latence et en coût — et inutile : au-delà de quelques dizaines de candidats, on rerank surtout du bruit. D'où l'architecture en entonnoir : la recherche hybride réduit le champ à quelques dizaines de candidats que le reranker peut traiter rapidement, et concentre le calcul précis là où il compte.

Réglages et pièges

• Calibrez le top-N de récupération — trop petit, vous privez le reranker de bons candidats (le bon document n'est jamais dans la liste, le rerank n'y peut rien) ; trop grand, vous payez en latence pour rien. Le top-30 à top-50 est un bon point de départ ; mesurez le recall@N sur votre golden set pour trancher.
• Ajustez ef_search côté pgvector/HNSW — ce paramètre contrôle la largeur de l'exploration du graphe à la requête. Trop bas, l'index HNSW rate de bons candidats (recall dégradé) ; trop haut, la latence grimpe. Visez un ef_search qui garantit que vos top-N denses sont stables, typiquement quelques centaines. C'est le pendant côté index du top-N côté application.
• Gardez le RRF k autour de 60 — c'est une valeur éprouvée. La toucher n'apporte généralement rien : si la fusion vous déçoit, le problème est presque toujours en amont (qualité des embeddings, chunking, recall de l'un des moteurs), pas dans k.
• Surveillez la latence end-to-end — le reranking ajoute un saut réseau et du calcul. Mesurez l'impact perçu, pas seulement le p50 : ce sont les p95/p99 qui font fuir les utilisateurs.
• Le lexical n'est pas optionnel en multilingue ou jargon — sur des corpus techniques, juridiques ou financiers, BM25 rattrape souvent ce que le dense rate. En multilingue, vérifiez que votre tokenisation BM25 gère bien la langue (accents, composés).
• Posez un seuil de score reranker — au-delà du top-k, filtrez aussi sur un score de pertinence minimal. Mieux vaut transmettre 3 chunks vraiment pertinents que 8 dont 5 sont du bruit qui dilue le contexte du LLM.
• Évaluez avec un golden set — la seule façon de savoir si l'hybride + rerank améliore vraiment votre cas, et pas seulement « en théorie ». Mesurez context recall et context precision (par exemple via RAGAS) avant/après.

Conclusion

La similarité vectorielle seule est un bon point de départ et un mauvais point d'arrivée. En ajoutant une recherche lexicale fusionnée par RRF, vous récupérez ce que le sens seul laisse échapper — les codes, les références, le jargon ; en ajoutant un reranker cross-encoder, vous transformez une liste de candidats correcte en un contexte précis, en faisant enfin « se voir » la requête et les documents. C'est cette combinaison — large puis fin, sens puis littéral — qui sépare un RAG de démo d'un RAG qui répond juste en production. Et la bonne nouvelle, c'est que chaque brique (BM25, RRF, reranking) est aujourd'hui mature, peu coûteuse, et disponible aussi bien en API qu'en open source auto-hébergeable.

Pour aller plus loin

• Architecture RAG de production : du chunking au reranking, le guide complet
• Le chunking, l'étape la plus sous-estimée du RAG : stratégies 2026