Choisir et évaluer les bases vectorielles

L’écosystème des bases de données vectorielles s’est considérablement développé ces dernières années. Les options vont des services cloud spécialisés comme Pinecone aux extensions PostgreSQL comme pgvector, en passant par des serveurs open source comme Chroma, Qdrant et Weaviate, ainsi que des bibliothèques en mémoire comme FAISS. Il est important de choisir le bon outil, car une migration ultérieure coûte cher une fois vos données indexées.

Pour comparer les magasins de vecteurs, évaluez cinq dimensions : la latence des requêtes à l’échelle visée, le débit d’indexation pour l’ingestion par lots, les capacités de filtrage pour le préfiltrage fondé sur les métadonnées, la complexité opérationnelle (géré ou auto-hébergé), ainsi que le coût par million de vecteurs stockés et interrogés. Aucun outil ne s’impose dans toutes les dimensions.

Pinecone est une base de données vectorielle cloud entièrement gérée qui ne nécessite aucune gestion d’infrastructure. Elle excelle dans les charges de travail à forte concurrence, propose une recherche hybride sparse-dense native et fournit des requêtes constantes en quelques millisecondes, quelle que soit l’échelle. Le compromis concerne le coût : la solution est plus chère que les options auto-hébergées et entraîne une dépendance au fournisseur, puisque toutes les données résident dans le cloud de Pinecone.

pgvector étend PostgreSQL avec un type de données vector et des Index de recherche approximative des plus proches voisins (ANN) utilisant les algorithmes HNSW ou IVFFlat. Il est idéal si vous utilisez déjà PostgreSQL, car vos encodages résident dans la même base que vos données relationnelles, ce qui permet de puissantes jointures SQL entre la recherche vectorielle et les filtres structurés sans infrastructure supplémentaire.

Chroma est une base de données d’encodages open source conçue pour le prototypage rapide. Elle s’exécute dans le processus lors du développement local (aucun serveur nécessaire) et prend en charge un mode serveur persistant pour la production. Chroma est populaire dans les tutoriels LangChain grâce à son API extrêmement simple, mais ses capacités sont limitées à grande échelle : pas de mode distribué et filtrage moins performant que celui de Pinecone ou Qdrant.

Qdrant est une base de données vectorielle open source écrite en Rust, qui excelle dans le filtrage complexe des métadonnées. Contrairement aux bases de données qui appliquent les filtres après la recherche ANN, Qdrant préfiltre les vecteurs candidats selon les champs de leur charge utile avant le calcul des scores, ce qui améliore considérablement la précision lorsque les filtres sont sélectifs. Il prend en charge les Index HNSW sur disque, ce qui le rend adapté aux jeux de données qui ne tiennent pas en RAM.

Weaviate est une base de données vectorielle open source dotée d’une API GraphQL originale et d’une prise en charge intégrée des objets multimodaux (texte, images, audio). Elle s’intègre directement aux fournisseurs de modèles d’encodage par l’intermédiaire de modules, ce qui vous permet d’ingérer du texte brut et de laisser Weaviate appeler automatiquement l’API d’encodage. Cette commodité se paie par une configuration plus complexe que celle de Chroma ou de Qdrant.

FAISS (Facebook AI Similarity Search) est une bibliothèque C++ avec des liaisons Python qui fournit une recherche vectorielle en mémoire extrêmement rapide. Ce n’est pas une base de données (pas de persistance ni de serveur), mais elle gère une recherche de similarité à l’échelle du milliard sur une seule machine avec accélération GPU. FAISS est le bon choix pour les charges de recherche par lots hors ligne, intensives en lecture, lorsque vous contrôlez toute la pile technique.

La seule façon de choisir en toute confiance consiste à évaluer vos propres données. Une bonne évaluation mesure : (1) le temps d’indexation de l’ensemble de vos données, (2) la latence des requêtes aux percentiles p50, p95 et p99 sous charge concurrente, (3) le rappel@K en comparant les résultats ANN aux résultats exacts obtenus par force brute, et (4) la mémoire et le coût à l’échelle visée. Exécutez les mêmes requêtes sur chaque magasin candidat.

Les Index ANN échangent du rappel contre de la vitesse. Une valeur plus élevée du paramètre ef_search de HNSW permet de trouver des voisins plus précis, mais prend davantage de temps. Mesurez le rappel@10 (fraction des 10 plus proches voisins réels renvoyés) avec différents réglages, puis représentez le rappel en fonction de la latence. La plupart des systèmes de production visent un rappel de 95 à 99 %. En dessous de 90 %, les utilisateurs obtiennent des segments non pertinents, même si les requêtes sont rapides.

Utilisez cet arbre de décision : si vous avez besoin d’une absence totale de gestion d’infrastructure et que le budget n’est pas une contrainte, choisissez Pinecone. Si vous utilisez déjà PostgreSQL et que votre jeu de données contient moins de 10 millions de vecteurs, ajoutez pgvector. Pour une solution open source auto-hébergée avec un filtrage complexe des charges utiles, choisissez Qdrant. Pour le prototypage rapide et le développement local, commencez avec Chroma et migrez ultérieurement. Pour les traitements par lots hors ligne à l’échelle du milliard, utilisez FAISS.

Dans cette leçon, vous avez découvert le panorama des magasins de vecteurs, notamment Pinecone, pgvector, Chroma, Qdrant, Weaviate et FAISS, les cinq dimensions d’évaluation — latence, débit, filtrage, complexité et coût —, ainsi qu’un cadre de décision pratique pour choisir le magasin adapté à vos besoins d’infrastructure et d’échelle. Nous allons maintenant examiner le problème que RAG a été conçu pour résoudre.