Une base de données vectorielle stocke les données sous forme de vecteurs numériques à haute dimension et récupère les enregistrements par similarité plutôt que par valeur exacte. Au lieu de demander « trouver la ligne où id = 42 », vous demandez « trouver les lignes les plus similaires à cette requête ». C'est pourquoi elle constitue la couche de stockage standard pour la recherche sémantique, la recommandation et la génération augmentée par récupération.
Pourquoi des vecteurs, et non des lignes
La plupart des données qui importent dans les pipelines d'IA, textes, images, audio, ne possèdent pas de clé primaire naturelle sur laquelle effectuer une correspondance. Ce que vous cherchez à savoir, c'est : quels éléments stockés sont proches en sens de cette nouvelle entrée ?
Un modèle d'embedding convertit chaque élément en vecteur : une liste de nombres, souvent de centaines ou de milliers de dimensions, où la position dans cet espace encode le sens sémantique. Deux phrases qui disent la même chose avec des mots différents produiront des vecteurs proches l'un de l'autre. Deux phrases de sens opposé seront éloignées.
Une base de données vectorielle indexe ces vecteurs afin que les requêtes de voisinage le plus proche s'exécutent en quelques millisecondes, même sur des millions ou des milliards d'enregistrements.
Fonctionnement de la recherche par similarité
La mesure de similarité la plus courante est la similarité cosinus : l'angle entre deux vecteurs. D'autres mesures incluent le produit scalaire et la distance euclidienne. La recherche exacte du voisin le plus proche sur de grands ensembles de données est coûteuse en calcul ; la plupart des systèmes utilisent donc des algorithmes de voisinage approximatif (ANN). Ceux-ci sacrifient une petite quantité contrôlable de rappel en échange de gains de vitesse importants. Les stratégies d'indexation courantes comprennent HNSW (Hierarchical Navigable Small World) et IVF (Inverted File Index).
Il est généralement possible de combiner la similarité vectorielle avec des filtres classiques : « trouver les dix documents les plus similaires, mais uniquement parmi les données de ce client, publiés après cette date ». Cette requête hybride est la manière dont la plupart des systèmes en production utilisent les bases de données vectorielles dans la pratique.
Les bases de données vectorielles en production
- Pipelines RAG. Des extraits de texte sélectionnés par similarité sémantique avec la question de l'utilisateur sont transmis à un modèle de langage en tant que contexte. La base de données vectorielle est ce qui rend la récupération rapide et pertinente. Voir qu'est-ce que RAG pour une présentation complète.
- Recherche sémantique. Catalogues de produits, bases de connaissances du support, fonds documentaires juridiques : partout où la recherche par mots-clés échoue parce que les utilisateurs formulent les choses différemment de la façon dont les documents sont rédigés.
- Recommandation. Les embeddings d'utilisateurs et d'éléments sont stockés ; la recherche par similarité trouve les éléments proches de ce avec quoi un utilisateur a interagi.
- Déduplication et regroupement. Détection d'enregistrements quasi-duplicates ou regroupement d'éléments similaires, sans avoir besoin d'une correspondance exacte de chaîne de caractères.
Systèmes dédiés versus extensions
Certaines équipes utilisent des bases de données vectorielles conçues spécifiquement à cet effet. D'autres optent pour une extension vectorielle greffée sur une base de données relationnelle qu'elles exploitent déjà. Les deux approches sont utilisées en production à grande échelle. Le bon choix dépend du volume de requêtes, des exigences de latence, de la nécessité de garanties transactionnelles fortes sur les mêmes enregistrements, et de la familiarité opérationnelle. Il n'existe pas de réponse universelle.
Le lien avec la fenêtre de contexte
La recherche vectorielle est en partie un contournement des limites des fenêtres de contexte. Il est impossible de transmettre l'intégralité d'une base de connaissances à un modèle de langage ; vous en récupérez les tranches pertinentes et vous les transmettez. À mesure que les fenêtres de contexte s'élargissent, le calcul évolue, mais la récupération reste plus rapide et moins coûteuse que d'insérer tout le contenu dans un prompt, et elle maintient la source de vérité en dehors du modèle.
Ce que nous évaluons
Les ingénieurs qui travaillent sur des pipelines RAG ou de recherche sémantique doivent savoir appeler l'API d'une base de données vectorielle. Surtout, ils doivent évaluer si la recherche fonctionne réellement : les embeddings choisis conviennent-ils, la stratégie de découpage (chunking) change-t-elle le rappel, et dans quels cas une approche à base de modèle est le mauvais outil. Notre sélection couvre la conception de l'évaluation et le jugement sur la qualité de la recherche dans l'évaluation des ingénieurs IA. Le détail se trouve sur la page comment nous sélectionnons nos ingénieurs.
Réponses courtes
Quelle est la différence entre une base de données vectorielle et une base de données classique ?
Une base de données classique récupère les enregistrements par valeur exacte ou par plage. Une base de données vectorielle récupère par similarité : quels vecteurs stockés sont les plus proches d'un vecteur de requête. Elles répondent à des questions différentes et sont souvent utilisées conjointement dans le même système.
Faut-il une base de données vectorielle dédiée, ou une base de données relationnelle suffit-elle ?
Les deux fonctionnent en production. Les systèmes dédiés offrent généralement de meilleures performances à volume de requêtes élevé. Les extensions relationnelles sont plus simples à exploiter si vous utilisez déjà cette base de données. Le bon choix dépend de l'échelle, des exigences de latence et de la familiarité de l'équipe.
Une base de données vectorielle est-elle la même chose qu'un pipeline RAG ?
Non. Une base de données vectorielle est l'un des composants d'un pipeline RAG. RAG implique également un modèle d'embedding, une stratégie de découpage, un modèle de langage et une couche d'orchestration. La base de données gère le stockage et la récupération ; le reste du pipeline assemble et exploite ce qu'elle retourne.
