Le tabelle che non esistevano

Capitolo 2 — Le tabelle che non esistevano

Un tecnico di una ditta meccanica del Nord-Est ce lo ha raccontato davanti a un espresso, con quella calma dei veneti che prelude a un disastro: "Il nostro chatbot sapeva tutto del motore. Tranne i dati del motore." Poi ha spiegato. Il loro assistente AI interno sapeva descrivere le gamme di prodotto, i contesti d'uso, la storia del marchio, i vantaggi competitivi. Una meraviglia, sul piano narrativo. Ma quando un cliente domandava la coppia nominale del modello CMP50L — cioè il dato tecnico per cui la gente apre il catalogo, il numero per cui si compra un motore — il chatbot rispondeva in modo vago, a volte plausibile, a volte no. Cinque mesi di sviluppo, il direttore operativo sempre più perplesso, e nessuno che sapeva dire il perché.

La diagnosi è arrivata per caso, quasi per noia, ispezionando a mano il database dopo l'ennesima riunione senza conclusione. Il catalogo PDF conteneva 342 tabelle tecniche. Nel database ne erano arrivate zero. Non una manciata: zero. Nessuna. Il codice che estraeva le tabelle dai PDF salvava i dati in campi chiamati columns e data, mentre il codice che poi le indicizzava si aspettava campi chiamati headers e rows. Un "sinonimo" non rispettato. Una convenzione interna che era saltata in un refactoring dimenticato. Il risultato, per cinque mesi silenziosi: l'intera intelligenza numerica del catalogo — coppie, potenze, diametri, pesi, codici di ordinazione, tensioni di alimentazione — era uscita dal rubinetto senza essere mai versata nel bicchiere. Trecentoquarantadue tabelle, perse una per una in silenzio liturgico.

Questo è il tipo di bug che non grida. Non solleva eccezioni, non fa crashare niente, non appare in nessun log. Semplicemente, una parte del mondo cessa di esistere per il tuo sistema, e nessuno se ne accorge finché un utente — di solito un utente arrabbiato — non pone abbastanza domande ostinate da mostrare la voragine. Ed è emblematico di un problema molto più grande dei nomi dei campi: i framework RAG generici sono ottimizzati per il testo corrente — articoli, pagine web, paragrafi di narrativa — e trattano le tabelle come cittadini di seconda classe, quando le trattano. Ma i documenti aziendali italiani sono spesso tabelle. Cataloghi tecnici, listini prezzi, specifiche prodotto, schede di sicurezza, bollettini di ordinazione: la parte preziosa, per chi consulta questi documenti, è quella tabellare. Quella che si rompe per prima e di cui nessuno si accorge.

La lezione non è "stai attento ai nomi dei campi". È più scomoda: in un RAG serio, ogni tipo di contenuto — tabelle, immagini, codici alfanumerici, titoli di paragrafo, note a piè di pagina — ha bisogno di un trattamento dedicato, progettato, testato. E il test di funzionamento non è "il chatbot risponde a domande banali" — a quelle rispondono anche i sistemi rotti, perché ci sono abbastanza dati fluttuanti per costruire qualcosa di plausibile. Il test vero è "il chatbot risponde a domande che lo costringono a toccare ogni singolo pezzo della pipeline". Domande specifiche, numeriche, verificabili. Domande per cui esiste una risposta giusta e una sola, e se il sistema sbaglia lo sai subito.

Se questo test non lo fai, non sai se il tuo RAG funziona. Sai soltanto che non si lamenta. E "non si lamenta" è un criterio di qualità molto basso per un sistema che le persone useranno per prendere decisioni.