Choisir une base de données vectorielle pour le RAG : comparaison de huit options.

Le choix d’une base de données vectorielle pour RAG se résume à quelques questions essentielles concernant la taille, le filtrage, le mode d’hébergement et la capacité de votre équipe à gérer le volume d’opérations. Voici une version concise avant d’entrer dans les détails : Chroma et pgvector conviennent aux petits projets. Qdrant et Milvus sont les choix habituels pour une mise en œuvre auto-hébergée en production. Pinecone représente l’option entièrement gérée. Si Postgres est déjà présent dans votre stack, pgvector ne coûte rien de supplémentaire, et si vous souhaitez simplement une configuration locale prête en quelques minutes, Chroma s’installe avec une seule commande pip.

Les moteurs open source tels que Qdrant, Milvus et Weaviate rivalisent avec les plateformes payantes en termes de capacité de rappel des données et de latence, et chacun propose une version gratuite à héberger soi-même en plus d’une option cloud payante. Un autre chiffre à retenir : la combinaison de la récupération vectorielle dense avec la recherche par mots-clés BM25 sparses a permis d’augmenter le taux de Recall@10 de près de 78 % à environ 91 % dans les benchmarks en environnement de production, c’est pourquoi la recherche hybride figure parmi tant d’options ci-dessous.

Les bases de données vectorielles constituent la couche de récupération au sein de la plupart des applications d’IA générative. Elles permettent à une entreprise d’ancrer un modèle de langage dans ses propres données, afin que les réponses restent précises et adaptées au domaine concerné. À mesure que la quantité de données non structurées augmente, la récupération devient le principal goulot d’étranglement en termes de qualité, et choisir correctement signifie comprendre les algorithmes d’indexation, le comportement du filtrage ainsi que le coût de l’infrastructure nécessaire.

Quel est réellement le rôle d’une base de données vectorielle

Une base de données vectorielle stocke des embeddings à haute dimension et classe les lignes en fonction de leur proximité par rapport à un vecteur de requête, en utilisant la similarité cosinus, le produit scalaire ou la distance L2. Un moteur relationnel compare des tokens exacts, tandis que BM25 évalue le chevauchement des termes. Une recherche vectorielle peut restituer des documents sur les « voitures abordables » pour la requête « automobile bon marché », car ces deux expressions se trouvent proches l’une de l’autre dans l’espace des embeddings.

Cependant, il y a un inconvénient : la recherche des k voisins les plus proches exacts coûte O(N·d) par requête, ce qui devient peu pratique dès qu’on dépasse quelques centaines de milliers de vecteurs. Les bases de données vectorielles contournent ce problème en acceptant une légère perte en précision en échange d’index de voisins les plus proches approximatifs qui répondent en temps approximativement logarithmique.

Quoi mesurer avant de choisir

Les équipes qui omettent l’évaluation ont tendance à rencontrer des goulets d’étranglement en production. Quatre domaines méritent une attention particulière.

Qualité de la récupération et latence. Le taux de rappel@K indique avec quelle fréquence le système trouve les meilleures correspondances parmi ses K premiers résultats. Un taux de rappel élevé signifie que le modèle dispose des meilleures informations disponibles. La latence, exprimée en millisecondes, est tout aussi importante ; les ingénieurs se concentrent sur les valeurs p95 ou p99, car elles reflètent les cas les plus lents vécus par les utilisateurs.

Filtrage des métadonnées. Souvent, une requête doit être affinée à l’aide d’attributs structurés. Une recherche pour "politique d’entreprise" peut nécessiter de ne prendre en compte que les documents postérieurs à une date donnée ou appartenant à un département spécifique. Un bon filtrage évite que des documents irrelevants ou non autorisés n’apparaissent dans les résultats. Les bases de données dotées d’un filtrage préalable sont généralement plus performantes, car elles éliminent les enregistrements indésirables avant le démarrage de la recherche vectorielle, ce qui garantit la précision.

Adéquation avec l’écosystème. Une base de données devient plus utile lorsqu’elle s’intègre bien au reste de la pile d’IA. Les connecteurs pour LangChain et LlamaIndex réduisent le temps nécessaire pour mettre en place un pipeline RAG fonctionnel. Les bibliothèques clients disponibles dans plusieurs langues, ainsi que le support pour AWS, GCP et d’autres clouds, déterminent dans quelle mesure ce système s’intègre sans heurt aux logiciels d’entreprise existants.

Prêt à l’emploi. Cela concerne la capacité du système à fonctionner dans un environnement de production exigeant :

• La scalabilité, c’est-à-dire la possibilité de gérer des milliards de vecteurs et un fort trafic de requêtes.
• L’isolation entre les utilisateurs dans les applications multi-locataires.
• Le respect de normes telles que SOC 2, HIPAA et GDPR.
• L’observabilité, permettant de surveiller les performances de recherche et l’utilisation des ressources.

Options gratuites et open source

Les moteurs open source vous permettent de gérer votre propre infrastructure et d’éviter les frais de abonnement récurrents. Les moteurs ci-dessous sont listés approximativement du plus léger au plus lourd.

Chroma

Chroma est une base de données d’embedding conçue pour accélérer le travail des développeurs. C’est le chemin le plus court pour passer d’un répertoire vide à un prototype RAG fonctionnel, et de nombreuses personnes l’utilisent comme leur premier stockage vectoriel. Il convient aux hackathons, au développement local et aux expériences rapides où la facilité d’utilisation prime sur l’échelle distribuée.

Ses avantages : une petite API Python qui permet de passer de tests locaux temporaires à un mode client-serveur persistant, un stockage local basé sur SQLite afin de ne pas avoir besoin de configurer de serveur de base de données, ainsi que des fonctions d’embedding intégrées qui transforment du texte brut en vecteurs au moment de l’insertion, avec des paramètres par défaut tels que all-MiniLM-L6-v2. Il se connecte à LangChain, LlamaIndex, OpenAI et Hugging Face.

Sur le plan positif, l’installation se fait simplement avec pip install chromadb, la conversion texte en vecteurs s’effectue sans code supplémentaire, et le fonctionnement local offre un contrôle total sur les données et l’infrastructure. Sur le plan négatif, il manque des fonctionnalités de sécurité et de multi-locataires nécessaires aux environnements d’entreprise stricts, et il ne peut pas rivaliser avec les systèmes distribués conçus spécifiquement lorsque le nombre de vecteurs dépasse quelques millions.

La base de données principale est gratuite sous licence Apache 2.0, et une version hébergée dans le cloud est désormais disponible pour une mise à l’échelle en production.

Milvus

Milvus est une base de données vectorielle hautement distribuée, native du cloud, qui sépare le calcul du stockage. Elle s’adresse aux organisations gérant d’énormes volumes de données, avec des centaines de millions voire des milliards de vecteurs, où l’extension horizontale est obligatoire et non optionnelle.

Sa architecture sépare les nœuds de données, les nœuds de requêtes et les nœuds d’index. Elle prend en charge de nombreux types d’index, dont HNSW, IVF et DiskANN, ce qui permet d’optimiser le système en fonction du matériel spécifique, et elle dispose d’un indexage et d’une recherche fortement accélérés par GPU. Il est possible d’ajouter ou de supprimer des nœuds en temps réel sans interruption de service.

Forces : les ensembles de données de l’ordre du milliard se comportent de manière prévisible, sans pics anormaux de latence p99 ; l’isolation stricte des nœuds permet d’affecter les calculs exactement là où le travail en a besoin ; enfin, la communauté open source est importante, avec une abondance de documentation et de plugins. Faiblesses : déployer, ajuster et faire fonctionner ce système basé sur Kubernetes exige un véritable travail d’ingénierie, et pour une application RAG simple, les composants supplémentaires tels que etcd et Kafka constituent un surcoût inutile.

Cet moteur est disponible gratuitement sous licence Apache 2.0. Zilliz, l’entreprise qui le développe, propose un hébergement géré à partir de 155 dollars par mois.

Qdrant

Qdrant est un moteur de recherche vectorielle open source écrit en Rust, dont les priorités sont la sécurité mémoire, le débit élevé et un filtrage des données très efficace. Les équipes qui recherchent vitesse et fiabilité ont tendance à choisir cette solution, en particulier pour les systèmes RAG nécessitant des filtres de métadonnées avancés, une notation personnalisée et des délais très serrés.

À l’origine se trouve un moteur de stockage en Rust appelé Gridstore, optimisé pour les charges de travail vectorielles. Une architecture de recherche modulaire permet de combiner des vecteurs denses, des vecteurs spars et des filtres de métadonnées dans une même requête. Le filtrage s’applique directement au sein du graphe lors de la navigation HNSW, ce qui évite les baisses de précision liées au filtrage effectué après la recherche. Il existe également Qdrant Edge, une version légère destinée à l’intégration dans les appareils mobiles et les systèmes de robotique.

La latence typique p50 est d’environ 4 à 5 ms, le filtrage reste précis même sous des contraintes strictes, et la licence (Apache 2.0) est permissive. Les compromis : contribuer au noyau Rust implique une courbe d’apprentissage plus raide, et pour obtenir le meilleur comportement HNSW, il faut ajuster avec soin la mémoire et les paramètres de l’index.

La version open source est gratuite. Qdrant Cloud propose un niveau géré gratuit avec 1 GB d’espace de stockage, ainsi que des clusters payants basés sur l’utilisation.

Weaviate

Weaviate est une base de données open source conçue pour l’IA, organisée autour d’objets de type graphe, qui combine plusieurs styles de recherche et types de données en une seule expérience de requête. Elle convient lorsque vous avez besoin d’une recherche hybride avancée, de relations complexes entre objets, ainsi que d’un flux de travail d’IA intégré à la base de données.

Il intègre nativement une forte similarité ainsi qu’un classement des mots-clés basé sur BM25. Les modules de vectorisation se connectent à OpenAI, Cohere et Hugging Face pour vectoriser le texte à votre place. Les données sont stockées dans un schéma basé sur des classes conçu pour représenter des relations, et l’isolation ainsi que la réplication multi-utilisateurs sont incluses.

Les avantages sont une réduction des codes génériques, puisque la conversion texte en vecteur s’effectue directement dans la base de données, des paramètres hybrides réglables permettant d’équilibrer la précision des mots-clés exacts et la capacité de rappel sémantique large, ainsi que des réponses stables en quelques millisecondes, même avec des centaines de millions d’objets. Les inconvénients résident dans la difficulté initiale d’adaptation au schéma basé sur des classes et dans une consommation de ressources plus élevée par rapport aux solutions intégrées.

Le logiciel est gratuit sous licence BSD-3. Weaviate Cloud propose des plans gérés sans serveur à partir de 45 dollars par mois.

pgvector pour PostgreSQL

L’extension pgvector transforme PostgreSQL en un stockage de vecteurs performant, permettant de conserver les embeddings aux côtés des données transactionnelles ordinaires. C’est le choix naturel pour les équipes déjà engagées avec Postgres qui préfèrent ne pas mettre en place une autre base de données.

Elle ajoute un type de colonne vectorielle natif aux schémas SQL classiques, prend en charge la similarité cosinus, la distance L2 et le produit scalaire, crée des index HNSW et IVFFlat, et exécute des requêtes de similarité au sein de transactions ACID standard.

Le grand avantage réside dans l’évitement des coûts opérationnels, des vérifications de sécurité et de la maintenance d’un système distinct. La surveillance, les sauvegardes et la réplication existantes de Postgres sont conservées, et le filtrage des métadonnées se fait simplement à l’aide d’une clause WHERE familière, en complément d’une fonction de distance. Les inconvénients sont une consommation mémoire plus élevée et une capacité de mise à l’échelle moindre par rapport aux moteurs conçus exclusivement pour les vecteurs, ainsi qu’une augmentation notable de la latence au-delà d’environ 50 millions de vecteurs, à moins d’ajouter des outils comme pgvectorscale.

Cette extension est gratuite et open source. Ce que vous dépenserez dépend de la manière dont vous hébergez Postgres.

Options payantes et gérées

Les bases de données gérées vous offrent une expérience à faible maintenance, permettant à l’équipe de se concentrer sur l’application plutôt que sur les serveurs.

Pinecone

Pinecone a plus ou moins défini la catégorie des bases de données vectorielles gérées grâce à une architecture sans serveur et sans opérations nécessaires, qui cache toute l’infrastructure backend. Elle est destinée aux équipes souhaitant passer rapidement en production sans devoir gérer de serveurs, de clusters ou des paramètres d’indexation.

Elle fonctionne exclusivement en tant que SaaS cloud, sépare les couches de lecture, d’écriture et de stockage afin que chacune puisse s’échelonner indépendamment, héberge des modèles d’incorporation et de réclassement via Pinecone Inference, et prend en charge les vecteurs denses, les vecteurs spars et un filtrage efficace des métadonnées. En retour, vous n’avez pas à vous occuper de l’infrastructure, pas de mises à jour ni de reconstruction d’index, bénéficiez d’une large compatibilité avec les frameworks et les clouds, ainsi que d’une haute disponibilité avec des performances prévisibles sous charge.

Les inconvénients sont qu’il s’agit d’un logiciel à source fermée, ce qui entraîne un véritable verrouillage par le fournisseur, et que les tarifs de consommation augmentent rapidement pour les charges de travail impliquant de nombreuses opérations de lecture et d’écriture.

Les prix indiqués sont les suivants : un niveau Starter gratuit (2 Go, 1 million de lectures, uniquement AWS us-east-1) ; le niveau Standard avec un minimum mensuel de 50 $, soit 0,33 $ par Go-mois, plus environ 4 à 4,50 $ par million d’unités d’écriture et 16 à 18 $ par million d’unités de lecture ; le niveau Enterprise avec un minimum mensuel de 500 $ ; ainsi qu’un add-on HIPAA au prix de 190 $ par mois.

Turbopuffer

Turbopuffer est un moteur de recherche sans serveur conçu directement sur du stockage d’objets cloud, où l’efficacité en termes de coûts est le principe fondamental. C’est le candidat idéal pour les produits SaaS et IA multi-locataires disposant d’un grand nombre de noms d’espace, où les dépenses doivent être maîtrisées.

Il contourne les disques conventionnels et effectue des recherches directement sur le stockage d’objets, gère des milliards de vecteurs sans limite stricte en matière de noms de namespace, utilise un index SPFresh optimisé pour les recherches, et rend les écritures visibles dans les résultats immédiatement. Les coûts de stockage et de requêtes diminuent fortement par rapport aux anciens services gérés ; les tarifs par pod qui pénalisent les architectures multi-locataires sont évités, et la conformité SOC 2 et HIPAA est incluse dans les plans standard.

Cependant, il s’agit d’un logiciel à source fermée avec un historique plus court que celui de ses concurrents établis, et son écosystème de plugins ainsi que ses intégrations sont moins développés. La facturation est entièrement basée sur l’utilisation, avec un minimum mensuel de 64 $ pour les plans standard, et les grands noms de namespace bénéficient de réductions de volume pour les requêtes.

TiDB Vector Search

PingCAP’s TiDB Vector Search associe une base de données SQL distribuée à son propre moteur d’incorporation, permettant ainsi aux gros volumes de travail transactionnels et aux recherches sémantiques de fonctionner au sein d’un même système évolutif. Cela est particulièrement utile lorsque l’on a besoin d’une grande échelle horizontale, combinée à un filtrage SQL complexe et à des recherches vectorielles sur les mêmes données en même temps.

La plateforme combine le stockage d’incorporations et le SQL distribué, crée des index SQL classiques à côté d’index vectoriels HNSW, répartit les requêtes sur plusieurs nœuds pour assurer une haute disponibilité, et prend en charge des recherches hybrides ainsi que des recherches par mots-clés exacts en plus de la similarité vectorielle. Cela élimine les problèmes de synchronisation et les pipelines entre une base de données d’application et un stockage vectoriel distinct, permet des recherches multi-locataires fortement filtrées via des jointures SQL, et s’adapte à l’échelle sans ralentir les requêtes.

C’est excessif pour un pipeline RAG léger basé uniquement sur des vecteurs, et optimiser pleinement les performances exige une compréhension approfondie du SQL distribué.

Au TiDB Cloud Starter, le plan gratuit est le plus généreux de sa catégorie : 5 GiB de stockage par ligne, 5 GiB de stockage colonne par colonne et 50 millions d’unités de requête par cluster, avec jusqu’à 5 clusters par organisation. Cela représente 25 GiB de stockage par ligne, 25 GiB de stockage colonne et 250 millions d’unités de requête par mois gratuitement. Au-delà, le coût est de 0,10 $ par million d’unités de requête et de 0,20 $ par GiB-mois pour le stockage par ligne dans la région us-east.

Où le RAG vectoriel manque de performance

La recherche vectorielle est puissante, mais elle présente encore des faiblesses qui nuisent à la précision dans les environnements d’entreprise.

• Perte de contexte. Le RAG vectoriel standard divise les documents en petits fragments pour tenir dans les fenêtres de contexte. Cette étape mécanique détruit la structure des documents complexes, et un petit fragment perd facilement son lien avec les en-têtes ou les sections qui lui donnaient son sens.
• Imprécision. La récupération dépend de la proximité dans l’espace vectoriel, ce qui entraîne des confusions entre des termes similaires ou des noms de produits ayant des formulations similaires. Des faits erronés finissent dans la requête, ce qui provoque des hallucinations.
• Mises à jour coûteuses. Passer à un modèle d’embedding plus performant signifie re-embeddingner l’ensemble du corpus et reconstruire des index volumineux à partir de zéro, ce qui augmente les coûts de calcul et les dépenses.

Graph RAG est une alternative possible. Il modélise les points de données en nœuds et les relations en arêtes, et des outils tels que le Writer Knowledge Graph maintiennent des liens explicites entre les documents. Cela permet un raisonnement à plusieurs étapes, réduit les hallucinations et permet à une équipe de mettre à jour un seul fait sans devoir réintégrer tout le contenu.

Une manière pratique de décider

Commencez par ce que vous utilisez déjà. Avec Postgres et moins de 10 millions de vecteurs, pgvector gère la tâche sans nécessiter de nouvelle dépendance, tandis que pgvectorscale l’étend à 50 millions et plus. Avec MongoDB, utilisez Atlas Vector Search. Avec Elastic ou OpenSearch, vous pouvez rester tel quel, car OpenSearch 3.0 a comblé la majeure partie des lacunes. Avec Redis, utilisez le support natif des vecteurs de Redis 8 avec FT.HYBRID.

En partant de zéro, prenez en compte trois éléments :

1. Échelle et capacité de traitement. La création de prototypes avec moins de 1 million de vecteurs indique Chroma. Une mise en production auto-hébergée offrant de fortes performances de filtrage suggère Qdrant. Les travaux à l’échelle de milliards de vecteurs ou accélérés par GPU orientent vers Milvus. Une production gérée nécessitant le respect de normes réglementaires convient à Pinecone ou Weaviate Cloud.
2. Forme des coûts. Pour des architectures multi-locataires intensives où la plupart des utilisateurs restent inactifs, les économies de 10 à 100 fois offertes par Turbopuffer sont réelles, bien que les requêtes froides prennent environ 500 ms. Pour des configurations sensibles au coût avec plus de 50 millions de vecteurs et une charge prévisible, pgvector associé à pgvectorscale est adapté.
3. Exigences en matière de raisonnement. Pour les questions nécessitant plusieurs étapes de traitement, une explicable ou une structure relationnelle, il convient d’ajouter un graphe de connaissances tel que Neo4j, Memgraph ou FalkorDB et d’utiliser Graph RAG en parallèle des vecteurs, et non à leur place.

Questions fréquentes

Comment construire une base de données vectorielle pour RAG ? Divisez les documents en blocs, créez des embeddings à l’aide d’un modèle tel qu’OpenAI ou BGE, puis stockez et indexez ces vecteurs dans des outils comme Qdrant, Milvus ou pgvector. Pour une configuration entièrement locale, utilisez Chroma ou FAISS exécutés sur une seule machine, sans recourir au cloud.

Quel est son rôle ? C’est le moteur de récupération situé entre vos documents et le LLM. Il stocke les embeddings et, au moment de la requête, renvoie les blocs les plus pertinents afin que le modèle puisse répondre en s’appuyant sur un contexte concret et non uniquement sur sa mémoire.

Quelle base de données choisir ? Cela dépend de l’échelle et de l’ensemble des technologies utilisées. Chroma et pgvector sont les meilleures options gratuites pour les projets de petite à moyenne taille, Qdrant et Milvus sont préférables pour les environnements auto-hébergés en production, tandis que Pinecone est la meilleure solution gérée lorsque vous souhaitez zéro gestion opérationnelle.

Comment les vecteurs sont-ils utilisés dans le pipeline ? Un modèle d’incorporation convertit des fragments de texte en vecteurs à haute dimension. La base de données les stocke, et lorsqu’une question arrive, elle trouve les vecteurs les plus proches du vecteur de la requête grâce à une recherche ANN, puis transmet ces fragments dans le prompt.

Une base de données vectorielle est-elle toujours nécessaire ? Non, même si elle reste la norme dans l’industrie. Les systèmes sans vecteurs, tels que PageIndex, omettent complètement les incorporations. Ils transforment les documents en arbres hiérarchiques et permettent au LLM de raisonner à partir du sommaire pour trouver des réponses. De nombreuses équipes d’entreprise utilisent également des bases de données graphiques pour GraphRAG, récupérant du contexte grâce à des connexions explicites plutôt qu’à une similarité spatiale.

Quels sont les sept types de RAG ? Le RAG naïf (recherche de base suivie de génération), le retrieve-and-rerank (l’approche habituelle en production), le RAG hybride (recherche dense et sparse combinées), le RAG multimodal (texte, images et audio dans une même chaîne de traitement), le Graph RAG (parcours des graphes de connaissances pour les requêtes relationnelles), le RAG agentique (un agent LLM choisit la meilleure stratégie de recherche pour chaque requête) et le HyDE RAG (le modèle rédige d’abord une réponse hypothétique, puis effectue une recherche en fonction d’elle).