Benchmark di database vettoriali: 7 motori open-source per RAG

Abbiamo confrontato sette database vettoriali open-source e self-hosted come livello di recupero di una pipeline RAG, eseguiti uno alla volta su embedding bge-m3 identici e query reali mediche e tecniche, così che l'indice del database fosse l'unica variabile. Il carico di lavoro ha coperto MedRAG-50k, TechQA-28k e un corpus di 2.25M vettori attraverso otto dimensioni, dall'accuratezza e qualità del recupero fino a velocità, memoria, ricerca filtrata e ibrida, costo di costruzione e variazione in tempo reale.

Velocità single-thread

Ogni motore viene valutato allo stesso livello di recall, il punto operativo condiviso in cui il suo parametro di ricerca (ef o nprobe) viene regolato fino a raggiungere un Recall@10 di 0.95, consentendo un confronto equo dei valori di velocità.

Su un singolo thread client, Redis eroga 764 QPS su MedRAG-50k con 559 MB di RAM di picco, il throughput più alto e la memoria più bassa del gruppo. L'ordine single-thread è Redis 764, Qdrant 377, Milvus 342, Weaviate 341, pgvector 257, Chroma 197, LanceDB 70, una forbice di 10x tra il primo e l'ultimo. LanceDB è l'outlier on-disk, scambiando RAM con la latenza con un p95 vicino a 22 ms. Redis resta il più veloce e LanceDB il più lento su TechQA-28k (651 contro 81) e a 2.25M (495 contro 28), anche se la parte centrale si rimescola su larga scala, dove Milvus scende dal terzo al sesto posto.

Per la RAG, la latenza di coda influenza l'esperienza utente più del throughput grezzo. La latenza per query, aggregata su 100 esecuzioni di 154 query a parità di recall, segue l'ordine del throughput.

Redis è stato eseguito con persistenza disattivata (nessuno snapshot RDB né file append-only), quindi i suoi valori di velocità e memoria si riferiscono a una configurazione volatile senza durabilità.

Throughput sotto concorrenza

I QPS single-thread rispondono a quanto velocemente viene eseguita una singola query. La domanda di produzione è il throughput con molti client concorrenti, e la risposta dipende da come è costruito il client, non solo dal database.

Un client a ciclo chiuso può essere guidato in due modi, entrambi comuni nelle app Python RAG. Un singolo processo asincrono o thread deserializza ogni risultato concorrente (gRPC/protobuf o RESP) su un unico GIL, quindi è il client, non il server, a limitare il throughput. Molti processi worker (il pattern gunicorn -w N) dispongono ciascuno del proprio GIL, esponendo molta più capacità del server. Abbiamo misurato entrambi su un box da 32 vCPU con ef fisso=128, verificando il recall per ogni punto.

Quando la concorrenza delle richieste sale da 1 a 512 attraverso fino a 32 processi worker, le linee di throughput si incrociano. Redis parte più in alto con una richiesta e finisce più in basso, mentre Weaviate sale dal fondo del gruppo fino a un plateau di 8330 QPS a 512 richieste, superando 7.114 lungo il percorso a 32. Su un singolo processo asincrono la classifica segue invece l'efficienza di parsing del client Python, poiché il RESP di Redis è il più leggero da deserializzare e perde meno a causa del GIL.

Il picco a processo singolo e il picco a 32 processi di ciascun motore sono i massimi dell'intera scansione da 1 a 512, non il throughput a un singolo numero di richieste.

Redis mantiene la latenza di singola query più bassa del gruppo (circa 1.6 ms), e il suo core di ricerca single-thread satura intorno a 1642 QPS a 32 richieste concorrenti, poi va in anti-scalabilità oltre quel punto (il pool di thread di query WORKERS di RediSearch è disattivato per impostazione predefinita). Weaviate e Milvus (server multi-thread) e pgvector (un backend Postgres indipendente per connessione) scalano sui 32 core. pgvector ha il picco a processo singolo più basso (536) e il secondo picco a 32 processi più alto (4832). Con un budget p99 inferiore a 100ms, l'ordine multi-processo è Weaviate 8290, pgvector 4828, Milvus 4725, Qdrant 1737, Redis 1642.

Il parsing gRPC più pesante di Qdrant rende il suo valore co-locato limitato dal client piuttosto che dal server, poiché il solo numero di processi lo porta da 455 QPS su un processo a 1859 su 32. Chroma e LanceDB sono stati esclusi dall'esecuzione multi-processo. Chroma fissa ef alla creazione della collezione e mostra anti-scalabilità, con un p99 di 13 secondi a 512 richieste, e LanceDB è incorporato, quindi il discorso del client di rete non si applica.

Impronta di memoria

A 50k vettori, la RAM di picco va da 559 MB (Redis, in-RAM, persistenza disattivata) a 3.300 MB (Milvus), con Weaviate a 1.201, LanceDB a 1.574, Chroma a 1.800 e pgvector a 2.024. La classifica cambia a 2.25M, dove si apre il compromesso tra memoria e disco.

La RAM di picco a 2.25M, tra i cinque motori in-memory, va da 17.0 GB (Milvus) a 62.4 GB (Chroma), un intervallo di 3.7x, ovvero da 7.5 GB a 27.7 GB per milione di vettori. Milvus resta il più snello perché scarica l'indice su disco (stile DiskANN), mentre i motori HNSW interamente in-RAM crescono più rapidamente; così Milvus, il più pesante a 50k (3.300 MB), è il più snello a 2.25M (17.0 GB), con Chroma il più pesante a 62.4 GB.

I due motori on-disk restano fuori da questo confronto sulla RAM perché la loro impronta è su disco piuttosto che in RAM. pgvector mantiene un indice on-disk di 18.4 GB e LanceDB uno di 12.0 GB a 2.25M, e la loro RAM di servizio è una page cache su quell'indice piuttosto che l'intero working set, che non è stato misurato. Una precisazione vale anche per i valori in-memory: sono un picco di build-and-serve, non un'impronta solo di serving, quindi una nuova misurazione solo in serving resta una rifinitura aperta.

Freschezza, scritture ed eliminazioni sotto churn in tempo reale

Le altre sette dimensioni misurano un corpus statico caricato in blocco e poi letto. Le basi di conoscenza RAG reali aggiungono, aggiornano ed eliminano documenti continuamente mentre l'indice viene unito in background. Questo carico di churn è stato eseguito su MedRAG-50k su un box separato da 8 vCPU, quindi il suo throughput è interno a questa sezione e non confrontabile con i valori di velocità a 32 core. I segnali di correttezza (controlli di recall e tombstone) sono indipendenti dall'hardware.

Freschezza (read-after-write). Con l'impostazione di consistenza con cui è stato configurato ciascun motore, tutti garantiscono la lettura dopo la scrittura. Un documento appena scritto è immediatamente ricercabile, con zero scritture non visibili su circa 150. La latenza dall'ack di scrittura alla visibilità in ricerca è di 2 ms p50 per Redis, 4 ms per Weaviate, 9 ms per Qdrant, 12 ms per Milvus, 14 ms per pgvector, 31 ms per LanceDB e 41 ms per Chroma. Milvus trova la nuova riga tramite una scansione a consistenza forte del segmento in crescita non ancora sigillato (il vettore entra nel grafo HNSW persistente più tardi), quindi i suoi 12 ms rappresentano la ricercabilità del segmento in crescita, una valida lettura-dopo-scrittura dal punto di vista utente.

Scritture e letture sotto carico misto. Con un writer che punta a 150 scritture/s e sei reader che eseguono query per 60 secondi, il recall in lettura si è mantenuto tra 0.96 e 1.00 per ogni motore e nessun indice è degradato sotto scritture concorrenti. Il throughput di scrittura a riga singola separa i motori di 57x, e l'ordine è vicino all'inverso della classifica di costruzione statica.

LanceDB paga un commit copy-on-write per riga e Chroma un'aggiunta HTTP per riga, ed è per questo che i costruttori statici più veloci sono i più lenti sotto churn. Il throughput di scrittura qui è il tasso raggiunto rispetto a un obiettivo di 150/s sotto letture concorrenti, quindi i motori veloci sono limitati vicino a 150 piuttosto che mostrare il loro picco. Va letto come comportamento di scrittura online a riga singola e ad alta frequenza, non come ingestion batch, che è il punto di forza di questi motori e qui non è testato.

Eliminazione e compattazione. Eliminando un 20% casuale del set attivo e reinserendo 20% di nuovi documenti, la perdita di tombstone è stata zero per ogni motore. Un id eliminato non è mai riapparso nella ricerca, e Recall@10 è rimasto tra 0.97 e 1.00 dopo il ciclo completo. La correttezza regge sotto churn ovunque. Il costo varia in base al motore. pgvector paga un VACUUM di 53 secondi e Milvus una compattazione di 11 secondi, mentre per i motori a scrittura lenta domina il reinserimento (Chroma 276 s, LanceDB 1139 s per circa 6.000 documenti).

Weaviate ha eseguito questa sezione con 3.000 documenti iniziali invece di 30.000 (il suo inserimento bulk sincrono è lento sul box piccolo), quindi i suoi QPS di lettura riguardano un corpus più piccolo. A quella scala la sua freschezza corretta è di circa 5 ms e il suo tasso di scrittura di circa 102/s, il che colloca entrambi a metà gruppo.

Metriche spiegate

ANN Recall@10 è la frazione dei 10 veri vettori più vicini (secondo un oracolo kNN esatto a forza bruta sugli stessi embedding indicizzati dal DB) restituita dall'indice approssimato. Isola il database (tipo di indice, ef/nprobe, implementazione), non l'embedding.

nDCG@10 è un punteggio da 0 a 1 ponderato per posizione che indica se il documento corretto etichettato da umani compare vicino alla cima della lista dei risultati. Misura la rilevanza del recupero end-to-end, che è in gran parte una proprietà del modello di embedding, mantenuto costante qui tra tutti i motori.

Δ (delta bridge) è l'nDCG@10 dell'oracolo meno l'nDCG@10 del database a una data impostazione di ricerca. Converte l'errore di approssimazione di ciascun motore nella qualità della risposta che la sua velocità costa, ed è riportabile perché disponiamo sia di un oracolo sia di etichette umane.

Risultati del benchmark dei database vettoriali

I sette motori sono pari sull'accuratezza del recupero

A Recall@10 = 0.95 su MedRAG-50k, nDCG@10 si colloca tra 0.803 (pgvector) e 0.817 (LanceDB), una forbice di 0.014. Il ponte delta-oracolo va da 0.009 (LanceDB) a 0.023 (pgvector), quindi l'approssimazione del database costa al massimo 0.023 punti di nDCG di qualità della risposta.

Con questo embedding, corpus, punto operativo k=10 e 0.95, la scelta del database sposta nDCG@10 al massimo di 0.014, contro la forbice di 10x nel throughput single-thread e la forbice di 3.7x nella memoria di picco mostrate sopra. La scelta dell'indice inizia a spostare la qualità a Recall@10 = 0.99 o superiore, con k più grandi, con corpus molto più ampi o con indici quantizzati.

L'affidabilità del recupero varia più in base a ciò che chiede una query che a quale database risponde. Sulle 154 query MedRAG all'oracolo kNN esatto, le ricerche factoid ottengono 0.888 nDCG@10, le domande condizionali 0.836, le domande comparative 0.779 e le domande di esistenza di clausole 0.763. Il divario di 0.125 tra factoid ed esistenza di clausole è presente in modo identico in tutti e sette i motori.

I filtri sui metadati costano throughput, non recall

Con un predicato sui metadati applicato, il Recall@10 nel caso peggiore resta tra 0.968 (Redis) e 1.00 (Weaviate, pgvector, LanceDB) su una griglia di selettività (1/5/20/50%) e correlazione dei predicati (sparsi e raggruppati). La separazione è nel throughput filtrato.

La separazione è nel throughput. Chroma (11-19 QPS) e pgvector (10-56 QPS) mantengono il recall con un throughput filtrato da 20 a 40x inferiore rispetto agli altri. Milvus mantiene il recall più alto nel caso peggiore (0.984) con 268 a 732 QPS lungo la selettività, mentre Redis è il più veloce a bassa selettività (1.374 QPS al 1%) con un livello di recall più basso (0.968). A selettività 1-5%, un recall di 1.00 è in gran parte il ramo di scansione completa esatta del query planner sotto la soglia di scansione completa di ciascun motore, non HNSW filtrabile, dichiarato per ogni motore.

*Il recall filtrato di LanceDB è stato misurato inizialmente a 0.24 su filtri raggruppati, poi ritirato. La scansione variava ef, ma la manopola del recall di LanceDB è nprobes, quindi è stato eseguito a un valore predefinito di circa 9% delle partizioni. Rimisurato con nprobes corretti, il Recall@10 raggruppato recupera da 0.24 a 0.76 (nprobes=128) fino a circa 1.00 (nprobes=256), con QPS inferiori da 3 a 5x. LanceDB mantiene il recall filtrato, lentamente. Una rimisurazione del throughput filtrato a parità di recall e sullo stesso host è ancora in sospeso, quindi i QPS filtrati di LanceDB non sono elencati.

La ricerca ibrida aggiunge fino a 0.067 nDCG

Aggiungendo un braccio BM25 standard e fondendolo con il braccio denso tramite fusion a rango reciproco (RRF, k=60), nDCG@10 aumenta di 0.030 a 0.067 per ogni motore dotato di un braccio keyword. Su MedRAG i bracci denso e BM25 hanno individualmente una forza quasi uguale (circa 0.80 ciascuno), quindi l'incremento recupera gli errori di ciascun braccio piuttosto che far dominare un singolo braccio.

I motori con un braccio BM25 forte guadagnano di più, mentre pgvector e Weaviate guadagnano meno, seguendo i loro bracci keyword più deboli (0.740 e 0.782). Nessun ibrido di alcun motore scende sotto il proprio braccio denso una volta misurato correttamente.

Ciò che distingue i motori è la fusion nativa rispetto a round-trip lato client, da Milvus a 340 QPS nativa a pgvector a 12 QPS lato client. Quattro motori fondono nativamente (Qdrant, Milvus, Weaviate, LanceDB). Redis esegue BM25 e KNN nativi ma nessuna fusion lato server in questa versione, quindi il client effettua due round trip e fonde in Python. pgvector non ha fusion API, fonde lato client e il suo braccio keyword è Postgres ts_rank (term frequency con normalizzazione della lunghezza, senza IDF), che con una scansione full-text OR gira a 12 QPS. Chroma self-hosted non ha alcuna ricerca keyword con ranking (BM25 è una funzionalità di Chroma Cloud), quindi non ha una riga ibrida.

Il tempo di costruzione dell'indice arriva a 13x

A 50k vettori, la costruzione dell'indice va da 7 secondi (LanceDB) e 11 a 13 (Weaviate, Milvus) fino a 88 secondi (pgvector). A 2.25M la forbice raggiunge 13x. LanceDB e Milvus terminano in 7-8 minuti, contro 44 minuti per Redis e 92 per pgvector. Normalizzato al costo del box, il costo di costruzione va da €0.04 per 1M vettori (LanceDB) e €0.05 (Milvus) a €0.58 (pgvector). La costruzione è un costo una tantum, pagato di nuovo solo quando il corpus viene re-indicizzato.

Qualità del recupero a 2.25M vettori

Per testare la qualità su larga scala mantenendo etichette umane reali, abbiamo costruito un corpus di 2.25M vettori. Combina i 50k documenti MedRAG etichettati con 2.2M distrattori PubMed, tutti nello stesso spazio bge-m3, con controllo di integrità affinché nessun distrattore sia un bersaglio etichettato male. I dataset ANN standard su scala miliardi non contengono etichette di rilevanza umane, quindi non possono mostrare cosa succede dopo.

Il recall ANN geometrico regge su scala. Ogni motore raggiunge ancora Recall@10 sopra 0.973 a 2.25M (Qdrant e Milvus a 0.999), quindi l'indice trova i veri vettori più vicini. La qualità semantica delle risposte non regge. nDCG@10 scende da circa 0.81 a 50k a circa 0.56 a 2.25M per ogni motore, perché il documento corretto è sepolto tra 2.2M distrattori.

Il crollo non è un effetto del database. Colpisce in modo identico l'oracolo kNN esatto (nDCG@10 dell'oracolo a 2.25M è 0.572, e ogni motore si colloca su quel tetto intorno a 0.55-0.57). Se la causa sia il tetto dell'embedding, l'ambiguità del corpus o etichette single-positive che perdono quasi-duplicati ora rilevanti non viene stabilito qui. Separare quelle cause richiede una nuova etichettatura umana dei documenti recentemente primi in classifica. Il fatto riportabile è che scalare il corpus di 45x ha cancellato circa un terzo della qualità delle risposte (nDCG@10 da 0.81 a 0.56) lasciando ogni indice ANN con recall quasi perfetto, un effetto che un benchmark solo geometrico non vedrebbe.

Durabilità, alta disponibilità e sicurezza per motore

Velocità, memoria e recall sono gli assi misurati. Per un deployment RAG in produzione anche gli assi non misurati (durabilità, alta disponibilità, controllo degli accessi) distinguono questi motori. Questo inventario di capacità è fondato sulla documentazione ufficiale di ciascun motore nell'edizione open-source benchmarkata. È un inventario di capacità, non un chaos test. Il tempo di failover effettivo, la finestra di perdita di dati nel ripristino da crash e l'isolamento dei tenant sotto carico non sono misurati qui.

Tra i sette, solo pgvector offre il ripristino point-in-time (tramite archiviazione WAL di Postgres) e sicurezza a livello di riga. Qdrant, Milvus e Weaviate includono replica e RBAC nelle loro build open-source, con l'avvertenza che l'alta disponibilità di Milvus risiede nella modalità distribuita più pesante, non nella build stand-alone misurata qui. Nessuno dei sette cripta i dati su disco in modo nativo. Tutti si affidano alla crittografia del disco o del volume a livello di infrastruttura.

Per RAG multi-tenant, dove un filtro funge anche da confine di controllo degli accessi, Qdrant, Milvus, Weaviate e pgvector possono imporre l'isolamento dei tenant all'interno del database. Chroma e LanceDB incorporato lo demandano all'applicazione. Un pre-filtro corretto restituisce meno risultati, un rischio di completezza, piuttosto che far trapelare i documenti di un altro tenant. Una perdita cross-tenant richiederebbe un post-filtro difettoso, che nessuno di questi motori ha usato.

Come funziona la ricerca approssimata dei vicini più prossimi

Un database vettoriale memorizza un vettore ad alta dimensionalità per documento e, dato un vettore di query, restituisce i k più vicini in base a una metrica di distanza (qui coseno su vettori normalizzati L2). La ricerca esatta dei vicini più prossimi confronta la query con ogni vettore memorizzato, il che è corretto ma scala linearmente con la dimensione del corpus. A 50k vettori è veloce. A milioni è troppo lenta per essere servita.

Gli indici ANN (approssimati) rinunciano a parte dell'accuratezza per cercare una frazione dei vettori memorizzati. La struttura dominante tra questi motori è HNSW, un grafo di prossimità a strati che scende da un punto di ingresso grossolano a un vicinato denso, visitando un numero limitato di candidati stabilito da una manopola di ricerca (ef per HNSW, nprobe per IVF). Un ef più grande visita più candidati, aumentando il recall e riducendo i QPS. Un ef più piccolo fa il contrario.

Poiché quella manopola scambia continuamente recall contro velocità, confrontare due motori a una singola impostazione fissa è fuorviante, perché uno potrebbe spendere più accuratezza per la propria velocità. Il confronto equo spazza la manopola, disegna la curva recall-QPS di ciascun motore e li legge tutti allo stesso recall. Quel punto a parità di recall (qui Recall@10 = 0.95) è dove sono stati rilevati i valori di QPS, latenza e memoria di questo benchmark.

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Metodologia del benchmark

Motori. Qdrant v1.18.1, Milvus v2.6.0, Weaviate 1.38.0, pgvector 0.8.x (Postgres 17), Chroma 1.5.0, Redis/RediSearch 8.2 e LanceDB 0.34.0, con immagini Docker bloccate. Redis è stato eseguito con persistenza disattivata (nessuno snapshot RDB né file append-only).

Hardware. Un Hetzner CCX53 (32 vCPU dedicate, 128 GB di RAM, NVMe, nbg1) per accuratezza, velocità, memoria, filtri e costruzione, un container attivo alla volta, un container nuovo per ogni costruzione dell'indice e un client single-thread co-locato. La dimensione di churn in tempo reale è stata eseguita su un CCX33 (8 vCPU, 32 GB).

Embedding. bge-m3, 1024 dimensioni, coseno su float32 normalizzati L2, k=10, seed 42, identici a livello di byte tra i motori. Le query contengono etichette umane single-positive (target_doc_id).

Corpus. MedRAG-50k (154 query) e TechQA-28k (151 query) per la qualità del recupero, e un corpus di 2.25M vettori (50k etichettati più 2.2M distrattori) per il livello di scala. La dimensione ibrida è stata rieseguita su Docker locale, quindi i suoi QPS sono confrontabili tra le righe ibride, non con i valori del box. I suoi nDCG e Δ sono indipendenti dall'hardware.

Statistiche. 100+ esecuzioni per misura, taglio degli outlier IQR a 3.0x, temporizzazione perf_counter_ns. Pool di query da 154 a 246 limitano il reporting della coda a p95, occasionalmente p99. p99.9 non è definito con questi conteggi.

Doppia verità di riferimento. Un database vettoriale ha due verità di riferimento indipendenti e questo benchmark misura entrambe. La verità geometrica (ANN Recall@10 rispetto all'oracolo esatto a forza bruta sugli stessi vettori) chiede se l'indice ha restituito i veri vettori più vicini, isolando il database. La verità semantica (nDCG@10, MRR, Hit@k rispetto alle etichette umane) chiede se i documenti restituiti sono rilevanti, il che è in gran parte l'embedding, mantenuto costante. Poiché l'embedding è congelato, classificare i motori sui punteggi semantici grezzi classificherebbe l'embedding. La potenza del database si manifesta come velocità e memoria a parità di recall ANN, e il ponte Δ traduce la sua perdita di approssimazione in qualità della risposta.

Ancoraggio di correttezza. Ogni ricetta per motore (filtri e ibridi) è stata tratta dalla documentazione ufficiale alla versione esatta e verificata in modo avversariale prima della codifica. La dimensione ibrida porta con sé una chiave di risposta BM25 indipendente (due riferimenti concordano a nDCG circa 0.81), quindi un motore con un punteggio lontano segnala un bug del harness, non un risultato. Quel controllo ha segnalato tre errori di misura al primo passaggio, tutti nel nostro harness (un artefatto di temporizzazione dell'indice asincrono su Weaviate, una funzione di ranking Postgres errata e un bug di SQL fusion che faceva ignorare a HNSW la sua impostazione ef), che abbiamo corretto rimisurando tutti e sette i motori in un unico ambiente coerente, dove i cinque motori già corretti hanno riprodotto esattamente i loro valori. Le dimensioni di concorrenza e churn portano lo stesso ancoraggio (re-controlli di recall e tombstone), quindi nessun valore riportato è veloce ma errato.

Significatività statistica

Ogni valore riportato è una stima puntuale bootstrap su 100+ esecuzioni, con un intervallo di confidenza al 95% da 1.000 ricampionamenti, e una differenza è considerata reale quando i due intervalli non si sovrappongono.

L'incremento ibrido è il caso limite, quindi i suoi intervalli sono la prova decisiva. Quattro motori superano lo zero e due no:

L'accuratezza del recupero è la stessa regola letta al contrario. Gli nDCG@10 dei sette motori ricadono in intervalli sovrapposti su una forbice di 0.014, quindi nessuno vince, che è ciò che significa il pareggio. Gli ordinamenti di velocità e memoria sono molto al di fuori di tale incertezza, con divari (throughput single-thread 10x, memoria di picco 3.7x) che superano di gran lunga il rumore bootstrap.

Motori testati

Limitazioni

Redis è stato eseguito con persistenza disattivata, quindi una configurazione AOF con fsync cambierebbe la sua latenza di scrittura e l'impronta rispetto ai valori volatili riportati qui.

Le etichette umane sono single-positive (un solo documento corretto per query), senza rilevanza graduata o accordo tra annotatori, quindi nDCG@10, MRR@10 e Hit@10 trasportano un segnale quasi identico su questi dati. L'embedding è mantenuto costante per scelta. Famiglie di embedding, dimensioni e comportamento multilingue sono un benchmark separato. Questa esecuzione isola il livello di recupero. Le fasi di reranking (cross-encoder) e generazione delle risposte con LLM di una pipeline RAG sono fuori ambito. I motori cloud gestiti (Pinecone, Zilliz e altri) sono una fase successiva. Il confronto di durabilità e sicurezza è fondato sulla documentazione, non sottoposto a chaos test.

Ulteriori letture

• Benchmark di modelli di embedding
• Benchmark di reranker
• Calcolatore di database vettoriali
• Modelli di embedding open-source
• Modelli di embedding multilingue
• Embedding multimodali
• Framework RAG agentici

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  = {{Benchmark di database vettoriali: 7 motori open-source per RAG}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/open-source-vector-databases}},
  note   = {AIMultiple. Consultato il 17 Luglio 2026}
}

Registro delle modifiche

3 aggiornamenti

1. 202617 Lug

   Faiss sostituito con LanceDB nell'elenco dei database vettoriali confrontati.

2. 27 Feb

   Aggiunti aggiornamenti recenti a Milvus, Qdrant e Chroma.

3. 202514 Ago

   Aggiunta una nuova sezione, "Caratteristiche chiave dei database vettoriali open source", all'articolo.

Ekrem Sarı

Ricercatore IA

Segui

Ekrem è un Ricercatore IA e Data Scientist presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di IA e LLM.

Visualizza il profilo completo

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.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento