Bases de données vectorielles (Vector DBs & ANN Search)

1. Vue d'ensemble du concept et problème systémique

Avec l'avènement des embeddings, les ingénieurs ont été confrontés à un nouveau défi : comment stocker et rechercher rapidement des données dans un espace vectoriel où chaque enregistrement possède une dimensionnalité allant de plusieurs centaines à plusieurs milliers de coordonnées ?

1. Inadéquation des index B-Tree classiques : Les index B-Tree sont efficaces pour trier des nombres ou des chaînes unidimensionnels, mais ils sont mathématiquement impuissants face aux vecteurs géométriques de 1536 dimensions (« Malédiction de la dimensionalité » / Curse of Dimensionality).
2. Volume mémoire considérable : Le stockage de tableaux de flottants float32 exige des gigaoctets de RAM et une accélération matérielle spécialisée (instructions AVX-512, SIMD ou CUDA).
3. Nécessité de liaison avec les métadonnées : Trouver un vecteur ne suffit pas — le système doit restituer instantanément le texte associé, l'auteur, la date, l'URL de la source primaire et le niveau d'accès de l'utilisateur.

Les bases de données vectorielles (Vector Databases) ont transformé la recherche sémantique vectorielle en un primitive infrastructurel fiable, capable de localiser les entités les plus similaires parmi des milliards d'enregistrements en quelques millisecondes.

2. Taxonomie architecturale et modèle mental

Dans l'univers des stores vectoriels, deux modèles conceptuels dominent l'organisation des données et les structures d'index associées :

• 1. Index HNSW (Hierarchical Navigable Small World) : Le standard or de la recherche vectorielle. Il construit un graphe multi-niveaux, analogue à l'algorithme Skip-List : les couches supérieures contiennent des liens longs permettant de sauter rapidement vers le cluster cible de l'espace, tandis que la couche inférieure (Layer 0) assure une navigation fine entre les voisins les plus proches. Il offre le meilleur compromis entre vitesse et exhaustivité de la recherche (Recall > 98 %).
• 2. Index IVF (Inverted File Index) : L'espace est partitionné en cellules de Voronoï via une clustering K-Means. Une requête identifie d'abord les centroides les plus proches, puis scanne uniquement les vecteurs situés dans ces clusters. Elle nécessite moins de RAM que HNSW, mais présente une précision moindre.
• 3. Formats architecturaux des bases :
  • Bases de données vectorielles autonomes dédiées (Dedicated Vector DBs) : Qdrant (Rust), Milvus (Go/C++), Chroma, Pinecone. Optimisées pour le passage à l'échelle, le sharding et les calculs GPU parallèles.
  • Extensions vectorielles relationnelles (Integrated Extensions) : pgvector pour PostgreSQL, sqlite-vec / Turso pour SQLite. Elles garantissent le maintien des transactions ACID et offrent une syntaxe SQL familière.
• 4. Quantification et compression mémoire : Utilisation de la Scalar Quantization (SQ) ou de la Product Quantization (PQ) pour compresser les vecteurs en mémoire sous forme de représentations 8 bits ou 1 bit.

3. Pipeline technique et mécanique interne

Le cycle de vie du stockage et de la recherche dans une base de données vectorielle :

1. Ingestion & Attachement du Payload (Écriture et liaison des charges utiles) : Le client transmet un vecteur accompagné de métadonnées JSON (text, document_id, created_at, tenant_id).
2. Insertion dans le Graphe & Liaison des Arêtes (Intégration HNSW) : L'algorithme identifie les voisins les plus proches pour le nouveau vecteur à chaque niveau du graphe et crée des arêtes bidirectionnelles, en respectant la limite de degré des sommets $M$.
3. Traitement de la Requête & Traversée Multi-niveaux (Recherche par requête) : Lors de la réception d'un vecteur de requête, l'algorithme initie une recherche gloutonne (Greedy Search) depuis la couche supérieure, descendant vers les niveaux inférieurs au fur et à mesure que le cluster est localisé.
4. Récupération Filtrée en Une Seule Étape (Retrieval with Filtering) : Si la requête inclut un filtre SQL/JSON, la vérification de conformité des métadonnées s'effectue directement lors de la traversée du graphe (Filtered HNSW), garantissant le retour strict des enregistrements pertinents.

4. Scénarios d'ingénierie pratiques en production

01. Mémoire à long terme des agents (Agent Memory Storage)

Un agent autonome stocke des faits concernant le développeur dans une collection Qdrant ou pgvector : [vector, payload: { user_id: 104, fact: "préfère bun à npm" }]. Avant le début d'une session, l'agent extrait les 5 faits les plus pertinents.

02. RAG industriel pour le support technique

Une base vectorielle conserve 500 000 chunks de documentation. La requête d'un client trouve en 12 millisecondes les 20 fragments d'instructions les plus pertinents, qui sont ensuite transmis à un reranker.

03. Catalogue E-Commerce sémantique avec filtrage facettes

Recherche de vêtements sur la requête « veste légère pour courir en automne » avec un pré-filtre obligatoire price <= 3000 AND in_stock = true AND size = 'L'.

5. Pièges, erreurs courantes et sécurité

• Incohérence de dimensionnalité (Dimension Mismatch Error) : Tenter d'exécuter une recherche avec un vecteur issu d'un modèle OpenAI (1536 dimensions) dans un index conçu pour un modèle Cohere (1024 dimensions) provoque une erreur fatale d'exécution de la base de données.
• Pic de consommation mémoire lors de la construction de l'index (HNSW Build RAM Spike) : La création d'un index HNSW sur 5 millions de vecteurs nécessite 2 à 3 fois plus de RAM pendant la phase de build que pour le stockage final. Prévoyez un buffer RAM suffisant ou utilisez une quantification disque externe.
• Oubli de la vacuümisation et de la défragmentation : Les opérations fréquentes UPDATE et DELETE créent des nœuds orphelins vides dans les graphes vectoriels. Lancez régulièrement l'optimisation des index (Vacuum / Segment Compaction).