Blog
Guida per sviluppatori all’esplorazione delle funzionalità di Milvus 2.6 su Zilliz Cloud

Guida per sviluppatori all’esplorazione delle funzionalità di Milvus 2.6 su Zilliz Cloud

Feb 11, 202610 min read

Milvus è nato come database vettoriale open-source ad alte prestazioni progettato per scalare, con funzionalità di ricerca vettoriale ANN all'avanguardia. Con la crescita della community di sviluppatori, le richieste di funzionalità si sono estese fino a includere ricerca full-text, boosting e supporto per tipi di dati semi-strutturati (JSON, struct, ecc.). Queste richieste riflettono una tendenza più ampia verso la convergenza delle capacità dei database, spinta dalla necessità di funzionalità più avanzate (oltre alla ricerca per similarità) che aiutino ad accelerare lo sviluppo di applicazioni AI.

La convergenza non emerge solo nelle richieste di funzionalità — ora emerge nel database stesso. Con Milvus 2.6, molte capacità che in precedenza gli sviluppatori dovevano assemblare al di fuori del database, come il ranking basato sul decadimento, il boosting a livello di campo e il filtraggio ibrido tra dati strutturati e non strutturati, sono ora primitive di prima classe.

In altre parole, Milvus 2.6 segna il passaggio da "ricerca vettoriale + codice collante" a un motore di retrieval più avanzato, ed è ora Generally Available (GA) su Zilliz Cloud (un servizio Milvus gestito).

In questo articolo, passerò in rassegna alcune delle interessanti funzionalità di Milvus v2.6, quando usarle e come usarle. Iniziamo!

La Embedding Function (nota anche come Data In, Data Out)

Ti sei mai chiesto se il database possa gestire la generazione degli embedding per tuo conto? Con le Embedding Functions (note anche come "Data in, data out"), Milvus può trasformare testo grezzo in vettori chiamando servizi di embedding esterni di terze parti come OpenAI, VoyageAI e Cohere.

Embedding Functions è stata rilasciata per la prima volta in Milvus v2.6.0, e l'ho mostrata nella demo kafka-milvus-no-code-pipelines. Ora, le Embedding Functions sono disponibili su Zilliz Cloud, il servizio completamente gestito del database vettoriale Milvus.

Come funziona la embedding function?

Supponiamo che tu inserisca "The quick brown fox jumps over the lazy dog" in Milvus con una embedding function configurata. Milvus lo intercetta a livello proxy, lo instrada attraverso una pipeline di embedding specifica per provider e memorizza il vettore prodotto dal tuo modello. La stessa trasformazione avviene al contrario durante la ricerca. Il testo della tua query viene convertito in un vettore prima di raggiungere l'indice.

Questa funzionalità è particolarmente utile per i team che desiderano delegare al database la responsabilità di gestire i workflow di embedding. Consentendo al database di generare in modo trasparente gli embedding al momento dell'ingestione (tramite un provider di modelli di terze parti), Zilliz Cloud si occupa dell'integrazione API, del batching, dei retry, dei rate limit e della gestione degli errori.

Per iniziare con le Embedding Functions su Zilliz Cloud, devi:

Configurare la Model Provider Integration per il provider di servizi di embedding che preferisci
Creare una collection con Embedding Function definita
Inserire i tuoi dati.

Dovresti essere in grado di vedere la embedding function nella console di Zilliz Cloud nella pagina dello schema della tua collection, se l'hai configurata correttamente.

Ora devi solo inserire il testo grezzo, e gli embedding verranno generati automaticamente e memorizzati nel campo vettoriale denso specificato. Con le embedding functions definite, non devi più generare embedding, nemmeno per la tua query di ricerca.

Un possibile problema che potresti incontrare sarà il limite di dimensione del batch imposto da Milvus quando si usa la embedding function.

2026-01-21 14:03:12,902 [ERROR][handler]: RPC error: [insert_rows], <MilvusException: (code=65535, message=numRows [1000] > function [openai]'s max batch [640])>, <Time:{'RPC start': '2026-01-21 14:03:12.722589', 'RPC error': '2026-01-21 14:03:12.902013'}>

Best practice e suggerimenti

Resta entro il limite di dimensione del batch (mostrato nel messaggio di errore). Si tratta di un meccanismo di sicurezza per evitare di raggiungere il limite di token del provider del modello per chiamata API. Ad esempio, OpenAI ha una limitazione di massimo 300.000 token per chiamata API.
Per testi lunghi o casi d'uso con documenti di grandi dimensioni, devi suddividere in chunk prima dell'inserimento. Ad esempio, OpenAI ha un limite di 8192 token per testo di input per tutti i modelli di embedding.
Sebbene provider come VoyageAI e Cohere tronchino automaticamente i testi lunghi per impostazione predefinita, fare affidamento su questo può comportare la perdita silenziosa del contenuto alla fine del documento.

Evidenziazione lessicale

L'evidenziazione lessicale è utile per mostrare agli utenti perché un risultato corrisponde alla loro query, marcando visivamente i termini o le frasi esatte che hanno attivato la corrispondenza. Questo migliora trasparenza, interpretabilità e fiducia degli utenti nei risultati di ricerca.

Ecco alcuni scenari chiave:

Visualizzazione dei risultati di ricerca sulle UI. Quando si creano interfacce di ricerca, l'evidenziazione aiuta gli utenti a comprendere rapidamente la pertinenza di un risultato senza aprire il documento completo. Riduce il carico cognitivo e migliora il click-through rendendo esplicita la corrispondenza.

Ricerca di documenti / contenuti. In documenti di grandi dimensioni (ad es. knowledge base, PDF, policy), l'evidenziazione lessicale consente agli utenti di individuare immediatamente le parole chiave corrispondenti nel contesto circostante, accelerando la scoperta delle informazioni.

Analisi di log / eventi. L'evidenziazione nei log operativi o nei dati degli eventi rende più facile individuare pattern corrispondenti, codici di errore o parole chiave all'interno di testo denso e non strutturato, specialmente durante il troubleshooting o la risposta agli incidenti.

Debug di RAG (Retrieval-Augmented Generation). Nelle pipeline RAG, l'evidenziazione lessicale aiuta i professionisti a ispezionare quali parti dei chunk recuperati corrispondono alla query originale. Questo è utile per:

Verificare la correttezza del recupero
Diagnosticare falsi positivi o corrispondenze deboli
Comprendere perché un determinato contesto è stato selezionato per la generazione

Per implementare l'evidenziazione lessicale lato server con Zilliz Cloud, per prima cosa istanzia un LexicalHighlighter (con il testo della query da evidenziare e i tag circostanti per indicare l'aspetto del testo evidenziato) e forniscilo come parametro alla tua richiesta di ricerca full-text.

Quindi, Milvus eseguirà la ricerca e applicherà la logica lessicale per trovare corrispondenze esatte e restituire informazioni posizionali su quali sottostringhe evidenziare.

Best practice e suggerimenti

LexicalHighlighter funziona solo con la ricerca full-text BM25. Non funzionerà per la ricerca vettoriale densa.
Puoi definire pre_tags e post_tags per racchiudere i termini corrispondenti con tag HTML (ad es., classe CSS personalizzata, grassetto, corsivo, ecc.) che vengono renderizzati direttamente su una pagina web.

Indice N-gram

Gli indici N-gram sono potenti tecniche di indicizzazione dei motori di ricerca che scompongono le stringhe in sequenze di caratteri più piccole e sovrapposte (ad es., "coffee" in 3-grammi -> "cof", "off", "ffe", "fee") per abilitare corrispondenze parziali, flessibili e in stile wildcard.

Ecco alcuni scenari in cui troverai utili gli indici n-gram:

Migliorare le prestazioni delle ricerche di sottostringhe (ad es., LIKE %deep%)
Search-as-you-type / autocompletamento
Ricerca fuzzy
Ricerca di nomi di dominio e identificatori (ad es. example.com, facebook.com)

Come funziona?

I documenti che contengono un n-gramma specificato possono essere individuati in modo efficiente utilizzando un indice, spesso indicato come indice invertito, che mappa ogni n-gramma a un elenco di identificatori dei documenti che contengono quell'n-gramma. L'elenco viene mantenuto ordinato per consentire sia una compressione efficiente sia un'esecuzione efficiente delle query. Nel caso di Milvus, l'indice ngram è costruito sopra Tantivy, che a sua volta utilizza tecniche di compressione come delta encoding, bitpacking e skip list per comprimere e ridurre la dimensione della lista invertita, rendendo l'indice leggero.

Invece di eseguire una scansione completa sul tuo campo di testo, Milvus prima estrae il predicato, ad es. deep, lo scompone in n-grammi in base alle dimensioni dei grammi configurate, esegue lookup sull'indice invertito e interseca i risultati per identificare i candidati che contengono tutti i grammi, quindi verifica le corrispondenze esatte rispetto al pattern LIKE originale.

Milvus consente di specificare min_gram e max_gram, che rappresentano rispettivamente la lunghezza minima e massima degli n-grammi che verranno generati. Per maggiori dettagli su come creare e utilizzare l'indice ngram, consulta il documento sull'Indice NGRAM.

Ecco una breve demo dell'autocompletamento implementato utilizzando la funzionalità di indice ngram di Milvus.

Best practice e suggerimenti

Esegui benchmark con query rappresentative: Testa con pattern di query realistici prima della distribuzione in produzione per verificare che le impostazioni min_gram e max_gram siano allineate al comportamento effettivo degli utenti.
Combina strategicamente con la ricerca vettoriale: Usa il filtraggio accelerato da NGRAM come pre-filtro per ridurre l'insieme dei candidati prima del calcolo della similarità vettoriale, migliorando la latenza complessiva delle query.
Evita l'over-indexing: Non tutti i campi VARCHAR traggono beneficio da un indice NGRAM. Dai priorità ai campi utilizzati frequentemente nelle query LIKE con pattern wildcard.
Nota che l'indice n-gram è case-sensitive. Ciò significa che i token vengono indicizzati esattamente come appaiono nel testo originale, preservando le distinzioni tra maiuscole e minuscole. Le query devono corrispondere esattamente alla capitalizzazione utilizzata nel contenuto indicizzato.

Decay Ranker

Immagina di costruire un motore di ricerca semantico per articoli di ricerca, in cui privilegi gli articoli pubblicati negli ultimi 10 anni rispetto a quelli pubblicati più di 10 anni fa.

Senza il decay ranker di Milvus, probabilmente devi riordinare i risultati di ricerca al di fuori del database vettoriale in base al campo dell'anno di pubblicazione. Ciò richiederà elaborazione lato application server / client, che aggiungerà sia complessità sia latenza, con un possibile impatto negativo sull'esperienza utente.

Al centro del decay ranker di Milvus c'è la Decay Function. Le Decay Function regolano i punteggi di rilevanza in base a campi numerici (come i timestamp). Il punteggio finale viene calcolato come:

final_score = normalized_similarity_score x decay_score

Attualmente, esistono tre diverse decay function, vale a dire: Linear, Exponential e Gaussian. Ogni decay function è utile per scenari diversi. Ad esempio, la Linear Function dovrebbe essere utilizzata quando è necessario escludere entità oltre un certo punto (ad es. anni, distanza, ecc.). La Exponential Function può essere utilizzata quando si desidera che gli elementi più recenti dominino i risultati, pur consentendo ai risultati più vecchi di essere individuabili. La Gaussian Function è utile per le ricerche basate sulla posizione, cioè gli elementi più vicini alla posizione attuale verranno classificati più in alto.

Le decay function sono altamente personalizzabili e puoi controllarne la forma utilizzando diversi parametri durante la loro inizializzazione:

origin: Punto di riferimento (ad es., timestamp corrente)
offset: Crea una "zona senza decadimento" in cui gli elementi mantengono punteggi pieni (decay = 1.0). Utile per garantire che elementi molto recenti o molto vicini non vengano penalizzati affatto.
scale: Valori più grandi producono un calo graduale della rilevanza; valori più piccoli producono un calo più ripido.
decay: Controlla la ripidezza della curva. Valori più bassi (ad es., 0.3) creano un calo più ripido; valori più alti (ad es., 0.7) creano un calo più graduale. Il valore predefinito è 0.5.

Ecco un esempio di come determinare i parametri della funzione di decadimento:

Per usare l'anno corrente come origine: origin=2026
Gli articoli di ricerca dal 2021 al 2026 sono ugualmente rilevanti senza alcun decadimento applicato: offset=6
Il moltiplicatore del punteggio alla distanza di scala: decay=0.5
Gli articoli del 2010 dovrebbero avere un punteggio di decadimento (specificato in precedenza) pari a 0.5: scale=16 (poiché 2026 - 2010 = 16)

Best practice e suggerimenti

Esegui A/B test sulle configurazioni di decadimento. Piccole modifiche ai parametri scale e decay possono avere un impatto significativo sull'esperienza utente.
Assicurati che tutti i parametri basati sul tempo (origin, scale, offset) utilizzino la stessa unità dei dati della tua collection.
FunctionScore accetta solo una singola DecayFunction per query. Il concatenamento o la composizione di più DecayFunction non è attualmente supportato.
Ogni decay ranker supporta solo un campo numerico. Non puoi combinare più fattori di decadimento in un singolo ranker.
Evita il decadimento su campi sparsi o distorti. Se il tuo campo di decadimento ha molti valori nulli, outlier o distribuzioni fortemente distorte, il ranking con decadimento può produrre risultati non intuitivi.

Boosting

Il boosting è un meccanismo pratico per incorporare segnali di dominio nel ranking della ricerca vettoriale. Mentre la ricerca semantica coglie di cosa tratta la tua query, spesso ignora ciò che conta di più in un determinato dominio. Il boosting ti consente di riordinare i risultati utilizzando un campo di metadati arbitrario, codificando di fatto l'intuizione di business o di dominio nel livello di retrieval.

Ad esempio, in un workflow di ricerca di articoli scientifici, due articoli possono essere entrambi rilevanti per "deep learning", ma non ugualmente importanti. Un articolo molto citato può meritare di apparire sopra uno meno citato, anche se il suo punteggio di similarità è leggermente inferiore. Con il boosting, un articolo con un punteggio di similarità di 0.79 ma 1.200 citazioni può essere classificato più in alto rispetto a un articolo con punteggio 0.81 e solo 10 citazioni.

Quanto sopra può essere implementato applicando il boosting agli articoli in base al conteggio delle citazioni. Una semplice implementazione è la seguente:

Ma cosa succede se vogliamo applicare il boosting agli articoli di ricerca con conteggi di citazioni compresi tra 100 e 1000 e includere persino una funzione di decadimento per favorire gli articoli più recenti? A quanto pare, possiamo concatenare una funzione di decadimento con più boost ranker in una singola richiesta di ricerca utilizzando la classe FunctionScore.

Best practice e suggerimenti

FunctionScore è attualmente supportato solo per la ricerca vettoriale densa. La ricerca ibrida non supporta FunctionScore; usa invece un singolo ranker.
Per il boosting basato su campi a valori continui, considera di inserire i valori in bucket discreti e assegnare pesi di boost distinti a ciascun bucket.

Conclusione

Milvus 2.6 rappresenta un significativo passo avanti in ciò che un database vettoriale può fare out of the box. Le funzionalità e capacità di cui ho discusso sopra non sono solo piacevoli da avere: eliminano il glue code che gli sviluppatori dovevano precedentemente creare e mantenere al di fuori del database.

Invece di mettere insieme pipeline di embedding esterne, logiche di reranking personalizzate e workaround per la ricerca di sottostringhe, ora puoi esprimerli direttamente nelle tue query Milvus. Il risultato è codice applicativo più pulito, latenza inferiore e meno componenti da debuggare quando qualcosa va storto.

Se hai trattato Milvus come "solo" un archivio vettoriale, potrebbe essere il momento di riconsiderare ciò che è possibile. Tutte queste funzionalità sono ora GA su Zilliz Cloud, quindi puoi iniziare a sperimentare oggi stesso.

Risorse

Aggiornato il Jul 28, 2026

Ivan Tang
Solutions Architect

Continua a leggere

Introducing Loon: A New Storage Engine for Vector Data That Never Stops Changing

Loon is a new storage engine for Milvus 3.0 and Zilliz Vector Lakebase, built to manage evolving vector datasets with ColumnGroups, row ID alignment, and Manifests.

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.

Zilliz Cloud Now Available in AWS Asia Pacific (Seoul)

Zilliz Cloud is now available in AWS Seoul — low-latency vector search, in-country data residency, and one-step migration for Korean AI teams. 31 regions across 5 clouds.