Accueil › Glossaire › Vector Store

Vector Store

Un vector store (base de données vectorielle) est un système de stockage spécialisé conçu pour stocker, indexer et rechercher efficacement des vecteurs de haute dimension (embeddings), permettant la recherche par similarité sémantique plutôt que par correspondance exacte de mots-clés.

Quand vous cherchez « comment réduire le taux de churn » dans une base classique, elle cherche les mots exacts « réduire », « taux », « churn ». Un vector store comprend le sens de votre requête et retrouve aussi les documents qui parlent de « fidélisation client », « rétention des utilisateurs » ou « attrition ». C’est cette capacité de recherche sémantique qui fait des vector stores le composant central des architectures RAG (Retrieval-Augmented Generation) et de toute application IA qui a besoin de retrouver de l’information pertinente dans un corpus de documents.

Concepts fondamentaux

Embeddings et espace vectoriel

Un embedding est une représentation numérique d’un contenu (texte, image, audio) sous forme de vecteur de nombres à virgule flottante. Un modèle d’embedding (comme text-embedding-3-small d’OpenAI, embed-v4 de Cohere, ou les modèles Qwen3-embedding) transforme un texte en un vecteur de 512 à 4096 dimensions. Les textes sémantiquement proches produisent des vecteurs proches dans cet espace de haute dimension.

Par exemple, les phrases « Le chat dort sur le canapé » et « Un félin se repose sur le sofa » produiront des vecteurs très proches, malgré des mots différents. C’est cette propriété qui permet la recherche sémantique : au lieu de chercher des mots-clés exacts, on cherche les vecteurs les plus proches du vecteur de la requête.

Métriques de similarité

La distance entre deux vecteurs quantifie leur similarité. Trois métriques dominent :

Cosine similarity : mesure l’angle entre deux vecteurs. La métrique la plus utilisée pour le texte. Insensible à la magnitude (longueur) du vecteur, elle se concentre sur la direction. Score de 0 (orthogonal, pas de relation) à 1 (identique).

Dot product (produit scalaire) : si les vecteurs sont normalisés (magnitude = 1), le dot product équivaut au cosine similarity mais est plus rapide à calculer. C’est pourquoi la plupart des vector stores normalisent les embeddings à l’insertion.

Distance euclidienne (L2) : mesure la distance géométrique directe entre deux points dans l’espace vectoriel. Utilisée quand la magnitude du vecteur a une importance (certains cas d’image search).

Recherche Approximate Nearest Neighbor (ANN)

Trouver le vecteur le plus proche dans une collection de millions de vecteurs de 1536 dimensions par force brute (comparer avec chaque vecteur) est prohibitivement lent. Les algorithmes ANN (Approximate Nearest Neighbor) échangent un peu de précision (recall) contre un gain massif de vitesse. Les principaux :

HNSW (Hierarchical Navigable Small World) : l’algorithme le plus utilisé en 2026. Il construit un graphe multi-couches navigable où chaque nœud est connecté à ses voisins proches. Les recherches naviguent ce graphe du niveau le plus grossier au plus fin. Excellent ratio recall/latence, mais consommateur en mémoire.

IVF (Inverted File Index) : partitionne l’espace vectoriel en clusters (via k-means). À la recherche, seuls les clusters les plus proches de la requête sont explorés. Moins gourmand en mémoire que HNSW, adapté aux très gros volumes.

PQ (Product Quantization) : compresse les vecteurs en sous-vecteurs quantifiés pour réduire l’empreinte mémoire. Souvent combiné avec IVF (IVF-PQ) pour les collections de milliards de vecteurs où la mémoire est la contrainte principale.

Les vector stores en détail

Pinecone : le managé clé en main

Pinecone est un vector store entièrement managé (SaaS). Vous n’avez rien à installer, configurer ou maintenir. Vous envoyez des vecteurs via l’API, Pinecone gère l’indexation, le scaling et la haute disponibilité. C’est le choix le plus rapide pour passer en production.

Le pricing est basé sur le stockage (nombre de vecteurs x dimensions) et le compute (requêtes par seconde). Le tier Serverless (lancé en 2024) réduit significativement les coûts pour les workloads variables. Pinecone supporte le filtrage par métadonnées et la recherche hybride (vecteur + sparse/keyword).

Le compromis : vendor lock-in total (pas d’option self-hosted), et le coût peut devenir significatif à grande échelle. Pour les prototypes et les applications de taille moyenne, Pinecone est excellent. Pour les très gros volumes ou les exigences de souveraineté des données, regardez les alternatives open source.

Qdrant : performance et Rust

Qdrant est un vector store open source écrit en Rust, conçu pour la performance et la fiabilité. Le moteur Rust offre des latences sub-milliseconde et une empreinte mémoire optimisée. Qdrant supporte le filtrage avancé par métadonnées, les payloads riches (JSON arbitraire attaché à chaque vecteur) et la recherche hybride.

Qdrant peut être déployé en self-hosted (Docker, Kubernetes) ou utilisé en version cloud managée. L’expérience développeur est saluée par la communauté : le client Python est bien conçu, la documentation est claire, et l’outil « fonctionne simplement ». C’est un choix solide pour les équipes qui veulent performance + contrôle.

Weaviate : le vector store orienté AI-native

Weaviate se distingue par ses modules d’embedding intégrés : vous pouvez envoyer du texte brut (pas des vecteurs pré-calculés) et Weaviate génère les embeddings automatiquement via des modèles configurables (OpenAI, Cohere, HuggingFace). Cela simplifie l’architecture en éliminant l’étape séparée de génération d’embeddings.

Weaviate supporte nativement la recherche hybride (BM25 keyword + vecteur), le GraphQL comme interface de requête, et des modules de génération (RAG natif). Il est open source (licence BSD) et disponible en cloud managé (Weaviate Cloud). Le compromis est une complexité de configuration supérieure à Qdrant ou Pinecone pour les cas d’usage simples.

Milvus : le scale massif

Milvus est un vector store open source (licence Apache 2.0) conçu pour les déploiements à très grande échelle (milliards de vecteurs). Son architecture distribuée (via Kubernetes) sépare stockage et compute. Milvus est soutenu par Zilliz, qui propose une version cloud managée.

Milvus supporte le plus large éventail d’algorithmes d’indexation (HNSW, IVF, PQ, DiskANN, GPU-accelerated) et les types de données multiples (vecteurs denses, sparse, et scalaires). C’est le choix pour les organisations avec des volumes massifs et des exigences de performance strictes. Le compromis : la complexité opérationnelle est plus élevée que les alternatives pour les petits déploiements.

ChromaDB : le prototypage rapide

ChromaDB est un vector store open source, embedded (fonctionne en mémoire dans votre processus Python), conçu pour le prototypage rapide et les applications de petite taille. Quelques lignes de code suffisent pour démarrer. ChromaDB s’intègre nativement avec LangChain et LlamaIndex.

ChromaDB n’est pas conçu pour la production à grande échelle : les limites apparaissent au-delà de quelques centaines de milliers de vecteurs. Pour le prototypage, les démos et les applications internes de petite taille, c’est le point de départ le plus rapide.

pgvector : le vecteur dans PostgreSQL

pgvector est une extension PostgreSQL qui ajoute le support des vecteurs et la recherche par similarité directement dans votre base relationnelle existante. Vous stockez les embeddings dans une colonne vector(1536) à côté de vos données structurées et requêtez avec des opérateurs SQL spécifiques.

-- Créer une table avec une colonne vectorielle
CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    title TEXT,
    content TEXT,
    category TEXT,
    embedding vector(1536)  -- 1536 dimensions
);

-- Créer un index HNSW pour la performance
CREATE INDEX ON documents
    USING hnsw (embedding vector_cosine_ops);

-- Recherche par similarité sémantique
SELECT id, title,
       1 - (embedding  query_embedding) AS similarity
FROM documents
WHERE category = 'technologie'
ORDER BY embedding  query_embedding
LIMIT 5;

L’avantage de pgvector est majeur : pas de base de données supplémentaire à gérer. Vos vecteurs vivent à côté de vos données relationnelles, avec les mêmes transactions ACID, le même RBAC et les mêmes backups. Pour la plupart des applications avec moins de quelques millions de vecteurs, pgvector est suffisant et réduit drastiquement la complexité opérationnelle.

En 2026, pgvector a mûri significativement : support HNSW et IVFFlat, performances améliorées, et adoption massive. Pour beaucoup d’équipes, c’est le point de départ le plus pragmatique.

Comparatif des vector stores

Vector stores dans une architecture RAG

Le cas d’usage dominant des vector stores en 2026 est le RAG (Retrieval-Augmented Generation). Dans un pipeline RAG, le vector store est le composant de retrieval :

Indexation : vos documents (base de connaissances, documentation, emails, PDFs) sont découpés en chunks, chaque chunk est transformé en embedding par un modèle d’embedding, et l’embedding + les métadonnées sont stockés dans le vector store.

Retrieval : quand un utilisateur pose une question, sa requête est transformée en embedding, le vector store retrouve les K chunks les plus sémantiquement proches (top-K nearest neighbors), et ces chunks sont injectés dans le prompt du LLM comme contexte.

Génération : le LLM génère une réponse en s’appuyant sur le contexte fourni par le vector store, ce qui ancre ses réponses dans vos données réelles plutôt que dans ses connaissances générales.

# Pipeline RAG simplifié avec Qdrant
from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct
import openai

# 1. Initialiser le client
client = QdrantClient(url="http://localhost:6333")

# 2. Créer une collection
client.create_collection(
    collection_name="knowledge_base",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

# 3. Indexer les documents (après chunking)
for i, chunk in enumerate(chunks):
    embedding = openai.embeddings.create(
        model="text-embedding-3-small",
        input=chunk["text"]
    ).data[0].embedding

    client.upsert(
        collection_name="knowledge_base",
        points=[PointStruct(
            id=i,
            vector=embedding,
            payload={"text": chunk["text"], "source": chunk["source"]}
        )]
    )

# 4. Retrieval : trouver les chunks pertinents
query = "Comment réduire le taux de churn ?"
query_embedding = openai.embeddings.create(
    model="text-embedding-3-small",
    input=query
).data[0].embedding

results = client.query_points(
    collection_name="knowledge_base",
    query=query_embedding,
    limit=5
)

# 5. Générer la réponse avec le contexte
context = "n".join([r.payload["text"] for r in results.points])
response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": f"Contexte :n{context}"},
        {"role": "user", "content": query}
    ]
)

Hybrid search : vecteur + mots-clés

La recherche hybride combine la recherche vectorielle (similarité sémantique) avec la recherche par mots-clés (BM25, full-text search). C’est devenu la norme pour le RAG en production car la recherche vectorielle seule peut manquer des termes spécifiques (noms propres, numéros de référence, acronymes techniques) que la recherche keyword capture parfaitement.

Weaviate supporte nativement le BM25 + vecteur. Qdrant et Milvus supportent les sparse vectors pour la composante keyword. pgvector peut combiner tsvector (full-text search PostgreSQL) avec les vecteurs dans une même requête SQL. C’est un avantage significatif de pgvector : la recherche hybride se fait naturellement en SQL.

Vector store vs Feature store

Un feature store gère des features structurées (numériques, catégorielles) pour les modèles ML classiques (régression, classification, recommandation). Un vector store gère des embeddings pour la recherche par similarité sémantique. Les deux se complètent dans les applications ML complètes :

Le feature store fournit les features tabulaires (historique d’achat, fréquence de connexion, score de crédit). Le vector store fournit les résultats de recherche sémantique (documents pertinents, produits similaires, réponses de FAQ proches). Dans une application RAG avec personnalisation, les deux sources d’information sont combinées pour enrichir le contexte du LLM.

Bonnes pratiques

Soignez le chunking

La qualité du RAG dépend autant du chunking que du vector store. Des chunks trop courts perdent le contexte. Des chunks trop longs diluent la pertinence. Le sweet spot est typiquement 256 à 512 tokens, avec un overlap de 50 à 100 tokens entre chunks consécutifs. Testez différentes stratégies (par paragraphe, par section, par fenêtre glissante) et évaluez le recall sur un jeu de test.

Exploitez les métadonnées

Chaque vecteur doit porter des métadonnées riches : source du document, date, auteur, catégorie, langue. Le filtrage par métadonnées avant la recherche vectorielle (pre-filtering) réduit l’espace de recherche et améliore la pertinence. Chercher « comment configurer le firewall » dans la catégorie « documentation technique » donne de meilleurs résultats que chercher dans l’ensemble du corpus.

Choisissez le bon modèle d’embedding

Le modèle d’embedding détermine la qualité de la représentation sémantique. En 2026, les modèles de pointe incluent Qwen3-embedding-8b, Cohere embed-v4, les modèles voyage-3 de Voyage AI, et text-embedding-3-large d’OpenAI. Évaluez sur votre corpus avec des métriques de retrieval (recall@5, MRR) avant de choisir. Un modèle plus gros n’est pas toujours meilleur pour votre cas d’usage spécifique.

Prévoyez la réindexation

Quand vous changez de modèle d’embedding, vous devez réindexer l’intégralité de votre corpus. Les embeddings de deux modèles différents ne sont pas compatibles. Planifiez cette réindexation dans votre architecture et conservez les textes sources, pas seulement les embeddings.

Évaluez le retrieval

Ne déployez pas un pipeline RAG sans évaluer la qualité du retrieval. Créez un jeu de test (questions + documents attendus) et mesurez le recall@K (combien de documents pertinents sont retrouvés dans le top-K). Un recall@5 en dessous de 80 % signifie que votre LLM ne verra pas le bon contexte une fois sur cinq.

Quand avez-vous besoin d’un vector store dédié ?

Pas toujours. Pour les prototypes, les MVPs et les applications avec quelques dizaines de milliers de documents, la recherche vectorielle peut se faire en mémoire avec NumPy/scikit-learn ou avec FAISS sans base de données. pgvector suffit pour la plupart des applications de production avec moins de quelques millions de vecteurs.

Un vector store dédié (Qdrant, Pinecone, Milvus) se justifie quand vous avez des millions à des milliards de vecteurs, des exigences de latence sub-milliseconde, un QPS (queries per second) élevé, ou des besoins avancés de filtrage et de recherche hybride. Pour les applications enterprise à grande échelle, ces systèmes sont indispensables.

Verdict

Le marché des vector stores a dépassé les 4 milliards de dollars en 2026, porté par l’adoption massive du RAG. Mais le choix n’est pas binaire entre « pas de vector store » et « Pinecone entreprise ». Le spectre est large : NumPy pour les prototypes, FAISS pour les lots en mémoire, pgvector pour la production simple, Qdrant ou Weaviate pour la production avancée, Milvus pour le scale massif, Pinecone pour le zéro-ops.

Notre recommandation pragmatique : commencez par pgvector si vous avez PostgreSQL. Si les performances ou les fonctionnalités de pgvector deviennent insuffisantes, migrez vers Qdrant (self-hosted) ou Pinecone (managé). Ne commencez pas par un vector store dédié : commencez par valider votre cas d’usage RAG avec l’infrastructure la plus simple possible, puis scalez quand les limites apparaissent.