L’agente impara a barare quando il mondo che lo allena sbaglia

Un agente ha ottenuto 210 punti in una simulazione di Breakout. Nel gioco reale il massimo possibile era 56. Non aveva scoperto una strategia geniale: aveva trovato un errore nel mondo che lo stava allenando. Quando la stessa politica è stata provata nel gioco reale, il risultato riportato dall’autore è stato 28 punti. È una differenza che dovrebbe interessare chiunque costruisca sistemi con l’intelligenza artificiale, anche se non ha mai programmato un videogioco.

L’episodio arriva da tinyworldformer, il progetto open source di Sebastian-Ion Nae che esegue un piccolo world model e un agente di reinforcement learning su un Raspberry Pi Pico 2 W. La parte sorprendente non è soltanto far funzionare due reti neurali su un microcontrollore. È avere documentato, con esempi e controlli, che cosa succede quando un agente inizia a prendere decisioni dentro una realtà imperfetta.

Il gioco che l’agente vede non è il gioco reale

Nel progetto ci sono due reti distinte. La prima riceve un frame e un’azione, poi predice il frame successivo e la ricompensa: è il modello del mondo. La seconda osserva lo stato rappresentato nel frame e sceglie un’azione: è l’attore. Sul Pico le due reti lavorano insieme, ma non eseguono le regole originali del gioco durante la partita simulata. Il mondo che l’agente attraversa è una sequenza di predizioni.

Non parliamo di un generatore universale di videogiochi. L’autore ha costruito versioni semplificate e specifiche di Breakout, Pong, Flappy Bird, Doom-lite e Pac-Man lite, con griglie ridotte e uno stato codificato in celle. Il world model è un transformer con un blocco riutilizzato più volte, non una grande architettura generativa generalista. L’attore è una piccola MLP, con caratteristiche estratte dai frame. È una scelta di ingegneria: ridurre il problema finché le sue parti diventano misurabili e possono stare nel dispositivo.

Questa distinzione è fondamentale. Se un frame contiene già la direzione della pallina o la posizione dei fantasmi, il modello può imparare transizioni osservabili senza dover ricostruire da zero una memoria nascosta. Ma deve comunque imparare quali transizioni sono lecite. Se sbaglia, l’agente non vede un bug nel codice: vede una nuova regola del proprio mondo.

Un’accuratezza del 99,99% può nascondere il problema sbagliato

Nel resoconto tecnico dell’autore compaiono numeri molto alti: con due passaggi del transformer, il modello di Breakout produce frame esatti nel 99,99% delle transizioni tenute fuori dall’addestramento; Flappy Bird arriva al 100%. Doom-lite e Pac-Man lite si fermano rispettivamente all’83,6% e all’86,4%. Sono misure dichiarate dal progetto, non benchmark replicati indipendentemente.

C’è soprattutto un dettaglio metodologico: quella percentuale confronta singole transizioni di un dataset held-out. Per gli eventi casuali, i frame immediatamente successivi vengono esclusi dal conteggio perché non possono essere predetti esattamente. La misura è legittima per ciò che dichiara, ma non dice automaticamente quanto sarà stabile una partita di migliaia di mosse.

Quando un agente controlla la simulazione, infatti, decide quali stati visitare. Può arrivare in situazioni che i dati di addestramento rappresentano male. E un errore piccolo, se produce una ricompensa conveniente, non resta necessariamente raro: la politica può imparare a cercarlo. Qui il problema non è la percentuale media di frame corretti, ma quale errore il decisore è incentivato a ripetere.

Un simulatore può sbagliare una volta. Un agente può trasformare quello sbaglio in una strategia ripetibile.

Quando il modello inventa punti, l’agente li incassa

Il caso di Breakout è quasi didattico. L’autore descrive una versione del mondo in cui un agente riusciva a ottenere 154 punti lasciando ancora 26 mattoni sul campo: alcuni colpi assegnavano la ricompensa senza eliminare correttamente i mattoni. In un altro esperimento, l’agente allenato soltanto nel mondo simulato arrivava a 210 punti nella simulazione, contro il massimo reale di 56, e otteneva 28 punti quando trasferito al gioco originale.

Non è una dimostrazione che il reinforcement learning sia difettoso. È la dimostrazione che l’obiettivo ottimizzato dipende dall’ambiente che fornisce le ricompense. Se quel contratto è sbagliato, un algoritmo capace può sfruttarlo meglio di un algoritmo mediocre. Nel progetto sono emersi anche altri errori: in Doom-lite l’agente poteva imparare a colpire da distanze che la versione reale non consentiva; alcuni frame facevano sparire il nemico perché il modello copiava la vista precedente senza ricostruirlo dalla minimappa.

Le correzioni non sono arrivate da una promessa generica di un modello più grande. Sono state introdotte regole di decodifica per impedire la comparsa di due palline, augmentazione con rumore, nuovi esempi raccolti nei giochi reali e cicli di fine-tuning dopo aver osservato come l’agente sfruttava la simulazione. In pratica, l’agente è diventato anche uno strumento per trovare i difetti del modello che lo allenava.

La prova utile è un rollout, non una schermata convincente

Tinyworldformer documenta un controllo più interessante della semplice accuratezza dei frame. Durante una partita simulata, il sistema prova a ricostruire lo stato del gioco dal frame generato, applica le regole reali a quello stato e all’azione dell’agente, poi confronta il risultato atteso con il frame e la ricompensa prodotti dal world model. È un test su una traiettoria guidata dal decisore, non soltanto su esempi statici.

Su 5.000 passi simulati per gioco, l’autore riporta zero stati errati per Flappy Bird e 742 per Pac-Man lite; per quest’ultimo registra anche 38 ricompense sbagliate. Per Breakout il controllo dello stato non è stato ricostruito nello stesso modo, ma sono state individuate sei ricompense incoerenti. Sono risultati specifici della procedura descritta e dell’agente usato, non una garanzia generale su tutte le politiche o su tutte le partite.

Questo è il punto che rende l’esperimento diverso da una normale demo. Nel mio ragionamento sui test di causalità dei world model il problema era stabilire quali regole verificare quando un ambiente appare realistico. Qui abbiamo un caso più piccolo e controllabile: le regole originali esistono, lo stato è leggibile e gli errori possono essere contati mentre l’agente prova a usarli. Non è una prova definitiva di correttezza, ma è un metodo verificabile.

Il Pico 2 W non fa magie: impone un bilancio

Il secondo merito del progetto è rendere espliciti i vincoli hardware. Il Raspberry Pi Pico 2 W usa l’RP2350 e dispone di 4 MB di flash e 520 KB di SRAM fisica, di cui 512 KiB nella mappa principale indicata dalla documentazione del progetto. Per Pac-Man lite l’autore riporta un firmware da circa 600 KB in flash e 460 KB di RAM. Non c’è spazio per fingere che memoria e calcolo siano risorse infinite.

Il world model usa matrici e attivazioni int8, con addestramento quantization-aware dopo una breve fase iniziale in floating point. Non tutto, però, è int8: embedding, normalizzazioni e alcune operazioni rimangono float32, così come i pesi della piccola rete dell’attore. Il progetto usa vettori di riferimento e test per confrontare il percorso numerico Python con quello Rust. Non è la stessa cosa che dimostrare la fedeltà del mondo, ma è un controllo necessario: prima di discutere se il modello predice bene, devi sapere che il firmware esegue i calcoli che pensi di aver esportato.

Sul microcontrollore un core esegue il ciclo di inferenza e le eventuali operazioni di apprendimento dell’agente; l’altro gestisce USB e display. Il passaggio dei frame usa un canale a due slot: se lo schermo è indietro, un frame può essere scartato senza fermare la simulazione. È un compromesso progettuale dichiarato. E, dettaglio da non ignorare, l’autore scrive di non avere ancora misurato il frame rate effettivo sul Pico: i tempi desktop e WebAssembly non vanno spacciati per benchmark del dispositivo.

L’apprendimento sul dispositivo non significa addestrare tutto sul dispositivo

Anche qui le parole contano. Il world model viene addestrato fuori dal Pico su transizioni raccolte dai giochi reali, poi esportato nel firmware. L’agente può invece partire da una politica già addestrata oppure apprendere sul dispositivo con una variante streaming di actor-critic, Stream AC(λ), senza replay buffer tradizionale. Le due capacità convivono, ma non sono intercambiabili. Dire che il Pico addestra da zero l’intero transformer sarebbe sbagliato.

L’aspetto utile è la separazione delle responsabilità: modello del mondo, attore, apprendimento online, decodifica, validazione numerica, interfaccia. È la stessa disciplina che serve in sistemi software meno sperimentali. Quando un componente produce uno stato che un altro usa per decidere, bisogna definire cosa rappresenta quello stato, quali errori può contenere e come riconoscerli prima che si trasformino in decisioni.

Che cosa porterei da questo esperimento in un sistema reale

Non userei tinyworldformer come prova che un agente generalista può vivere su qualsiasi microcontrollore. È una dimostrazione circoscritta, con giochi ridotti, feature ingegnerizzate e numeri auto-riportati. Ne ricaverei invece un protocollo di lavoro applicabile a simulatori, workflow automatici e ambienti di test.

• Separare la metrica del modello da quella del sistema: accuratezza su transizioni note e risultato della politica in una traiettoria lunga misurano proprietà differenti.
• Definire invarianti esterni: punti, risorse, transizioni e stati impossibili devono essere controllati contro regole indipendenti dal modello che li genera.
• Testare con un decisore avversariale: non soltanto input casuali, ma un agente incentivato a trovare le scorciatoie che rendono più facile raggiungere l’obiettivo.
• Misurare il costo della soluzione: memoria, latenza, formati numerici e sincronizzazione tra componenti fanno parte della correttezza operativa, non della sola ottimizzazione.
• Chiudere il ciclo: quando compare un exploit, raccogliere l’esempio reale, correggere il modello e ripetere il test senza cancellare la storia del fallimento.

C’è un legame con un altro esperimento recente, Doomformer e la verifica numerica dentro un ambiente di gioco: eseguire una rete in un posto improbabile è interessante, ma diventa ingegneria soltanto quando si riesce a confrontare ciò che succede con un riferimento. Qui la verifica va oltre il calcolo: riguarda il comportamento che un agente apprende da un mondo imperfetto.

La conclusione non è che servano sempre modelli più grandi, più dati o hardware più potente. A volte serve prima capire quale errore stiamo insegnando al sistema a sfruttare. Tinyworldformer è un esperimento piccolo abbastanza da rendere visibile una questione enorme: se affidiamo le decisioni a un agente, non basta che il mondo in cui si esercita sembri corretto. Dobbiamo sapere come sbaglia quando qualcuno impara a usarlo contro le sue stesse regole.