Elasticsearch è morto, lunga vita alla ricerca lessicale

Ormai tutti sanno che la ricerca ibrida ha migliorato la qualità della ricerca RAG (Retrieval-Augmented Generation). Sebbene la ricerca con incorporazione densa abbia mostrato capacità impressionanti nel catturare relazioni semantiche profonde tra query e documenti, ha ancora notevoli limiti. Tra questi, la mancanza di spiegabilità e le prestazioni non ottimali con query a coda lunga e termini rari.

Molte applicazioni RAG sono in difficoltà perché i modelli pre-addestrati spesso mancano di conoscenze specifiche del dominio. In alcuni scenari, la semplice corrispondenza delle parole chiave BM25 supera questi modelli sofisticati. È qui che la ricerca ibrida colma il divario, combinando la comprensione semantica del recupero vettoriale denso con la precisione della corrispondenza delle parole chiave.

Perché la ricerca ibrida è complessa in produzione

Sebbene framework come LangChain o LlamaIndex rendano semplice la realizzazione di un proof-of-concept di retriever ibrido, la scalabilità alla produzione con enormi insiemi di dati è impegnativa. Le architetture tradizionali richiedono database vettoriali e motori di ricerca separati, il che comporta diverse sfide fondamentali:

• Elevati costi di manutenzione dell'infrastruttura e complessità operativa

• Ridondanza dei dati su più sistemi

• Difficile gestione della coerenza dei dati

• Sicurezza e controllo degli accessi complessi tra i sistemi

Il mercato ha bisogno di una soluzione unificata che supporti la ricerca lessicale e semantica, riducendo al contempo la complessità e i costi del sistema.

I punti dolenti di Elasticsearch

Elasticsearch è stato uno dei progetti di ricerca open-source più influenti dell'ultimo decennio. Basato su Apache Lucene, ha guadagnato popolarità grazie alle sue elevate prestazioni, alla scalabilità e all'architettura distribuita. Sebbene abbia aggiunto la ricerca vettoriale RNA nella versione 8.0, le implementazioni di produzione devono affrontare diverse sfide critiche:

Alti costi di aggiornamento e indicizzazione: L'architettura di Elasticsearch non disaccoppia completamente le operazioni di scrittura, creazione di indici e interrogazione. Ciò comporta un notevole sovraccarico di CPU e I/O durante le operazioni di scrittura, soprattutto negli aggiornamenti in blocco. La contesa di risorse tra indicizzazione e interrogazione influisce sulle prestazioni, creando un importante collo di bottiglia per gli scenari di aggiornamento ad alta frequenza.

Scarse prestazioni in tempo reale: Essendo un motore di ricerca "quasi in tempo reale", Elasticsearch introduce una notevole latenza nella visibilità dei dati. Questa latenza diventa particolarmente problematica per le applicazioni di intelligenza artificiale, come i sistemi ad agenti, dove le interazioni ad alta frequenza e il processo decisionale dinamico richiedono un accesso immediato ai dati.

Difficile gestione degli shard: Sebbene Elasticsearch utilizzi lo sharding per l'architettura distribuita, la gestione degli shard pone problemi significativi. La mancanza di un supporto dinamico per lo sharding crea un dilemma: un numero eccessivo di shard in dataset di piccole dimensioni porta a prestazioni scarse, mentre un numero insufficiente di shard in dataset di grandi dimensioni limita la scalabilità e causa una distribuzione non uniforme dei dati.

Architettura non cloud-native: Sviluppato prima che le architetture cloud-native diventassero prevalenti, il design di Elasticsearch associa strettamente storage e calcolo, limitando la sua integrazione con infrastrutture moderne come cloud pubblici e Kubernetes. La scalabilità delle risorse richiede un aumento simultaneo dello storage e dell'elaborazione, riducendo la flessibilità. In scenari multireplica, ogni shard deve costruire il proprio indice in modo indipendente, aumentando i costi di calcolo e riducendo l'efficienza delle risorse.

Scarse prestazioni della ricerca vettoriale: Sebbene Elasticsearch 8.0 abbia introdotto la ricerca vettoriale ANN, le sue prestazioni sono significativamente inferiori a quelle di motori vettoriali dedicati come Milvus. Basata sul kernel Lucene, la sua struttura di indici si rivela inefficiente per i dati ad alta dimensionalità, e fatica a soddisfare i requisiti di ricerca vettoriale su larga scala. Le prestazioni diventano particolarmente instabili in scenari complessi che coinvolgono il filtraggio scalare e la multi-tenancy, rendendo difficile il supporto di un carico elevato o di esigenze aziendali diverse.

Consumo eccessivo di risorse: Elasticsearch richiede un consumo estremo di memoria e CPU, soprattutto quando si elaborano dati su larga scala. La sua dipendenza dalla JVM richiede frequenti aggiustamenti delle dimensioni dell'heap e la regolazione della garbage collection, con un grave impatto sull'efficienza della memoria. Le operazioni di ricerca vettoriale richiedono calcoli intensivi ottimizzati per SIMD, per i quali l'ambiente JVM è tutt'altro che ideale.

Questi limiti fondamentali diventano sempre più problematici man mano che le organizzazioni scalano la loro infrastruttura di IA, rendendo Elasticsearch particolarmente impegnativo per le moderne applicazioni di IA che richiedono prestazioni e affidabilità elevate.

Introduzione di Sparse-BM25: ripensare la ricerca lessicale

Milvus 2.5 introduce il supporto nativo per la ricerca lessicale attraverso Sparse-BM25, basandosi sulle capacità di ricerca ibrida introdotte nella versione 2.4. Questo approccio innovativo comprende i seguenti componenti chiave:

• tokenizzazione avanzata e pre-elaborazione tramite Tantivy

• Gestione distribuita del vocabolario e della frequenza dei termini

• Generazione di vettori sparsi utilizzando TF del corpus e TF-IDF della query

• Supporto di indici invertiti con algoritmo WAND (Block-Max WAND e supporto di indici a grafo in fase di sviluppo).

Rispetto a Elasticsearch, Milvus offre notevoli vantaggi in termini di flessibilità degli algoritmi. Il calcolo della somiglianza basato sulla distanza vettoriale consente di effettuare corrispondenze più sofisticate, compresa l'implementazione del TW-BERT (Term Weighting BERT) basato sulla ricerca "End-to-End Query Term Weighting". Questo approccio ha dimostrato prestazioni superiori sia nei test in-domain che out-domain.

Un altro vantaggio fondamentale è l'efficienza dei costi. Sfruttando sia l'indice invertito che la compressione densa dell'embedding, Milvus ottiene un miglioramento delle prestazioni di cinque volte con un degrado del richiamo inferiore all'1%. Grazie alla potatura dei termini di coda e alla quantizzazione dei vettori, l'utilizzo della memoria è stato ridotto di oltre il 50%.

L'ottimizzazione delle query lunghe è un punto di forza particolare. Laddove gli algoritmi WAND tradizionali faticano a gestire le interrogazioni più lunghe, Milvus eccelle combinando le incorporazioni rade con gli indici di grafo, ottenendo un miglioramento delle prestazioni di dieci volte negli scenari di ricerca vettoriale rada ad alta dimensionalità.

Milvus: il database vettoriale definitivo per RAG

Milvus è la scelta principale per le applicazioni RAG grazie al suo set completo di funzionalità. I vantaggi principali includono:

• Ricco supporto di metadati con funzionalità di schema dinamico e potenti opzioni di filtraggio.

• Multi-tenancy di livello aziendale con isolamento flessibile attraverso collezioni, partizioni e chiavi di partizione

• Supporto degli indici vettoriali su disco, primo nel settore, con archiviazione multilivello dalla memoria a S3.

• Scalabilità cloud-native che supporta la scalabilità senza soluzione di continuità da 10M a 1B+ di vettori

• Funzionalità di ricerca complete, tra cui raggruppamento, intervallo e ricerca ibrida

• Profonda integrazione dell'ecosistema con LangChain, LlamaIndex, Dify e altri strumenti di intelligenza artificiale.

Le diverse capacità di ricerca del sistema comprendono metodologie di raggruppamento, intervallo e ricerca ibrida. La profonda integrazione con strumenti come LangChain, LlamaIndex e Dify, oltre al supporto per numerosi prodotti di AI, pone Milvus al centro del moderno ecosistema di infrastrutture di AI.

Uno sguardo al futuro

Mentre l'IA passa dal POC alla produzione, Milvus continua a evolversi. Ci concentriamo sul rendere la ricerca vettoriale più accessibile e conveniente, migliorando al contempo la qualità della ricerca. Che si tratti di una startup o di un'impresa, Milvus riduce le barriere tecniche allo sviluppo di applicazioni di IA.

Questo impegno per l'accessibilità e l'innovazione ci ha portato a un altro importante passo avanti. Mentre la nostra soluzione open-source continua a servire da base per migliaia di applicazioni in tutto il mondo, riconosciamo che molte organizzazioni hanno bisogno di una soluzione completamente gestita che elimini i costi operativi.

Zilliz Cloud: La soluzione gestita

Negli ultimi tre anni abbiamo costruito Zilliz Cloud, un servizio di database vettoriale completamente gestito basato su Milvus. Grazie a una reimplementazione cloud-native del protocollo Milvus, offre una maggiore usabilità, efficienza dei costi e sicurezza.

Grazie alla nostra esperienza nella gestione dei più grandi cluster di ricerca vettoriale al mondo e nel supporto a migliaia di sviluppatori di applicazioni di intelligenza artificiale, Zilliz Cloud riduce significativamente i costi e le spese operative rispetto alle soluzioni self-hosted.

Siete pronti a sperimentare il futuro della ricerca vettoriale? Iniziate oggi stesso la vostra prova gratuita con un credito fino a 200 dollari, senza bisogno di carta di credito.