Recherche hybride : BM25 + vectoriel

#Le problème du pur vectoriel

Noms propres et identifiants

"Dupont contre Martin", "SKU ABC-1234", "RG/2024-117". L'embedding les traite comme du bruit. Pourtant ce sont souvent les termes exacts que vous cherchez.

Vocabulaire de domaine rare

Médical, juridique, technique : les termes spécifiques ont des embeddings fragiles parce que peu représentés dans les corpus d'entraînement.

Requêtes très courtes

"facture 2024" — trop peu de signal pour un embedding. BM25 gère nativement.

#BM25, le retour

BM25 est un algorithme de ranking lexical inventé dans les années 80, qui équipe Elasticsearch, Lucene, SQLite FTS5, Postgres via pg_trgm. Il mesure la correspondance exacte entre termes, pondérée par TF-IDF.

Forces

Termes rares (+poids), requêtes courtes, identifiants exacts, vocabulaire de domaine.

Faiblesses

Synonymes ("voiture" ≠ "automobile"), reformulations ("CDD" ≠ "contrat à durée déterminée"), paraphrases.

Pré-requis

Tokenisation + normalisation (minuscules, accents, stemming). Pas de modèle à entraîner.

#L'hybride : le meilleur des deux

On exécute les deux en parallèle — BM25 et embedding — sur la même requête, chacun produit son top-20. On fusionne les deux listes pour obtenir un top-20 hybride, souvent meilleur que chacun séparément.

#RRF : fusionner sans trafiquer

Le piège classique : normaliser les scores de BM25 et du vectoriel pour les additionner. Ça ne marche pas — les échelles sont incomparables. La méthode qui marche : Reciprocal Rank Fusion.

RRF_score(doc) = Σ  1 / (k + rank_i(doc))
                 i

  k = 60 (constante magique, robuste empiriquement)
  rank_i = rang du doc dans la liste i (1 si premier, 2 si deuxième...)

Le doc n'est dans une liste ? Son apport = 0.

#Stack pratique

Qdrant 1.10+

Supporte la recherche hybride native avec RRF. Un seul appel API.

Weaviate

Recherche hybride native, pondération alpha réglable entre lexical et vectoriel.

Elasticsearch 8.x

kNN + BM25 combinés via RRF. Plus lourd à déployer mais très complet.

ChromaDB + rank_bm25

Recherche vectorielle via Chroma, BM25 via la lib Python rank_bm25, fusion manuelle en Python. Solution DIY.

#Implémentation custom (ChromaDB + rank_bm25)

from rank_bm25 import BM25Okapi
import chromadb, unicodedata, re

def normalize(txt):
    txt = unicodedata.normalize("NFKD", txt.lower())
    return re.sub(r"[^a-z0-9\s]", " ", txt).split()

# Indexation BM25 (en mémoire)
all_docs = [d["text"] for d in load_docs()]
bm25 = BM25Okapi([normalize(d) for d in all_docs])

# ChromaDB (vectoriel)
client = chromadb.PersistentClient("./chroma_db")
coll = client.get_collection("docs")

def rrf_fuse(rankings, k=60):
    scores = {}
    for ranking in rankings:
        for rank, doc_id in enumerate(ranking, start=1):
            scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank)
    return sorted(scores, key=scores.get, reverse=True)

def hybrid_search(question, top_k=5):
    # BM25
    bm25_scores = bm25.get_scores(normalize(question))
    bm25_top = sorted(range(len(all_docs)), key=lambda i: -bm25_scores[i])[:20]
    bm25_ranking = [str(i) for i in bm25_top]

    # Vectoriel
    vec_res = coll.query(query_texts=[question], n_results=20)
    vec_ranking = vec_res["ids"][0]

    # Fusion
    fused = rrf_fuse([bm25_ranking, vec_ranking])
    return [all_docs[int(i)] for i in fused[:top_k]]

#Régler le ratio BM25 / vectoriel

Par défaut RRF traite les deux listes à égalité. Si votre corpus est très spécialisé (beaucoup d'identifiants), vous pouvez favoriser BM25 en divisant son rank par un facteur < 1 (donc en augmentant sa contribution). À l'inverse, sur corpus libre, favorisez le vectoriel.

def rrf_fuse_weighted(rankings, weights, k=60):
    scores = {}
    for ranking, weight in zip(rankings, weights):
        for rank, doc_id in enumerate(ranking, start=1):
            scores[doc_id] = scores.get(doc_id, 0) + weight / (k + rank)
    return sorted(scores, key=scores.get, reverse=True)

# Ex : 40 % BM25, 60 % vectoriel
fused = rrf_fuse_weighted([bm25_ranking, vec_ranking], [0.4, 0.6])