Il team Crusty Coders risponde con un pre-ordinamento lineare dei dati vettoriali
Per anni chi costruiva indici per la ricerca vettoriale ha potuto contare su una comoda semplificazione: i vettori erano normalizzati, quindi il prodotto scalare tra due punti coincideva con la loro similarità coseno. Costruire un grafo di nearest neighbor era un problema relativamente addomesticato. Poi è arrivata l’edizione 2026 della SISAP Indexing Challenge, e quella semplificazione è saltata. Il paper sottomesso il 23 luglio scorso su arXiv dal team Crusty Coders — lo stesso gruppo che firma l’algoritmo Dynamic Exploration Graph dal 2023 — racconta esattamente questo passaggio: il nuovo task impone di lavorare con vettori non normalizzati, e tutto quello che funzionava bene fino all’anno scorso va ripensato da capo.
L’illusione della normalizzazione
Nel 2025 la competizione era un’altra cosa. Il team hforest aveva vinto il Task 2 completandolo in 105 secondi, mentre gli stessi Crusty Coders si erano fatti notare per una tecnica di quantizzazione a 2 bit chiamata Equi-Voronoi Polytopes. Erano soluzioni ingegnose, tarate su un problema ben definito: dataset di dimensioni contenute e vettori normalizzati, dove la distanza euclidea e il prodotto scalare raccontavano la stessa storia. La geometria era pulita, i grafi si costruivano con relativa prevedibilità.
Il salto del 2026 sta tutto in due scelte tecniche della commissione SISAP. Primo: i dataset sono più grandi. Secondo, e molto più rilevante: i vettori su cui bisogna lavorare — feature estratte da Llama-3.2-8B a 1024 dimensioni — non sono normalizzati. Significa che il prodotto scalare non è più una proxy della distanza euclidea. Per un algoritmo che costruisce grafi basandosi sulla prossimità tra punti, è un problema concreto: due vettori con prodotto scalare elevato possono essere lontanissimi nello spazio, e due vicini geometrici possono avere prodotto scalare basso. I criteri di vicinato che guidavano la costruzione del grafo smettono di funzionare.
A questo si aggiunge un vincolo infrastrutturale niente affatto teorico: le submission vengono eseguite in container Docker con un limite di 8 vCPU e 24 GB di RAM su processore AMD EPYC 7F72. Non si può compensare con la forza bruta. Bisogna scegliere dove spendere ogni ciclo di calcolo.
L’ordinamento che viene prima del grafo
La risposta dei Crusty Coders ha un’impostazione controintuitiva. Invece di partire dalla costruzione del grafo e adattarlo in corsa ai vettori non normalizzati, introducono un passaggio preliminare: un ordinamento lineare dei dati tramite Fast Linear Assignment Sorting, o FLAS. Prima ancora di pensare ai collegamenti tra nodi, i vettori vengono disposti lungo una dimensione. Solo dopo, su quella base ordinata, entra in gioco il Dynamic Exploration Graph (DEG), l’algoritmo che il gruppo aveva già introdotto nel 2023 e che qui viene adattato al nuovo scenario.
Perché ordinare prima di connettere? Il punto è che in uno spazio non normalizzato la nozione di “vicino” diventa ambigua. Due embedding di Llama-3.2-8B possono essere simili per prodotto scalare ma distanti in norma, oppure vicini in norma ma con orientamenti divergenti. Un grafo costruito senza pre-ordinamento rischia di creare scorciatoie fuorvianti: collegamenti che sembrano promettenti in base al prodotto scalare ma che portano in zone dello spazio irrilevanti per la query. FLAS impone un ordine di visita che mitiga questa ambiguità, dando al DEG una struttura più stabile su cui lavorare.
Il paper descrive il meccanismo in dettaglio tecnico, ma l’intuizione di fondo è accessibile anche a chi non mastrica algebra lineare: se non puoi più fidarti della geometria implicita dei tuoi dati, devi costruire tu una struttura esplicita prima di tentare qualsiasi indicizzazione. È un cambio di filosofia che sposta il costo computazionale dalla fase di query a quella di pre-processing — una scelta sensata se il pre-processing è soggetto ai limiti di 8 vCPU e 24 GB di RAM ma può essere eseguito una volta sola, mentre le query arrivano a ripetizione.
Cosa cambia per chi fa ricerca su larga scala
La SISAP è una competizione accademica, ma il problema che mette sul tavolo è tutt’altro che accademico. Chiunque gestisca motori di ricerca vettoriale nel mondo reale — dai sistemi RAG per chatbot alle raccomandazioni di prodotti — ha a che fare con embedding non normalizzati molto più spesso di quanto i benchmark tradizionali lascino credere. I modelli più usati oggi, da Llama a BGE-M3 (anche questo nella competizione, per il Task 1), producono vettori la cui norma non è costante. La domanda che i Crusty Coders pongono, in modo indiretto, è: ha senso continuare a ottimizzare algoritmi che funzionano solo nell’ipotesi semplificata di vettori normalizzati, quando i dati reali non lo sono quasi mai? La loro scommessa è che un pre-ordinamento lineare possa restituire robustezza a un grafo pensato per un mondo geometricamente più ordinato di quello in cui operiamo.
Con la SISAP che spinge verso scenari sempre più aderenti alla realtà dei dati, chi costruisce motori di ricerca vettoriale oggi si trova davanti a una scelta che non è solo tecnica: continuare a investire su architetture pensate per vettori normalizzati, sperando che il pre-processing a monte uniformi le norme quanto basta, oppure accettare il disordine e progettare indici che ci convivano fin dall’inizio. I Crusty Coders hanno già scelto.
