Recherche hybride (Dense + Sparse Search)

1. Aperçu du concept et problème systémique

Au démarrage de la création de systèmes RAG, les ingénieurs s'appuient souvent exclusivement sur des bases de données vectorielles : le texte est découpé en chunks, traité par un modèle d'embeddings puis indexé via HNSW.

En production, cette approche se heurte inévitablement à l'« aveuglement vectoriel » :

1. Échec sur les identifiants exacts : Lorsqu'un ingénieur recherche le code d'erreur ERR_CONNECTION_REFUSED, la recherche vectorielle renvoie des articles généraux sur le réseau mais manque la ligne précise dans les logs.
2. Échec sur les noms propres rares : Les nouveaux noms de frameworks, les patronymes uniques ou les constantes spécifiques au projet ne disposent pas d'une représentation dense dans les poids du modèle d'embeddings.
3. Limites de la recherche full-text classique (BM25) : À l'inverse, la recherche classique est incapable de comprendre les concepts abstraits, les synonymes et les reformulations.

La recherche hybride (Hybrid Search) synthétise le meilleur des deux mondes : elle effectue une recherche parallèle sur des mots-clés exacts (Sparse/BM25) et sur le contenu sémantique (Dense/Vectors), avant de fusionner les résultats dans une restitution unique et équilibrée.

2. Taxonomie architecturale et modèle mental

Un système de recherche hybride se compose de trois blocs architecturaux clés :

• 1. Couche de recherche sparse (Sparse / Lexical Retrieval) : Algorithme BM25 ou TF-IDF sur un index inversé. Calcule la fréquence exacte des termes en tenant compte de la longueur du document. Garantit la détection des correspondances exactes de mots, références produits, variables et numéros d'erreurs.
• 2. Couche de recherche dense (Dense / Semantic Retrieval) : Recherche vectorielle basée sur la distance euclidienne ou cosinus (HNSW/IVF). Responsable de l'extraction de documents au contenu similaire, même si aucune parole n'est partagée entre la requête et le texte.
• 3. Couche de fusion des rangs (Fusion Layer) :
  • Reciprocal Rank Fusion (RRF) : indépendante des échelles de scores, elle opère purement sur les positions (rangs) dans chaque liste. C'est le standard le plus stable.
  • Linear Weighted Fusion (fusion alpha) : normalisation des scores et addition pondérée : $\text{Score} = \alpha \cdot S_{\text{dense}} + (1 - \alpha) \cdot S_{\text{sparse}}$.
• 4. Modèles sparse appris (Learned Sparse / SPLADE) : Approche moderne combinant l'analyse par réseaux de neurones avec la structure d'un index inversé, étendant automatiquement la requête avec des mots-clés pertinents.

3. Pipeline technique et mécanique interne

Le cycle de vie d'une requête hybride dans un moteur de recherche :

1. Dual Query Dispatch (Dispatch parallèle) : La requête utilisateur entrante est simultanément transformée en vecteur (via l'API d'embedding) et en requête textuelle pour le parser full-text (requête FTS).
2. Concurrent Index Lookup (Recherche parallèle) :
   • Branche A : le moteur vectoriel scanne le graphe HNSW et retourne les top-50 candidats selon la similarité cosinus.
   • Branche B : l'index inversé trouve les top-50 candidats selon la formule BM25.
3. Score Normalization & RRF Aggregation (Fusion) : Les listes de candidats sont dédupliquées par ID de document. Chaque candidat reçoit un score intégral RRF basé sur sa position dans les deux restitutions.
4. Final Cutoff & Re-ranking (Sélection finale) : Le top-$K$ des documents les mieux classés est transmis à l'étape finale de re-ranking par cross-encoder (Re-ranker) ou directement dans le contexte du LLM.

4. Scénarios d'ingénierie pratiques en production

01. Recherche intelligente dans les dépôts de code

Un développeur écrit : « où est implémenté le cache de sessions redis ».

• BM25 trouve instantanément les fichiers mentionnant la constante 'REDIS_SESSION_KEY'.
• La recherche Dense récupère le module d'authentification, où la stratégie d'invalidation des sessions est décrite sans utiliser le mot direct « cache ».
• RRF place en première position le fichier auth/session-cache.ts, présent dans les deux restitutions.

02. Recherche E-Commerce mélangeant caractéristiques et noms

L'utilisateur cherche : « aspirateur sans fil silencieux v15 ». BM25 trouve le modèle exact Dyson V15, tandis que la recherche Dense filtre les variantes selon la sémantique du faible niveau sonore, assurant une précision de conversion optimale.

03. Référentiels médicaux et pharmaceutiques

Recherche par symptômes (« lourdeur sous l'hypochondre droit ») combinée à la désignation latine exacte de la substance active du médicament ou au code médical du diagnostic selon la CIM-10.

5. Pièges, erreurs courantes et sécurité

• Incompatibilité des échelles de scores bruts (Score Incommensurability) : L'erreur la plus grossière consiste à additionner directement la proximité cosinus (de 0 à 1) au score BM25 (qui peut atteindre 25 et plus). Cela annule totalement la composante vectorielle. Utilisez toujours RRF ou une normalisation Min-Max.
• Double charge sur l'infrastructure (Latency Overhead) : L'exécution séquentielle, d'abord BM25 puis la recherche vectorielle, double la latence. Les deux requêtes doivent s'exécuter strictement de manière asynchrone via Promise.all() ou des threads DB parallèles.
• Biais du poids $\alpha$ vers les extrêmes : Fixer le poids $\alpha = 0.9$ transforme la recherche hybride en simple recherche vectorielle, rendant inutile le coût de maintenance de l'index inversé.