Le regole del digitale stanno cambiando.
O sei visibile o sei fuori. Noi ti aiutiamo a raggiungere i clienti giusti — quando ti stanno cercando.
Contattaci ora
Il metodo si chiama Reverse Neighbor Sliding Merge e riusa i vicini già calcolati negli indici esistenti
Un paper accettato a SIGMOD 2027 propone il metodo Reverse Neighbor Sliding Merge per fondere indici HNSW riusando i vicini già calcolati, con speedup fino a 3,86 volte sul merge e 9,92 volte sulla ricostruzione, testato su 50 sotto-indici e 100 milioni di vettori. La promessa è concreta per i database vettoriali, ma i risultati andranno confermati su carichi reali di produzione.
Un paper appena accettato a SIGMOD 2027 promette di cambiare il modo in cui i database vettoriali fondono i propri indici HNSW. Per capire perché la notizia conta, bisogna partire da una premessa: i database vettoriali sono quelli che usano motori di ricerca e sistemi di raccomandazione per trovare elementi simili tra loro, e l’indice HNSW è la struttura che rende quelle ricerche efficienti. Lo studio è firmato da Liuchang Jing, Mingyu Yang, Lei Li, Jianbin Qin e Wei Wang. La pagina arXiv del lavoro riporta la sottomissione il 19 febbraio 2026 e l’ultima revisione il 17 settembre 2026, ovvero ieri. L’accettazione a SIGMOD 2027 è già annotata sul manoscritto.
Il metodo si chiama Reverse Neighbor Sliding Merge, in sigla RNSM. La domanda che prova a rispondere è semplice: quando un database vettoriale deve unire due o più indici, serve davvero buttare via i grafi esistenti e ricostruire tutto da capo?
Il dato che conta: 3,86x di speedup sul merge HNSW
Il numero da tenere a mente è 3,86. Secondo gli esperimenti riportati nel paper, RNSM ottiene fino a 3,86 volte di speedup rispetto ai metodi esistenti di merge di indici. In parole più semplici: l’operazione di fusione, che prima richiedeva una certa quantità di tempo, ora può essere completata in meno di un terzo di quel tempo.
Il confronto con la ricostruzione dell’indice è ancora più netto: fino a 9,92 volte più veloce, mantenendo prestazioni di ricerca comparabili. Non è un risultato da laboratorio su dataset piccoli: gli autori hanno testato la fusione di fino a 50 sotto-indici su dataset di 100 milioni di vettori, con speedup che restano coerenti al crescere della scala.
Ma perché un merge di indici più veloce dovrebbe interessare a chi gestisce un database vettoriale? Il problema parte da una scelta architetturale.
Perché i segmenti immutabili trasformano il merge in un collo di bottiglia
Lucene utilizza segmenti immutabili: una scelta architetturale che porta all’uso di più grafi a livello di segmento. Quando i dati cambiano, si creano nuovi segmenti; quando i segmenti diventano troppi, vanno fusi. E qui arriva il costo nascosto. Lo stato dell’arte precedente, come descritto nel blog di ricerca di Elastic, prevedeva di mantenere il grafo più grande e reinserire i vettori da quelli scartati, ignorando i grafi che li contengono. Tradotto: l’informazione strutturale già calcolata finiva nel cestino e una parte dei dati veniva reindicizzata da zero. Un costo che cresce con la frequenza degli aggiornamenti.
Eppure c’è un paradosso: il modo in cui il database salva i dati non è il modo migliore per servirli. Come si può fondere due grafi HNSW senza ripartire da zero?
Tre algoritmi per fondere grafi HNSW, più uno nuovo
La ricerca precedente ha proposto tre algoritmi: Naive Graph Merge (NGM), Intra Graph Traversal Merge (IGTM) e Cross Graph Traversal Merge (CGTM). Sono descritti in un paper su arXiv, dove il merging di grafi HNSW viene definito un’operazione critica per sistemi distribuiti, indicizzazione incrementale e compattazione di database. In parallelo esiste anche HNSW-Merger, un algoritmo a due stadi basato su ricerca che unisce due o più indici HNSW sfruttando le informazioni di prossimità degli indici esistenti: prevede forward HNSW search e lazy backward direct-connect, come descritto nella pagina GitHub del progetto.
Il nuovo paper accettato a SIGMOD 2027 aggiunge un tassello diverso: RNSM sfrutta le informazioni di prossimità già presenti negli indici invece di scartarle. È l’idea del Reverse Neighbor Sliding, che riusa i vicini già calcolati per costruire il grafo fuso. Il contesto spiega perché il problema esiste. Scritture continue, aggiornamenti incrementali, cancellazioni e flush lasciano dietro di sé segmenti sigillati: è quanto descritto nel blog di Milvus dedicato alla compattazione. Un layout valido per salvare i dati, ma non il più veloce per servire le query.
Per chi fa impresa online, un merge più efficiente significa query più veloci su cataloghi e raccomandazioni in continua evoluzione, senza dover scegliere tra freschezza dei dati e tempi di risposta. Il paper non promette soluzioni magiche: dice che si può fare meglio riusando il lavoro già fatto, e lo dimostra con numeri che i progettisti di database vettoriali dovranno prendere sul serio.
