Définition en une phrase
Sistema que almacena vectores y permite recuperar elementos próximos según una métrica de similitud.
Qu’est-ce qu’une base de données vectorielle ?
Une base de données vectorielle est un système qui stocke des vecteurs — des listes de nombres représentant des données — et permet de rechercher ceux qui sont les plus proches d’un vecteur de requête, selon une métrique donnée. Elle vise à faciliter les recherches par similarité dans des ensembles de représentations numériques, par exemple pour retrouver des textes, des produits ou des images associés à une requête.
La base de données travaille avec les vecteurs qu’elle reçoit. Un modèle ou un autre composant transforme généralement la donnée d’origine en une représentation numérique appelée embedding. La création de l’embedding et la recherche qui suit sont deux opérations distinctes : stocker des vecteurs ne signifie pas que la base de données les a créés, qu’elle a compris le contenu ou qu’elle a confirmé l’équivalence de deux éléments.
Dans une application, le vecteur est généralement associé à un identifiant. Il peut aussi être accompagné de métadonnées, comme une catégorie ou une date, et d’une référence à la donnée d’origine. Le contenu complet peut se trouver dans le même système ou dans un autre. Les types de données acceptés, les fonctions proposées et leur mise en œuvre varient selon les produits : l’expression « base de données vectorielle » ne désigne pas une architecture unique.
Ce qu’un enregistrement contient et comment une requête est traitée
Un enregistrement vectoriel peut comprendre un identifiant, le vecteur, des métadonnées et une référence à l’objet associé. Pour un fragment de documentation, par exemple, on pourrait stocker le vecteur, l’identifiant du document, la langue et l’emplacement du fragment. Le texte d’origine pourrait rester dans la base de données ou être récupéré depuis un autre espace de stockage.
Le parcours habituel comporte plusieurs étapes. L’application prend la donnée à indexer et la transmet à un modèle d’embeddings ; elle reçoit un vecteur qu’elle stocke avec un identifiant. Lorsqu’une requête arrive, le système génère un vecteur de requête compatible — ou le reçoit d’un autre composant — puis demande les plus proches voisins. L’application peut ensuite récupérer les données d’origine, appliquer des règles métier ou présenter les résultats.
La compatibilité entre les vecteurs stockés et celui de la requête est importante. S’ils proviennent de modèles différents, de configurations incompatibles ou d’espaces de représentation qui ne correspondent pas, leur comparaison risque de ne pas être utile. La base de données ne peut pas corriger automatiquement une représentation inadaptée.
De la donnée aux résultats
- 01Préparer la donnée et générer son embedding avec un modèle adapté à la tâche.
- 02Stocker le vecteur avec un identifiant et, si nécessaire, des métadonnées ou une référence à l’original.
- 03Convertir la requête en un vecteur compatible et rechercher les plus proches voisins selon la métrique choisie.
- 04Récupérer les données associées et évaluer les résultats à l’aide des règles et critères propres à l’application.
Comment mesurer la proximité
Une recherche a besoin d’une règle pour comparer les vecteurs. Parmi les mesures courantes figurent la similarité cosinus, le produit scalaire et la distance euclidienne. Ces termes ne sont pas interchangeables : ils calculent des relations différentes et leurs résultats peuvent être classés ou interprétés différemment.
La similarité cosinus compare l’orientation des vecteurs ; la distance euclidienne mesure l’écart entre leurs points ; le produit scalaire combine leurs composantes et peut dépendre de la norme des vecteurs. Le choix ne devrait pas être fait par habitude uniquement. Il doit être cohérent avec le modèle, la manière dont ses vecteurs ont été générés ou normalisés et l’objectif de l’application.
Il est utile de vérifier la configuration de bout en bout : quelle métrique l’implémentation propose, laquelle est utilisée par l’index et comment les résultats sont classés ou présentés. Une étiquette comme « similarité » ne garantit pas que deux produits calculent la même valeur, ni qu’une valeur élevée ait la même interprétation dans tous les systèmes.
Repères pour choisir une mesure
Ce tableau est conceptuel et ne remplace pas la documentation du modèle ni celle de l’implémentation utilisée.
| Mesure | Ce qu’elle compare, en général | Points à vérifier |
|---|---|---|
| Similarité cosinus | L’orientation relative des vecteurs. | Vérifier que le modèle et l’implémentation sont configurés pour cette mesure, ainsi que le classement des résultats. |
| Produit scalaire | La somme des produits des composantes ; la norme peut avoir une influence. | Vérifier que l’influence de la norme correspond au comportement attendu des vecteurs générés. |
| Distance euclidienne | L’écart géométrique entre les vecteurs. | Vérifier que la distance et son classement correspondent à l’objectif et à la configuration du système. |
Recherche exacte et recherche approximative
Lors d’une recherche exacte, le système compare la requête à tous les vecteurs de l’ensemble considéré et renvoie les meilleurs résultats selon la métrique. C’est un point de référence clair pour évaluer la qualité, mais le travail peut augmenter avec la taille de la collection.
La recherche approximative des plus proches voisins, généralement abrégée en ANN, s’appuie sur des structures d’index pour explorer une partie de l’espace au lieu de comparer exhaustivement chaque vecteur. Elle peut réduire le temps de requête, sans garantir que les voisins trouvés seront toujours exactement les mêmes que ceux d’une recherche exhaustive. Le degré d’approximation et le coût dépendent de l’index, de ses paramètres et de la charge de travail.
HNSW est un exemple d’index de recherche approximative fondé sur des graphes hiérarchiques. Ce n’est ni une exigence pour toutes les bases de données vectorielles, ni la seule méthode d’indexation. La documentation de chaque système peut décrire des index et des compromis différents ; le seul nom d’un index ne suffit donc pas à prévoir les performances d’une application réelle.
Pour comparer les approches, on peut lancer des requêtes représentatives avec une recherche exacte et avec l’index approximatif, puis observer à la fois la qualité de récupération et la latence. Ne mesurer que la rapidité peut masquer des résultats manquants ; ne mesurer que la concordance avec la recherche exacte ne dit pas si le système répond aux besoins des utilisateurs.
Premier choix : exact ou approximatif ?
| Situation | Option à évaluer | Principal compromis |
|---|---|---|
| Collection de petite taille ou besoin d’une référence de qualité | Recherche exacte | Elle compare tous les candidats considérés ; son coût peut augmenter avec la taille de l’ensemble. |
| Collection importante ou exigences fortes en matière de latence | Index ANN, comme HNSW s’il est disponible et adapté | La réponse peut être plus rapide, mais les résultats peuvent différer de ceux de la recherche exacte. |
| Exigences encore inconnues | Mesurer les deux options à l’aide de données et de requêtes représentatives | Il faut définir un critère de qualité et un objectif de latence avant de décider. |
Filtres et recherche combinée
Les métadonnées décrivent des aspects de l’enregistrement qui ne sont pas nécessairement encodés dans le vecteur. Un filtre peut restreindre la recherche à une catégorie, une langue, une date ou des éléments disponibles. Une recherche par similarité peut ainsi porter sur un sous-ensemble pertinent, si l’implémentation et l’application permettent cette combinaison.
Les filtres peuvent aussi modifier le comportement pratique d’une requête. Par exemple, si un filtre ne laisse qu’un petit nombre de candidats ou sélectionne une partie très précise de l’index, le système peut avoir besoin d’une stratégie de récupération différente. Il ne faut pas supposer que tous les produits appliquent les filtres au même moment, avec les mêmes garanties ou le même effet sur l’index.
Dans une application, la recherche vectorielle peut être combinée à une recherche lexicale, qui repère des correspondances entre mots, ainsi qu’à des règles explicites. Cette approche peut être utile lorsque le rapprochement conceptuel compte autant que les termes exacts, les identifiants ou les contraintes. Il ne faut pas tenir la recherche hybride pour une fonction universelle : elle peut nécessiter des capacités particulières ou une coordination dans l’application elle-même.
Trois exemples d’utilisation
Les exemples qui suivent décrivent des usages possibles, et non des résultats garantis. Dans chaque cas, la recherche récupère des candidats à partir de représentations ; leur interprétation et leur validation dépendent du système et du contexte d’utilisation.
En commerce électronique, la recherche par image ou description peut proposer des articles à examiner, tandis que les informations du catalogue et les règles de l’application permettent de tenir compte de la disponibilité, du prix ou de la catégorie. En biomédecine, des représentations vectorielles peuvent aider à repérer des séquences, structures ou molécules à étudier dans un ensemble sélectionné. Dans les médias, des vecteurs peuvent servir à retrouver des images ou des extraits audio proches d’une requête. Aucun de ces rapprochements ne constitue, à lui seul, une validation de la pertinence, de l’équivalence ou de la vérité.
Ce que la base de données ne fait pas
Une base de données vectorielle ne crée pas nécessairement les embeddings : cette tâche revient généralement à un modèle ou à un autre composant. Elle ne garantit pas non plus que les vecteurs représentent bien le contenu ou la tâche visée. Le système compare les représentations qu’on lui fournit, sans pouvoir déduire automatiquement si elles sont adaptées.
La proximité vectorielle n’est pas une décision de pertinence. Un élément proche selon une métrique peut être inutile pour l’utilisateur, ne pas respecter une règle métier ou ne pas répondre exactement à la requête. La base de données ne valide pas non plus la vérité des informations récupérées. Enfin, elle ne rédige pas de réponse en langage naturel comme le ferait un composant génératif, même si une application peut utiliser les résultats de recherche pour alimenter un tel composant.
Confusions fréquentes
Un embedding est une représentation numérique produite par un modèle ou un autre composant. Une base de données vectorielle stocke ces vecteurs et peut rechercher leurs voisins. L’un est une représentation ; l’autre est un système de stockage et de recherche. Les confondre conduit à attribuer à la base de données la création ou l’interprétation des embeddings.
La recherche sémantique désigne une recherche visant à retrouver des contenus associés au sens ou à l’intention, plutôt qu’uniquement des mots identiques. Elle peut s’appuyer sur des vecteurs, mais la base de données vectorielle n’est qu’une partie éventuelle de sa mise en œuvre : le modèle, la préparation des données, les filtres et le classement comptent aussi.
Une base de données relationnelle organise des données selon une structure relationnelle et peut prendre en charge des opérations vectorielles si elle dispose des fonctions correspondantes. Elle ne devient pas nécessairement un système spécialisé distinct pour fournir cette capacité. À l’inverse, toutes les bases relationnelles n’offrent pas les mêmes fonctions vectorielles : cela dépend du produit et de sa configuration.
L’expression « magasin de vecteurs » ou « entrepôt d’embeddings » met l’accent sur le stockage des vecteurs. Elle ne garantit pas, à elle seule, un ensemble particulier de fonctions de base de données, d’indexation, de filtrage ou de gestion des données.
Enfin, une base de données vectorielle n’est pas un système RAG. Dans un système de génération augmentée par la récupération, la recherche peut fournir des éléments à un composant génératif, mais la base de données n’est pas l’ensemble du processus : la préparation des contenus, la récupération, la construction du contexte et la génération sont des étapes distinctes.
Limites et critères de décision
La qualité de la recherche dépend en premier lieu de la représentation produite par le modèle et de son adéquation à la tâche. Le choix de la métrique et sa cohérence avec le modèle et la configuration comptent également. Un index ANN peut améliorer le compromis entre latence et récupération, mais les résultats doivent être évalués avec des requêtes réelles plutôt que supposés satisfaisants à partir du seul type d’index.
Les filtres sélectifs peuvent influer sur les candidats disponibles et sur la manière de les récupérer. Il faut vérifier le comportement de l’implémentation, notamment lorsque les filtres combinent plusieurs conditions. Les mises à jour des données, le coût mémoire, les permissions d’accès et la confidentialité font aussi partie de la conception : la recherche de similarité ne dispense pas de gérer correctement les données ni leurs accès.
Il n’existe pas de seuil universel de taille ou de performance qui impose le recours à un produit vectoriel spécialisé. Une base de données générale disposant d’un support vectoriel peut suffire ; un système spécialisé peut être à évaluer si ses fonctions correspondent mieux aux besoins. La décision dépend de la charge de travail, des exigences de latence, de la qualité attendue, des filtres et des contraintes opérationnelles. Il est utile de mesurer les options avec un jeu représentatif et des critères définis à l’avance.
Liste de vérification avant de choisir
- 01Vérifier quel modèle produit les vecteurs et si le vecteur de requête est compatible avec ceux qui sont stockés.
- 02Confirmer la métrique utilisée, son ordre de classement et sa cohérence avec le modèle et l’objectif de la recherche.
- 03Comparer la recherche exacte et l’option ANN sur des requêtes représentatives, en observant la qualité de récupération et la latence.
- 04Tester l’effet des filtres, des mises à jour et des règles d’accès dans les conditions réelles d’utilisation.
- 05Évaluer si une base de données générale avec support vectoriel répond aux besoins avant de retenir un système spécialisé.
- 06Définir comment la pertinence sera évaluée : la proximité vectorielle seule ne suffit pas.
Notions connexes
Pour comprendre l’ensemble d’un système de recherche, il est utile de distinguer quelques notions voisines. Un embedding est le vecteur représentant une donnée. La recherche sémantique décrit l’objectif de retrouver des contenus associés à une requête, tandis que la recherche vectorielle désigne une manière de comparer des représentations. Le RAG peut utiliser des résultats récupérés pour construire le contexte d’une génération, sans se confondre avec la base de données qui les a recherchés.
Le découpage en fragments, ou chunking, consiste à segmenter un contenu pour préparer des unités qui pourront être représentées et retrouvées. La quantification est une notion liée à la représentation et au stockage des vecteurs, dont l’intérêt et les effets dépendent de l’implémentation. L’inférence désigne l’exécution d’un modèle, par exemple pour produire une représentation ; elle ne doit pas être confondue avec la recherche dans l’index.
Ces concepts sont complémentaires, mais ne remplissent pas la même fonction. Pour garder une architecture compréhensible, il faut identifier séparément qui produit les vecteurs, où ils sont stockés, comment les voisins sont recherchés et comment l’application décide d’utiliser les résultats.