La recherche hybride combine une recherche sémantique par vecteurs (dense) et une recherche lexicale par mots-clés, le BM25 (sparse), puis fusionne les deux classements pour retrouver aussi bien le sens d'une question que les références exactes qu'une recherche purement sémantique laisse filer. Ajouter un reranker, un modèle qui relit les meilleurs candidats en croisant directement question et document, affine ensuite ce classement avant qu'il parte au LLM.
Ces deux briques ne sont pas gratuites : elles ajoutent de la latence, un service de plus à exploiter, et une surface d'évaluation plus large. Pour un décideur technique qui évalue s'il faut les construire, la question n'est pas "est-ce que ça marche mieux", la réponse est presque toujours oui, mais "est-ce que le gain justifie le coût sur mon cas précis".
Cet article explique pourquoi la recherche sémantique seule échoue sur les codes et le jargon métier, comment la recherche hybride et le reranking corrigent ce défaut, ce qu'ils coûtent en latence et en exploitation, et comment mesurer le gain avant de décider de les construire.
En bref
- La recherche sémantique seule rate les codes, références et termes rares parce qu'elle compresse le sens dans un vecteur unique
- Le BM25 corrige ce défaut par correspondance exacte de mots, fusionné à la recherche dense via Reciprocal Rank Fusion
- Qdrant gère nativement les deux recherches et leur fusion, sans moteur BM25 séparé à exploiter
- Le reranking ajoute une précision réelle mais coûte entre 50 et 300 ms de latence selon l'implémentation
- Le gain se mesure sur un jeu de questions de référence, jamais à l'impression
Pourquoi la recherche sémantique seule rate les références exactes
Un modèle d'embedding transforme une question et un document en vecteurs, puis mesure leur proximité dans cet espace. C'est ce qui permet à un RAG de comprendre que "tarif" et "prix" désignent la même chose, ou que "annuler une commande" et "procédure de rétractation" parlent du même sujet. Notre guide technique sur les embeddings et la recherche sémantique détaille ce mécanisme et ses limites.
Le problème vient de cette même compression. Un vecteur unique représente le sens général d'un texte, pas ses détails exacts. Deux documents qui parlent du même sujet général, une facture précise et un résumé du chiffre d'affaires du trimestre, peuvent se retrouver presque à la même distance d'une question sur la facturation, alors qu'un seul des deux contient la bonne réponse.
Les codes, références et identifiants
Numéros de facture, références produit, articles de loi, identifiants internes : ce sont des tokens où seule la correspondance exacte compte. Un modèle d'embedding a vu ce type de motif à l'entraînement, mais il a tendance à traiter des codes qui se ressemblent comme interchangeables. La référence exacte demandée par l'utilisateur peut se retrouver noyée derrière des documents simplement voisins par le sujet.
Le jargon et le vocabulaire métier
Un terme technique rare dans le langage courant mais fréquent dans un métier précis reçoit souvent une représentation approximative de la part d'un modèle d'embedding généraliste. Le modèle compense par une approximation basée sur la ressemblance de forme, ce qui peut être franchement à côté de la plaque sur un vocabulaire très spécialisé (nomenclature technique, terminologie réglementaire, abréviations internes à l'entreprise).
Ce n'est pas un cas marginal. Sur un projet d'assistant RAG déployé pour un éditeur toulousain de logiciel médical, la recherche hybride BM25 a été retenue précisément parce que les utilisateurs posaient des questions truffées de termes statistiques et de noms de fonctionnalités précis, que la recherche sémantique seule manquait régulièrement. C'est ce choix d'architecture qui a contribué à la baisse de moitié des tickets support constatée après le déploiement.
Recherche hybride : dense et BM25, puis fusion des classements
La recherche hybride exécute deux recherches en parallèle sur la même question : une recherche dense (par similarité vectorielle) et une recherche BM25 (par correspondance de mots pondérée par fréquence et rareté). Un terme qui n'apparaît que dans une poignée de documents sur plusieurs milliers reçoit un poids élevé dans BM25 : s'il figure dans la question, ces documents remontent en tête, là où la recherche sémantique les aurait dilués parmi des résultats thématiquement proches.
Reste à fusionner les deux listes de résultats en une seule. La méthode la plus robuste, et la plus utilisée en production, est la Reciprocal Rank Fusion (RRF), décrite par Cormack, Clarke et Buettcher en 2009. Son principe évite un piège classique : les scores de BM25 et les scores de similarité vectorielle ne vivent pas sur la même échelle, et une pondération fixe entre les deux se dérègle dès que le corpus change.
RRF contourne le problème en ignorant les scores bruts et en travaillant uniquement sur le rang de chaque document dans chaque liste. Un document bien classé par les deux méthodes à la fois obtient un score de fusion élevé, même s'il n'était numéro un dans aucune des deux. C'est un signal d'accord entre deux méthodes de recherche différentes, ce qui est un indicateur de pertinence solide.
Ce que la fusion RRF change concrètement
- Un document trouvé par la recherche dense mais absent des résultats BM25 reste dans la liste, avec un score plus faible
- Un document trouvé par les deux méthodes remonte, même s'il n'était en tête d'aucune des deux
- Aucune pondération à calibrer manuellement, contrairement à une somme pondérée des scores bruts
- La fusion reste stable quand le corpus grandit, alors qu'une pondération fixe doit être recalibrée
Le reranking : une seconde passe qui affine la précision
La recherche hybride améliore le rappel, c'est-à-dire la probabilité que le bon document figure quelque part dans les vingt ou cinquante premiers résultats. Mais un RAG n'envoie au LLM que 3 à 5 passages. Un document pertinent classé quinzième ne sert à rien s'il n'entre jamais dans ce lot final.
C'est le rôle du reranking : reprendre les meilleurs candidats de la recherche hybride et les reclasser avec un modèle qui compare directement la question et chaque document, un cross-encoder, au lieu de comparer des vecteurs pré-calculés indépendamment. Cette comparaison directe donne un score de pertinence beaucoup plus fin, au prix d'un calcul par paire question-document, ce qui interdit de l'utiliser sur des milliers de candidats mais convient parfaitement sur les vingt à cinquante premiers résultats déjà filtrés par la recherche hybride.
Le reranker est un outil de précision, pas de rappel : s'il n'y a pas le bon document dans le lot de départ, aucun reranking ne le fera apparaître. Il corrige le classement, pas les trous du retrieval en amont. Si votre recherche hybride ne remonte déjà pas le bon document dans le top 50, corrigez d'abord le chunking, les embeddings ou le paramétrage BM25 avant d'ajouter un reranker.
| Option de reranking | Hébergement | Latence indicative | Coût indicatif |
|---|---|---|---|
| Cohere Rerank | API tierce | 100 à 300 ms | Environ 2 $ pour 1 000 requêtes (50 documents) |
| BGE-reranker-v2-m3 (open source) | Auto-hébergé, GPU | 50 à 150 ms | Coût d'un serveur GPU partagé, pas de coût par requête |
| Cross-encoder léger (type MiniLM) | Auto-hébergé, CPU | 15 à 50 ms | Coût CPU marginal, qualité en retrait |
Qdrant : recherche hybride native, sans architecture séparée
Historiquement, faire de la recherche hybride demandait de faire tourner deux systèmes : un moteur BM25 comme Elasticsearch, et une base vectorielle à part. Ce n'est plus nécessaire avec Qdrant, qui permet de stocker sur un même point un vecteur dense et un vecteur sparse de type BM25, puis d'interroger les deux en parallèle via son API de requête, avec une fusion RRF intégrée.
L'intérêt opérationnel dépasse la simple commodité. Faire tourner deux systèmes séparés (un moteur de recherche lexicale et une base vectorielle) double le nombre de services à surveiller, à faire évoluer et à sécuriser, et ajoute un aller-retour réseau entre les deux avant de pouvoir fusionner les résultats côté application. Avec une fusion native, les deux recherches s'exécutent dans le même système et la latence réseau supplémentaire disparaît.
D'autres bases vectorielles proposent des approches comparables (Weaviate avec son propre système de fusion, Elasticsearch en combinant ses capacités historiques de recherche lexicale à un module vectoriel, pgvector associé à un module de recherche plein texte PostgreSQL pour les architectures qui doivent rester simples). Notre comparatif des bases de données vectorielles pour le RAG détaille ces alternatives selon votre contexte technique et votre volumétrie.
Ce que la recherche hybride et le reranking coûtent réellement
Ajouter ces deux briques n'est jamais gratuit, sur trois plans distincts qu'il faut évaluer avant de décider.
La latence
La recherche hybride en elle-même coûte peu, de l'ordre de quelques dizaines de millisecondes, puisque les deux recherches s'exécutent en parallèle dans le même système. Le reranking coûte davantage, entre 50 et 300 millisecondes selon qu'il tourne sur un modèle auto-hébergé sur GPU ou via une API tierce avec un aller-retour réseau. Sur un pipeline RAG complet, ce coût reste toutefois secondaire face à la génération par le LLM, souvent 60 à 80% de la latence totale. Optimiser le reranker de 200 à 50 ms ne réduira pas la latence totale de moitié, il faut regarder d'abord où se trouve réellement le goulot d'étranglement.
La complexité opérationnelle
Un service de reranking, qu'il soit auto-hébergé ou consommé via API, est un composant de plus à monitorer, à faire évoluer, et dont la panne dégrade tout le pipeline. Une fusion RRF côté base vectorielle est plus simple à exploiter qu'une fusion faite à la main dans le code applicatif, mais elle reste une brique de plus par rapport à une recherche dense seule.
La complexité d'évaluation
Chaque brique ajoutée est une variable de plus à isoler quand une réponse est mauvaise. Avant de conclure qu'un RAG répond mal, il faut désormais savoir distinguer un problème de recherche dense, un problème de score BM25, un problème de fusion, un problème de reranking et un problème de génération. Notre article sur la baseline d'évaluation RAG détaille comment séparer ces maillons avant de corriger.
Quand le gain justifie le coût, et comment le mesurer
La recherche hybride et le reranking ne sont pas une case à cocher par défaut. Ils apportent le plus de valeur dans des conditions précises, et sont souvent superflus dans d'autres.
| Le gain se justifie souvent | Le gain est souvent marginal |
|---|---|
| Corpus technique avec codes, références, jargon métier | FAQ mono-produit, corpus homogène et restreint |
| Plusieurs milliers de documents ou plus | Quelques dizaines à centaines de documents |
| Questions de longue traîne, formulations variées | Budget de latence total sous 400 ms, LLM compris |
| Documents semblables en surface mais factuellement distincts | Recherche déjà proche de 100% de rappel sans ces briques |
Dans tous les cas, la décision ne devrait pas se prendre à l'impression. La méthode : constituer un petit jeu de questions réelles avec leur bonne réponse de référence, mesurer le taux de bonnes réponses et le rappel du retrieval avant d'ajouter la recherche hybride, puis remesurer après chaque brique ajoutée, sur exactement le même jeu de test. Notre article sur la baseline d'évaluation RAG avant correction détaille comment construire ce jeu de test et l'exploiter.
Si le rappel du retrieval est déjà satisfaisant sans recherche hybride, l'ajouter n'apportera rien de mesurable. Si le reranking n'améliore pas le score sur votre jeu de test, ce n'est probablement pas le reranker le problème, mais un manque en amont dans la recherche hybride elle-même. Ces deux briques ne sont que deux des leviers possibles : notre article sur l'optimisation d'un système RAG les replace dans l'ensemble des cinq leviers techniques disponibles, du parsing au reranking.
Le même arbitrage coût contre gain s'applique quel que soit l'hébergement du RAG, y compris quand la contrainte de souveraineté impose un déploiement en France ou sur vos propres serveurs : voir notre article sur l'architecture d'un RAG souverain avec Mistral, où le choix entre reranker auto-hébergé et API tierce se pose dans les mêmes termes, avec en plus la contrainte de localisation des données.
Vous hésitez entre construire cette brique ou la déléguer ?
On regarde votre corpus et vos traces de requêtes, et on vous dit si la recherche hybride et le reranking sont justifiés, ou si le retrieval dense suffit encore.
Comment Tensoria construit cette brique pour ses clients
Quand nous concevons un assistant IA interne RAG sur mesure, la recherche hybride et le reranking ne sont pas ajoutés par principe : ils sont mesurés sur un jeu de questions réelles issu de votre corpus, avant d'être validés ou écartés. Si votre RAG est déjà en production et déçoit sur des questions précises, notre audit technique RAG et Agents IA isole d'abord si le problème vient du retrieval ou de la génération, avant de recommander une brique plutôt qu'une autre. C'est sur devis, dimensionné selon la taille de votre corpus et vos contraintes de latence.
Pour une vue d'ensemble de l'architecture, des coûts et des choix techniques d'un RAG en entreprise au-delà du seul retrieval, notre guide du RAG en entreprise couvre l'ensemble du sujet.
Questions fréquentes
Articles recommandés
- Embeddings et recherche sémantique : comprendre le fonctionnement des vecteurs avant d'aborder leurs limites.
- Optimiser un système RAG : les cinq leviers techniques, du parsing au reranking, replacés dans leur ensemble.
- Baseline d'évaluation RAG : la méthode pour mesurer un gain avant de l'affirmer.
- Comparatif des bases de données vectorielles pour le RAG : Qdrant, pgvector, Weaviate et les autres selon votre contexte.
- RAG souverain avec Mistral : le même arbitrage coût contre gain, appliqué à un déploiement en France.
- Cas client : assistant RAG pour un éditeur de logiciel médical : la recherche hybride BM25 en conditions réelles, sur un corpus technique.
