Come Zilliz ha visto il futuro dei database vettoriali e lo ha costruito per la produzione
Questo post è un riepilogo del podcast con Innovator Coffee e James Luan, VP of Engineering di Zilliz.
Prima che l'IA generativa diventasse mainstream, i database vettoriali venivano raramente discussi di per sé. La maggior parte dell'attenzione era ancora rivolta ai database relazionali, ai motori di ricerca o ai framework per big data. La ricerca vettoriale, se mai veniva menzionata, di solito restava confinata negli articoli di ricerca o all'interno di librerie di algoritmi, non nelle conversazioni sui sistemi di produzione.
Ma i database vettoriali non sono spuntati dal nulla. Sono nati da un cambiamento più profondo nel modo in cui i dati vengono creati e utilizzati. Intorno al 2017–2018, i team di Zilliz hanno iniziato a vedere emergere lo stesso problema: le aziende volevano lavorare con molti più dati non strutturati—testo, immagini, audio, log, comportamento degli utenti—ma i loro strumenti esistenti non erano progettati per questo. I database tradizionali e la ricerca per parole chiave potevano archiviare questi dati, ma non erano bravi a comprenderli. Gestivano bene le corrispondenze esatte. Significato e similarità erano un'altra storia.
I vettori offrivano un modo pratico per colmare questo divario. Trasformando testo, immagini e altri contenuti in embedding, la similarità diventava qualcosa che i sistemi potevano calcolare direttamente. Una volta che i dati venivano rappresentati in questo modo, i database non si limitavano più ad archiviare record. Potevano recuperare informazioni in base al significato, non solo alle parole chiave.
Pertanto, i database vettoriali si collocano tra modelli potenti e dati reali disordinati, rendendo le informazioni non strutturate ricercabili, confrontabili e utilizzabili su larga scala.
Quindi, come ha fatto la ricerca vettoriale a passare dalla ricerca alla produzione, e dove sono diretti ora i database vettoriali? In un recente episodio del podcast in lingua inglese Innovator Coffee, James Luan, VP of Engineering di Zilliz, ha condiviso il suo punto di vista, attingendo alla storia della fondazione dell'azienda, al pensiero dietro Milvus, il database vettoriale open-source di Zilliz, e ai principi di progettazione che hanno plasmato il sistema.
Dagli algoritmi alla produzione: l'evoluzione dei database vettoriali
Ripensando ai primi tempi, prima che la ricerca vettoriale fosse pronta per la produzione, James Luan osserva che la maggior parte dei primi progressi è avvenuta all'interno delle grandi aziende tecnologiche. Progetti come FAISS di Meta hanno posto le basi tecniche, ma erano librerie, non database. Sistemi simili di ricerca vettoriale esistevano in aziende come Microsoft e Spotify, in genere creati per uso interno e adattati a carichi di lavoro specifici. Questi strumenti erano efficaci, ma non erano mai stati progettati per funzionare come sistemi generici e duraturi.
Il punto di svolta è arrivato quando la ricerca vettoriale è passata dalla ricerca a prodotti reali. Una volta che i team hanno provato a distribuirla in produzione, le sfide a livello di sistema sono diventate impossibili da ignorare. Scalabilità, affidabilità e operazioni quotidiane contavano tanto quanto la qualità della ricerca. Sono emersi percorsi diversi. Alcuni team hanno costruito servizi gestiti ottimizzati per l'inferenza online e una stretta integrazione con i modelli linguistici di grandi dimensioni. Altri hanno adottato un approccio infrastrutturale più ampio, integrando la ricerca vettoriale con data lake e database tradizionali per supportare casi d'uso su scala enterprise. Secondo James, questa divergenza è una fase naturale nell'emergere di qualsiasi nuovo livello infrastrutturale.
Con la maturazione dei modelli linguistici di grandi dimensioni e l'arrivo delle applicazioni in produzione, il ruolo dei database vettoriali si è ampliato rapidamente. I primi casi d'uso si concentravano sul recupero basato sulla similarità: sistemi di raccomandazione, ricerca di immagini e abbinamento di contenuti. Negli ultimi due o tre anni, la Retrieval-Augmented Generation (RAG) è diventata il pattern dominante. Nei sistemi RAG, i database vettoriali forniscono ai modelli un contesto pertinente e fondato, consentendo il recupero di fatti e contribuendo a ridurre le allucinazioni.
Quel ruolo diventa ancora più importante nei sistemi basati su agenti. Qui, i database vettoriali agiscono come memoria a lungo termine o quasi in linea, supportando il ragionamento multi-step, la compressione del contesto e il recupero multimodale. James riassume questo cambiamento con un principio semplice: meno struttura, più intelligenza. Man mano che le capacità dei modelli migliorano, pipeline rigide e una pesante etichettatura iniziale possono frenare i sistemi. Gli agenti funzionano meglio quando operano in uno spazio semantico flessibile e decidono dinamicamente come recuperare e combinare le informazioni.
Allo stesso tempo, James sottolinea che i database vettoriali non sono magia. La qualità del recupero dipende tanto dalla governance dei dati quanto dagli algoritmi. Dati ben curati e rilevanti per il dominio—insieme a una valutazione continua—sono essenziali. I modelli di embedding, i reranker e le strategie di recupero evolvono rapidamente, e i team che lasciano passare troppo tempo senza rivalutare il proprio stack spesso restano indietro.
Guardando oltre l’inferenza, James vede i database vettoriali svolgere un ruolo crescente nell’addestramento e nella preparazione dei dati. Con la crescente diffusione dei modelli multimodali, la ricerca vettoriale viene usata sempre più spesso per pulire, deduplicare e curare grandi dataset che comprendono testo, immagini, video e PDF. Nel tempo, questo potrebbe convergere con i data lake in un’architettura “vector lake”, collegando l’elaborazione batch dei dati con l’inferenza online.
In questa visione di più lungo periodo, i database vettoriali non sono più soltanto motori di recupero. Diventano un livello semantico che attraversa addestramento, inferenza e governance dei dati a lungo termine—supportando l’intero ciclo di vita dei sistemi di IA.
Come Zilliz ha trovato la sua direzione prima che i database vettoriali diventassero mainstream
James descrive i primi giorni di Zilliz come un periodo di esplorazione piuttosto che di chiarezza immediata. Sia lui sia il CEO dell’azienda provenivano da contesti di database tradizionali, avendo trascorso anni a costruire sistemi transazionali presso Oracle. Fin dall’inizio, sapevano di non voler costruire un altro database convenzionale—ma quale dovesse essere quell’alternativa era ancora una questione aperta.
Il loro primo tentativo fu un database accelerato da GPU, pensato per velocizzare l’elaborazione dei dati su larga scala tramite hardware specializzato. Tecnicamente, funzionava. Commercialmente, no. Le GPU offrivano prestazioni elevate, ma erano costose, e per la maggior parte dei carichi di lavoro reali il compromesso costo–prestazioni era difficile da giustificare. Allo stesso tempo, sistemi basati su CPU come ClickHouse stavano migliorando rapidamente, colmando gran parte del divario prestazionale a una frazione del costo.
Quell’esperienza impose un ripensamento più profondo. Invece di chiedersi come rendere i database più veloci, il team iniziò a porsi una domanda diversa: quali tipi di dati erano ancora serviti male? I carichi di lavoro analitici e transazionali tradizionali disponevano già di soluzioni mature. A emergere era il dato non strutturato—testo, immagini e altri contenuti che gli utenti volevano sempre più cercare e comprendere, non solo archiviare.
Il punto di svolta arrivò grazie al feedback degli utenti. Alcuni dei primi utenti chiesero se il sistema potesse essere usato per accelerare la ricerca di immagini. Quella domanda indicava un’opportunità più ampia: la similarità semantica su larga scala, resa possibile dalle rappresentazioni vettoriali. Il team capì che i vettori—non le GPU—erano l’astrazione più fondamentale. Da quell’intuizione nacque Milvus come progetto open-source focalizzato sulla ricerca vettoriale su larga scala.
James sottolinea che questo pivot non fu guidato dall’hype. All’epoca, i “database vettoriali” non erano una categoria riconosciuta, e persino il termine stesso non aveva una definizione chiara. A guidare la decisione fu una convinzione radicata nei fondamenti dei database: se la ricerca semantica sarebbe diventata importante, avrebbe finito per richiedere le stesse qualità di qualsiasi sistema dati critico—scalabilità, stabilità e affidabilità.
Quella scelta definì la direzione di tutto ciò che seguì. Impegnandosi presto sui vettori come dati di prima classe e sui database come sistemi di lunga durata, Zilliz si posizionò in anticipo rispetto allo spostamento del settore verso applicazioni guidate dall’IA—ben prima che tale cambiamento diventasse ampiamente visibile.
Man mano che i modelli sono poi passati dalla ricerca alla produzione, i database vettoriali sono diventati una componente centrale delle architetture AI aziendali, supportando pipeline RAG, sistemi agentici, retrieval multimodale e deduplicazione dei dati di training su larga scala. Con questa espansione sono arrivate nuove aspettative. La sola velocità non era più sufficiente. Accuratezza, scalabilità, efficienza dei costi, governance dei dati e sicurezza sono diventate tutte priorità di primo ordine.
La conclusione di James è che costruire sistemi in grado di bilanciare queste esigenze non è un problema di ottimizzazione a breve termine. Richiede pazienza, investimenti ingegneristici continui e un impegno di lungo periodo nei fondamentali dell’infrastruttura—ben oltre l’entusiasmo iniziale per una nuova categoria.
Sfide tecniche e soluzioni: eseguire database vettoriali in produzione
Man mano che i database vettoriali sono entrati in veri sistemi AI di produzione, James sostiene che il successo ha smesso di riguardare le pure prestazioni. Nelle prime implementazioni, la velocità contava più di ogni altra cosa. Ma con l’ingresso in scena dei grandi modelli linguistici, la vera sfida è diventata costruire sistemi che potessero scalare in modo sostenibile—bilanciando contemporaneamente costi, accuratezza, affidabilità e requisiti aziendali.
Costi: andare oltre la ricerca solo in memoria
James sottolinea che i primi sistemi di ricerca vettoriale si basavano fortemente su indici in memoria. Questo approccio funzionava quando i dataset erano piccoli, ma è diventato economicamente insostenibile quando le applicazioni guidate da LLM hanno spinto i volumi di dati molto più in alto. A quella scala, ridurre la latenza di pochi millisecondi conta molto meno che controllare i costi di storage.
La soluzione è un approccio a livelli per storage e indicizzazione. Combinando indici in memoria, basati su disco e su object-storage, i database vettoriali possono ridurre i costi di storage fino a 100 volte. Questo cambiamento non si limita a ottimizzare i carichi di lavoro esistenti: rende innanzitutto pratico il retrieval su larga scala.
Scalabilità e stabilità su scala reale
Le pressioni sui costi espongono rapidamente i limiti di scalabilità. James osserva che molti team iniziano con configurazioni semplici, a nodo singolo, perché sono facili da distribuire. I problemi emergono più tardi, quando i dati crescono di 10, 50 o persino 100 volte in poco tempo.
Questa realtà ha portato Zilliz a ricostruire Milvus come sistema distribuito e cloud-native. Per James, la scalabilità è inseparabile dalla stabilità. Un sistema che può scalare ma fallisce in modo imprevedibile sotto carichi di lavoro reali non è un’infrastruttura utilizzabile.
Sottolinea che la stabilità è spesso la parte più difficile del trasformare la ricerca vettoriale in un sistema di produzione. Con gli strumenti open-source esistenti, molti team possono costruire un prototipo funzionante in sei-dodici mesi. Ciò che è difficile è fare in modo che quel sistema si comporti in modo affidabile per lunghi periodi di tempo mentre cambiano volume dei dati, pattern di query e complessità operativa.
A differenza dell’ottimizzazione delle prestazioni, la stabilità non deriva da una singola svolta. I miglioramenti delle prestazioni sono visibili: i benchmark possono mostrare un miglioramento del 20% o 30% in pochi mesi. La stabilità si costruisce diversamente. Ogni correzione può migliorare lo SLA solo di una frazione di punto percentuale, appena percettibile da sola. Ma attraverso centinaia di piccoli miglioramenti cumulativi, un sistema diventa gradualmente abbastanza affidabile da funzionare come infrastruttura di lungo periodo.
Accuratezza: il retrieval stabilisce il limite massimo
Nei sistemi RAG e agentici, la qualità del retrieval determina direttamente le prestazioni del modello. Se il sistema non riesce a recuperare le informazioni corrette, il modello non ha modo di compensare.
James sottolinea che l’accuratezza non è solo una questione di database. Dipende dall’intero stack di retrieval, inclusi modelli di embedding, strategie di reranking e qualità dei dati. Poiché questi componenti evolvono rapidamente, i team devono rivalutare frequentemente le proprie configurazioni—spesso ogni pochi mesi—per mantenere l’accuratezza nel tempo.
Come Zilliz bilancia open source e business
Nell’ultimo anno o due, James ha dedicato molto tempo a riflettere su una sfida che si presenta ripetutamente per le aziende open-source: come costruire e sostenere una community open-source attiva, gestendo al tempo stesso un business in crescita.
Gli obiettivi open source e commerciali non sempre si allineano perfettamente. I progetti open-source dipendono dall’apertura, dalla partecipazione a lungo termine e dalla fiducia della community, mentre un’azienda deve gestire obiettivi di ricavi e vincoli di crescita. Negli ultimi anni, questa discrepanza è diventata più visibile in tutto il settore. James ha visto diversi team spostare i loro progetti open-source in modalità manutenzione, non perché la tecnologia avesse smesso di funzionare, ma perché il modello open-source era diventato difficile da sostenere man mano che il business cresceva.
Ma per Zilliz, l’open source non è solo una scelta tecnica: è anche una decisione di go-to-market. In pratica, funziona in modo molto simile a una free trial altamente tecnica: un modo per gli sviluppatori di scoprire, valutare e acquisire fiducia in un prodotto attraverso un utilizzo reale. Questo è particolarmente importante per le startup, dove acquisire i primi utenti è difficile. Per un team guidato dall’ingegneria come Zilliz, questo si è dimostrato molto più efficace rispetto agli approcci tradizionali di marketing o guidati dalle vendite.
Rendendo Milvus open-source, il team si è concentrato su GitHub come principale punto di ingresso. Gli sviluppatori hanno usato Milvus in carichi di lavoro reali, condiviso feedback e contribuito con miglioramenti al progetto. Nel tempo, questo ha creato un ciclo di feedback stretto tra utenti, community e sviluppo del prodotto.
I risultati sono stati tangibili. James osserva che circa l’80% dei clienti di Zilliz Cloud ha iniziato come utenti del progetto open-source Milvus. L’open source è servito anche come potente meccanismo di fiducia: i team che avevano eseguito Milvus autonomamente erano molto più a loro agio nell’adottare in seguito un’offerta commerciale.
Tuttavia, quella transizione non è mai stata automatica. James è chiaro sul fatto che l’open source da solo non crea un business. Un prodotto commerciale deve fare più che confezionare l’open source: deve risolvere problemi che la versione open-source non risolve. Per Zilliz, quel valore risiede nell’operare Milvus in modo affidabile su larga scala: gestire gli aggiornamenti, affrontare i guasti e ottimizzare continuamente prestazioni e costi.
Un risultato importante di questo approccio è che molti utenti vedono diminuire i costi complessivi dopo il passaggio all’offerta gestita. I database vettoriali evolvono rapidamente, spinti dai progressi nell’indicizzazione, nella quantizzazione e nello storage. Con Zilliz Cloud, gli utenti beneficiano continuamente di questi miglioramenti, senza doversi assumere l’onere degli aggiornamenti o della gestione dell’infrastruttura.
Dal punto di vista di James, questo equilibrio è ciò che rende sostenibile il modello. L’open source crea accesso e fiducia. L’offerta commerciale trasforma il progresso infrastrutturale a lungo termine in valore pratico, senza compromettere l’apertura che ha attratto gli utenti fin dall’inizio.
Come Zilliz si distingue in un mercato affollato
Quando gli viene chiesto come appare oggi il mercato dei database vettoriali, James riconosce che la rapida adozione dell’AI ha rapidamente affollato lo spazio. Ora include servizi gestiti, plugin leggeri e un numero crescente di nuovi operatori che offrono funzionalità di ricerca vettoriale. In superficie, molte di queste soluzioni sembrano simili.
Secondo James, la vera distinzione non è definita da elenchi di funzionalità, ma dalla profondità e maturità dei sistemi sottostanti. Creare una funzione di base di ricerca vettoriale è relativamente semplice. Costruire un sistema in grado di operare in modo affidabile su larga scala, per lunghi periodi di tempo, non lo è.
Maturità dei sistemi
Il vantaggio di Zilliz parte dalla maturità dei sistemi, in particolare scalabilità, stabilità e controllo dei costi. Fin dall’inizio, Milvus è stato progettato come un database distribuito, Kubernetes-native, costruito per rimanere stabile mentre i volumi di dati crescono di decine di volte. Questo è importante perché i carichi di lavoro vettoriali raramente scalano in modo lineare. I sistemi che funzionano bene su piccola scala spesso faticano quando l’utilizzo diventa sostenuto, irregolare e imprevedibile.
Anche il costo fa parte di questa maturità. Zilliz ha investito presto nell’indicizzazione multi-tier, combinando memoria, disco e object storage. Questo offre agli utenti una flessibilità pratica per bilanciare prestazioni e costi man mano che i carichi di lavoro evolvono, invece di vincolarli a un’unica modalità operativa costosa.
Prontezza per l’enterprise
La prontezza per l’enterprise è un altro elemento distintivo chiave. James mette a confronto Zilliz con team che provengono principalmente da background incentrati sui modelli o sull’AI. Le radici di Zilliz nell’ingegneria tradizionale dei database hanno portato a investimenti precoci in funzionalità come controllo degli accessi, isolamento dei dati, deployment BYOC, crittografia e compliance.
Queste funzionalità non sono opzionali su scala enterprise. Sono ciò che consente ai database vettoriali di andare oltre la sperimentazione degli sviluppatori ed entrare in ambienti regolamentati come finanza, sanità e grandi organizzazioni con rigorosi requisiti di sicurezza e governance.
Affidabilità operativa
James osserva che molti team sottovalutano la complessità operativa a lungo termine dei database vettoriali. I primi sistemi possono funzionare bene in configurazioni controllate, ma le vere sfide emergono quando i dati crescono rapidamente, la concorrenza aumenta e le applicazioni AI passano alla produzione continua.
La maggior parte delle aziende non vuole investire tempo e risorse nella gestione di infrastrutture complesse, soprattutto in aree altamente specializzate come la ricerca vettoriale. È qui che James vede il ruolo di Zilliz: farsi carico dell’onere operativo dell’esecuzione di database vettoriali su larga scala, così che i team possano concentrarsi sulla creazione di applicazioni invece che sulla manutenzione dell’infrastruttura. Con la maturazione del mercato, questa divisione del lavoro diventa sempre più importante.
Guardando avanti: la prossima fase dei database vettoriali
Guardando ai prossimi tre-cinque anni, James adotta una visione pragmatica della direzione in cui si sta muovendo il settore. La crescita continuerà, ma la domanda chiave non sarà più se sia possibile costruire sistemi di database vettoriali: sarà se possano essere gestiti in modo sostenibile. Man mano che i modelli diventano più grandi e le applicazioni AI entrano più profondamente in produzione, i volumi di dati si espanderanno rapidamente, alzando l’asticella per controllo dei costi, affidabilità, accuratezza e sicurezza.
In quell’ambiente, la capacità di ridurre i costi di un ordine di grandezza senza compromettere la qualità del retrieval diventa un benchmark determinante. James ritiene che sia qui che si formino vantaggi duraturi. I leader a lungo termine nello spazio dei database vettoriali non saranno determinati da funzionalità o hype, ma dalla disciplina infrastrutturale: la capacità di eseguire sistemi su larga scala in modo efficiente, affidabile e nel tempo.
Per ascoltare la discussione completa, puoi trovare l’episodio su Spotify, Apple Podcasts, e YouTube.
Continua a leggere
From Vector Database to Vector Lakebase
Zilliz offers a fully managed Vector Lakebase powered by Milvus, unifying real-time vector search, lake-scale discovery, and Al data operations.
Expanding Our Global Reach: Zilliz Cloud Launches in Azure Central India
Zilliz Cloud expands to Azure Central India. This new region helps customers meet compliance, reduce latency, and optimize cloud costs when building AI applications.
Why AI Databases Don't Need SQL
Whether you like it or not, here's the truth: SQL is destined for decline in the era of AI.