Recherche hybride avec OpenSearch : combiner BM25 et vectoriel pour de meilleurs résultats RAG
Une grande partie de la qualité d’un système RAG ne se joue pas dans le modèle de langage, mais en amont, au moment de retrouver les bons passages. Or les deux grandes familles de recherche ont chacune un angle mort. La recherche lexicale classique, type BM25, excelle sur les termes exacts, les références, les codes produit ou les noms propres, mais échoue dès que la question est formulée autrement que le document. La recherche vectorielle, elle, capte le sens et les reformulations, mais peut passer à côté d’un mot-clé précis ou d’un acronyme rare. La recherche hybride consiste à faire tourner les deux en parallèle et à fusionner leurs résultats. OpenSearch, fork open source d’Elasticsearch sous licence Apache 2.0, intègre nativement cette mécanique.
Pourquoi combiner les deux approches
L’idée est simple : les forces de l’une compensent les faiblesses de l’autre. Sur une requête comme « procédure de remboursement formulaire CERFA 14011 », BM25 va verrouiller le numéro exact du formulaire, là où le vectoriel risque de le diluer. À l’inverse, sur « comment annuler mon abonnement », le vectoriel rapprochera la question d’un document intitulé « résiliation de contrat » même sans mot commun, là où BM25 ne trouvera rien. En production, un système hybride est presque toujours plus robuste qu’un système purement vectoriel, surtout sur des corpus techniques riches en jargon, en codes et en références.
Les briques d’OpenSearch
OpenSearch réunit dans un même moteur ce qui demande souvent plusieurs outils ailleurs :
- Recherche lexicale BM25 : l’indexation plein texte historique, mature et rapide, avec gestion des analyseurs linguistiques, des synonymes et du stemming.
- Recherche vectorielle k-NN : un champ de type knn_vector stocke les embeddings et les indexe avec des algorithmes de voisinage approché comme HNSW, pour une recherche sémantique à grande échelle.
- Pipeline de recherche hybride : un objet de configuration qui normalise puis combine les scores des deux requêtes en une liste unique de résultats.
- Ingest pipelines : la possibilité de générer les embeddings au moment de l’indexation via un modèle hébergé, pour ne pas avoir à les calculer côté application.
Le point délicat : fusionner deux scores qui n’ont pas la même échelle
Un score BM25 et une distance vectorielle ne vivent pas dans le même monde : ni la même plage de valeurs, ni la même signification. Les additionner brutalement n’a aucun sens. Deux stratégies dominent pour les réconcilier.
La première est la normalisation puis combinaison : OpenSearch ramène les scores de chaque requête sur une échelle commune, par exemple entre 0 et 1, puis les agrège selon une pondération choisie, souvent une moyenne arithmétique ou géométrique. On peut ainsi donner plus de poids au lexical ou au sémantique selon la nature du corpus.
La seconde est la fusion par rang réciproque (Reciprocal Rank Fusion, ou RRF) : plutôt que de comparer les scores, on ne regarde que la position de chaque document dans chaque liste de résultats. Un document bien classé par les deux méthodes remonte fortement. L’avantage de RRF est de s’affranchir totalement des échelles de score, ce qui la rend très stable et peu sensible au réglage. C’est souvent un excellent point de départ.
Une chaîne RAG type avec OpenSearch
Dans une architecture concrète, OpenSearch occupe la place du moteur de retrieval, en amont du modèle de langage :
- Indexation : les documents sont découpés en passages, chaque passage est indexé à la fois en texte brut pour BM25 et sous forme d’embedding pour le k-NN.
- Interrogation : à chaque question, une requête hybride interroge simultanément les deux index et le pipeline fusionne les résultats.
- Affinage : les meilleurs passages peuvent passer par un reranker, un cross-encoder qui réordonne finement la sélection avant de la transmettre au modèle.
- Génération : les passages retenus alimentent le contexte du LLM, qu’il soit auto-hébergé ou distant.
Cette chaîne reste entièrement composée de briques ouvertes et auto-hébergeables, dans la continuité des approches déjà décrites sur ce site pour l’inférence locale et les pipelines RAG.
Points de vigilance
- Cohérence des embeddings : le modèle qui génère les vecteurs à l’indexation doit être strictement le même qu’à l’interrogation. Changer de modèle impose de réindexer tout le corpus.
- Réglage de la pondération : le bon équilibre lexical / sémantique dépend du corpus. Il se mesure sur un jeu de questions de référence, pas à l’intuition.
- Ressources : l’index vectoriel HNSW consomme de la mémoire vive. Le dimensionnement doit anticiper le volume de passages et la taille des embeddings.
- Évaluation : sans mesure objective de la pertinence, par exemple via un outil d’évaluation de RAG, il est impossible de savoir si l’hybride améliore réellement les réponses.
Pourquoi ce sujet a sa place ici
On a déjà couvert les bases vectorielles dédiées et les rerankers comme second étage de précision. La recherche hybride complète ce tableau par l’étage le plus structurant : la qualité du premier retrieval. OpenSearch a le mérite de réunir lexical et vectoriel dans un seul moteur open source mature, ce qui simplifie l’architecture tout en gardant la maîtrise complète des données et de l’infrastructure.
