Dimenticate le Keywords: perché la ricerca vettoriale è il cervello di G.I.N.O. (e perché ho scelto HNSWLib)

 

C’è un momento, quando si costruisce un sistema che deve rispondere davvero alle domande, in cui la ricerca per keyword smette semplicemente di funzionare. Non perché sia sbagliata. Ma perché è letterale. E la lingua, soprattutto quella amministrativa e normativa, non lo è mai.

Se un utente chiede “quanto mi ridanno per il dentista” e il regolamento parla di “spese odontoiatriche”, il fallimento non è tecnico. È concettuale. Le parole non coincidono, il significato sì. Ed è proprio questo scarto, minimo ma sistematico, che rende inutilizzabile un motore basato su match testuali.

La ricerca vettoriale entra qui. Non come ottimizzazione. Come cambio di modello mentale.

Il mio progetto di interrogazione dati ( fino a 50.000 pagine ), che per semplicità chiamero' G.I.N.O.,  legge un documento, non conserva parole. Produce rappresentazioni. Ogni frase viene trasformata in un vettore numerico attraverso un modello di embedding. Nel mio caso quello di Google Gemini, ma il punto non è il provider. Il punto è l’operazione: comprimere significato in geometria.

Un vettore non “dice” nulla. Sta. Occupa una posizione in uno spazio ad alta dimensionalità. E quella posizione è determinata dalla semantica del testo. Concetti simili finiscono vicini. Concetti lontani si separano naturalmente. Dentista e odontoiatra diventano prossimi. Rimborso e copertura si riconoscono. Non perché qualcuno lo ha deciso, ma perché il linguaggio funziona così.

La ricerca, a questo punto, non è più una scansione. È una misura di distanza.

Questo è il motivo per cui la vector search non è un accessorio dei sistemi RAG. È la loro memoria operativa. Senza, la generazione è cieca. Con, diventa contestuale.

Il problema successivo non è teorico. È architetturale.

Per interrogare vettori servono indici dedicati. I database tradizionali non sono progettati per questo tipo di spazio. Negli ultimi anni sono emerse diverse soluzioni, ognuna con una visione implicita su scala, complessità e deployment.

FAISS è il riferimento storico. Nato in casa Meta, è pensato per volumi enormi e ottimizzazione estrema. Ma richiede competenze, tuning e infrastruttura. È una soluzione da laboratorio o da big tech. Non da applicazione installabile con un comando.

ChromaDB ha semplificato molto l’accesso alla vector search. Ottimo supporto ai metadati, API amichevoli, integrazione rapida. Ma introduce un servizio separato, un ciclo di vita proprio. In un ecosistema Node.js, questo dettaglio pesa più di quanto sembri.

Qdrant è probabilmente la scelta più solida per un SaaS vettoriale. Scritto in Rust, stabile, performante, con filtri avanzati. Ma è un sistema. Richiede container, configurazione, persistenza gestita. Ottimo se stai costruendo una piattaforma. Eccessivo se stai costruendo uno strumento.

G.I.N.O., aveva un vincolo chiaro: zero infrastruttura aggiuntiva. Nessun servizio esterno obbligatorio. Nessuna complessità nascosta per chi installa.

È qui che entra HNSWLib.

HNSWLib non è un database. È un’implementazione efficiente di un’idea: gli spazi semantici possono essere navigati come reti stradali. Autostrade per muoversi velocemente tra regioni lontane. Strade locali per affinare la ricerca. Il risultato è una ricerca approssimata, ma estremamente veloce, che nella pratica è indistinguibile da una esatta per dataset medio-piccoli.

La scelta è stata conseguenza diretta del contesto. Poche migliaia di documenti. Necessità di risposte immediate. Deployment semplice. Persistenza su file. Tutto ciò che un sistema di assistenza reale richiede, e che spesso viene sacrificato in nome di un’architettura “enterprise”.

HNSWLib gira in memoria, nello stesso processo dell’applicazione. L’indice si salva su disco come una cartella. Il backup è banale. L’avvio è immediato. La latenza è trascurabile.

C’è un compromesso. La cancellazione dei dati non è elegante. Gli indici HNSW non amano essere smontati pezzo per pezzo. Ma anche questo è un problema solo se si insiste a trattarlo come un database tradizionale.

In G.I.N.O., quando un documento viene rimosso, l’indice viene rigenerato in background. È un’operazione veloce, silenziosa, proporzionata alla scala. Non serve gestire stati intermedi, tombstone o processi di compattazione. Serve accettare che semplicità e controllo spesso valgono più della flessibilità teorica.

La lezione, alla fine, non riguarda HNSWLib. Riguarda il modo in cui pensiamo la ricerca.

Finché cerchiamo parole, otteniamo corrispondenze. Quando iniziamo a cercare significati, otteniamo risposte. La ricerca vettoriale non migliora l’esperienza. Cambia il tipo di sistema che stiamo costruendo.

E quando un utente chiede se uno scontrino è rimborsabile, e ottiene una risposta sensata, non è magia. È geometria applicata al linguaggio.