Choisissez une base vectorielle selon votre volume de données, vos contraintes d’exploitation, votre besoin de filtrage et votre stack existante. Pinecone, Weaviate, Qdrant, Milvus, pgvector et ChromaDB ne répondent pas au même problème. Le bon choix commence par comprendre embeddings, recherche sémantique et RAG.
À quoi sert une base vectorielle ?
Une base vectorielle sert à stocker, indexer et retrouver des contenus proches par le sens, pas seulement par mots-clés exacts.
Une base relationnelle classique, comme PostgreSQL ou MySQL, organise les données en lignes, colonnes, clés primaires, clés étrangères et relations. Elle répond très bien à des questions structurées : “Quels clients ont commandé en mars ?”, “Quel produit a ce SKU ?”, “Quelle facture correspond à cet identifiant ?”. Une base vectorielle travaille autrement : elle manipule des vecteurs haute dimension, c’est-à-dire des tableaux de nombres flottants, donc des nombres à virgule, qui représentent le sens d’un texte, d’une image, d’un son ou d’un autre objet numérique.
Ces vecteurs viennent des embeddings. Un embedding est une représentation numérique produite par un modèle de machine learning. Le modèle transforme un contenu en liste de nombres, de façon à placer les contenus proches par le sens dans des zones proches de l’espace vectoriel.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
| Modèle d’embedding | Dimensions |
| OpenAI text-embedding-3-small | 1536 |
| sentence-transformers/all-MiniLM-L6-v2 | 384 |
| Cohere embed-v3 | 1024 |
| Google text-embedding-004 | 768 |
Pour le RAG, acronyme de Retrieval-Augmented Generation, ou génération augmentée par récupération, cette mécanique est centrale. Avant de demander à un LLM, c’est-à-dire un grand modèle de langage, de répondre, on récupère les documents les plus pertinents dans une base vectorielle. Ces documents sont ensuite ajoutés au prompt pour fournir du contexte fiable, récent ou spécifique à votre entreprise.
Un exemple simple suffit. Une requête comme voiture électrique familiale peut retrouver un contenu qui parle de berline EV pour enfants, même si les mots exacts ne sont pas identiques. Le système comprend que “voiture” est proche de “berline”, que “électrique” est proche de “EV”, et que “familiale” peut être lié à “pour enfants”.
Comprendre les embeddings est donc nécessaire, mais pas suffisant. Pour choisir une base vectorielle sérieusement, il faut aussi comprendre comment la recherche de similarité fonctionne quand le volume passe de quelques milliers à plusieurs millions de documents.
Comment fonctionne la recherche sémantique ?
La recherche sémantique convertit la requête en vecteur, puis cherche dans l’index les vecteurs les plus proches selon une mesure de similarité.
Dans un système RAG, pour Retrieval-Augmented Generation, c’est-à-dire génération augmentée par récupération d’information, le flux commence avant même la question utilisateur. Les documents sont ingérés, puis souvent découpés en chunks, des passages plus courts de quelques centaines de tokens pour éviter de noyer le modèle dans trop de texte. Chaque chunk est transformé en embedding par un modèle choisi. Un embedding est une représentation numérique du sens sous forme de vecteur, par exemple une liste de 768, 1 536 ou 3 072 nombres selon les modèles.
Ces vecteurs sont ensuite stockés dans une base vectorielle avec leurs métadonnées : source, date, auteur, URL, droits d’accès, catégorie métier. Quand vous posez une question, la requête est encodée avec le même modèle d’embedding, puis la base cherche les passages les plus proches. Ces passages sont envoyés au LLM, Large Language Model, qui les utilise comme contexte pour répondre avec moins d’invention et plus d’ancrage documentaire.
Le cœur du sujet, c’est la recherche de plus proches voisins, ou nearest neighbour search. En théorie, on pourrait comparer le vecteur de la requête à tous les vecteurs de la base. En pratique, cela devient vite trop lent avec des millions de chunks. Les bases vectorielles utilisent donc souvent l’ANN, pour Approximate Nearest Neighbour. Le principe est simple : au lieu d’être parfaitement exhaustif, l’index trouve très vite des candidats très proches, avec un compromis contrôlé entre vitesse, coût mémoire et précision.
Les mesures de similarité les plus courantes répondent à des besoins différents :
- Similarité cosinus : Compare l’angle entre deux vecteurs, utile quand la direction compte plus que la magnitude.
- Distance euclidienne : Mesure la distance géométrique entre deux points dans l’espace vectoriel.
- Produit scalaire ou dot product : Mesure l’alignement entre deux vecteurs, en tenant aussi compte de leur amplitude selon le modèle utilisé.
Deux familles d’index reviennent souvent dans les documentations. HNSW, pour Hierarchical Navigable Small World, construit un graphe de voisinage dans lequel la recherche navigue rapidement de proche en proche. IVF, pour Inverted File Index, regroupe les vecteurs en clusters afin de ne chercher que dans les zones les plus prometteuses.
Un point est critique : les documents et les requêtes doivent être encodés avec le même modèle d’embedding. Si le modèle change sans réindexation, les vecteurs ne vivent plus dans le même espace mathématique. La recherche compare alors des objets incompatibles, et la pertinence se dégrade.
| Élément | Rôle | Risque si mal choisi |
| Modèle d’embedding | Transforme textes et requêtes en vecteurs comparables. | Résultats incohérents ou chute de pertinence. |
| Mesure de similarité | Définit comment la proximité est calculée. | Mauvais classement des passages. |
| Index ANN | Accélère la recherche à grande échelle. | Latence élevée ou rappel insuffisant. |
| Métadonnées | Filtrent les résultats par source, droit ou contexte. | Fuites d’accès ou contexte non pertinent. |
Quelles solutions comparer pour le RAG ?
Les six options à comparer en priorité sont Pinecone, Weaviate, Qdrant, Milvus, pgvector et ChromaDB, car elles couvrent des besoins très différents entre SaaS managé, open source, extension PostgreSQL et prototypage local.
Aucune base vectorielle ne gagne partout. Une solution peut être excellente sur 200 000 documents avec peu de filtres, puis devenir moins pertinente sur 50 millions de chunks avec des filtres métier complexes, une contrainte de latence forte, un budget mémoire limité ou un modèle d’embedding plus large.
Les caractéristiques ci-dessous viennent des documentations officielles des projets et éditeurs concernés. Les dimensions d’embeddings doivent aussi être vérifiées côté fournisseur de modèle, par exemple OpenAI indique 1 536 dimensions pour text-embedding-3-small et 3 072 pour text-embedding-3-large dans sa documentation.
| Solution | Type | Point fort | À surveiller | Cas d’usage adapté |
| Pinecone | SaaS managé | Production rapide sans gérer l’infrastructure vectorielle. | Coût, dépendance fournisseur, gouvernance des données. | Équipe qui veut réduire l’exploitation et livrer vite. |
| Weaviate | Open source avec offre cloud | Recherche hybride, schéma de données, intégrations IA. | Modélisation du schéma et complexité selon les modules activés. | RAG combinant texte, métadonnées et recherche sémantique. |
| Qdrant | Open source, écrit en Rust | Filtres sur payloads, performances, déploiement maîtrisé. | Dimensionnement mémoire et choix d’index selon le volume. | Produit RAG avec filtres métier importants. |
| Milvus | Open source distribué | Architecture pensée pour les gros volumes. | Complexité opérationnelle plus élevée. | Très grands corpus et montée en charge structurante. |
| pgvector | Extension PostgreSQL | Vecteurs dans une base déjà utilisée par beaucoup d’équipes. | Limites possibles à grande échelle face à une base spécialisée. | Données métier déjà dans Postgres, RAG pragmatique. |
| ChromaDB | Base vectorielle simple | Démarrage rapide en local ou sur application légère. | Passage en production à valider selon charge et exploitation. | Prototype, POC, agent local, première version RAG. |
Le bon choix dépend donc moins du nom de l’outil que de votre contexte réel. Les critères décisifs restent le volume, les filtres, la latence attendue, la stratégie cloud ou self-hosted, le modèle d’embedding et les tests sur vos propres données.
Comment choisir selon votre projet IA ?
Choisir une base vectorielle revient à arbitrer entre qualité de recherche, simplicité d’exploitation, intégration à la stack existante, coût, gouvernance des données et capacité à monter en charge. Le bon choix dépend moins du benchmark vu sur LinkedIn que de votre cas d’usage réel.
Définissez d’abord le cas d’usage. Un chatbot documentaire, un moteur de recherche interne, un support client, une recommandation produit, un enrichissement CRM ou un agent IA connecté à une base de connaissance n’ont pas les mêmes contraintes. Le RAG, pour Retrieval-Augmented Generation, consiste à récupérer des documents pertinents avant de générer une réponse avec un modèle de langage. La base vectorielle sert donc à retrouver les bons passages, pas seulement à stocker des vecteurs.
Évaluez ensuite le volume. Regardez le nombre de documents, le nombre de chunks, la dimension des embeddings, la fréquence de mise à jour et la croissance prévue. Un embedding est une représentation numérique d’un texte, souvent composée de centaines ou milliers de dimensions. Plus il y a de chunks et de dimensions, plus l’indexation, le stockage et les requêtes coûtent cher.
Mesurez la qualité avant la latence. Créez un jeu de questions de test, puis vérifiez les documents récupérés dans le top 3, top 5 ou top 10. Suivez la précision perçue, les oublis gênants et les erreurs critiques. Une réponse rapide basée sur le mauvais document reste une mauvaise réponse.
Testez les filtres. Dans les applications business, ils sont souvent décisifs : droits utilisateurs, langue, date, produit, pays, catégorie, statut de document. Une base vectorielle qui cherche bien mais filtre mal peut devenir inutilisable en production.
Comparez l’exploitation. SaaS managé, cloud privé, Kubernetes, serveur dédié ou PostgreSQL existant : chaque option change la charge d’équipe, la sécurité et la conformité. Le SaaS réduit l’administration, mais impose plus de dépendance fournisseur. L’open source donne plus de contrôle, mais demande plus d’exploitation.
Contrôlez les coûts complets. Intégrez le stockage vectoriel, le calcul d’indexation, les requêtes, la réplication, le monitoring, le temps d’équipe et la réindexation lors d’un changement de modèle d’embedding.
- Prototype rapide : ChromaDB ou pgvector.
- PostgreSQL déjà central : pgvector.
- Production managée : Pinecone ou Weaviate Cloud.
- Open source contrôlé : Qdrant ou Weaviate.
- Très gros volumes distribués : Milvus.
Deux erreurs reviennent souvent : choisir l’outil le plus populaire sans test, ou comparer seulement la latence sans mesurer la pertinence métier.
| Si votre priorité est | Regardez d’abord | Pourquoi |
| Prototyper vite | ChromaDB, pgvector | Installation simple, intégration rapide, peu d’infrastructure. |
| Capitaliser sur PostgreSQL | pgvector | Moins de briques à maintenir, données proches du SI existant. |
| Réduire l’exploitation | Pinecone, Weaviate Cloud | Service managé, montée en charge et supervision simplifiées. |
| Garder le contrôle | Qdrant, Weaviate | Déploiement open source, choix d’hébergement plus flexible. |
| Gérer de très gros volumes | Milvus | Architecture distribuée pensée pour la recherche vectorielle à grande échelle. |
Alors, quelle base vectorielle mérite vos tests ?
La meilleure base vectorielle n’est pas celle qui promet le plus, mais celle qui récupère les bons documents, au bon coût, dans vos contraintes réelles. Pour un RAG fiable, commencez par choisir un modèle d’embedding stable, construisez un petit jeu de tests, mesurez la pertinence des résultats et comparez l’exploitation. Pinecone, Weaviate, Qdrant, Milvus, pgvector et ChromaDB ont chacun leur place. Votre décision doit venir du cas d’usage, pas d’un classement générique. Le bénéfice est simple : une application IA plus fiable, plus explicable et plus utile pour vos utilisateurs.
FAQ
- Qu’est-ce qu’une base vectorielle ?
Une base vectorielle est un système conçu pour stocker et rechercher des vecteurs, c’est-à-dire des tableaux de nombres représentant le sens d’un contenu. Elle permet de retrouver des textes, images ou sons proches sémantiquement, même si les mots exacts ne correspondent pas. - Pourquoi utiliser une base vectorielle pour le RAG ?
Le RAG a besoin de récupérer les bons documents avant de générer une réponse avec un LLM. La base vectorielle sert à trouver les passages les plus proches de la question posée, afin de fournir au modèle un contexte plus pertinent et de réduire les réponses approximatives. - Quelle différence entre recherche par mots-clés et recherche vectorielle ?
La recherche par mots-clés cherche des correspondances textuelles. La recherche vectorielle cherche une proximité de sens. Par exemple, elle peut rapprocher automobile et car si les embeddings les placent dans une zone similaire de l’espace vectoriel. - Faut-il choisir Pinecone, Weaviate, Qdrant, Milvus, pgvector ou ChromaDB ?
Le bon choix dépend du projet. Pinecone convient bien au managé, Weaviate et Qdrant aux déploiements open source solides, Milvus aux gros volumes distribués, pgvector aux équipes déjà sur PostgreSQL, ChromaDB aux prototypes et applications légères. - Peut-on changer de modèle d’embedding facilement ?
Pas sans précaution. Les documents et les requêtes doivent être encodés avec le même modèle d’embedding. Si vous changez de modèle, il faut généralement recalculer les vecteurs et reconstruire l’index pour éviter une perte de pertinence.
A propos de l’auteur
Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA, le SEO et le GEO. J’ai travaillé pour des organisations comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer un projet IA ou RAG proprement, je suis disponible pour vous aider : contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.