Hybrid search en RAG : bien combiner BM25 et similarité vectorielle

La recherche hybride en RAG combine la recherche lexicale (BM25/correspondance de mots-clés) et la similarité vectorielle dense. Les deux retrievers tournent en parallèle, et leurs listes de résultats sont fusionnées en un seul classement par fusion de rangs. Le système trouve ainsi à la fois des passages sémantiquement proches et des termes exacts, des noms propres et des codes que les embeddings seuls manquent. Depuis 2023, la récupération hybride fait partie intégrante de l'Advanced RAG et a sa place dans tout pipeline de production qui doit chercher dans autre chose que des textes génériques.

• Ce qui est combiné : la récupération sparse (BM25, tokens exacts) et la récupération dense (embeddings vectoriels, sens), réunies en un seul ensemble de résultats.
• Comment c'est combiné : par fusion de rangs, le plus souvent Reciprocal Rank Fusion (RRF), plus rarement par fusion pondérée des scores avec normalisation préalable.
• Pourquoi ça en vaut la peine : l'hybride bat le RAG purement vectoriel partout où les termes exacts comptent, et améliore le rappel de façon mesurable.

Les deux piliers : lexical contre sémantique

BM25 (sparse / lexical). BM25 est le standard éprouvé de la recherche plein texte. L'algorithme évalue les documents selon la correspondance exacte des termes, pondère davantage les termes rares (inverse document frequency) et normalise selon la longueur du document. BM25 est déterministe, rapide, indépendant de la langue dans son mécanisme et ne nécessite aucune inférence de modèle. Sa force est aussi sa limite : il ne trouve que ce qui apparaît littéralement (ou après tokenisation et stemming). Les synonymes, les périphrases et les paraphrases lui échappent.

Similarité vectorielle dense (sémantique). La récupération dense projette la requête et le document dans le même espace vectoriel et mesure leur proximité, le plus souvent par similarité cosinus. Un index approximatif des plus proches voisins (dans presque toutes les bases de données vectorielles, HNSW selon Malkov et Yashunin) permet de passer la recherche à l'échelle. La récupération dense capte le sens : « délai de résiliation » et « notification de fin de contrat » se retrouvent proches, même sans mot commun. Le revers : les embeddings lissent les chaînes exactes. Un numéro d'article, un code d'erreur ou un nom propre rarement vu se dilue dans l'espace sémantique.

C'est précisément là que naît le besoin de combiner. Anthropic illustre le problème par un exemple dans son article sur Contextual Retrieval : si quelqu'un demande le code d'erreur « TS-999 », un modèle d'embedding trouvera peut-être des contenus sur les codes d'erreur en général, mais risque de manquer la correspondance exacte. BM25, lui, cherche exactement cette chaîne. Les deux méthodes échouent sur des requêtes différentes, c'est pourquoi elles se complètent.

Quand l'hybride bat le RAG vectoriel classique

La recherche hybride n'est pas indispensable pour tous les corpus, mais elle est nettement supérieure dans les cas suivants :

• Codes et identifiants exacts : références produit, numéros d'article et de commande, SKU, codes d'erreur et de statut, références de tickets.
• Noms propres et termes techniques : personnes, entreprises, noms de produits, articles de loi, termes techniques rares sous-représentés dans le corpus d'entraînement du modèle d'embedding.
• Recherche dans le code et les logs : noms de fonctions, variables, clés de configuration : ici, la correspondance exacte compte souvent plus que le sens.
• Requêtes mixtes : langage naturel avec des tokens exacts intégrés (« Comment corriger le code d'erreur TS-999 ? »).

Pour des textes homogènes et narratifs sans identifiants stricts, la récupération dense seule peut suffire. Mais dès que des termes structurés, des numéros ou une terminologie réglementée entrent en jeu, et c'est la règle au quotidien en B2B, l'hybride l'emporte.

Fusion : RRF, scores pondérés et problème de normalisation

La partie délicate n'est pas la recherche en parallèle, mais la fusion. Les scores BM25 et vectoriels vivent dans des plages de valeurs non comparables : les scores BM25 ne sont pas bornés et dépendent du corpus, la similarité cosinus est comprise entre moins un et un. Si tu les additionnes simplement, l'échelle dominante écrase tout.

Reciprocal Rank Fusion (RRF) résout cela élégamment en ignorant les scores bruts pour n'utiliser que les positions dans le classement. Chaque document reçoit, pour chaque liste de résultats, un score selon la formule :

```
RRF_score(d) = somme sur toutes les listes de 1 / (k + rang(d))
```

Ici, rang(d) est la position du document dans la liste concernée et k une petite constante (souvent 60) qui atténue l'influence des rangs très élevés. Un document bien placé dans les deux listes cumule le score total le plus élevé. Comme RRF est indépendant de l'échelle, toute normalisation devient inutile, ce qui le rend robuste et presque sans paramètre.

La fusion pondérée des scores est l'alternative quand tu veux délibérément donner plus de poids à une modalité (par exemple 0,7 * dense + 0,3 * sparse). Elle exige toutefois une normalisation : les deux listes de scores doivent d'abord être ramenées à une plage commune (par ex. min-max entre zéro et un) avant d'être combinées linéairement. C'est plus puissant, mais plus sensible au réglage et à la dérive du corpus.

Architecture du pipeline

Schématiquement, un pipeline de récupération hybride fonctionne ainsi :

```
Query ──┬─► Dense Encoder ──► ANN-Index (HNSW) ──► top_n_dense
│
└─► Tokenizer ──────► BM25-Index ───────► top_n_sparse
│
Rank-Fusion (RRF / weighted) ◄────┘
→ unified top_k
```

En pratique, un reranking suit : la récupération hybride fournit, avec un rappel élevé, généralement 50 à 100 candidats (top_k = 50–100), puis un reranker cross-encoder évalue la requête et le document ensemble et réduit la sélection aux cinq à dix résultats les plus précis, qui sont transmis au LLM. Les modèles les plus répandus sont Cohere Rerank, BGE-Reranker et Jina Reranker v3. Son éditeur, Jina AI, appartient à Elastic depuis octobre 2025. Les cross-encoders sont plus précis, mais plus lents, c'est pourquoi ils n'interviennent qu'après le rappel hybride, peu coûteux.

Exemple pratique chiffré

Le point de données solide le plus pertinent provient de Contextual Retrieval d'Anthropic (chiffres de 09/2024). L'approche prolonge précisément l'idée hybride : avant l'embedding et avant l'indexation BM25, chaque chunk est précédé d'un court en-tête de contexte généré par un LLM (Contextual Embeddings plus Contextual BM25).

• Contextual Embeddings seuls : taux d'échec de récupération dans le top 20 réduit de 5,7 à 3,7 %, moins 35 %.
• Contextual Embeddings plus Contextual BM25 (donc hybride) : de 5,7 à 2,9 %, moins 49 %.
• Avec un reranking en plus : ramené à 1,9 %, moins 67 %.

Autrement dit : le simple ajout de la composante BM25 à la récupération dense contextualisée fait passer le taux d'échec de 3,7 à 2,9 %, un gain de rappel sensible, impossible à obtenir sans recherche lexicale. L'indexation a coûté environ 1,02 dollar US par million de tokens de document avec le prompt caching (chiffres de 09/2024). Ces chiffres proviennent d'une évaluation menée par l'éditeur et doivent être lus comme tels.

Une deuxième preuve, indépendante : sur le benchmark Agri-Query (arXiv:2508.18093, 2025), la récupération hybride combinée à Gemini 2.5 Flash dépasse 85 % d'exactitude dans plusieurs langues et bat nettement les prompts naïfs à contexte long. La recherche hybride est donc aussi un argument dans le débat en cours « RAG contre contexte long » : pour des requêtes réalistes en plusieurs parties, le RAG hybride reste l'architecture la plus précise et la plus rationnelle en coûts.

Outils : la recherche hybride dans la base de données vectorielle

En 2026, toutes les bases de données vectorielles prêtes pour la production prennent en charge la recherche hybride, nativement ou via une extension. Qdrant (Berlin) mise sur les vecteurs creux et BM42, Weaviate (Amsterdam) combine BM25 et dense, Pinecone propose le sparse-dense, Vespa et les stacks de recherche établis Elastic et OpenSearch associent BM25 classique et kNN. pgvector atteint l'hybride grâce à des extensions BM25 supplémentaires. Pour les projets européens soumis à des exigences de souveraineté, Qdrant et Weaviate sont les options les plus évidentes : hébergées dans l'UE, elles offrent un filtrage granulaire des métadonnées, utile pour la séparation des clients conformément au RGPD.

Pour les agences et le B2B

La recherche hybride est le levier qui fait passer un prototype RAG au statut de solution de production fiable, surtout dans les secteurs avec catalogues produits, normes, numéros de dossier, tarifs ou manuels techniques, où les termes exacts sont critiques pour l'activité. Si, en tant qu'agence, tu construis des assistants basés sur le RAG ou des portails de connaissances pour des clients en Europe, prévois la récupération hybride avec RRF et reranking comme choix par défaut, pas comme une réflexion après coup. Blck Alpaca conçoit et met en œuvre ces pipelines de récupération de façon souveraine dans l'UE en tant que logiciel d'entreprise sur mesure, du choix des outils à l'évaluation avec RAGAS, en passant par la stratégie de fusion. Contacte-nous si tu veux que ton système RAG trouve de manière fiable les bons documents.