Quand on branche un modèle de langage sur une base de documents, la première décision technique est celle du moteur de recherche qui va lui fournir les bons passages. Deux familles s’opposent : la recherche plein-texte, qui compare des mots, et la recherche sémantique, qui compare des sens via des embeddings. Choisir la mauvaise famille pour le mauvais cas condamne le système à des réponses fausses, quelle que soit la qualité du modèle.
La recherche plein-texte, souvent une variante de BM25, trouve un document parce qu’il contient les mots de la requête. La recherche sémantique le trouve parce qu’il parle de la même chose, même avec des mots différents. Ces deux logiques ne se recoupent que partiellement, et chacune a des cas où elle est nettement supérieure.
Cet article explique comment trancher entre les deux, et pourquoi la réponse est souvent un hybride. L’objectif est de vous éviter de construire un système entier sur une intuition, puis de découvrir après coup que la moitié de vos requêtes passent à côté.
Ce que la recherche plein-texte fait bien
La recherche plein-texte excelle quand la correspondance exacte compte. Un numéro de référence, un identifiant de produit, un code d’erreur, un nom propre : la requête doit trouver le document qui contient précisément ces caractères. La sémantique n’apporte rien ici, elle risque même de brouiller, en ramenant des documents qui parlent du même sujet sans contenir la référence recherchée.
Elle a un second avantage, moins visible : la transparence. On comprend pourquoi un document remonte, puisqu’il contient le terme. Quand un résultat est faux, on peut l’expliquer et le corriger en ajustant les champs ou les poids. Cette prévisibilité est précieuse dans les métiers où l’on doit justifier une réponse, comme le support technique ou le juridique.
Enfin, elle ne dépend d’aucun modèle externe. Pas d’embeddings à générer ni à mettre à jour, pas de coût de vectorisation, pas de dérive quand le modèle change. Pour un corpus stable et des requêtes précises, c’est souvent l’option la plus simple et la plus robuste.
Ce que la recherche sémantique apporte en plus
La recherche sémantique change la donne quand la requête et le document ne partagent pas le vocabulaire. Un utilisateur qui cherche « comment annuler ma commande » doit trouver le passage intitulé « procédure de rétractation ». Aucun mot en commun, et pourtant c’est la bonne réponse. C’est exactement ce cas que les embeddings traitent : ils rapprochent les textes par le sens, pas par la surface.
Elle est également supérieure pour les questions reformulées, les synonymes, les fautes de frappe, et les corpus multilingues où la question arrive dans une langue et le document dans une autre. Un même espace vectoriel peut rapprocher « délai de livraison » et « combien de temps pour recevoir mon colis », là où la recherche lexicale ne trouve rien.
Sa limite est le coût et l’opacité : il faut générer et stocker des embeddings, choisir un modèle, et l’on ne voit pas directement pourquoi deux textes sont jugés proches. Un faux positif sémantique est plus difficile à corriger qu’un faux positif lexical, parce qu’il n’y a pas de terme fautif à pointer.
Les cas où la sémantique se trompe
Il faut être lucide sur les échecs de la recherche sémantique, car ils sont moins visibles que ceux du plein-texte. Premier cas : les correspondances exactes. Si un document contient un identifiant précis et que la requête le cite, la recherche sémantique peut le noyer parmi des documents qui parlent du même thème sans contenir l’identifiant. Elle perd là où le plein-texte gagne.
Deuxième cas : les corpus très techniques, où le vocabulaire spécialisé compte. Deux textes proches en apparence peuvent dire des choses opposées sur un point précis, et la similarité vectorielle moyenne l’écart. Le plein-texte, qui s’accroche au terme exact, est plus fiable pour ces nuances.
Troisième cas : les données structurées, comme les tables ou les métadonnées. Les embeddings traitent mal les champs numériques, les dates et les hiérarchies. Un filtre sur une période ou un statut relève du plein-texte ou d’un filtre SQL, pas de la similarité vectorielle.
L’hybride, presque toujours la bonne réponse
Dans la majorité des systèmes réels, la bonne architecture combine les deux : une première passe lexicale pour les correspondances exactes, une passe sémantique pour les reformulations, puis une fusion des résultats. C’est ce qu’on appelle la recherche hybride, et elle couvre les cas des deux familles.
Le schéma courant est simple. On indexe le corpus deux fois : une fois en plein-texte, une fois en vecteurs. À chaque requête, on lance les deux recherches, on fusionne les listes avec un score combiné, et on passe le haut du classement au modèle de langage. Le surcoût est modeste, le gain est important, parce qu’on ne perd plus les requêtes que l’une des deux méthodes ratait seule.
L’étape qui améliore le plus les résultats est le reclassement : une fois les candidats récupérés, un modèle de reclassement relit la requête et chaque passage, et réordonne. C’est à ce stade que l’on gagne en précision sur les cas difficiles, plus qu’en ajoutant des candidats ou en changeant le modèle d’embeddings.
Comment trancher sur vos données
La décision ne se tranche pas dans l’abstrait, elle se mesure sur votre corpus. Le bon point de départ est de réunir une cinquantaine de vraies requêtes, avec pour chacune le passage attendu, puis de comparer les deux méthodes sur ce jeu de test. Le taux de réussite observé dit bien plus qu’un raisonnement théorique.
Ce jeu d’évaluation sert ensuite en continu : à chaque changement de modèle, de chunking ou de pondération, on relance la mesure et on voit si l’on a gagné ou perdu. C’est la seule façon d’améliorer un système de recherche sans avancer à l’aveugle, et elle s’applique aussi bien au plein-texte qu’aux embeddings.
Le résultat typique de cette mesure est celui que l’on vient de décrire : chacune des méthodes gagne sur une partie des requêtes, et l’hybride gagne sur presque toutes. Mais la mesure vous le confirmera sur vos données, et c’est elle qui doit guider, pas l’intuition.
L’accompagnement Agenticiel pour votre recherche de documents
Construire un système de recherche hybride qui tient en production demande de la méthode : préparer le corpus, choisir les modèles, mettre en place le jeu d’évaluation, puis itérer. Agenticiel accompagne les PME qui veulent brancher un modèle de langage sur leurs documents sans passer par une suite d’essais et d’erreurs coûteux.
Nous construisons le pipeline de bout en bout, de l’indexation au reclassement, avec une mesure de qualité sur vos propres requêtes plutôt que sur des benchmarks génériques. Le développement est assuré par une équipe offshore francophone, basée à Madagascar, qui travaille dans votre langue et sur votre fuseau horaire. La sous-traitance de développement vous permet d’accéder à cette expertise sans recruter une équipe interne dédiée.
Notre approche consiste à mesurer avant de choisir : nous testons plein-texte, sémantique et hybride sur vos données réelles, et nous ne retenons que l’architecture qui gagne sur vos requêtes, pas celle qui gagne en théorie.