Benchmark di Database Vettoriali: 7 Motori Open-Source per RAG

Abbiamo sottoposto a benchmark sette database vettoriali open-source e self-hosted come livello di recupero di una pipeline RAG, ciascuno eseguito singolarmente sugli stessi embedding bge-m3 e su query mediche e tecniche reali, in modo 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 di vettori attraverso otto dimensioni, dall'accuratezza e qualità del recupero fino a velocità, memoria, ricerca filtrata e ibrida, costo di costruzione e turnover 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 numeri di velocità.

Su un singolo thread client, Redis serve 764 QPS su MedRAG-50k con 559 MB di picco RAM, 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 dal primo all'ultimo. LanceDB è l'eccezione su disco, che scambia RAM con latenza a un p95 vicino a 22 ms. Redis rimane il più veloce e LanceDB il più lento su TechQA-28k (da 651 a 81) e a 2.25M (da 495 a 28), anche se la parte centrale si ridistribuisce su larga scala, dove Milvus scende dal terzo al sesto posto.

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

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

Throughput in regime di concorrenza

I QPS single-thread rispondono a quanto è veloce una singola query. La domanda in 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 pilotato in due modi, entrambi comuni nelle app Python RAG. Un singolo processo asincrono o threaded 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) ottengono ciascuno il proprio GIL, esponendo molta più capacità del server. Abbiamo misurato entrambi su una macchina con 32 vCPU a ef=128 fisso, e verificato la recall in ogni punto.

Man mano che la concorrenza delle richieste sale da 1 a 512 su un massimo di 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 a un plateau di 8330 QPS a 512 richieste, passando per 7.114 lungo il percorso a 32. Su un singolo processo asincrono la classifica invece segue l'efficienza di parsing del client Python, poiché 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 rappresentano i massimi lungo l'intera scansione da 1 a 512, non il throughput a un singolo conteggio di richieste.

Redis detiene la latenza per singola query più bassa del gruppo (circa 1,6 ms), e il suo nucleo di ricerca single-threaded satura intorno a 1642 QPS a 32 richieste concorrenti, per poi scalare negativamente oltre (il pool di thread di query WORKERS di RediSearch è disattivato per impostazione predefinita). Weaviate e Milvus (server multi-threaded) 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 di p99 inferiore a 100 ms 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 sposta 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 scala negativamente, con un p99 di 13 secondi a 512 richieste, e LanceDB è embedded, quindi lo scenario 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 rimane il più snello perché scarica l'indice su disco (stile DiskANN) mentre i motori HNSW completamente in-RAM crescono più velocemente, quindi 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 su disco sono esclusi da questo confronto di RAM perché la loro impronta è su disco piuttosto che in RAM. pgvector mantiene un indice su disco 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. Si tratta di un picco build-and-serve, non di un'impronta di solo serving, quindi una nuova misurazione in modalità solo serving è un affinamento ancora aperto.

Freschezza, scritture ed eliminazioni in regime di turnover in tempo reale

Le altre sette dimensioni misurano un corpus statico con caricamento bulk e poi lettura. Le basi di conoscenza RAG reali aggiungono, aggiornano ed eliminano documenti in modo continuo mentre l'indice esegue merge in background. Questo carico di lavoro di turnover è stato eseguito su MedRAG-50k su una macchina separata con 8 vCPU, quindi il suo throughput è interno a questa sezione e non confrontabile con i numeri 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 ciascun motore è stato configurato, ognuno è read-after-write. Un documento appena scritto è immediatamente ricercabile, con zero scritture su circa 150 non visibili. 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 attraverso una scansione a consistenza forte del segmento in crescita non ancora sigillato (il vettore entra successivamente nel grafo HNSW persistente), quindi i suoi 12 ms rappresentano la ricercabilità del segmento in crescita, un read-after-write valido dal punto di vista dell'utente.

Scritture e letture sotto carico misto. Con uno scrittore che punta a 150 scritture/s e sei lettori che interrogano per 60 secondi, la recall in lettura si è mantenuta tra 0,96 e 1,00 per ogni motore, e nessun indice si è degradato sotto scritture concorrenti. Il throughput di scrittura per singola riga 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, motivo per cui i costruttori statici più veloci sono i più lenti in regime di turnover. Il throughput di scrittura qui è il tasso raggiunto contro un obiettivo di 150/s sotto letture concorrenti, quindi i motori veloci sono limitati vicino a 150 anziché mostrare il loro picco. Si legga questo come comportamento di scrittura online a singola riga e ad alta frequenza, non come ingestione batch, che è il punto di progettazione di questi motori e non è testata qui.

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

Weaviate ha eseguito questa sezione con 3.000 documenti iniziali anziché 30.000 (la sua ingestione bulk sincrona è lenta sulla macchina piccola), quindi i suoi QPS in lettura sono su 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à classifica.

Metriche spiegate

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

nDCG@10 è un punteggio da 0 a 1 ponderato per posizione che misura se il documento corretto etichettato manualmente atterra 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 per ogni motore.

Δ (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, riportabile perché disponiamo sia di un oracolo che di etichette umane.

Risultati del benchmark dei database vettoriali

I sette motori pareggiano 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 delta bridge verso l'oracolo va da 0,009 (LanceDB) a 0,023 (pgvector), quindi l'approssimazione del database costa al massimo 0,023 punti nDCG di qualità della risposta.

Con questo embedding, corpus, k=10 e punto operativo 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, a k più grandi, a corpora molto più grandi o con indici quantizzati.

L'affidabilità del recupero varia più in base a ciò che una query chiede che a quale database risponde. Sulle 154 query MedRAG presso l'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 ricerche factoid e di esistenza di clausole è presente in modo identico su 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 rimane 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 la recall con un throughput filtrato da 20 a 40x inferiore rispetto agli altri. Milvus mantiene la recall più alta nel caso peggiore (0,984) con da 268 a 732 QPS attraverso la selettività, mentre Redis è il più veloce a bassa selettività (1.374 QPS al 1%) con un pavimento di recall più basso (0,968). A selettività 1-5%, una recall di 1,00 è in gran parte il ramo di scansione completa esatta del query planner al di sotto della soglia di scansione completa di ciascun motore, non HNSW filtrabile, dichiarato per ogni motore.

*La recall filtrata di LanceDB è stata inizialmente misurata a 0,24 su filtri raggruppati, poi ritirata. La scansione ha variato ef, ma la manopola di recall di LanceDB è nprobes, quindi è stato eseguito a un valore predefinito di circa il 9% delle partizioni. Rimisurata con nprobes appropriati, Recall@10 raggruppato recupera da 0,24 a 0,76 (nprobes=128) fino a circa 1,00 (nprobes=256), con QPS da 3 a 5x inferiori. LanceDB mantiene la recall filtrata, lentamente. Una rimisurazione del throughput filtrato a recall corrispondente sullo stesso host è ancora in sospeso, quindi i QPS filtrati di LanceDB non sono elencati.

La ricerca ibrida aggiunge fino a 0,067 nDCG

Aggiungere un braccio standard di keyword BM25 e fonderlo con il braccio denso tramite fusion a rango reciproco (RRF, k=60) aumenta nDCG@10 da 0,030 a 0,067 per ogni motore dotato di braccio keyword. Su MedRAG i bracci denso e BM25 sono di forza quasi uguale individualmente (circa 0,80 ciascuno), quindi l'aumento recupera gli errori di ciascun braccio anziché un braccio dominare.

I motori con un braccio BM25 forte guadagnano di più, e pgvector e Weaviate guadagnano meno, coerentemente con i loro bracci keyword più deboli (0,740 e 0,782). Nessun motore ibrido scende al di sotto del proprio braccio denso una volta misurato correttamente.

Ciò che separa i motori è la fusion nativa rispetto ai round-trip lato client, da Milvus a 340 QPS nativi 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 è ts_rank di Postgres (frequenza dei termini con normalizzazione della lunghezza, senza IDF), che con una scansione full-text OR funziona a 12 QPS. Chroma self-hosted non ha alcuna ricerca keyword classificata (BM25 è una funzionalità di Chroma Cloud), quindi non ha una riga ibrida.

Il tempo di costruzione dell'indice ha una forbice di 13x

A 50k vettori, la costruzione dell'indice va da 7 secondi (LanceDB) e da 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 della macchina, il costo di costruzione va da €0,04 per 1M di 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 di vettori

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

La recall ANN geometrica regge su larga 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 della risposta 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 di distrattori.

Il crollo non è un effetto del database. Colpisce l'oracolo kNN esatto in modo identico (nDCG@10 dell'oracolo a 2.25M è 0,572, e ogni motore si attesta su quel soffitto intorno a 0,55-0,57). Se la causa sia il limite dell'embedding, l'ambiguità del corpus o etichette a singolo positivo che non colgono quasi-duplicati ora rilevanti non viene stabilito qui. Separare queste cause richiede una ri-etichettatura umana dei documenti recentemente promossi in classifica. Il fatto riportabile è che scalare il corpus di 45x ha cancellato circa un terzo della qualità della risposta (nDCG@10 da 0,81 a 0,56) mentre ogni indice ANN continuava a riportare una recall quasi perfetta, un effetto che un benchmark puramente geometrico non avrebbe rilevato.

Durabilità, HA e sicurezza per motore

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

Tra i sette, solo pgvector offre il recupero point-in-time (tramite archiviazione WAL di Postgres) e la sicurezza a livello di riga. Qdrant, Milvus e Weaviate forniscono 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 standalone misurata qui. Nessuno dei sette crittografa nativamente i dati su disco. 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 embedded lo demandano all'applicazione. Un pre-filtro corretto restituisce meno risultati, un rischio di completezza, anziché far trapelare i documenti di un altro tenant. Una fuga cross-tenant richiederebbe un post-filtro difettoso, che nessuno di questi motori ha utilizzato.

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 secondo una metrica di distanza (qui coseno su vettori L2-normalizzati). 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 lento per servire.

Gli indici approssimati dei vicini più prossimi (ANN) sacrificano un po' di accuratezza per cercare solo una frazione dei vettori memorizzati. La struttura dominante in questi motori è HNSW, un grafo di prossimità a strati che cammina da un punto di ingresso grossolano fino 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 la recall e riducendo i QPS. Un ef più piccolo fa l'opposto.

Poiché quella manopola scambia recall contro velocità in modo continuo, confrontare due motori a un'impostazione fissa è fuorviante, poiché uno potrebbe spendere più accuratezza per la propria velocità. Il confronto equo scansiona la manopola, disegna la curva recall-contro-QPS di ciascun motore e li legge tutti alla stessa recall. Quel punto a recall corrispondente (Recall@10 = 0,95 qui) è dove vengono presi i numeri di QPS, latenza e memoria in 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 fissate. Redis è stato eseguito con persistenza disattivata (nessuno snapshot RDB o file append-only).

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

Embedding. bge-m3, 1024-dim, coseno su float32 L2-normalizzati, k=10, seed 42, byte-identici tra i motori. Le query portano etichette umane a singolo positivo (target_doc_id).

Corpora. MedRAG-50k (154 query) e TechQA-28k (151 query) per la qualità del recupero, e un corpus di 2.25M di vettori (50k etichettati più 2.2M di 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 numeri della macchina. I suoi nDCG e Δ sono indipendenti dall'hardware.

Statistiche. 100+ esecuzioni per misurazione, trim degli outlier IQR a 3,0x, temporizzazione perf_counter_ns. I pool di query da 154 a 246 limitano il reporting della coda a p95, occasionalmente p99. p99.9 non è definito a questi conteggi.

Doppia verità di riferimento. Un database vettoriale ha due verità di riferimento indipendenti, e questo benchmark le valuta entrambe. La verità di riferimento geometrica (ANN Recall@10 contro l'oracolo esatto a forza bruta sugli stessi vettori) chiede se l'indice ha restituito i veri vettori più vicini, isolando il database. La verità di riferimento semantica (nDCG@10, MRR, Hit@k contro 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 recall ANN corrispondente, e il Δ bridge traduce la sua perdita di approssimazione in qualità della risposta.

Ancora di correttezza. Ogni ricetta per motore (filtro e ibrido) è stata tratta dai documenti ufficiali alla versione esatta e verificata in modo avversariale prima della codifica. La dimensione ibrida porta una chiave di risposta BM25 indipendente (due riferimenti concordano a nDCG circa 0,81), quindi qualsiasi motore che si discosti molto segnala un bug del harness, non un risultato. Quel controllo ha segnalato tre errori di misurazione al primo passaggio, tutti nel nostro harness (un artefatto di temporizzazione dell'indice asincrono su Weaviate, una funzione di ranking Postgres sbagliata e un bug di fusion SQL che faceva sì che HNSW ignorasse 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 numeri. Le dimensioni di concorrenza e turnover portano la stessa ancora (ricontrolli di recall e tombstone), quindi nessun numero riportato è veloce-ma-sbagliato.

Significatività statistica

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

L'aumento 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, ed è ciò che significa il pareggio. Gli ordinamenti di velocità e memoria si collocano ben al di fuori di quell'incertezza, con divari (10x throughput single-thread, 3,7x memoria di picco) che schiacciano il rumore del bootstrap.

Motori testati

Limitazioni

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

Le etichette umane sono a singolo positivo (un documento corretto per query), senza rilevanza graduata o accordo inter-annotatore, quindi nDCG@10, MRR@10 e Hit@10 portano un segnale quasi identico su questi dati. L'embedding è mantenuto costante per progettazione. Le famiglie di embedding, le dimensioni e il comportamento multilingue costituiscono un benchmark separato. Questa esecuzione isola il livello di recupero. Le fasi di reranking (cross-encoder) e generazione della risposta tramite LLM di una pipeline RAG sono fuori dallo scopo. I motori cloud gestiti (Pinecone, Zilliz e altri) sono una fase successiva. Il confronto di durabilità e sicurezza è basato sulla documentazione, non testato con chaos engineering.

Ulteriori letture

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

Cita questa ricerca

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}
}

Ekrem Sarı

Ricercatore di intelligenza artificiale

Segui

Ekrem è un ricercatore di intelligenza artificiale presso AIMultiple, specializzato in automazione intelligente, GPU, agenti di intelligenza artificiale e framework RAG.

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