De quel espace de stockage vectoriel un million de fragments de documents personnels ont-ils besoin ?
Un million de segments nécessitent environ 1,5 à 6,1 Go pour les seuls vecteurs float32 courants, avant de tenir compte des index de graphe, des métadonnées, du texte, des réplicas et de l’espace de travail.
Le calcul commence par les dimensions, et non par le nombre de documents : un million de vecteurs de 768 dimensions contiennent 768 millions de valeurs de quatre octets, soit environ 3,07 Go en valeur décimale. Un stockage exploitable est plus volumineux, car il doit identifier les vecteurs, permettre des recherches efficaces, filtrer les métadonnées, conserver le texte des segments et résister à la maintenance des index pendant les recherches comme pendant les opérations de maintenance sur le serveur.
Les octets bruts des vecteurs constituent le seuil minimal reproductible
Multipliez le nombre de segments par le nombre de dimensions et le nombre d’octets par coordonnée. Pour un million de vecteurs float32, 384 dimensions utilisent 1,536 Go, 768 en utilisent 3,072 et 1 536 en utilisent 6,144. Les gigaoctets binaires paraissent environ sept pour cent plus petits dans les unités affichées.
Un aperçu de la mise à l’échelle présente la même relation concernant le stockage brut des vecteurs : le nombre de dimensions multiplié par la largeur des valeurs détermine la charge utile des coordonnées avant l’ajout des structures de la base de données.
Le float16 peut réduire de moitié la composante vectorielle, tandis que l’int8 ou la quantification par produit peuvent la réduire davantage. La compression peut affecter le rappel et nécessite la prise en charge de la base de données. Les documents sources et le texte généré des segments ne sont pas inclus dans ces chiffres.
Les index et les métadonnées peuvent être aussi volumineux que les coordonnées
La recherche plate ajoute relativement peu de structures d’index, mais parcourt de nombreux vecteurs. HNSW stocke des liens vers des voisins et plusieurs couches de graphe afin de réduire le travail de recherche. Les identifiants par vecteur, les marqueurs des enregistrements supprimés, les filtres, l’alignement et les pages de la base de données ajoutent une surcharge supplémentaire.
Une introduction à la connectivité HNSW explique pourquoi la connectivité des graphes accélère la recherche approximative tout en consommant davantage de mémoire et de stockage. Le nombre de voisins configuré modifie directement ce coût.
Les métadonnées varient encore davantage. Un identifiant de document compact et un code de langue peuvent ajouter quelques dizaines d’octets ; des chemins répétés, des autorisations et le texte complet des segments peuvent en ajouter des centaines ou des milliers. Stockez le texte une seule fois ou de manière cohérente dans la base de données vectorielle avant de comparer les totaux.
Pourquoi une estimation unique du stockage peut être trompeuse
Pour un million de segments float32 de 768 dimensions, une fourchette de planification pratique est souvent de 5 à 12 Go pour les vecteurs et un index approximatif, avant d’ajouter une quantité importante de texte et les réplicas. Il s’agit d’une fourchette budgétaire, pas d’une garantie liée à un format.
Une comparaison des architectures vectorielles estime une surcharge de stockage HNSW qui dépasse largement les coordonnées brutes pour certaines configurations HNSW. Les paramètres par défaut du moteur et ceux du graphe déterminent le multiplicateur réel.
Cette fourchette devient inadaptée avec plusieurs embeddings par segment, des index de mots-clés hybrides, la réplication, les instantanés ou les reconstructions qui dupliquent temporairement les données. Elle peut aussi surestimer un stockage compressé sur disque. « Un million de segments » ne suffit pas si les dimensions, le type de données, l’index, les métadonnées et le nombre de copies ne sont pas précisés.
Extrapolez à partir d’un échantillon d’index de dix pour cent
Insérez 100 000 segments représentatifs en utilisant le type de données final des embeddings, le schéma de métadonnées et les paramètres d’index définitifs. Mesurez séparément la colonne de vecteurs bruts, l’index, les métadonnées, le texte, les octets du journal de préécriture et ceux des instantanés après compactage. Multipliez par dix les composants évolutifs et ajoutez une marge pour la reconstruction et les sauvegardes.
Effectuez le test sur le niveau de stockage de l’espace de travail prévu, car la compression et l’allocation du système de fichiers influencent les totaux physiques. Évitez toute extrapolation à partir de fichiers de base de données vides.
Prévoyez au minimum le total stable mesuré, plus une copie temporaire de l’index et 20 % d’espace libre. Si la réplication est activée, multipliez uniquement les composants répliqués. Répétez l’échantillonnage chaque fois que les dimensions, les métadonnées ou les paramètres de voisinage HNSW changent.
Produits recommandés
Centre Tech & IA
Plus à lire
Comment mesurer la qualité de la récupération RAG locale et interpréter le rappel, la précision et la couverture des citations
Créez un jeu de test RAG local, calculez les principales métriques de récupération, interprétez leurs compromis et vérifiez si les affirmations des réponses sont...
Pourquoi le calcul des fonctionnalités de la maison intelligente devient-il plus important lorsque le nombre de capteurs augmente à fréquence d’échantillonnage constante ?
Suivez les calculs par capteur et intercapteurs à mesure que le nombre d’appareils augmente, identifiez les coûts de fusion non linéaires et évaluez les...
Pourquoi le coût de l’évaluation du RAG devient-il plus important à mesure que la bibliothèque de documents s’agrandit, pour un même volume de requêtes ?
Comprenez pourquoi l’augmentation du corpus accroît l’effort d’évaluation du RAG sans augmenter le nombre de requêtes des utilisateurs, et comment les tests stratifiés maintiennent...
