Pourquoi l’Enterprise RAG a besoin d’une recherche hybride, et non seulement de vecteurs

La plus grande idée reçue concernant le RAG d’entreprise est que de meilleurs embeddings produisent automatiquement de meilleures réponses. La qualité des réponses dépend bien plus de ce qui est récupéré que du modèle de chat utilisé.

Introduction

La génération augmentée par récupération permet aux assistants d’accéder à des connaissances externes avant de parler. La plupart des démonstrations mettent l’recherche vectorielle au centre :

Documents
    │
Chunking
    │
Embedding Model
    │
Vector Database
    │
Top-K Retrieval
    │
Large Language Model

Embedder les documents, stocker les vecteurs, récupérer les voisins les plus proches pour chaque requête. Ce schéma fonctionne bien dans les démonstrations mais échoue souvent en production — surtout dans les entreprises remplies d’identifiants. La recherche vectorielle pure est rarement suffisante. La recherche hybride est devenue la stratégie de récupération par défaut pour les systèmes RAG sérieux.

Pourquoi la recherche vectorielle est devenue populaire

Les moteurs de mots-clés effectuent des correspondances par tokens. La requête « Comment réinitialiser un mot de passe ? » renvoie aux documents contenant les termes “réinitialiser/mot de passe/compte”. La phrase « Impossible d’accéder au compte » peut ignorer complètement les documents relatifs aux mots de passe, même si l’intention est identique. Les embeddings transforment le sens en espace vectoriel, ce qui fait que les paraphrases continuent de se recouper. Pour les FAQ et les documents narratifs, c’est une avancée majeure.

Où les vecteurs purs échouent

Les corpus d’entreprise sont remplis de numéros de facture, d’identifiants d’employés, de codes d’erreur, de références SKU, d’identifiants de contrat, de numéros de politique et de chaînes de version. Ces éléments sont importants pour les utilisateurs, mais difficiles à gérer par les modèles densifs.

Face à un enregistrement tel que :

Invoice Number : INV-93842
Status         : Paid
Customer       : ABC Corporation

une requête du type « Quel est le statut de la facture INV-93842 ? » récupère souvent des guides de facturation plutôt que cette facture elle-même, car les embeddings mettent l’accent sur les concepts “facture/paiement” plutôt que sur l’identifiant exact.

D’autres modes d’échec

Les recherches basées sur des erreurs de base de données cherchent :

ORA-12514

il est possible que des guides de connectivité génériques soient affichés à la place de la page ORA-12514.

Les recherches concernant les produits, telles que :

RTX-9000 Switch

peuvent donner lieu à des aperçus sur les réseaux plutôt qu’au manuel RTX-9000.

Les questions relatives aux versions, comme :

Version 4.3.12

aboutissent souvent à des notes de version génériques, et non spécifiquement à celles de la version 4.3.12.

Les recherches dans le domaine de la santé, pour :

Patient ID: P-482731

peuvent restituer des documents de procédures d’enregistrement à la place du dossier médical concerné.

Lorsque des identifiants précis sont essentiels, la similitude sémantique seule ne suffit pas à garantir la fiabilité.

Pourquoi les embeddings échouent ici

Les modèles apprennent des correspondances telles que médecin↔physicien ou voiture↔automobile. Des expressions comme :

INV-93842

ou

RTX-9000

contiennent peu de contenu sémantique. En changeant :

INV-93842

en

INV-93843

Cela modifie l’entité commerciale tandis que les embeddings restent presque identiques. C’est inhérent à la récupération dense, et non un bug d’un seul fournisseur.

La segmentation de la récupération d’entreprise

Informations sémantiques (politique de résiliation, processus de demande, réinitialisation du mot de passe) — les vecteurs sont excellents. Informations exactes (identifiants, codes, SKUs, versions) — les mots-clés/BM25 sont excellents.

Utiliser uniquement une stratégie signifie exceller sur un axe et rencontrer des difficultés sur l’autre. La recherche hybride existe pour couvrir les deux cas.

Découvrez la recherche hybride

Au lieu de BM25 ou des vecteurs, exécutez les deux et fusionnez-les :

User Query
                         │
        ┌────────────────┴────────────────┐
        │                                 │
        ▼                                 ▼
 Keyword Search (BM25)           Vector Search
        │                                 │
        └──────────────┬──────────────────┘
                       ▼
              Merge & Score Fusion
                       ▼
                 Cross-Encoder Re-ranker
                       ▼
                Top Relevant Context
                       ▼
                 Large Language Model

La recherche par mots-clés protège les identifiants et les tokens rares. La recherche vectorielle couvre les synonymes et les formulations différentes. Un réclassificateur (ou fusion par rang réciproque) ordonne les candidats combinés pour la requête de l’utilisateur.

Pourquoi la recherche hybride gagne

Pour la question « Pourquoi la facture INV-93842 est-elle encore en attente d’approbation ? », l’approche hybride peut correspondre à l’ID exact grâce aux mots-clés, récupérer les documents de workflow associés via des vecteurs, et réordonner les résultats afin que l’enregistrement de la facture soit en tête tout en maintenant la disponibilité des documents du processus. Chaque technique fait ce pour quoi elle est la meilleure.

Considerations finales

Les bases de données vectorielles restent fondamentales. Elles ne constituent pas un remplacement complet des systèmes d’indexation classiques. Les connaissances d’entreprise combinent du texte, des codes et des enregistrements. La recherche hybride prend en compte cette diversité.

Un modèle de chat plus performant ne peut pas corriger un ensemble de candidats faible. Il vaut mieux investir dans une recherche capable de mettre en évidence régulièrement les passages corrects plutôt que d’allouer des budgets à des générateurs plus puissants ou à des prompts plus sophistiqués — dans les systèmes RAG, la qualité de la réponse dépend d’abord de la qualité de la recherche.

D’un point de vue opérationnel, enregistrez quelle branche a contribué à chaque recherche (mots-clés ou données denses), ajustez les poids de fusion sur un ensemble d’évaluation comprenant à la fois des questions paraphrasées et des recherches par identifiant, et refusez de déclarer que « RAG est prêt » après une démonstration ne portant que sur des questions sémantiques simples. Les requêtes identifiées représentent les tests d’acceptation que les entreprises échouent réellement en environnement de production.

Créer un système hybride sans chercher à tout résoudre d’un coup

Commencez par utiliser BM25 (ou une recherche lexicale équivalente) en complément de l’index vectoriel existant — de nombreuses bases de données vectorielles offrent déjà des API hybrides. Assurez-vous que les identifiants des blocs soient alignés afin que la fusion soit simple. Commencez par utiliser la fusion par rang réciproque avant d’entraîner un re-rangeur à base de cross-encoder ; la RRF est peu coûteuse et suffisante dans la plupart des cas pour prouver que l’écart lié aux recherches par identifiant se réduit.

Créez un ensemble d’évaluation comprenant deux groupes : des questions de paraphrase (sémantiques) et des questions d’identification (exactes). Évaluez séparément le taux de rappel@k. Ne lancez la version hybride que lorsque les deux groupes s’améliorent ou que l’un d’eux s’améliore sans nuire à l’autre. Faites attention à la latence : exécuter deux systèmes de récupération en parallèle est généralement acceptable, tandis qu’un réclassement séquentiel de très grands ensembles de candidats ne l’est pas.

La stratégie de segmentation en blocs reste importante. Les identifiants enfouis dans de très gros blocs affaiblissent à la fois les scores BM25 et les scores densifs. Préférez des limites de blocs qui conservent intactes les en-têtes de facture, les titres des codes d’erreur et les lignes SKU. Les filtres de métadonnées (ligne de produit, région linguistique, type de document) réduisent davantage les erreurs de correspondance avant la fusion.

Enfin, informez les parties prenantes concernant le produit : « nous avons intégré tout ce qui était possible » n’est pas une stratégie de récupération. La version hybride est la stratégie qui correspond à la manière dont les entreprises posent réellement leurs questions — à moitié en langage naturel, à moitié avec des IDs de ticket saisis depuis l’écran.

Liste de vérification du déploiement

1. Examiner les requêtes d’inventaire dans les journaux de production ; indiquer celles qui nécessitent une correspondance exacte et celles qui peuvent être paraphrasées.
2. Mettre en place une recherche lexicale sur le même corpus et les mêmes identifiants de blocs que l’index vectoriel.
3. Fusionner avec RRF ; enregistrer les sources de contribution pour chaque résultat.
4. Évaluer le taux de rappel@k pour les deux groupes ; ajuster les poids.
5. Ne considérer un réclassificateur appris que si le budget de latence le permet.
6. Conserver les champs d’identifiant dans les métadonnées pour des filtres stricts optionnels lorsque l’interface connaît déjà une facture ou un SKU.

Les équipes qui passent directement à un « modèle d’embedding plus grand » découvrent souvent à nouveau les mêmes problèmes d’identifiants avec des vecteurs plus élégants. La recherche hybride est la solution peu attrayante mais adaptée à la manière dont les tickets sont rédigés.