Recherche hybride : BM25 vs vectoriel (et pourquoi il vous faut les deux)

Recherche hybride : BM25 vs vectoriel (et pourquoi il vous faut les deux)

Un agent de support saisit « SKU-4471 » dans votre chatbot RAG. Quatre résultats remontent. Tous faux, et tous avec une belle assurance. Un modèle d'embedding généraliste n'a aucune raison de placer cette chaîne exacte près d'elle-même dans l'espace vectoriel. Ce cas d'échec à lui seul explique l'existence de la recherche hybride, et c'est pourquoi les équipes posent toutes la même question : comment combiner concrètement BM25 et recherche vectorielle sans passer sa vie à régler un curseur ?

Si vous évaluez plus largement l'outillage RAG, notre comparatif des meilleurs outils RAG couvre l'ensemble de la pile.

Points clés à retenir

• BM25 trouve les correspondances exactes de mots-clés (SKU, codes d'erreur) ; la recherche vectorielle trouve du texte conceptuellement similaire, pas des chaînes identiques.
• La recherche hybride combine les deux, le plus souvent via le Reciprocal Rank Fusion (RRF), et surpasse chaque méthode seule sur des requêtes mixtes.
• Sur le benchmark WANDS, le RRF simple atteint 0,7068 de NDCG (contre 0,6983 pour BM25) ; avec du tuning, il monte à 0,7497, soit +7,4 %.
• Postgres/pgvector peut faire de la recherche hybride en natif via ts_rank + pgvector, sans base de données vectorielle dédiée.

Qu'est-ce que la recherche hybride ? (BM25 + vectoriel combinés)

La recherche hybride exécute BM25 et la recherche vectorielle comme deux passes de retrieval distinctes sur la même requête, puis fusionne les deux listes de résultats classées en une seule sortie à l'aide d'un algorithme de fusion, le plus souvent le Reciprocal Rank Fusion. Ce n'est pas une troisième méthode de retrieval ; c'est une couche d'orchestration posée sur deux méthodes existantes.

Cette distinction compte, car une bonne partie du trafic de recherche autour de ce sujet confond BM25 et recherche vectorielle comme s'il s'agissait de la même chose. Ce n'est pas le cas. BM25 est une fonction de scoring creuse (sparse), fondée sur les mots-clés, qui plonge ses racines dans la recherche d'information des années 1970. La recherche vectorielle est une recherche de similarité dense, fondée sur des embeddings, qui n'est devenue pratique à grande échelle que depuis la dernière décennie. La recherche hybride les traite comme des entrées complémentaires, non comme des techniques concurrentes, et fusionne leurs sorties au lieu de choisir un gagnant à l'avance.

BM25 vs vectoriel vs hybride : comparatif rapide

Sur le benchmark e-commerce WANDS, BM25 seul score 0,6983 de NDCG et la recherche vectorielle seule 0,6953 (quasi à égalité). La fusion RRF simple, sans tuning par corpus, atteint 0,7068, soit un gain modeste de 1,2 % sur BM25 seul. Le benchmark de Doug Turnbull teste aussi une variante optimisée qui ajoute un boost sur les noms de produits au-dessus du RRF, et cette version atteint 0,7497, soit +7,4 %. Soyons honnêtes sur le chiffre que vous citez : le RRF seul vous donne un avantage faible mais réel dès l'installation ; le chiffre de 7,4 % exige un tuning métier supplémentaire que la plupart des équipes sautent le premier jour. Ni BM25 ni la recherche vectorielle ne domine seul ; ils couvrent des modes d'échec différents, et les fusionner ferme les deux brèches d'un coup.

Mécanique de BM25 : comment la recherche par mots-clés score la pertinence

BM25 score les documents selon la fréquence des termes, pondérée par la rareté de chaque terme sur l'ensemble du corpus, puis normalisée par la longueur du document. Robertson et Zaragoza ont posé cette formalisation dans leur article de 2009, « The Probabilistic Relevance Framework: BM25 and Beyond ». C'est un raffinement du TF-IDF, pas un remplaçant.

Deux paramètres contrôlent l'essentiel du comportement de BM25. k1 (typiquement 1,2-2,0) contrôle la saturation de la fréquence de terme : il plafonne l'effet de la répétition d'un mot sur le score, pour qu'un document qui dit « facture » 40 fois ne passe pas automatiquement devant un passage plus court et plus pertinent qui le dit 4 fois. b (0,75 par défaut) contrôle la normalisation par la longueur du document : il décide de la sévérité avec laquelle BM25 pénalise les documents longs, qui contiennent naturellement plus de correspondances.

Se tromper sur b est une erreur de tuning réelle et fréquente. Les documents techniques courts (logs d'erreurs, titres de produits) demandent un b plus faible, car la variance de longueur est mince ; les contenus longs (pages de documentation, articles) veulent en général un b proche de la valeur par défaut. La faiblesse centrale de BM25 est l'inadéquation de vocabulaire : si un utilisateur demande « comment récupérer mon argent » et que le document dit seulement « politique de remboursement », BM25 ne trouve aucun token commun et ne renvoie rien d'utile.

Mécanique de la recherche vectorielle dense (et ses angles morts)

La recherche vectorielle projette le texte dans des embeddings de dimension fixe à l'aide d'un modèle, puis trouve les vecteurs proches par similarité cosinus ou produit scalaire, le tout accéléré par un index de plus proches voisins approchés. HNSW est l'algorithme dominant chez Weaviate, Qdrant et Milvus : il échange un peu de rappel contre des gains de vitesse majeurs à grande échelle.

C'est ce qui règle le problème d'inadéquation de vocabulaire de BM25 : « récupérer mon argent » et « politique de remboursement » atterrissent proches dans l'espace d'embedding même avec zéro token commun, car le modèle capture le sens, pas la forme de surface. Le choix du modèle compte énormément ici. Voyez notre guide pour choisir le bon modèle d'embedding, et notre comparaison des embeddings Voyage, OpenAI et Cohere si vous pesez les options.

Mais le retrieval dense a son propre angle mort, et c'est l'image miroir de celui de BM25. Quand nous construisons des systèmes RAG pour des clients, l'échec sur correspondance exacte que nous rencontrons le plus souvent n'a rien d'exotique. C'est un agent de support qui demande un numéro de commande ou un SKU précis, et l'index vectoriel qui renvoie avec assurance quelque chose de sémantiquement proche mais faux. Un modèle d'embedding généraliste n'a aucune raison de placer « SKU-4471 » ou « ERR_CONN_RST » près de lui-même dans l'espace vectoriel plutôt qu'à côté d'un token apparenté mais erroné, car de telles chaînes apparaissent rarement comme des concepts distincts et isolés dans les données d'entraînement. BigData Boutique documente exactement ce motif d'échec avec ses propres exemples de SKU et de codes d'erreur. C'est un phénomène établi et corroboré de façon indépendante à travers les déploiements RAG, pas une bizarrerie isolée.

Comment combiner BM25 et recherche vectorielle : RRF vs fusion pondérée par alpha

Il existe deux vraies façons de fusionner les résultats BM25 et vectoriels, et presque personne parmi ceux qui écrivent sur la recherche hybride ne les contraste clairement. Le Reciprocal Rank Fusion (RRF), issu de l'article SIGIR 2009 de Cormack, Clarke et Buettcher, travaille sur les rangs : score = somme(1 / (k + rang_i)) sur chaque liste de résultats, avec k typiquement fixé à 60. Comme il ne s'intéresse qu'à la position, pas au score brut, le RRF encaisse sans broncher les différences d'échelle entre les scores non bornés de BM25 et l'intervalle 0-1 de la similarité cosinus, et il n'a besoin d'aucun tuning par corpus.

La fusion pondérée par alpha (convexe) fonctionne autrement : final = alpha * score_dense + (1 - alpha) * score_sparse, et travaille sur des scores normalisés plutôt que sur des rangs. Elle peut mieux refléter l'amplitude de la confiance (un hit vectoriel à 0,95 de similarité paraît vraiment plus fort qu'un hit à 0,61), mais elle impose de régler alpha pour chaque corpus, et ce réglage casse en silence quand vos distributions de scores bougent (nouveau modèle d'embedding, corpus réindexé, mix de requêtes différent).

En pratique, le choix dépend de la confiance que vous accordez à votre calibration de scores. Avec un BM25 standard face à un modèle d'embedding unique et stable, la pondération par alpha peut gratter un classement légèrement meilleur, car elle utilise l'écart réel de scores, pas seulement la position. Mais cette calibration dérive plus qu'on ne le croit. Changez de version de modèle d'embedding, redécoupez vos documents, ou ajoutez une passe de reranking en amont, et la distribution de vos scores denses bouge. Personne n'est réveillé à 3 h du matin quand alpha=0,6 cesse d'être la bonne valeur ; le classement se dégrade juste un peu, sans bruit, et c'est facile à rater si vous ne lancez pas d'évals de retrieval régulièrement. Le RRF évite entièrement le problème, car il ne regarde jamais les scores bruts, seulement la position dans le classement : une réindexation ou un changement de modèle ne peut pas le casser en silence comme il peut casser la pondération par alpha.

Le RRF n'a besoin d'aucun tuning par corpus ; la pondération par alpha demande une surveillance constante à mesure que vos données changent.

Les moteurs divergent sur les valeurs par défaut. Weaviate expose à la fois le RRF et un paramètre alpha que vous fixez explicitement. Elasticsearch fournit un RRF natif via son API retriever (vérifiez le versioning exact dans votre déploiement ; c'est arrivé dans la branche 8.x). Qdrant prend en charge le RRF en natif via son Query API. La fonctionnalité hybride de Pinecone s'appuie en général sur une combinaison convexe pondérée par alpha plutôt que d'exposer directement le RRF. Si vous hésitez, partez du RRF. C'est le choix le moins gourmand en maintenance.

RRF en partant de zéro : un exemple Python sans vendor

Tous les exemples de code RRF que nous avons trouvés dans les guides concurrents sont verrouillés sur le SDK d'un vendor : client Weaviate, client Qdrant, client Pinecone. Voici une version sans framework, à poser dans n'importe quelle pile, avec k=60 comme valeur standard :

def reciprocal_rank_fusion(result_lists, k=60):
    """
    result_lists: list of ranked lists, each a list of document IDs
                  ordered from most to least relevant.
    k: RRF constant (60 is the standard default from Cormack et al., 2009).
    Returns: list of (doc_id, fused_score) sorted descending by score.
    """
    scores = {}
    for result_list in result_lists:
        for rank, doc_id in enumerate(result_list, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda item: item[1], reverse=True)

# Example usage:
bm25_hits = ["doc_9", "doc_2", "doc_14", "doc_1"]
vector_hits = ["doc_2", "doc_1", "doc_9", "doc_30"]

fused = reciprocal_rank_fusion([bm25_hits, vector_hits])
for doc_id, score in fused:
    print(f"{doc_id}: {score:.4f}")

Voilà tout l'algorithme. Pas de SDK, pas de verrouillage vendor, et il fonctionne que vos deux listes classées viennent d'Elasticsearch et d'un index Faiss, ou de Postgres ts_rank et de pgvector. Si vous faites tourner les modèles vous-même plutôt que de passer par une API, voyez notre guide pour exécuter des modèles d'embedding en local avec Ollama.

Postgres + pgvector : la recherche hybride sans base vectorielle dédiée

Vous n'avez pas besoin d'une base de données vectorielle dédiée pour faire de la recherche hybride. D'après un benchmark pg_textsearch/pgvector du développeur Pedro Alonso (Postgres 17, pg_textsearch 1.3.0, pgvector 0.8.2, embeddings nomic-embed-text, dataset BEIR SciFact), une seule instance Postgres avec le ts_rank natif score seulement 0,07 de NDCG@10, très loin derrière les 0,69 de BM25, les 0,66 de pgvector et les 0,70 de l'hybride, le tout dans une seule instance, avec un RRF hybride autour de 11,5 ms de latence médiane.

Ce chiffre de 0,07 est révélateur : le ts_rank intégré à Postgres est un classeur basé sur la densité de couverture (cover-density), pas un vrai BM25. Si vous voulez un vrai scoring BM25 dans Postgres, il vous faut une extension. pg_textsearch, VectorChord et ParadeDB ajoutent tous un classement de type BM25 correct que le ts_rank natif ne fournit pas. Associez l'une d'elles à pgvector pour la similarité dense, fusionnez les deux listes classées avec la fonction RRF ci-dessus, et vous obtenez une recherche hybride dans une seule instance Postgres, sans infrastructure distincte à faire tourner.

Voici à peu près à quoi ressemble cet appariement dans une seule requête, combinant un rang lexical issu d'une extension compatible BM25 avec une distance vectorielle de pgvector :

WITH lexical AS (
  SELECT id, ts_rank_cd(body_tsv, query) AS rank
  FROM documents, plainto_tsquery('english', 'refund policy') query
  WHERE body_tsv @@ query
  ORDER BY rank DESC LIMIT 50
),
semantic AS (
  SELECT id, embedding <=> '[0.012, -0.045, ...]' AS distance
  FROM documents
  ORDER BY distance LIMIT 50
)
SELECT * FROM lexical
FULL OUTER JOIN semantic USING (id);

Envoyez les deux jeux de résultats dans la fonction RRF ci-dessus et vous avez une recherche hybride dans une instance Postgres. La limite honnête : cela tient bien la route jusqu'à quelques millions de lignes, mais Postgres n'a pas été construit comme un moteur de retrieval dédié. Vous gérez vous-même le tuning de vos index, le simple ts_rank_cd n'est toujours pas un vrai BM25 sans extension, et vous n'avez ni le reranking intégré ni le support multi-vecteurs que Weaviate ou Milvus livrent en natif. Si votre corpus est petit ou moyen et que vous faites déjà tourner Postgres, vous vous épargnez une deuxième infrastructure entière. Au-delà de plusieurs dizaines de millions de documents, ou si vous avez besoin d'un reranking avancé, un moteur dédié rentabilise son coût.

Si vous comparez Qdrant, Chroma ou pgvector pour votre pile plus largement, c'est une décision distincte de la méthode de fusion elle-même. Voyez notre comparaison de Qdrant, Chroma et pgvector pour les arbitrages.

Quelles bases vectorielles proposent une recherche hybride native ?

La plupart des bases vectorielles modernes livrent désormais la recherche hybride d'entrée de jeu, mais la méthode de fusion par défaut diffère sensiblement.

Vérifiez le versioning exact avant de vous engager. Les fonctionnalités hybrides arrivent vite sur ces moteurs tout au long de 2026, et la forme des API change d'une release à l'autre. Pour une décision d'achat plus large que la mécanique de fusion, voyez notre comparatif complet des meilleures bases de données vectorielles.

La recherche hybride vaut-elle sa complexité ?

La recherche hybride est architecturalement juste quand votre corpus présente à la fois des motifs à correspondance exacte (SKU, identifiants, termes rares) et des requêtes conceptuelles reformulées. Si votre corpus n'a ni l'un ni l'autre (contenu purement narratif, aucun identifiant que quiconque cherche par chaîne littérale), vous ajouterez peut-être de la complexité de fusion pour un gain à peine perceptible.

Imaginez ce qu'un corpus « narratif uniquement » veut dire concrètement : les archives d'un blog d'entreprise, un wiki d'ingénierie interne rempli de runbooks bavards, un site de documentation que personne ne cherche par identifiant produit ou numéro de ticket. Sur ces corpus, la recherche vectorielle seule vous donne en général l'essentiel de la valeur, et l'étape de fusion ajoute juste une deuxième passe de retrieval et un paramètre dont quelqu'un hérite, pour un gain qui se confond avec le bruit. Comparez avec un système de tickets de support ou un catalogue e-commerce, où SKU, numéros de commande et codes de modèle apparaissent en permanence dans les requêtes réelles. Voilà le vrai test : extrayez dix requêtes réelles de vos logs et comptez combien contiennent un identifiant exact qu'un modèle d'embedding fonctionnant à la paraphrase ne placera jamais correctement. Zéro ? Laissez tomber l'hybride. Plus d'une ou deux ? Construisez-le.

La recherche hybride n'est pas une mise à niveau universelle : si votre corpus ne contient ni SKU, ni identifiants, ni recherches de termes rares, vous ajoutez peut-être de la complexité de fusion pour un gain que vous ne verrez jamais.

Le coût est réel mais borné : une deuxième passe de retrieval, une étape de fusion et un paramètre de pondération dont quelqu'un hérite. Nous ne citons volontairement aucun chiffre de latence ici, car ceux qui circulent proviennent de configurations anonymes sur du matériel anonyme, et la vôtre différera. Mesurez sur votre propre corpus avant de décider. Deux fils Hacker News capturent bien la tension réelle des praticiens : « Hybrid Search Is Just the Beginning: Optimizing the R in RAG » et « Better RAG Results with Reciprocal Rank Fusion and Hybrid Search ». Les deux fils poussent à ne pas adopter l'hybride comme une bonne pratique cargo-cult sans avoir d'abord vérifié que votre corpus présente bien les motifs de requêtes qu'il est censé résoudre. Avant de le construire, il vaut la peine de comprendre comment mesurer réellement la qualité du retrieval : les chiffres de NDCG et de rappel@k n'ont de sens que face à votre propre corpus, pas face à un dataset de benchmark.

Notre position : par défaut, passez à l'hybride pour tout système RAG qui traite du support utilisateur, de l'e-commerce ou de la gestion de tickets. Ces charges mélangent presque toujours identifiants et langage naturel. Sautez-le pour les corpus purement narratifs (documentation longue, wikis rédactionnels) tant que vous n'avez pas mesuré un écart réel que le retrieval à méthode unique laisse ouvert.

Questions fréquemment posées

Qu'est-ce que la recherche hybride dans le RAG ?

La recherche hybride exécute le retrieval BM25 (mots-clés) et vectoriel (sémantique) comme deux passes distinctes sur la même requête, puis fusionne les deux listes classées avec un algorithme de fusion, en général le Reciprocal Rank Fusion. Elle attrape à la fois les requêtes à correspondance exacte et les requêtes conceptuelles reformulées, qu'aucune des deux méthodes ne traite seule.

BM25 est-il identique à la recherche vectorielle ?

Non. BM25 est une recherche lexicale creuse qui score le chevauchement exact et la rareté des termes. La recherche vectorielle est une recherche sémantique dense qui utilise des embeddings et des calculs de similarité. Ce sont deux méthodes de retrieval aux forces opposées ; la recherche hybride les combine au lieu de remplacer l'une ou l'autre.

Comment combiner BM25 et la recherche vectorielle ?

Exécutez les deux méthodes de retrieval indépendamment sur la même requête, puis fusionnez les deux listes de résultats classées, le plus souvent avec le Reciprocal Rank Fusion, qui somme 1 / (k + rang) sur chaque liste. La combinaison de scores pondérée par alpha est l'alternative, mais elle exige un tuning par corpus dont le RRF se passe.

Qu'est-ce que le Reciprocal Rank Fusion (RRF) ?

Le RRF est un algorithme de fusion issu de l'article SIGIR 2009 de Cormack, Clarke et Buettcher, qui combine plusieurs listes classées en sommant 1 / (k + rang) pour chaque document, avec k typiquement fixé à 60. Il travaille sur la position dans le classement, pas sur les scores bruts, et reste donc stable malgré les différences d'échelle entre méthodes de retrieval.

Quelle différence entre RRF et fusion pondérée par alpha ?

Le RRF combine des rangs et n'a besoin d'aucun tuning par corpus. La fusion pondérée par alpha combine des scores normalisés via un paramètre alpha réglable, ce qui peut mieux refléter l'amplitude de la confiance mais impose de recalibrer en continu dès que les distributions de scores bougent, par exemple après une réindexation ou un changement de modèle.

Quand utiliser la recherche hybride plutôt que la recherche vectorielle seule ?

Utilisez la recherche hybride quand vos requêtes mélangent des identifiants exacts (SKU, numéros de commande, codes d'erreur) et des questions conceptuelles en langage naturel : le support, l'e-commerce et les systèmes de tickets le font en général. Passez votre chemin pour les contenus purement narratifs sans identifiants, où la complexité de fusion ajoutée ne produira probablement aucun gain mesurable.

Pourquoi la recherche vectorielle rate-t-elle les correspondances exactes comme les SKU ou les codes d'erreur ?

Les modèles d'embedding apprennent à partir de motifs généraux du langage, et des chaînes comme « SKU-4471 » ou « ERR_CONN_RST » apparaissent rarement comme des concepts distincts et isolés dans les données d'entraînement. Le modèle n'a aucune raison forte de placer cette chaîne exacte plus près de lui-même qu'à côté d'un token sémantiquement apparenté mais faux.

Quelles bases vectorielles prennent en charge la recherche hybride en natif ?

Weaviate, Qdrant, Elasticsearch, OpenSearch, Vespa et Milvus livrent tous une recherche hybride native en 2026, même si leurs méthodes de fusion par défaut diffèrent (RRF vs pondération par alpha vs normalisation). Postgres avec pgvector peut aussi faire de la recherche hybride, mais il lui faut une extension BM25, car le ts_rank natif n'est pas un vrai BM25.

La recherche hybride vaut-elle la complexité supplémentaire ?

Pour les corpus qui mélangent requêtes à correspondance exacte et requêtes conceptuelles, oui. Le RRF simple bat déjà chaque méthode seule sur le benchmark WANDS (0,7068 contre 0,6983 pour BM25), et une variante optimisée atteint +7,4 % (0,7497). Pour les corpus purement narratifs sans identifiants, la deuxième passe de retrieval et le tuning de fusion qu'elle exige peuvent peser plus lourd qu'un gain que vous ne remarquerez pas. Mesurez avant de vous engager.

Postgres/pgvector peut-il faire de la recherche hybride sans base vectorielle dédiée ?

Oui. Associez pgvector pour la similarité dense à une vraie extension BM25 comme pg_textsearch, VectorChord ou ParadeDB (le ts_rank natif seul score seulement 0,07 de NDCG@10 dans le benchmark pg_textsearch/pgvector de Pedro Alonso, contre 0,70 pour l'hybride), puis fusionnez les deux listes classées avec le RRF, le tout dans une seule instance Postgres.

Les deux méthodes de retrieval laissent de vrais trous quand elles tournent seules : BM25 rate la paraphrase, la recherche vectorielle rate les identifiants exacts, et les fusionner avec le RRF est la façon la moins gourmande en maintenance de boucher les deux. Si vous pesez entre construire cela vous-même ou faire appel à une équipe qui a déjà livré du retrieval RAG, notre guide complet pour créer une application RAG couvre l'étape suivante, ou contactez-nous si vous préférez que Techsy le construise avec vous.