Qu’est-ce qu’une base de données vectorielle ? Le moteur de l’IA moderne expliqué

Illustration of a cat on a ladder reaching toward shelves of rectangular files.

Une base de données vectorielle aide un logiciel à trouver des choses qui ressemblent à d’autres. Au lieu de demander seulement un mot exact ou un numéro de commande, une application peut rechercher des documents, des images ou des produits dont les représentations numériques sont proches d’une requête.

Cela la rend utile pour l’IA moderne, mais ce n’est pas un petit cerveau dans un classeur. Elle ne comprend pas vos documents, ne garantit pas de réponses correctes et ne donne pas automatiquement une mémoire à un chatbot. Son intérêt réside dans l’aide qu’elle apporte à une application pour retrouver du contenu utile.

Sommaire

Qu’est-ce qu’une base de données vectorielle ?

Un vecteur est une liste ordonnée de nombres. Une base vectorielle stocke ces listes et permet des recherches par similarité, généralement avec des identifiants et des métadonnées reliant les résultats au contenu d’origine.

Imaginez une bibliothèque où les livres occupent des positions sur une carte selon leur sujet et leur style. Demander quelque chose de semblable à un livre favori revient à chercher autour de sa position. Dans un véritable espace d’embeddings, il peut y avoir des centaines ou des milliers de coordonnées, et la carte dépend du modèle qui l’a créée.

Le bibliothécaire n’est pas devenu omniscient. Un livre voisin peut toujours être dépassé, trompeur ou simplement une mauvaise recommandation pour vous.

Vecteurs, embeddings et sens

Un embedding représente un élément sous forme de vecteur. Pour la recherche sémantique de texte, un modèle d’embeddings est entraîné afin que des relations utiles dans le langage se reflètent dans la proximité numérique. D’autres modèles représentent des images, de l’audio ou des combinaisons de médias.

Publicité

Une recherche sur « un félin dormant au soleil » pourrait retrouver une légende parlant d’« un chat faisant la sieste près de la fenêtre », malgré des formulations différentes. C’est une illustration du comportement recherché, pas une garantie que tous les modèles classeront correctement cette paire.

Les dimensions ne portent généralement pas des étiquettes bien rangées comme « félinité », « soleil » et « probabilité de renverser un verre ». Leur utilité vient de la représentation dans son ensemble.

Les modèles diffèrent par leur entraînement, leurs langues prises en charge, la longueur d’entrée et les tâches qu’ils maîtrisent. Une représentation adaptée à de courtes descriptions de produits peut mal convenir à des passages juridiques spécialisés. Le choix de la base ne sauve pas un modèle d’embeddings inadapté.

Comment fonctionne une recherche vectorielle

  1. Préparer le contenu source, en découpant si nécessaire les longs documents en passages utiles.
  2. Générer des embeddings et les stocker avec des identifiants et des métadonnées pertinentes.
  3. Représenter la requête dans un espace d’embeddings compatible.
  4. Trouver des vecteurs voisins grâce à une mesure de distance ou de similarité.
  5. Renvoyer le contenu associé en appliquant les autorisations de l’application et ses autres exigences.

La similarité cosinus, le produit scalaire et la distance euclidienne sont des choix courants. Ils ne sont pas interchangeables dans toutes les configurations : normalisation et norme des vecteurs comptent. Suivez les indications du modèle d’embeddings et évaluez les résultats, plutôt que choisir la métrique au nom le plus mathématique.

Recherche exacte et voisins approximatifs

La recherche exacte trouve les résultats les plus proches selon la métrique choisie. La recherche approximative de plus proches voisins, ou ANN, peut réduire le travail grâce à un index restreignant la recherche. Elle peut manquer certains véritables plus proches voisins ; l’ampleur dépend de l’index, des réglages et des données.

HNSW repose sur des graphes, tandis que d’autres méthodes organisent ou compressent différemment l’espace de recherche. Les travaux de 2017 à l’origine de Faiss exploraient des implémentations sur GPU pour la recherche exhaustive, approximative et compressée. Même à grande échelle, le choix technique est plus nuancé que « la recherche exacte est impossible ».

Une petite collection n’a parfois aucun besoin d’index approximatif. À plus grande échelle, comparez vitesse, rappel et consommation de ressources sur des requêtes représentatives. « Rapide » impressionne beaucoup moins lorsque le résultat absent était précisément celui qu’il vous fallait.

Pourquoi les bases vectorielles comptent pour l’IA

Un modèle de langage peut produire une réponse sans interroger une base de données. Sa fenêtre de contexte peut aussi contenir directement les messages précédents. Aucun de ces comportements ne prouve l’intervention d’un stockage vectoriel.

La récupération ajoute une autre capacité : trouver du contenu à fournir avec une question. Notre guide de la génération augmentée par récupération, ou RAG (en anglais), explique comment ce contenu peut éclairer une réponse.

La recherche vectorielle est une méthode de récupération parmi d’autres. Recherche par mots-clés, requêtes structurées et combinaisons de méthodes peuvent aussi convenir. Un numéro de facture exact, par exemple, n’invite pas à renvoyer quelque chose d’une atmosphère émotionnelle similaire.

Le texte récupéré doit toujours être pertinent et fiable. Un générateur peut mal comprendre une bonne source, et une recherche très efficace peut retrouver une mauvaise source. La récupération est une infrastructure utile, pas un certificat automatique de vérité.

Quand la recherche par similarité est utile

  • Découverte documentaire : retrouver des passages abordant une question sans reprendre sa formulation exacte.
  • Recherche visuelle : retrouver des images ou produits aux caractéristiques visuelles proches avec un modèle d’image adapté.
  • Recommandations : générer des éléments candidats ressemblant aux centres d’intérêt d’un utilisateur avant d’appliquer d’autres règles de classement.
  • Recherche de code : trouver des fonctions ou exemples pertinents grâce à des représentations conçues pour le code.
  • Détection de doublons : repérer des éléments à vérifier pour une similarité importante.

Ce sont des conceptions possibles, pas l’affirmation que tous les fils de recommandations ou assistants de programmation utilisent la même architecture. La similarité demande aussi une interprétation : deux tickets d’assistance peuvent concerner le même produit tout en exigeant des réponses opposées.

Les bases vectorielles remplacent-elles les bases traditionnelles ?

Non. Les bases relationnelles restent utiles pour les enregistrements structurés, les relations, les transactions et les conditions exactes. La recherche par similarité répond à un autre type de question, et les deux peuvent cohabiter.

Postgres avec pgvector, par exemple, permet le stockage vectoriel et la recherche exacte ou approximative de voisins, aux côtés de SQL, des jointures et des fonctions transactionnelles de PostgreSQL. Ses index documentés comprennent HNSW et IVFFlat.

Un service vectoriel dédié peut convenir à une charge nécessitant une montée en capacité distincte ou une autre organisation opérationnelle. Cela ne signifie pas qu’une extension relationnelle devient inadaptée à un nombre magique de vecteurs. Taille des données, mélange de requêtes, filtres, fréquence des mises à jour et exigences de latence comptent tous.

Publicité

Partez de l’application plutôt que d’un concours de popularité entre fournisseurs. Trois grandes approches méritent comparaison :

  • Ajouter la recherche vectorielle à une base existante : potentiellement pratique lorsque les enregistrements source et les autorisations s’y trouvent déjà.
  • Utiliser un service dédié : évaluez les fonctions de recherche, le modèle de déploiement, les sauvegardes et les responsabilités opérationnelles proposés.
  • Intégrer une bibliothèque de recherche dans une application : utile si vous pouvez gérer vous-même persistance, contrôle d’accès et comportement du service.

Une bibliothèque et une base gérée ne sont pas des ensembles équivalents. L’une peut fournir le mécanisme des plus proches voisins en vous laissant l’essentiel de la plomberie autour.

Testez d’abord une petite collection représentative. Incluez des requêtes difficiles, des identifiants exacts, des documents à accès restreint et des mises à jour récentes, pas seulement les cinq exemples qui donnent à la démonstration des dons de voyance. Estimez ensuite toute la facture : génération d’embeddings, stockage, recherche, reclassement, sauvegardes et exploitation.

Les pièges derrière la démonstration

Le stockage n’est pas la RAM

Un milliard de vecteurs de 1 536 coordonnées stockées sous forme de nombres de quatre octets nécessitent environ 6,14 To pour ces seuls nombres. Ce calcul ne signifie pas que toute la collection doit toujours résider en RAM. Conception de l’index, compression et architecture de stockage influencent les besoins en mémoire ; métadonnées, index et répliques ajoutent d’autres coûts de stockage.

Changer de modèle change la carte

Il ne faut pas mélanger les vecteurs de modèles incompatibles simplement parce qu’ils ont le même nombre de dimensions. Une migration peut demander de recalculer les embeddings des sources. Garder l’ancien modèle et l’ancien index disponibles peut aider pendant la transition ; les anciens vecteurs ne cessent pas soudainement de fonctionner avec leur configuration d’origine.

La similarité peut manquer l’essentiel

Des passages longs et mal découpés peuvent enfouir la réponse. Des fragments trop courts peuvent perdre le contexte. Recherche par mots-clés et reclassement peuvent aider certaines charges, mais nécessitent des mesures plutôt qu’une inclusion automatique dans chaque système.

Constituez un ensemble de questions avec les sources utiles attendues. Vérifiez si le système les retrouve, écarte les contenus non pertinents et respecte les filtres. Une réponse élégante ne prouve pas que la récupération a réussi.

Autorisations et confidentialité s’appliquent toujours

Faites respecter les autorisations avant que du contenu restreint atteigne le modèle de langage. Gardez suppressions et mises à jour cohérentes entre les enregistrements source et l’index de recherche.

Il ne faut pas supposer les embeddings anonymes. Une étude de 2023 sur l’inversion d’embeddings a récupéré du texte et des informations personnelles dans ses conditions expérimentales. Cela ne signifie pas que chaque vecteur puisse toujours être décodé, mais convertir du texte en nombres n’est pas une garantie de confidentialité.

Questions fréquentes

Tous les chatbots ont-ils besoin d’une base vectorielle ?

Non. Un chatbot peut utiliser directement l’historique de conversation ou retrouver des informations par d’autres méthodes. Choisissez la recherche vectorielle lorsque la récupération par similarité résout un problème réel.

Une base vectorielle est-elle la même chose qu’un LLM ?

Non. L’une stocke et recherche des représentations ; l’autre génère du langage. Notre guide du fonctionnement des LLM (en anglais) explique le côté modèle.

Un score de similarité plus élevé signifie-t-il qu’une réponse est vraie ?

Non. Il mesure une relation selon une représentation et une métrique données. Un document faux peut être très pertinent pour votre question.

En faut-il une pour utiliser MCP ?

Non. MCP relie des applications d’IA à des outils et à des données (en anglais) ; il n’exige pas que ces outils utilisent un stockage vectoriel.

Que devrais-je essayer d’abord ?

Une petite comparaison entre une recherche simple par mots-clés et une recherche par embeddings adaptée, avec de vraies questions. Laissez les résultats justifier la machinerie supplémentaire. Même un projet d’IA mérite le droit d’avoir un classeur ennuyeux mais efficace.

Traduction française de l’article original en anglais du 2026-06-12. Traduction réalisée avec l’aide de l’IA le 1 novembre 2026 ; les références temporelles restent celles de l’original.

Publicité
Partager cet article