Qu’est-ce qu’une base de données vectorielle ? Embeddings, similarité et RAG

Une base de données vectorielle stocke des représentations numériques de vos documents, appelées embeddings, et permet de retrouver ceux qui se ressemblent par le sens plutôt que par les mots exacts. C’est la brique technique qui permet à un système de RAG de retrouver un passage pertinent même s’il ne contient aucun des mots de la question posée. Mais elle n’est pas toujours indispensable : dans bien des cas, un bon moteur full-text, ou une combinaison des deux, suffit largement.

Une base vectorielle, c’est quoi exactement ?

Une base de données classique (relationnelle ou documentaire) organise l’information en lignes, colonnes ou champs, et sait très bien répondre à des requêtes exactes : « trouve la facture n° 2024-0456 ». Une base de données vectorielle répond à une autre question : « trouve les passages qui parlent de la même chose que cette phrase ». Pour cela, elle ne stocke pas du texte brut mais des vecteurs : des listes de nombres (souvent 384, 768 ou 1 536 dimensions) qui positionnent chaque fragment de texte dans un espace mathématique où la proximité géométrique traduit une proximité de sens.

Concrètement, un moteur vectoriel est composé de trois éléments : un modèle d’embedding qui transforme le texte en vecteurs, un index qui organise ces vecteurs pour les retrouver rapidement, et un algorithme de similarité qui calcule la distance entre un vecteur de requête et les vecteurs stockés. Si vous découvrez le sujet, l’article Qu’est-ce que le RAG (génération augmentée par récupération) ? Le guide pratique pose les bases du mécanisme complet, de la question posée à la réponse générée.

Les embeddings : transformer du texte en coordonnées

Un modèle d’embedding est entraîné à placer des phrases de sens proche à des coordonnées voisines. « Résiliation du contrat » et « fin anticipée de l’abonnement » n’ont presque aucun mot en commun, mais leurs vecteurs seront proches, car le modèle a appris que ces expressions renvoient à une notion similaire. À l’inverse, « rupture de contrat » et « rupture de stock » partagent un mot mais pointeront vers des régions différentes de l’espace vectoriel.

Cette capacité à capter le sens au-delà des mots exacts est ce qui rend la recherche sémantique précieuse pour des documents rédigés en langage naturel : contrats, politiques internes, documentation produit, e-mails de support. Elle a en revanche ses limites sur des contenus très structurés (références, codes articles, numéros de série), où une correspondance exacte reste plus fiable qu’une similarité approximative.

La recherche par similarité : comment un moteur retrouve l’aiguille dans la botte de foin

Une fois les vecteurs calculés, il faut comparer celui de la question posée à ceux de tous les passages indexés, puis renvoyer les plus proches. La mesure de distance la plus courante est la similarité cosinus (l’angle entre deux vecteurs), parfois remplacée par le produit scalaire ou la distance euclidienne selon le modèle utilisé. Sur quelques centaines de passages, une comparaison brute (dite « flat » ou « exhaustive ») est instantanée. Le problème commence à partir de centaines de milliers, voire de millions de vecteurs : comparer la requête à chacun d’eux devient trop coûteux en temps de calcul.

Les index HNSW, IVF et consorts

C’est là qu’interviennent les index de recherche approximative des plus proches voisins (ANN, pour Approximate Nearest Neighbors). Ils acceptent de sacrifier un peu d’exactitude pour gagner énormément en vitesse.

Le choix de l’index n’est pas anodin : il conditionne le temps de réponse, la consommation mémoire et la qualité des résultats. C’est un des aspects que détaille l’article Chunking, indexation, recherche : comment fonctionne un pipeline RAG, utile si vous voulez comprendre toute la chaîne entre le découpage d’un document et la réponse finale.

Base vectorielle, full-text ou recherche hybride : que choisir ?

La recherche vectorielle n’est pas une solution miracle qui remplace tout le reste. Un moteur full-text classique (type BM25, utilisé par exemple par Elasticsearch ou Postgres) reste imbattable pour retrouver des termes exacts, des références, des acronymes ou des numéros. La recherche vectorielle, elle, excelle quand la question est formulée différemment du document source. La recherche hybride combine les deux : elle croise les scores du full-text et de la similarité sémantique pour obtenir le meilleur des deux mondes, avec en plus une expansion de mots-clés qui aide à rapprocher synonymes et formulations voisines.

Quand avez-vous vraiment besoin d’une base vectorielle pour un projet RAG ?

Avant d’investir du temps dans une infrastructure vectorielle dédiée, posez-vous quelques questions simples.

• Vos utilisateurs posent-ils des questions en langage naturel, avec des formulations variées, plutôt que des recherches par mots-clés précis ?
• Votre corpus dépasse-t-il quelques dizaines de documents, avec un vocabulaire métier riche en synonymes (juridique, RH, support client) ?
• Avez-vous besoin de retrouver un passage pertinent même si la question ne reprend aucun mot exact du document ?
• Le volume de contenu va-t-il croître dans le temps, au point de rendre une recherche exhaustive trop lente ?
• Devez-vous générer une réponse argumentée avec des passages cités, plutôt qu’une simple liste de résultats ?

Si vous répondez oui à plusieurs de ces points, la recherche sémantique (vectorielle ou hybride) apporte une vraie valeur. Si en revanche votre usage principal consiste à retrouver des fiches techniques par référence, ou un catalogue de quelques dizaines d’entrées très structurées, un bon moteur full-text peut suffire, sans la complexité d’un pipeline d’embeddings à maintenir.

Reste la question de l’infrastructure : héberger soi-même une base vectorielle implique de choisir un modèle d’embedding, de gérer sa cohérence dans le temps (un changement de modèle oblige souvent à tout ré-indexer), de dimensionner l’index et de surveiller la pertinence des résultats. L’article RAG as a service : définition, alternatives et quand l’utiliser détaille les compromis entre monter sa propre stack et utiliser un service managé.

Les pièges courants à connaître

• Changer de modèle d’embedding sans tout ré-indexer : les anciens et nouveaux vecteurs ne sont pas comparables entre eux.
• Mal découper les documents : des chunks trop longs diluent le sens, trop courts perdent le contexte (un sujet traité dans Préparer ses documents pour l’IA : rédiger un corpus qui donne de bonnes réponses).
• Sous-estimer le coût mémoire d’un index HNSW à grande échelle, qui peut dépasser celui des documents originaux.
• Oublier de réévaluer la pertinence des réponses dans le temps, à mesure que le corpus grossit et change.
• Choisir le RAG alors qu’un ajustement du modèle (fine-tuning) répondrait mieux au besoin, ou inversement (un arbitrage détaillé dans RAG ou fine-tuning : que choisir pour vos documents métier ?).

Questions fréquentes