La geometria del pensiero: perché la ricerca semantica da sola non basta


“Il linguaggio è la casa dell'essere”
Martin Heidegger

C'è una domanda che chiunque costruisca sistemi di recupero dell'informazione prima o poi deve affrontare, non sul piano tecnico, ma su quello epistemologico. Quando una macchina cerca, cosa sta cercando? Cerca una parola? Cerca un concetto? Cerca un'intenzione? Cerca un fatto registrato in una tabella? La risposta a questa domanda determina tutto: l'architettura del sistema, la qualità dei risultati, il modo in cui la conoscenza viene restituita all'utente. E la storia di come il campo dell'information retrieval ha cambiato risposta nel corso degli ultimi decenni è, a tutti gli effetti, una storia filosofica mascherata da storia tecnica.

In VerdeLab ci siamo trovati a confrontarci con questa domanda in modo molto concreto e non solo durante la progettazione del sottosistema di ricerca di Labyrinthum. E il confronto ci ha portato molto lontano dal codice, fino alla morfologia, alla semantica distribuzionale, alla geometria dello spazio concettuale e alla logica relazionale dei dati strutturati. Vale la pena condividere questo percorso.

Il punto di partenza della storia è lo stemmer (Martin Porter, informatico e linguista britannico è famoso per aver inventato nel 1980 il Porter Stemmer, uno degli algoritmi più utilizzati al mondo per la lingua inglese). Chiunque abbia lavorato con motori di full-text search conosce questo strumento: un algoritmo che riduce ogni parola alla propria radice morfologica, o stem. "Correre", "corre", "corsa", "correndo" diventano tutti, in qualche misura, corr-. L'obiettivo è ovvio: se un documento parla di "gestione" e l'utente cerca "gestire", il motore deve comunque trovarlo. Lo stemmer è il meccanismo che rende possibile questa normalizzazione.

Ma se si guarda più da vicino a questo meccanismo, emerge qualcosa di preciso sul modo in cui il sistema pensa il linguaggio. Lo stemmer opera sul significante nel senso saussuriano: lavora sulla forma della parola, sulla sua superficie morfologica, con regole deterministiche che variano da lingua a lingua. È una grammatica riduzionista: ogni parola viene ricondotta al suo invariante flessionale e su quell'invariante vengono costruiti gli indici. Il risultato è un inverted index ovvero una mappa che dice: "questa radice compare in questi documenti, con questa frequenza". I motori BM25, costruiti su questa tradizione, sono trasparenti, efficienti, robusti. Per testi tecnici, giuridici, scientifici — dove la terminologia è specifica e la variazione lessicale è minima — funzionano con precisione notevole. Tuttavia il loro orizzonte è quello della forma. Lo stemmer non sa che "automobile" e "vettura" condividono un campo semantico, a meno che qualcuno non abbia costruito un thesaurus esplicito. Non sa che "entropia" nella termodinamica e "entropia" nella teoria dell'informazione abitano regioni concettuali distinte ma connesse. Non sa, soprattutto, che il significato di una parola non è una proprietà intrinseca della parola stessa: emerge dal contesto in cui la parola vive.

Quando si parla di LLM e di RAG, la parola "token" sembra a prima vista analoga allo stem: un'unità di testo su cui il sistema lavora. Ma la somiglianza è ingannevole. La differenza tra i due è una differenza di paradigma, anzi, di ontologia del linguaggio. Per capirlo, vale la pena entrare nei dettagli di un famoso algoritmo di tokenizzazione come WordPiece, che è alla base di BERT e di buona parte dei modelli di embedding più diffusi. WordPiece non taglia le parole lungo le cuciture morfologiche, come farebbe uno stemmer. Parte da ogni singolo carattere del corpus — ogni lettera, cifra, segno di punteggiatura — e costruisce iterativamente un vocabolario di sotto-parole fondendo le coppie che mostrano il legame statistico più forte. La parola "embedding", all'inizializzazione, viene vista come la sequenza di caratteri ['e', '##m', '##b', '##e', '##d', '##d', '##i', '##n', '##g'], dove il prefisso ## segnala che il frammento appartiene all'interno di una parola e non al suo inizio. Ma il criterio con cui WordPiece decide quali coppie fondere è ciò che lo rende concettualmente interessante e lo distingue dall'algoritmo concorrente BPE. Il Byte Pair Encoding seleziona semplicemente la coppia più frequente nel corpus, conta le occorrenze grezze e unisce la coppia che compare di più. WordPiece adotta invece un approccio probabilistico: per ogni potenziale coppia di token adiacenti A e B, calcola il rapporto

Score(A, B) = P(AB) / [P(A) · P(B)]

dove P(AB) è la frequenza relativa della stringa combinata e P(A) e P(B) sono le probabilità dei singoli frammenti presi isolatamente. Questo rapporto misura qualcosa di preciso: quanto la comparsa congiunta di A e B sia intenzionale rispetto al puro caso. Due token frequenti ma indipendenti — come "di" e "per" — avranno un denominatore enorme e uno score basso. Due frammenti che compaiono quasi esclusivamente uniti — come "neuro" e "scienze" — avranno uno score elevato, perché il loro legame è sistematico, non accidentale. Il vocabolario finale di BERT, costruito con questo processo iterativo, conta 30.522 token: non morfemi, non parole, non sillabe ma legami statistici cristallizzati. Questo ha una conseguenza epistemologica importante. Un token WordPiece non porta significato in sé: è un residuo del processo con cui il modello ha imparato a segmentare efficientemente la distribuzione delle stringhe testuali nel corpus di addestramento. Il significato emerge altrove, nello spazio degli embedding, dove l'intero chunk di testo viene proiettato in uno spazio vettoriale ad alta dimensione (tipicamente 768 o 1536 dimensioni) e la vicinanza geometrica codifica la prossimità semantica. L'intuizione profonda è quella che J.R. Firth formulò in una celebre sintesi: "You shall know a word by the company it keeps." Il significato non è nella forma, ma nell'uso, nelle co-occorrenze, nelle relazioni contestuali. Il vettore di embedding è una mappa compressa di queste relazioni e per questo riesce a fare ciò che lo stemmer non può: trovare un passaggio su "limiti della misura nella meccanica quantistica" partendo da una query sulle "implicazioni epistemologiche del principio di indeterminazione", senza che le parole si sovrappongano, perché i due frammenti abitano la stessa regione dello spazio semantico. Wittgenstein lo aveva intuito quando, nelle Ricerche Filosofiche, abbandonò la teoria del significato come riferimento a favore del significato come uso. Gli embedding sono, in qualche modo, la formalizzazione computazionale di quella svolta.

Ma ogni paradigma porta con sé i propri limiti strutturali. Lo stemmer fallisce nella prossimità concettuale, come abbiamo detto. Il puro retrieval vettoriale porta con sé un problema diverso, più sottile: la deriva semantica. Uno spazio ad alta dimensione è anche uno spazio pieno di prossimità spurie, un chunk recuperato può essere geometricamente vicino alla query pur essendo contestualmente irrilevante o fuorviante. La ricerca semantica ha un recall elevato ma una precisione che richiede disciplina. C'è poi un secondo problema specifico del RAG: l'asimmetria query-documento. Una domanda dell'utente e un paragrafo di un saggio che risponde a quella domanda vivono in regioni diverse dello spazio degli embedding, perché le query tendono ad essere brevi, ellittiche, idiomatiche, mentre i documenti sono elaborati, densi, terminologicamente precisi. Il vettore di una domanda e il vettore della sua risposta non coincidono necessariamente. È per questo che è stata sviluppata la tecnica HyDE (Hypothetical Document Embedding). Prima di cercare, il sistema genera una risposta ipotetica alla query usando un LLM e poi "embeda" quella risposta ipotetica. L'idea è elegante: usare il modello non per rispondere direttamente, ma per tradurre la domanda nel registro semantico in cui vivono le risposte, chiudendo l'asimmetria prima ancora di iniziare il retrieval. Il graph retrieval aggiunge un terzo livello: non più forma né distribuzione statistica, ma topologia del pensiero. Un grafo di conoscenza è una mappa dell'architettura intellettuale di chi ha costruito la base documentale. Attraversarlo durante il retrieval significa lasciare che quella architettura — sedimentata nel tempo dall'utente — guidi attivamente la ricerca, portando in superficie connessioni che nessuna similarità coseno potrebbe trovare perché non vivono nel testo, ma nella struttura delle relazioni tra i testi.

C'è tuttavia una forma di conoscenza che sfugge a tutti e tre questi livelli contemporaneamente. Consideriamo una domanda come: "Qual è l'ultimo libro che ho letto che mi è piaciuto di più?" Questa domanda non è semantica nel senso degli embedding. Non è morfologica nel senso degli stemmer. Non è topologica nel senso del grafo. La risposta non vive in nessun chunk testuale, vive nei campi strutturati di un database: date di lettura, valutazioni, metadati, categorie, stati. È conoscenza categoriale, organizzata in schemi relazionali, non in linguaggio naturale. E tuttavia è conoscenza pienamente legittima, anzi spesso la più rilevante per chi gestisce un archivio personale costruito negli anni. Per raggiungere questo quarto strato è necessario un meccanismo completamente diverso: la capacità di tradurre l'intenzione espressa in linguaggio naturale direttamente in una query formale sul database, generata a runtime dal motore LLM. Non una ricerca nei documenti, ma un'interrogazione dinamica della struttura relazionale capace di rispondere a domande statistiche, temporali, comparative, che presuppongono l'accesso ai metadati registrati nelle tabelle piuttosto che al contenuto indicizzato. Questo quarto canale chiude un cerchio epistemologico. La conoscenza umana non vive solo nel testo: vive anche nella struttura con cui organizziamo il testo, nei metadati che assegniamo, nelle relazioni che registriamo. Un sistema di recupero che ignora questo strato è un sistema che risponde bene alle domande su la conoscenza, ma non alle domande della conoscenza, quelle che emergono dall'interazione tra il proprio archivio, il proprio tempo, le proprie valutazioni.

Mettere insieme BM25, ricerca vettoriale, graph retrieval e SQL generativo non è una soluzione di compromesso. È, se si riconosce la profondità teorica di ciò che ciascuna tecnica fa, una scelta epistemologicamente fondata perché risponde a quattro livelli del linguaggio e della conoscenza che operano simultaneamente. BM25 è il guardiano della denotazione precisa: coglie il termine tecnico esatto, il nome proprio, la citazione verbatim. Il retrieval vettoriale è l'esploratore della connotazione distribuita: coglie il senso, l'intenzione, il campo concettuale. Il grafo è il cartografo della topologia intellettuale: segue le connessioni esplicite sedimentate nel tempo dall'utente. L'SQL generativo è l'interprete della struttura relazionale: traduce l'intenzione in interrogazione formale sui dati categoriali. La fusione dei ranking tramite RRF (Reciprocal Rank Fusion) per i primi tre canali non è un artificio statistico: è il riconoscimento che la pertinenza ha più dimensioni e che nessuna da sola è sufficiente. Il quarto canale opera su un piano diverso — non di ranking ma di interrogazione diretta — e porta nel perimetro del sistema un tipo di risposta che i canali testuali non potrebbero mai produrre.

In VerdeLab abbiamo percorso questo ragionamento fino in fondo prima di scrivere una riga di codice per il motore di Labyrinthum. La convinzione che guida il progetto è che un sistema di gestione della conoscenza personale degno di questo nome non può permettersi di scegliere un solo livello della conoscenza. Chi studia, chi ricerca, chi costruisce un corpus intellettuale nel corso degli anni ha bisogno che il sistema lo incontri su tutti i piani contemporaneamente: quando cerca una parola precisa, quando cerca un'idea di cui non ricorda il nome, quando vuole navigare le connessioni tra i propri appunti e quando vuole semplicemente sapere quale libro ha letto più di recente con un certo grado di soddisfazione. Costruire quel sistema ha richiesto, prima ancora che ingegneria, una teoria. E continuare a costruirlo richiede che quella teoria rimanga viva, aggiornata e interrogata perché ogni scelta architetturale è anche una scelta epistemologica e le scelte epistemologiche non dovrebbero essere prese per inerzia.


VerdeLab è una software house italiana che sviluppa soluzioni di AI e NLP dal 2003. Labyrinthum è il nostro sistema PKM per studiosi e ricercatori: knowledge management multimodale, retrieval ibrido a quattro canali, xAI nativa e sovranità totale sui dati. Scopri di più su verdelab.info/landinglabyrinthum.

Commenti

Post popolari in questo blog

Labyrinthum: come stiamo costruendo uno strumento per pensare meglio

Labyrinthum