← Torna agli articoli
Quando l'AI aziendale non sa quello che sa Capitolo 4 di 6
AI 16/04/2026 ProtoMedia

L'allucinazione ereditata

Capitolo 4 — L'allucinazione ereditata

Questa è forse la storia più istruttiva dell'intera inchiesta, perché tocca un tema che i tutorial ignorano e che invece fa più danni di tutti gli altri messi insieme: la qualità dei dati che entrano.

Un'azienda americana di biciclette — chiamiamola così per rispetto — aveva un archivio fotografico enorme, migliaia di immagini di prodotto, eventi, clienti in sella, viaggi promozionali. Era il patrimonio visivo dell'azienda, accumulato in quindici anni di campagne. In un momento di lungimiranza, qualcuno aveva usato un servizio di tagging automatico per aggiungere, a ogni foto, una lista di "oggetti presenti": "bici, casco, strada, montagna, persona". Metadati utili, in teoria, per la futura ricerca visuale. Archiviati accanto alle foto, dimenticati per anni, poi recuperati e ingeriti nel nuovo RAG aziendale con la naturale convinzione che "più metadati, meglio è".

Dopo l'ingestione, la ricerca per immagini dava risultati surreali. Cercavi "bici in città" e ti usciva una foto di un lago. Cercavi "modello donna con casco" e ti usciva un'auto d'epoca. Cercavi "montagna" e ti usciva, indistintamente, qualunque cosa — un campionario casuale dell'intero archivio, come se il sistema avesse tirato a sorte. Il team, inizialmente, ha puntato il dito contro il modello di embedding visuale. Poi contro il reranker (vedi capitolo precedente, per capire perché questa pista fosse particolarmente seducente). Poi contro la qualità delle descrizioni generate dall'AI.

L'indagine vera, fatta questa volta con un query SQL diretto al database, ha mostrato una cosa grottesca. Di 3997 foto del catalogo, tutte, ma proprio tutte, avevano la stessa identica lista di oggetti. Una lista di diciannove elementi — "auto, moto, lago, mare, montagna, bici, casco, strada, città, persona..." — che non aveva nessuna relazione con il contenuto della singola foto. Era stata importata, anni prima, da un altro sito web, come set di tag generici per riempire un campo obbligatorio del CMS. Nessuno, in azienda, se ne ricordava più. Le foto erano passate di sistema in sistema portandosi dietro quelle etichette fantasma, plausibili abbastanza da non destare sospetti, velenose abbastanza da corrompere ogni ricerca basata su di esse. Il motore di ricerca, diligente, le utilizzava come sintomo di contenuto. E restituiva qualunque foto per qualunque query, con un certo grado di allucinazione garantito per legge di natura.

Il punto duro, quello che fa male quando lo si capisce, è che in un RAG i dati "rumorosi" non fanno rumore che si senta. Non rallentano il sistema, non generano errori, non accendono spie. Si limitano a erodere silenziosamente la qualità dei risultati. E quando il modello linguistico a valle riceve cinque documenti di cui quattro fuori tema, non ti dice "questi non c'entrano, chiedimi qualcos'altro": costruisce diligentemente una risposta che li mescoli, e la risposta suona sempre plausibile. Sempre. L'allucinazione finale — quella risposta inventata di cui ci si lamenta — non nasce dal modello, come è raccontata nella narrativa dominante. Nasce a monte, dai dati. Il modello è solo chi la confeziona in una frase grammaticalmente impeccabile. Ma la colpa è altrove, più indietro, in quello che hai dato da mangiare al sistema mesi prima di chiedergli qualcosa.

Questa osservazione ha conseguenze pratiche che costano soldi. Il primo lavoro di chi costruisce un RAG aziendale serio, prima di scrivere una riga di codice, è fare l'autopsia dei propri dati. Da dove vengono. Chi li ha toccati. Quali campi sono osservati e quali sono eredità fossili di sistemi precedenti. Quali metadati hanno significato oggi e quali lo avevano nel 2017 e nessuno si è più preso la briga di ripulirli. È un lavoro poco glamour, molto archivistico, completamente assente dai tutorial, spesso percepito come "non tecnico" e quindi snobbato dalle squadre di sviluppo. Ma senza quell'igiene iniziale, qualunque architettura geniale tu metta a monte diventa semplicemente un amplificatore molto potente di spazzatura molto vecchia.

Nel caso dell'azienda americana, la soluzione è stata brutale e giusta: svuotare il campo "oggetti", ricostruire i metadati a partire da zero con un modello di visione moderno applicato a ogni singola foto, e tenere traccia, questa volta, di quando e come ogni metadato è stato prodotto. Lavoro noioso. Risultato: la ricerca ha finalmente iniziato a funzionare. Non perché avessero cambiato modello. Perché avevano fatto pulizia in cantina.

La lezione in breve: Prima di scrivere una riga di codice, fai l'autopsia dei tuoi dati. Senza quell'igiene iniziale, qualunque architettura diventa un amplificatore di spazzatura.

Hai un'osservazione? Scrivici

Il messaggio arriva solo a noi. Se il tuo commento è interessante potremmo pubblicarlo in fondo all'articolo, ma solo dopo averlo valutato.