Black box, input-output, identificazione del sistema

Un sistema di cui si vedono solo gli ingressi e le uscite, mai l’interno. La cibernetica ha trasformato questa condizione di ignoranza in un metodo, e quel metodo dice oggi cosa significa davvero valutare un modello che non si può aprire.

Perché questo capitolo

Un dispositivo arriva sul banco sigillato. Su un lato ha dei morsetti d’ingresso, sull’altro dei morsetti d’uscita. Non si può aprire: forse è incollato, forse smontarlo lo distrugge, forse semplicemente non c’è il permesso. Eppure bisogna sapere cosa fa. L’unica mossa disponibile è collegare segnali agli ingressi e misurare cosa esce.

Questa scena ha un nome — il problema della scatola nera (black box) — e non descrive un caso di laboratorio raro. Descrive la condizione normale della conoscenza scientifica.

La cibernetica degli anni Cinquanta se ne accorse e fece una mossa decisiva: invece di trattare quell’ignoranza come un ostacolo, la trasformò in un metodo. Non potendo guardare dentro, si sonda da fuori, in modo sistematico, e si costruisce progressivamente un modello del comportamento. L’ignoranza sul meccanismo non sparisce; viene aggirata.

Per chi costruisce sistemi con l’AI questo capitolo non è un esercizio storico. Un modello di deep learning, e in particolare un LLM, è l’esempio contemporaneo per eccellenza di scatola nera: un sistema addestrato, funzionante, in produzione, con un meccanismo interno che chi lo usa — e in larga misura anche chi lo costruisce — non sa leggere come si legge un programma.

Capire l’epistemologia della scatola nera significa capire cosa stai davvero facendo quando valuti, sondi, e decidi di fidarti di un sistema che non puoi aprire. La risposta a quella domanda è stata scritta nel 1956, prima che esistesse qualunque rete neurale profonda. Il vocabolario c’era già; mancava soltanto la scatola a cui applicarlo.

Contesto

Il termine “black box” non nasce dalla teoria. Nasce dall’officina.

Peter Galison, storico della scienza statunitense che ha studiato la cibernetica di Wiener, lo fa risalire al Radiation Laboratory del MIT durante la Seconda guerra mondiale: i componenti elettronici per il radar — amplificatori, ricevitori, filtri — erano alloggiati in contenitori metallici scuri con morsetti d’ingresso e d’uscita, che un tecnico poteva usare senza sapere cosa contenessero.

Una versione alternativa lega il termine alla Tizard Mission del 1940, la missione che porta dalla Gran Bretagna agli Stati Uniti un magnetron a cavità sperimentale dentro una scatola di metallo nero: un componente difficile da spiegare, chiuso in una scatola nera letterale. Comunque sia andata, l’origine è materiale prima che concettuale: scatole vere, di metallo, di colore scuro.

Il radar e il controllo del tiro contraereo sono lo stesso terreno da cui nasce la cibernetica, raccontato nel capitolo Wiener: comunicazione e controllo in animali e macchine. Norbert Wiener (matematico statunitense del MIT, 1894-1964, fondatore della cibernetica), lavorando al predittore antiaereo nei primi anni Quaranta, tratta il comportamento del pilota nemico come un servomeccanismo: un sistema opaco le cui mosse evasive si caratterizzano statisticamente dai soli ingressi e uscite, senza pretendere di modellarne la mente.

Nel 1944 lo psicologo sperimentale Edwin Boring, in corrispondenza con Wiener, descrive il cervello come “a mysterious box with binding posts and knobs on it” — una misteriosa scatola con morsetti e manopole. La frase non è un’immagine poetica: è la formulazione esatta del problema. Il cervello, per chi lo studia da fuori, è letteralmente una scatola con dei terminali.

Il termine entra nel discorso cibernetico nei primi anni Cinquanta. Nel gennaio 1951 Wiener discute “the problem of the black box” con W. Ross Ashby al Burden Neurological Institute, e già allora distingue le scatole nere — struttura interna ignota — dalle scatole bianche, di cui si conosce lo schema.

Non è un caso che il concetto maturi proprio in quel decennio e in quell’ambiente. Sono gli anni delle Macy Conferences, la serie di incontri interdisciplinari che radunano matematici, neurofisiologi, psicologi e ingegneri attorno all’idea di sistema, informazione e controllo — il tema del capitolo Macy Conferences (in preparazione) di questa Parte.

La scatola nera è uno strumento perfetto per quella conversazione. Permette di parlare di un cervello, di una macchina e di un organismo con lo stesso vocabolario, senza dover prima concordare cosa ci sia dentro ciascuno. È un concetto che traduce: un neurofisiologo e un ingegnere elettronico, davanti a sistemi incomparabili, possono lavorare entrambi sul protocollo ingresso-uscita. La scatola nera era, in quel contesto, una lingua franca.

La sistematizzazione definitiva è di W. Ross Ashby (psichiatra e pioniere britannico della cibernetica, 1903-1972), nello stesso libro che ha già attraversato questa Parte: An Introduction to Cybernetics (Chapman and Hall, Londra, 1956), il primo manuale sistematico della disciplina. Lo stesso libro che enuncia la legge della varietà necessaria dedica un intero capitolo, intitolato “The Black Box”, al problema di studiare un sistema che non si può aprire. È quel capitolo l’oggetto principale di questo.

Per Ashby la scatola nera non era un tema marginale. Il problema lo aveva accompagnato per tutta la carriera: il suo Homeostat, la macchina adattiva descritta nel capitolo Ashby, omeostato e adattamento, era stato studiato dai colleghi proprio come una scatola nera — un dispositivo di cui si osservava il ritorno all’equilibrio senza dover seguire ogni passaggio dei suoi circuiti. Ashby sapeva, da psichiatra, che il cervello del paziente era la scatola nera per definizione: nessun accesso diretto, solo comportamento osservabile. Il capitolo del 1956 generalizza quella condizione e la rende un metodo.

Una precisazione sulla collocazione. Questo capitolo sta nella Parte sulla cibernetica perché lì il concetto è nato e lì è stato formalizzato. Ma la scatola nera ha un parente strettissimo nella Parte sulla teoria dei sistemi: il capitolo Cosa posso misurare, cosa posso governare parla di osservabilità, cioè di quanto dello stato interno di un sistema sia ricostruibile dalle sue uscite. La scatola nera è, si vedrà, il caso limite di osservabilità ridotta. I due capitoli si leggono bene in coppia: la teoria dei sistemi dà la nozione graduata, la cibernetica dà il caso estremo e il metodo per affrontarlo.

L’intuizione

Primo angolo: l’esperimento di Ashby

Ashby costruisce la scena con precisione, e conviene seguirla parola per parola perché è la definizione operativa del concetto.

Un esperimentatore si trova davanti a una scatola con un certo numero di morsetti. Nelle parole di Ashby: “by applying various combinations of electrical potentials to these terminals he can observe what potentials appear on the other terminals” — applicando varie combinazioni di potenziali elettrici a questi morsetti può osservare quali potenziali compaiono sugli altri.

Applica un ingresso, registra l’uscita, annota la coppia con l’istante di tempo. Quel registro crescente di coppie ha un nome tecnico in Ashby: il protocollo. Il protocollo è l’unico dato grezzo disponibile. Non c’è altro: né uno schema, né un manuale, né una finestra sul fianco.

Il punto centrale del capitolo di Ashby è una frase che limita in modo netto cosa si può sapere: “all knowledge obtainable from a Black Box … is such as can be obtained by re-coding the protocol; all that, and nothing more” — tutta la conoscenza ricavabile da una scatola nera è quella ottenibile ricodificando il protocollo, tutta lì, e niente di più.

Il modello del comportamento è una riscrittura compatta della tabella di coppie ingresso-uscita. Non esiste un canale privilegiato verso l’interno: c’è il protocollo, e c’è ciò che dal protocollo si può comprimere. Tutto ciò che si crede di sapere “in più” sulla scatola, se non viene dal protocollo, è ipotesi travestita da conoscenza.

Fin qui sembra la descrizione di un caso particolare. Il passo che rende il capitolo di Ashby memorabile è il ribaltamento successivo. Ashby scrive che “every electrical engineer and every cybernetician, in fact every scientist, has had experience of the Black Box” — ogni ingegnere, ogni cibernetico, ogni scienziato ha avuto a che fare con la scatola nera. E poi, ancora più netto: “in fact all real objects are Black Boxes” — tutti gli oggetti reali sono scatole nere.

Questa non è retorica. È un’affermazione epistemologica precisa. Aprire la scatola non risolve il problema: dentro si trovano altri componenti, e ognuno è a sua volta una scatola nera con i suoi morsetti.

La conoscenza scientifica, in fondo, è sempre conoscenza black-box. Aprire un cervello e guardarne i neuroni non rende il cervello trasparente: sposta soltanto il confine della scatola di un livello, e i neuroni restano oggetti da sondare con i loro ingressi e le loro uscite. Si possono aprire anche i neuroni, e dentro si troveranno canali ionici, anch’essi da sondare.

Lo scienziato non apre mai davvero la natura: costruisce modelli a partire da protocolli di ingresso-uscita, a ogni livello. La scatola nera, in questa lettura, non è una limitazione di un certo tipo di studio. È la forma di ogni conoscenza empirica.

Secondo angolo: sistemi diversi, comportamento identico

Il secondo angolo è una conseguenza scomoda del primo, e cambia il modo di leggere qualsiasi modello black-box.

Se tutta la conoscenza viene dal protocollo, allora due scatole con interni completamente diversi possono produrre lo stesso identico protocollo, e dall’esterno restano indistinguibili.

Pensa a una scatola che, dati due bit, ne restituisce uno: la stessa tabella ingresso-uscita la realizzano un circuito a relay, uno a valvole, uno a transistor, una lookup table su carta, o una persona che calcola a mente. Cinque meccanismi incompatibili, un solo protocollo. Nessuna quantità di sondaggio, su quella tabella, riuscirà mai a dire quale dei cinque c’è dentro.

Questo è esattamente il punto di contatto con l’osservabilità, il concetto che la Parte sulla teoria dei sistemi definisce come la possibilità di ricostruire lo stato interno di un sistema dalle sue uscite. Quando due stati interni diversi danno sempre la stessa uscita per ogni ingresso, sono indistinguibili dall’esterno: il sistema non è completamente osservabile. La scatola nera è il caso limite di questa situazione — l’osservabilità ridotta a quel poco che il protocollo lascia trapelare.

La conseguenza pratica pesa. Dal comportamento non si risale a un meccanismo unico: si risale a una classe di equivalenza di meccanismi, tutti compatibili con i dati raccolti. Il modello black-box è sotto-determinato: i dati lo vincolano, non lo fissano.

Ed è qui che si annida il rischio. Un modello black-box può predire benissimo gli output già osservati e sbagliare clamorosamente su input fuori dalla regione che è stata sondata. La classe di meccanismi compatibili con il protocollo è larga, e i suoi membri si separano proprio là dove non si è guardato. Due scatole che coincidono su mille prove possono divergere sulla milleunesima.

Terzo angolo: capire come comprimere

C’è un terzo modo di guardare la stessa cosa, che chiarisce in cosa consista davvero il “modello” che si costruisce. Torna alla frase di Ashby: la conoscenza ricavabile è ciò che si ottiene “ricodificando il protocollo”. Ricodificare significa riscrivere in forma più corta.

Il protocollo grezzo è una lista che cresce senza fine: una riga per ogni prova. Per una porta logica a due ingressi sono quattro righe e basta — il protocollo è già finito. Ma per una scatola con molti ingressi, o con ingressi continui, o con memoria, il protocollo è di fatto infinito: non si finisce mai di sondare. Avere quel protocollo in mano non è capire la scatola; è solo possederne il diario.

Capire la scatola significa trovare una regola più corta del protocollo che lo riproduca. Quattro righe della porta logica si comprimono in tre lettere: “OR”. Una funzione sondata in cento punti si comprime, se si ha fortuna, nella formula $x^2$ . Il modello è la versione compressa del comportamento.

E qui si vede perché un modello che riproduce il protocollo senza comprimerlo — una lookup table grande quanto il protocollo stesso — non è un modello: non ha capito niente, ha solo ricopiato. Lo stesso vale per un LLM che ha memorizzato un benchmark invece di risolverlo: riproduce le risposte note, ma non ha compresso la regola, e infatti fallisce sul caso nuovo.

Questo terzo angolo dà un criterio operativo. Un buon modello black-box è molto più corto del protocollo che spiega, e predice righe del protocollo non ancora osservate. Se non è più corto, è una copia; se non predice, non è stato validato. Un modello del comportamento di un LLM che vale qualcosa è una descrizione compatta — “affidabile su X, debole su Y” — che anticipa risposte non ancora viste, non un archivio di risposte già date.

Tieni insieme i tre angoli e hai l’intera epistemologia della scatola nera. Primo: si può conoscere solo il protocollo. Secondo: il protocollo non identifica un meccanismo, ma una famiglia di meccanismi. Terzo: capire la scatola è comprimere il protocollo in una regola più corta che predice. Tutto ciò che segue — l’identificazione del sistema, la valutazione di un LLM, i limiti del red-teaming — è conseguenza di questi tre fatti.

La meccanica

Tre gradi di trasparenza: white, black, grey

Prima della procedura serve un vocabolario. La trasparenza di un sistema non è un interruttore acceso o spento: è un continuum con tre punti di riferimento, ripresi dalla letteratura sull’identificazione dei sistemi.

Un modello white box (scatola bianca) deriva da principi primi: si conosce la struttura interna prima di misurare qualsiasi cosa. Le equazioni di Newton per un pendolo, lo schema circuitale di un amplificatore, il codice sorgente di una funzione. Si sa come funziona, e la misura serve al più a confermare. Il limite del white box è pratico: per sistemi reali abbastanza ricchi, il modello da principi primi diventa intrattabilmente complesso.

Un modello black box (scatola nera) sta all’estremo opposto: nessuna conoscenza interna, solo ingressi e uscite. Il modello è puramente comportamentale — riproduce ciò che il sistema fa, senza dire come.

Un modello grey box (scatola grigia) sta in mezzo: si conosce la forma del modello, per ragioni teoriche, ma i suoi parametri vanno stimati dai dati. Si sa che la crescita di una coltura segue una certa curva di saturazione; quale curva, esattamente, lo dicono le misure.

La maggior parte dei sistemi realmente studiati è grigia. Il bianco e il nero sono i due estremi ideali verso cui ci si avvicina, raramente i punti in cui ci si trova. Anche un LLM, sondato a lungo, diventa un grigio molto chiaro: si sa molto del suo comportamento, anche senza saperne il meccanismo.

Questa classificazione è la stessa che il capitolo Modelli descrittivi, predittivi, prescrittivi introduce parlando di modelli: white, black e grey box sono modelli ordinati per quanto meccanismo interno incorporano.

Sondaggio passivo e sondaggio attivo

Prima della procedura, una distinzione che cambia tutto: chi sceglie gli ingressi?

Nel sondaggio passivo l’esperimentatore non controlla gli ingressi: osserva il sistema mentre opera, e registra le coppie ingresso-uscita che capitano. Un astronomo studia le stelle così: non può accendere o spegnere una supernova, può solo guardare. Un team che colleziona i log di un modello in produzione fa lo stesso — il protocollo è quello che gli utenti reali hanno generato.

Nel sondaggio attivo l’esperimentatore sceglie gli ingressi. Decide cosa immettere, e può scegliere proprio gli ingressi che separano le ipotesi rivali. È l’esperimento di Ashby in senso pieno, ed è molto più potente: gli ingressi mirati restringono la classe dei meccanismi compatibili più in fretta degli ingressi che capitano.

La differenza è netta nel caso dell’AI. Raccogliere i log di produzione di un LLM è sondaggio passivo: rivela cosa il modello fa sugli input reali, ma lascia interi continenti del suo comportamento non toccati, perché nessun utente ci è andato.

Costruire una eval con prompt scelti, e ancor più fare red-teaming, è sondaggio attivo: si va apposta dove il sondaggio passivo non arriva. Per questo un sistema valutato solo sui log di produzione può sembrare solido e nascondere fallimenti gravi: il protocollo passivo non li ha mai sollecitati. Gli input più pericolosi sono spesso proprio quelli che nessun utente onesto digiterebbe.

Identificazione del sistema: la procedura

Studiare una scatola nera ha un nome ingegneristico: identificazione del sistema (system identification), la costruzione di un modello matematico di un sistema dinamico a partire da dati di ingresso-uscita misurati.

È una disciplina matura della teoria del controllo, con i suoi metodi e i suoi teoremi. Qui interessa l’ossatura concettuale, non il dettaglio tecnico. La procedura, ridotta all’osso, ha sei passi.

1. Definire il confine. Decidere cosa conta come ingresso e cosa come uscita. Non è una formalità: scegliere il confine cambia il problema, esattamente come argomenta il capitolo Scegliere il confine cambia il problema. Un confine diverso è una scatola diversa, e quindi un’identificazione diversa.

2. Progettare gli ingressi (experiment design). Ingressi poco vari rivelano poco: si vede solo la fetta di comportamento che quegli ingressi toccano. Un ingresso ricco di varietà sonda più stati del sistema. Qui torna la legge della varietà necessaria: per distinguere $N$ comportamenti interni servono almeno $N$ ingressi distinguibili. Sondare con poca varietà e poi stupirsi che il modello fallisca su un caso nuovo è un errore di progettazione, non sfortuna.

3. Registrare il protocollo. Le coppie (ingresso, uscita) con l’istante di tempo. Se il sistema ha stato interno — cioè memoria — l’uscita dipende anche dalla storia, non solo dall’ingresso corrente, e il protocollo deve includere intere sequenze, non coppie isolate.

4. Ipotizzare una classe di modelli. Il sistema è lineare? Ha memoria finita? È una rete? La scelta della classe è un atto di conoscenza esterna iniettata nel problema: è qui che il grey box si separa dal black box puro. Un black box rigoroso non assume nulla; in pratica si assume sempre qualcosa.

5. Stimare i parametri. Fittare il modello scelto al protocollo, minimizzando l’errore tra l’uscita predetta e l’uscita misurata. Gli strumenti sono quelli statistici: minimi quadrati, oppure la stima di massima verosimiglianza, che cerca i parametri sotto cui i dati osservati sono più probabili.

6. Validare su ingressi nuovi. Il test vero non è riprodurre il protocollo con cui si è stimato il modello: è predire l’uscita su ingressi mai visti. Un modello che riproduce e basta ha soltanto memorizzato il protocollo, e memorizzare non è capire.

In notazione minima. Un sistema dinamico a tempo discreto con stato interno si scrive con due equazioni:

$x[t+1] = f(x[t],\, u[t]) \qquad y[t] = g(x[t],\, u[t])$

Qui $u$ è l’ingresso, $y$ è l’uscita, $x$ è lo stato interno. La prima equazione dice come lo stato evolve; la seconda come l’uscita dipende da stato e ingresso. In parole povere: ciò che vedi adesso dipende da ciò che immetti e da ciò che il sistema si porta dentro dal passato.

Nella scatola nera $f$ , $g$ e perfino la dimensione di $x$ — quanti numeri servono a descrivere lo stato — sono ignoti. L’identificazione cerca $f$ e $g$ , o un modello equivalente direttamente ingresso-uscita, tali che la $y$ predetta combaci con la $y$ misurata.

Per un sistema senza memoria il problema collassa al caso più semplice, $y[t] = h(u[t])$ : la scatola è una pura funzione, e identificarla significa ricostruire quella funzione punto per punto. Con la memoria il problema si fa molto più duro, perché lo stato $x$ non si osserva mai direttamente — va inferito anch’esso dal protocollo.

Una nota pratica chiude questo passaggio. Nell’ingegneria del controllo esiste un’idea chiamata Identification for Control: non serve il modello “vero” del sistema, serve un modello abbastanza buono per lo scopo. Un modello imperfetto è spesso sufficiente a controllare bene. Questo anticipa un punto centrale sulla valutazione dei modelli: non serve capire come funziona internamente un LLM per usarlo con profitto; serve un modello abbastanza affidabile del suo comportamento.

Perché due scatole indistinguibili si separano: un conto

Vale la pena rendere numerico il secondo angolo dell’intuizione, perché è la cosa che più spesso si dà per scontata.

Prendi due scatole con un ingresso intero e un’uscita intera. La prima calcola $y = x$ . La seconda calcola $y = x + (x-1)(x-2)(x-3)$ . Internamente sono due cose diverse: la prima è banale, la seconda fa un calcolo polinomiale. Vediamo se il sondaggio le distingue.

Sondale entrambe sugli ingressi $1, 2, 3$ . La prima dà $1, 2, 3$ . La seconda dà: $1 + 0 = 1$ , poi $2 + 0 = 2$ , poi $3 + 0 = 3$ — perché il prodotto $(x-1)(x-2)(x-3)$ si annulla esattamente in quei tre punti. Protocollo identico. Tre prove, e le due scatole sono indistinguibili.

Sonda ora con $x = 4$ . La prima dà $4$ . La seconda dà $4 + (3)(2)(1) = 4 + 6 = 10$ .

Il protocollo si biforca. Le due scatole, identiche su tre ingressi, divergono di sei unità al quarto. Chi si fosse fermato a tre prove avrebbe consegnato un modello — “questa scatola calcola $y = x$ ” — sbagliato per una delle due scatole, e non avrebbe avuto modo di accorgersene.

Il punto generale: per qualsiasi insieme finito di prove esistono infinite scatole che le superano tutte e poi divergono. Il trucco usato qui — aggiungere un termine che si annulla sui punti sondati — funziona sempre, per qualunque protocollo finito. Non c’è insieme di prove abbastanza grande da chiudere la questione, finché lo spazio degli ingressi resta infinito.

Più si sonda, più la classe dei meccanismi compatibili si restringe — ma non si chiude mai del tutto. Questo è il motivo formale per cui la validazione su ingressi nuovi non è un passo opzionale: è l’unico passo che separa i membri della classe, e lo fa sempre solo in parte.

Quando un’eval di un LLM passa su mille casi, ha ristretto la classe; non l’ha chiusa. Resta sempre lo spazio per una scatola che concorda su quei mille e diverge sul successivo. Per questo un punteggio alto su un benchmark non è una garanzia: è un vincolo, e i vincoli lasciano sempre dei gradi di libertà.

La varietà del sondaggio comanda tutto

Resta da legare l’identificazione alla legge che attraversa questa Parte. La qualità di un modello black-box è limitata, in modo duro, dalla varietà degli ingressi con cui si sonda.

Se gli ingressi esplorano dieci situazioni distinte, il modello può distinguere al più dieci comportamenti: tutto ciò che la scatola fa di diverso nelle situazioni non sondate resta invisibile, e il modello lo riempirà con un’interpolazione arbitraria — di solito quella che gli è più comoda, non quella vera.

È la legge della varietà necessaria applicata all’esperimento, non al regolatore: per identificare $N$ comportamenti interni distinti servono almeno $N$ ingressi che li mettano in luce.

Un sondaggio povero di varietà non è un sondaggio rapido: è un sondaggio che produce un modello sicuro di sé e sbagliato. La maggior parte dei fallimenti “a sorpresa” di un sistema black-box è, vista da qui, un fallimento di experiment design deciso molto prima — quando si è scelto cosa immettere.

Il legame con il comportamentismo

Lo schema epistemico della scatola nera ha un gemello in psicologia: il comportamentismo (behaviorism), la corrente che da John Watson (psicologo statunitense, che nel 1913 pubblica il manifesto del movimento) fino a B. F. Skinner studia la mente trattandola come inaccessibile.

Si osservano lo stimolo e la risposta — l’ingresso e l’uscita — e si rifiuta per metodo di parlare di stati mentali interni, considerati non misurabili e quindi fuori dalla scienza. La mente, per il comportamentista, è la scatola nera dell’organismo.

Qui è obbligatorio marcare la classe dell’affermazione, perché è il punto in cui un capitolo scivola facilmente. Il rapporto tra la scatola nera della cibernetica e il comportamentismo psicologico è un’analogia strutturale forte, non una filiazione. Lo stesso schema epistemico — studiare solo ingresso e uscita, non l’interno — applicato a domini diversi.

Non c’è evidenza che Ashby o Wiener derivino il concetto da Watson, né viceversa. Sono figli dello stesso clima scientifico anti-introspezionista di inizio Novecento: Wiener tratta il pilota come scatola nera negli stessi anni in cui il comportamentismo domina la psicologia americana. Convergenza, non discendenza — e il capitolo lo dichiara per non far scivolare il lettore verso un legame causale che non esiste.

C’è un dettaglio storico che rende il parallelo più che una coincidenza di metodo. Il comportamentismo nasce come reazione all’introspezione: i fondatori volevano una psicologia che potesse misurare, e gli stati mentali interni — non misurabili da terzi — venivano esclusi per disciplina scientifica, non per convinzione che non esistessero. La scatola nera della cibernetica fa la stessa mossa per la stessa ragione: non nega che dentro ci sia un meccanismo, sospende il discorso sul meccanismo perché non è osservabile. Entrambe le posizioni sono epistemologie dell’umiltà metodologica, non metafisiche dell’assenza.

Il parallelo ha una coda contemporanea che vale tutto il capitolo. La psicologia ha superato il comportamentismo puro con la rivoluzione cognitiva degli anni Cinquanta e Sessanta, che torna a parlare di rappresentazioni interne e processi mentali — la mente smette di essere una scatola da non aprire e diventa qualcosa di cui ricostruire l’architettura. La svolta fu possibile non perché qualcuno decise che gli stati interni erano leciti, ma perché arrivarono strumenti nuovi: il vocabolario dell’informazione, il computer come metafora del processo, esperimenti che misuravano i tempi di reazione come finestre indirette sul calcolo mentale. Lo stesso identico movimento, si vedrà tra poco, si sta ripetendo nell’interpretabilità dei modelli di AI, e per la stessa ragione: non un cambio di permessi, ma l’arrivo di strumenti per guardare dentro.

Il ponte verso l’AI e l’agent coding

L’LLM come scatola nera

Un modello di deep learning, e in particolare un LLM, è la scatola nera per eccellenza del presente.

E qui serve una marcatura precisa: non si tratta di un’analogia didattica, si tratta di identità. Un LLM soddisfa alla lettera la definizione di Ashby — un sistema noto solo per i suoi ingressi e le sue uscite, con un meccanismo interno opaco. La scatola nera del 1956 e l’LLM del 2026 sono lo stesso concetto, non due cose che si somigliano. Quando Ashby scrive “all real objects are Black Boxes”, un LLM rientra nella frase senza bisogno di adattarla.

C’è un’obiezione immediata: i pesi di un LLM sono visibili, sono numeri in una matrice, dove sta l’opacità?

La risposta separa due cose che è facile confondere. Visibili non vuol dire leggibili. Vedere miliardi di numeri non è capire l’algoritmo che quei numeri realizzano. L’opacità della scatola nera LLM non è un’opacità di accesso — i pesi si possono scaricare — ma un’opacità di interpretazione: nessuno sa guardare quei pesi e dire “ecco la riga dove il modello decide”.

È esattamente il punto di Ashby quando dice che aprire la scatola sposta soltanto il confine: dentro un LLM aperto trovi attivazioni che vanno a loro volta interpretate, scatole dentro scatole. La differenza con un programma scritto a mano è netta. Un programma è già nella forma compressa e leggibile — il codice sorgente è il modello. I pesi di un LLM sono il protocollo della scatola, congelato; il modello compresso e leggibile, quello, va ancora trovato.

Le due strade per aprire la scatola

Da questa opacità nascono due programmi di ricerca diversi, e la distinzione tra i due struttura l’intera interpretabilità dei modelli moderni.

La prima strada è l’interpretabilità black-box, o comportamentale (behavioral). Si resta fuori dalla scatola. Si sonda con ingressi scelti, si fa probing comportamentale, si costruiscono valutazioni — le eval — e benchmark, si fa red-teaming, cioè sondaggio adversariale sistematico per scovare i comportamenti indesiderati.

È, alla lettera, l’esperimento di Ashby applicato a un LLM: ingressi dentro, uscite fuori, protocollo, modello del comportamento. Valutare un LLM è fare scienza black-box. Si stima un modello del comportamento del sistema a partire da un campione di coppie prompt-risposta, e quel modello è valido nella regione sondata e incerto fuori, esattamente come ogni identificazione di sistema.

La seconda strada è l’interpretabilità meccanicistica (mechanistic interpretability). Si apre la scatola. Si guardano pesi e attivazioni, si cerca di fare reverse engineering dei circuiti, delle feature, degli algoritmi che il modello implementa nei suoi parametri.

È un programma che si appoggia al dibattito raccontato nel capitolo Quando scomporre funziona e quando no: scomporre un sistema nei suoi pezzi funziona quando quei pezzi hanno funzioni isolabili, e parte della difficoltà della mechanistic interpretability è proprio scoprire se le reti neurali abbiano pezzi di quel tipo. Non è scontato che li abbiano: una funzione potrebbe essere distribuita su molti pesi senza un “luogo” preciso da indicare.

Il parallelo con la psicologia non è una suggestione di chi scrive: è argomentato in un paper. The Cognitive Revolution in Interpretability (Adam Davies e Ashkan Khakzar, arXiv 2024) sostiene che il passaggio dall’interpretabilità comportamentale a quella delle rappresentazioni e degli algoritmi interni “echoes the ‘cognitive revolution’ in 20th-century psychology that shifted the study of human psychology from pure behaviorism toward mental representations and processing” — riecheggia la rivoluzione cognitiva che spostò lo studio della mente dal comportamentismo puro verso le rappresentazioni e i processi mentali.

La storia della psicologia si sta ripetendo, passo per passo, sulle reti neurali. Prima il behaviorism, poi la svolta verso l’interno. Vale la pena marcare la classe di questa affermazione: è un’analogia storica robusta, sostenuta da chi lavora nel campo, non un teorema. Le due interpretabilità — comportamentale e meccanicistica — non sono in competizione: sono complementari, come lo sono diventate, nella psicologia matura, lo studio del comportamento e quello dei processi cognitivi. Il red-teaming dice che un modello sbaglia; la mechanistic interpretability prova a dire perché. Servono entrambe.

Il modello come scatola nera nelle API

C’è un caso in cui la scatola nera non è una scelta di metodo ma un vincolo definitivo. Quando si usa un modello via API — quella di Anthropic, di OpenAI, di Google — non si vedono affatto i pesi: si ha soltanto l’interfaccia ingresso-uscita.

Per chi costruisce un prodotto sopra un’API, il modello è una scatola nera in senso stretto, e non c’è interpretabilità meccanicistica possibile perché non c’è accesso all’interno. La seconda strada è chiusa per costruzione: resta solo la prima.

Tutto ciò che si può fare è identificazione del sistema da fuori. È nato attorno a questo un intero filone di tecniche di auditing black-box.

Test statistici per verificare se un’API stia davvero servendo il modello dichiarato e non un modello più piccolo e più economico. Fingerprinting per riconoscere quale modello c’è dietro un endpoint. Ricostruzione della struttura del system prompt dai soli pattern di rifiuto. Sono tutte applicazioni della stessa procedura di Ashby a una scatola che non si può aprire nemmeno volendo.

C’è una differenza di posta in gioco rispetto al laboratorio del 1956. La scatola nera di Ashby era un esercizio epistemologico; la scatola nera di un’API è un rapporto commerciale e contrattuale. Chi paga per un modello vuole sapere se sta ricevendo ciò per cui paga, e l’unica leva che ha è il sondaggio dall’esterno. L’identificazione del sistema, qui, è anche una forma di verifica e di tutela.

L’agente come scatola nera

L’ultimo ponte è il più operativo. Capire un agente — un sistema che usa un LLM per compiere azioni in più passi — a partire dai suoi soli comportamenti è il problema della scatola nera in forma quotidiana.

Un agente fallisce un task: il guasto è nel modello, nel prompt, in un tool che ha risposto male, nello stato che si è corrotto strada facendo? Senza osservabilità interna — senza trace, senza log delle decisioni intermedie — ci si trova davanti a una scatola nera, e l’unica mossa è sondare dall’esterno, riprovare con ingressi variati, congetturare.

Progettare quei trace, quei log, quelle decisioni rese ispezionabili, significa spostare il confine dell’agente da nero verso grigio: rendere visibile abbastanza meccanismo interno da poter diagnosticare invece di indovinare. È il motivo per cui l’osservabilità degli agenti non è un lusso operativo ma una precondizione del debugging, e il filo che lega questo capitolo al concetto di osservabilità della Parte sulla teoria dei sistemi.

Valutare un modello è fare scienza

Conviene fermarsi su un punto che attraversa tutti i ponti precedenti, perché cambia il modo di leggere il proprio lavoro.

Quando un team costruisce una eval per un LLM, non sta facendo controllo qualità nel senso di una checklist. Sta facendo scienza black-box: sta costruendo un modello del comportamento di un sistema opaco a partire da un campione di osservazioni. Le stesse domande che si pone uno scienziato davanti a un fenomeno naturale si pongono qui.

Il campione è rappresentativo? Gli ingressi coprono la varietà dei casi reali, o solo quelli comodi da scrivere? Il modello del comportamento generalizza, o ha solo riassunto i casi visti? È robusto a piccole variazioni dell’ingresso? Sono le domande del metodo sperimentale, e una eval che non se le pone produce un modello del comportamento che vale meno della carta su cui è scritto.

Questa lettura ha una conseguenza pratica. Le competenze che servono a valutare bene un LLM non sono diverse, nella sostanza, da quelle che servono a uno sperimentatore: disegnare gli ingressi, controllare le variabili, diffidare dei risultati troppo belli, validare fuori campione.

Chi tratta la valutazione di modelli come un’attività di routine, e non come scienza dell’identificazione di un sistema, sta sotto-stimando la difficoltà del problema — e di solito se ne accorge quando il modello fallisce su un caso che la sua eval non aveva mai sollecitato. La scatola nera del 1956 non è un capitolo di storia: è il manuale di metodo di chiunque oggi metta alla prova un modello.

Esempi

Esempio 1 — sondare una porta logica

Una scatola ha due morsetti d’ingresso e uno d’uscita. Si decide di sondarla con tutte le combinazioni possibili di bit e si registra il protocollo:

ingresso (0,0)  ->  uscita 0
ingresso (0,1)  ->  uscita 1
ingresso (1,0)  ->  uscita 1
ingresso (1,1)  ->  uscita 1

Quattro righe, e il modello è immediato: la scatola realizza un OR logico. Ma il modello dice cosa fa la scatola, non come.

Lo stesso identico protocollo lo darebbero un OR a relay, uno a transistor, una lookup table stampata su carta, o una persona che applica la regola a mente. Il protocollo identifica la funzione, e lascia indeterminata l’intera classe dei meccanismi che la calcolano. Qui la classe è chiusa solo perché lo spazio degli ingressi è minuscolo: quattro combinazioni, tutte sondabili. È un lusso che si perde appena la scatola si fa più grande.

E c’è un secondo punto, nascosto. Le quattro righe bastano solo se la scatola è senza memoria. Se l’uscita dipendesse anche dagli ingressi passati — se la scatola avesse uno stato interno — quattro coppie isolate non basterebbero.

Immagina una scatola che restituisce 1 solo se l’ingresso corrente è (1,1) e anche l’ingresso precedente era (1,1). Sondandola con le quattro combinazioni una alla volta, in ordine, non si vedrebbe mai due (1,1) di fila: il protocollo direbbe “restituisce sempre 0 su (1,1)”, una conclusione falsa. Per identificare una scatola con memoria servono sequenze, e bisogna sondare anche l’effetto dell’ordine — quale ingresso viene prima di quale.

Quattro prove che sembrano esaurire una scatola a due ingressi possono coprire solo una fetta di una scatola con memoria. E dall’esterno non c’è modo di sapere, prima di sondare bene, se la scatola la memoria ce l’ha. È il motivo per cui un LLM, che ha memoria di tutto il contesto, non si valuta con prompt isolati: la risposta a un prompt dipende da cosa c’è prima nella conversazione, e un protocollo di prompt scollegati identifica la scatola sbagliata.

Esempio 2 — black-box testing nel codice

Sondare una funzione di cui non si vuole leggere il sorgente: la si chiama con molti valori d’ingresso, si registra cosa restituisce, si congettura cosa fa.

# la funzione f viene trattata come opaca
casi = [-3, -1, 0, 1, 2, 5, 10]
for x in casi:
    print(x, "->", f(x))
# protocollo osservato:
# -3 -> 0   -1 -> 0   0 -> 0   1 -> 1   2 -> 4   5 -> 25   10 -> 100

Dal protocollo si congettura: f(x) restituisce x*x per x positivo e 0 per x non positivo. È esattamente il black-box testing, la pratica di verificare che ingressi specificati producano uscite attese trattando il codice come opaco.

Qui l’opacità è una scelta metodologica, non un vincolo: il sorgente in linea di principio si potrebbe leggere — sarebbe white-box testing — ma si decide di non farlo, per testare il comportamento e non l’implementazione. La scatola nera, in questo caso, la si costruisce apposta. Il motivo è solido: un test che non guarda il codice non si rompe quando il codice viene riscritto, purché il comportamento resti lo stesso.

Esempio 3 — valutare un LLM via API

Un team integra un LLM nel proprio prodotto attraverso un’API. Non possiede i pesi, non li possiederà mai. Per decidere se quel modello è adatto, costruisce una eval: un insieme di prompt rappresentativi dei casi d’uso reali, raccoglie le risposte del modello, e le valuta secondo criteri definiti.

È la procedura di Ashby, punto per punto. Progettare gli ingressi: scegliere prompt che coprano la varietà dei casi reali — se ne sceglie pochi e simili, si identifica solo una fetta del comportamento. Registrare il protocollo: la tabella di coppie prompt-risposta.

Stimare il modello del comportamento: “questo modello è affidabile sull’estrazione di dati strutturati, debole sull’aritmetica a più cifre, prudente sui temi sensibili”. A questo il team aggiunge il red-teaming — ingressi adversariali, costruiti apposta per trovare i buchi che il sondaggio ordinario non tocca. È sondaggio attivo portato al limite: si vanno a cercare gli ingressi che fanno fallire la scatola.

Il modello del comportamento che ne esce non è il meccanismo del modello: è una mappa comportamentale, valida nella regione sondata e incerta fuori. Esattamente come ogni identificazione di sistema, e con esattamente lo stesso limite che Ashby aveva enunciato settant’anni prima: il protocollo non fissa il meccanismo, e due modelli che coincidono su mille prompt possono divergere sul milleunesimo.

Esempio 4 — diagnosticare un agente che fallisce

Un agente di coding deve correggere un bug in un repository. Riceve il task, esplora i file, modifica il codice, lancia i test. Su un certo task fallisce: i test restano rossi. Chi lo ha costruito vede solo questo — task in ingresso, fallimento in uscita. Una scatola nera con un protocollo di una riga.

La domanda di diagnosi è: dov’è il guasto? Nel modello, che ha ragionato male? Nel prompt di sistema, che non gli ha dato le istruzioni giuste? In un tool, che ha restituito un output fuorviante? Nello stato della sessione, che si è riempito di contesto irrilevante e ha confuso il modello? Quattro ipotesi, e dal protocollo a una riga non se ne può scartare nessuna.

L’unica via, finché la scatola resta nera, è sondare: rilanciare il task variando un elemento alla volta — un prompt diverso, un tool sostituito con uno mock affidabile, una sessione ripulita — e osservare quale variazione cambia l’uscita. È identificazione del sistema fatta a mano, lenta e incerta, perché ogni prova costa una run intera dell’agente.

Il salto di qualità arriva quando si dà all’agente osservabilità interna: un trace strutturato che registra ogni passo — quale tool è stato chiamato, con quali argomenti, cosa ha risposto, cosa il modello ha deciso dopo.

A quel punto il protocollo non è più una riga, sono cinquanta: una per ogni passo intermedio. La scatola è passata da nera a grigia, e la diagnosi smette di essere un indovinello e diventa una lettura. Si vede che il tool al passo dodici ha restituito un path sbagliato, e il resto del fallimento discende da lì.

È lo stesso identico salto che la psicologia ha fatto con la rivoluzione cognitiva: non più solo stimolo e risposta, ma una finestra sui passi intermedi. Progettare i trace di un agente è, letteralmente, decidere quanto grigia rendere la sua scatola.

Applicazioni pratiche

Valutazione di modelli e benchmark. Ogni eval è un’identificazione di sistema black-box: si stima un modello del comportamento da un campione di coppie ingresso-uscita.

La qualità dell’eval dipende dalla varietà degli ingressi, nello stesso modo in cui la qualità di un’identificazione dipende dall’experiment design. Un benchmark con prompt poco vari sonda poco, e un punteggio alto su quel benchmark dice poco sul comportamento fuori dalla sua regione.

Red-teaming. È sondaggio adversariale: ingressi scelti per trovare i comportamenti indesiderati che il sondaggio normale non raggiunge.

Nei termini di questo capitolo, è experiment design orientato ai casi peggiori — si progettano apposta gli ingressi che separano i membri “cattivi” della classe di meccanismi compatibili da quelli accettabili. Un red-teaming che non trova nulla non è una buona notizia: spesso è solo un sondaggio che non ha cercato abbastanza in là.

Auditing di API. Verificare che un’API serva davvero il modello dichiarato, fare fingerprinting del modello dietro un endpoint, monitorare il drift nel tempo: sono tutte identificazioni di sistema su una scatola che non si può aprire per vincolo di accesso.

Lo strumento è statistico, l’epistemologia è quella di Ashby. La scatola, qui, non è solo opaca: è anche di proprietà di qualcun altro, e questo aggiunge al problema una dimensione di verifica contrattuale.

Debugging di agenti. Un agente è una scatola nera finché non gli si dà osservabilità interna. Progettare trace, log strutturati delle decisioni e checkpoint dello stato significa spostare il confine da nero a grigio, e trasformare il debugging da indovinello a diagnosi.

Decidere quando aprire la scatola. Non sempre conviene la mechanistic interpretability. Per molti scopi operativi un buon modello black-box del comportamento basta — è il principio dell’Identification for Control: un modello imperfetto è spesso sufficiente.

Aprire la scatola conviene quando le poste in gioco — sicurezza, allineamento, comportamenti rari ma gravi — rendono insufficiente la sola mappa comportamentale. È una decisione di costo: l’interpretabilità meccanicistica è cara, e va spesa dove la mappa comportamentale, da sola, lascerebbe un rischio inaccettabile.

Dove si rompe

Il concetto di scatola nera è potente proprio perché è generale, e la sua generalità è anche il suo punto debole: applicato senza attenzione produce errori ricorrenti.

Vale la pena attraversarli uno per uno, perché sono gli errori che ricompaiono ogni volta che si valuta un sistema opaco — un modello, un’API, un agente.

“Black box vuol dire che non sappiamo niente.” È il fraintendimento più comune e il più sbagliato. Black box vuol dire che si sa solo ciò che il protocollo ingresso-uscita rivela — e può essere moltissimo.

Un modello black-box ben sondato predice il comportamento con grande precisione. Quello che manca non è la conoscenza: è il meccanismo. Una scatola nera ben identificata è un oggetto molto conosciuto, di cui si ignora soltanto l’interno. L’astronomia ha predetto eclissi con secoli di anticipo trattando il sistema solare come una scatola da osservare, molto prima di sapere cosa fosse la gravità.

Confondere il modello black-box con il meccanismo. Il modello riproduce il comportamento; non è ciò che sta dentro. Confondere i due porta a un errore preciso: fidarsi del modello fuori dalla regione sondata, dove la classe dei meccanismi compatibili si separa.

Un modello che combacia con mille osservazioni non garantisce nulla sulla milleunesima, perché di meccanismi che combaciano con quelle mille ce ne sono molti, e divergono altrove. È l’errore dell’esempio numerico del polinomio, ripetuto in scala: tre punti coincidenti, e poi la sorpresa.

Black box non vuol dire imprevedibile. Una scatola nera può essere perfettamente deterministica. Opaca e casuale sono due proprietà diverse: si può predire benissimo l’uscita di una scatola senza avere la minima idea di come quell’uscita sia prodotta.

Il modello black-box di un sistema deterministico opaco può essere preciso al cento per cento. L’opacità riguarda il meccanismo, non la prevedibilità. Confondere le due porta a un pessimismo ingiustificato: “è una scatola nera, quindi non possiamo fidarci” è un non sequitur — la fiducia si costruisce sul protocollo, non sulla trasparenza del meccanismo.

Pensare che aprire la scatola la renda trasparente. Aprire sposta il confine di un livello: dentro ci sono altre scatole.

Vale per il cervello — i neuroni, una volta esposti, restano oggetti opachi da sondare — e vale per gli LLM, dove le attivazioni interne, una volta rese visibili, vanno a loro volta interpretate. La trasparenza totale è un limite ideale, non uno stato raggiungibile aprendo un coperchio.

Il problema dell’identificazione mal posta. Se gli ingressi con cui si sonda hanno poca varietà, l’identificazione è sotto-determinata in modo grave: il protocollo è compatibile con un’enorme classe di modelli, e il modello stimato è poco più di un’ipotesi.

Un’eval con prompt monotoni, un red-teaming pigro, un benchmark ristretto: tutti producono modelli del comportamento che sembrano solidi e non lo sono. Il fallimento successivo “su un caso imprevisto” è spesso, in realtà, un caso “non sondato” — la varietà mancava già nell’experiment design. La parola “imprevisto”, in questi rapporti di incidente, andrebbe spesso letta come “non immesso”.

L’illusione della scatola bianca. Avere accesso all’interno non garantisce di capirlo. I pesi di un LLM open-weights sono interamente visibili, eppure il modello resta opaco.

È la trappola simmetrica della prima: come “black box” non significa ignoranza totale, “white box” non significa comprensione. La trasparenza di accesso e la trasparenza di interpretazione sono cose diverse, e confonderle porta a sopravvalutare cosa si capisce di un modello solo perché se ne possiedono i pesi. Un modello open-weights non è un modello capito: è un modello la cui scatola si può aprire, il che è solo il primo passo.

Quando il sistema cambia mentre lo sondi. L’identificazione assume, implicitamente, che la scatola sia la stessa per tutta la durata del sondaggio. Un modello aggiornato dietro un’API, un sistema che apprende mentre opera, un agente il cui stato evolve: in questi casi il protocollo mescola misure di scatole diverse, e il modello stimato non corrisponde a nessuna di esse. È una delle ragioni per cui l’auditing di API non è mai concluso una volta per tutte.

La scatola che reagisce a chi la sonda. C’è un caso peggiore del precedente: la scatola non solo cambia, ma cambia in risposta al sondaggio. Un sistema che riconosce di essere sotto valutazione e si comporta diversamente da come si comporterebbe in produzione rende il protocollo non solo instabile ma ingannevole — il modello stimato descrive il comportamento “sotto esame”, non quello reale. È un rischio concreto per la valutazione di modelli capaci, e non ha analogo nella scatola nera elettromeccanica di Ashby: una valvola non sa di essere misurata. Qui l’oggetto del sondaggio è abbastanza complesso da avere un comportamento condizionato dal contesto di sondaggio, e questo erode l’assunzione di fondo dell’intero metodo.

Confondere la scatola con la sua interfaccia. Quando si usa un modello via API, la scatola che si sonda non è il modello: è il modello più tutto ciò che lo avvolge — il system prompt del provider, i filtri di sicurezza, l’eventuale routing verso modelli diversi, il caching. Il protocollo raccolto identifica quel sistema composto, non il modello nudo. Attribuire al modello un comportamento che in realtà viene da un filtro a monte è un errore di confine, nel senso del capitolo sui confini del sistema: si è disegnata la scatola nel punto sbagliato.

Collegamenti

Wiener: comunicazione e controllo in animali e macchine — la scatola nera nasce come strumento concettuale della cibernetica; Wiener tratta il pilota nemico come scatola nera già nel predittore antiaereo.
La legge della varietà necessaria — per distinguere $N$ comportamenti interni servono almeno $N$ ingressi distinguibili: sondare una scatola nera richiede varietà nell’experiment design.
Ashby, omeostato e adattamento — lo stesso libro e lo stesso autore: An Introduction to Cybernetics contiene sia l’omeostato sia il capitolo sulla scatola nera.
Cosa posso misurare, cosa posso governare — la scatola nera è il caso limite dell’osservabilità ridotta: sistemi internamente diversi che danno lo stesso protocollo sono indistinguibili dall’esterno.
Modelli descrittivi, predittivi, prescrittivi — white, black e grey box sono modelli ordinati per quanto meccanismo interno incorporano.
Quando scomporre funziona e quando no — aprire la scatola e scomporla nei suoi pezzi è una scommessa riduzionista; la mechanistic interpretability ne è un caso contemporaneo.
Scegliere il confine cambia il problema — dove si traccia il confine della scatola cambia cosa sono ingresso e uscita, e quindi l’identificazione.
Stato, transizione, traiettoria — le equazioni di stato e uscita usate nella meccanica dell’identificazione sono il vocabolario dei sistemi dinamici.
Cervello, colonne, aree funzionali — il cervello come scatola nera dell’organismo: aprirlo sposta il confine ai neuroni, anch’essi opachi.
Maximum likelihood: fittare modelli massimizzando probabilità — la stima dei parametri nel passo di fitting dell’identificazione.
mech-interp-intro (in preparazione) — il programma esplicito di aprire la scatola LLM: probing, sparse autoencoders, analisi dei circuiti.
benchmark-llm (in preparazione) — la valutazione dei modelli come identificazione di sistema black-box.
red-teaming (in preparazione) — il sondaggio adversariale come experiment design orientato ai casi peggiori.

Per andare oltre

W. Ross Ashby, An Introduction to Cybernetics, Chapman and Hall, 1956 — il capitolo 6, “The Black Box”, è la fonte primaria del concetto; il testo integrale è disponibile su Internet Archive.
Adam Davies, Ashkan Khakzar, The Cognitive Revolution in Interpretability: From Explaining Behavior to Interpreting Representations and Algorithms, arXiv:2408.05859, 2024 — argomenta il parallelo tra interpretabilità delle reti neurali e rivoluzione cognitiva in psicologia.
Elizabeth R. Petrick, Building the Black Box: Cyberneticians and Complex Systems, Science, Technology, & Human Values, SAGE, 2020 — storia di come i cibernetici adottarono e ridefinirono un concetto degli ingegneri elettronici.
Voce System identification su Wikipedia — panoramica accessibile su white, grey e black box e sulla procedura di identificazione dei sistemi dinamici.
Voce Black box su Wikipedia — sintesi della definizione sistemica, della storia del termine e della formalizzazione di Bunge.