Une base vectorielle stocke des embeddings — des vecteurs de 768 à 3072 dimensions — et permet de retrouver très rapidement les plus proches d'un vecteur de requête (recherche par similarité). C'est la couche de stockage du RAG : on indexe ses documents une fois, on cherche en quelques millisecondes parmi des millions de chunks. Sans elle, on tomberait sur des recherches en O(n) inacceptables au-delà de quelques milliers de documents.
Les principaux acteurs en 2026 : Pinecone (managé, simple, plus cher), Weaviate (open-source, riche en features), Qdrant (open-source, rapide, Rust), pgvector (extension PostgreSQL, pertinent quand on a déjà du Postgres et des volumes < 10M chunks), Milvus (à grande échelle). Pour la majorité des projets PME/ETI, pgvector suffit largement et évite d'introduire un nouveau service à opérer. Pinecone devient pertinent au-delà de 50M de vecteurs ou quand on a besoin d'une recherche distribuée.
Les paramètres qui comptent en production : algorithme d'index (HNSW est le standard), métrique de distance (cosinus pour le texte), filtres métadata (filtrer par client, date, langue avant la recherche vectorielle), recherche hybride (vectoriel + BM25), et reranking en post-traitement. Une base vectorielle mal configurée renvoie du bruit — et un chatbot ou un agent IA qui s'en nourrit hallucinera. Le tuning de la stack RAG, c'est 70 % du travail d'un projet sérieux.
Quelle base vectorielle pour quel volume
- < 1M chunks : pgvector dans votre Postgres existant — simple, robuste, pas de service additionnel.
- 1M à 50M chunks : Qdrant ou Weaviate auto-hébergés — bon compromis perf/coût/contrôle.
- > 50M chunks ou multi-tenant lourd : Pinecone managé ou Milvus distribué.
- Toujours activer les filtres métadata avant la recherche vectorielle — gain de perf x10 facile.
