Recherche hybride : pourquoi combiner mots-clés et vecteurs bat chaque méthode seule

La recherche hybride consiste à interroger vos documents à la fois avec une recherche plein texte classique (BM25, basée sur les mots-clés exacts) et avec une recherche vectorielle (basée sur le sens, via des embeddings), puis à fusionner les deux classements. Sur des documents professionnels, où un numéro d'article, un sigle ou une référence précise côtoient des questions formulées en langage naturel, cette combinaison retrouve nettement plus souvent le bon passage que chaque méthode prise isolément.

Pourquoi le plein texte (BM25) seul ne suffit pas

BM25 est l'algorithme de scoring utilisé par la plupart des moteurs de recherche plein texte (Elasticsearch, PostgreSQL full-text, Lucene). Il mesure la fréquence des mots d'une requête dans un document, pondérée par leur rareté dans l'ensemble du corpus. C'est redoutablement efficace pour retrouver un terme exact : une référence de contrat, un code NAF, le nom d'un règlement, un numéro d'article de convention collective.

Mais BM25 ne comprend pas le sens. Si un utilisateur pose la question « combien de temps avant que mon employeur ne me paie plus rien pendant un arrêt maladie ? » et que le document parle de « délai de carence » et de « maintien de salaire », BM25 risque de rater le passage pertinent faute de recouvrement lexical suffisant. Il échoue aussi sur les synonymes, les reformulations, les fautes de frappe et les questions posées dans un registre différent de celui du document source.

Pourquoi la recherche vectorielle seule ne suffit pas non plus

La recherche vectorielle transforme chaque extrait de texte en un vecteur numérique (un embedding) qui capture son sens, puis compare ce vecteur à celui de la question posée. Elle excelle là où BM25 échoue : elle rapproche « arrêt maladie » de « incapacité de travail », ou « résiliation » de « rupture du contrat », même sans mot commun. Pour comprendre le mécanisme en détail, notre article sur les embeddings expliqués simplement détaille comment un texte devient un vecteur.

Le revers de la médaille : les embeddings lissent le sens général d'un texte, au détriment des détails exacts. Une recherche vectorielle a souvent du mal à distinguer « article 12 » de « article 21 », ou « seuil de 10 000 euros » de « seuil de 100 000 euros », parce que ces chiffres pèsent peu dans la représentation vectorielle globale d'une phrase. Sur des documents juridiques, comptables ou réglementaires, où chaque chiffre et chaque référence compte, cette faiblesse est rédhibitoire si elle n'est pas compensée.

La recherche hybride : combiner les deux sans sacrifier ni l'un ni l'autre

L'idée de la recherche hybride est simple : exécuter les deux recherches en parallèle sur la même question, obtenir deux classements de passages candidats, puis les fusionner en un seul classement final. L'enjeu technique n'est pas de choisir entre les deux, mais de les faire coexister correctement, sachant que les scores BM25 et les scores de similarité vectorielle n'ont ni la même échelle, ni la même distribution statistique. Additionner naïvement un score BM25 de 8,3 et un score cosinus de 0,71 n'a aucun sens mathématique.

C'est là qu'intervient le reciprocal rank fusion, une méthode qui ignore les scores bruts et ne retient que le rang de chaque passage dans chaque classement.

Reciprocal Rank Fusion (RRF) : comment ça marche concrètement

Le RRF attribue à chaque document un score égal à la somme de 1 / (k + rang) pour chacun des classements où il apparaît, k étant une constante (souvent fixée à 60) qui atténue le poids des premiers rangs sans les rendre écrasants. Un document bien classé dans les deux recherches obtient un score élevé ; un document très bien classé dans une seule recherche mais absent de l'autre reste compétitif grâce à ce rang unique favorable. C'est ce qui permet au RRF de capter aussi bien le passage trouvé par mot-clé exact que celui trouvé par proximité sémantique.

Un exemple chiffré

Imaginons une question sur un marché public : « quel est le délai pour demander une avance ? ». Voici comment trois passages pourraient être classés par chaque méthode, puis fusionnés par RRF (avec k = 60).

Dans cet exemple, le passage A (trouvé facilement par mots-clés) et le passage B (trouvé seulement par la recherche sémantique parce qu'il utilise « acompte » plutôt qu'« avance ») remontent tous les deux en tête. Une recherche purement plein texte aurait manqué le passage B ; une recherche purement vectorielle aurait sous-classé le passage A à cause du bruit du passage C. C'est exactement ce type de situation qui se produit sur un article détaillant le calcul d'une avance sur marché public.

Exemples concrets sur des documents professionnels

• Convention collective : une question sur le « forfait jours » doit remonter l'article qui parle de « convention de forfait en jours » (reformulation) ET celui qui cite « 218 jours » (le chiffre exact), deux besoins que seul l'hybride couvre simultanément.
• Documentation technique ou API : un développeur qui cherche « comment authentifier mes requêtes » doit retrouver la page qui contient littéralement « clé API » (mot-clé) même s'il n'a jamais tapé ce terme, grâce au vecteur, et la page qui montre le header exact Authorization: Bearer (exact, donc BM25).
• Contrats et marchés publics : les références d'articles (« article 1218 du Code civil »), les seuils en euros et les sigles (DC4, OSS, IOSS) sont mieux retrouvés par BM25, alors que les questions formulées librement par un utilisateur non juriste passent mieux en vectoriel.
• Notes de conformité LCB-FT : des termes comme « PPE », « vigilance renforcée » ou « pays tiers à haut risque » sont des expressions figées que BM25 retrouve très bien, alors qu'une question du type « que dois-je vérifier pour un client politiquement exposé » a besoin du vecteur pour faire le lien.

Mettre en place une recherche hybride : par vous-même ou en la déléguant

Construire un pipeline hybride maison demande plusieurs briques : un index plein texte (Elasticsearch, OpenSearch, PostgreSQL avec pg_trgm/tsvector), un index vectoriel (pgvector, une base dédiée), un modèle d'embeddings à faire tourner ou appeler en API, puis une logique de fusion RRF à coder et calibrer. Pour une vue d'ensemble de ces briques, notre article sur le pipeline RAG (chunking, indexation, recherche) détaille chaque étape, et celui sur qu'est-ce qu'une base de données vectorielle complète la partie stockage.

C'est un chantier d'ingénierie réel, pas un simple appel d'API. Si l'objectif est d'obtenir des réponses fiables sur des documents métier sans monter cette infrastructure, une alternative consiste à utiliser une plateforme qui fait tourner le plein texte et le vectoriel en parallèle nativement. C'est l'approche retenue par Kopik : chaque document déposé est indexé à la fois pour la recherche plein texte et pour la recherche sémantique avec expansion de mots-clés, sans configuration à faire côté utilisateur.

Concrètement, vous déposez vos PDF, fichiers Word ou Markdown sur une base de connaissances, Kopik s'occupe de l'extraction, du découpage et de l'indexation hybride, et chaque question posée interroge les deux index avant de retourner une réponse sourcée avec les passages cités, ou les passages bruts en mode « passages ». Pour comprendre le principe général avant d'aller plus loin, l'article qu'est-ce que le RAG pose les bases, et comment fonctionne le RAG étape par étape suit une question de bout en bout.

Interroger une base hybride via API ou MCP

Une fois la base indexée, elle peut être interrogée de trois façons : directement sur le site, via une API REST avec des clés dédiées, ou via un serveur MCP utilisable depuis Claude, Cursor ou ChatGPT. Le moteur de recherche hybride reste identique quel que soit le canal : c'est la logique de fusion qui garantit la pertinence, pas l'interface. Les détails techniques (authentification, formats de réponse, modes citation et passages) sont documentés sur la page développeurs, et notre guide pour connecter Claude, Cursor ou ChatGPT à une base de connaissances explique la configuration MCP pas à pas. Vous pouvez aussi parcourir le catalogue de bases existantes pour voir le type de documents déjà indexés par d'autres utilisateurs.

Limites et bonnes pratiques à connaître

1. Le RRF suppose un nombre de résultats candidats suffisant dans chaque classement (en général 20 à 50) pour ne pas pénaliser injustement un passage pertinent mais mal classé dans un seul des deux index.
2. La qualité du découpage en chunks conditionne tout : un chunk trop long dilue le signal vectoriel, un chunk trop court perd le contexte nécessaire pour BM25.
3. Sur des corpus très techniques avec beaucoup d'acronymes propres au métier, il peut être utile de renforcer le poids du plein texte dans la fusion plutôt que de garder une pondération strictement égale.
4. Toujours vérifier les passages cités dans la réponse finale plutôt que de faire confiance aveuglément au classement : la fusion améliore le rappel, elle ne garantit pas que la réponse générée interprète correctement le passage retrouvé.

En résumé

BM25 excelle sur les termes exacts, la recherche vectorielle excelle sur le sens et les reformulations : aucune des deux ne suffit seule sur des documents professionnels mêlant jargon technique, chiffres précis et questions posées en langage courant. Le reciprocal rank fusion permet de combiner les deux classements sans avoir à harmoniser des échelles de score incompatibles, et c'est cette combinaison, plus qu'un modèle d'embeddings sophistiqué, qui fait le plus souvent la différence sur la qualité perçue d'un système de questions-réponses.