Pourquoi la recherche vectorielle plutôt que le plein-texte

Quand on construit la brique de retrieval d'un RAG, une décision structure tout le reste : comment décide-t-on qu'un passage est « pertinent » pour une question ? Deux familles de réponses s'affrontent en apparence. La recherche plein-texte compare des mots. La recherche vectorielle (sémantique) compare du sens. Ce document explique pourquoi le vectoriel est le choix par défaut d'un RAG, ce qu'il coûte, et pourquoi opposer les deux est un faux débat.

Ce document explique le pourquoi. Pour le comment (métrique cosinus, index kNN, score, contrats du composant), voir la référence du moteur RAG. Pour le parcours pas à pas, voir le tutoriel « RAG de bout en bout ».

Le problème : une question n'utilise presque jamais les mots de la réponse

Un utilisateur ne connaît pas le vocabulaire exact de votre documentation. Il tape « comment protéger mon site » là où le document parle de « durcissement TLS et en-têtes HTTP ». Il demande « c'est lent » là où la page traite de « latence et cache de prompt ». Il pose une question en langage naturel — une phrase, une intention — quand le corpus contient des affirmations techniques.

Le fossé entre la formulation de la question et celle de la réponse est la difficulté centrale du retrieval. Toute la valeur d'un RAG dépend de la capacité à le franchir. Les deux approches le franchissent très différemment.

Le plein-texte : trouver les mots

La recherche plein-texte indexe les termes d'un document. À la requête, elle retrouve les documents qui contiennent les mots de la question, pondérés par leur rareté (un mot rare discrimine mieux qu'un mot courant) et leur fréquence dans le document.

C'est une mécanique lexicale : elle raisonne sur des chaînes de caractères, éventuellement normalisées (minuscules, radicaux, pluriels). Ses qualités sont réelles et souvent sous-estimées :

• Exactitude sur les termes rares : un code d'erreur, un identifiant, un nom de fonction, une référence de norme — le plein-texte les retrouve au caractère près. Un embedding, lui, peut « diluer » un token rare dans le sens global de la phrase.
• Transparence : on comprend pourquoi un résultat remonte (il contient le mot). C'est auditable, prévisible, sans surprise.
• Coût quasi nul : indexer un mot ne demande aucun modèle, aucun calcul vectoriel, aucun service externe.

Sa limite est structurelle : il ne connaît que les mots qu'on lui donne. « Voiture » et « automobile » sont pour lui deux chaînes étrangères. Une question reformulée avec un vocabulaire différent de celui du corpus rate sa cible, même si la réponse est là, exprimée autrement.

Le vectoriel : trouver le sens

La recherche vectorielle change de terrain. Chaque passage est transformé, par un modèle d'embeddings, en un vecteur : une liste de nombres qui encode son sens. La propriété fondamentale de cet espace est que deux textes proches par le sens ont des vecteurs proches, indépendamment des mots employés.

Dès lors, chercher ne consiste plus à comparer des mots mais à mesurer une distance géométrique entre le vecteur de la question et ceux des passages. Le passage le plus « proche » est le plus pertinent — même s'il ne partage aucun mot avec la question.

C'est ce qui débloque les usages qu'un RAG exige :

• Synonymes et paraphrases : « protéger mon site » retrouve « durcissement et en-têtes HTTP » parce que les deux vivent au même endroit de l'espace de sens.
• Questions en langage naturel : une phrase interrogative se compare proprement à une affirmation, là où le plein-texte butait sur la différence de forme.
• Robustesse à la formulation : reformuler la question sans changer l'intention retrouve les mêmes passages. C'est précisément ce qu'on veut d'un assistant documentaire — et ce qu'on teste explicitement (une question et sa reformulation doivent converger).

Le rôle asymétrique de la question et du passage

Un point contre-intuitif éclaire pourquoi le vectoriel est taillé pour le RAG : une bonne chaîne d'embeddings encode différemment un texte selon son rôle. Un passage à indexer et une question à poser ne sont pas traités de la même manière (souvent via des préfixes distincts, de type passage / requête). Le modèle apprend ainsi que « la relation utile n'est pas passage↔passage mais question↔passage » — exactement l'asymétrie d'un RAG, où de courtes questions doivent retrouver de longs extraits. Le plein-texte, lui, ne distingue pas les rôles.

Les compromis du vectoriel (les rendre explicites)

Choisir le vectoriel n'est pas gratuit. Un ingénieur honnête pose la facture sur la table :

• Coût de vectorisation. Chaque passage indexé et chaque question posée doit passer par un modèle d'embeddings — un calcul, souvent un appel réseau à un service dédié. Le plein-texte n'a rien de tout cela. Ce coût se paie à l'ingestion (une fois, par lots) et à chaque requête (sur la seule question).
• Un index spécialisé. Stocker et interroger des vecteurs demande une structure de recherche par plus proches voisins (kNN), qui n'est pas un index texte ordinaire. C'est une dépendance technique supplémentaire à installer, configurer et maintenir.
• Faiblesse sur l'exact et le rare. C'est le revers exact de sa force. Là où le plein-texte excelle — codes, identifiants, termes rares, correspondance au caractère près — le vectoriel est plus flou : il capte le sens global et peut « lisser » le détail qui, justement, faisait toute la requête.
• Opacité relative. Un résultat remonte parce qu'il est « proche » dans un espace à plusieurs centaines de dimensions. C'est moins immédiatement explicable qu'un mot surligné. D'où l'importance d'un seuil de score pour écarter les voisins trop lointains : sans lui, on injecte du bruit que le modèle de génération prendra pour du contexte fiable.
• Dépendance au modèle. La qualité du retrieval plafonne à celle du modèle d'embeddings, et changer de modèle impose de tout réindexer (les vecteurs d'un modèle ne sont pas comparables à ceux d'un autre).

Pourquoi ce n'est pas un choix binaire

Présenter plein-texte et vectoriel comme rivaux est une erreur de cadrage. Leurs forces et leurs faiblesses sont symétriques :

Là où l'un est fort, l'autre est faible. C'est la définition même de deux approches complémentaires. En pratique, les systèmes de retrieval mûrs les combinent (recherche hybride) : le vectoriel assure le rappel sémantique (retrouver ce qui veut dire la même chose), le plein-texte garantit la précision lexicale (ne pas rater le code d'erreur ou l'identifiant que l'utilisateur a tapé au caractère près).

Pourquoi, alors, le vectoriel est-il le choix par défaut d'un RAG ? Parce que le mode d'entrée d'un RAG est la question en langage naturel, et que le premier échec à éviter est le silence : ne rien remonter parce que l'utilisateur n'a pas deviné le vocabulaire du corpus. Le vectoriel adresse frontalement ce risque. Le plein-texte reste une couche d'appoint précieuse — pas le socle. On part du sens, on renforce avec les mots ; rarement l'inverse.

À retenir

• Le plein-texte compare des mots ; le vectoriel compare du sens via des embeddings et une distance géométrique.
• Le vectoriel franchit le fossé entre la formulation de la question et celle de la réponse (synonymes, paraphrases, langage naturel) — le besoin central d'un RAG.
• Il se paie : vectorisation, index spécialisé, moins bon sur l'exact/rare, moins explicable, dépendant du modèle.
• Les deux approches sont complémentaires, pas opposées. Le vectoriel est le socle par défaut d'un RAG ; le plein-texte, une couche d'appoint sur les termes exacts.

Suite naturelle : la référence du moteur RAG (mécanique de la recherche kNN cosinus et du score) et le tutoriel « RAG de bout en bout » (mise en œuvre pas à pas).