Une fois qu'on sait transformer un texte en vecteur et mesurer la proximité de deux vecteurs, une question pratique se pose : comment retrouver, parmi des milliers voire des millions de vecteurs, ceux qui ressemblent le plus à une requête ? Comparer la requête à chaque document « à la main » ne tient pas à l'échelle. C'est le rôle d'une base vectorielle (vector database) : stocker des vecteurs et retrouver les plus proches en un instant. Cet article explique ce qu'est une base vectorielle, comment elle va vite, quelle métrique de similarité utiliser, puis dresse le panorama des solutions courantes — Chroma, Qdrant, pgvector, Pinecone — et les critères pour choisir la sienne.
Qu'est-ce qu'une base vectorielle ?
Une base vectorielle est un système de stockage spécialisé dans les vecteurs (les embeddings) et leur recherche par similarité. À chaque vecteur, elle associe le texte d'origine et des métadonnées (catégorie, source, date, identifiant…). Elle expose deux opérations principales :
- Indexer : on lui donne des documents, elle calcule (ou reçoit) leurs vecteurs et les range dans un index optimisé.
- Rechercher : on lui donne une requête, elle la transforme en vecteur et renvoie les k documents les plus proches — typiquement les passages les plus pertinents pour répondre.
C'est exactement le moteur de recherche d'un système RAG : on indexe une fois la base de connaissances, puis chaque question déclenche une recherche qui remonte les bons passages.
Trouver les vecteurs les plus proches d'une requête, c'est le problème du plus proche voisin (nearest neighbor). La méthode naïve — calculer la similarité avec tous les vecteurs un par un — est exacte mais linéaire : doubler le corpus double le temps de réponse. Sur des millions de vecteurs, c'est trop lent.
Les bases vectorielles utilisent donc un index ANN (Approximate Nearest Neighbor, plus proche voisin approché). L'idée : accepter des résultats « presque parfaits » en échange d'une recherche bien plus rapide, en pré-organisant les vecteurs dans une structure intelligente. L'algorithme le plus répandu est HNSW (Hierarchical Navigable Small World), un graphe à plusieurs niveaux qu'on parcourt en se rapprochant de proche en proche de la requête. En pratique, on gagne plusieurs ordres de grandeur sur la vitesse pour une perte de précision négligeable.
À cela s'ajoute le filtrage par métadonnées : restreindre la recherche aux vecteurs qui satisfont une condition (par exemple categorie = "juridique"), pour ne chercher que dans le bon sous-ensemble.
Quelle métrique de similarité ?
« Le plus proche » suppose une façon de mesurer la distance entre deux vecteurs. Au moment de créer une collection, la base demande justement quelle métrique utiliser. Trois reviennent partout pour le texte :
| Métrique | Ce qu'elle mesure | Pertinente quand… |
|---|
| Cosine (similarité cosinus) | l'angle entre les vecteurs, ignore leur longueur | défaut pour le texte : la taille d'un document ne doit pas peser sur le score |
| Dot product (produit scalaire) | l'angle et la magnitude | le modèle encode de l'information dans la norme du vecteur |
| Euclidienne (L2) | la distance « à vol d'oiseau » | les écarts absolus de coordonnées comptent (données spatiales) |
Point clé : si les vecteurs sont normalisés (norme ramenée à 1 — ce que font la plupart des modèles de texte), cosine, dot product et L2 donnent le même classement. La différence devient purement technique. D'où la règle d'or : choisissez la métrique sur laquelle votre modèle d'embedding a été entraîné. Les modèles texte courants sont optimisés pour le cosine — c'est le défaut raisonnable.
Ce qu'une base vectorielle apporte de plus
On pourrait stocker ses vecteurs dans un tableau et coder la recherche soi-même. Mais une base vectorielle apporte tout ce qui manque pour aller en production :
- La vitesse à l'échelle grâce à l'index ANN, là où une recherche maison reste linéaire.
- La persistance : les vecteurs survivent au redémarrage, on ne recalcule pas tout.
- Le filtrage par métadonnées combiné à la recherche sémantique.
- Les opérations CRUD : ajouter, mettre à jour ou supprimer des documents sans tout réindexer.
- La montée en charge : millions de vecteurs et requêtes concurrentes.
Panorama des solutions
Il n'existe pas une base vectorielle, mais une famille d'outils aux compromis différents. En voici quatre représentatifs.
Chroma — open source, pensée local-first. Elle s'utilise directement depuis Python, tourne en mémoire ou persistée sur disque sans serveur à administrer. Sa simplicité en fait l'outil idéal pour prototyper et apprendre ; elle vise moins les très gros volumes.
Qdrant — open source, écrite en Rust, orientée performance et filtrage avancé. Elle s'auto-héberge ou s'utilise en version cloud managée. Un bon choix en production avec des exigences de débit et de latence.
pgvector — non pas une base à part, mais une extension de PostgreSQL qui ajoute un type vecteur et la recherche de similarité à une base SQL classique. Imbattable quand vous utilisez déjà PostgreSQL : pas de nouvelle infrastructure, vecteurs et données métier dans la même base.
Pinecone — service managé propriétaire (SaaS). Vous n'hébergez rien : l'éditeur gère le passage à l'échelle et la disponibilité. Simplicité d'exploitation, au prix d'un coût récurrent, d'une dépendance au fournisseur et de l'envoi des données chez un tiers.
| Solution | Modèle | Hébergement | Idéale pour |
|---|
| Chroma | 🔓 Open source | 🏠 Local / embarquée | Prototypage, apprentissage, petits projets |
| Qdrant | 🔓 Open source | 🏠 Auto-hébergée ou ☁️ managée | Production exigeante (perf, filtrage) |
| pgvector | 🔓 Open source | 🏠 Dans votre PostgreSQL | Stack déjà sur PostgreSQL |
| Pinecone | 🔒 Propriétaire | ☁️ Managée (SaaS) | Production sans ops, passage à l'échelle |
Le bon choix dépend du contexte, pas d'un classement absolu. Quelques questions à se poser :
- Quel volume ? À petite échelle, presque tout convient ; à grande échelle, la performance de l'index compte.
- Auto-hébergé ou managé ? Tout gérer soi-même (contrôle, données qui ne sortent pas) ou déléguer l'exploitation (rapidité, moins d'ops) ?
- Open source ou propriétaire ? Coût, réversibilité, souveraineté des données.
- Quelle intégration à l'existant ? Déjà sur PostgreSQL ? pgvector évite d'ajouter une brique.
- Quels besoins de filtrage et de latence ? Recherche hybride, filtres complexes, temps de réponse garanti.
Une trajectoire fréquente : prototyper avec Chroma en local, puis migrer vers une base de production (Qdrant, pgvector ou Pinecone) quand le besoin de volume, de disponibilité ou d'intégration se précise. Les notions pratiquées sur une base — collections, embeddings, recherche par similarité, métadonnées — se retrouvent, sous d'autres noms, dans toutes les autres.
Conclusion
Une base vectorielle stocke des vecteurs et retrouve les plus proches d'une requête en un instant, grâce à un index de plus proche voisin approché (ANN) et au filtrage par métadonnées. Chroma, Qdrant, pgvector et Pinecone répondent au même besoin avec des compromis différents — local vs managé, ouvert vs propriétaire, généraliste vs intégré à PostgreSQL. Le choix se fait selon le volume, l'hébergement et l'existant. C'est la deuxième brique d'un RAG, après les embeddings : reste à les assembler en un pipeline complet.
