Note di rilascio
Scopri le novità di Milvus! Questa pagina riassume le nuove funzionalità, i miglioramenti, i problemi noti e le correzioni di bug presenti in ogni versione. Ti consigliamo di visitare regolarmente questa pagina per rimanere aggiornato sulle novità.
v3.0.0
Data di rilascio: 29 luglio 2026
| Versione di Milvus | Versione SDK Python | Versione SDK Node.js | Versione SDK Java | Versione SDK Go |
|---|---|---|---|---|
| 3.0.0 | 3.0.1 | 3.0.3 | 3.0.5 | 3.0.0 |
Milvus 3.0.0 è stato ufficialmente rilasciato! Basandosi sull'architettura lake-native introdotta nella versione 3.0-beta, questa versione completa ciò che la beta aveva iniziato: External Collection copre un numero maggiore di flussi di lavoro lakehouse; lo schema supporta l'aggiunta, il backfill e l'eliminazione online; l'indice sparse è stato ricostruito attorno a SINDI; StructArray e la ricerca per faccette completano il motore di recupero; il passthrough FAISS e TEXT ampliano le opzioni di indicizzazione e modalità; inoltre, Woodpecker funziona come servizio autonomo.
Guarda il video qui sotto per saperne di più su Milvus 3.0 e partecipa alla sessione AMA con i manutentori del core:
Se non conosci ancora la linea 3.0, la sezione "Riepilogo delle funzionalità di Core 3.0" qui sotto riassume le funzionalità introdotte nella versione 3.0-beta; le note di rilascio della versione 3.0-beta contengono le descrizioni complete.
Novità della versione 3.0.0 (rispetto alla 3.0-beta)
Raccolta esterna: flussi di lavoro lakehouse più completi
La versione 3.0-beta ha introdotto la funzione "External Collection": è possibile fare riferimento ai file del lakehouse in loco, creare indici ed effettuare ricerche senza copiare i dati in Milvus. Questa versione estende tale funzionalità verso flussi di lavoro completi di recupero dati in ambiente lakehouse. I campi esterni possono ora alimentare i campi di output delle funzioni, come i vettori sparsi BM25, le firme MinHash e gli embedding di testo, in modo che i campi di recupero derivati dal testo e dal modello vengano creati all’interno di Milvus senza copiare la tabella di origine. Refresh supporta inoltre l’evoluzione additiva dello schema: quando la tabella esterna acquisisce nuove colonne, Milvus applica le patch ai segmenti interessati invece di ricostruire la collezione.
Questa versione aggiunge inoltre un formato esterno denominato " milvus-table " che tratta i metadati degli snapshot di Milvus e i manifesti di Storage V3 come una fonte esterna, in modo che uno snapshot della collezione possa essere utilizzato a sua volta come tabella esterna: i sistemi di elaborazione in batch e di servizio ottengono una vista condivisa e supportata dal manifesto degli stessi dati.
Per ulteriori informazioni, consultare Creare una raccolta esterna e snapshot.
Schema flessibile: aggiungere, integrare e rimuovere colonne online
Gli schemi non rimangono statici in produzione — i modelli incorporati vengono sostituiti, le feature subiscono iterazioni, i campi vengono deprecati — e in passato ciò comportava ricostruzioni complete della collezione con tempi di inattività o doppie scritture. La versione 3.0.0 chiude il cerchio: le colonne possono essere aggiunte, popolate e rimosse mentre il servizio continua.
Il backfill funziona in entrambe le direzioni. Il backfill esterno gestisce i valori calcolati al di fuori di Milvus: si aggiunge una colonna, si esegue uno snapshot della collezione come punto di partenza coerente, si esegue il processo offline, si riscrivono i valori e Milvus indicizza la nuova colonna in modo incrementale — un aggiornamento del modello di embedding su centinaia di milioni di righe diventa un’operazione a caldo senza tempi di inattività. Il backfill interno copre i valori derivati dal kernel: basta associare una funzione BM25 o MinHash a una collezione esistente e il suo campo di output viene calcolato automaticamente sui dati esistenti.
Per ulteriori informazioni, consultare la sezione “Aggiunta di campi a una collezione esistente”.
Riorganizzazione degli indici sparsi: SINDI, Block-Max WAND e Block-Max MaxScore
Milvus 3.0 aggiorna l’indice vettoriale sparso su tutta la linea. Introduce nuovi algoritmi di ricerca — SINDI, Block-Max WAND e Block-Max MaxScore — insieme alla compressione con lista invertita, alla quantizzazione configurabile e alla selezione dell’algoritmo di ricerca in base al carico di lavoro. Anche il caricamento tramite mmap, la serializzazione e il punteggio BM25 sono stati ottimizzati, riducendo lo spazio di archiviazione dell’indice e il sovraccarico di caricamento per la ricerca su vettori sparsi e full-text su larga scala. Nei benchmark interni, l’indice BM25 compresso è circa 3 volte più piccolo dell’indice sparso 2.6 a un recall comparabile, mentre SINDI raggiunge fino a circa 10 volte il QPS di MaxScore su embedding sparsi appresi. Una volta abilitata la nuova versione dell’indice (vedere le note sulla compatibilità e sul comportamento), SINDI diventa l’impostazione predefinita per la ricerca IP sparsa, mentre MaxScore è l’impostazione predefinita per BM25.
Copertura di StructArray
StructArray ora supporta i valori nulli, gli indici bitmap, l’aggiunta dinamica di campi su collezioni attive e l’aggiornamento parziale dei campi struct tramite upsert, con copertura REST e importazione in blocco corrispondenti.
La ricerca a livello di elemento aggiunge la ricerca ibrida tra i sottocampi vettoriali con raggruppamento configurabile per entità (varianti max / sum / avg / top-k), oltre alla ricerca per intervallo e al raggruppamento al suo interno. Il filtraggio annidato copre i predicati element_filter, i quantificatori MATCH_ANY / MATCH_ALL / MATCH_LEAST / MATCH_MOST / MATCH_EXACT, l’accesso posizionale ai sottocampi come tags[0][name] e array_length() sulla colonna struct.
Per ulteriori informazioni, consultare StructArray e Operatori StructArray.
Aggregazione della ricerca e ricerca per faccette
L’aggregazione delle query della versione beta calcola statistiche esatte sui dati filtrati; la versione 3.0.0 aggiunge la suddivisione per faccette nel percorso di ricerca. Specificare un campo di faccetta al momento della ricerca e Milvus restituisce i valori di faccetta principali, ciascuno rappresentato dal suo membro con la migliore corrispondenza nella classifica ANN e annotato con aggregati quali COUNT e AVG — la barra laterale della ricerca per faccette (marchio, fascia di prezzo, attributi) in un’unica richiesta, invece di effettuare un recupero eccessivo e un conteggio lato client.
Riconversione della classifica tramite Function Chain
Il riclassamento è ora componibile tramite l’API Function Chain, che esegue una pipeline ordinata e tipizzata come parte di un’unica richiesta di ricerca. Una catena può combinare il riscoraggio L0 iniziale su QueryNode con il riclassamento L2 post-riduzione su Proxy, supportando la trasformazione e la combinazione dei punteggi, il riclassamento basato su modelli, l’ordinamento e il taglio dei candidati senza orchestrazione lato client. Questa versione aggiunge inoltre il punteggio XGBoost nativo per il riordino L0 utilizzando modelli UBJ registrati come FileResources, insieme ai provider di inferenza Hugging Face per l’embedding del testo gestito dal server e il riordino basato sulla somiglianza delle frasi.
Campi TEXT per testi lunghi
I campi TEXT rendono i testi lunghi di prima classe, eliminando i limiti di lunghezza a livello di archiviazione: supportano text_match, phrase_match e BM25. I valori inferiori a 64 KB rimangono in linea; quelli più grandi vengono trasferiti in file LOB a livello di partizione in formato Vortex, con la colonna che memorizza solo i riferimenti (file_id, offset). I file LOB sono condivisi tra i segmenti, quindi la compattazione sposta i riferimenti invece di riscrivere il testo. Per RAG ciò significa recuperare vettori e testo sorgente dallo stesso archivio in un unico I/O — senza bisogno di gestire un archivio blob esterno.
Pass-through dell’indice FAISS
Un nuovo tipo di indice « FAISS » accetta stringhe arbitrarie di «index-factory» di Faiss tramite il parametro « faiss_index_name » — IVF64,Flat, HNSW16,Flat, OPQ16,IVF64,PQ16x4 — con i parametri di ricerca passati direttamente, in modo che le ricette di Faiss vengano riprodotte direttamente su Milvus.
Supporto dei formati Vortex e Lance
Il livello di archiviazione acquisisce due formati colonnari aperti: Vortex come formato interno di nuova generazione — codifiche adattive (dizionario, RLE, bit-packing, compressione specifica per i valori in virgola mobile), decompressione zero-copy, ottimizzato per carichi di lavoro misti vettoriali e scalari — e Lance, insieme a Parquet, per l’interoperabilità con l’ecosistema aperto. Vortex è destinato a diventare il formato interno predefinito, con il pushdown dei filtri e una variante locale in fase di sviluppo.
Distribuzione autonoma di Woodpecker
Woodpecker, il WAL al centro del percorso di scrittura in streaming, può ora essere implementato come servizio indipendente anziché integrato in altri nodi — scalabilità indipendente, isolamento dei guasti e osservabilità, come qualsiasi altro microservizio. Ciò è particolarmente importante per i cluster di grandi dimensioni e i carichi di lavoro con un elevato numero di operazioni di scrittura.
Riepilogo delle funzionalità principali della versione 3.0
Le funzionalità riportate di seguito sono state introdotte nella versione 3.0-beta e fanno parte della versione 3.0.0; consultare le note sulla versione beta per le descrizioni complete.
- Raccolta esterna — interrogazione dei dati lakehouse (Parquet, Lance, Iceberg, Vortex) in loco: zero-copy, di sola lettura, sincronizzati tramite aggiornamento incrementale.
- Snapshot — viste di raccolta in sola lettura a un punto nel tempo tramite riferimento al segmento, con spazio di archiviazione marginale quasi nullo.
- Storage V3 (Loon) — archiviazione colonnare basata su manifest su storage a oggetti; la base per Snapshot e Raccolta esterna.
- Query / Ricerca ORDER BY — ordinamento multi-campo lato server con ASC / DESC per campo.
- Aggregazione delle query — COUNT / SUM / AVG / MIN / MAX con raggruppamento, valutata lato server.
- EmbList + DiskANN — indicizzazione multivettoriale su disco per elenchi di incorporamento StructArray, con percorsi di accelerazione quali Muvera e Lemur.
- Funzione MinHash (doc-in, doc-out) — firme MinHash lato server più "
MINHASH_LSH" per il rilevamento di quasi-duplicati. - Vettori nullabili — NULL su tutti e sei i tipi di vettore; la ricerca salta le righe NULL e AddField si estende ai campi vettoriali.
- TTL delle entità — scadenza per riga determinata da un campo TIMESTAMPTZ.
- FileResource — dizionari, elenchi di sinonimi ed elenchi di parole da escludere gestiti a livello di cluster per analizzatori, BM25 e Text Match.
- Force Merge — compattazione dei segmenti attivata dall’operatore, in modalità sincrona o asincrona.
Note sulla compatibilità e sul comportamento
- Storage V3 (Loon) è disabilitato per impostazione predefinita. Le funzionalità che dipendono da esso — come i campi Snapshot e TEXT — richiedono l’abilitazione manuale tramite
common.storage.useLoonFFI. Storage V3 sarà abilitato per impostazione predefinita in una versione successiva. - La compatibilità e il rollback dalla versione 2.6 alla 3.0 sono garantiti: una distribuzione della versione 3.0 può essere riportata alla versione 2.6. Tuttavia, una volta abilitate o utilizzate funzionalità che modificano il formato dei dati serializzati (ad esempio Storage V3), il rollback non è più possibile.
- Le nuove versioni dell’indice sono per ora opzionali. Gli algoritmi di indicizzazione di nuova introduzione richiedono l’aumento manuale della versione dell’indice di destinazione (da
dataCoord.targetVecIndexVersiona 10, dadataCoord.targetScalarIndexVersiona 4) prima che entrino in vigore; una versione successiva li abiliterà per impostazione predefinita. - Le immagini GPU passano a CUDA 12.9 e non mantengono più la compatibilità GPU con Ubuntu 20.04.
v3.0-beta
Data di rilascio: 9 maggio 2026
| Versione di Milvus | Versione SDK Python | Versione SDK Node.js |
|---|---|---|
| 3.0-beta | 3.0.0 | 3.0.0 |
Milvus 3.0-beta amplia il database vettoriale Milvus con una nuova integrazione nell’ecosistema Open Lake: External Collection consente a Milvus di interrogare le tabelle Lake esterne senza copia (zero-copy), mentre Spark può leggere le collezioni Milvus direttamente tramite Snapshot. Questa versione offre inoltre funzionalità di recupero più avanzate, schemi più espressivi, una personalizzazione più approfondita della ricerca testuale, controlli più precisi sul ciclo di vita dei dati e dei modelli, nonché maggiori controlli a livello di operatore. Milvus 3.0 costituisce il kernel centrale di Zilliz Lakebase, ne alimenta il funzionamento unificato in termini di servizio, discovery e elaborazione batch.
Caratteristiche principali
External Collection
Nelle tipiche pipeline di dati per l’IA, terabyte di embedding e metadati risiedono già su sistemi di archiviazione a oggetti sotto forma di tabelle Parquet, Lance o Iceberg. Copiare tali dati in Milvus raddoppia i costi di archiviazione, aggiunge una pipeline ETL che deve essere mantenuta sincronizzata e sottrae al cliente il controllo sulla governance dei dati.
La raccolta esterna elimina la necessità di copia. Una raccolta Milvus può fare riferimento ai file nella loro posizione originale, mentre Milvus gestisce esclusivamente lo schema, gli indici e l’esecuzione delle query. Un aggiornamento incrementale mantiene la raccolta allineata ai file sottostanti. I clienti i cui dati non possono lasciare il data lake, come i team finanziari e sanitari, possono eseguire il recupero vettoriale su quei dati direttamente dove si trovano. Un singolo set di dati residente nel data lake può anche essere servito da più istanze di Milvus contemporaneamente.
Per ulteriori informazioni, consultare la sezione Creare una raccolta esterna.
Snapshot
La distribuzione e la scoperta in batch spesso richiedono la stessa Collection contemporaneamente. La valutazione dei modelli A/B, la deduplicazione su larga scala, la convalida del backfill e il rollback delle versioni richiedono tutte una visione stabile della Collection mentre le operazioni di scrittura sono ancora in corso.
Lo snapshot crea una vista "point-in-time" e di sola lettura di una raccolta facendo riferimento ai segmenti esistenti anziché copiare i dati, quindi il costo marginale di archiviazione è prossimo allo zero. I processi batch possono leggere dallo snapshot con isolamento in stile MVCC mentre la raccolta attiva continua ad accettare operazioni di scrittura.
Per ulteriori informazioni, consultare le sezioni Snapshot, Gestione degli snapshot e Casi d’uso degli snapshot.
Query / Ricerca con ordinamento
La ricerca e le query ora supportano l’ordinamento su più campi, con l’ordinamento delegato al kernel di Milvus e le opzioni “ ASC ” e “ DESC ” configurabili per ogni campo. Ciò colma una lacuna comune in produzione: il Top-K basato esclusivamente sulla distanza spesso non soddisfa le esigenze aziendali quando l’elemento più simile non è il più economico, il più recente o il più popolare.
Le applicazioni non devono più recuperare un numero eccessivo di risultati e riordinarli sul client per ottenere una classifica composita.
Per ulteriori informazioni, consultare Ordinamento dei risultati di ricerca in base a campi scalari e Ordinamento dei risultati delle query.
Aggregazione delle query
In passato, per generare statistiche sulla distribuzione dei tenant, conteggi sulla completezza dei campi o lo stato di avanzamento del rollout delle versioni da una Milvus Collection, era necessario recuperare le entità corrispondenti sul client e aggregarle lì. Milvus 3.0 integra l’aggregazione scalare in stile SQL nel kernel. Una chiamata di query accetta espressioni di aggregazione e di tipo “ group_by_fields ” in output_fields, tra cui count(*), count(<field>), sum(<field>), avg(<field>), min(<field>) e max(<field>). L’aggregazione viene valutata sul lato server dopo il filtraggio.
Per ulteriori informazioni, consultare Risultati delle query di aggregazione.
Vettore nullo
Gli embedding vengono spesso generati in modo asincrono, pertanto un’entità può arrivare prima del proprio vettore. Anche i dati multimodali presentano lacune naturali, come un video senza sottotitoli o un prodotto senza immagine. Le versioni precedenti non offrivano una soluzione adeguata: le applicazioni ritardavano la scrittura fino a quando il vettore non era pronto oppure inserivano un vettore segnaposto, e entrambe le scelte compromettevano la qualità del recupero.
Milvus 3.0 supporta il valore NULL nei campi vettoriali per tutti e sei i tipi di vettori. La ricerca ignora automaticamente i vettori NULL, la qualità del recupero non ne risente e i vettori NULL non occupano praticamente spazio di archiviazione. Con questa modifica, la funzione " AddField " si estende anche ai campi vettoriali: grazie a " nullable=True", una Collection esistente può aggiungere nuovi campi vettoriali online senza necessità di ricostruzione.
Per ulteriori informazioni, consultare Campi nullabili.
Dizionario personalizzato e dizionario dei sinonimi
I tokenizzatori predefiniti non sempre soddisfano i requisiti di qualità della ricerca in produzione. Il cinese, i settori verticali come medicina, diritto e chimica, nonché i corpora multilingue possono trarre notevoli vantaggi dai dizionari personalizzati e dalle tabelle di sinonimi. Finora, queste risorse erano per lo più implementate come riscritture delle query a livello di applicazione.
Milvus 3.0 introduce un meccanismo FileResource per la registrazione di dizionari personalizzati per i tokenizzatori, elenchi di sinonimi, elenchi di parole da escludere e regole di scomposizione delle parole composte. Una volta registrata, una risorsa può essere richiamata da qualsiasi tokenizer o filtro e ha effetto su BM25, sugli analizzatori e su Text Match. I dizionari e i sinonimi possono ora essere gestiti centralmente e con controllo delle versioni, anziché essere sparsi nel codice dell’applicazione.
Per ulteriori informazioni, consultare Gestione delle risorse file.
TTL delle entità
Il TTL a livello di raccolta e di partizione è troppo generico per molti scenari relativi al ciclo di vita e alla conformità. Tenant diversi all’interno della stessa raccolta hanno spesso regole di conservazione diverse e le singole entità potrebbero dover scadere secondo una tempistica che non corrisponde al resto della raccolta.
Milvus 3.0 supporta il TTL per singola entità. È sufficiente dichiarare un campo « TIMESTAMPTZ » nello schema, contrassegnarlo come campo TTL tramite una proprietà della raccolta e Milvus provvederà automaticamente a liberare le entità scadute. Ciò copre le richieste relative al «diritto all’oblio», la scadenza dei dati di sessione e la cronologia delle conversazioni limitata, senza necessità di pulizia da parte dell’applicazione.
Per ulteriori informazioni, consultare Impostazione del TTL a livello di entità.
MinHash DIDO (Doc-in, Doc-out)
Milvus 2.6 ha aggiunto l’indice MINHASH_LSH per il rilevamento di quasi-duplicati basato su insiemi, ma le applicazioni dovevano comunque calcolare le firme MinHash prima di scrivere i dati in Milvus.
Milvus 3.0 aggiunge una funzione MinHash lato server. È sufficiente dichiarare nello schema un campo di input " VARCHAR " e un campo di output " BINARY_VECTOR ", associare una funzione " FunctionType.MINHASH " e Milvus calcolerà le firme durante l’inserimento, l’inserimento in blocco e la ricerca. Insieme a " MINHASH_LSH", ciò supporta i flussi di lavoro di deduplicazione per grandi set di dati, il fingerprinting e il rilevamento del plagio all’interno di Milvus.
Per ulteriori informazioni, consultare Funzione MinHash.
EmbList + DISKANN
L’assunto “un’entità = un vettore” non è più adeguato al recupero moderno. I documenti lunghi vengono suddivisi in molti blocchi, i modelli a interazione tardiva come ColBERT generano un vettore per ogni token e le entità multimodali possono presentare diverse viste.
EmbList memorizza un elenco di vettori a lunghezza variabile per ogni entità, utilizzando l’ DISKANN come indice su disco. Il percorso su disco mantiene sotto controllo l’utilizzo della RAM quando il corpus supera i limiti di memoria disponibili. EmbList + DISKANN è la prima variante della più ampia famiglia StructList presente in questa versione RC. Il resto della famiglia, compreso il filtraggio StructList e l’accelerazione multivettoriale Muvera / Lemur, è previsto per la versione ufficiale 3.0.
Per ulteriori informazioni, consultare Ricerca con elenchi di embedding.
Force Merge
I carichi di lavoro di produzione accumulano frammentazione dei segmenti nel tempo, causando fluttuazioni nella latenza delle query e un aumento dello spazio di archiviazione.
Milvus 3.0 aggiunge la possibilità di attivare esplicitamente la compattazione dei segmenti durante le finestre di traffico ridotto, sia in modalità sincrona che asincrona.
Per ulteriori informazioni, consultare " Compattazione con unione forzata".
Storage V3
Milvus 3.0 introduce Storage V3, un motore di archiviazione colonnare basato su manifesti in cui dati e metadati risiedono su un sistema di archiviazione a oggetti compatibile con S3. Ogni versione del set di dati viene acquisita come snapshot immutabile del manifesto, un file codificato in Avro che registra quali gruppi di colonne, log delta e statistiche compongono il set di dati.
I manifesti sono file Avro compatti, mentre i log delta registrano le eliminazioni a livello di entità senza riscrivere i file di dati. Ciò mantiene ridotto il sovraccarico dei metadati man mano che i set di dati crescono. Il manifesto inoltre disaccoppia il tracciamento dei metadati dal percorso di query, consentendo a una Collection di gestire un numero maggiore di segmenti senza compromettere le prestazioni delle query.
Poiché gli stati sono archiviati su uno storage a oggetti, il set di dati è autodescrittivo: qualsiasi lettore con accesso al percorso di archiviazione può individuarlo e interpretarlo senza bisogno di un catalogo centrale. Questa proprietà è alla base delle integrazioni con External Collection, Snapshot e dei futuri lake.