BM25 et recherche hybride : fusionner, puis mesurer le rappel

Documentation vérifiée le 24 octobre 2026. Les conseils de mise en œuvre ci-dessous s’appuient sur la documentation actuelle d’Elasticsearch, de Weaviate et de Pinecone. Les paramètres d’évaluation constituent une proposition de protocole initial : ils ne correspondent ni à des gains mesurés ni à des benchmarks des fournisseurs.

Qu’est-ce que la recherche hybride ?

La recherche hybride tient compte à la fois des mots employés et du sens de la requête pour retrouver les contenus. Dans l’architecture présentée ici, la recherche par mots-clés produit une liste classée, la recherche vectorielle en produit une autre, puis une méthode de fusion les combine. L’explication de Weaviate décrit ces deux branches et leur fusion.

Imaginez deux personnes chargées de répondre à la même question d’assistance. L’une cherche les noms exacts et les messages d’erreur dans un index. L’autre repère les idées proches, y compris dans des réponses formulées autrement. Vous réunissez leurs sélections au lieu de demander à chacune d’effectuer seule les deux tâches.

BM25 est une fonction de classement lexical qui attribue un score aux documents selon les termes de la requête qu’ils contiennent. La fréquence des termes et la longueur du document influencent ce score : il apporte davantage qu’un simple comptage des mots communs. Elasticsearch utilise BM25 comme mesure de similarité textuelle par défaut. La référence d’Elastic sur la similarité détaille ces facteurs.

La recherche vectorielle compare des embeddings, des représentations numériques du contenu, pour repérer des proximités de sens. Elle peut rapprocher « Je suis sans cesse déconnecté » d’un document sur l’expiration des sessions, même si les mots diffèrent. Notre guide de la recherche sémantique explique ce mode de recherche.

Prenons la requête illustrative ERR_SESSION_EXPIRED after login. La branche lexicale permet au message d’erreur exact de figurer dans les résultats. La branche sémantique peut apporter des explications sur les sessions d’authentification et leur renouvellement. La fusion détermine l’ordre final. Cet exemple décrit le comportement recherché ; il ne promet pas qu’un système non configuré produira un classement précis.

Recherche vectorielle hybride : prévoir le traitement des identifiants exacts

Une branche par mots-clés ne garantit pas de retrouver un identifiant à l’identique. L’analyse textuelle, qui transforme les chaînes de caractères en tokens interrogeables, peut modifier ce qui est indexé. L’analyseur standard d’Elastic, par exemple, découpe une expression contenant des traits d’union dans l’exemple de sa documentation. Vérifiez le traitement de vos propres SKU et codes d’erreur par l’analyseur configuré. Documentation de l’analyseur standard.

Conservez les identifiants dans un champ dédié à la correspondance exacte lorsque leur graphie détermine l’élément recherché. Elastic documente son champ keyword pour ce type de valeur structurée. Une recherche sur le SKU fictif AX-BLUE ne doit pas se transformer sans avertissement en recommandation de AX-GREEN au motif que leurs descriptions se ressemblent. Référence du champ keyword.

Règle de décision : lorsqu’un identifiant unique est reconnu, dirigez-le vers une recherche exacte si c’est le comportement attendu du produit. Réservez le classement hybride aux questions qui associent cet identifiant à un besoin plus large, comme la recherche de conseils de dépannage pour l’article concerné.

BM25 et vecteurs : fusion RRF ou scores pondérés ?

Commencez par la fusion réciproque des rangs si vous cherchez une référence initiale sans avoir à calibrer des échelles de scores différentes. Envisagez les scores pondérés lorsque vous disposez d’annotations pour régler l’équilibre et que vous avez intérêt à préserver les écarts entre les scores.

La fusion réciproque des rangs s’appuie sur les positions

La fusion réciproque des rangs, ou RRF, additionne une contribution pour chaque liste dans laquelle un document apparaît :

RRF(document) = somme de 1 / (c + rang) sur les listes de résultats.

Les rangs commencent à la première position. Un document absent d’une liste n’apporte aucune contribution au titre de celle-ci. Gordon V. Cormack, Charles L. A. Clarke et Stefan Büttcher ont présenté RRF dans leur article de SIGIR 2009. Ils ont fixé la constante à 60 pour leurs expériences. L’article scientifique l’appelle k ; nous utilisons ici c pour éviter toute confusion avec le nombre de résultats dans recall@k.

RRF est pratique, car un score BM25 élevé et un score vectoriel élevé n’ont pas besoin d’avoir la même signification. Seules leurs positions comptent. L’implémentation RRF de Pinecone explicite la numérotation des rangs à partir de la première position et le traitement des documents absents.

Une conséquence mérite d’être vérifiée. Dans un exemple construit pour l’illustration, le document A arrive en tête de la liste par mots-clés et n’apparaît pas dans la liste vectorielle. Le document B occupe la deuxième place dans les deux listes. Avec c = 60, A obtient 1/61 et B obtient 2/62. B l’emporte. Ce calcul découle de la formule ; ce n’est pas un benchmark de recherche.

Les scores pondérés conservent les écarts entre résultats

La fusion par scores pondérés combine les scores de pertinence après avoir rendu leurs échelles comparables. Une forme courante est :

score = alpha × score vectoriel normalisé + (1 − alpha) × score par mots-clés normalisé.

Le poids alpha règle l’équilibre. Une valeur initiale de 0.5 attribue des coefficients égaux ; elle ne prouve ni une utilité équivalente ni un réglage optimal. Documentez ensemble la normalisation et la pondération : modifier l’une ou l’autre peut changer le classement.

Le retriever linéaire d’Elasticsearch permet une somme pondérée avec des méthodes de normalisation comme minmax. La fusion par scores relatifs de Weaviate conserve les écarts relatifs au sein de chaque ensemble de résultats, tandis que la fusion par rangs les élimine.

Prenez RRF comme première référence ; ne retenez la fusion pondérée que si les requêtes réservées à l’évaluation la justifient. N’additionnez pas des scores BM25 bruts et des scores de similarité vectorielle en supposant que leur somme a un sens. Consignez aussi le nombre de candidats retenus : changer les résultats qui entrent dans une liste normalisée peut modifier l’étendue de ses scores.

Quand la recherche hybride fait-elle mieux que la recherche vectorielle seule ?

L’hybride est utile lorsque la branche par mots-clés retrouve des contenus pertinents que la branche vectorielle manque, et que la fusion les maintient assez haut dans le classement pour servir. C’est une condition vérifiable, pas une promesse universelle de précision.

Les cas les plus propices à un essai sont les suivants :

• Recherche dans l’assistance : messages d’erreur exacts, noms de fonctions et vocabulaire des comptes mêlés à la description des symptômes.
• Recherche dans un catalogue : noms de produits ou SKU exacts associés à des besoins de compatibilité ou de pièces de rechange.
• Recherche dans les connaissances internes : noms de projets et abréviations associés à des questions en langage naturel.

La présentation de la recherche hybride par Pinecone cite précisément les codes produits, les messages d’erreur et les noms comme signaux lexicaux, en complément de la recherche dense pour le sens.

Pour retrouver uniquement un identifiant, commencez par une recherche exacte fiable. Si la recherche vectorielle répond déjà bien aux besoins de votre corpus et de vos requêtes, attendez d’avoir constaté un problème de récupération avant d’ajouter une branche.

La limite pratique tient à la couverture des candidats. La fusion ne peut classer que l’union des documents retrouvés par ses branches. Si aucune ne trouve le passage pertinent, modifier la fusion ne le fera pas réapparaître. Si le passage est présent avant la fusion, mais absent des résultats finaux, examinez plutôt le classement et la troncature de la liste.

Ajouter la recherche hybride à votre système actuel

Conservez le système en place s’il offre les mécanismes de recherche nécessaires. Changer à la fois de base de données et de stratégie de recherche rend plus difficile l’identification de ce qui a produit le gain.

La distinction ci-dessous porte sur l’endroit où les résultats sont combinés ; elle ne classe pas les fournisseurs.

Recherche hybride avec Elasticsearch

Elasticsearch, un moteur capable de recherche textuelle et vectorielle, permet de réunir un retriever textuel standard et un retriever vectoriel knn sous un retriever rrf. La référence officielle du retriever RRF documente cette organisation et sa fenêtre de candidats.

Dans un index existant, conservez le texte interrogeable et son embedding sous le même identifiant de document. Interrogez les deux branches sur les mêmes contenus admissibles, puis appliquez la fusion. Les restrictions liées au tenant, aux autorisations et à la version du produit doivent rester cohérentes entre les branches.

Voici une requête à exécuter après avoir défini ES_URL et ES_API_KEY. Elle suppose l’existence d’un index docs, d’un champ textuel text, d’un champ de vecteur dense embedding et d’un fichier query-vector.json contenant le véritable tableau d’embedding de la requête. Générez ce tableau avec le modèle utilisé pour les documents indexés. La commande nécessite jq et curl.

jq -n --slurpfile v query-vector.json \
  --arg q 'ERR_SESSION_EXPIRED after login' \
  '{
    size: 10,
    retriever: {
      rrf: {
        retrievers: [
          {standard: {query: {match: {text: $q}}}},
          {knn: {
            field: "embedding",
            query_vector: $v[0],
            k: 50,
            num_candidates: 100
          }}
        ],
        rank_window_size: 50,
        rank_constant: 60
      }
    }
  }' > hybrid-request.json

curl --fail-with-body "$ES_URL/docs/_search" \
  -H "Authorization: ApiKey $ES_API_KEY" \
  -H 'Content-Type: application/json' \
  --data-binary @hybrid-request.json

Ces paramètres servent à illustrer l’évaluation. size indique le nombre final de résultats ; rank_window_size détermine combien de résultats de chaque retriever enfant peuvent participer à la fusion. Avant de reprendre cet exemple sans filtre dans une application soumise à des autorisations, ajoutez les contraintes qui déterminent les contenus admissibles. Elastic documente un filter parent qui s’applique aux retrievers enfants selon leurs spécifications.

Le point de blocage : une fenêtre trop étroite dans une branche peut éliminer précisément le résultat que l’hybride devait récupérer. Comparez les candidats de chaque branche aux résultats finaux avant de régler la fusion. Si vous passez au retriever linéaire, configurez la normalisation en même temps que les poids.

Recherche hybride avec Weaviate

Weaviate, une base de données dotée de fonctions de recherche textuelle et vectorielle, expose la recherche hybride via collection.query.hybrid. Sa composante lexicale est BM25F, la variante qui prend en charge plusieurs champs. La documentation des requêtes hybrides couvre les propriétés interrogeables, le choix de la fusion et l’explication des scores.

Faites pointer query_properties vers les champs qui apportent des indices lexicaux utiles : titres, messages d’erreur ou noms de produits, par exemple. Fournissez le vecteur de la requête si votre application génère les embeddings, ou utilisez la vectorisation configurée pour la collection. Définissez explicitement fusion_type lorsque vous comparez les méthodes de fusion, et demandez explain_score pour comprendre les déplacements d’un résultat dans le classement.

Définissez aussi alpha explicitement : 0 sélectionne la recherche par mots-clés, et 1 la recherche vectorielle. La documentation actuelle prévient que la pondération effective en l’absence de ce paramètre dépend du client. relativeScoreFusion est la méthode de fusion par défaut ; rankedFusion est également disponible. Référence de la fusion dans Weaviate.

Le point de blocage : un poids ne peut pas compenser l’absence d’un champ interrogeable ni réparer un token d’identifiant altéré. Examinez la contribution lexicale avant de conclure qu’il faut remplacer le modèle d’embedding. Utilisez les extrémités de la plage de pondération — recherche vectorielle seule et recherche par mots-clés seule — comme références de diagnostic, puis évaluez leur combinaison.

Recherche hybride avec Pinecone

Pinecone, une base de données dédiée à la recherche, documente plusieurs architectures hybrides distinctes. Choisissez-en une avant de copier un exemple : la combinaison dense/creux côté serveur et la RRF côté client correspondent à des implémentations différentes. Présentation de la recherche hybride dans Pinecone.

Pour associer BM25 et la recherche dense, la voie Documents API exécute une recherche plein texte et une recherche par vecteurs denses, puis fusionne leurs listes ordonnées d’identifiants avec RRF dans votre application. Le guide RRF de Pinecone présente cette implémentation côté client.

Pour une combinaison native de vecteurs denses et creux, la Vectors API peut stocker les deux représentations dans chaque enregistrement et les combiner en une seule requête. Son guide pour un index unique impose vector_type="dense" et metric="dotproduct" ; le client met les vecteurs de requête à l’échelle pour régler leur influence relative.

Un vecteur creux est une représentation, pas la preuve qu’il a été produit par BM25. Précisez le modèle lexical ou la fonction de score plein texte dans votre documentation d’architecture.

Le point de blocage : filtrer par mots-clés, puis classer par recherche dense ne revient pas à faire intervenir les deux signaux dans le classement. Un filtre supprime des candidats ; il ne peut pas récupérer une correspondance par synonyme qu’il a déjà exclue. Utilisez un filtre pour imposer une condition obligatoire, et la fusion lorsque chaque branche doit pouvoir apporter un résultat.

Quel rôle joue la recherche hybride dans le RAG ?

La recherche hybride modifie l’étape de récupération du RAG, ou génération augmentée par la recherche : l’application fournit à un modèle de langage des sources retrouvées avant qu’il ne réponde. Elle ne remplace pas la génération et ne prouve pas que la réponse est correcte.

Gardez la même unité de récupération. Si la branche par mots-clés renvoie des documents entiers et la branche vectorielle des passages, définissez la correspondance entre leurs identifiants avant de fusionner. Sinon, plusieurs passages d’une même source risquent d’occuper la sélection au détriment d’autres sources pertinentes. Notre guide des bases de données vectorielles présente les fondements du stockage et de la recherche.

Le RAG agentique ajoute des décisions sur l’action de recherche à lancer ou sur la nécessité de chercher à nouveau. Un retriever hybride peut faire partie de ces actions. Si un bot d’assistance manque un code d’erreur exact, corrigez et évaluez ce retriever avant d’ajouter davantage d’orchestration.

Conservez le même générateur et le même prompt pendant la comparaison des méthodes de recherche. Si les requêtes à termes exacts progressent, mais que les paraphrases restent mal couvertes, utilisez les mêmes requêtes annotées pour comparer les modèles d’embedding. Modifier simultanément l’embedding, le découpage en fragments et la fusion empêche d’attribuer le résultat à une cause précise.

Mesurer le rappel@k avant et après

Utilisez un petit jeu de requêtes annotées et comparez la recherche par mots-clés seule, la recherche vectorielle seule et la recherche hybride face aux mêmes réponses attendues. Une réponse générée fluide n’est pas une mesure de qualité de la recherche.

Rappel@k = nombre d’identifiants pertinents retrouvés parmi les k premiers résultats ÷ nombre total d’identifiants annotés comme pertinents pour cette requête. Faites la moyenne des valeurs par requête pour obtenir le rappel@k macro. Si les annotations sont incomplètes, présentez le résultat comme un rappel calculé sur les jugements de pertinence connus : il ne mesure pas le rappel sur l’ensemble des éléments pertinents du corpus.

Exécuter le script local d’évaluation du rappel

Enregistrez le code suivant dans evaluate_recall.py. Il utilise uniquement la bibliothèque standard de Python 3. qrels.jsonl contient un objet JSON par requête, avec les champs qid, slice et relevant. Chaque fichier de résultats associe un identifiant de requête à la liste ordonnée des identifiants renvoyés.

Par exemple, une annotation pourrait être {"qid":"q-exact","slice":"exact","relevant":["guide-login"]}. Un fichier de résultats pourrait contenir {"q-exact":["guide-reset","guide-login"]}. Ces exemples illustrent le format ; ils ne proviennent pas des résultats d’un système testé. Faites figurer chaque requête annotée dans chaque fichier de résultats, avec une liste vide lorsque la recherche n’a rien renvoyé.

import json
import sys
from collections import defaultdict
from statistics import mean

qrels_path, bm25_path, vector_path, hybrid_path, cutoff = sys.argv[1:]
k = int(cutoff)
if k < 1:
    raise ValueError("k must be positive")

with open(qrels_path, encoding="utf-8") as f:
    labels = [json.loads(line) for line in f if line.strip()]
if not labels or len({r["qid"] for r in labels}) != len(labels):
    raise ValueError("Labels must be nonempty with unique query IDs")

runs = {}
for name, path in (("bm25", bm25_path), ("vector", vector_path),
                   ("hybrid", hybrid_path)):
    with open(path, encoding="utf-8") as f:
        runs[name] = json.load(f)
    missing = {r["qid"] for r in labels} - runs[name].keys()
    if missing:
        raise ValueError(f"{name} is missing query IDs: {sorted(missing)}")

groups = defaultdict(list)
skipped = 0
for row in labels:
    relevant = set(row["relevant"])
    if not relevant:
        skipped += 1
        continue
    scores = {}
    for name, run in runs.items():
        unique_ids = list(dict.fromkeys(run[row["qid"]]))
        scores[name] = len(relevant & set(unique_ids[:k])) / len(relevant)
    groups["overall"].append(scores)
    groups["slice:" + row["slice"]].append(scores)

if not groups:
    raise ValueError("No answerable queries to score")
for group, rows in sorted(groups.items()):
    values = {name: mean(r[name] for r in rows) for name in runs}
    delta = values["hybrid"] - values["vector"]
    report = " ".join(f"{name}={v:.3f}" for name, v in values.items())
    print(f"{group} n={len(rows)} recall@{k} {report} delta={delta:+.3f}")
print(f"Excluded no-answer queries: {skipped}")

Exécutez le script sur les annotations et les exports du jeu réservé à l’évaluation :

python3 evaluate_recall.py qrels.jsonl bm25.json vector.json hybrid.json 10

Le script supprime les identifiants en double avant de limiter le nombre de résultats. Appliquez la même règle de déduplication dans l’application. Il indique l’évolution de la recherche hybride par rapport à la recherche vectorielle et affiche aussi la référence par mots-clés, pour qu’un bon système lexical ne disparaisse pas de la comparaison.

Déployez lorsque les catégories de requêtes concernées progressent et que les régressions restent acceptables au regard des exigences du produit. Si les candidats s’améliorent sans gain de rappel final, ajustez la fusion ou le nombre de résultats retenus. Si le rappel final progresse, examinez séparément l’ordre des résultats, la justesse des réponses générées et la latence de bout en bout. Le rappel ne mesure aucun de ces aspects.

Les promesses à relativiser et les prochaines étapes

« L’hybride offre le meilleur des deux mondes » masque le choix d’ingénierie. Cette approche peut élargir la couverture utile, mais elle donne aussi à une autre branche de recherche une influence sur la liste finale. RRF peut faire reculer une correspondance exacte ; la fusion pondérée peut favoriser une échelle de scores ou une normalisation qui se comporte différemment. Aucune des deux ne compense l’absence de contenu source.

Les équipes de développement ont intérêt à agir maintenant si l’analyse révèle que des documents pertinents contenant les termes exacts sont absents des candidats vectoriels. Ajoutez la branche lexicale, assurez la cohérence des identifiants de documents et des autorisations, puis lancez la comparaison sur les requêtes annotées.

Les équipes d’exploitation doivent attendre avant de déployer si le problème actuel vient de contenus obsolètes, d’autorisations manquantes ou de l’absence d’annotations de pertinence. Réglez ces prérequis, puis comparez les stratégies de recherche.

Les équipes qui disposent d’une recherche fiable par identifiant ne sont pas concernées tant qu’elles n’ont pas besoin d’une recherche plus large. Conservez ce parcours fiable et évaluez séparément l’hybride pour les questions en langage naturel.

Dès lundi : rassemblez les recherches qui échouent, annotez les sources attendues et comparez le retriever vectoriel existant à une référence par mots-clés. Ajoutez la fusion une fois la contribution de chaque branche visible. Gardez la configuration qui fait ses preuves sur les requêtes réservées à l’évaluation.

Questions fréquentes

Recevez des guides pratiques de développement dans la newsletter.