… e il Database Corrotto

Avevo un file CSV con 20.341 dipendenti distribuiti su 90 aziende. Un dataset da Kaggle — dati HR sintetici di un sistema SaaS multi-tenant — che però è un piccolo museo degli orrori della data quality reale: date impossibili, dipendenti nati nell’anno 1 dopo Cristo, altri con data di nascita nel 2097, generi scritti in quattro lingue diverse, cancellazioni di massa con timestamp al secondo che tradiscono operazioni programmatiche invece di turnover fisiologico. L’ho dato in pasto a tre modelli diversi e ho chiesto di analizzarlo. Stessa domanda, stesso testo, tre trascrizioni diverse.

Ma prima di parlare dell’analisi, vale la pena fermarsi sul file. Gemini lo ha misurato: 1.039.759 token. Non un milione “circa” — un milione preciso, superato. E questo non è un dettaglio trascurabile, perché cambia completamente il senso dell’esperimento. Un CSV, a differenza di un romanzo o di un articolo, non ha ridondanza linguistica. In un testo narrativo, se il modello perde il filo per qualche migliaio di token, il contesto circostante aiuta a ricostruire — personaggi, trama, registro stilistico fungono da rete di sicurezza. In un CSV ogni riga è atomica: un record saltato è un record perso, un numero mancante non si recupera per inferenza. Il context rot su dati strutturati è probabilmente più rapido e più invisibile che su testo narrativo.

Chi ha lavorato con traduttori simultanei in conferenze tecniche lo sa: la resa è fedele finché il relatore va a ritmo normale e il testo è strutturato. Quando accelera, o quando arrivano i numeri in serie, o quando il documento è lungo e denso, qualcosa comincia a scivolare. Non i concetti principali — quelli reggono. Sono le cifre precise, i subordinati complessi, i dettagli che stanno a pagina dodici, che scompaiono o si approssimano. Il traduttore non mente: interpreta. Ma la distanza tra quello che ha sentito e quello che restituisce cresce in modo prevedibile e misurabile con la lunghezza e la densità del testo. La cabina dichiarata — “lavoro in sei lingue su qualsiasi documento” — non corrisponde alla cabina usabile sotto pressione reale.

I modelli di linguaggio a contesto lungo hanno lo stesso problema, e ha un nome: context rot. La finestra dichiarata non corrisponde alla finestra usabile.

DeepSeek ha prodotto un’analisi competente, ordinata, con un esempio ripetuto identico due volte nella stessa sezione — cosa che una seconda lettura avrebbe catturato, ma che rivela un modello che non ha riletto. Ha trovato le anomalie principali, le ha catalogate, le ha descritte. Non sbaglia. Non aggiunge niente che non fosse già visibile con attenzione. Probabilmente ha visto solo una parte del dataset — la più vistosa, quella in cima. È il traduttore che, stanco, riassume il senso generale e lascia perdere le tabelle.

Gemini ha fatto meglio. Ha identificato il “bug Y2K” — l’ipotesi che le date 0001-0008 in quella company specifica nascano da un errore di parsing su anno a due cifre: qualcuno ha digitato 06, il sistema ha letto anno 6 d.C. Non è una catalogazione, è un’inferenza causale. Ha trovato le cancellazioni di massa con timestamp al secondo e le ha riconosciute come operazioni programmatiche. Ha anche contato i token del file con precisione millimetrica. Poi si è fermato. I numeri aggregati che avrebbe dovuto produrre — quanti record totali, quante aziende, quante anomalie per tipo — mancano. Si comporta come un analista che “ha già visto questo film”: capisce che la macchina è montata male perché riconosce il rumore del motore, ma non conta i bulloni. La diagnosi è dei sintomi, non della patologia.

Opus 4.6 ha contato tutto.

Numeri precisi: 20.341 record, 90 aziende, 63% senza data di nascita, 62.5% senza data di assunzione, 35 viaggiatori nel tempo, 68 minorenni assunti, 461 fantasmi senza flag. La differenza tra “diverse aziende hanno pattern di cancellazione sospetti” e “119 dipendenti cancellati nello stesso giorno in una singola company, 97 più 71 in due giorni consecutivi in un’altra” è la differenza tra parafrasi e traduzione precisa. Identifica poi tre sorgenti distinte di corruzione: import massivi da sistemi legacy con formati data incompatibili, assenza di vincoli di integrità cross-campo, localizzazione dell’interfaccia senza normalizzazione al livello dello storage. Chiude con una raccomandazione operativa: servirebbe un serio passaggio di data cleansing prima di qualsiasi elaborazione.

Qui entra il punto che trasforma questo esperimento in qualcosa di più interessante. Opus 4.6 ha prodotto quei numeri su un file da 1.039.759 token. Per farlo, ha dovuto usare la finestra da 1M token in beta — quella standard si ferma a 200K, un quinto del file. I conti tornano: 20.341 record è il numero esatto delle righe del CSV, verificabile con un semplice wc -l. Ha letto tutto.

C’è un benchmark che misura esattamente questa capacità. Si chiama MRCR v2, e funziona nascondendo informazioni specifiche — gli “aghi” — dentro enormi quantità di testo irrilevante, poi verificando se il modello riesce a trovarle tutte. Opus 4.6 segna 76% sulla variante più difficile: otto aghi nascosti in un milione di token. Il suo predecessore, Sonnet 4.5, arrivava al 18.5% sullo stesso test. Gemini 3 Pro, che vanta una finestra da 2 milioni di token — il doppio di Opus — crolla al 26.3% alla stessa lunghezza di contesto, secondo la propria scheda di valutazione ufficiale.

Quei numeri suggeriscono che stiamo misurando la cosa sbagliata. La dimensione della finestra di contesto è diventata una metrica di marketing: chi dichiara di più vince il confronto sul foglio, indipendentemente da cosa succede dentro quella finestra. Servirebbe un’altra unità di misura — chiamiamola pure Effective Context Window — che misuri non quanti token un modello accetta in input, ma quanti ne elabora davvero mantenendo recall preciso. Su questa metrica, Gemini 3 Pro con 2M token dichiarati ha una ECW che, sul nostro CSV, si è rivelata probabilmente attorno a un quinto del file. Opus 4.6, con 1M token dichiarati, sembra averla usata quasi per intero.

Gemini aveva già la cabina da un milione di token prima di Opus. L’ha anche misurata meglio di chiunque altro. Ma ha restituito una parafrasi del documento, non una traduzione. Le cifre precise — quelle distribuite lungo tutto il file, nei record delle aziende a metà dataset — sono scivolate fuori dalla finestra usabile pur restando dentro quella dichiarata.

Resta una tensione irrisolta che vale nominare: in produzione, quale delle due intelligenze è più preziosa? L’inferenza causale di Gemini — capire il perché del bug Y2K senza contare ogni istanza — o la misura puntuale di Opus — sapere esattamente quanti record sono affetti, dove, e per quale classe di problema? La risposta dipende dal task. Se devi spiegare al team tecnico perché il sistema è rotto, l’intuizione causale vale oro. Se devi giustificare un intervento di data cleansing al management con numeri verificabili, ti serve la misura esatta. Sono strumenti diversi, non una gerarchia.

Il dataset corrotto non aspettava una parafrasi elegante. E nemmeno una cabina enorme con l’audio che si perde a metà.

---

Il dataset è pubblicamente disponibile su Kaggle (dati HR sintetici multi-tenant). Le analisi sono output reali dei tre modelli sullo stesso file CSV, febbraio 2026. Dimensione: 1.2 MB, 1.039.759 token (conteggio Gemini). Confronto MRCR v2 a 1M token: Opus 4.6 76%, Gemini 3 Pro 26.3% — fonte: schede di valutazione ufficiali dei rispettivi modelli, febbraio 2026.