Une base de données vectorielle stocke des embeddings denses ou creux haute dimension et leurs métadonnées, offrant une recherche de similarité par plus proches voisins approximatifs (ANN) en quelques millisecondes pour le RAG, la recherche sémantique et la mémoire des agents IA.
| Besoin / Contrainte | Catégorie recommandée | Solutions représentatives | Pourquoi ce choix |
|---|---|---|---|
| Pile PostgreSQL existante, sous ~10 M de vecteurs | Extension SGBDR | pgvector (+ halfvec / HNSW) | Réutilise transactions ACID, JOIN SQL et exploitation existante sans nouveau composant |
| Recherche hybride plein texte BM25 + vecteurs | Extension moteur de recherche | Elasticsearch / OpenSearch / Vespa | Écosystème mature d'index inversés et de classement hybride multi-étapes |
| Service dédié haut QPS avec filtrage complexe | Base vectorielle distribuée dédiée | Qdrant / Milvus / Weaviate | Moteur de stockage spécialisé, filtrage payload rapide et mise à l'échelle horizontale |
| Dev local, edge/desktop ou lecture directe de data lake | Base embarquée / colonnaire | LanceDB / Chroma / FAISS | Exécution in-process avec intégration zero-copy Apache Arrow / Parquet |
| Gros volumes froids/tièdes à coût stockage minimal | SaaS natif stockage objet | Turbopuffer | Stockage objet (S3/GCS) comme source de vérité + cache NVMe/RAM local |
| Serverless zéro-ops intégré à un cloud public | Service cloud entièrement géré | Pinecone / Vertex AI Vector Search / Azure AI Search | Mise à l'échelle serverless élastique et intégration IAM / supervision native |
🔗 Aides-mémoires associés : Concepts LLM & Agents IA · Algorithmes IA modernes · Commandes PostgreSQL · Commandes Redis · Commandes MongoDB
1. Concepts clés et métriques de distance
1.1 Terminologie essentielle
| Terme | Définition | Enjeux d'ingénierie |
|---|---|---|
| Embedding | Tableau de flottants de taille fixe encodant le sens d'un texte, image ou audio | Dimensions courantes : 384 / 768 / 1024 / 1536 / 3072 ; RAM et calcul croissent linéairement |
| ANN (Approximate Nearest Neighbor) | Recherche accélérée par index troquant un infime rappel (95–99 %) contre un gain ×100–1000 | Compromis central latence vs rappel, opposé au balayage exact k-NN |
| Metadata Filtering | Filtrage des résultats vectoriels par attributs scalaires (locataire, date, ACL, catégorie) | Distinguer Pre-filtering, Single-stage / Inline et Post-filtering |
| Hybrid Search | Association de vecteurs denses (sémantique) et vecteurs creux / BM25 (mots-clés exacts) | Corrige les oublis du sémantique pur sur références SKU, codes d'erreur et acronymes |
| Sparse Vector | Vecteur très haute dimension composé majoritairement de zéros (SPLADE, poids BM25) | Ne stocke que les indices et poids non nuls ; complète naturellement la recherche dense |
1.2 Trois métriques de distance et similarité
Cosine(u, v) = (u · v) / (‖u‖₂ · ‖v‖₂)
IP(u, v) = u · v = ∑ᵢ (uᵢ × vᵢ)
L₂(u, v) = √( ∑ᵢ (uᵢ − vᵢ)² )
| Métrique | Signification | Équivalence mathématique | Cas d'usage typiques |
|---|---|---|---|
| Similarité cosinus (Cosine) | Mesure uniquement l'angle sans la norme (−1 à 1 ; distance = 1 - cos) |
Classement identique au produit scalaire si vecteurs normalisés L₂ | Recherche sémantique texte, RAG, embeddings de phrases (choix par défaut) |
| Produit scalaire (IP / Dot) | Dépend de l'angle et de la norme ; coût de calcul minimal | Sur vecteurs normalisés, remplace Cosine en évitant racines et divisions | Systèmes de recommandation bi-tours, embeddings normalisés (ex. OpenAI) |
| Distance euclidienne (L₂) | Distance géométrique directe ; plus petite = plus proche | Sur vecteurs unitaires : L₂² = 2 − 2 · cos(u, v) |
Embeddings image/visage, clustering spatial, signaux sensibles à la norme |
2. Algorithmes d'indexation ANN et quantification
2.1 Comparatif des index vectoriels
| Type d'index | Mécanisme | Empreinte RAM | Latence & Rappel | Échelle & Moteurs types |
|---|---|---|---|---|
| Flat (Scan exact) | Calcul exhaustif de la distance sur tous les vecteurs | Modérée (vecteurs bruts/quantifiés seuls) | Rappel 100 % ; latence explose au-delà de ~100k | Petits jeux (<100k), benchmarks de référence |
| IVF-Flat (Fichier inversé) | Partitionnement K-Means en nlist seaux ; scan des nprobe plus proches |
Faible (quasi aucun surcoût de graphe) | Réglable via nprobe ; rappel moyen à élevé |
1M–10M sous contrainte mémoire (FAISS / Milvus / pgvector) |
| IVF-PQ (IVF + Product Quantization) | Partitionnement + compression par sous-espaces et dictionnaires | Très faible (réduction ×16–64) | Ultra-rapide ; rappel brut moindre (re-scoring requis) | 100M+ en mémoire (FAISS / Milvus / LanceDB) |
| HNSW (Graphe hiérarchique) | Graphe multi-niveaux type skip-list (haut grossier, bas précis) | Élevée (vecteurs + arêtes en RAM ou mmap chaud) | Milliseconde + 95–99 % rappel ; standard industriel | 1M–100M+ temps réel faible latence (Qdrant / Milvus / Weaviate / pgvector) |
| DiskANN (Graphe Vamana) | Graphe optimisé SSD : vecteurs compressés en RAM, graphe complet sur NVMe | Faible (RAM réduite ×5–10) | 100M+ sur un nœud en ms ; dépend des IOPS NVMe | 100M–1B+ à budget RAM contraint (Milvus / LanceDB / Azure) |
| ScaNN | Quantification vectorielle anisotrope + partitionnement arborescent | Faible–Modérée | Meilleur compromis rappel/latence en produit scalaire | Recherche & recommandation massive (Vertex AI Vector Search / OSS) |
Paramètres clés de réglage HNSW :
M(arêtes bidirectionnelles max par nœud, typiquement16–64) : augmente le rappel en haute dimension au prix de plus de RAM et de temps de construction.efConstruction(taille de file candidate lors de la construction, typiquement100–400) : n'affecte que la durée d'indexation et améliore la qualité du graphe.efSearch(largeur d'exploration à la requête, ≥top_k) : seul paramètre ajustable par requête ; plus élevé = meilleur rappel mais QPS réduit.
2.2 Quantification et estimation mémoire
Base de calcul pour 10 millions de vecteurs × 1536 dimensions (FP32 brut) :
Taille brute ≈ N × D × 4 octets (le graphe HNSW ajoute ~1,2× à 1,5× de surcharge RAM)
| Quantification | Largeur / dim | Compression | Taille 10M × 1536-dim | Compromis précision & usage |
|---|---|---|---|---|
| FP32 (Non compressé) | 32 bits (4 o) | 1× | ~57,2 Go | Précision de référence ; coûteux en RAM résidente |
| FP16 / BF16 (Demi-précision) | 16 bits (2 o) | 2× | ~28,6 Go | Quasi sans perte de rappel (ex. pgvector halfvec), excellent ROI |
| SQ8 (Quantification scalaire Int8) | 8 bits (1 o) | 4× | ~14,3 Go | Préserve généralement ≥97 % de rappel ; standard en production |
| PQ (Product Quantization) | Sous-espaces | 16×–64× | ~1–4 Go | Nécessite entraînement ; associer à oversampling + rescore |
| BQ (Quantification binaire 1 bit) | 1 bit | 32× | ~1,79 Go | Scan Hamming ultra-rapide ; rescore 3×–5× recommandé (≥1024 dim) |
3. Comparatif stratifié des solutions
3.1 Bases vectorielles natives dédiées
| Produit | Licence / Déploiement | Langage & Stockage | Index & Points forts | Positionnement |
|---|---|---|---|---|
| Qdrant | Apache 2.0 / Auto-hébergé & Cloud | Rust ; RAM, disque mmap & quantification disque | HNSW + SQ8/BQ ; vecteurs creux natifs et index payload ultra-rapides | Service autonome haut QPS, multi-tenant, filtrage complexe |
| Milvus | Apache 2.0 / Distribué & Zilliz Cloud | Plan de contrôle Go + exécution C++ ; calcul/stockage découplés | IVF, HNSW, DiskANN, GPU CAGRA ; partitions multi-locataires | Plateformes milliard-échelle à fort débit |
| Weaviate | BSD-3-Clause (extensions entreprise fermées) | Go ; stockage objet + index inversé intégrés | HNSW + quantification dynamique/PQ/BQ ; GraphQL/REST, modules de vectorisation | Applications RAG avec pipeline d'embedding intégré |
| Chroma | Apache 2.0 / Embarqué & Client-Serveur | Noyau Python / Rust ; SQLite + stockage local ou distribué | HNSW ; API minimaliste, intégration étroite LangChain / LlamaIndex | Prototypage rapide et RAG Python petit à moyen |
| LanceDB | Apache 2.0 / Embarqué & Enterprise | Rust ; format colonnaire Lance & Apache Arrow | IVF-PQ, HNSW, DiskANN ; I/O zero-copy, multimodal natif (audio/vidéo/tables) | Apps locales embarquées, lecture directe S3 serverless, data lakes |
| Pinecone | SaaS Serverless propriétaire | Moteur distribué géré (évolué des Pods vers le Serverless) | Index propriétaire découplé ; hybride sparse-dense, isolation par Namespace | Équipes cloud privilégiant le zéro-ops managé |
| Turbopuffer | SaaS propriétaire / BYOC | Rust ; stockage objet (S3/GCS) comme source de vérité + cache NVMe/RAM | Index par centroïdes (type SPFresh) évitant les sauts aléatoires I/O ; texte + vecteur | Grands volumes froids/tièdes (ex. indexation de code) à coût minimal |
3.2 Bibliothèques de recherche vectorielle (non SGBD complets)
| Produit | Licence | Périmètre et limites | Cas d'usage |
|---|---|---|---|
| FAISS (Meta) | MIT | Bibliothèque de recherche C++ / Python (pas de persistance de métadonnées, transactions distribuées ni serveur d'auth) ; CPU SIMD & multi-GPU | Calcul batch hors ligne, recherche ML, noyau embarqué dans un moteur maison |
3.3 Extensions de bases classiques et moteurs de recherche
| Produit | Base | Capacités vectorielles | Atouts et limites |
|---|---|---|---|
| pgvector | Extension PostgreSQL (dont Supabase) | Types vector / halfvec / sparsevec / bit ; HNSW & IVFFlat |
Atouts : ACID, JOIN SQL, zéro nouvelle brique ; Limites : amplification d'écriture et pression RAM >10M–50M lignes |
| Elasticsearch / OpenSearch | Index inversé Lucene + HNSW | Hybride natif Dense Vector + BM25, fusion RRF, filtres imbriqués | Atouts : réutilise les équipes search existantes ; Limites : forte consommation RAM off-heap JVM et merges de segments |
| Redis (Query Engine) | Store KV en mémoire | Flat & HNSW, latence sous la milliseconde, mises à jour temps réel | Atouts : idéal pour cache sémantique et feature stores ; Limites : coût RAM élevé à grande échelle |
| MongoDB Atlas Search | Base documentaire (Atlas / Local CLI) | HNSW basé sur Lucene aux côtés des documents BSON | Atouts : supprime la double écriture doc/vecteur ; Limites : couplage fort à la plateforme Atlas |
| SingleStore | Base SQL HTAP distribuée | SQL + opérations vectorielles natives (dot / L₂), colonnes + lignes | Charges mixtes analytiques temps réel et transactionnelles |
| Vespa | Moteur big-data Apache 2.0 | HNSW + hybride exact/approximatif, classement ML multi-étapes (Tensor/XGBoost/ONNX) | Plateformes massives recherche/recommandation ; courbe d'apprentissage élevée |
3.4 Services cloud entièrement gérés
| Service | Fournisseur | Architecture & Points clés |
|---|---|---|
| Vertex AI Vector Search (ex-Matching Engine) | Google Cloud (GCP) | Basé sur ScaNN ; mises à jour streaming à l'échelle du milliard et hybride sparse-dense |
| Amazon OpenSearch Serverless / Aurora pgvector | AWS | Clusters de recherche serverless ou extensions RDS/Aurora, intégration native Amazon Bedrock |
| Azure AI Search | Microsoft Azure | Semantic Ranker intégré, pipelines de vectorisation et contrôle d'accès RBAC entreprise |
4. Stratégies de filtrage et recherche hybride
4.1 Modes d'exécution du filtrage de métadonnées
| Stratégie | Ordre d'exécution | Point de rupture & parade |
|---|---|---|
| Pre-filtering | Évalue d'abord l'index scalaire pour générer un bitmap d'ID, puis lance la recherche vectorielle | Sous des filtres très sélectifs (<1 %), le graphe se fragmente ; Parade : bascule auto vers scan exact |
| Post-filtering | Récupère le Top-K global puis élimine les entrées ne respectant pas les prédicats | Risque de retourner moins de K résultats (voire 0) ; Parade : ne jamais utiliser seul sans fort oversampling |
| Single-stage / Inline | Vérifie dynamiquement le bitmap de filtre à chaque saut du graphe HNSW | Standard moderne (Qdrant / Milvus / Weaviate / pgvector 0.8+ iterative scan) équilibrant rappel et latence |
4.2 Fusion RRF (Reciprocal Rank Fusion)
Les scores vectoriels et BM25 n'ayant pas la même échelle, la RRF fusionne directement les classements sans calibration :
RRF_Score(d) = ∑_{r ∈ R} 1 / (k + rank_r(d)) (constante de lissage usuelle k = 60)
5. Extraits prêts pour la production
5.1 Schéma pgvector, HNSW et scan itératif (SQL)
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
tenant_id INT NOT NULL,
content TEXT NOT NULL,
embedding halfvec(1536), -- float16 réduit la mémoire de 50 % vs float32
fts tsvector GENERATED ALWAYS AS (to_tsvector('simple', content)) STORED
);
CREATE INDEX idx_docs_emb_hnsw ON documents
USING hnsw (embedding halfvec_cosine_ops)
WITH (m = 16, ef_construction = 128);
CREATE INDEX idx_docs_fts ON documents USING gin (fts);
SET hnsw.ef_search = 100;
SET hnsw.iterative_scan = relaxed_order;
SELECT id, content, 1 - (embedding <=> $1::halfvec) AS cosine_sim
FROM documents
WHERE tenant_id = 42
ORDER BY embedding <=> $1::halfvec
LIMIT 10;
Opérateurs de distance pgvector :
<->Euclidienne (L₂) ·<=>Distance cosinus (1 - cos) ·<#>Produit scalaire négatif ·<+>Manhattan (L₁).
5.2 Qdrant : quantification binaire et filtrage Payload (Python)
from qdrant_client import QdrantClient, models
client = QdrantClient(url="http://localhost:6333")
client.create_collection(
collection_name="knowledge_base",
vectors_config=models.VectorParams(
size=1536,
distance=models.Distance.COSINE,
on_disk=True,
),
quantization_config=models.BinaryQuantization(
binary=models.BinaryQuantizationConfig(always_ram=True)
),
)
client.create_payload_index(
collection_name="knowledge_base",
field_name="tenant_id",
field_schema=models.PayloadSchemaType.KEYWORD,
)
hits = client.query_points(
collection_name="knowledge_base",
query=[0.012, -0.045, ...],
query_filter=models.Filter(
must=[models.FieldCondition(key="tenant_id", match=models.MatchValue(value="org_a"))]
),
search_params=models.SearchParams(
quantization=models.QuantizationSearchParams(rescore=True, oversampling=3.0)
),
limit=10,
).points