Accueil › Glossaire › Hybrid Search

Hybrid Search (Recherche Hybride)

Le hybrid search est une architecture de recherche d’information qui combine la recherche par mots-clés (lexicale, typiquement BM25) avec la recherche sémantique (vectorielle, par embeddings) pour obtenir des résultats à la fois précis sur les termes exacts et pertinents sur le sens.

Ni la recherche par mots-clés ni la recherche vectorielle ne sont suffisantes seules. BM25 excelle pour retrouver un numéro de référence ou un nom propre, mais rate les synonymes et les reformulations. La recherche sémantique comprend l’intention, mais peut renvoyer des résultats vaguement liés au lieu de correspondances exactes. Le hybrid search résout ce dilemme en exécutant les deux recherches en parallèle, puis en fusionnant les résultats avec un algorithme comme Reciprocal Rank Fusion (RRF). C’est le standard de facto pour tout système de retrieval sérieux en 2026.

Pourquoi le hybrid search est indispensable

Chaque méthode de recherche a un angle mort structurel. Comprendre ces limites explique pourquoi la combinaison des deux approches surpasse systématiquement chacune prise isolément.

Les limites du keyword search

La recherche par mots-clés, typiquement BM25 ou TF-IDF, utilise un index inversé pour retrouver les documents contenant les termes de la requête. Elle est rapide, transparente et excellente pour les correspondances exactes. Mais elle échoue dès que l’utilisateur s’exprime différemment du document. Si vous cherchez « chaussures de sport » et que la fiche produit dit « sneakers running », BM25 ne fait pas le lien. Les synonymes, les reformulations et les requêtes en langage naturel sont ses points faibles.

Les limites du semantic search

La recherche sémantique convertit requêtes et documents en vecteurs numériques et compare leur similarité. Elle comprend que « chaussures de sport » et « sneakers running » sont liés sémantiquement. Mais elle a aussi ses failles. Un modèle d’embedding ne distingue pas bien les nuances fines entre des termes très proches. Une recherche pour « article L.225-37 du Code de commerce » peut renvoyer des résultats sur le droit des sociétés en général. Les codes produit, numéros de série, identifiants techniques et noms propres rares sont mal gérés par les vecteurs, car le modèle d’embedding les traite comme des sous-mots génériques plutôt que comme des identifiants uniques.

La complémentarité démontrée

Le hybrid search exploite la complémentarité de ces deux approches. La recherche lexicale apporte la précision sur les termes exacts. La recherche vectorielle apporte la compréhension du sens et de l’intention. Combinées, elles couvrent les deux cas : le document pertinent qui utilise exactement les mêmes mots ET le document pertinent qui exprime la même idée avec des mots différents. Les benchmarks montrent de façon constante que le hybrid search surpasse chaque méthode utilisée seule, avec des gains significatifs en recall et en NDCG (Normalized Discounted Cumulative Gain).

Comment fonctionne le hybrid search

L’architecture du hybrid search repose sur trois étapes distinctes : deux recherches parallèles et une fusion.

Étape 1 : Recherche parallèle

Quand l’utilisateur envoie sa requête, le système lance simultanément deux recherches :

Recherche lexicale (BM25) : La requête est tokenisée et comparée à un index inversé. BM25 calcule un score basé sur la fréquence des termes (TF), l’inverse de la fréquence documentaire (IDF) et la longueur du document. Les documents contenant les mots de la requête sont classés par pertinence lexicale. Ce score est non borné : il peut aller de 0 à des valeurs très élevées selon la distribution des termes.

Recherche vectorielle : La requête est convertie en vecteur par un modèle d’embedding, puis comparée aux vecteurs de tous les documents via un algorithme de plus proches voisins (typiquement HNSW). Les documents les plus proches sémantiquement sont renvoyés avec un score de similarité (cosine similarity, généralement entre 0 et 1).

Chaque recherche produit sa propre liste classée, avec des scores sur des échelles totalement différentes. C’est précisément ce qui rend la fusion non triviale.

Étape 2 : Fusion des résultats

Les deux listes classées doivent être fusionnées en une seule. C’est le cœur du hybrid search, et c’est là que le choix de l’algorithme de fusion a un impact majeur sur la qualité. Trois méthodes principales existent :

Reciprocal Rank Fusion (RRF)

RRF est de loin l’algorithme de fusion le plus utilisé. Son principe est simple et élégant : il ignore les scores bruts et travaille uniquement avec les rangs (positions) des documents dans chaque liste. La formule :

RRF_score(d) = Σ  1 / (k + rang(d, recherche_i))

Où :
- d = un document
- k = constante de lissage (généralement 60)
- rang(d, recherche_i) = position du document d dans les résultats de la recherche i (à partir de 1)

Prenons un exemple concret. Trois documents apparaissent dans les résultats de deux recherches :

Les documents A et B, présents dans les deux listes, obtiennent les meilleurs scores RRF. C’est le principe fondamental : un document bien classé dans plusieurs recherches est probablement plus pertinent qu’un document bien classé dans une seule.

Les avantages de RRF sont nombreux. Il ne nécessite aucune normalisation des scores (les échelles BM25 et cosine sont incompatibles). Il ne demande aucun tuning initial. Il est robuste et performant sur la plupart des datasets. C’est pourquoi il est le choix par défaut de Weaviate, Elasticsearch, OpenSearch et Azure AI Search.

Linear Combination (combinaison linéaire)

La combinaison linéaire calcule un score final comme somme pondérée des scores normalisés de chaque recherche :

Score_final(d) = α × score_BM25_normalisé(d) + β × score_vectoriel_normalisé(d)

Où α et β sont des poids à ajuster (typiquement α + β = 1)

Cette méthode peut surpasser RRF quand les poids sont bien calibrés, car elle exploite l’information des scores (pas seulement les rangs). Mais elle est fragile : elle exige une normalisation correcte des scores (min-max ou z-score), et les poids optimaux varient selon le dataset et le type de requête. Elasticsearch la propose sous le nom « linear retriever ». Elle est recommandée quand vous avez des données de test pour calibrer les poids.

Relative Score Fusion (RSF)

Proposé par Weaviate, le Relative Score Fusion normalise les scores de chaque recherche par rapport à leur propre distribution (min-max scaling interne), puis les combine. C’est un compromis entre la simplicité de RRF et la richesse d’information de la combinaison linéaire. Weaviate le propose comme alternative à RRF via le paramètre fusionType.

Étape 3 : Reranking (optionnel mais recommandé)

Après la fusion, une étape de reranking améliore significativement la qualité. Un modèle de type cross-encoder évalue chaque paire requête-document de façon plus fine que la recherche initiale. Le cross-encoder prend en entrée la requête et le document concaténés, et produit un score de pertinence unique. C’est plus lent (il faut évaluer chaque document un par un), donc on l’applique uniquement sur les top 20-50 résultats de la fusion RRF.

Ce pipeline en trois étapes (retrieval lexical + vectoriel → fusion RRF → reranking cross-encoder) est le pattern standard des systèmes de RAG en production. Chaque étape filtre et affine les résultats : la première maximise le recall, la seconde combine les signaux, la troisième maximise la précision du classement final.

Les outils qui supportent le hybrid search nativement

La bonne nouvelle : vous n’avez plus besoin de construire le hybrid search from scratch. Les principales bases de données vectorielles et moteurs de recherche le supportent nativement.

Implémenter le hybrid search : exemples concrets

Avec Weaviate (Python)

import weaviate

client = weaviate.connect_to_local()

# Requête hybrid search avec Weaviate
collection = client.collections.get("Article")
response = collection.query.hybrid(
    query="protéger les plantes du gel",
    alpha=0.5,          # 0 = pur BM25, 1 = pur vecteur, 0.5 = équilibré
    limit=10,
    fusion_type="ranked"  # "ranked" (RRF) ou "relative_score"
)

for obj in response.objects:
    print(obj.properties["title"], obj.metadata.score)

Le paramètre alpha contrôle la balance entre BM25 et vecteurs. En pratique, commencez à 0,5 (équilibré), puis ajustez selon vos tests : alpha plus bas si vos requêtes sont techniques avec des termes exacts, plus haut si elles sont en langage naturel.

Avec Qdrant (Python)

from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://localhost:6333")

# Hybrid search avec Qdrant Query API
results = client.query_points(
    collection_name="articles",
    prefetch=[
        # Recherche dense (vecteurs)
        models.Prefetch(
            query=[0.1, 0.3, ...],  # embedding de la requête
            using="dense",
            limit=20
        ),
        # Recherche sparse (BM25 / SPLADE)
        models.Prefetch(
            query=models.SparseVector(
                indices=[1, 42, 1337],
                values=[0.5, 0.8, 0.3]
            ),
            using="sparse",
            limit=20
        ),
    ],
    query=models.FusionQuery(fusion=models.Fusion.RRF),
    limit=10
)

Qdrant utilise un système de prefetch en cascade : vous pouvez empiler plusieurs étapes de retrieval et de reranking directement côté serveur, sans aller-retour client-serveur supplémentaires.

Avec PostgreSQL (pgvector + ParadeDB)

-- Hybrid search avec RRF dans PostgreSQL pur
WITH bm25_results AS (
    SELECT id, RANK() OVER (ORDER BY pdb.score(id) DESC) AS rank
    FROM articles
    WHERE content @@@ 'protéger plantes gel'
    ORDER BY pdb.score(id) DESC
    LIMIT 20
),
vector_results AS (
    SELECT id, RANK() OVER (ORDER BY embedding  query_vector) AS rank
    FROM articles
    ORDER BY embedding  query_vector
    LIMIT 20
),
rrf AS (
    SELECT id, 1.0 / (60 + rank) AS score FROM bm25_results
    UNION ALL
    SELECT id, 1.0 / (60 + rank) AS score FROM vector_results
)
SELECT a.id, a.title, SUM(rrf.score) AS rrf_score
FROM rrf
JOIN articles a ON a.id = rrf.id
GROUP BY a.id, a.title
ORDER BY rrf_score DESC
LIMIT 10;

Cette approche est idéale si vous avez déjà une base PostgreSQL et ne souhaitez pas ajouter un service externe. pgvector gère les vecteurs, ParadeDB apporte un vrai BM25 (pas juste le ts_rank_cd natif de PostgreSQL), et le RRF se calcule en SQL pur.

Bonnes pratiques du hybrid search

Commencez par RRF avec k=60. C’est le point de départ le plus robuste. RRF ne nécessite aucune normalisation des scores et fonctionne bien dans la grande majorité des cas. Ne passez à la combinaison linéaire que si vous avez des données d’évaluation pour calibrer les poids.

Ajustez le ratio keyword/semantic. Les requêtes techniques avec des identifiants précis bénéficient d’un poids plus fort sur BM25. Les requêtes en langage naturel (« comment faire pour… ») bénéficient d’un poids plus fort sur le vecteur. Certains systèmes avancés utilisent un routeur de requêtes qui détecte automatiquement le type et ajuste les poids. Mais attention : un routeur trop complexe ajoute de la latence et des bugs. Gardez la logique simple.

Ajoutez un reranker. Pour tout système en production, le reranking post-fusion est le levier d’amélioration le plus fiable. Un cross-encoder comme cross-encoder/ms-marco-MiniLM-L-6-v2 (open source) ou les modèles de reranking de Cohere et Jina améliorent significativement la pertinence des top résultats.

Pondérez les champs. Si vos documents ont un titre et un corps, le BM25 devrait donner plus de poids au titre. BM25F (la variante de BM25 utilisée par Weaviate et Elasticsearch) permet de pondérer chaque champ. Un match dans le titre est généralement bien plus informatif qu’un match dans le corps du document.

Mesurez, mesurez, mesurez. Le hybrid search a plusieurs paramètres ajustables (alpha, k, poids des champs, nombre de résultats par retriever). La seule façon de les optimiser est d’évaluer sur un jeu de test avec des jugements de pertinence. Les métriques clés : precision@k, recall@k, NDCG@10 et MRR (Mean Reciprocal Rank).

Hybrid search dans les pipelines RAG

Le hybrid search est devenu le composant de retrieval standard dans les architectures RAG. Voici le pipeline type d’un système RAG en production :

1. Chunking : Les documents sont découpés en morceaux de 200-500 tokens. Chaque chunk est indexé à la fois dans un index BM25 et dans un index vectoriel.

2. Double indexation : Chaque chunk reçoit un vecteur d’embedding (dense) et est indexé en full-text (sparse/BM25). Certains systèmes ajoutent aussi des vecteurs sparse via SPLADE pour un troisième signal.

3. Retrieval hybride : La requête utilisateur lance les deux recherches en parallèle. Les résultats sont fusionnés par RRF. Typiquement, on récupère les top 20-50 chunks.

4. Reranking : Un cross-encoder reclasse les chunks fusionnés pour ne garder que les 3-5 plus pertinents.

5. Génération : Les chunks sélectionnés sont injectés dans le prompt du LLM, qui génère la réponse finale.

Ce pipeline multi-étages est utilisé par la majorité des chatbots d’entreprise, des assistants documentaires et des moteurs de question-réponse. La recherche hybride au milieu garantit un recall élevé (on ne rate pas de documents pertinents), tandis que le reranking final garantit que le LLM reçoit les passages les plus pertinents dans son contexte limité.

Sparse vectors et SPLADE : le troisième signal

Au-delà de la dichotomie BM25 (lexical) vs dense vectors (sémantique), un troisième type de représentation gagne en importance : les sparse vectors, typiquement générés par des modèles comme SPLADE (Sparse Lexical and Expansion Model). SPLADE combine la structure d’un index inversé (comme BM25) avec l’apprentissage de Transformers. Il génère des vecteurs très creux (la plupart des valeurs sont à zéro) mais qui capturent à la fois les correspondances lexicales ET une certaine expansion sémantique des termes.

Concrètement, si la requête contient « voiture », SPLADE peut activer aussi les dimensions correspondant à « automobile », « véhicule » et « conduite » dans le vecteur sparse. C’est un compromis entre la précision lexicale de BM25 et la compréhension sémantique des dense vectors. Qdrant, Pinecone et Milvus supportent tous les sparse vectors, et certains pipelines utilisent une fusion à trois voies (BM25 + dense + sparse) pour maximiser le recall.

Elasticsearch propose ELSER (Elastic Learned Sparse Encoder), son propre modèle de sparse encoding entraîné en interne, qui joue un rôle similaire et s’intègre directement dans ses pipelines de retrieval.

Verdict

Le hybrid search n’est pas une option, c’est une nécessité. Si vous construisez un système de recherche ou un pipeline RAG en 2026, la recherche vectorielle seule ne suffit pas. Le keyword search seul ne suffit pas non plus. Le hybrid search avec RRF est le baseline minimum, et le pattern complet (hybrid + reranking) est le standard de production.

La bonne nouvelle : l’implémentation est devenue triviale. Weaviate, Qdrant, Elasticsearch et même PostgreSQL (avec pgvector + ParadeDB) offrent le hybrid search en natif. Il n’y a plus besoin de maintenir deux systèmes séparés et de bricoler la fusion côté client. Activez-le, commencez avec RRF (k=60) et un alpha à 0,5, mesurez vos résultats, et ajustez. C’est la fondation sur laquelle tout le reste (reranking, query routing, agentic RAG) se construit.