Quanto spazio di archiviazione vettoriale richiedono un milione di frammenti di documenti domestici?
Un milione di chunk richiede circa 1,5–6,1 GB soltanto per i comuni vettori float32, prima di aggiungere indici a grafo, metadati, testo, repliche e spazio di lavoro.
Il calcolo parte dalle dimensioni, non dal numero di documenti: un milione di vettori da 768 dimensioni contiene 768 milioni di valori da quattro byte, ovvero circa 3,07 GB decimali. Un archivio pronto per la distribuzione è più grande perché deve identificare i vettori, cercarli in modo efficiente, filtrare i metadati, conservare il testo dei chunk e resistere alla manutenzione degli indici durante le operazioni di ricerca e manutenzione sul server.
I byte dei vettori grezzi forniscono il limite minimo riproducibile
Moltiplica il numero di chunk per le dimensioni degli embedding e per i byte di ogni coordinata. Per un milione di vettori float32, 384 dimensioni richiedono 1,536 GB, 768 ne richiedono 3,072 GB e 1.536 ne richiedono 6,144 GB. I gigabyte binari risultano circa il sette percento più piccoli nelle unità visualizzate.
Una panoramica sul dimensionamento mostra la stessa relazione dello spazio di archiviazione dei vettori grezzi: il numero di dimensioni moltiplicato per la larghezza del valore determina il contenuto delle coordinate prima delle strutture del database.
Float16 può dimezzare la componente vettoriale, mentre int8 o la quantizzazione del prodotto possono ridurla ulteriormente. La compressione può influire sul richiamo e richiede il supporto del database. I documenti sorgente e il testo generato dei chunk non sono inclusi in questi numeri.
Gli indici e i metadati possono essere comparabili alle coordinate
La ricerca piatta aggiunge una struttura d'indice relativamente ridotta, ma analizza molti vettori. HNSW memorizza collegamenti tra vicini e più livelli del grafo per ridurre il lavoro di ricerca. ID per vettore, marcatori dei record eliminati, filtri, allineamento e pagine del database aggiungono ulteriore overhead.
Un'introduzione alla connettività HNSW descrive perché la connettività del grafo accelera la ricerca approssimata consumando al contempo memoria e spazio di archiviazione aggiuntivi. Il numero di vicini configurato modifica direttamente questo costo.
I metadati variano ancora di più. Un ID documento compatto e un codice lingua possono aggiungere decine di byte; percorsi ripetuti, autorizzazioni e testo completo dei chunk possono aggiungerne centinaia o migliaia. Archivia il testo una sola volta o in modo coerente all'interno del database vettoriale prima di confrontare i totali.
Quando una singola stima dello spazio di archiviazione non è sufficiente
Un intervallo pratico di pianificazione per un milione di chunk float32 da 768 dimensioni è spesso di 5–12 GB per i vettori più un indice approssimato, prima di aggiungere quantità significative di testo e repliche. Si tratta di un intervallo per la pianificazione, non di una garanzia sul formato.
Un confronto tra architetture vettoriali stima un overhead di archiviazione HNSW che, con alcune configurazioni HNSW, supera sostanzialmente le coordinate grezze. I valori predefiniti del motore e i parametri del grafo determinano il moltiplicatore reale.
L'intervallo non è valido in presenza di più embedding per chunk, indici ibridi per parole chiave, replica, snapshot o ricostruzioni che duplicano temporaneamente i dati. Può inoltre sovrastimare un archivio compresso basato su disco. “Un milione di chunk” non è sufficiente se non vengono specificati dimensioni, dtype, indice, metadati e numero di copie.
Estrarre una stima da un campione d'indice del dieci percento
Inserisci 100.000 chunk rappresentativi utilizzando il dtype finale degli embedding, lo schema dei metadati e i parametri dell'indice. Dopo la compattazione, misura separatamente i byte della colonna dei vettori grezzi, dell'indice, dei metadati, del testo, del registro write-ahead e degli snapshot. Moltiplica per dieci le componenti scalabili e aggiungi margine per la ricostruzione e il backup.
Esegui il test sul livello di spazio di lavoro dello storage previsto, perché la compressione e l'allocazione del filesystem influenzano i totali fisici. Evita di estrapolare da file di database vuoti.
Prevedi almeno il totale stabile misurato, più una copia temporanea dell'indice e il 20 percento di spazio libero. Se la replica è abilitata, moltiplica solo le componenti replicate. Ripeti il campionamento ogni volta che cambiano le dimensioni, i metadati o le impostazioni dei vicini HNSW.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Come misurare la qualità del recupero RAG locale e interpretare recall, precisione e copertura delle citazioni
Crea un set di test RAG locale, calcola le metriche di base del recupero, interpretane i compromessi e verifica se le affermazioni nelle risposte...
Perché l’elaborazione delle funzionalità della casa intelligente diventa più importante all’aumentare del numero di sensori con la stessa frequenza di campionamento?
Monitora i calcoli per sensore e tra sensori all’aumentare del numero di dispositivi, identifica i costi di fusione non lineari e valuta le prestazioni...
Perché il costo della valutazione RAG diventa più importante con l’aumentare della libreria di documenti, a parità di volume di query?
Comprendi perché la crescita del corpus aumenta lo sforzo di valutazione del RAG senza un aumento delle query degli utenti e come i test...
