Recherche hybride pour RAG : BM25, vecteurs et fusion de rang réciproque en pratique
Recherche hybride pour RAG : pourquoi la récupération basée uniquement sur des vecteurs perd les identifiants exacts, comment la fusion de rangs réciproques combine BM25 avec des embeddings, et en quoi la recherche hybride reste insuffisante.
Sources: Hybrid Search in RAG — BM25, Vectors, and Reciprocal Rank Fusion in Practice
Intégrer une recherche par mots-clés à un système de récupération basé uniquement sur des vecteurs représente l’un des moyens les moins coûteux d’améliorer la précision dans les systèmes RAG. Anthropic l’a mesuré sur ses propres corpus : l’utilisation de BM25 contextuel en complément des embeddings contextuels a permis de réduire de jusqu’à 49 % le nombre de résultats incorrects parmi les 20 meilleurs, sans modifier le modèle d’embeddings.
Examinons les raisons derrière ce chiffre. Un utilisateur tape un identifiant de véhicule tel que GX-V5-5N. Un système purement vectoriel fournit des instructions de mise en registration générales ainsi que des historiques de maintenance, et le document correct fait même partie des dix premiers résultats. Les embeddings, eux, saisissent parfaitement le contexte automobile, et c’est précisément pour cette raison qu’ils éliminent la chaîne de caractères littérale. Il ne s’agit pas de embeddings faibles ; il s’agit d’un problème structurel qui affecte tout système RAG basé uniquement sur des vecteurs, ce qui correspond à ce que produisent la plupart des tutoriels par défaut.
Ci-dessous : pourquoi la combinaison de la recherche lexicale et de la recherche vectorielle nécessite des mathématiques différentes de celles utilisées pour calculer la moyenne des scores, ce que fait la fusion par rang réciproque, où l’approche hybride cesse d’être utile, et ce qu’il faut mesurer avant de l’activer.
L’idée en deux minutes
La recherche vectorielle pure perd systématiquement les correspondances exactes telles que les codes d’erreur, les identifiants de produits et les noms propres. L’incorporation n’est pas mauvaise ; la proximité sémantique et la correspondance littérale sont simplement des propriétés différentes.
BM25, une fonction de classement lexicale datant des années 1990, comble les lacunes des vecteurs. Elle permet de détecter des tokens rares et spécifiques presque gratuitement, mais elle rate les paraphrases et les synonymes en contrepartie. Les deux méthodes échouent dans des directions opposées, ce qui constitue la raison structurelle de les combiner, et non une simple mode technique temporaire.
Le problème, c’est que leurs résultats ne peuvent pas être additionnés. Les scores BM25 sont illimités et dépendent du corpus, tandis que la similarité cosinus se situe entre –1 et 1. Une somme de 15,3 et 0,82 n’a aucun sens. C’est pourquoi les moteurs modernes ne fusionnent pas les scores ; ils fusionnent plutôt les positions de classement à l’aide de la Reciprocal Rank Fusion.
Cependant, l’approche hybride ne gagne pas toujours. Pour les requêtes basées sur des identifiants exacts, BM25 seul peut surpasser toute méthode de fusion. La question pertinente n’est pas de savoir s’il faut utiliser l’approche hybride, mais quelle proportion de vos requêtes en a réellement besoin, et c’est ce qu’il faut mesurer.
Deux points aveugles complémentaires
Imaginez deux collègues juniors ayant des faiblesses opposées.
Le premier est aussi littéral que Ctrl+F. Lorsqu’on lui demande la page correspondant au code d’erreur ERR_CONNECTION_RESET, il la trouve immédiatement. Interrogé sur les problèmes de connexion, il ignore le document concernant la perte de session, car aucun des mots de la requête n’y figure.
Le second sait interpréter ce qui est implicite. Il comprend que les problèmes de connexion et la perte de session décrivent la même chose. Cependant, lorsqu’on lui demande un code d’erreur précis, il fournit une note générale sur les pannes réseau, car cette chaîne rare est noyée dans le sens global de la phrase.
Aucun de ces deux approches ne suffit à lui seul. Voilà l’essentiel de l’argument en deux paragraphes.
Ce que compte BM25
BM25 n’est ni magique ni obsolète. Il fonctionne sur un index inversé, une table reliant chaque mot aux documents qui le contiennent, ce qui permet à l’algorithme de ne jamais parcourir l’ensemble de la collection. Le classement repose sur trois principes intuitifs :
- Les termes rares pèsent plus lourd. L’identifiant GX-V5-5N en dit bien plus que le mot « véhicule ».
- La répétition sature. Une dixième occurrence d’un mot apporte beaucoup moins que la deuxième, car la courbe s’aplatit après quelques répétitions.
- La longueur est pénalisée. Les documents longs ne devraient pas l’emporter simplement parce qu’ils offrent plus de possibilités de correspondances aléatoires.
Un modèle vectoriel fonctionne selon un autre principe. Le texte devient une liste de nombres qui codent le sens, et le classement repose sur la proximité dans cet espace, que la requête et le document partagent ou non un mot. Un moteur mesure la couverture des caractères, tandis que l’autre mesure la couverture du sens.
Une erreur de catégorie à éviter
Il est tentant de considérer la recherche vectorielle comme une version améliorée de la recherche de texte complet, plus moderne et plus intelligente, et comme la solution naturelle. C’est une erreur de catégorie. Les vecteurs ne remplacent pas la recherche lexicale. Ils résolvent un problème différent et, ce faisant, perdent une capacité que la recherche lexicale possédait gratuitement.
Si un corpus contient des codes, des identifiants ou des noms propres, une simple embedding les fera disparaître, peu importe la qualité du modèle. La limite provient de ce que représente un vecteur. La bonne approche consiste à déterminer quelles requêtes nécessitent quelle intensité, ce qui pose le problème de la fusion de deux listes de résultats mesurées en unités non liées.
Pourquoi les scores ne peuvent pas être simplement additionnés
L’instinct naturel en ingénierie est de normaliser, de pondérer et d’additionner. Cela heurte cependant un fait que l’ajustement ne peut pas éliminer.
BM25 ne possède pas de plafond théorique. Sa valeur de sortie augmente avec le nombre de termes de requête correspondants, leur rareté dans le corpus ainsi que la longueur du document ; ainsi, un même document obtient une valeur différente après l’arrivée de dix mille nouveaux fichiers. La similarité cosinus, qui compare l’angle entre deux vecteurs, reste dans la plage allant de –1 à 1.
Ajouter 15,3 à 0,82 revient à additionner des kilogrammes et des livres sans effectuer de conversion : c’est arithmétiquement possible, mais informationnellement vide. On peut utiliser la normalisation min-max ou z-score, mais dans ce cas, les deux systèmes de notation doivent être recalibrés chaque fois que le corpus, le modèle d’incorporation ou la composition des requêtes change. Une telle calibration, qui doit être effectuée à chaque reindexation, constitue une dette différée.
Vote sur la position
La fusion de classements réciproques évite ce problème en ignorant les scores. Elle ne prend en compte que le classement que chaque moteur attribue à un document. La formule est simple : le score fusionné d’un document est la somme, pour chaque moteur, de un divisé par (k plus son classement dans la liste de ce moteur). Un document absent d’une liste ne contribue rien.
Ainsi, un document parmi les trois premiers dans les deux listes l’emporte sur un document qui est premier dans l’une des listes mais absent de l’autre. La RRF récompense la concordance dans l’ordre plutôt que la certitude, et la position dans le classement est une unité produite de la même manière par chaque moteur de classement.
Cette méthode provient de Cormack, Clarke et Büttcher lors du SIGIR 2009, bien avant RAG. Leur raisonnement : les classements les plus élevés devraient compter le plus, les classements plus bas ne devraient pas disparaître complètement, et la constante k atténue l’influence de tout système particulièrement atypique.
Une note de bas de page évoquée lors des revues de conception : la valeur standard de k égale à 60 provient d’une seule expérience pilote et n’a pas été modifiée lors des validations ultérieures. Les auteurs eux-mêmes l’ont décrite comme un choix non réfléchi. Avec k=60, le premier rang obtient un score d’environ 1,6 % supérieur à celui du deuxième rang, tandis que le soixantième rang ne reçoit qu’environ la moitié du score du premier rang.
En pratique, k fonctionne comme un réglage subtil et non comme une manette. Ce qui importe davantage, c’est le nombre de candidats fournis par chaque composante. Si la composante vectorielle fournit cinquante candidats, un document à la position cinquante-et-une n’apporte absolument aucun score.
Comment le mode hybride est devenu la norme
Les chiffres les plus clairs proviennent des expériences de récupération contextuelle menées en 2024 par Anthropic sur ses propres ensembles de données, afin de déterminer avec quelle fréquence le bon fragment manquait parmi les vingt meilleurs résultats. Les embeddings contextuels seuls ont permis de réduire ces omissions de 35 pour cent. L’ajout d’un mécanisme BM25 contextuel a porté cette réduction à 49 pour cent, ce qui montre que l’aspect lexical contribuait pour une grande part aux améliorations apportées par les embeddings.
Il convient de ne pas se méprendre : le même rapport indique une réduction de 67 pour cent lorsqu’on ajoute un étape de réclassement, mais ce réclassement constitue une étape distincte utilisant un type de modèle différent. La fusion et le réclassement ne sont pas des synonymes, et les mélanger sur une même diapositive est une erreur fréquente dans les présentations.
La convergence entre les fournisseurs en dit plus que n’importe quel benchmark isolé. Elasticsearch, OpenSearch, Weaviate, Qdrant et Azure AI Search intègrent tous nativement le RRF. La recherche hybride est passée d’une option avancée à la configuration par défaut.
Le coût d’un deuxième index
Il y a un prix à payer, et il doit être pris en compte avant de prendre une décision, et non après le premier incident :
- plus d’espace disque, en quantité dépendante de la configuration,
- quelques millisecondes supplémentaires pour l’étape de fusion,
- et, ce qui est le plus important, un deuxième élément qui peut sortir de synchronisation. Si un document est supprimé de l’index vectoriel mais reste dans l’index lexical, il réapparaît sans cesse comme un fantôme.
Les équipes déjà utilisant Postgres peuvent souvent bénéficier d’un système lexical en combinant pgvector avec la recherche plein texte intégrée, entièrement en SQL et sans nouvelle infrastructure. Si le système RAG actuel ne fait que travailler avec des vecteurs, la meilleure question est de savoir pourquoi il ne dispose pas de BM25, ce qui relève d’une dette technique et non d’une innovation.
Où le système hybride perd
L’unanimité des fournisseurs pourrait laisser penser que le système hybride l’emporte toujours. Les tests directs sont plus nuancés, et des résultats étranges apparaissent lorsque l’on analyse les scores par type de requête plutôt que de les moyanner.
Dans la comparaison Azure AI Search de Microsoft en 2023, la recherche hybride a surpassé la recherche basée uniquement sur des vecteurs dans l’ensemble. Si l’on examine les résultats par catégorie, le schéma est moins clair : pour les requêtes purement basées sur des mots-clés, le moteur lexical unique peut obtenir un score plus élevé que le résultat issu de la fusion. La moyenne cache ce que révèle une analyse par segment.
Un deuxième moteur n’ajoute pas toujours de valeur
Là où le moteur lexical a raison, un deuxième vote affaiblit son résultat. Supposons que BM25 classe le document correct en premier position tandis que les vecteurs le placent à la dixième. La fusion le fait descendre en dessous d’un document classé troisième par les deux méthodes. L’accord prime sur la précision, ce qui est voulu par conception, mais cela a un coût pour certains types de requêtes.
La qualité de la deuxième étape est également importante. Des tests de récupération en première phase sur un corpus scientifique ont montré qu’un système hybride basé sur un modèle d’incorporation faible se classait en dessous de BM25 seul, tandis que la même configuration avec un modèle plus puissant se situait nettement au-dessus. La fusion ne crée rien de nouveau ; elle se contente de mélanger des éléments existants, et le bruit reçoit autant de poids que le signal.
Cela ne contredit pas le point de départ. La qualité de l’incorporation détermine l’ampleur de l’apport de la composante vectorielle, mais même la meilleure incorporation ne peut pas restituer un identifiant exact qu’elle ne représente pas. Il s’agit de deux axes distincts.
Aucun de ces résultats ne s’oppose à la recherche hybride. Tous deux s’opposent à son utilisation sans mesurer sa propre distribution de requêtes. De nombreuses équipes choisissent la recherche hybride par défaut, sans jamais prendre en compte cette distribution.
La mesure est peu coûteuse. Divisez les journaux de requêtes en requêtes dotées d’un identifiant exact et en requêtes purement conceptuelles, puis calculez une métrique pour chaque groupe séparément. Cela prend des heures et non quelques minutes, tandis qu’un seul chiffre agrégé cache la régression qui causera des problèmes en production par la suite.
Le problème du consensus
La fusion des classements présente une faille plus subtile qui apparaît lorsque les moteurs sont d’accord et non lorsqu’ils ne le sont pas.
Prenons une recherche dans une documentation technique, avec une requête concernant la configuration d’OAuth via des variables d’environnement. La méthode vectorielle renvoie un guide général sur la sécurité : pertinent dans l’idée, mais sans détails spécifiques sur OAuth. BM25 renvoie une correspondance précise pour OAuth, mais dans un changelog vieux de trois ans. Aucune des deux solutions n’est optimale, et la fusion classe néanmoins en premier le résultat le moins fiable des deux.
C’est la conséquence directe du fonctionnement de RRF. Le journal des modifications obsolète a été évalué au niveau intermédiaire par les deux moteurs, de sorte que leurs deux classements réciproques ont donné un total supérieur à celui de la page fraîche que seul un moteur a appréciée. Deux avis mitigés l’emportent sur un avis ferme et correct.
Filtrage avant fusion
La correction se situe en amont du calcul mathématique. Dans la plupart des cas, des filtres de métadonnées stricts, tels que la fraîcheur, les permissions et l’état du document, doivent être appliqués avant la fusion et non après. La fusion ne doit pas prendre en compte des candidats qui n’ont jamais été autorisés à participer. Certains systèmes en production filtrent après et obtiennent de bons résultats ; il s’agit donc d’une décision architecturale à tester sur son propre corpus, et non d’une règle universelle.
Ici, la séquence n’a pas d’importance esthétique. Le filtrage après fusion élimine de la sortie la page obsolète, mais la page fraîche qui a déjà perdu son vote et qui est tombée en dehors de la limite reste absente. Le filtrage avant fusion modifie l’ensemble des candidats sur lesquels les deux moteurs votent à l’origine.
En pratique, appliquez trois filtres en même temps à l’entrée des deux processus : les permissions de l’utilisateur, le statut du document et une fenêtre de fraîcheur adaptée au domaine. Les deux processus doivent recevoir exactement les mêmes filtres. Sinon, l’un remplit sa liste de candidats de documents que l’autre n’a jamais vus, et la fusion transforme cette asymétrie en avantage de classement.
Un autre avantage pour les langues morphologiquement riches : l’inflection importante entrave la correspondance lexicale. Sans une bonne lemmatisation, BM25 perd une grande partie de son efficacité, car les variantes en cas d’un même mot, comme umowy et umowie en polonais ou Vertrags et Verträgen en allemand, apparaissent comme des tokens complètement différents. C’est un cas rare où c’est la méthode vectorielle qui sauve celle lexicale, et non l’inverse.
Le système hybride corrige donc une catégorie d’erreurs tout en en créant une nouvelle, et rien dans une pile de recherche ne peut être considéré comme fiable par défaut sans vérification.
Que retenir de cela
La baisse de 49 % des recherches infructueuses ne provient ni d’un modèle plus puissant ni d’une plus grande capacité de GPU. Elle résulte du constat qu’une seule représentation de texte ne peut répondre à deux types de requêtes fondamentalement différents.
- BM25 et les vecteurs échouent dans des directions opposées, ce qui constitue la raison structurelle de les combiner.
- RRF fusionne les positions de rang plutôt que les scores, car les échelles de BM25 et de cosinus sont incompatibles et la normalisation ne supprime jamais complètement le coût de calibration.
- La recherche hybride est la méthode par défaut chez les fournisseurs d’infrastructures ; donc ignorer la deuxième étape représente une dette technique et non du conservatisme.
- Le choix par défaut ne signifie pas nécessairement une meilleure performance en général. Pour les requêtes utilisant des identifiants exacts, BM25 seul peut surpasser la fusion, et une métrique moyenne masquera ce fait.
- Appliquez des filtres de métadonnées avant la fusion, sinon l’accord entre les moteurs de recherche fera passer en priorité un document obsolète sur un document plus récent.
Pour la semaine prochaine, prenez les mille dernières requêtes réelles, classez-les en fonction du fait qu’elles contiennent un identifiant exact ou qu’elles sont purement conceptuelles, puis calculez le rapport correspondant. Évaluez ensuite la précision séparément pour chacun des deux groupes et conservez deux lignes de résultats plutôt qu’une moyenne combinée. Ce tableau, bien plus que tout critère de référence fourni par un fournisseur, montre si l’approche hybride améliorera votre système ou ne fera que vous imposer un deuxième index à gérer. Il vous indique également dans quelle mesure votre trafic dépend de chaînes de caractères exactes, ce que très rarement quelqu’un a mesuré.
Lectures complémentaires
- Notes pratiques : Les limites de la recherche vectorielle dans RAG — Similarité cosinus et autres aspects — Guide pas à pas des Notes pratiques : Les limites de la recherche vectorielle dans RAG — Similarité cosinus et autres aspects : contrats, vérifications et espaces de code prêts à l’emploi pour les équipes qui implémentent ce modèle.
- Apache Doris 4.1 : Recherche vectorielle, stockage JSON, OLAP et Lakehouse — Aperçu des nouvelles fonctionnalités d’Apache Doris 4.1 : index vectoriels IVF, fonction de recherche BM25, documents JSON de 100 MB, Segment V3, caches de requêtes, écritures Iceberg, instructions MERGE INTO et TIMESTAMPTZ.