Une base de données vectorielle stocke des vecteurs de haute dimension (typiquement de 384 à 3 072 nombres à virgule flottante, selon le modèle d'embedding) et prend en charge la recherche rapide de plus proches voisins à travers des millions ou des milliards de vecteurs. L'opération fondamentale est : étant donné un vecteur de requête, trouver les k vecteurs dans la base de données qui en sont les plus proches, mesurés par similarité cosinus, produit scalaire ou distance euclidienne. La recherche par force brute (comparer la requête à chaque vecteur stocké) est exacte mais beaucoup trop lente à grande échelle. Les bases de données vectorielles utilisent donc des algorithmes de recherche approximative de plus proches voisins (ANN) qui échangent une infime perte de précision contre des gains de vitesse massifs — trouvant typiquement 95 à 99 % des vrais plus proches voisins tout en ne parcourant qu'une petite fraction de l'index.
L'algorithme ANN le plus courant est HNSW (Hierarchical Navigable Small World), utilisé par Qdrant, Weaviate, pgvector et bien d'autres. HNSW construit un graphe multicouche où chaque vecteur est un nœud connecté à ses plus proches voisins. La recherche commence à la couche supérieure (connexions éparses, longue portée) et descend vers les couches inférieures (connexions denses, courte portée), comme zoomer sur une carte. C'est rapide, précis, et fonctionne bien pour des ensembles de données allant jusqu'à quelques centaines de millions de vecteurs. Le compromis est la mémoire : HNSW garde le graphe en RAM, donc vous avez besoin de suffisamment de mémoire pour contenir vos vecteurs plus la surcharge du graphe. Pour un million de vecteurs de dimension 1 536 (la sortie d'ada-002 d'OpenAI), cela représente environ 6 à 8 Go. Les alternatives comme IVF (inverted file index) et ScaNN utilisent moins de mémoire mais nécessitent plus de réglages. Pinecone et certaines configurations de Qdrant utilisent la quantification — compressant les vecteurs de float32 à int8 ou binaire — pour faire tenir plus de vecteurs dans la même mémoire au prix d'une légère perte de précision.
Le choix entre les principales bases de données vectorielles dépend de vos contraintes. Qdrant et Weaviate sont open source et auto-hébergeables, ce qui compte pour la confidentialité des données et le contrôle des coûts — vous les exécutez sur votre propre infrastructure et ne payez que le calcul. Pinecone est entièrement géré (pas d'infrastructure à opérer) mais verrouillé à un fournisseur et facturé par vecteur, ce qui devient coûteux à grande échelle. ChromaDB est léger et intégrable (tourne dans le processus, stocke sur disque), excellent pour le prototypage et les petits ensembles de données mais pas conçu pour les charges de production avec des millions de vecteurs. PostgreSQL avec l'extension pgvector est attrayant si vous utilisez déjà Postgres, puisque vous évitez d'ajouter une nouvelle base de données à votre pile, mais ses performances de requête sont inférieures à celles des bases de données vectorielles dédiées à plus grande échelle. Pour la plupart des systèmes RAG en production, Qdrant ou Weaviate offrent le meilleur équilibre entre performance, fonctionnalités et contrôle opérationnel.
Le filtrage par métadonnées est une fonctionnalité qui sépare les bases de données vectorielles sérieuses des implémentations jouets. En pratique, vous ne voulez presque jamais chercher dans toute votre collection — vous voulez chercher « tous les documents téléchargés par cet utilisateur » ou « uniquement les documents des 30 derniers jours » ou « uniquement les fragments de ce PDF spécifique ». Les bases de données vectorielles permettent de stocker des métadonnées aux côtés de chaque vecteur et d'appliquer des filtres avant ou pendant la recherche de similarité. C'est ce qu'on appelle le pré-filtrage (filtrer d'abord, puis chercher dans l'ensemble réduit) ou le post-filtrage (tout chercher, puis écarter les résultats qui ne correspondent pas). Le pré-filtrage est plus efficace mais nécessite que l'index le supporte ; la plupart des bases de données en production le font maintenant. Bien définir votre schéma de métadonnées au moment de l'indexation évite des douleurs énormes plus tard — ajouter des filtres après coup sur une collection qui n'était pas conçue pour signifie souvent tout réindexer.
Les bases de données vectorielles existaient avant la vague actuelle d'IA — Spotify utilisait la recherche approximative de plus proches voisins pour les recommandations musicales il y a des années, et la bibliothèque Faiss de Facebook existe depuis 2017. Mais l'explosion des modèles d'embedding et du RAG en 2023-2024 les a fait passer d'une technologie de niche à une infrastructure critique. L'espace mûrit encore rapidement : la multi-location (isoler efficacement les données entre clients dans un déploiement partagé), la recherche hybride (combiner recherche vectorielle et par mots-clés dans une seule requête), et l'indexation sur disque (gérer des ensembles de données plus grands que la RAM) sont tous des domaines où les produits diffèrent significativement et s'améliorent rapidement. Si vous démarrez un projet aujourd'hui, choisissez une base de données qui gère votre échelle actuelle, prend en charge le filtrage par métadonnées et la recherche hybride, et a une trajectoire de maintenance active. Vous pourrez toujours migrer plus tard — les vecteurs d'embedding sont portables.