C'è un cavallo morto in via Pordenone

Come modelliamo la realtà, e come a volte la tradiamo, in informatica

 

C'è una barzelletta di Pino Caruso, uno dei più raffinati comici che l'Italia abbia avuto, che racconta di un giovane negoziante balbuziente. Un mattino trova un cavallo morto davanti alla sua bottega e chiama i soccorsi per farlo rimuovere. Ogni volta che l'operatore gli chiede il nome della strada, la parola gli si inceppa in gola: lui balbetta, l'operatore si spazientisce, pensa a un disturbo in linea e riattacca. Succede quattro volte. Alla quinta il nome esce perfetto: "Via Po". L'operatore, sollevato, gli chiede come mai adesso ci sia riuscito senza problemi. E lui risponde, semplice: ha trascinato il cavallo fin lì, perché sapeva di riuscire a pronunciare quel nome senza inciampare.

La battuta funziona su più livelli, ma ce n'è uno che vale la pena portare fuori dal registro comico, perché tocca un nervo scoperto di ogni disciplina che si occupi di rappresentare la realtà per poterla governare: l'informatica in testa.

Scavalcare, non cavalcare

Nel racconto di Caruso, prima di arrivare al telefono, il ragazzo scavalca il cavallo morto. Non lo cavalca. Ed è un dettaglio lessicale piccolo ma esatto: cavalcare presuppone un animale vivo, che collabora, che ha una sua energia da condividere con chi lo monta. Scavalcare tratta l'animale come un ostacolo, un ingombro geometrico da superare. Il prefisso "s-" fa tutto il lavoro: trasforma un soggetto in un oggetto. La parola giusta, in quel momento, non descrive semplicemente la scena: la costituisce. Dichiara cosa quel cavallo è diventato.

È un principio che vale in generale, molto prima e molto oltre la battuta: la parola che scegliamo per nominare una cosa non è mai neutra rispetto a quella cosa. La nomina, la definisce, decide cosa possiamo farne. In informatica questo principio non è un lusso stilistico, è la sostanza stessa del lavoro.

Il momento più delicato: la modellazione

Chiunque faccia analisi dei problemi in informatica conosce bene il passaggio più critico dell'intero processo: la modellazione della realtà. Le variabili in gioco, in qualunque dominio non banale, sono sempre troppe per essere trattate tutte. Il compito del modellatore è una potatura: decidere che una variabile è essenziale e un'altra è trascurabile. È un'operazione necessaria, non evitabile: un modello che includesse tutto non sarebbe più un modello, sarebbe il fenomeno stesso, inutilizzabile proprio per la sua completezza.

Ma questa potatura è un terreno scivoloso. Se il criterio con cui tagliamo i rami non è dichiarato e vigilato, rischia di essere "a sentimento": arbitrario, comodo, piegato ai nostri pregiudizi frettolosi più che alla fedeltà del fenomeno. E il pericolo aumenta perché il risultato di questa potatura, una volta incorporato in un formalismo, in una classe, in uno schema dati, in un algoritmo, si presenta con l'autorità apparente della matematica. Una scelta discutibile fatta a parole si può contestare; la stessa scelta incorporata in una riga di codice si nasconde dietro una parvenza di oggettività che il linguaggio naturale non ha.

Primo caso: gli oggetti che tradiamo

Nell'analisi orientata agli oggetti, il momento più delicato è quello in cui sembra che decidiamo noi quali siano gli oggetti del dominio e quali attributi li definiscano. Sembra, ma non dovrebbe essere così: il modellatore serio conserva un timore reverenziale verso ciò che l'oggetto, nel dominio che sta rappresentando, effettivamente è. Il rischio, quando questo timore manca, è di trasformarlo in un animale mitologico: un corpo che appartiene al dominio reale, ma con una testa che appartiene alla comodità implementativa del progettista. Un attributo aggiunto perché torna utile a noi, una responsabilità affibbiata a una classe perché ci semplifica l'architettura, non perché appartenga davvero a quell'oggetto.

Non è un caso che l'ingegneria del software abbia un nome tecnico per la versione degenerata di questo fenomeno, la classe che accumula troppe responsabilità, il cosiddetto God Object. Di solito lo si insegna come un difetto di design. Ma è, prima ancora, un difetto etico: è il punto in cui il progettista ha smesso di ascoltare i confini naturali dell'oggetto e li ha ridisegnati per la propria convenienza. Ha spostato il cavallo.

Secondo caso: il tipo che dichiara il significato

Anche la scelta del tipo di dato, che sembra la decisione più tecnica e meno filosofica dell'intero processo, è in realtà una dichiarazione di significato. La regola generale è semplice: numero intero se contiamo, numero reale se misuriamo. Ma le eccezioni contano quanto la regola, e sono istruttive. Un numero di telefono, un CAP, una partita IVA restano stringhe anche se scritti con sole cifre, perché non sono quantità: sommarli non ha alcun senso, e trattarli come numeri sarebbe un errore che riguarda cosa quella cosa è, travestito da scelta tecnica innocua.

C'è poi un caso più sottile ancora. Se il dato è la temperatura massima registrata oggi in una città, posso anche accontentarmi di un numero intero: per lo scopo che ci interessa, sapere se domani serve la giacca, il decimo di grado è rumore, e troncarlo non falsifica nulla di rilevante. Ma se il dato è la temperatura corporea di una persona, no. Lì il decimo di grado è informazione clinica, non rumore. Troncarlo a intero significherebbe nascondere varianza reale dietro una precisione apparente più bassa, e in questo caso specifico, con una punta di ironia, significherebbe anche togliere ai pazienti più apprensivi la soddisfazione di poter dire con precisione di avere trentasette e uno. La scelta del tipo, insomma, dichiara implicitamente quanto della realtà vogliamo che sopravviva alla rappresentazione. Farla per comodità invece che per fedeltà al fenomeno è già, in piccolo, un atto di violenza epistemica, anche se si esaurisce nella scelta tra int e float in una riga di codice che quasi nessuno guarderà mai con occhio critico.

Il salto di scala: il training dell'intelligenza artificiale

Nell'analisi a oggetti e nella scelta dei tipi di dato, l'atto di modellazione resta artigianale, individuale, tracciabile: un progettista che decide, un dato alla volta, cosa conta e cosa no. Nel training di un sistema di intelligenza artificiale lo stesso identico gesto avviene però su scala industriale, distribuito tra migliaia di micro-decisioni prese da persone diverse in momenti diversi: chi raccoglie il dataset, chi lo ripulisce, chi scrive le linee guida per chi lo annota, chi decide quali esempi trattare come outlier da scartare e quali come casi core da conservare.

Qui il cavallo non lo sposta più una singola persona con un gesto deliberato. Lo spostano cento persone con cento piccoli gesti amministrativi, ciascuno ragionevole se preso da solo (pulizia dei dati, deduplicazione, bilanciamento delle classi), nessuno dei quali sembra, isolatamente, un atto di manomissione della realtà. Eppure il risultato aggregato può essere esattamente lo stesso della barzelletta: un sistema che risponde con piena sicurezza attingendo a una scena costruita a propria immagine, senza sapere di averlo fatto. Ed è qui l'aggravante specifica del digitale rispetto al bias umano tradizionale: il sistema non mente, non ha nemmeno la consapevolezza minima che serve per mentire. Esegue soltanto la via che gli è stata data, convinto, se così si può dire, che sia quella originaria.

Una responsabilità che non si delega al codice

Il punto d'arrivo di questo percorso è che la modellazione della realtà, in informatica, non è un'attività di secondo livello, un semplice trasferimento neutro di conoscenza da un dominio a un formalismo. È un atto epistemologicamente primario, e per questo un atto che porta con sé una responsabilità morale, non solo tecnica. Un modello costruito senza fedeltà al fenomeno che rappresenta non è "tecnicamente valido ma eticamente discutibile": è semplicemente falso, anche quando è formalmente impeccabile, anche quando compila senza errori, anche quando le metriche sono ottime.

La differenza tra chi modella con onestà e chi modella per comodità non sta quasi mai in un errore visibile. Sta in una domanda che ciascuno di noi, davanti a ogni variabile che decide di scartare, dovrebbe porsi con onestà: la sto scartando perché davvero non cambia il comportamento del fenomeno rispetto alla domanda che sto facendo, o perché mi complica la vita, o non conferma quello che già mi aspettavo? La prima è potatura. La seconda, per quanto compiuta con le migliori intenzioni amministrative, è già uno spostare il cavallo.

Guardare fuori, guardare dentro

C'è un aspetto di questo lavoro che riguarda non solo il fenomeno che rappresentiamo, ma chi lo rappresenta. L'informatica, quando la si pratica sul serio e non solo come esecuzione tecnica, costringe a un esercizio continuo di metacognizione: non basta guardare fuori, al problema, bisogna guardare anche dentro, a come noi stessi lo stiamo affrontando, con quali strumenti concettuali, con quali scorciatoie, con quali automatismi. È un cambio di prospettiva che non si esaurisce mai in una sola direzione: si osserva il fenomeno, poi si osserva se stessi mentre lo si osserva, poi di nuovo il fenomeno, in un movimento che somiglia più a una dialettica che a una sequenza ordinata di passi. È l'immagine che Escher ha fissato in "Mani che disegnano": una mano disegna l'altra, che a sua volta disegna la prima, e non esiste un punto zero puro da cui il processo abbia inizio, perché ogni mano che disegna è già stata disegnata da qualcos'altro. Anche il modellatore, in fondo, pensa il fenomeno con categorie che il fenomeno stesso, o fenomeni precedenti, hanno contribuito a formare in lui.

 

E in questo movimento, prima o poi, ci si accorge di un fatto scomodo: siamo inadeguati al compito. Non per pigrizia occasionale, ma strutturalmente, perché la complessità del reale eccede sempre, per definizione, la capacità che abbiamo di contenerla in un modello. Siamo, per usare un'immagine che rende bene l'idea, poco attrezzati a sopravvivere nel mare della complessità in cui l'informatica ci getta ogni volta che affrontiamo un problema non banale. Ed è proprio per questo che la frequentazione assidua con l'informatica, più di quanto si creda, è un'esperienza di vita che mantiene umili: chi ci lavora seriamente sa, o dovrebbe sapere, quanto sia pieno di limiti nel tentativo di dominare una realtà che lo eccede sempre.

Eppure navigare necesse est. Non ci è concesso restare fermi davanti alla complessità in attesa di comprenderla per intero, perché quel momento non arriva mai: il problema va affrontato comunque, una decisione va presa comunque, il modello va costruito comunque. Una quadratura, insomma, siamo costretti a trovarla. Ed è qui che si apre la scelta vera, quella che la barzelletta di Caruso mette in scena con una leggerezza solo apparente: possiamo trovarla spostando il cavallo, cioè piegando la realtà a ciò che siamo capaci di gestire, e tradendo così la verità pur di aggirare il nostro limite. Oppure possiamo imporci di restare fedeli agli aspetti qualificanti del fenomeno che stiamo esaminando, anche quando questo significa convivere apertamente con la propria inadeguatezza invece di occultarla. Non è una scelta che si compie una volta per tutte: è uno sforzo dialettico continuo, un negoziato senza tregua tra il proprio io, con i suoi limiti, le sue comodità, i suoi automatismi, e il proprio fuori, cioè la realtà che siamo chiamati a rappresentare con onestà, indipendentemente da quanto siamo o non siamo attrezzati per farlo.

Il negoziante di Pino Caruso, alla fine, si vanta di aver fatto "una fatica bestiale". Ed è vero, letteralmente: trascinare un cavallo morto per la città è un lavoro pesante. Ma è una fatica sprecata, e per giunta più grave di quanto sembri a prima vista: non si è limitato a nascondere il proprio limite, ha inquinato la scena prima ancora che chiunque potesse osservarla, come chi sposta un corpo prima che arrivi la scientifica. Chi guarda da fuori non vede più la realtà originaria, vede solo la versione già manomessa che gli viene consegnata come se fosse quella vera. Il difetto che gli inceppa la parola resta esattamente dov'era, perché un cavallo si può spostare ma un difetto non si risolve spostando qualcos'altro. E il vero compito, in fondo, non era liberarsi della balbuzie: era riuscire a dire la verità nonostante la balbuzie, senza tradire la realtà per aggirare il proprio limite. Quel compito, lui, non lo ha nemmeno affrontato.