GARBAGE IN, GARBAGE OUT
Perché i RAG aziendali non mantengono quello che promettono
C’è un momento preciso in cui si capisce che qualcosa non ha funzionato. Non è quando il sistema restituisce una risposta sbagliata, quello lo vedi subito. È quando restituisce una risposta plausibile, basata su un documento che l’azienda aveva scartato tre anni prima.
Ho visto succedere questa cosa più volte, in contesti diversi. Un legale che chiede chiarimenti su una clausola contrattuale e riceve una sintesi tecnicamente corretta, riferita però a una bozza mai entrata in vigore. Un controller che interroga i dati finanziari e ottiene un’analisi coerente, costruita su un foglio di lavoro preliminare datato sei mesi prima della versione approvata dal CDA. In entrambi i casi, il sistema non ha sbagliato nel senso tecnico del termine. Ha fatto esattamente quello che gli era stato chiesto. Il problema era a monte.
La premessa che ha convinto tutti
L’idea alla base del RAG, la Retrieval-Augmented Generation, è elegante nella sua semplicità. Invece di addestrare un modello sui dati aziendali, operazione costosa e rapidamente obsoleta, gli si dà accesso a un archivio di documenti proprietari che interroga in tempo reale prima di rispondere. Il modello smette di essere un oracolo generico e diventa, almeno in teoria, un esperto del contesto specifico dell’organizzazione.
I vendor hanno venduto bene questa promessa. Nei Proof of Concept spesso funzionava. Il passaggio in produzione è dove le cose si sono complicate.
Il problema non è il modello
La disillusione che oggi si respira in molte aziende viene attribuita ai limiti dei Large Language Model. Le allucinazioni. La mancanza di affidabilità. Il fatto che “inventa cose”.
È una lettura parziale, e in buona parte sbagliata.
Quando un sistema RAG restituisce informazioni obsolete o fuorvianti, il più delle volte non sta inventando nulla. Sta recuperando esattamente quello che c’è nell’archivio. E nell’archivio c’è tutto: bozze di contratti mai approvate, presentazioni interne di tre anni fa, appunti di riunione scritti a caldo pieni di ipotesi e numeri provvisori, documenti ufficiali validati e firmati. Tutto insieme, senza gerarchia, senza distinzione.
Per il sistema, questi documenti hanno la stessa autorità. Un contratto firmato pesa quanto un draft inviato per commenti informali. Una policy approvata dal CDA ha lo stesso peso di una proposta che non è mai passata in approvazione.
Il risultato non è un’allucinazione tecnica. È qualcosa di più sottile e più pericoloso: una risposta statisticamente coerente con i dati ingeriti, ma operativamente disastrosa rispetto alla realtà aziendale corrente.
Un archivio senza gerarchia non è una knowledge base. È un deposito.
Il problema del chunking
I documenti aziendali non vengono ingeriti interi. Per ragioni legate alla gestione della memoria e dei costi computazionali, i sistemi RAG spezzano i file in blocchi, chunk, da qualche centinaio di token ciascuno. Per testi narrativi lineari il danno è limitato. Per la documentazione aziendale tipica, tabelle finanziarie, schemi contrattuali, specifiche tecniche, il danno può essere significativo.
Una tabella di budget tagliata nel mezzo perde la correlazione tra righe e intestazioni di colonna. Un contratto suddiviso in frammenti perde il filo logico tra le clausole. Il sistema recupera i chunk più rilevanti semanticamente, ma non necessariamente i più contestuali. La risposta può essere composta da pezzi corretti che, assemblati, producono una lettura distorta.
L’espansione delle finestre di contesto, oggi i modelli più avanzati possono gestire milioni di token in una singola sessione, sembra risolvere il problema in teoria. In pratica, inviare interi archivi documentali a ogni query comporta costi e latenze incompatibili con un uso operativo quotidiano.
Quello che manca nell’infrastruttura
Se si guarda ai RAG che non funzionano come dovrebbero, il problema raramente è il modello linguistico o la qualità degli embedding. Il problema è quello che succede prima, nella fase di ingestione dei dati.
Due elementi, in particolare, sono quasi sempre assenti.
Il primo è una gerarchia documentale esplicita. Non tutti i documenti hanno la stessa autorità: un contratto firmato supera una bozza, una policy approvata supera una proposta, una delibera CDA supera un verbale preliminare. Questa gerarchia esiste nella testa di chi lavora in azienda. Raramente viene codificata nell’infrastruttura che gestisce i dati.
Il secondo è un filtro sulla validità del documento prima dell’ingestione. La domanda che nessun sistema pone automaticamente: questo documento è ancora valido? È una versione finale o una bozza? È stato superato da una versione successiva? In assenza di un processo di validazione pre-ingestion, l’archivio cresce e incorpora tutto, incluso quello che l’azienda, di fatto, non considera più vero.
Quello che rimane
Il problema dei RAG aziendali non è un problema di intelligenza artificiale. È un problema di architettura dell’informazione, e in parte esiste nelle aziende da molto prima che l’AI entrasse in scena.
Le organizzazioni hanno sempre prodotto più documenti di quanti riuscissero a gestire. Hanno sempre convissuto con versioni diverse della stessa cosa. L’AI non ha creato questo disordine: lo ha reso operativo. Ha trasformato il rumore di fondo in input attivo per i sistemi decisionali.
La differenza è che adesso il disordine risponde alle domande.
E risponde con sicurezza.
Questo articolo è stato prodotto con l’AI. Le osservazioni, le scelte editoriali e la responsabilità del contenuto sono dell’autore.”
Sergio Caniatti - Creator & Architect, UBcore OS