Il motore che aveva sei poli — Il mito delle dieci righe di codice

Inchiesta in sei puntate sui motivi per cui il chatbot documentale che ti hanno venduto continua a inventare — e sulla direzione diversa che, all'inizio del 2026, qualcuno ha iniziato a percorrere.

Inchiesta in sei puntate sui motivi per cui il chatbot documentale che ti hanno venduto continua a inventare — e sulla direzione diversa che, all'inizio del 2026, qualcuno ha iniziato a percorrere.

Intro — Il motore che aveva otto poli (ma ne aveva sei)

Milano, marzo 2026. Un manager apre il chatbot aziendale interno, di quelli montati "in due settimane" dall'ufficio IT con grande entusiasmo e scarsa diffidenza. Domanda semplicissima: "Quanti poli ha il motore CMP40M?". Il chatbot risponde con tutta la sicurezza che i grandi modelli linguistici sanno esibire: "Il motore CMP40M ha otto poli."

Sbagliato. Ne ha sei. La risposta giusta non stava nel catalogo da 422 pagine che qualcuno, mesi prima, aveva versato con la massima fiducia dentro un database vettoriale, convinto che da lì in poi il sistema "avrebbe saputo tutto". Quel dato, nel catalogo, non c'era proprio. Stava in un PDF allegato a un'email dei tecnici SEW, archiviata in una cartella che nessuno si era preso la briga di indicizzare.

Questa scena, con variazioni di settore e di dialetto, si ripete in centinaia di uffici italiani. La promessa era semplice e seducente: date al vostro assistente AI tutti i documenti aziendali, e potrà rispondere a qualunque domanda su di essi. La realtà è molto più prosaica: il chatbot legge ma non capisce, cerca ma non trova, e quando non trova — invece di dirlo — inventa. Inventa con fluidità, con grammatica perfetta, con numeri plausibili. Il che è molto peggio del non rispondere.

Tra la fine del 2024 e l'inizio del 2026 abbiamo passato mesi a fare l'autopsia di questi fallimenti. Non per alimentare polemiche, ma per capire una cosa: perché un'idea tanto lineare — "dagli i documenti e poi chiedigli cose" — diventi così difficile quando esce dal palcoscenico della demo ed entra nella stanza dei server veri.

Questa inchiesta in sei capitoli racconta quello che abbiamo trovato: bug silenziosi che cancellavano interi cataloghi, reranker cloud con i punteggi sbagliati, allucinazioni nate non dal modello ma da dati contaminati anni prima, bollette in uscita che rendevano ogni query più cara del suo valore, e framework "popolari" che promettono tutto in dieci righe di codice a patto che non gli si chieda troppo. E nell'ultimo capitolo, la direzione diversa che qualcuno, in silenzio, ha iniziato a percorrere all'inizio del 2026 — un'architettura in cui la strategia di ricerca smette di essere codice e diventa un documento che chiunque, in azienda, può leggere e modificare.

Ogni capitolo regge da solo. Se vuoi cominciare dalla storia delle 342 tabelle sparite, o da quella del reranker bugiardo, sei libero di farlo. Ma il racconto nel suo insieme ha una morale che emerge solo alla fine: il RAG aziendale — quell'acronimo tecnico che sta per Retrieval-Augmented Generation, cioè "genera risposte basandoti su documenti che recuperi prima" — non è ancora un prodotto finito. È una frontiera. E come tutte le frontiere, finora è stata raccontata soprattutto dai venditori. È tempo di ascoltare anche chi ci ha vissuto dentro.

Capitolo 1 — Il mito delle dieci righe di codice

La slide è identica in ogni conferenza sull'AI dal 2023 in poi: "Il tuo assistente documentale aziendale in 10 righe di codice." Sotto il titolo, un blocco di Python in colori pastello che mostra una libreria open source — tipicamente una di quelle celebri americane, il cui nome evoca catene di alberi o lama tibetani — che carica PDF, li spezzetta, li incolla dentro un database vettoriale e li interroga con un modello linguistico. In cinque minuti, hai un chatbot. In cinque minuti, gli applausi. In cinque minuti, un'azienda italiana di medie dimensioni si convince che il problema è risolto e che il suo reparto IT può farcela in due settimane.

Il problema — quello che la slide non dice — è che la demo è costruita con tre PDF ben formati, una domanda cucita addosso per combaciare con il contenuto, un palcoscenico senza latenze reali, e un presentatore che ha provato il tutto ventisette volte prima di salire. Nella realtà, i documenti aziendali sono un disastro geologico: scansioni di scansioni, tabelle che si sovrappongono al testo, note a piè di pagina che si infilano nei paragrafi, codici alfanumerici tipo "RH1M" che il chunker taglia a metà credendoli parole, immagini che contengono il settanta percento dell'informazione utile ma che nessuno estrae davvero, e layout così creativi da richiedere un archeologo più che un parser.

Il RAG — questa è l'idea sotto il cofano — è un'ottima idea. Prendi la domanda dell'utente, cerca nel tuo archivio i documenti più pertinenti, passali al modello linguistico e fatti dare una risposta fondata su quei documenti. In teoria, risolve elegantemente il problema dell'allucinazione: il modello non deve più "sapere" la risposta, deve solo "leggerla" nei pezzi che gli hai fornito. In pratica, ogni anello della catena — il chunking, l'embedding, il retrieval, il reranking, la generazione finale — ha i suoi modi di rompersi, e la rottura raramente si manifesta come un errore visibile. Si manifesta come una risposta leggermente sbagliata. Poi come una risposta completamente sbagliata. Poi come un manager che si chiede perché sta pagando per un sistema che sa meno del tirocinante.

I framework open source che hanno reso popolare il RAG sono fatti per dimostrare, non per produrre. Sono concatenazioni elegantissime di astrazioni in cui ogni strato nasconde un'assunzione non detta: che i tuoi PDF abbiano un'OCR decente, che le tue foto siano già state descritte, che le tue tabelle seguano una convenzione, che il modello di embedding parli davvero la tua lingua (spoiler: molti parlano bene solo inglese), che il tuo archivio sia già stato ripulito di duplicati. Quando una di queste assunzioni salta — e almeno una salta sempre, quasi sempre tre — il sistema non smette di funzionare. Peggio: smette di funzionare bene, ma continua a dare risposte. Risposte fluide, sicure, e spesso scollegate dalla verità.

C'è una frase che circola tra chi questi sistemi li costruisce per mestiere, e che nei tutorial non leggerete mai: "il RAG è facile da fare, e difficile da fare bene." Tra il primo demo e il servizio in produzione c'è un abisso che non si colma aggiungendo GPU o cambiando modello. Si colma capendo una cosa scomoda: quando costruisci un RAG aziendale non stai scrivendo codice. Stai progettando un piccolo, ostinato motore di ricerca su misura per i tuoi documenti, con tutte le scelte editoriali che questo comporta — cosa è rumore, cosa è segnale, cosa va indicizzato due volte, cosa va buttato. Solo che nei tutorial in dieci righe queste scelte sono prese al posto tuo, una volta, da qualcuno che non ha mai visto i tuoi documenti. E sono quasi sempre quelle sbagliate per il tuo caso.