Calculateur de dimensionnement et de sélection de bases de données vectorielles
La question pratique derrière une base de données vectorielle auto-hébergée pour RAG est de savoir quel moteur convient à un serveur donné, et lequel est exclu par la charge de travail. Le calculateur ci-dessous répond aux deux, à partir de notre benchmark de sept bases de données vectorielles auto-hébergées exécuté à rappel équivalent sur des embeddings identiques.
Explication des métriques du calculateur
Cinq cases à cocher en haut du calculateur nomment cinq charges de travail RAG courantes, et chacune correspond à une limite mesurée issue du benchmark plutôt qu'à une affirmation de fournisseur. Cocher une case filtre la liste des moteurs par rapport à un nombre spécifique. La laisser décochée signifie que la charge de travail ne s'applique pas, et aucun moteur n'est filtré sur ce critère. Ce que chaque commutateur demande, et la mesure qui le sous-tend :
Sélection et dimensionnement
Deux décisions précèdent un index en cours d'exécution. La première est la sélection, car certains moteurs ne peuvent pas effectuer une tâche donnée. Le calculateur vérifie chaque moteur par rapport aux cinq commutateurs d'exigence ci-dessus et élimine ceux qui échouent. La seconde est le dimensionnement, c'est-à-dire quels sont les moteurs survivants qui tiennent dans la boîte et avec quelle marge. Pour chaque survivant, il indique s'il convient, s'il est juste ou ne convient pas, plus le nombre de vecteurs que le serveur pourrait contenir. Aucune de ces décisions ne dépend de la qualité de la récupération, car les sept moteurs sont à égalité dans un écart nDCG de 0.014 par rapport à un oracle kNN exact.
Empreinte à 2.25M vecteurs
À 2.25M vecteurs, le benchmark a mesuré deux empreintes, selon l'endroit où réside l'index. Pour les cinq moteurs en mémoire, il a enregistré le pic de RAM pendant la construction et le service, de 17.0 Go (Milvus) à 62.4 Go (Chroma). Pour les deux moteurs sur disque, il a enregistré l'index sur disque, 12.0 Go pour LanceDB et 18.4 Go pour pgvector, ce qui coûte beaucoup moins cher par gigaoctet. Ces chiffres sont les mesures brutes, pas les entrées de dimensionnement du calculateur. Le calculateur dimensionne plutôt le service en régime permanent.
Pour les moteurs en mémoire, cela se situe en dessous du pic de construction et de service, et pour les moteurs sur disque, cela ajoute la copie de la table et le texte des segments en plus de l'index mesuré, de sorte que pour le même corpus de 2.25M, ses chiffres sont plus bas en RAM et plus élevés sur disque que les barres ici. La répartition mesurée par rapport à modélisée ci-dessous concilie les deux. Le benchmark complet par moteur derrière le calculateur, couvrant précision, vitesse, recherche filtrée et hybride, coût de construction et rotation en direct, comparaison de bases de données vectorielles open source.
Le modèle de dimensionnement
Les entrées sont la taille du corpus, le découpage et le modèle d'embedding, et le calculateur déduit les deux nombres qui déterminent le dimensionnement. La taille du corpus et le découpage donnent le nombre de vecteurs. Un corpus de 2 Go (décimal, 2 milliards d'octets) à 4 octets par token donne 500M tokens, et des segments de 512 tokens avec un chevauchement de 15% avancent d'un pas de 512 × 0.85 = 435.2 tokens, donc le nombre est arrondi(500M ÷ 435.2) = 1,148,897 vecteurs. Le modèle d'embedding donne la dimension, donc l'entrée est un choix de modèle, pas un nombre brut, et bge-m3 la fixe à 1024.
L'empreinte de chaque moteur est alors un coût par vecteur multiplié par le nombre de vecteurs, plus une base de processus fixe : footprint = base_gb + bytes_per_vector × N. Le coût par vecteur est là où les moteurs divergent, car une base de données vectorielle stocke plus que le vecteur brut. Elle conserve également le graphe d'index qui rend la recherche rapide, et, pour le véritable RAG, le texte du segment qu'elle doit retourner. Le tableau ci-dessous est le coût par vecteur que produit la disposition de stockage de chaque moteur à 1024 dimensions en float32.
Deux faits de disposition font l'essentiel de la séparation. Redis conserve une deuxième copie de chaque vecteur (un hachage source plus une copie dans l'index) et ne peut pas décharger le texte du segment, ce qui en fait le plus lourd en RAM. pgvector stocke également chaque vecteur deux fois sur disque, une fois dans le tas de la table et une fois dans l'index HNSW, et son index arrondit à des pages Postgres de 8 Ko, de sorte qu'un vecteur float32 de 1024 dimensions remplit une page entière à lui seul. Les quatre autres moteurs en mémoire déchargent le texte du segment sur disque, de sorte que leur coût en RAM est le vecteur plus un petit graphe. Le commutateur Stocker le texte du segment contrôle cette charge utile, environ 2 Ko par vecteur à 512 tokens. Redis le conserve en RAM, tous les autres moteurs le gardent sur disque, et désactiver le commutateur le supprime partout.
La base de processus fixe est ajoutée une fois par moteur : 2.0 Go pour Milvus, 0.5 pour Weaviate, 0.3 pour Chroma, 0.2 pour Qdrant, 0.05 pour Redis, et 0 pour les deux moteurs sur disque. En rassemblant le tout pour le corpus par défaut de 2 Go (1.15M vecteurs) sur un serveur de 16 Go, 200 Go, Qdrant a besoin de 5.1 Go de RAM, Milvus et Weaviate de 6.9 Go, Redis de 12.5 Go, tandis que pgvector a besoin de 16.5 Go de disque et LanceDB de 8.5 Go.
Le verdict compare cette empreinte à la boîte sur la ressource contraignante, et la ligne de 80% est une marge de sécurité délibérée. À 80% ou en dessous de la RAM ou du disque, cela indique qu'il convient, ce qui laisse environ un cinquième de la boîte pour le cache de pages du système d'exploitation, les tampons de requêtes et la croissance. De 80 à 100% est juste, et au-delà ne convient pas. Le chiffre correspond au service en régime permanent, donc la construction ou la reconstruction de l'index sur la même boîte nécessite plus de RAM pendant la durée, se rapprochant du pic mesuré. En exécutant la même formule à l'envers, on obtient la capacité, (box − base) ÷ bytes_per_vector : le même serveur de 16 Go contient nominalement 1.47M vecteurs sur Redis, 3.7M sur Qdrant, et, sur son disque de 200 Go, 14.0M sur pgvector et 27.1M sur LanceDB, chacun dans la bande d'erreur que l'outil affiche à côté plutôt qu'une ligne dure. L'activation de la quantification divise la partie vectorielle (int8 par 4x, quantification de produit par 16x, binaire par 32x) pour les moteurs qui la prennent en charge, et changer le modèle d'embedding redimensionne chaque nombre en fonction de la dimension.
Mesuré par rapport à modélisé
Le calculateur sépare ce que le benchmark a mesuré de ce qu'il modélise, car les deux ont des niveaux de confiance différents. Les chiffres de RAM que le benchmark a enregistrés sont un pic de construction et de service, qui est environ deux à trois fois plus élevé que le service en régime permanent, et pour Weaviate, cela a été gonflé par une limite de mémoire Go élevée. Le calculateur ne dimensionne pas à partir de ce pic. Il dimensionne les cinq moteurs en mémoire à partir de la formule de service documentée de chaque fournisseur, les coûts additifs vecteur plus graphe dans le tableau, et garde le pic mesuré comme vérification de limite supérieure. Ainsi, la mesure enregistre ce que le benchmark a observé, tandis que le dimensionnement est délibérément inférieur.
Les deux moteurs sur disque sont l'inverse. Leur index disque a été mesuré directement et tenu à moins de 1 à 2 pour cent sur un corpus de validation, donc le calculateur les dimensionne à partir de la mesure. Chaque capacité comporte une bande d'erreur visible qui reflète cette division : 25 à 30 pour cent pour les estimations de service en mémoire modélisées, 15 pour cent pour pgvector, et 1 à 2 pour cent pour le disque mesuré de LanceDB. Deux entrées sont étiquetées comme hypothèses plutôt que comme mesures. Le cache de RAM pour les moteurs sur disque est fixé à 25 pour cent de l'index et est modifiable, car leur RAM de service n'a jamais été mesurée, et les ratios de quantification proviennent de la littérature plutôt que de ce benchmark, de sorte que la perte de rappel réelle varie avec les données.
Le seuil de capacité
La moitié de sélection du calculateur est un ensemble de faits binaires, pas un score. Le tableau ci-dessous est le côté par moteur des commutateurs ci-dessus. Pour chaque moteur, il montre les charges de travail qui l'excluent et celles qu'il fait encore mais à un taux signalé. Milvus et Weaviate n'ont aucune élimination sur aucun commutateur, c'est pourquoi ils apparaissent comme les généralistes propres.
Redis est signalé plutôt qu'éliminé sur la durabilité car il peut être rendu anti-crash avec un fichier append-only. Il a été testé avec la persistance désactivée, donc le signalement indique que la limite est notre configuration, pas le moteur.
Ajouter comme source préféréeMéthodologie du benchmark
Les chiffres proviennent d'un benchmark sur un seul serveur des sept moteurs, chacun exécuté dans son propre conteneur Docker épinglé sur un Hetzner CCX53 (32 vCPU, 128 Go de RAM, NVMe). Chaque moteur a indexé les mêmes vecteurs bge-m3 (1024 dimensions, cosinus sur float32 normalisé L2) et a été lu à un Rappel@10 correspondant de 0.95 atteint en balayant son ef ou nprobe, avec k=10 et seed 42. Les corpus étaient MedRAG-50k et TechQA-28k pour la qualité et un niveau MedRAG de 2.25M vecteurs pour l'échelle. Les statistiques complètes, les intervalles de confiance et les versions par moteur se trouvent dans l'article de benchmark.
Limites
Les chiffres de service en mémoire sont des formules de fournisseurs calibrées par rapport à un pic de construction et de service, pas une mesure directe du service, ils comportent donc la bande de 25 à 30 pour cent que montre le calculateur. La RAM de service pour pgvector et LanceDB est une hypothèse de cache non mesurée, c'est pourquoi le calculateur dimensionne ces deux-là sur disque. Les formes de déploiement diffèrent également par conception. LanceDB est une bibliothèque embarquée, pgvector est une extension PostgreSQL, les cinq autres sont des serveurs autonomes, et Redis a fonctionné avec la persistance désactivée, donc l'empreinte et les taux de chaque moteur reflètent sa propre forme opérationnelle plutôt qu'une configuration identique. Le benchmark a utilisé un seul modèle d'embedding à 1024 dimensions, donc un modèle ou un nombre de dimensions différent modifie chaque empreinte, c'est pourquoi le modèle est une entrée plutôt qu'un nombre fixe. Les moteurs gérés et hébergés dans le cloud font l'objet d'une comparaison distincte.
Conclusion
Pour une base de données vectorielle auto-hébergée dans RAG, le choix est un problème de dimensionnement et de sélection plutôt que de précision, puisque les sept moteurs se situent à moins de 0.014 nDCG les uns des autres. Le calculateur transforme les calculs d'empreinte et les limites de charge de travail mesurées en une réponse pour un serveur spécifique plutôt qu'en un classement. Sur une boîte de 16 Go à 1024 dimensions, il contient 1.5M vecteurs sur Redis jusqu'à 3.7M sur Qdrant en RAM, et 14M à 27M sur les moteurs sur disque, et l'activation d'une charge de travail à forte rotation exclut Chroma et LanceDB tout en laissant Milvus et Weaviate sans problème. Le benchmark mesuré derrière chacun de ces chiffres est la comparaison de bases de données vectorielles open source.
Lectures complémentaires
- Benchmark de modèles d'embedding
- Benchmark de reranker
- Base de données vectorielle pour RAG
- Modèles d'embedding open source
- Modèles d'embedding multilingues
- Embeddings multimodaux
- Frameworks RAG agentiques
Citez ce benchmark
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{Calculateur de dimensionnement et de sélection de bases de données vectorielles}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/vector-database-for-rag}},
note = {AIMultiple. Consulté le 20 Juillet 2026}
}
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.