Vector Database
Une vector database est une base de données spécialisée conçue pour stocker des vecteurs d'embedding et récupérer rapidement les plus proches sur le plan sémantique. C'est désormais une infrastructure essentielle pour les pipelines de RAG, la recherche sémantique, les systèmes de recommandation et la mémoire à long terme des agents IA.
Une vector database est une base de données spécialisée conçue pour stocker des vecteurs d'embedding et récupérer rapidement les plus proches sur le plan sémantique. C'est désormais une infrastructure essentielle pour les pipelines de RAG, la recherche sémantique, les systèmes de recommandation et la mémoire à long terme des agents IA.
Pourquoi c'est important
Les bases de données SQL traditionnelles sont optimisées pour les correspondances exactes de mots-clés, mais la recherche à l'ère des LLM repose sur la similarité sémantique. Trouver les top-k plus proches voisins parmi des millions de vecteurs (chacun de plus de 1 000 dimensions) en quelques millisecondes est pratiquement impossible avec une base de données généraliste. Les vector databases résolvent ce problème grâce aux algorithmes de plus proches voisins approchés (ANN), qui permettent la récupération en temps réel sur laquelle s'appuient les réponses des LLM.
Comment ça fonctionne
- Génération des embeddings : des modèles comme OpenAI et Cohere transforment du texte ou des images en vecteurs.
- Indexation : des algorithmes ANN comme HNSW, IVF ou PQ structurent les vecteurs pour une récupération rapide.
- Embedding de la requête : la requête de l'utilisateur est vectorisée par le même modèle.
- Recherche par similarité : les top-k vecteurs sont renvoyés selon la similarité cosinus, le produit scalaire ou la distance euclidienne.
- Jointure des métadonnées : le texte d'origine et les métadonnées attachés à chaque vecteur sont renvoyés et injectés dans le contexte du LLM.
Principales solutions
Vector databases dédiées :
- Pinecone : service managé, API simple, démarrage rapide
- Weaviate : open source, forte recherche hybride (vecteur + mot-clé)
- Qdrant : fondé sur Rust, hautes performances, faible consommation de ressources
- Milvus : recherche vectorielle distribuée à grande échelle
Extensions vectorielles de bases de données existantes :
- pgvector : extension PostgreSQL, garde les vecteurs aux côtés des données SQL
- Elasticsearch : associe la recherche par mots-clés à la recherche vectorielle
- Redis : recherche vectorielle en mémoire
Schéma courant : commencer avec pgvector, puis migrer vers une base dédiée lorsque le trafic et l'échelle l'exigent.
Critères de sélection
Taille des données : en dessous de 1 million de vecteurs, pgvector suffit. Au-delà de 100 millions de vecteurs, une base dédiée est indispensable.
Recherche hybride : si vous devez combiner vecteur + mot-clé + filtre, Weaviate ou Elasticsearch excellent.
Latence : les applications destinées aux utilisateurs visent un p99 inférieur ou égal à 100 ms. Les index HNSW sont les plus fiables dans cette plage.
Charge opérationnelle : les services managés comme Pinecone coûtent plus cher mais suppriment presque tout le travail d'infrastructure. L'open source (Qdrant, Milvus) fait l'inverse.
Filtrage par métadonnées : si le pré-filtrage par catégorie, date ou identifiant utilisateur est fréquent, choisissez une solution qui le combine efficacement avec la recherche vectorielle.
Implications pour le GEO
Les exploitants de blogs construisent rarement leurs propres vector databases, mais rédiger un contenu qui se positionne bien dans les vector databases des LLM et de l'AI search compte. Des titres clairs, des paragraphes autonomes, des chiffres et des sources concrets augmentent la qualité des embeddings, ce qui se traduit par des scores de similarité plus élevés au moment où les vector databases choisissent ce qu'elles citent.
Sources: