Salahzar's Weblog

Qualcuno ha preso 1,3 milioni di documenti giudiziari del caso Epstein, li ha dati in pasto a un modello linguistico, e adesso chiunque può cercare un nome e ottenere un riassunto navigabile con le connessioni tra persone, luoghi, date. Tremila dollari di costi di elaborazione, una catena di strumenti che va dall’OCR alla ricerca testuale su PostgreSQL, e il gioco è fatto. La reazione di chi mastica ingegneria dei dati è prevedibile: quanto ha speso per documento? Serviva davvero il modello per la ricerca, o bastava l’indicizzazione classica? La deduplicazione dei nomi regge? Domande legittime, e ci torno. Ma il punto è un altro.

Quei documenti erano già pubblici. Tecnicamente. Nel senso che un giornalista investigativo con tre mesi di tempo, un avvocato con accesso a PACER, o un ossessivo con competenze archivistiche poteva raggiungerli, leggerli, incrociarli. Adesso li raggiunge chiunque digiti un cognome in un campo di ricerca. Il salto non è tecnologico — è di accessibilità. E l’accessibilità, quando l’oggetto è un caso giudiziario con nomi di persone reali, ha conseguenze che i tecnici sottovalutano regolarmente.

C’è un parallelo che viene naturale, e non è nemmeno troppo lontano. In Italia la cronaca giudiziaria funziona così da sempre: migliaia di pagine di ordinanze, intercettazioni, perizie, e poi il cronista che le condensa in un articolo. “Tizio avrebbe incontrato Caio il 14 marzo a Reggio Calabria”. Quel condizionale dovrebbe segnalare cautela, ma nella testa del lettore diventa fatto. Il riassunto del cronista è il processo, per la stragrande maggioranza delle persone. Chi ha mai letto per intero un’ordinanza di custodia cautelare? Eppure tutti hanno un’opinione su Guilmi, su Catanzaro, sulla ‘Ndrangheta a Milano. L’opinione è figlia del riassunto, non del documento.

Questo progetto automatizza quel cronista.

Ma devo fare una deviazione tecnica, perché le scelte di chi ha costruito il sistema non sono indifferenti. L’autore ha usato PostgreSQL con ricerca a testo completo invece di infilare tutto in un database vettoriale — scelta controcorrente in un momento in cui sembra che senza rappresentazioni vettoriali non si possa fare nulla di serio. Ha ragione. Per cercare nomi e parole chiave, la corrispondenza esatta con classificazione classica funziona meglio. Il modello linguistico non serve per trovare i documenti: serve per riscriverli. Riassunti, estrazione di entità, normalizzazione del testo sporco che esce dall’OCR. Non sta sostituendo strumenti collaudati — li affianca con qualcosa che prima richiedeva un essere umano con tanta pazienza.

Il costo — circa 0,002 euro a documento in elaborazione in lotto — è ragionevole per un esperimento. Meno ovvia è la scelta di passare tutto dal modello. Perché 1,3 milioni di documenti non sono tutti uguali. Molti saranno fogli di routine, notifiche procedurali, duplicati. Una catena di elaborazione pensata bene avrebbe filtrato prima, riassunto poi. Ma questo è un progetto personale, non una redazione con revisioni incrociate.

Dai documenti saltano fuori 238mila “persone”. Che probabilmente sono centomila o meno, dopo aver tolto i duplicati: OCR che legge male, nomi con iniziali, secondi nomi che appaiono e scompaiono, omonimie. L’autore pensa di usare rappresentazioni vettoriali per raggruppare le varianti, e ci può stare, ma prima ci sono passaggi più economici: normalizzazione deterministica, confronto approssimato, raggruppamento per cognome e iniziale. Il modello linguistico dovrebbe entrare solo sui casi ambigui, come arbitro finale. Non su tutto il mucchio. Ma non è questo il problema del progetto.

Il problema è che quando generi riassunti automatici, grafi di connessione, e pagine con il nome di una persona e una descrizione sintetica della sua presenza nei documenti, stai costruendo una narrazione. Puoi dire che estrai, che sintetizzi, che rendi accessibile. Ma il lettore che arriva sulla pagina di Mario Rossi e legge “collegato a tre incontri documentati con l’imputato nel periodo 2003-2005” non sta leggendo il documento — sta leggendo l’interpretazione che il modello ha dato del documento. E il modello non ha giudizio, non conosce il contesto, non distingue tra una presenza rilevante e una comparsata burocratica. Il grafo delle relazioni amplifica: due nomi che compaiono nello stesso faldone diventano “collegati”, e “collegati” nel contesto Epstein non è un termine neutro. C’è anche qualcosa di più sottile: il modello che produce quei riassunti è stato addestrato su un corpus che include già anni di copertura giornalistica del caso. Quando riassume un documento processuale, non parte da zero — parte da quello che “sa” dai giornali. Il rischio è un circolo vizioso: il modello conferma la narrazione dominante invece di interrogarla, e il lettore trova nel riassunto esattamente quello che si aspettava di trovare. Il contrario della trasparenza.

È il meccanismo della cronaca giudiziaria italiana, ma senza il cronista. E il cronista, per quanto impreciso, per quanto fazioso a volte, almeno era qualcuno. Aveva un nome, una testata, una querela possibile. Il riassunto del modello non ha niente di tutto questo. Chi lo contesti? Chi citi in giudizio? Il ragazzo che ha messo su il progetto nel tempo libero?

Qui entra il cinema, e non come decorazione. Sbatti il mostro in prima pagina, Bellocchio, 1972: il caporedattore che seleziona, taglia, riassume i fatti fino a costruire il colpevole. Il mostro non esce dall’indagine — esce dalla prima pagina. Esce dal riassunto. Il meccanismo è lo stesso, solo che al posto del caporedattore c’è un modello linguistico che non sa di stare facendo una prima pagina. E questo progetto, per quanto nato come esperimento tecnico — e lo è, un esercizio di orchestrazione notevole per un singolo sviluppatore: raccolta massiva, elaborazione asincrona, sistema di code, ricerca testuale e a grafo, quattrocento gigabyte di dati — non tratta un catalogo di ricette o un archivio di brevetti. Tratta un caso giudiziario che la stampa mondiale ha trasformato in terreno di caccia per complottisti, giustizieri digitali e chiunque abbia un conto da regolare.

L’autore nei commenti sembra consapevole del rischio. Ma la consapevolezza non basta, perché il problema non è l’intenzione di chi pubblica — è l’uso che ne fa chi legge. Un archivio di documenti grezzi è una cosa. Un motore di ricerca con riassunti automatici e grafi di relazione su materiale giudiziario sensibile è un’altra. La differenza sta tutta nel riassunto — in quel passaggio dal documento grezzo alla sintesi leggibile dove qualcosa decide cosa conta e cosa no.

Chi controlla il riassunto controlla la narrazione. Era vero per il cronista giudiziario, è vero per l’algoritmo. Solo che il cronista lo sapeva.

Il progetto discusso in questo pezzo è Epstein Graph, presentato dall’autore (u/indienow) su r/SideProject: 1.317.893 documenti indicizzati, 238.163 persone estratte, sei giorni di lavoro, tremila dollari di elaborazione tramite API OpenAI in lotto su PostgreSQL. Le fonti documentali sono il Dipartimento di Giustizia statunitense (rilascio del 30 gennaio 2026 in base all’Epstein Files Transparency Act), la House Oversight Committee, l’Estate of Jeffrey Epstein, e il processo 2008. Il riferimento cinematografico è a Sbatti il mostro in prima pagina (Marco Bellocchio, 1972). Progetti analoghi: Epstein Archive (nicko170, articolo 404 Media), Epstein Suite, NIA Agent.