Elasticsearch era fantastico, ma i database vettoriali sono il futuro
Questo post è stato originariamente pubblicato su The New Stack e viene ripubblicato qui con autorizzazione.
Per decenni, il matching delle parole chiave, noto anche come ricerca full-text, esemplificato da Elasticsearch, è stato la scelta predefinita per i sistemi di recupero delle informazioni come la ricerca aziendale e i motori di raccomandazione.
Con l’avanzare delle tecnologie di ricerca basate sull’IA, si assiste a uno spostamento verso la ricerca semantica, che consente ai sistemi di comprendere sia il significato sia l’intento dietro le query degli utenti. I modelli di embedding e i database vettoriali sono diventati centrali in questo cambiamento.
La ricerca semantica supera il matching delle parole chiave rappresentando i dati come embedding vettoriali, offrendo una comprensione più sfumata dell’intento di ricerca e trasformando applicazioni che spaziano dalla generazione aumentata dal recupero (RAG) alla ricerca multimodale.
In pratica, sistemi efficaci di recupero delle informazioni hanno bisogno sia di comprensione semantica sia di matching esatto delle parole chiave. Per esempio, gli utenti si aspettano che i risultati di ricerca mostrino concetti correlati alle loro query di ricerca, rispettando al contempo il testo letterale usato nella query, come termini e nomi speciali, e restituiscano i risultati con corrispondenza esatta.
Una ricerca semantica basata su vettori densi aiuta a comprendere il significato (come sapere che ‘car’ e “automobile” sono la stessa cosa) e la ricerca full-text tradizionale fornisce i risultati precisi che gli utenti si aspettano (come trovare corrispondenze esatte per “Python 3.9”). Di conseguenza, molte organizzazioni stanno adottando un approccio di ricerca ibrida, combinando i punti di forza di entrambi i metodi per bilanciare una rilevanza semantica flessibile con un matching esatto delle parole chiave prevedibile.
La sfida della ricerca ibrida
Un modo comune per implementare la ricerca ibrida è usare un database vettoriale purpose-built come Milvus open source per una ricerca semantica efficiente e scalabile, insieme a motori di ricerca tradizionali come Elasticsearch o OpenSearch per la ricerca full-text.
Sebbene questo approccio possa produrre buoni risultati, introduce anche un nuovo livello di complessità. Gestire due sistemi di ricerca distinti significa occuparsi di infrastrutture, configurazioni e attività di manutenzione separate, creando un carico operativo più pesante e aumentando la probabilità di potenziali problemi di integrazione.
Elasticsearch vs Milvus on Hybrid search
Figura: Elasticsearch vs Milvus sulla ricerca ibrida
Una soluzione unificata per la ricerca ibrida offrirebbe molti vantaggi:
Manutenzione dell’infrastruttura ridotta: Gestire un solo sistema invece di due riduce drasticamente la complessità operativa, facendo risparmiare sia tempo sia risorse. Questo significa anche meno cambi di contesto e meno carico mentale per padroneggiare due diversi insiemi di API.
Gestione dei dati consolidata: Una struttura di tabella unificata consente di archiviare sia dati densi (basati su vettori) sia sparsi (basati su parole chiave) insieme a etichette di metadati condivise. Usare due sistemi separati richiederebbe di archiviare due volte le etichette di metadati affinché entrambe le parti possano eseguire il filtraggio dei metadati.
Query semplificata: Una singola richiesta può eseguire sia attività di ricerca semantica sia full-text, eliminando la necessità di effettuare due chiamate API a sistemi separati.
Sicurezza e controllo degli accessi migliorati: Un approccio unificato consente una gestione della sicurezza più semplice e robusta, poiché tutti i controlli di accesso possono essere amministrati centralmente all’interno di un database vettoriale, migliorando la conformità e la coerenza della sicurezza.
Come un approccio vettoriale unificato semplifica la ricerca ibrida
Nella ricerca semantica, i modelli di machine learning “incorporano” il testo come punti, noti come vettori densi, in uno spazio ad alta dimensionalità in base al suo significato. I testi con semantica simile sono più vicini tra loro in questo spazio. Ad esempio, “mela” e “frutto” potrebbero essere più vicini in questo spazio rispetto a “mela” e “auto.” Questo ci consente di trovare rapidamente testo semanticamente correlato semplicemente calcolando la distanza tra ciascun punto utilizzando algoritmi di nearest neighbor approssimato (ANN).
Questo metodo può essere applicato anche alla ricerca full-text codificando documenti e query come vettori sparsi. Nei vettori sparsi, ogni dimensione rappresenta un termine e il valore indica quanto sia importante ciascun termine nel documento.
I termini non presenti nel documento hanno valore zero. Poiché un determinato documento in genere utilizza solo una piccola parte di tutti i possibili termini del vocabolario, la maggior parte dei termini non apparirà nel documento. Ciò significa che i vettori risultanti sono sparsi — la maggior parte dei loro valori è zero. Ad esempio, nel set di dati MS-MARCO comunemente utilizzato per valutare attività di recupero delle informazioni, sebbene vi siano circa 9 milioni di documenti e un milione di termini univoci, un sistema di ricerca di solito suddivide questa grande raccolta in segmenti più piccoli per una gestione più semplice.
Anche a livello di segmento, con centinaia di migliaia di termini nel suo vocabolario, ciascun documento di solito contiene meno di 100 termini, il che significa che oltre il 99% dei valori di ciascun vettore è zero. Questa estrema sparsità ha importanti implicazioni sul modo in cui archiviamo ed elaboriamo questi vettori in modo efficiente.
Questo schema di sparsità può essere sfruttato per ottimizzare le prestazioni di ricerca mantenendo l’accuratezza. I database vettoriali originariamente progettati per vettori densi possono essere adattati per gestire questi vettori sparsi in modo efficiente. Ad esempio, il database vettoriale open source Milvus ha appena rilasciato il supporto nativo alla ricerca full-text utilizzando Sparse-BM25, un’implementazione a vettori sparsi dell’algoritmo BM25 utilizzato da Elasticsearch e altri sistemi di ricerca full-text. Sparse-BM25 sblocca l’ottimizzazione basata sull’approssimazione per la ricerca full-text con:
Algoritmo di recupero efficiente con pruning dei dati: Applicando un pruning basato su euristiche per scartare i documenti con i valori di vettore sparso più bassi nell’indice del segmento e ignorando i vettori sparsi a basso valore nella query di ricerca, un database vettoriale può ridurre significativamente la dimensione dell’indice e ottimizzare le prestazioni con una perdita di qualità minima.
Sblocco di ulteriori ottimizzazioni delle prestazioni: Rappresentare la frequenza dei termini come un vettore sparso invece che come un indice invertito consente ulteriori ottimizzazioni basate su vettori. Queste includono:
L’indicizzazione a grafo viene utilizzata per una ricerca più efficiente rispetto alle scansioni brute-force.
Product quantization (PQ) / scalar quantization (SQ) per ridurre ulteriormente l’impronta di memoria.
Oltre a queste ottimizzazioni, l’implementazione Sparse-BM25 eredita anche diversi vantaggi a livello di sistema dal database vettoriale ad alte prestazioni Milvus:
Implementazione efficiente a basso livello e gestione della memoria: Il motore principale di indicizzazione vettoriale in Milvus è implementato in C++, offrendo una gestione della memoria più efficiente rispetto a un sistema basato su Java come Elasticsearch. Questo da solo riduce l’impronta di memoria risparmiando gigabyte rispetto a un approccio basato su JVM.
Supporto per MMap: Analogamente all’uso della page-cache da parte di Elasticsearch per l’archiviazione degli indici sia in memoria sia su disco, Milvus supporta il memory mapping (MMap) per estendere la capacità di memoria quando l’indice supera la memoria disponibile.
Perché gli stack di ricerca tradizionali non sono all’altezza della ricerca vettoriale
Elasticsearch è stato creato per gli indici invertiti tradizionali, rendendo fondamentalmente difficile ottimizzare l’intera architettura per la ricerca vettoriale densa. L’impatto è evidente: anche con appena 1 milione di vettori, Elasticsearch impiega 200 millisecondi (come testato su Elastic Cloud completamente gestito) per restituire il risultato di ricerca rispetto ai 6 ms di Milvus (come testato su Zilliz Cloud completamente gestito) — una differenza di prestazioni di oltre 30 volte. Anche il throughput misurato in query al secondo (QPS) presenta una differenza di 3 volte, con l’istanza più performante su Zilliz Cloud che raggiunge 6000 QPS, mentre Elastic Cloud arriva al massimo a 1900 QPS. Inoltre, Zilliz Cloud è 15 volte più veloce di Elastic Cloud nel caricare i dati vettoriali e creare l’indice. Questo divario di prestazioni si amplia su larga scala, dove l’implementazione Java/JVM di Elasticsearch fatica a eguagliare la scalabilità dei database vettoriali basati su C++/Go. Inoltre, Elasticsearch manca di funzionalità critiche per la ricerca vettoriale come gli indici basati su disco (DiskAnn, MMap), il filtraggio ottimizzato dei metadati e la ricerca per intervallo.
VectorDBBench Benchmarking Results.jpg
Figura: Risultati del benchmark VectorDBBench (fonte)
Conclusione
I database vettoriali, esemplificati da Milvus, sono destinati a superare Elasticsearch come soluzione unificata per la ricerca ibrida. Integrando la ricerca vettoriale densa con tecniche ottimizzate per vettori sparsi, i database vettoriali offrono prestazioni, scalabilità ed efficienza superiori. Questo approccio unificato semplifica l’infrastruttura, riduce l’impronta di memoria e potenzia le capacità di ricerca, rendendolo il futuro delle esigenze di ricerca avanzata. Di conseguenza, i database vettoriali forniscono una soluzione completa che combina senza soluzione di continuità ricerca semantica e full-text, superando i sistemi di ricerca tradizionali come Elasticsearch.
Continua a leggere
Zilliz Cloud Delivers Better Performance and Lower Costs with Arm Neoverse-based AWS Graviton
Zilliz Cloud adopts Arm-based AWS Graviton3 CPUs to cut costs, speed up AI vector search, and power billion-scale RAG and semantic search workloads.
Build for the Boom: Why AI Agent Startups Should Build Scalable Infrastructure Early
Explore strategies for developing AI agents that can handle rapid growth. Don't let inadequate systems undermine your success during critical breakthrough moments.
How to Build RAG with Milvus, QwQ-32B and Ollama
Hands-on tutorial on how to create a streamlined, powerful RAG pipeline that balances efficiency, accuracy, and scalability using the QwQ-32B and Milvus.