La Coerenza Non È Correttezza: Perché un Paper Ha Bisogno di Tesi Verificabili, Non di Prosa Impeccabile
Qualche giorno fa ho letto un paper. Il titolo, da solo, avrebbe dovuto mettermi in guardia: Conditional Realism, Stewardship, and Survivable Cognition Under Finite Constraint. Quaranta pagine su Zenodo, con tanto di DOI, ORCID e un'impalcatura di riferimenti che rimandano tutti al programma di ricerca dell'autore stesso, l'Architecture of Limitation. Ha l'aria di una cosa seria. Mentre lo leggi, la prosa scorre, non si contraddice mai, anticipa le proprie obiezioni e le disinnesca con eleganza.
Eppure, arrivato alla fine, non avevo niente a cui aggrapparmi. Non perché fosse difficile — lo è, e di proposito — ma perché non avanzava una sola tesi che potessi mettere alla prova, controllare o confutare da fuori del suo stesso testo. Era impeccabile e vuoto nello stesso momento. E la cosa più rivelatrice è che il paper descrive il proprio modo di fallire senza mai riconoscersi allo specchio.
Vale la pena spiegare perché, perché lo schema è sempre più diffuso, e nell'era dei modelli di linguaggio individuarlo è diventato, in sordina, una competenza di ingegneria di prim'ordine.
Il nocciolo di verità, prima di tutto
Lasciami essere giusto, prima di essere duro. Il paper ha una buona idea, e parto da quella perché il resto non suoni come una battaglia contro un fantoccio.
L'idea è questa: l'espressione "human in the loop" funziona spesso come un segnaposto simbolico. Infiliamo un essere umano dentro una catena decisionale e dichiariamo che il sistema è sicuro, senza mai definire a quali condizioni quella partecipazione umana sia davvero significativa, proporzionata o responsabile. Il paper propone di sostituirla con una nozione di stewardship: ciò che l'essere umano porta non è supervisione, ma esposizione alla conseguenza. Il modello genera; l'essere umano sopporta. L'asimmetria è strutturale, non morale.
Su questo sono d'accordo. Anzi, si lega direttamente a una cosa che sostengo da tempo: l'IA aumenta, non sostituisce. La parte della catena che non puoi esternalizzare è proprio quella di chi porta il peso dell'errore e mantiene un rapporto conflittuale con la realtà quando il sistema deriva. È un'intuizione solida.
Il problema è tutto ciò che le sta intorno.
Il punto centrale: il paper è il proprio modo di fallire
Ecco ciò che mi ha davvero spinto a scrivere questo post.
Il paper, citando lavori precedenti dello stesso autore, conia due termini per descrivere come falliscono i sistemi di ragionamento sotto pressione:
- "Coherence inflation": il momento in cui la struttura recuperabile di un argomento comincia a sembrare spiegazione completa, e la coerenza interna sempre più ricca viene scambiata per certezza metafisica.
- "Hallucination as geometric overflow": testo che conserva fluidità, coerenza e organizzazione esplicativa mentre deriva oltre i confini che originariamente fondavano il ragionamento.
Rileggi quelle due definizioni. Sono la descrizione esatta del paper che le contiene.
Quaranta pagine di prosa fluida, internamente coerente, che non tocca mai terra. Ogni riferimento in bibliografia è un altro documento dello stesso autore, caricato sullo stesso repository, dentro lo stesso quadro inventato. È un anello di citazione chiuso: il testo si convalida con il proprio vocabolario. Il paper anticipa persino questa accusa — scrive letteralmente che "i lettori possono interpretare il presente lavoro come ricorsivamente autoconvalidante" — e la liquida dicendo che non è la sua intenzione. Ma riconoscere un circolo vizioso non lo spezza. La bibliografia continua a inseguirsi la coda.
E il dettaglio che corona il tutto: un DOI di Zenodo non è revisione paritaria. Zenodo assegna un DOI a qualunque cosa carichi — un PDF, un dataset, un meme. È un servizio di archiviazione, non un sigillo di qualità. L'apparato dell'autorità accademica — ORCID, DOI, sezioni numerate in cifre romane — è estetica, non sostanza.
Quello che ti ritrovi tra le mani è un artefatto che supera i propri test perché se li è scritti da solo, e che non può fallirne nemmeno uno perché non avanza mai una tesi controllabile.
L'analogia di ingegneria
Se sei un ingegnere, hai già pronto il modello mentale per capire esattamente cosa sta succedendo qui.
Immagina una PR che compila pulita, passa il linter e ha la CI verde. Tutti i test passano. Poi apri i test e scopri che a scriverli è stato lo stesso codice che dovrebbero verificare, e che ogni assert è una tautologia: expect(x).toBe(x). La build è verde. La copertura è al 100%. E il sistema non fa assolutamente niente.
Questo è il paper. Coerenza sintattica perfetta, zero contatto con un oracolo esterno.
In programmazione abbiamo un istinto affilato per queste cose, perché ci hanno morso fin troppe volte. Sappiamo che un test che passa sempre non vale niente. Sappiamo che un sistema che si convalida solo contro sé stesso — senza un ambiente di staging, senza dati reali, senza un utente che protesta — può essere profondamente rotto e sembrare in perfetta salute. Una compilazione pulita non è correttezza. La CI verde non è verità. È coerenza interna, una proprietà molto più a buon mercato e molto meno preziosa.
La filosofia e la scienza hanno lo stesso istinto, e ha un nome: falsificabilità. Un'affermazione che non si può formulare in modo che possa risultare falsa non è falsa — nelle parole di Pauli, "not even wrong". Non entra nemmeno in gioco. Non c'è niente su cui discutere, perché non c'è niente che il mondo possa contraddire.
Cosa rende solido un paper
Qui voglio essere costruttivo, perché la mossa facile sarebbe fermarsi a "questa è fuffa". La domanda utile è: cosa gli servirebbe per essere solido?
Tre cose, in ordine di forza decrescente.
1. Una tesi verificabile, con esperimenti, dati e risultati
Lo standard d'oro. Affermi qualcosa sul mondo, progetti un modo per misurarlo, raccogli i dati, e i risultati o sostengono la tesi o la demoliscono. Il punto chiave è che qualcun altro, da fuori, può riprodurla e arrivare a una conclusione propria. I dati non sono tuoi; appartengono a chiunque sia disposto a replicarli.
Qualche settimana fa ho scritto di un paper sull'allineamento dell'IA che tratta il sistema dispiegato come una distribuzione di probabilità su traiettorie e definisce l'allineamento come appartenenza topologica a un insieme sicuro. Non serve seguire la matematica per cogliere la differenza di natura: quel paper sostiene che l'appartenenza si può dimostrare con log finiti usando bound conformali. Ha uno scope dichiarato (sistemi di lavoro di informazione, non IA incarnata). Puoi dissentire, puoi attaccarne le assunzioni, puoi provare a trovare un controesempio. Ti offre una superficie a cui aggrapparti. È questo che fa di un paper parte di una conversazione.
2. Una tesi falsificabile, anche se non hai potuto provarla tu
Non tutto ha bisogno di un esperimento di laboratorio nel giorno stesso in cui viene pubblicato. Ma deve essere formulato in modo che si possa mettere alla prova, in linea di principio, da qualcuno, prima o poi. "I team che monitorano le traiettorie intermedie intercettano le deviazioni prima di quelli che monitorano solo l'output finale" è un'affermazione per cui oggi magari non hai i dati per chiuderla, ma che qualunque team può provare a confutare con la propria telemetria. È discutibile su un terreno condiviso.
3. Come minimo, una tesi discutibile fuori dalla testa di chi la scrive
Questo è il livello minimo, ed è esattamente quello che il paper di Zenodo non riesce a superare. Un'affermazione filosofica può essere perfettamente legittima senza nessun esperimento — la filosofia seria lo fa di continuo — purché offra definizioni, distinzioni e conseguenze che un altro possa raccogliere e contestare. Il realismo strutturale, il fallibilismo, il problema dell'induzione: sono posizioni filosofiche vecchie, dibattute per decenni, proprio perché formulate in modo abbastanza netto da permettere a qualcuno di dire "no, ed ecco perché".
Il paper che ho letto non fa questo. Riconfeziona il realismo strutturale epistemico — una posizione che esiste dagli anni Ottanta — con vocabolario inventato ("survivable cognition", "recoverable continuity", "operational invariants") e lo presenta come un'architettura proprietaria con "capability layers". Si dichiara "operational, not metaphysical" decine di volte, eppure non fornisce una sola operazione: non una metrica, non una procedura, non un criterio. La parola "operational" funziona come un talismano. Tutto è definito per nominalizzazione astratta, niente per operazione misurabile.
È un esperimento mentale sigillato dentro sé stesso. E un esperimento mentale in cui nessuno può entrare da fuori non è ricerca; è un diario in carattere accademico.
Perché ora questo è un problema di ingegneria
Fin qui potrebbe sembrare una baruffa tra accademici. Non lo è. È un problema nostro, e si è fatto urgente per una ragione concreta: i modelli di linguaggio sono motori di coerenza.
Un LLM è ottimizzato per produrre la continuazione più plausibile, più fluida, più internamente coerente di un testo. Non è ottimizzato per dire la verità. Quando funziona bene, le due cose grosso modo coincidono. Ma coerenza e correttezza sono assi indipendenti, e un modello può percorrere una distanza enorme lungo l'asse della coerenza con zero spostamento su quello della correttezza. Può generare quaranta pagine impeccabili su un quadro che non esiste, con una bibliografia che cita sé stessa, e ogni frase si incastrerà con la precedente.
Il paper che ho letto ha tutte le impronte di essere nato così — e l'ironia è perfetta, perché descrive proprio questo fenomeno e non si riconosce allo specchio.
È qui che torna la sua unica buona idea, rivolta contro il paper stesso. La difesa contro la coerenza vuota non è diffidare dell'IA. È lo steward umano che porta la conseguenza ed esercita la verifica. Il modello genera la prosa; qualcuno deve essere colui che chiede "un momento, questo si può controllare? Contro che cosa? Chi può replicarlo? I riferimenti esistono fuori da questo documento?". Quella funzione non si può esternalizzare allo stesso sistema che genera il testo, per la stessa ragione per cui non lasci che il codice scriva e approvi i propri test.
E questa è, quasi parola per parola, la tesi a cui torno sempre: l'IA aumenta, non sostituisce. L'aumento è reale ed enorme. Ma la responsabilità epistemica — il contatto con un oracolo esterno — resta umana. Il paper voleva argomentarla e invece la dimostra, diventando l'esempio di cosa succede quando quella funzione manca.
Una checklist, per ingegneri
Perché questo sia azionabile e non solo un lamento elegante, ecco le domande che mi pongo quando leggo — o scrivo — qualcosa che pretende di essere un contributo serio. Sono le stesse che faresti in una code review:
- Riesci a enunciare la tesi centrale in modo che possa risultare falsa? Se non esiste nessuno stato del mondo che la contraddirebbe, non è una tesi; è una definizione travestita.
- C'è una qualche misurazione? Dati, un esperimento, un'osservazione riproducibile. E se non c'è, almeno una conseguenza che qualcuno possa andare a cercare.
- Qualcuno da fuori potrebbe discuterla sul proprio terreno? Oppure puoi dibatterla solo dopo aver ingoiato per intero il vocabolario dell'autore?
- I riferimenti sono un anello chiuso? Se ogni citazione rimanda all'autore o al suo stesso quadro, la bibliografia è decorazione, non fondamento.
- I termini sono definiti come operazioni o come sostantivi astratti? "Recoverability" senza un modo per misurarla è una parola, non un concetto.
- L'apparenza di autorità sta facendo il lavoro della verità? Un DOI, un ORCID e sezioni in cifre romane non sono revisione paritaria. Chiediti chi ha davvero valutato tutto questo.
Se un testo fallisce la maggior parte di queste domande, può essere brillante, può essere bello, può perfino essere corretto per caso — ma non ci puoi appoggiare il peso. E in produzione, appoggiare il peso sulle cose è tutto il lavoro.
Cosa mi porto a casa
La coerenza costa poco. È sempre stato così, ma una volta servivano talento od ossessione per produrre quaranta pagine internamente coerenti sul nulla. Oggi è gratis e istantanea. Il che significa che la coerenza ha smesso di essere un segnale di qualità, e tutto il carico si sposta sulle proprietà che avrebbero dovuto contare fin dall'inizio: verificabilità, falsificabilità, esposizione alla contraddizione dall'esterno.
Il paper che ho letto non è solido, e non è tecnico — nonostante tutto il suo vocabolario di geometria vettoriale e rappresentazioni semantiche distribuite, non contiene una sola equazione, un solo dato, un solo esperimento. Ma mi è stato utile, perché è il caso di studio perfetto di qualcosa che tutti dovremo imparare a riconoscere: testo che suona come una tesi e non lo è.
Il lavoro di ingegneria — e quello di chiunque voglia pensare bene con questi strumenti — non è smettere di usare la macchina che genera prosa fluida. È mantenere la disciplina di chiedersi, ogni singola volta, contro che cosa questo viene controllato. Perché un sistema che si convalida solo contro sé stesso sembra in perfetta salute fino al giorno in cui lo metti davanti al mondo.
Stai costruendo sistemi IA dove la distanza tra coerenza e correttezza si paga in produzione, e preferiresti un team con l'istinto di verificarla contro la realtà? Parla con un CTO sul dispiegamento di capacità di ingegneria nearshore con la disciplina di non scambiare la CI verde per la verità.


