Calcolatore per il dimensionamento e la scelta di database vettoriali
La domanda pratica dietro un database vettoriale self-hosted per RAG è quale motore si adatta a un dato server, e quale il carico di lavoro esclude. Il calcolatore qui sotto risponde a entrambe, dal nostro benchmark di sette database vettoriali self-hosted eseguiti con recall abbinata su embedding identici.
Metriche del calcolatore spiegate
Cinque caselle di controllo nella parte superiore del calcolatore denominano cinque carichi di lavoro RAG comuni, e ciascuna corrisponde a un limite misurato dal benchmark piuttosto che a una dichiarazione del fornitore. Selezionarne una filtra l'elenco dei motori rispetto a un numero specifico. Lasciarla deselezionata significa che il carico di lavoro non è applicabile, e nessun motore viene filtrato in base a esso. Cosa richiede ciascun interruttore, e la misurazione che lo sostiene:
Selezione e dimensionamento
Due decisioni precedono un indice in esecuzione. La prima è la selezione, perché alcuni motori non possono svolgere un determinato compito. Il calcolatore verifica ciascun motore rispetto ai cinque interruttori dei requisiti sopra ed elimina quelli che falliscono. La seconda è il dimensionamento, ovvero quali dei motori sopravvissuti si adattano al server e con quale margine. Per ogni sopravvissuto riporta se si adatta, è stretto o non si adatta, più il numero di vettori che il server conterrebbe. Nessuna decisione ruota attorno alla qualità del recupero, poiché i sette motori si equivalgono entro uno spread nDCG di 0.014 rispetto a un oracolo esatto kNN.
Impronta a 2.25M vettori
Con 2.25M vettori il benchmark ha misurato due impronte, suddivise in base a dove risiede l'indice. Per i cinque motori in-memory ha registrato il picco di RAM durante la costruzione e l'erogazione, da 17.0 GB (Milvus) a 62.4 GB (Chroma). Per i due motori su disco ha registrato l'indice su disco, 12.0 GB per LanceDB e 18.4 GB per pgvector, che costa molto meno per gigabyte. Quei numeri sono le misurazioni grezze, non gli input di dimensionamento del calcolatore. Il calcolatore dimensiona invece il servizio a regime.
Per i motori in-memory, l'impronta a regime è inferiore al picco di costruzione e servizio, e per i motori su disco aggiunge la copia della tabella e il testo dei chunk sull'indice misurato, quindi per lo stesso corpus di 2.25M i suoi numeri risultano inferiori in RAM e superiori su disco rispetto alle barre qui. La suddivisione misurata-contro-modellata di seguito riconcilia i due. Il confronto completo per motore dietro il calcolatore, su accuratezza, velocità, ricerca filtrata e ibrida, costo di costruzione e rotazione in tempo reale, confronto di database vettoriali open-source.
Il modello di dimensionamento
Gli input sono la dimensione del corpus, il chunking e il modello di embedding, e il calcolatore deriva i due numeri che guidano il dimensionamento. La dimensione del corpus e il chunking forniscono il conteggio dei vettori. Un corpus da 2 GB (decimali, 2 miliardi di byte) a 4 byte per token 500M token, e chunk da 512 token con 15% di sovrapposizione avanzano di un passo di 512 × 0.85 = 435.2 token, quindi il conteggio è round(500M ÷ 435.2) = 1,148,897 vettori. Il modello di embedding fornisce la dimensione, quindi l'input è la scelta del modello, non un numero grezzo, e bge-m3 lo imposta a 1024.
L'impronta di ciascun motore è quindi un costo per vettore moltiplicato per il conteggio dei vettori, più un costo fisso di processo: footprint = base_gb + bytes_per_vector × N. Il costo per vettore è dove i motori divergono, perché un database vettoriale memorizza più del semplice vettore grezzo. Contiene anche il grafo dell'indice che rende la ricerca veloce e, per RAG reale, il testo del chunk che deve restituire. La tabella seguente mostra il costo per vettore che la struttura di archiviazione di ciascun motore produce a 1024 dimensioni in float32.
Due fatti di layout fanno la maggior parte della separazione. Redis mantiene una seconda copia di ogni vettore (un hash sorgente più una copia nell'indice) e non può scaricare il testo del chunk, quindi è il più pesante in RAM. pgvector memorizza ogni vettore due volte anche su disco, una volta nell'heap della tabella e una all'interno dell'indice HNSW, e il suo indice arrotonda a pagine Postgres da 8 KB, quindi un vettore float32 a 1024 dimensioni riempie una pagina intera da solo. Gli altri quattro motori in-memory scaricano il testo del chunk su disco, quindi il loro costo in RAM è il vettore più un piccolo grafo. L'interruttore 'Store chunk text' controlla quel carico, circa 2 KB per vettore a 512 token. Redis lo tiene in RAM, tutti gli altri motori lo tengono su disco e spegnendo l'interruttore lo rimuove ovunque.
Il costo fisso del processo viene aggiunto una volta per motore: 2.0 GB per Milvus, 0.5 per Weaviate, 0.3 per Chroma, 0.2 per Qdrant, 0.05 per Redis e 0 per i due motori su disco. Mettendo insieme per il corpus predefinito da 2 GB (1.15M vettori) su un server da 16 GB, 200 GB, Qdrant ha bisogno di 5.1 GB di RAM, Milvus e Weaviate 6.9 GB, Redis 12.5 GB, mentre pgvector necessita di 16.5 GB di disco e LanceDB 8.5 GB.
Il verdetto confronta quell'impronta con il server sulla risorsa vincolante, e la linea del 80% è un margine deliberato. Al di sotto del 80% di RAM o disco risulta 'si adatta', il che lascia circa un quinto del server per la cache delle pagine del sistema operativo, i buffer di query e la crescita. Dal 80 al 100% è 'stretto', e oltre non si adatta. La cifra è per il servizio a regime, quindi costruire o ricostruire l'indice sullo stesso server richiede più RAM per la durata, più vicino al picco misurato. Eseguendo la stessa formula al contrario si ottiene la capacità, (box − base) ÷ bytes_per_vector: lo stesso server da 16 GB contiene nominalmente 1.47M vettori su Redis, 3.7M su Qdrant, e, sul suo disco da 200 GB, 14.0M su pgvector e 27.1M su LanceDB, ciascuno all'interno della banda di errore che lo strumento mostra accanto, piuttosto che una linea netta. Attivare la quantizzazione divide la parte vettoriale (int8 per 4x, quantizzazione del prodotto per 16x, binaria per 32x) per i motori che la supportano, e cambiare il modello di embedding ridimensiona ogni numero attraverso la dimensione.
Misurato contro modellato
Il calcolatore separa ciò che il benchmark ha misurato da ciò che modella, poiché i due hanno diversi livelli di confidenza. I valori di RAM registrati dal benchmark sono un picco di costruzione e servizio, che è circa due o tre volte superiore al servizio a regime, e per Weaviate è stato gonfiato da un limite di memoria Go elevato. Il calcolatore non dimensiona a partire da quel picco. Dimensiona i cinque motori in-memory in base alla formula di servizio documentata da ciascun produttore, i costi additivi vettore-più-grafo nella tabella, e mantiene il picco misurato come controllo del limite superiore. Quindi la misurazione registra ciò che il benchmark ha osservato, mentre il dimensionamento rimane al di sotto di proposito.
I due motori su disco sono il contrario. Il loro indice su disco è stato misurato direttamente e mantenuto entro l'1-2 percento su un corpus di test tenuto da parte, quindi il calcolatore li dimensiona a partire dalla misurazione. Ogni capacità ha una banda di errore visibile che riflette questa suddivisione: 25 fino a 30 percento per le stime di servizio in-memory modellate, 15 percento per pgvector e dall'1 al 2 percento per la misurazione su disco di LanceDB. Due input sono etichettati come ipotesi piuttosto che misurazioni. La cache RAM per i motori su disco è impostata al 25 percento dell'indice ed è modificabile, perché la loro RAM di servizio non è mai stata misurata, e i rapporti di quantizzazione provengono dalla letteratura piuttosto che da questo benchmark, quindi la perdita di recall reale varia con i dati.
Il filtro di capacità
La metà di selezione del calcolatore è un insieme di fatti binari, non un punteggio. La tabella seguente mostra il lato per motore degli interruttori sopra. Per ciascun motore, mostra i carichi di lavoro che lo escludono e quelli che può ancora svolgere ma a un tasso segnalato. Milvus e Weaviate non subiscono alcuna esclusione su alcun interruttore, motivo per cui risultano come i generalisti puliti.
Redis viene segnalato piuttosto che escluso per la durabilità perché può essere reso a prova di crash con un file append-only. È stato sottoposto a benchmark con la persistenza disattivata, quindi il flag nota che il limite è la nostra configurazione, non il motore.
Aggiungi come fonte preferitaMetodologia del benchmark
I numeri provengono da un benchmark su server singolo dei sette motori, ciascuno eseguito nel proprio container Docker associato su un Hetzner CCX53 (32 vCPU, 128 GB RAM, NVMe). Ogni motore ha indicizzato gli stessi vettori bge-m3 (1024-dim, coseno su float32 normalizzato L2) e sono stati letti con un Recall@10 abbinato di 0.95 raggiunto facendo variare ef o nprobe, con k=10 e seed 42. I corpus erano MedRAG-50k e TechQA-28k per la qualità e un livello MedRAG da 2.25M vettori per la scalabilità. Le statistiche complete, gli intervalli di confidenza e le versioni per motore sono nell'articolo del benchmark.
Limitazioni
Le cifre di servizio in-memory sono formule del fornitore calibrate rispetto a un picco di costruzione e servizio, non una misurazione diretta del servizio, quindi portano la banda del 25 fino al 30 percento che il calcolatore mostra. La RAM di servizio per pgvector e LanceDB è un'ipotesi di cache non misurata, motivo per cui il calcolatore dimensiona questi due su disco. Anche le forme di distribuzione differiscono per progettazione. LanceDB è una libreria embedded, pgvector è un'estensione PostgreSQL, gli altri cinque sono server autonomi e Redis è stato eseguito con persistenza disattivata, quindi l'impronta e i tassi di ciascun motore riflettono la propria forma operativa anziché una configurazione identica. Il benchmark ha utilizzato un modello di embedding a 1024 dimensioni, quindi un modello diverso o un numero diverso di dimensioni cambia ogni impronta, motivo per cui il modello è un input anziché un numero fisso. I motori gestiti e ospitati su cloud sono un confronto separato.
Conclusione
Per un database vettoriale self-hosted in RAG, la scelta è un problema di dimensionamento e selezione piuttosto che di accuratezza, poiché i sette motori si collocano entro 0.014 nDCG l'uno dall'altro. Il calcolatore trasforma la matematica dell'impronta e i limiti di carico misurati in una risposta per un server specifico anziché in una classifica. Su un server da 16 GB a 1024 dimensioni contiene 1.5M vettori su Redis fino a 3.7M su Qdrant in RAM, e da 14M a 27M sui motori su disco, e attivare un carico di lavoro con elevata rotazione esclude Chroma e LanceDB lasciando Milvus e Weaviate liberi. Il benchmark misurato dietro ognuno di questi numeri è il confronto di database vettoriali open-source.
Ulteriori letture
- Benchmark dei modelli di embedding
- Benchmark dei reranker
- Database vettoriale per RAG
- Modelli di embedding open-source
- Modelli di embedding multilingue
- Embedding multimodali
- Framework Agentic RAG
Cita questo benchmark
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{Calcolatore per il dimensionamento e la scelta di database vettoriali}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/vector-database-for-rag}},
note = {AIMultiple. Consultato il 20 Luglio 2026}
}
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.