Modelli descrittivi, predittivi, prescrittivi

Un modello non è una copia del sistema: è un sostituto deliberatamente impoverito, costruito per rispondere a una domanda. Questo capitolo spiega cosa si guadagna e cosa si perde in quella sostituzione — e perché un modello di machine learning è, alla lettera, uno di questi sostituti.

Perché questo capitolo

C’è una frase che gira da mezzo secolo in statistica, in ingegneria, in economia, e che a una prima lettura sembra una resa: “all models are wrong, but some are useful”. Tutti i modelli sono sbagliati, ma alcuni sono utili. Detta così, suona come un’ammissione di fallimento mascherata da aforisma. In realtà è il contrario: è la regola operativa più importante che si possa imparare prima di costruire qualsiasi modello, e spiegarla bene è metà del lavoro di questo capitolo.

I capitoli precedenti della Parte IX hanno dato per scontato qualcosa di grosso. Sistema, ambiente, confine, stato ha definito cosa è un sistema. Stato, transizione, traiettoria ha definito stato e regola di transizione. Ma in entrambi i casi si è lavorato su una descrizione del sistema, non sul sistema vero.

Quella descrizione ha un nome, e ha regole sue: si chiama modello. Studiare un sistema reale direttamente è quasi sempre impossibile — è troppo grande, troppo rumoroso, troppo intrecciato. Si studia un suo surrogato più maneggevole. Il modello è il surrogato. Questo capitolo mette a fuoco l’atto del modellare: come si decide cosa tenere e cosa buttare, come si verifica che ciò che resta basti, e perché ogni scelta in questo lavoro è un compromesso, mai un’ottimizzazione pura.

Per chi costruisce sistemi AI la posta è alta, e non in senso vago. Un modello di machine learning è un modello di sistema, nel senso tecnico stretto della teoria dei sistemi: una rappresentazione costruita per mappare ingressi a uscite. Quando un agente di reinforcement learning impara un “world model” del suo ambiente, sta facendo modellazione nel senso pieno della parola.

Quando si discute se un LLM “abbia un modello del mondo”, si sta usando — spesso senza saperlo — un vocabolario che ha radici precise. E quando si testa un agente contro un ambiente simulato, si sta scegliendo un punto su un asse di compromesso che questo capitolo rende esplicito. Avere il concetto “modello” pulito vuol dire vedere tutte queste cose come istanze di una stessa idea, invece che come argomenti separati da imparare uno per uno.

Contesto

Modellare è antico quanto la scienza, ma il pensiero esplicito sulla modellazione — il riconoscere che il modello è una cosa diversa dal sistema, con regole proprie — è più recente, e vale la pena ricostruirne le tappe.

La meccanica di Isaac Newton, nel Seicento, è il modello white-box per eccellenza, anche se nessuno la chiamava così: poche equazioni, derivate da principi generali, che predicono il moto dei corpi. Pierre-Simon de Laplace, matematico e astronomo francese (1749-1827), ne diede nel 1814 la formulazione più ambiziosa, il “demone di Laplace”: un’intelligenza che conoscesse posizione e velocità di ogni particella dell’universo potrebbe calcolare l’intero futuro. È la fede massima nel modello deterministico completo. Per due secoli l’ideale implicito della scienza è stato questo: un modello giusto è un modello che riproduce esattamente il sistema.

La crepa in quell’ideale arriva nel Novecento da più direzioni. Una è la statistica. George Box (statistico britannico, 1919-2013, fra i padri del disegno sperimentale e del controllo statistico di qualità) formula nel 1976, in un articolo intitolato “Science and Statistics” (Journal of the American Statistical Association, vol. 71), un’idea che capovolge l’ideale laplaciano: il modello non deve riprodurre il sistema, perché non può.

La forma canonica della frase compare nel libro che Box scrive con Norman Draper, Empirical Model-Building and Response Surfaces (1987): “Essentially, all models are wrong, but some are useful”. Non è cinismo. È lo spostamento del criterio di giudizio dalla verità all’utilità, e tutto questo capitolo ne discende.

Un’altra direzione è ingegneristica. A partire dagli anni ‘50, Jay Forrester (ingegnere statunitense, 1918-2016, al MIT, già pioniere della memoria a nuclei magnetici dei computer) crea la system dynamics: un metodo per modellare sistemi sociali ed economici, non solo fisici, tramite accumuli (stock), flussi (flow) e ritardi (delay) collegati in anelli di feedback. La system dynamics porta la modellazione fuori dal suo recinto tradizionale — i sistemi meccanici semplici — verso i sistemi complessi e socio-economici. Da questa tradizione nasce nel 1972 il caso più discusso di modello mai costruito, The Limits to Growth, che incontreremo nella sezione “Dove si rompe”.

Questo capitolo eredita da entrambe le linee. Da Box, il principio che il modello si giudica per utilità rispetto a uno scopo, non per fedeltà assoluta. Da Forrester, l’idea che si possa modellare qualunque sistema, non solo quelli con leggi pulite — pagando però un prezzo in incertezza.

C’è infine una domanda che conviene mettere a fuoco prima di proseguire: perché modellare, invece di studiare il sistema direttamente? Le ragioni sono tre, e nessuna è marginale.

La prima è l’accessibilità: molti sistemi non si lasciano osservare per intero. Non si può smontare un’economia per vedere come funziona, né aspettare cinquant’anni per sapere come evolverà. La seconda è la manipolabilità: sul modello si possono provare interventi che sul sistema vero sarebbero impossibili, costosi o pericolosi — abbassare di colpo un tasso di natalità, simulare un crash, far fallire mille volte un agente.

La terza è la comprensibilità: il sistema vero ha troppi dettagli perché una mente — o un calcolatore — ci ragioni sopra. Il modello, omettendo, rende il sistema pensabile. Modellare non è un ripiego in attesa di poter studiare la realtà: è il modo in cui la realtà complessa diventa oggetto di pensiero.

L’intuizione

Prima di qualsiasi formalismo, due modi distinti di afferrare cosa è un modello. Il primo parte da un oggetto concreto e familiare: una mappa. Il secondo da una scelta operativa: cosa scrivi e cosa ometti. Conviene tenerli entrambi, perché il primo dice cosa è un modello e il secondo dice come si costruisce.

Primo angolo: la mappa non è il territorio

Una mappa stradale è un modello di una regione. È utilissima, e nessuno la confonde con la regione vera. Perché?

Perché omette quasi tutto. Una mappa stradale non mostra l’altezza dell’erba, il colore delle case, la geologia del sottosuolo, la temperatura dell’aria. Mostra strade, incroci, nomi, distanze. Quell’omissione massiccia non è un difetto della mappa: è la mappa.

Una “mappa” che riproducesse ogni dettaglio della regione, in scala 1:1, sarebbe grande quanto la regione e inutile come strumento — non ci si potrebbe ragionare sopra più di quanto si possa ragionare sulla regione stessa. Una mappa serve proprio perché è più piccola, più semplice, più povera del territorio.

E qui arriva il punto che la mappa rende ovvio. Della stessa regione esistono mappe diverse: stradale, geologica, climatica, catastale. Non sono in competizione, non c’è quella “vera” e quelle “sbagliate”. Ognuna omette cose diverse e conserva cose diverse, e ognuna è corretta per la domanda che si pone. La mappa geologica è inutile per guidare in auto, la mappa stradale è inutile per cercare petrolio. Non esiste “la mappa” della regione. Esiste la mappa-per-guidare, la mappa-per-trivellare.

Un modello è esattamente questo. È una rappresentazione semplificata di un sistema che conserva gli aspetti rilevanti per uno scopo dato e butta via il resto. Le tre parole pesano tutte. Rappresentazione: il modello sta al posto del sistema, può essere un sistema di equazioni, un grafo, una rete neurale, un foglio di calcolo. Semplificata: il modello omette, sempre, per definizione. Per uno scopo: non esiste il modello di un sistema, esiste il modello per rispondere a una certa domanda.

Da qui la massima di Box si legge senza più alcun sapore di resa. “Tutti i modelli sono sbagliati” significa: ogni modello, omettendo, differisce dal sistema — è “sbagliato” nel senso preciso di “non identico”. Questo è inevitabile, vale per la mappa stradale come per le equazioni di Newton. “Ma alcuni sono utili” significa: poiché la fedeltà perfetta è irraggiungibile per costruzione, il modello non si giudica chiedendo “è la realtà?” — la risposta è sempre no. Si giudica chiedendo “serve a rispondere alla domanda per cui l’ho costruito?”.

Va detto subito cosa la massima non dice, perché è il fraintendimento più comune. Non dice che tutti i modelli si equivalgono, che “tanto sono tutti sbagliati”. Dice l’opposto: alcuni sono utili e altri no, e distinguere quali è tutto il mestiere. La massima sposta il criterio di valutazione — dalla verità all’utilità — non lo abolisce. Lo statistico britannico David Cox, nel 1995, ha precisato la frase proprio per evitare questa lettura: meglio pensare ai modelli come “rappresentazioni idealizzate” che catturano gli aspetti importanti, che insistere sulla parola “sbagliato”. È una limatura, non un rovesciamento.

C’è una conseguenza pratica di questa intuizione che vale la pena estrarre subito. Se non esiste “il modello” di un sistema ma solo modelli-per-uno-scopo, allora la prima domanda da farsi davanti a qualsiasi modello — il proprio o quello di qualcun altro — non è “è corretto?” ma “per quale domanda è stato costruito?”. Un modello usato per rispondere a una domanda diversa da quella per cui è nato può essere perfettamente costruito e completamente fuorviante. È un errore che non lascia tracce: il modello non si rompe, non dà errori, restituisce numeri puliti — solo, sono numeri che rispondono a una domanda che nessuno ha posto. Tenere esplicito lo scopo di un modello è una disciplina, e la sua assenza è una delle cause più silenziose di decisioni sbagliate.

Secondo angolo: cosa scrivi sul foglietto

Il secondo angolo è la stessa idea vista dal lato di chi costruisce il modello. Immagina di dover descrivere un sistema a qualcuno che dovrà usarlo per decidere. Hai un foglio. Cosa ci scrivi?

Non puoi scriverci tutto: il sistema reale ha infiniti dettagli. Devi scegliere. E ogni cosa che scrivi ha un costo e ogni cosa che ometti ha un rischio. Se scrivi troppo, il foglio diventa illeggibile, e chi lo riceve non riesce a usarlo — hai fatto un modello intrattabile. Se scrivi troppo poco, ometti qualcosa che contava, e chi decide sbaglia — hai fatto un modello infedele. Modellare è scegliere cosa va sul foglio, e questa scelta è sempre un compromesso fra due pressioni opposte.

Da una parte la fedeltà: quanto il modello assomiglia al sistema, quanti dettagli conserva. Dall’altra la trattabilità: quanto il modello è facile da costruire, da calcolare, da capire, da comunicare. Le due si oppongono direttamente. Ogni variabile in più, ogni equazione in più, ogni parametro in più aumenta la fedeltà potenziale ma costa: servono più dati per stimarlo, più calcolo per simularlo, più fatica per capirlo e fidarsene. Ogni semplificazione alleggerisce ma rischia di buttare via qualcosa di importante.

Il punto cruciale, e controintuitivo, è questo: il modello migliore non è il più fedele possibile. È quello collocato nel punto giusto dell’asse fedeltà-trattabilità per lo scopo che ha.

Per progettare un ponte serve fedeltà altissima sul comportamento meccanico delle travi. Per spiegare a un consiglio comunale perché il ponte costa tanto serve un modello molto più grezzo, ma comunicabile in cinque minuti. Stesso ponte, due modelli, due punti diversi sull’asse, entrambi corretti perché rispondono a due scopi diversi.

Questo asse non è una particolarità della teoria dei sistemi. È lo stesso compromesso che ricompare in tutta la wiki sotto nomi diversi. Nel machine learning è il trade-off bias-varianza: un modello troppo semplice ha bias alto (è sistematicamente impreciso), uno troppo complesso ha varianza alta (si adatta al rumore). In statistica è la tensione fra parsimonia e aderenza ai dati, formalizzata in criteri come AIC e BIC che penalizzano esplicitamente la complessità. Nell’interpretabilità è la tensione fra modelli leggibili e modelli performanti. Sono tutte la stessa cosa: fedeltà contro trattabilità.

Vale la pena fermarsi su una parola di questo asse, perché è quella che più spesso viene fraintesa: la trattabilità. Non significa solo “facile da calcolare”. Ha almeno tre dimensioni, e un modello può essere trattabile in una e intrattabile in un’altra.

C’è la trattabilità computazionale: il modello si simula in tempi ragionevoli? C’è la trattabilità statistica: i dati a disposizione bastano a calibrare tutti i suoi parametri senza overfittare? E c’è la trattabilità cognitiva: una persona riesce a capire cosa fa il modello e perché, e quindi a fidarsene e a usarne i risultati per decidere?

Una rete neurale profonda può essere trattabile in senso computazionale — gira su una GPU — e completamente intrattabile in senso cognitivo: nessuno sa leggere i suoi pesi. Un modello a venti parametri può essere cognitivamente semplice e statisticamente intrattabile, se i dati per stimarli sono dieci. Quando si sceglie un punto sull’asse, conviene chiedersi quale trattabilità conta per lo scopo: per un modello che deve guidare una decisione umana, la trattabilità cognitiva pesa più di quella computazionale.

Terzo angolo: il modello come compressione

C’è un terzo modo di guardare la cosa, che torna utile soprattutto quando il modello in questione è un modello di machine learning. Un modello è una compressione del sistema.

Comprimere un file significa trovare una rappresentazione più corta che conserva l’informazione che conta e scarta la ridondanza. Un modello fa la stessa cosa con un sistema: ne trova una descrizione più corta del sistema stesso, conservando la struttura regolare — le leggi, le relazioni stabili — e scartando il dettaglio irripetibile. Le tre leggi di Keplero comprimono migliaia di osservazioni astronomiche in tre frasi: questa è una compressione fortissima, e di altissima qualità, perché conserva esattamente ciò che si ripete.

Questo angolo chiarisce due cose. La prima: un buon modello non è quello che memorizza i dati, è quello che ne trova la regola — e una regola è più corta dei dati che spiega. La seconda: l’overfitting, visto da qui, è una compressione fallita. Un modello che overfitta non ha trovato la regola, ha memorizzato i dati uno per uno, rumore incluso. È come “comprimere” un file riscrivendolo identico: nessuna compressione vera, nessuna regola estratta. Per questo un modello overfittato non generalizza: non ha niente da dire su un dato nuovo, perché non ha mai trovato la struttura, ha solo copiato. La compressione che butta via il rumore e tiene il segnale è esattamente l’apprendimento riuscito.

La meccanica

Con le due intuizioni in mano, si può rendere preciso il vocabolario del modellare. Tre blocchi: i tipi di modello, l’atto di tracciare il confine, e la validazione.

I tipi di modello

I modelli si classificano lungo più assi indipendenti. Ogni asse è una scelta di modellazione separata, e un modello reale è un punto in tutti questi assi insieme.

Asse 1 — da dove viene il modello: white-box, grey-box, black-box. È l’asse più importante per il ponte verso l’AI, e va spiegato con cura.

Un modello white-box (sinonimi: meccanicistico, first-principles, basato su teoria) è derivato dalla conoscenza del dominio. Le sue equazioni rappresentano meccanismi noti. Le equazioni del moto di Newton applicate a un proiettile sono un modello white-box: ogni termine corrisponde a una forza che sappiamo nominare. Un modello epidemiologico SIR — che divide la popolazione in suscettibili, infetti, rimossi e scrive come i numeri fluiscono fra i tre gruppi — è white-box: il tasso di contagio e il tasso di guarigione sono quantità con un significato preciso.

I pregi del white-box: è interpretabile, perché ogni parametro vuol dire qualcosa; estrapola bene fuori dai dati osservati, perché codifica leggi che valgono anche lì; richiede pochi dati, perché la struttura la fornisce la teoria. Il difetto: bisogna conoscere i meccanismi, e per i sistemi complessi quei meccanismi spesso non si conoscono o sono troppi.

Un modello black-box (sinonimi: empirico, data-driven, fenomenologico) è costruito interamente dai dati, senza assunzioni sui meccanismi interni. Cattura la relazione ingresso-uscita osservata e nient’altro. Una regressione su dati storici è black-box. Una rete neurale è black-box. I pregi: non serve capire il sistema, basta osservarlo abbastanza; cattura relazioni che nessuna teoria saprebbe scrivere. I difetti, speculari a quelli del white-box: è opaco, perché i parametri non hanno un significato leggibile; estrapola male, perché fuori dal range dei dati visti non ha nessuna legge a cui appoggiarsi; richiede molti dati.

Un modello grey-box sta in mezzo: scheletro teorico, dettagli stimati dai dati. La struttura delle equazioni viene dalla fisica, ma alcuni coefficienti incerti si calibrano sulle misure. È il caso più frequente nell’ingegneria reale, perché di un sistema di solito si conosce qualcosa ma non tutto.

Asse 2 — c’è il tempo? statico contro dinamico. Un modello statico descrive una relazione che non evolve: dato l’ingresso, l’uscita. Una regressione che lega il prezzo di una casa ai metri quadri è statica. Un modello dinamico descrive come lo stato cambia nel tempo, e ha una regola di transizione — esattamente l’oggetto di Stato, transizione, traiettoria. Le equazioni del moto sono dinamiche.

Asse 3 — c’è il caso? deterministico contro stocastico. Un modello deterministico dà sempre la stessa uscita per lo stesso ingresso. Un modello stocastico include variabili aleatorie: lo stesso ingresso produce una distribuzione di uscite. Una catena di Markov — un sistema che salta fra stati con certe probabilità — è stocastica. Le equazioni di Newton sono deterministiche. Quasi tutti i modelli AI sono stocastici: il sampling di un LLM e la policy di un agente RL producono uscite distribuite, non fisse.

Asse 4 — come scorre il tempo: continuo contro discreto. Tempo continuo (descritto da equazioni differenziali) contro tempo discreto (descritto da passi, da iterazioni). Anche le grandezze possono essere continue (una temperatura) o discrete (un conteggio di individui). Un transformer lavora a tempo discreto, un token alla volta.

Asse 5 — lo spazio conta? lumped contro distributed. Un modello lumped (a parametri concentrati) tratta una grandezza come uniforme: “la temperatura della stanza” è un numero solo. Un modello distributed la tratta come funzione della posizione: “la temperatura in ogni punto”, e richiede equazioni più pesanti. Lumped è più semplice, distributed più fedele quando lo spazio davvero conta.

Questi assi sono ortogonali. Un modello reale è una combinazione: si può avere un modello dinamico, stocastico, a tempo discreto, lumped, black-box — e ogni scelta su ogni asse è separata dalle altre.

Descrittivo, predittivo, prescrittivo

C’è un sesto modo di classificare i modelli, che riguarda non la loro struttura ma il loro uso, ed è il sottotitolo di questo capitolo. È una gradazione di ambizione crescente.

Un modello descrittivo spiega come un sistema funziona o si comporta, organizza la conoscenza senza necessariamente predire. Risponde a “com’è fatto questo sistema, quali parti ha, come sono collegate”. Un diagramma causale che mostra gli anelli di feedback di un’economia è descrittivo: non dice quando arriverà la prossima recessione, dice come le parti si influenzano. Anche una buona tassonomia — la classificazione dei tipi di modello in questo stesso capitolo — è un modello descrittivo.

Un modello predittivo stima cosa accadrà. Risponde a “dato lo stato attuale, dove andrà il sistema”. Un modello meteo che dà la temperatura di domani è predittivo. Un classificatore che, dato un commento, predice se è spam, è predittivo. La maggior parte dei modelli di machine learning vivono qui: il loro scopo dichiarato è la predizione su dati nuovi.

Un modello prescrittivo suggerisce cosa fare per ottenere un obiettivo. Risponde a “quale azione conviene prendere”. Un modello di ottimizzazione che indica come allocare un budget, un controllore che decide la prossima mossa di un termostato, la policy di un agente RL: sono prescrittivi. Non descrivono e non si limitano a predire — raccomandano un intervento.

I tre livelli hanno requisiti crescenti, ed è qui che la gradazione diventa istruttiva. Descrivere chiede solo che il modello sia coerente e leggibile. Predire chiede in più che sia validato: le sue stime devono reggere il confronto con dati nuovi.

Prescrivere chiede qualcosa di ancora più forte: un modello causale, non solo correlazionale. Un modello black-box puramente predittivo cattura correlazioni — “quando vedo A, di solito segue B” — e questo basta a predire. Ma prescrivere significa intervenire sul sistema, e un intervento segue le cause, non le correlazioni: agire su A cambia B solo se A causa B, non se entrambi dipendono da un terzo fattore nascosto. È la distinzione al centro di correlazione e causalità. Un modello può essere ottimo come predittore e del tutto inservibile come guida all’azione — e il fatto che predica bene può rendere quel difetto invisibile, perché chi lo usa lo vede “funzionare”.

Tracciare il confine

Prima di scrivere un’equazione, modellare comincia con due decisioni.

La prima è il confine del sistema: cosa sta dentro il modello, descritto in dettaglio, e cosa sta fuori, trattato come ambiente — un ingresso dato, o ignorato del tutto. È la nozione introdotta in Sistema, ambiente, confine, stato e ripresa nel capitolo confini-del-sistema (in preparazione). Spostare il confine cambia il modello: se modello un agente LLM e tengo il prompt fuori dal confine, il prompt è un ingresso esterno; se lo metto dentro, diventa una variabile da spiegare, e il modello deve dire da dove viene.

La seconda è il livello di astrazione: con quale grana descrivere ciò che sta dentro il confine. Un’economia si può modellare al livello del singolo consumatore o al livello degli aggregati macroeconomici. Entrambi corretti, per scopi diversi. Un livello troppo fine rende il modello intrattabile; troppo grezzo, lo rende cieco al fenomeno che interessa.

Validare un modello

Costruito un modello, bisogna stabilire se funziona. Qui si annidano tre attività distinte che vengono confuse di continuo, e tenerle separate è essenziale.

La verifica (verification) risponde alla domanda: il modello è stato implementato correttamente, come l’ho progettato? È debug. Si controlla che il codice della simulazione corrisponda alle equazioni intese, che non ci siano errori di trascrizione. È una domanda interna al modello.

La validazione (validation) risponde a una domanda diversa: il modello corrisponde abbastanza al sistema reale, per lo scopo dato? Si confrontano le predizioni del modello con dati reali — e qui sta il punto — dati non usati per costruire il modello. È una domanda esterna. Lo slogan classico della tradizione di modeling and simulation cattura la differenza in modo netto: verification è “are we building the model right?”, stiamo costruendo il modello correttamente; validation è “are we building the right model?”, stiamo costruendo il modello giusto. Un modello può essere verificato e non validato: implementato alla perfezione, ma è il modello sbagliato per quel sistema.

La calibrazione (calibration) è l’aggiustamento dei parametri liberi del modello perché le sue predizioni combacino con i dati osservati. È stima di parametri, ed è esattamente ciò di cui parlano i capitoli maximum likelihood e regressione statistica: trovare i valori dei parametri che rendono il modello più aderente ai dati.

Il rischio centrale della calibrazione ha un nome che chi conosce il ML riconoscerà subito: overfitting. Con abbastanza parametri liberi, un modello può combaciare alla perfezione con i dati di calibrazione e tuttavia predire malissimo su dati nuovi, perché ha fittato il rumore invece del segnale. Un modello overfittato dà una calibrazione che sembra eccellente — le curve passano per tutti i punti — e crolla appena lo si mette alla prova fuori. La difesa è una sola, ed è la stessa del ML: validare su dati tenuti da parte, mai sugli stessi dati usati per calibrare. Calibrazione perfetta non è validità.

C’è poi un problema più sottile, l’identificabilità. Un parametro è identificabile se il suo valore può essere determinato in modo univoco dai dati. La distinzione standard ha due livelli.

L’identificabilità strutturale chiede: in linea di principio, anche con dati perfetti e infiniti, questo parametro è determinabile dalla struttura del modello? Se due parametri compaiono nelle equazioni solo come loro prodotto — diciamo sempre $a \cdot b$ , mai $a$ e $b$ separati — allora nessun dato al mondo potrà mai dire se la coppia vale $(2, 3)$ oppure $(1, 6)$ : il prodotto è lo stesso.

L’identificabilità pratica chiede invece: con i dati reali a disposizione, finiti e rumorosi, il parametro è stimabile con un’incertezza accettabile? Un modello con parametri non identificabili può dare buone predizioni — il prodotto $a \cdot b$ è ben determinato anche se $a$ e $b$ no — ma i singoli parametri sono privi di senso. È pericoloso quando quei parametri vengono interpretati come misure del mondo.

Le tre attività vanno fatte in un certo ordine, ed è facile sbagliarlo. Prima si verifica: non ha senso confrontare con la realtà un modello che potrebbe avere un bug di implementazione — non si saprebbe se la divergenza viene dal modello o dal codice. Poi si calibra: si stimano i parametri sui dati di calibrazione.

Infine si valida, e qui sta il vincolo che più spesso viene violato: la validazione deve usare dati diversi da quelli della calibrazione. Se si valida sugli stessi dati usati per calibrare, si sta solo misurando quanto bene l’ottimizzatore ha fatto il suo lavoro, non quanto il modello predice. È come dare a uno studente l’esame su cui si è esercitato: un voto alto non dice nulla sulla sua preparazione. La separazione fra dati di calibrazione e dati di validazione è la stessa idea della divisione train/test del machine learning, ed è la difesa numero uno contro l’autoinganno.

C’è un’ultima cosa da chiarire sulla validazione: con cosa si confronta il modello. Non basta dire “con la realtà” — bisogna scegliere cosa della realtà guardare e quanto scostamento tollerare. Un modello del clima può azzeccare la temperatura media e sbagliare la variabilità; uno può azzeccare il valore finale e sbagliare il percorso per arrivarci. Validare significa decidere in anticipo quali grandezze contano per lo scopo, e fissare una soglia di scostamento accettabile prima di guardare i risultati. Decidere la soglia dopo aver visto come va il modello è una forma sottile di autoinganno: si finisce per chiamare “validato” qualsiasi cosa il modello produca.

Modello analitico e modello simulativo

Una distinzione che attraversa tutto il modeling and simulation, e che vale la pena rendere esplicita. Un modello, una volta scritto, si può usare in due modi.

Lo si può risolvere analiticamente: manipolare le equazioni con la matematica fino a ottenere una formula che dà la risposta direttamente. Il modello del pendolo per angoli piccoli, visto fra gli esempi, ha una soluzione analitica: una formula per il periodo, valida per sempre, senza calcoli ripetuti. Quando esiste, la soluzione analitica è la più potente — dice tutto in una riga.

Ma per la maggior parte dei sistemi interessanti la soluzione analitica non esiste, esattamente come Poincaré scoprì per il problema dei tre corpi. Allora si usa il modello simulativo: non si risolve l’equazione, la si fa girare passo dopo passo su un calcolatore e si guarda cosa succede. Non si ottiene una formula, si ottiene una traiettoria — un caso particolare, per quei dati iniziali e quegli ingressi.

Il prezzo della simulazione è che ogni domanda richiede una nuova esecuzione: cambia lo stato iniziale, devi rifare tutto. La soluzione analitica risponde a tutte le domande in una volta; quella simulativa risponde a una domanda alla volta. Quasi tutti i modelli di sistemi complessi — World3, i world model degli agenti, i simulatori fisici — sono modelli simulativi: non perché si preferisca, ma perché per quei sistemi una formula chiusa non c’è.

La simulazione

Avere un modello dinamico non basta per vedere cosa predice. Bisogna simularlo: far girare la regola di transizione passo dopo passo, da uno stato iniziale, e osservare la traiettoria. La simulazione è l’uso operativo principale di un modello dinamico. Permette di rispondere a domande controfattuali — “cosa succede se cambio questo?” — senza toccare il sistema reale. Si possono provare scenari, esplorare interventi, fare previsioni, tutto al sicuro dentro il modello.

In pseudocodice, una simulazione è un anello che non sorprenderà nessuno:

stato = stato_iniziale
traiettoria = [stato]
per t da 1 a T:
    ingresso = ingressi[t]            # cio che il modello riceve dall'ambiente
    stato = transizione(stato, ingresso)   # la regola del modello
    traiettoria.append(stato)
restituisci traiettoria

Tre righe contano. stato_iniziale è la condizione di partenza: due simulazioni con la stessa regola ma stati iniziali diversi danno traiettorie diverse. transizione è il cuore del modello, la regola che incarna tutte le scelte di modellazione fatte finora — è white-box o black-box, deterministica o stocastica, a seconda di come l’abbiamo costruita. ingressi è il modo in cui l’ambiente, ciò che sta fuori dal confine, entra nel sistema. La traiettoria che esce è la predizione del modello, e va confrontata con la realtà in fase di validazione.

Se il modello è stocastico, una sola simulazione non basta. La regola di transizione contiene variabili aleatorie, quindi ogni esecuzione dà una traiettoria diversa. Per sapere cosa il modello predice davvero si esegue la simulazione molte volte e si guarda la distribuzione delle traiettorie: non “il sistema finirà qui” ma “il sistema finirà qui con questa probabilità, là con quest’altra”. È il metodo Monte Carlo applicato a un modello, e cambia la natura della predizione: l’uscita non è un numero, è una distribuzione, e la sua larghezza è una misura dell’incertezza del modello.

Il ciclo di modellazione

Le attività viste finora — scegliere il confine e il livello, scegliere il tipo, calibrare, verificare, validare, simulare — non si fanno una volta in sequenza e poi si chiude. Si fanno in un ciclo.

Si parte da un modello tentativo, lo si calibra, lo si valida. La validazione quasi mai dà un sì pieno al primo giro: il modello sbaglia da qualche parte. A quel punto la domanda non è “il modello è giusto o sbagliato” — è sempre, in qualche misura, sbagliato — ma “lo scarto che vedo è accettabile per il mio scopo, oppure no?”. Se non lo è, si torna indietro: si rivede il confine, si cambia il livello di astrazione, si aggiunge o si toglie una variabile, si cambia il tipo di modello. Poi si ricalibra e si rivalida.

Questo loop ha un nome nella tradizione di Box: iterative model building, costruzione iterativa del modello. Il punto importante è che non esiste un modello finito in senso assoluto. Esiste un modello abbastanza buono per lo scopo corrente. Quando lo scopo cambia, o quando il sistema cambia, il ciclo riparte. Un modello è un oggetto vivo, non un risultato definitivo — e questo, come si vedrà, vale anche per i modelli di machine learning, che si ri-addestrano quando i dati derivano.

Esempi

Quattro esempi eterogenei: uno numerico classico, uno storico, uno di codice e scenario AI, uno che mette a confronto diretto i due estremi white-box e black-box.

Esempio 1 — il pendolo: lo stesso sistema, due modelli

Un pendolo che oscilla con angoli piccoli. Il modello white-box completo è un’equazione differenziale che contiene un seno: $\ddot{\theta} = -\frac{g}{L}\sin\theta$ , dove $\theta$ è l’angolo rispetto alla verticale, $g$ l’accelerazione di gravità, $L$ la lunghezza. In parole povere: l’accelerazione angolare è proporzionale al seno dell’angolo, con segno opposto perché la gravità riporta il pendolo verso il basso. Quel seno rende l’equazione difficile: non ha una soluzione in formula chiusa.

Ora la semplificazione. Per angoli piccoli, $\sin\theta$ è quasi uguale a $\theta$ stesso (un fatto che si vede subito guardando il grafico del seno vicino allo zero). Sostituendo, l’equazione diventa $\ddot{\theta} = -\frac{g}{L}\theta$ , che ha una soluzione pulita: il pendolo oscilla in modo sinusoidale, con un periodo che dipende solo da $L$ e $g$ .

Questo è il trade-off fedeltà-trattabilità nudo. Il modello con il seno è più fedele: vale per qualsiasi angolo. Il modello con $\theta$ al posto di $\sin\theta$ è più trattabile: si risolve a mano. Per un pendolo di orologio, che oscilla di pochi gradi, il modello semplificato è “sbagliato” — non è identico — ma è utile, anzi è il modello giusto: l’errore è trascurabile e in cambio si ottiene una formula. Per un pendolo che fa giri quasi completi, lo stesso modello semplificato è inservibile. Stesso sistema fisico, due modelli, e quale sia “giusto” dipende dallo scopo: la massima di Box in tre righe di trigonometria.

Esempio 2 — World3 e i limiti di un modello di sistema complesso

Nel 1972 un gruppo del MIT — Donella Meadows, Dennis Meadows, Jørgen Randers, William Behrens — pubblica The Limits to Growth, un rapporto per il Club di Roma basato su un modello di system dynamics chiamato World3. World3 è un modello dell’intero sistema economico-ambientale globale. Integra cinque settori collegati da anelli di feedback: popolazione, produzione alimentare, output industriale, risorse non rinnovabili, inquinamento. Usa il vocabolario di Forrester — stock, flow, delay — e il suo scenario di riferimento, a crescita esponenziale senza interventi, proietta un superamento della capacità di carico del pianeta seguito da un collasso intorno alla metà del XXI secolo.

World3 è un esempio scolastico nei due sensi. È la dimostrazione che si può modellare un sistema di enorme complessità e ricavarne intuizioni — gli anelli di feedback, i ritardi, il superamento e collasso — che nessun ragionamento a parole avrebbe reso altrettanto nitide. Ed è insieme la dimostrazione dei limiti: World3 è un modello aggregato, con molti parametri stimati su dati incerti, e la sua identificabilità è debole. Mezzo secolo di dibattito non ha chiuso la questione se le sue traiettorie precise vadano prese come predizioni o solo come illustrazioni di una dinamica qualitativa. World3 insegna che la potenza di un modello e la sua incertezza crescono insieme: più ambizioso è il sistema che si modella, più il modello dice — e meno ci si può fidare dei suoi numeri esatti.

Esempio 3 — il world model di un agente RL

Un agente di reinforcement learning deve imparare a giocare a un videogioco di guida. Un agente model-free impara per tentativi diretti: prova un’azione, vede il risultato, aggiusta. Un agente model-based fa qualcosa in più: costruisce un world model, un modello del proprio ambiente, e lo usa per pianificare simulando traiettorie prima di agire.

Il paper canonico è “World Models” di David Ha e Jürgen Schmidhuber (NeurIPS 2018). L’idea, nel vocabolario di questo capitolo: una rete neurale impara un modello black-box e dinamico dell’ambiente di gioco — una rappresentazione compressa di com’è fatto il mondo e di come evolve. L’agente può poi essere addestrato interamente “dentro il sogno” generato dal suo world model, cioè dentro la simulazione del modello, e trasferito poi al gioco vero.

# agente model-based: pianifica simulando dentro il world model
def scegli_azione(stato, world_model, orizzonte):
    migliore = None
    miglior_ritorno = -infinito
    for piano in piani_candidati():
        s = stato
        ritorno = 0
        for azione in piano[:orizzonte]:
            s, reward = world_model.transizione(s, azione)  # simulazione
            ritorno += reward
        if ritorno > miglior_ritorno:
            miglior_ritorno, migliore = ritorno, piano
    return migliore[0]

Il punto: world_model.transizione è esattamente la transizione dello pseudocodice di simulazione visto sopra. L’agente non agisce nel mondo per scoprire cosa succede — lo simula nel suo modello e sceglie il piano migliore. Tutta la qualità della decisione dipende dalla validità del world model. Se il modello è overfittato all’esperienza passata, le traiettorie simulate divergono da quelle reali e il piano migliore “nel sogno” fallisce nel gioco vero. È il reinforcement learning model-based, e il legame con la modellazione è di identità, non di analogia: il world model di un agente è un modello di sistema, costruito e validato come ogni altro.

Esempio 4 — lo stesso problema, modello white-box e modello black-box

Un esempio diretto del contrasto white-box / black-box su un unico problema. Si vuole predire il tempo di caduta di un oggetto lasciato cadere da un’altezza $h$ .

Il modello white-box viene dalla fisica. La cinematica dà $t = \sqrt{2h/g}$ : il tempo di caduta è la radice di due volte l’altezza diviso l’accelerazione di gravità. Una formula, zero parametri da stimare dai dati, $g$ è una costante nota. In parole povere: la teoria ci consegna il modello già fatto.

Il modello black-box ignora la fisica. Si lasciano cadere oggetti da varie altezze, si cronometra, si raccolgono coppie $(h, t)$ , e si fitta una curva. Con abbastanza dati, una regressione su $\sqrt{h}$ — o una piccola rete neurale — riproduce la relazione altrettanto bene, dentro il range delle altezze provate.

Finché si resta nel range, i due modelli sono indistinguibili nelle predizioni. La differenza emerge altrove, su tre fronti.

Primo, fuori dal range: chiedi a entrambi il tempo di caduta da un’altezza dieci volte più grande di qualunque cosa misurata. Il modello white-box risponde correttamente — la formula vale ovunque. Il modello black-box estrapola alla cieca e può sbagliare di molto, perché non ha la legge, ha solo i punti.

Secondo, l’interpretabilità: nel modello white-box il numero $g$ è l’accelerazione di gravità, ha un significato, lo si può misurare altrove e confrontare. Nel modello black-box i coefficienti della curva fittata non vogliono dire niente di per sé. Terzo, i dati: il white-box non ne ha avuto bisogno, il black-box ne ha avuto bisogno di parecchi. È il quadro completo del contrasto, su un problema che sta in una riga di formula.

Applicazioni pratiche

La modellazione non è una cornice astratta per chi costruisce sistemi AI: è un’attività quotidiana, spesso non riconosciuta come tale.

Capacity planning di un servizio LLM. Dimensionare un servizio richiede un modello del costo e della latenza in funzione del carico, della lunghezza del contesto, del modello scelto. È tipicamente un modello grey-box: la struttura è nota a priori — la latenza cresce con il numero di token, il costo è lineare in input e output — ma i coefficienti si calibrano su misure reali del proprio stack. Lo scopo è dimensionare, non capire la fisica interna dei transformer, e questo fissa il punto sull’asse fedeltà-trattabilità: un modello grezzo ma calibrato bene.

Simulazione dell’agent loop per il testing. Prima di mettere un agente in produzione, lo si fa girare contro un ambiente simulato: filesystem finto, API mockate, utente simulato. Quell’ambiente simulato è un modello dell’ambiente reale — meno fedele, ma trattabile e soprattutto ripetibile. Il valore sta proprio nell’infedeltà controllata: la simulazione si può eseguire mille volte in modo identico, cosa impossibile con il sistema vero. Un agent test è una scelta deliberata di sacrificare fedeltà per trattabilità.

Model-based RL e il reality gap. Quando un agente impara un world model e pianifica al suo interno, sta modellando in tempo reale. Il rischio operativo è il reality gap: se il world model — o un simulatore fisico per la robotica — diverge dal mondo vero, i piani ottimizzati nel modello falliscono nella realtà. È overfitting visto dal lato della modellazione, e la difesa è la stessa: validare il world model contro dati reali, non fidarsi della sua aderenza al passato.

Scegliere il modello in data science. Di fronte a un problema predittivo, la scelta fra una regressione lineare interpretabile e un gradient boosting opaco non è una questione tecnica neutra: è una decisione di posizione sull’asse fedeltà-trattabilità, guidata dallo scopo. Serve capire quali fattori guidano il fenomeno — e allora vince l’interpretabilità del white-box-ish — oppure serve solo predire bene, e allora si accetta l’opacità del black-box.

Modellare il sistema agentico per anticiparne i guasti. Un sistema agentico in produzione è esso stesso un sistema da modellare — è la riflessività vista nella ricerca. Per la safety e il capacity planning si costruiscono modelli del sistema-agente: un modello del tasso di errore in funzione della lunghezza del task, un modello di quanti retry servono in media, un modello di come il costo cresce quando si concatenano più chiamate. Sono modelli descrittivi e predittivi del comportamento dell’agente, e servono a rispondere a domande operative — “quanto budget serve”, “dove conviene mettere un controllo umano” — prima che il sistema le risponda da solo, sul campo, in modo costoso. Un cenno di vocabolario per chi incontra il termine: un digital twin è la forma estrema di questa idea — un modello del sistema tenuto continuamente sincronizzato con dati reali, in modo da poterlo interrogare come se fosse il sistema. Il concetto è stato formalizzato da Michael Grieves nel 2002 nel contesto della gestione del ciclo di vita dei prodotti, ma la pratica è più antica: durante Apollo 13, nel 1970, la NASA usò simulatori a terra allineati con la telemetria della navetta per diagnosticare il guasto e provare le manovre di rientro al sicuro.

Dove si rompe

La modellazione fallisce in modi caratteristici, e quasi tutti i fallimenti nascono dal dimenticare che il modello non è il sistema.

Il modello scambiato per la realtà. Il fallimento radice. Un modello calibrato e validato funziona bene, e a forza di usarlo si smette di vedere le sue omissioni. Le decisioni si prendono “secondo il modello” come se il modello fosse il territorio. Il rischio cresce con la qualità del modello: più è buono, più è facile dimenticare cosa ha lasciato fuori. World3 ne è un esempio storico — le sue curve precise sono state a volte lette come profezie, quando il modello stesso era pensato per illustrare dinamiche qualitative. La mappa, per quanto buona, non è il territorio, e un modello che ha funzionato cento volte può rompersi alla centunesima perché il caso nuovo cade in ciò che aveva omesso.

Overfitting: la calibrazione che inganna. Già visto, ma va ribadito come modo di fallire. Un modello con troppi parametri liberi rispetto ai dati raggiunge una calibrazione visivamente perfetta e un potere predittivo pessimo. L’inganno è che la calibrazione sembra un successo: le curve passano per tutti i punti. Solo la validazione su dati nuovi smaschera il problema, ed è per questo che saltare la validazione — “il modello fitta benissimo, è pronto” — è uno degli errori più comuni e più costosi.

Parametri non identificabili interpretati. Un modello può predire bene e avere parametri privi di senso, se non sono identificabili. Il pericolo scatta quando qualcuno legge quei parametri come misure del mondo: “il modello dice che il tasso vero è 0.3”. Se quel parametro non è identificabile, 0.3 è solo uno fra infiniti valori egualmente compatibili con i dati, scelto dall’ottimizzatore per caso. Predizione valida, parametro inventato.

Estrapolazione di un black-box. Un modello black-box è affidabile dentro il range dei dati su cui è stato costruito e cieco fuori. Non ha leggi da seguire dove non ci sono dati. Usarlo per estrapolare — predire in condizioni mai osservate — è un errore strutturale, non un caso sfortunato. Un white-box, codificando leggi che valgono ovunque, estrapola meglio; un black-box no, per costruzione.

Il caso degli LLM: un modello del testo, non del mondo. Qui serve molta cautela nelle classi di affermazione. Si dice spesso che un LLM “ha un modello del mondo”. Marchiamo: è un’analogia, e va trattata come tale, non come identità. Quello che un LLM modella in senso stretto è la distribuzione del testo umano: è un modello black-box costruito dal corpus. Attraverso il testo, indirettamente, modella anche ciò che il testo descrive — ma è un modello di un modello, ed eredita ogni bias, lacuna ed errore del testo di partenza.

Esiste un dibattito aperto, vivo nel 2024-2026, se gli LLM costruiscano internamente un vero “world model” — rappresentazioni del processo causale che ha generato i dati — oppure solo “surface statistics”, correlazioni superficiali. Ci sono evidenze in entrambe le direzioni: esperimenti su modelli addestrati a giocare a Othello mostrano rappresentazioni interne sorprendentemente strutturate; critiche sottolineano che gli LLM operano su simboli e non su spazio e tempo, e non hanno una presa diretta su gravità, attrito, causalità fisica.

Indipendentemente da come si chiuderà il dibattito, la cornice “modello” rende leggibile il limite: un modello black-box estrapola male fuori distribuzione — e questo vale per un LLM come per qualsiasi black-box. Quando un LLM sbaglia su un caso lontano da ciò che il suo corpus copriva, non è un bug misterioso: è il comportamento previsto di un modello black-box fuori dal suo range.

Il modello giusto per lo scopo sbagliato. Un modello predittivo usato per prescrivere. Cattura correlazioni e predice bene, e qualcuno lo usa per decidere su quale leva agire. Ma intervenire segue le cause, non le correlazioni: la leva indicata può non avere alcun effetto causale. Il modello non è rotto — è usato fuori dal suo scopo, e questo è un modo di rompersi tanto quanto un bug.

Il confine tracciato male. Un modello può essere internamente impeccabile e fallire perché ha messo dentro il confine la cosa sbagliata, o ha lasciato fuori qualcosa che contava. Se modelli il costo di un servizio AI e tieni fuori dal confine il costo dei retry sugli errori, il modello sottostima il costo reale in modo sistematico — e nessuna calibrazione lo correggerà, perché il dato semplicemente non entra nel modello. Gli errori di confine sono insidiosi perché non si manifestano come imprecisione, ma come una distorsione costante che sembra parte del sistema. Si trovano solo mettendo in discussione il confine stesso, non aggiustando i parametri.

La deriva: il modello che invecchia. Un modello validato oggi può smettere di essere valido domani, non perché sia cambiato il modello, ma perché è cambiato il sistema. Il fenomeno ha un nome nel machine learning, drift: la distribuzione dei dati cambia, e un modello calibrato sul vecchio mondo predice sul nuovo. Un modello del comportamento degli utenti di un’app diventa obsoleto quando gli utenti cambiano abitudini. Questa è la ragione per cui il ciclo di modellazione non si chiude: la validità di un modello ha una scadenza, e un modello messo in produzione va rivalidato nel tempo, non dato per buono una volta per tutte.

Collegamenti

Sistema, ambiente, confine, stato — definisce sistema, ambiente, confine e stato: tutto ciò che un modello rappresenta. Modellare è dare una forma maneggevole a quelle nozioni.
Stato, transizione, traiettoria — un modello dinamico è una regola di transizione su uno stato. Quel capitolo costruisce il formalismo che qui si usa per la simulazione.
Feedback vs feedforward — i modelli di system dynamics, da Forrester a World3, sono fatti di anelli di feedback: capire il feedback è capire come quei modelli generano le loro dinamiche.
confini-del-sistema (in preparazione) — la prima decisione del modellare è dove tracciare il confine; quel capitolo la approfondisce.
riduzionismo-olismo (in preparazione) — scomporre un sistema in parti o trattarlo come un tutto è una scelta di modellazione: il livello di astrazione visto da un’altra angolazione.
Correlazione, confondenti, causalità — un modello prescrittivo richiede causalità, non solo correlazione. Spiega perché un modello predittivo può fallire come guida all’azione.
Maximum likelihood — calibrare un modello è stimarne i parametri massimizzando l’aderenza ai dati: la meccanica della calibrazione.
Calibrazione statistica — la calibrazione di un modello statistico e il problema di confidenze ben tarate: il versante statistico della validazione.
Regressione statistica — la regressione è il modello black-box più semplice e la procedura di calibrazione più studiata.
MDP come framework per il decision making — il world model di un agente model-based è un modello della dinamica e della reward di un MDP.
bias-varianza (in preparazione) — il trade-off bias-varianza del machine learning è il trade-off fedeltà/trattabilità di questo capitolo, formalizzato.
interpretabilita-intro (in preparazione) — la distinzione interpretabile vs opaco è la distinzione white-box vs black-box vista dal lato del deep learning.

Per andare oltre

George E. P. Box, “Science and Statistics”, Journal of the American Statistical Association, vol. 71, 1976 — il testo che introduce l’idea “all models are wrong”. Breve, leggibile, e ancora attuale sul rapporto fra scienza e modelli.
Donella H. Meadows, Thinking in Systems: A Primer (2008) — introduzione divulgativa al pensiero sistemico e ai modelli di system dynamics, dalla coautrice di The Limits to Growth. Il modo migliore per entrare nel modo di pensare di Forrester senza l’apparato tecnico.
David Ha, Jürgen Schmidhuber, “World Models”, NeurIPS 2018 (arXiv:1803.10122) — il paper canonico sui world model appresi nel reinforcement learning. La versione interattiva su worldmodels.github.io è particolarmente chiara.
Kenneth Li et al., “Large Language Model: world models or surface statistics?”, The Gradient, 2023 — discussione accessibile del dibattito se gli LLM costruiscano rappresentazioni interne strutturate, a partire dall’esperimento Othello-GPT.
Lennart Ljung, System Identification: Theory for the User (2a ed., 1999) — testo di riferimento sulla costruzione di modelli dai dati, con la trattazione classica dello spettro white-box / grey-box / black-box.