Allucinazioni LLM: spesso il retrieval è il problema

Tempo fa ho costruito una versione AI di me stesso su Slack con RAG, Pinecone, n8n e OpenAI. Il modello non era la parte difficile. La parte difficile era decidere che cosa fosse davvero conoscenza recuperabile: come spezzare le note in chunk, quali tag usare, come gestire contesto vecchio, e che cosa dovesse fare l’assistente quando la ricerca restituiva qualcosa di plausibile ma incompleto.

Da allora leggo molte “allucinazioni” degli LLM in modo diverso. Alcune sono comportamento del modello. Molte altre partono prima. La risposta fallisce perché il modello vede la prova sbagliata, metà della prova, o nessuna prova, e viene comunque invitato a rispondere.

Per questo considero il retrieval una superficie di prodotto, non solo un layer tecnico. Un contratto di retrieval deve chiarire che cosa il sistema può recuperare, come si valuta la fiducia e quando l’assistente deve rifiutare, fare una domanda o mostrare incertezza.

Cosa si rompe prima della risposta?

Il problema spesso nasce da un’assunzione silenziosa: se il documento è da qualche parte nel vector database, allora il sistema “lo sa”. In produzione non funziona così.

Un sistema RAG deve decidere quali documenti entrano nell’indice, quali chunk hanno abbastanza significato, quali metadati contano, quali filtri sono obbligatori e quanto contesto arriva al modello. Ognuna di queste scelte può distorcere la risposta prima ancora della generazione.

Se il chunk è troppo piccolo, il modello riceve frammenti senza il contesto decisionale intorno. Se è troppo grande, la frase rilevante può perdersi dentro un blocco troppo ampio. Se i metadati sono deboli, il sistema può recuperare un buon paragrafo dal cliente sbagliato, dal mercato sbagliato, da una versione prodotto superata o da una policy non più valida.

La risposta finale sembra fluida, ma la prova a monte era già compromessa.

Perché la ricerca vettoriale non basta?

La ricerca vettoriale è utile perché trova somiglianza semantica. Ma somiglianza non significa verità, ownership, freschezza, permesso o rilevanza operativa.

Nella conoscenza aziendale reale, la risposta giusta dipende spesso da relazioni e vincoli. Una nota sales può citare una feature, ma la fonte di verità può essere la roadmap. Un ticket di supporto può contenere un workaround, ma la regola stabile può vivere in una policy. Una citazione cliente può essere valida solo per un segmento. Un workflow può dipendere da chi possiede l’eccezione.

Ecco perché un approccio solo vettoriale può recuperare qualcosa che sembra vicino, ma manca la struttura che lo rende corretto. Lo stesso tema ritorna quando scegli RAG o CAG come decisione operativa: l’architettura conta, ma conta ancora di più il contratto su prove, latenza e ripetibilità.

La domanda pratica non è “la ricerca ha trovato un risultato?”. La domanda è: ha trovato la prova giusta per questa decisione, con i vincoli corretti e abbastanza contesto per non fingere?

Cosa indica AkasicDB?

Il lavoro di KAIST e GraphAI su AkasicDB mi interessa perché va in questa direzione. Il comunicato della ricerca descrive un sistema che integra retrieval vettoriale, grafo e database relazionale in un unico query plan, collegato a una demo SIGMOD con DOI. I numeri dichiarati, inclusa la riduzione delle allucinazioni, vanno letti con prudenza: è ricerca, non una garanzia di prodotto.

La direzione però è sensata. La conoscenza aziendale non è solo semantica. È anche relazionale e strutturata. I clienti appartengono ad account. Gli account appartengono a segmenti. Le policy hanno date. Le decisioni prodotto hanno owner. Le metriche hanno definizioni. I permessi contano.

Quando queste dimensioni vivono in sistemi separati, l’applicazione deve ricucirle dopo il retrieval. Proprio lì molti sistemi RAG diventano fragili: recuperano un chunk semanticamente plausibile e chiedono al modello di compensare la struttura mancante.

Quale checklist serve in produzione?

Per me la checklist minima è operativa, non accademica.

Primo: ogni fonte recuperabile deve avere owner, data, ambito e regole di freschezza. Se nessuno possiede la fonte, il modello non dovrebbe trattarla come verità durevole.

Secondo: l’assistente deve avere una policy di fallback. Quando la prova è debole, deve dirlo. Un RAG senza comportamento di rifiuto è una macchina di sicurezza apparente.

Terzo: il retrieval va testato. Non solo prompt test, ma test sulle prove: data questa domanda, quale fonte deve essere recuperata, quale fonte deve essere esclusa, e quale risposta deve essere impossibile senza più contesto? È vicino al problema di governance che ho descritto parlando di workflow n8n in produzione: il workflow non è finito quando gira, è finito quando le eccezioni sono visibili e hanno un owner.

Quarto: quando una risposta fallisce, il team dovrebbe guardare prima il layer di retrieval. Mancava la fonte? Il chunk era sbagliato? I metadati erano assenti? Serviva una relazione? Il modello è stato spinto a rispondere anche con prove sottili?

Dove essere prudenti?

Non trasformerei un paper o un benchmark in una decisione di acquisto. La lezione utile è più stretta: la qualità del retrieval non è un dettaglio backend. È parte della promessa fatta all’utente.

La guida OpenAI al retrieval è un buon promemoria: servono selezione dei file, comportamento di ricerca e configurazione degli strumenti, non solo prompting. Vale anche fuori da OpenAI. Se l’assistente può toccare la conoscenza aziendale, il team deve decidere che cosa significa “conoscere”.

Quindi, quando un LLM allucina dentro un prodotto RAG, provo prima a farmi una domanda più fredda: il modello ha inventato qualcosa, o gli abbiamo consegnato la stanza sbagliata chiedendogli di descrivere tutto l’edificio?