Référence rapide

Bases vectorielles & architecture de recherche : aide-mémoire (index, quantification et choix)

Guide de référence dense sur les bases vectorielles et la recherche sémantique : métriques de distance, algorithmes ANN (HNSW, IVF, DiskANN, ScaNN), estimation mémoire par quantification, filtrage inline, fusion RRF et comparaison stratifiée des solutions natives, extensions et services cloud.

· Publié le

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, typiquement 16–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, typiquement 100–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

Sujets associés