Comment fonctionne une base de données vectorielle : embeddings, recherche vectorielle et mémoire humaine

Des années peuvent s’écouler sans qu’on pense ne serait-ce qu’une fois à son professeur d’enfance. Puis, une odeur de poussière de craie, l’arôme de la cantine scolaire ou une chanson qui passait pendant le trajet en bus pour rentrer à la maison font immédiatement et vivement réapparaître cette personne. Rien n’a été recherché par son nom ; quelque chose de similaire est apparu, et le souvenir est remonté à la surface de lui-même.

C’est ce que les systèmes de recherche sémantique, de génération améliorée par la récupération d’informations (RAG) et les systèmes de recommandation basés sur l’IA tentent de reproduire, de manière imparfaite mais sérieuse, et l’élément qui rend cela possible est la base de données vectorielle. Le rappel par association constitue un bon modèle mental pour expliquer ce qu sont les vecteurs, comment on mesure la similarité, comment fonctionne la recherche du voisin le plus proche, et comment ces éléments forment un pipeline de récupération. Il montre également où cette analogie cesse de valoir, car ce sont précisément les points où les systèmes en production ont tendance à faire des erreurs.

Stockage par sens plutôt que par nom

La mémoire humaine ne dispose d’aucun index alphabétique. Il n’existe pas de dossier mental intitulé « Aliments » contenant un sous-dossier « Italien » avec un fichier nommé « Pizza ». C’est cette hiérarchie stricte qui permet à une base de données conventionnelle d’organiser les données : chaque enregistrement se trouve à une adresse connue et est retrouvé grâce à une clé précise.

La mémoire, elle, est organisée par sens et par associations : en fonction du contexte, des émotions, de la manière dont une chose est liée aux autres. L’idée de pizza est associée aux vendredis soir, à un voyage à Naples, aux plats réconfortants, aux tranches de fromage étirées, à l’arôme de l’origan, et peut-être aussi à un colocataire d’université qui a gâché chaque lot de pâte faite maison. Penser à la pizza ne déclenche pas l’ouverture d’un seul fichier ; cela active plutôt tout un réseau de souvenirs liés entre eux, en commençant par ceux qui sont les plus fortement associés.

Une base de données vectorielle s’appuie précisément sur ce principe. Les éléments y sont stockés en fonction de leur signification, et ils sont récupérés en fonction de leur similarité avec la requête, et non en fonction d’une correspondance exacte avec une clé.

Ce que code un vecteur d’incorporation

Pour comprendre cette base de données, il faut d’abord comprendre ce qu’elle contient. Un vecteur, ici, n’est rien de plus qu’une liste ordonnée de nombres représentant une signification.

Une machine n’a pas de notion concrète de ce qu’est la pizza. Ce qu’un modèle d’incorporation peut apprendre, en traitant d’énormes quantités de texte, c’est l’association que conserve un mot. Le mot « pizza » apparaît à proximité de « fromage », « italien », « pâte », « four » et « tranche ». Ces termes sont différents de ceux associés à « sushi », mais présentent de fortes similitudes avec ceux liés à « pain plat » ou « calzone ».

Le modèle condense ces motifs en une liste de nombres de longueur fixe, généralement allant de quelques centaines à quelques milliers de valeurs ; 384 et 1 536 constituent des tailles typiques. Aucun nombre en particulier ne porte d’étiquette lisible, mais ensemble ils positionnent l’élément avec précision dans un espace à haute dimension. La propriété importante est la suivante : les entrées ayant des significations similaires se voient attribuer des vecteurs situés proches les uns des autres. « Pizza » se trouve près de « pain plat » et très éloigné du « rapport de résultats trimestriels ».

En d’autres termes, le sens est transformé en distance. Tout le reste découle de cette seule transformation.

Similitude en tant que spectre, et non en tant que correspondance

Une requête traditionnelle est binaire : une ligne satisfait soit à la condition, soit non. En filtrant par « chien », on obtient des lignes contenant exclusivement le mot « chien », sans aucun résultat pour « chiot », « golden retriever » ou « fidèle compagnon à quatre pattes ».

La similarité sémantique remplace cette réponse oui/non par une note indiquant à quel point deux significations sont proches. Sur une échelle illustrative, « chiot » pourrait obtenir une note de 0,94 par rapport à « chien », « loup » environ 0,71, et « facture » autour de 0,08. La métrique utilisée est généralement la similarité cosinus ou une distance apparentée telle que le produit scalaire ou la distance euclidienne, et le choix approprié dépend de la manière dont le modèle d’incorporation a été entraîné.

Cela reflète l’effet de la poussière de craie : ce n’est pas une correspondance exacte, mais un indice qui active des souvenirs proches, lesquels à leur tour activent leurs voisins. Dans une base de données vectorielle, les mécanismes sont numériques. La requête est convertie en un vecteur, et la base de données renvoie les éléments stockés dont les vecteurs sont les plus proches du sien. Proche signifie similaire en sens.

C’est pourquoi une recherche pour « comment corriger une requête de base de données lente » peut faire apparaître un document intitulé « optimisation de la performance des requêtes à grande échelle », même si les deux phrases ne partagent quasiment aucun mot. Leurs vecteurs sont proches car ils expriment la même intention.

Une mise en garde concernant les chiffres

Les scores de similarité sont relatifs, et non absolus. Un score de 0,8 obtenu avec un modèle d’incorporation ne peut pas être comparé à un score de 0,8 obtenu avec un autre modèle, et même au sein d’un même modèle, la fourchette typique dépend du domaine. Considérez ces scores comme un moyen de classer les candidats, et si vous appliquez un seuil, calibrez-le à l’aide de vos propres données plutôt que de choisir un nombre rond.

Correction importante : le SQL classique basé sur des mots-clés ne peut pas exprimer de similarité sémantique, mais cela ne signifie pas pour autant que les bases de données SQL sont excluses. Des extensions telles que pgvector, abordées ci-dessous, ajoutent des colonnes vectorielles et des opérateurs de similarité à Postgres, permettant ainsi cette fonctionnalité au sein d’une base de données relationnelle.

Recherche du voisin le plus proche à grande échelle

Comment la base de données localise-t-elle réellement les vecteurs les plus proches ? L’opération principale s’appelle recherche du voisin le plus proche, et c’est justement pour la rendre rapide que les bases de données vectorielles existent.

Imaginez chaque élément stocké comme une étoile dans une galaxie, disposée en fonction de son sens, avec des éléments similaires regroupés dans la même région. Une requête ajoute une nouvelle étoile à cette galaxie et demande quels sont les cinq étoiles existantes les plus proches.

La méthode naïve mesure la distance entre la requête et chaque vecteur stocké, classe les résultats et renvoie les meilleurs. Pour des milliers de vecteurs, c’est rapide et tout à fait suffisant. Mais pour des millions ou des milliards, comparer avec tous devient très coûteux en temps très rapidement.

Les systèmes de production s’appuient donc sur des algorithmes d’approximation du voisin le plus proche. Au lieu d’examiner chaque étoile, ils utilisent un index qui réduit la recherche aux régions prometteuses, acceptant une légère perte en précision en échange d’une grande amélioration de la vitesse. L’algorithme le plus utilisé aujourd’hui est HNSW, pour Hierarchical Navigable Small World. Vous n’avez pas besoin de connaître son fonctionnement interne pour utiliser une base de données vectorielle, mais vous devez savoir qu’il est la raison pour laquelle une recherche sur cent millions d’embeddings peut être effectuée en quelques millisecondes.

Le terme « approximatif » mérite attention. Un index ANN peut parfois manquer le véritable voisin le plus proche, et le taux auquel il trouve les vrais meilleurs résultats, appelé rappel, dépend de paramètres d’index qui compromettent mémoire et latence au profit de la précision. Si la qualité des recherches semble inexplicablement irrégulière à grande échelle, il vaut la peine de vérifier les paramètres d’index ; notre guide sur l’ajustement des index HNSW pour les systèmes RAG en production aborde en détail ces paramètres.

Dans la base de données vectorielle

En son essence, une base de données vectorielle est un système de stockage optimisé pour une seule tâche : conserver des vecteurs et effectuer très rapidement des recherches de voisin le plus proche sur eux.

Imaginez une bibliothèque qui ignore le système décimal de Dewey et qui range les livres en fonction de leur atmosphère. Les livres sur le deuil se trouvent à côté de ceux sur la perte, qui à leur tour sont côte à côte avec ceux sur la solitude, puis l’isolement, suivis de mémoires d’expéditions en solitaire. Personne n’a attribué manuellement ces catégories ; cet agencement est apparu parce que les lecteurs attirés par un type de contenu ont tendance à vouloir aussi les autres.

Pinecone, Weaviate, Chroma et Qdrant sont des exemples de telles bibliothèques. On y charge des embeddings de documents, des descriptions de produits, des images converties en vecteurs ou des schémas de comportement des utilisateurs, et elles maintiennent l’index afin que les recherches restent rapides même à mesure que la collection s’agrandit.

Chaque enregistrement stocké comprend généralement trois éléments :

• Un ID qui identifie de manière unique l’élément.
• Le vecteur qui représente son sens.
• Des métadonnées facultatives telles que le titre, la date, la catégorie ou l’URL de source, qui peuvent servir à filtrer les résultats.

Les métadonnées sont plus précieuses qu’il n’y paraît au premier abord. Une demande réaliste pourrait être la suivante : trouver les cinq documents les plus similaires à la requête, mais uniquement ceux des 30 derniers jours et provenant uniquement de la base de connaissances de l’équipe d’ingénierie. Il s’agit d’une recherche vectorielle combinée à un filtre de métadonnées, et la plupart des systèmes en production reposent sur cette combinaison. La manière dont le filtre est appliqué est également importante : filtrer après la recherche de similarité peut vous donner moins de résultats que demandé, il est donc nécessaire de vérifier si votre base de données effectue des filtrages pendant la recherche elle-même.

Le pipeline de récupération RAG du début à la fin

Que ce soit au sein d’un système RAG, d’une fonction de recherche sémantique ou de toute application utilisant des connaissances stockées, la récupération suit toujours les mêmes quatre étapes.

1. Intégrer le contenu. Chaque document, article, description de produit ou enregistrement que vous souhaitez rendre recherchable passe par un modèle d’incorporation, et le vecteur résultant est stocké aux côtés du contenu original. Les documents longs sont généralement divisés en parties au préalable, car un seul vecteur pour un manuel entier mélange trop d’idées entre elles.
2. Incorporer la requête avec le même modèle. Cela n’est pas optionnel. Différents modèles d’incorporation produisent des vecteurs dans des espaces non liés, de sorte que comparer une requête issue d’un modèle avec des documents provenant d’un autre modèle donne des distances sans signification. Changer de modèle signifie réincorporer l’ensemble de la collection.
3. Rechercher. Le vecteur de la requête est envoyé dans la base de données, la recherche de voisins les plus proches identifie les vecteurs stockés les plus proches, et les meilleurs résultats sont retournés, généralement accompagnés de scores de similarité.

Utilisez les résultats. Dans un pipeline RAG, les extraits récupérés sont transmis au modèle de langage en tant que contexte, de sorte que la réponse s’appuie sur des documents réels plutôt que sur des suppositions. Dans un système de recommandation, les résultats sont les suggestions mêmes. Dans une fonction de recherche, ce sont les résultats affichés à l’utilisateur.

Du point de vue de l’utilisateur, une réponse pertinente apparaît en quelques instants. En réalité, le sens a été transformé en nombres, ces nombres ont été comparés à des millions d’éléments stockés, les correspondances les plus proches ont été retournées, et une réponse a été élaborée à partir de contenu authentique.

Pourquoi la recherche vectorielle est partout aujourd’hui

Il y a peu encore, les bases de données vectorielles n’étaient qu’un outil de niche utilisé uniquement pour mettre en place des recherches sémantiques ou des systèmes de recommandation spécialisés. Aujourd’hui, elles font partie intégrante de nombreuses applications d’intelligence artificielle. Le RAG a besoin d’un endroit pour stocker et interroger les embeddings de documents. Les agents interrogent les bases de connaissances en se basant sur le sens. Les systèmes de recommandation à grande échelle fonctionnent grâce à la similarité vectorielle. La recherche multimodale, telle que la recherche d’images à partir d’une description textuelle ou de produits à partir d’une photo téléchargée, s’appuie également sur les vecteurs.

Si vous développez des applications utilisant des grands modèles de langage en production, il est fort probable que vous dépendiez déjà de la recherche vectorielle ou que vous y dépendiez bientôt. Ce qui est encourageant, c’est que l’idée de base est déjà familière : depuis toujours, notre mémoire récupère les associations les plus proches de tout ce qui atteint nos sens. Une base de données vectorielle fait de même avec des nombres, en quelques millisecondes, sur des millions d’éléments.

Où l’analogie avec la mémoire échoue

La comparaison avec le cerveau est utile pour l’intuition, mais quelques différences sont importantes en pratique :

• La mémoire s’adapte continuellement ; un modèle d’embedding est figé. Si le vocabulaire de votre domaine change, les vecteurs ne s’actualisent pas automatiquement.
• La mémoire intègre facilement le contexte ; un vecteur ne capture que ce qui y a été introduit. Un texte source mal segmenté ou bruité génère des voisins de mauvaise qualité.
• La similarité n’équivaut pas à la pertinence. Deux passages peuvent être proches en sens tout en ne répondant qu’à un seul la question, c’est pourquoi de nombreux systèmes ajoutent une recherche par mots-clés ou une étape de réclassement supplémentaire.

Se mettre à l’œuvre

Vous pouvez expérimenter sans avoir à mettre en place aucune infrastructure :

• ChromaDB s’exécute localement au sein de Python, sans compte, clé API ni déploiement, et il ne faut que quelques lignes de code pour l’installer et l’initialiser. Il convient bien à l’apprentissage et aux petits projets.
• Qdrant propose un niveau gratuit en cloud ainsi qu’un client Python pratique, idéal lorsque l’on souhaite quelque chose proche de l’environnement de production sans devoir gérer soi-même des serveurs. Vérifiez les limites actuelles avant de compter sur eux.
• pgvector est une extension de Postgres. Si vous utilisez déjà Postgres, elle ajoute une recherche vectorielle sans introduire de base de données distincte, ce qui simplifie l’ensemble du système.

Quelle que soit votre choix, le flux de travail reste identique : choisir un modèle d’embedding, embedder votre contenu, stocker les vecteurs, embedder les requêtes reçues et effectuer une recherche. Les concepts restent les mêmes ; seule la bibliothèque client change.

Le modèle mental en quelques lignes

• Une embedding transforme le sens en position, de sorte que les éléments similaires se retrouvent proches les uns des autres.
• Les scores de similarité classent les candidats ; calibrez tout seuil à l’aide de vos propres données.
• Les index ANN tels que HNSW sacrifient un peu de rappel pour des gains de vitesse importants à grande échelle.
• Les filtres de métadonnées transforment la similarité brute en réponses respectant les règles de temps, de source et d’accès.
• Les requêtes et les documents doivent partager un même modèle d’embedding, et la qualité de la récupération dépend autant du découpage et de la qualité des données que de la base de données elle-même.

Lectures complémentaires

• Comment fonctionnent vraiment les bases de données vectorielles : des embeddings à la recherche hybride : Explique comment les embeddings encodent le sens, comment la recherche et l’indexation par similarité s’échelonnent, et quand la recherche hybride et les bases de données vectorielles conviennent réellement aux systèmes d’IA d’entreprise.

Ajustement des index HNSW et échellement de la recherche vectorielle pour RAG en production : Découvrez comment les paramètres M et ef de HNSW influencent le taux de rappel, la latence et la mémoire, comment les configurer dans Chroma, et quand échelonner une base de données vectorielle verticalement ou par shardage.

Ingénierie du contexte basée sur des ontologies lorsque le RAG vectoriel ne suffit pas : Lorsque le sens s’étend sur des systèmes de données structurés, les embeddings seuls ne permettent pas de réaliser des jointures. L’ingénierie du contexte basée sur des ontologies valide les faits typés, l’origine des données et les outils de voisinage pour obtenir des réponses fiables issues de modèles de langage grand public.