Controllo classico, RL e dove si sovrappongono

Due comunità hanno passato decenni a risolvere lo stesso problema con lessici diversi: scegliere azioni per ottimizzare un obiettivo in un sistema che evolve nel tempo. La differenza non è nel problema, è in una sola domanda — conosco il modello del sistema, o devo impararlo dai dati? Da quella domanda discende tutto: garanzie, campioni, vincoli, interpretabilità, e la scelta pratica di quale strumento prendere in mano.

Perché questo capitolo

C’è una scena che si ripete in ogni progetto serio di automazione. Un ingegnere ha un sistema da governare — un drone da stabilizzare, un braccio robotico da guidare, un datacenter da raffreddare, un agente software da far ragionare — e deve decidere con quale armamentario attaccarlo. Da una parte ha la teoria del controllo, sessant’anni di equazioni, garanzie di stabilità, controllori che si certificano. Dall’altra ha il reinforcement learning, che impara per tentativi e ha vinto a Go e ad Atari. La domanda non è accademica: scegliere lo strumento sbagliato significa buttare mesi, campioni, o garanzie di sicurezza.

Il capitolo su Optimal control: costo, dinamica, vincoli ha già stabilito una cosa importante e la diamo per acquisita: controllo ottimo e reinforcement learning sono, a livello matematico, lo stesso problema.

Minimizzare un costo cumulato lungo una dinamica è identico a massimizzare una ricompensa cumulata: la value function dell’RL è la cost-to-go del controllo, l’equazione di Bellman dell’RL è la versione discreta dell’equazione di Hamilton-Jacobi-Bellman. Quell’identità è argomentata lì, e qui non la ridimostriamo.

Quello che facciamo qui è il passo successivo, e operativo. Se è lo stesso problema, perché esistono due discipline? E soprattutto: dato un problema concreto sul tavolo, quale conviene usare, e perché? Questo capitolo mette controllo e RL fianco a fianco su sei assi di confronto, traccia un albero decisionale pratico, mostra dove i due mondi stanno convergendo nel 2026, e chiude trasponendo la stessa scelta sul design di agenti basati su modelli linguistici: quando un comportamento va controllato con regole e vincoli espliciti, e quando va appreso e ottimizzato dai dati.

La posta in gioco è concreta. Chi confonde i due strumenti tende a uno di due errori speculari: applicare l’RL dove un buon modello esisteva già — e quindi bruciare milioni di campioni per riscoprire faticosamente una soluzione che un’equazione avrebbe dato gratis — oppure ostinarsi col controllo classico dove il modello non c’è e non ci sarà mai, e finire impantanato a modellare ciò che si poteva solo imparare. Saper leggere un problema e dire “questo è terreno da controllo” o “questo è terreno da RL”, e perché, è una competenza ingegneristica che vale tanto quanto conoscere i singoli metodi.

Contesto

Il grafo di questo capitolo ha due vertici e un ponte già costruito tra loro.

Il primo vertice è la teoria del controllo, la disciplina ingegneristica di questa Parte XI: governare un sistema dinamico — il plant, nel suo lessico — agendo su un ingresso, misurando lo stato, correggendo. Strumenti come il PID, la stabilità di Lyapunov, il model predictive control. La sua assunzione di base, quasi sempre tacita: conosco le equazioni del sistema.

Il secondo vertice è il reinforcement learning (RL), il campo che studia come un agente impari a decidere bene interagendo con un ambiente, formalizzato sul Markov Decision Process della Parte VII. La sua assunzione di base, anch’essa quasi tacita: non conosco le equazioni del sistema, le devo scoprire.

Il ponte tra i due è già stato gettato due volte nella wiki, e questo capitolo si appoggia su entrambi senza ripeterli. Da feedback e controllo a MDP, Bellman, RL, nella Parte X, ricostruisce la genealogia storica: come dalla cibernetica e dal controllo ottimo degli anni Cinquanta si arriva all’RL maturato negli anni Ottanta, con la disciplina di marcare ogni legame come filiazione, analogia o equivalenza. Optimal control, in questa stessa Parte, stabilisce l’identità di problema. Qui non rifacciamo né la storia né la dimostrazione: costruiamo sopra di esse il confronto operativo.

Le date che contano per inquadrare la scena. Le due comunità nascono quasi insieme — il controllo ottimo con Richard Bellman e Lev Pontryagin negli anni Cinquanta, l’RL come campo unificato con il Q-learning di Chris Watkins nel 1989 — poi lavorano separate per decenni, una nelle facoltà di ingegneria, l’altra in quelle di informatica, con lessici e riviste diversi.

La riconvergenza è recente. Il manifesto di questo riavvicinamento dal lato del controllo è un articolo del 2018-2019 di Benjamin Recht (ricercatore di ottimizzazione e machine learning a UC Berkeley), A Tour of Reinforcement Learning: The View from Continuous Control (Annual Review of Control, Robotics, and Autonomous Systems, vol. 2, 2019), che guarda l’RL con gli occhi del controllo continuo e ne misura costi e benefici. Ci torneremo, perché il suo argomento centrale — “il ruolo dei modelli e il costo della generalità” — è la spina dorsale del confronto.

L’intuizione

Due angoli prima di entrare negli assi di confronto. Il primo è il più importante e va fissato bene: l’unica differenza che genera tutte le altre. Il secondo è il dizionario che permette di tradurre una frase dall’una all’altra lingua senza perdere nulla.

Primo angolo: la domanda che separa tutto è “conosco il modello?”

Immagina due modi di imparare a parcheggiare un’auto in retromarcia.

Il primo modo: hai studiato la geometria dell’auto. Sai esattamente come gira il volante in rapporto all’angolo delle ruote, quanto è lungo il passo, come la posizione cambia a ogni rotazione. Con queste equazioni in mano, calcoli la traiettoria perfetta prima ancora di toccare il volante, e la esegui.

Hai un modello del sistema, e lo sfrutti per risolvere il problema in anticipo. Questa è, in essenza, la teoria del controllo classica.

Il secondo modo: non sai niente di geometria dell’auto. Provi. Sterzi, vai a sbattere contro il cordolo, riprovi, gradualmente capisci “se sterzo così, finisco là”, e dopo molte prove parcheggi bene.

Non hai mai scritto un’equazione: hai imparato una politica di comportamento dai tentativi. Questo è, in essenza, il reinforcement learning.

Entrambi i guidatori risolvono lo stesso problema — portare l’auto nel posto con il minor numero di manovre goffe — ma partono da informazioni diverse. Il primo conosce la dinamica del sistema; il secondo no, e la compensa con l’esperienza.

Questo è il cardine. Il controllo classico è model-based per costruzione: assume di conoscere la dinamica, che gli arriva dalla fisica (le equazioni del moto, i bilanci di energia) o dall’identificazione di sistema (la procedura con cui si stima il modello da dati input-output, fatta una volta in fase di progetto).

L’RL nasce invece per il caso opposto, quando il modello non è noto o è troppo complesso per scriverlo. E qui l’RL si sdoppia in due strategie, distinzione cruciale che torna in tutto il capitolo:

Model-free: l’agente non costruisce mai un modello esplicito della dinamica. Impara direttamente, dai campioni di esperienza, quale azione conviene in quale stato (o quanto vale uno stato). Q-learning e policy gradient sono di questa famiglia.
Model-based RL: l’agente impara prima un modello approssimato della dinamica dai dati, poi pianifica su quel modello — esattamente come farebbe il controllo, ma su un modello appreso invece che dato. È il ponte naturale tra i due mondi, e lo incontreremo nella sezione sulla convergenza.

In una formula a parole, che riprende la conclusione del ponte della Parte X: RL è il controllo ottimo, meno l’ipotesi di modello noto, più l’approssimazione di funzione. Gli aggettivi adattivo (si adatta a una dinamica che scopre strada facendo) e approssimato (rappresenta la soluzione con una rete invece di calcolarla esatta) non sono ornamenti. Sono il contenuto esatto della differenza.

Secondo angolo: due lessici, gli stessi oggetti

C’è un esperimento mentale che chiarisce quanto le due discipline siano vicine. Prendi un robot che deve stare in equilibrio, e fai descrivere la scena a un ingegnere del controllo e a uno specialista di RL. Le due descrizioni useranno parole completamente diverse per indicare gli stessi oggetti.

Dove l’ingegnere dice plant (il sistema da governare), lo specialista di RL dice environment (l’ambiente). Dove uno dice stato, l’altro dice anche stato — qui le parole coincidono. Dove l’ingegnere dice ingresso o controllo $u$ , l’altro dice azione $a$ .

Dove l’ingegnere parla di una funzione di costo da minimizzare, lo specialista parla di reward da massimizzare — e un reward è semplicemente un costo col segno girato. Dove l’ingegnere dice controllore o legge di controllo, l’altro dice policy $\pi$ . La quantità che il controllo chiama cost-to-go — il costo che ti resta da pagare comportandoti in modo ottimo da qui in avanti — è esattamente ciò che l’RL chiama value function.

Questa tavola di corrispondenze non è un’analogia didattica da maneggiare con cautela: per la maggior parte delle righe è equivalenza di oggetto, lo stesso ente sotto due nomi. È diversa dalla tavola del ponte cibernetica-RL, che mappava cibernetica e RL marcando ogni riga come filiazione o analogia: lì molti legami erano somiglianze storiche o strutturali, qui parliamo di due ingegnerie che descrivono letteralmente lo stesso problema matematico.

Teoria del controllo	Reinforcement Learning	Nota sulla classe del legame
plant / sistema / processo	environment / ambiente	equivalenza di ruolo; in RL spesso black-box
stato $x$	stato $s$	stessa nozione (MDP/POMDP)
ingresso / controllo $u$	azione $a$	equivalenza di ruolo
funzione di costo $J$ (minimizzare)	return / reward (massimizzare)	stesso oggetto, segno opposto
running cost $L$	reward istantaneo $r$	per passo
cost-to-go $V(x)$	value function $V(s)$ , $Q(s,a)$	identità di oggetto (vedi controllo-ottimo)
controllore / legge di controllo	policy $\pi$	equivalenza di ruolo
HJB / equazione di Bellman	equazione di Bellman	stessa equazione
dinamica $\dot x = f(x,u)$ nota	transizione $P(s'\mid s,a)$ ignota	qui le due tradizioni divergono
identificazione di sistema	model learning (model-based RL)	stimare il modello dai dati
orizzonte recedente (MPC)	planning con modello / lookahead	stesso schema operativo

L’ultima riga su cui vale la pena soffermarsi è la terz’ultima, quella in grassetto. Tutte le altre righe sono lo stesso oggetto con due nomi. Quella riga — dinamica nota contro transizione ignota — è l’unica vera frattura, ed è il motivo per cui esistono due discipline invece di una. Tenere a mente che si tratta di due lessici, e non di due fenomeni, è il modo più rapido per non confondersi quando un testo passa dall’uno all’altro.

Terzo angolo: dove va a finire l’incertezza

C’è un terzo modo di guardare la differenza, ed è forse il più utile per chi deve scegliere: chiedersi dove vive l’incertezza nei due approcci, perché in entrambi c’è, ma in posti diversi.

Nel controllo classico l’incertezza vive nel modello. Tu il modello lo hai, ma sai che è approssimato: la massa reale non è esattamente quella nominale, l’attrito cambia con la temperatura, il sensore ha rumore. L’incertezza è la distanza tra il modello che hai scritto e il sistema vero.

Tutta la teoria del controllo robusto esiste per quantificare e domare proprio questa incertezza: progettare un controllore che resti stabile per tutti i modelli plausibili, non solo per quello nominale. L’incertezza è circoscritta, nominata, e c’è una macchina teorica per gestirla.

Nell’RL l’incertezza vive nei dati. Tu il modello non lo hai affatto; ciò che hai sono campioni di esperienza, ed è da quei campioni che devi inferire come comportarti. L’incertezza è quanto i campioni che hai visto rappresentano davvero il mondo: forse hai esplorato poco una regione dello spazio, e lì la tua policy è una scommessa.

È il problema esplorazione contro sfruttamento — provare cose nuove per ridurre l’incertezza, contro sfruttare ciò che già sai funziona — che non esiste nel controllo classico, dove non c’è niente da esplorare perché il modello è già lì. Un controllista non “esplora” il suo plant: lo conosce. Un agente RL deve, e ogni esplorazione costa un campione e rischia un’azione subottima.

Questa lettura spiega perché i due mondi si possono combinare invece di scegliersi a vicenda: l’incertezza sul modello e l’incertezza sui dati non sono nemiche, sono complementari. Il model-based RL, che vedremo, parte proprio da qui — impara un modello dai dati (attaccando l’incertezza sui dati) e poi ci pianifica sopra come farebbe il controllo (sfruttando la struttura), tenendo traccia di quanto si fida del modello appreso. Sapere dove vive l’incertezza di un problema concreto — più nel modello che hai, o più nei dati che ti mancano — è già metà della scelta tra i due approcci.

La meccanica: i sei assi di confronto

Stabilito che il problema è lo stesso e che l’unica frattura di partenza è la conoscenza del modello, vediamo come quella singola differenza si propaga in sei dimensioni concrete. Per ciascun asse: cosa offre il controllo, cosa offre l’RL, e perché.

Asse 1 — Conoscenza del modello

È l’asse-cardine, da cui discendono gli altri cinque.

Il controllo classico richiede un modello noto. Lo ottieni dalla fisica o dall’identificazione di sistema, e una volta che ce l’hai, il problema è risolvibile in anticipo, offline, senza toccare ancora il sistema reale.

L’RL affronta il caso in cui il modello è ignoto. Il model-free lo aggira del tutto, imparando direttamente policy e valori dai campioni. Il model-based RL lo impara, e poi è “controllo su un modello appreso”.

La sfumatura che molti perdono: model-based RL non è l’opposto del controllo, ne è il cugino più stretto — la stessa logica “modella e pianifica”, solo con un modello stimato dai dati invece che derivato dalla fisica.

Conviene rendere concreta la parola “modello”, perché è ambigua. Nel controllo, un modello è un sistema di equazioni che dice come lo stato evolve dato l’ingresso: $\dot x = f(x, u)$ , con $f$ scritta esplicitamente. Per un drone è la dinamica di volo derivata dalle leggi di Newton; per un reattore chimico sono i bilanci di massa ed energia.

Quando la fisica non basta, l’identificazione di sistema riempie i buchi: si stimolano gli ingressi, si registrano le uscite, e si stima la $f$ che meglio le raccorda. È un’operazione fatta una volta, in fase di progetto, dopodiché il modello è in mano.

Nel model-based RL il modello ha la stessa forma — predice il prossimo stato dato lo stato e l’azione — ma viene appreso da una rete neurale durante l’interazione, e continua a migliorare man mano che l’agente raccoglie dati. La differenza tra “identificazione di sistema” e “model learning” è più di grado che di natura: entrambe stimano una dinamica dai dati. La prima lo fa in blocco e in anticipo; la seconda in continuo e online.

Asse 2 — Spazio di stato e azione: continuo contro discreto

Il controllo nasce nel continuo. I suoi oggetti naturali sono posizioni, velocità, tensioni, temperature: numeri reali che evolvono secondo equazioni differenziali. I suoi strumenti — l’LQR, le equazioni di Riccati, i criteri di stabilità — sono fatti su misura per stati e ingressi continui.

L’RL nasce nel discreto: i primi MDP sono tabellari, con un numero finito di stati e azioni, e i primi successi sono giochi (Go, scacchi, Atari) dove le azioni sono mosse contabili.

L’RL moderno gestisce anche il continuo — algoritmi come DDPG o SAC producono azioni reali — ma è un’estensione. Il continuo, per il controllo, è la lingua madre; per l’RL, una seconda lingua imparata bene.

Questa differenza spiega una buona parte della divisione del lavoro nei sistemi reali. Gli strati di controllo a basso livello — un giunto robotico, una superficie aerodinamica — restano spesso nel dominio del controllo continuo classico.

L’RL entra invece dove lo spazio diventa ad alta dimensione o percettivo: decidere a partire da pixel grezzi, da uno stato che è un’immagine o un testo, dove non c’è alcun modello scrivibile e l’unica via è imparare dai dati.

Asse 3 — Garanzie

Qui la differenza è la più netta, ed è il vero vantaggio strutturale del controllo.

Il controllo offre garanzie forti su modelli precisi. La stabilità si dimostra con Lyapunov, l’ottimalità si calcola con Riccati, la robustezza si misura con margini di guadagno e di fase. Sono teoremi: dato il modello, sai con certezza che il sistema in anello chiuso non diverge, e sai entro quali perturbazioni del modello la garanzia regge. Questo è il senso preciso della parola “garanzia” in questa Parte.

L’RL offre poche garanzie. La convergenza degli algoritmi con approssimatori di funzione non lineari (le reti neurali) spesso non è dimostrata; non c’è, per default, alcuna garanzia che la policy appresa mantenga stabile il sistema in anello chiuso. In cambio di questa rinuncia, l’RL ottiene una cosa che il controllo non ha: la capacità di affrontare problemi senza modello, dove il controllo classico semplicemente non avrebbe niente da cui partire.

Vale la pena essere precisi su cosa manca, perché “poche garanzie” non significa “nessun risultato teorico”. L’RL ha teoremi di convergenza solidi nel caso tabellare (stati e azioni finiti, value function rappresentata esattamente in una tabella): lì il Q-learning converge alla policy ottima sotto ipotesi ragionevoli. Quello che salta è il deep RL: appena la value function diventa una rete neurale che approssima, le garanzie di convergenza svaniscono o diventano molto deboli, e si entra in un regime in cui “funziona quasi sempre in pratica” sostituisce “è dimostrato che funziona”. Il controllo, sul suo terreno — sistemi lineari, costi quadratici — non ha questo buco: la garanzia è esatta e vale per costruzione.

Il trade-off, detto secco: il controllo compra garanzie pagando l’ipotesi di conoscere il modello; l’RL si toglie quell’ipotesi rinunciando alle garanzie. È la stessa tensione che attraversa tutta l’ingegneria — più assunzioni fai, più puoi promettere; meno assunzioni fai, più sei generale ma più devi verificare empiricamente.

Asse 4 — Efficienza campionaria

Quanti tentativi servono per arrivare a una buona soluzione? Qui campione significa una interazione con il sistema: un passo di simulazione, o peggio, una manovra reale che consuma tempo e usura l’hardware.

Il controllo è data-efficient se il modello è buono. Risolto il modello, le interazioni col sistema reale necessarie sono zero o pochissime: hai calcolato la soluzione prima, sulla carta.

L’RL, soprattutto model-free, è notoriamente sample-hungry: può richiedere milioni di interazioni per imparare una buona policy. È la ragione per cui l’RL puro su un robot fisico è duro — le interazioni reali costano e rompono le cose — e per cui si addestra in simulazione e poi si trasferisce sul reale (la pratica del sim-to-real).

Il model-based RL recupera molta efficienza: la letteratura riporta che metodi model-based raggiungono le performance dei model-free con un fattore da due a nove volte meno campioni, imparando un modello e pianificandoci sopra invece di provare a tentoni nel mondo.

È la prova che gran parte della fame di campioni dell’RL non è intrinseca al problema, ma è il prezzo di rinunciare al modello: appena un modello rientra in gioco, anche se appreso, il conto dei campioni cala. La sample-efficiency, su questo asse, è quasi una funzione di quanto modello ti porti dietro.

La domanda operativa che questo asse impone è secca: quante interazioni reali ti puoi permettere?

Asse 5 — Gestione dei vincoli

Quasi ogni sistema reale ha vincoli: un attuatore eroga al massimo tot spinta, un giunto non supera un certo angolo, una zona è proibita per sicurezza.

Il controllo gestisce i vincoli in modo forte, e il model predictive control (MPC) è il suo strumento principe per questo: i vincoli su stato e ingresso entrano nativamente nel problema di ottimizzazione che l’MPC risolve a ogni passo, e sono soddisfatti per costruzione. Sono hard constraints: il controllore non li viola, punto.

L’RL standard li gestisce in modo debole. I vincoli si codificano come penalità nel reward (un grosso punteggio negativo se violi il vincolo) — una formulazione soft, che scoraggia ma non impedisce — oppure come Constrained MDP (CMDP), che limita il costo atteso cumulato sotto una soglia.

La letteratura sul safe RL nota apertamente il limite: imporre un vincolo di sicurezza duro, da rispettare a ogni singolo passo, è difficile quando lo strumento che hai è un vincolo sull’aspettativa del costo. Limitare la media delle violazioni non è limitare ogni violazione: una policy può rispettare il vincolo in media e violarlo gravemente in rari casi, esattamente quelli che in sicurezza contano di più. I filtri a vincolo duro che garantiscono zero violazioni esistono, ma tendono a soffocare l’esplorazione di cui l’RL vive.

La conseguenza pratica è importante e va detta senza ambiguità: se hai vincoli di sicurezza non negoziabili — “questa valvola non deve mai superare questa pressione” — il controllo, e l’MPC in particolare, li onora nativamente; l’RL standard no, e trattare un vincolo duro come una penalità nel reward è un errore di design ricorrente e pericoloso.

Asse 6 — Interpretabilità

Il controllo è interpretabile. Una legge come $u = -Kx$ si legge: l’azione è proporzionale allo stato, con questi guadagni. I poli del sistema in anello chiuso si ispezionano, un margine di fase è un numero che puoi mostrare a un revisore. Il comportamento si certifica.

L’RL è in larga parte una scatola nera. Una policy implementata come rete neurale non si legge; il perché di una certa azione è difficile da spiegare; la value function approssimata non si ispeziona con la stessa facilità con cui si guardano i poli di un sistema lineare.

Questo asse pesa molto nei domini regolati o critici, dove un’autorità chiede di dimostrare perché il sistema farà ciò che dice. Un controllore lineare si certifica; una policy neurale si può al più validare empiricamente, ed è una delle ragioni per cui filoni come il neural Lyapunov, che riportano certificati formali dentro il learning, sono così cercati.

Una sola cornice, due culture

I sei assi sopra non sono indipendenti: discendono tutti dall’asse-cardine (modello noto contro ignoto) e da una differenza di cultura tra le due comunità.

Vale la pena nominarla, perché spiega perché un testo di controllo e uno di RL “suonano” così diversi pur parlando dello stesso problema, e perché un ingegnere formato in una delle due tradizioni tende a un riflesso che non sempre è la scelta migliore.

La comunità del controllo è cresciuta in ingegneria, accanto a sistemi fisici reali — aerei, impianti, veicoli — dove un fallimento ha conseguenze materiali. La sua ossessione è la garanzia: prima di mettere un controllore su un aereo, vuoi una dimostrazione che non lo farà precipitare.

Da qui l’enfasi su stabilità, robustezza, margini, e l’abitudine a partire da un modello: senza modello non c’è teorema da dimostrare. Il controllista, davanti a un problema, chiede prima di tutto “qual è il modello?”.

La comunità dell’RL è cresciuta in informatica, accanto a problemi dove il modello o non esiste o è impossibile da scrivere — giochi con spazi astronomici, decisioni a partire da percezione grezza. La sua ossessione è la generalità: un metodo che funzioni senza dover conoscere il dominio, che impari da zero.

Da qui l’accettazione di rinunciare alle garanzie in cambio della capacità di affrontare problemi che il controllo non saprebbe nemmeno impostare. L’RL-ista, davanti a un problema, chiede prima di tutto “come faccio a raccogliere esperienza?”.

Nessuna delle due culture ha ragione in assoluto. Hanno ragione su problemi diversi.

Il controllista che pretende un modello dove non c’è e l’RL-ista che rifiuta un modello dove ce n’è uno ottimo stanno entrambi sbagliando per riflesso culturale, non per analisi del problema. La maturità ingegneristica, su questo bordo, è saper sospendere il proprio riflesso e chiedersi cosa il problema concreto richiede.

Esempi

Esempio numerico: lo stesso LQR, risolto e imparato

Prendiamo il problema più piccolo e meglio studiato, lo stesso che Recht usa come caso di studio nel suo Tour: un regolatore lineare quadratico (LQR) scalare. Lo stato è uno scalare $x$ (lo scostamento di una temperatura dal setpoint, diciamo), la dinamica è $\dot{x} = u$ (l’ingresso cambia direttamente lo stato), il costo è $J = \int_0^\infty (x^2 + r\,u^2)\,dt$ , con $r > 0$ .

L’ingegnere del controllo conosce la dinamica. Risolve l’equazione di Riccati associata e ottiene, in forma chiusa, la legge ottima $u^* = -\frac{1}{\sqrt{r}}\,x$ (la derivazione è in Optimal control). Zero interazioni col sistema reale: la soluzione esiste sulla carta, prima di accendere qualunque cosa.

Se il controllo è economico ( $r$ piccolo) il guadagno è alto e reagisce aggressivo; se è costoso ( $r$ grande) il guadagno è basso e va parsimonioso. Tutto questo lo sa prima di muovere il sistema, perché lo deduce dal modello.

L’agente RL non conosce la dinamica. Non sa che $\dot x = u$ . Deve provare azioni, osservare come lo stato risponde, stimare il valore degli stati, e gradualmente convergere a una legge che — se tutto va bene — approssima la stessa $u^* = -Kx$ che l’ingegnere ha scritto in una riga. Per farlo gli servono molti episodi di interazione.

Il punto pedagogico è esattamente la tesi di Recht: a parità di problema, conoscere il modello è un vantaggio enorme in campioni. L’RL “riscopre” faticosamente, dai dati, una soluzione che la conoscenza del modello consegna gratis.

Recht lo formula così: teoria ed esperimento dimostrano “il ruolo e l’importanza dei modelli, e il costo della generalità” — gli algoritmi RL più generali e agnostici al modello pagano questa generalità in campioni e performance. Che il caso scelto sia l’LQR, il problema più semplice del controllo, rende l’argomento ancora più forte: se l’RL fatica a riscoprire questo, figurarsi i casi difficili. Questo è anche il motivo per cui scegliere RL dove un buon modello esiste è quasi sempre uno spreco.

Esempio in codice: lo stesso loop, due framing

Lo stesso anello di decisione si scrive con il vocabolario del controllo o con quello dell’RL, e il diff tra le due versioni mostra esattamente dove le strade si separano.

# Framing controllo: il modello e la legge sono NOTI a chi progetta.
def loop_controllo(plant, riferimento, controllore):
    while plant.attivo():
        x = plant.misura_stato()
        # il controllore è una legge fissa, derivata dal modello noto
        u = controllore.legge(x, riferimento)   # es. u = -K x
        plant.applica(u)

# Framing RL: il modello è IGNOTO, la policy si impara.
def loop_rl(ambiente, policy):
    s = ambiente.stato_iniziale()
    while not ambiente.terminato():
        a = policy.scegli(s)               # policy, non legge fissa
        s_succ, reward = ambiente.passo(a) # la dinamica è una scatola
        policy.aggiorna(s, a, reward, s_succ)  # impara dall'esperienza
        s = s_succ

Le due funzioni hanno la stessa forma — leggi, decidi, agisci, ripeti — e tre differenze visibili nel codice dicono dove finisce l’identità e comincia la scelta operativa.

Primo: controllore.legge è una funzione fissa, calcolata dal modello prima di partire; policy viene modificata da policy.aggiorna a ogni passo. Secondo: nel framing di controllo il comportamento di plant è noto a chi ha progettato il controllore; in RL ambiente.passo è una scatola di cui non si conosce la dinamica.

Terzo, e conseguente dai primi due: il loop di controllo non ha bisogno di imparare, esegue; il loop RL spende ogni passo anche per imparare. È in quel policy.aggiorna che vivono i milioni di campioni dell’asse 4, ed è la sua assenza, nel loop di controllo, a rendere quest’ultimo data-efficient quando il modello è buono.

Esempio scenario reale: il robot che cammina

Un robot bipede deve imparare a camminare su terreni vari. La dinamica del contatto piede-suolo è un incubo da modellare: discontinua (il piede tocca o non tocca), dipendente da attriti e irregolarità che cambiano a ogni passo. Scrivere un modello fisico accurato è impraticabile.

Qui l’RL — tipicamente model-based RL addestrato in simulazione — impara una policy di locomozione che nessuna equazione chiusa saprebbe esprimere bene. Ma la policy RL, da sola, non offre garanzie: potrebbe comandare ai motori una coppia che danneggia i giunti.

La soluzione reale stratifica i due mondi. Sotto, uno strato di controllo a basso livello — spesso un MPC — riceve i comandi dell’RL e li esegue rispettando i vincoli fisici sui giunti come hard constraints: per quanto strana sia l’azione che l’RL chiede, lo strato di controllo garantisce che non si rompa l’hardware.

Sopra, l’RL fornisce l’intelligenza adattiva che il controllo da solo non avrebbe. Né l’uno né l’altro basterebbe: la locomozione moderna è controllo e RL, ciascuno dove è forte. È l’incarnazione fisica della stessa stratificazione che ritroveremo, trasposta, negli agenti software.

Esempio applicativo: il pendolo inverso, banco di prova condiviso

Un esempio che entrambe le comunità rivendicano è il pendolo inverso — un’asta incernierata su un carrello, da tenere dritta muovendo il carrello. È istruttivo proprio perché è uno dei pochi problemi che si affrontano in modo idiomatico sia col controllo sia con l’RL, e mette in scena la differenza in modo pulito.

L’ingegnere del controllo scrive le equazioni del moto del pendolo (sono note: è meccanica classica), le linearizza attorno alla posizione verticale, applica un LQR e ottiene un controllore $u = -Kx$ che stabilizza l’asta. Funziona al primo tentativo nell’intorno della verticale, con una garanzia di stabilità locale dimostrabile.

Il limite si vede subito: lontano dalla verticale la linearizzazione perde validità, e per il problema dello swing-up — partire con l’asta penzoloni e farla salire — l’LQR locale non basta, perché la dinamica in quella regione è troppo non lineare.

Lo specialista di RL non scrive equazioni. Lascia che l’agente provi, cada, riprovi, e dopo molti episodi impara una policy che fa sia lo swing-up sia il bilanciamento, gestendo l’intera regione non lineare che l’LQR locale non copriva. Paga questa generalità in campioni — molti episodi di tentativi — e in assenza di garanzie formali.

Lo stesso problema, due soluzioni che si rompono in punti diversi: il controllo è preciso e garantito ma locale, l’RL è globale ma costoso e non certificato. La sintesi pratica, di nuovo, esiste ed è ibrida: usare l’RL per lo swing-up nella regione non lineare e passare all’LQR per il bilanciamento fine vicino alla verticale.

Esempio decisionale: l’albero applicato a un datacenter

Devi gestire il raffreddamento di un datacenter: regolare le ventole e il condizionamento per tenere i server in temperatura spendendo meno energia possibile, senza mai superare soglie critiche.

Far girare l’albero decisionale (sotto) su questo caso. Hai un modello termico affidabile dell’edificio? Spesso sì, la termodinamica è nota e identificabile. Ci sono vincoli di sicurezza duri? Sì, le soglie di temperatura critiche non vanno mai superate. La risposta che l’albero produce è MPC: modello noto più vincoli duri è esattamente il suo terreno.

Se invece il modello termico fosse troppo complesso — un edificio dalla geometria irregolare, carichi termici imprevedibili — e avessi un simulatore fedele su cui spendere milioni di episodi, l’albero spingerebbe verso un approccio RL, e in pratica, oggi, verso un model-based RL che impari il modello termico dai dati e ci pianifichi sopra.

Studi comparativi su sistemi di climatizzazione confermano lo schema: il model-based batte il model-free su efficienza campionaria e affidabilità, proprio perché sfrutta la struttura del problema invece di ignorarla. È il datacenter a dettare la scelta, non la moda del metodo.

Applicazioni pratiche

Quando scegliere cosa: l’albero decisionale

La domanda “controllo o RL?” si risponde in pratica con poche domande in cascata.

Hai un modello affidabile della dinamica (dalla fisica o identificabile dai dati)? Se sì, il controllo è la scelta di default — vai avanti per affinarla. Se no, o se il modello è troppo complesso, ti orienti verso l’RL (model-free) oppure verso l’imparare un modello (model-based RL).
Lo spazio è continuo, a bassa-media dimensione, con dinamica regolare? Se sì e hai il modello, LQR o MPC ti danno una soluzione pulita e con garanzie. Se lo spazio è ad alta dimensione, percettivo (pixel), o la dinamica è fortemente non lineare, l’RL con approssimatori di funzione scala meglio.
Ti servono garanzie di stabilità o sicurezza certificabili? Se hai vincoli duri non negoziabili, il controllo li offre — MPC per i vincoli, Lyapunov per la stabilità — e l’RL standard no. Se basta “funziona bene in media”, l’RL è accettabile.
Quante interazioni col sistema reale ti puoi permettere? Se poche e costose (un robot fisico, un impianto critico), evita il model-free puro sul sistema reale: usa il controllo, o il model-based RL, o addestra in simulazione e trasferisci. Se le interazioni sono tante ed economiche (un simulatore perfetto, un gioco), il model-free va bene.
Hai bisogno di interpretabilità o di poter certificare il comportamento a un auditor? Se sì, il controllo. Se no, l’RL apre più opzioni.

La regola sintetica che riassume l’albero: più sai del sistema e più le garanzie contano, più la scelta pende verso il controllo; meno sai e più lo spazio è complesso o percettivo, più pende verso l’RL. E la risposta reale, nei sistemi seri, è spesso nel mezzo — model-based RL, oppure RL e MPC stratificati.

Le aree di convergenza moderna

Il bordo tra controllo e RL non è un muro: è una transizione, ed è oggi una delle zone di ricerca più attive. Sei filoni, dal più consolidato al più recente.

Il model-based RL (MBRL) impara un modello della dinamica dai dati e poi ci pianifica sopra. PETS (Chua et al., NeurIPS 2018) usa un ensemble probabilistico di modelli appresi — più reti che predicono la dinamica, la cui disuguaglianza misura quanto fidarsi — e ci fa girare sopra un MPC con cross-entropy method.

È letteralmente “fare controllo su un modello appreso”, e recupera gran parte della sample-efficiency del controllo mantenendo l’agnosticismo dell’RL. È il filone che più direttamente colma la frattura dell’asse 1.

L’integrazione diretta RL + MPC combina i due come strati: un MPC a basso livello esegue e filtra le azioni di un RL ad alto livello (action shielding), oppure l’RL fornisce il costo terminale di un MPC a orizzonte corto.

Zanon e Gros (2019) propongono un safe RL che usa un robust MPC come struttura della policy, ereditandone le garanzie di sicurezza. TD-MPC combina value learning model-free e planning model-based via MPC, battendo i model-free puri su compiti di controllo. È la riga “modello noto vs ignoto” della tavola di corrispondenza che si scioglie: l’RL fornisce ciò che non si sa modellare, l’MPC mette le garanzie su ciò che si sa.

Il differentiable control rende differenziabile l’oggetto stesso del controllo. Amos et al., Differentiable MPC for End-to-end Planning and Control (NeurIPS 2018), trasformano l’MPC in un layer su cui si può fare backpropagation, così che diventi una classe di policy addestrabile end-to-end. Fonde il vantaggio model-free (apprendimento end-to-end) con quello model-based (struttura e vincoli espliciti dentro la policy).

Il learning to control con certificati di stabilità impara contemporaneamente un controllore a rete neurale e una funzione di Lyapunov che ne certifica la stabilità, recuperando dentro un setup learning-based le garanzie che erano il punto forte del controllo. Lavori come Neural Lyapunov MPC e Neural Lyapunov Differentiable Predictive Control vanno in questa direzione.

L’RL per il tuning di controllori non sostituisce il controllore: ne ottimizza gli iperparametri. Auto-tuning dei guadagni di un PID, scelta delle matrici $Q$ ed $R$ di un LQR, calibrazione dei pesi di un MPC. Il controllore resta interpretabile e con garanzie; l’RL fa solo la calibrazione, là dove sintonizzare a mano sarebbe lungo.

La control-theoretic analysis dell’RL, infine, gira la prospettiva: usa gli strumenti del controllo per analizzare l’RL. Certificare che una policy appresa non destabilizzi il sistema, studiarne convergenza e robustezza. Un esempio recente impara funzioni di Lyapunov generalizzate aumentando la value function dell’RL con un residuo a rete neurale, per ottenere certificati di stabilità di policy apprese.

Tutti e sei i filoni dicono la stessa cosa da angoli diversi: la separazione storica tra le due comunità si sta ricucendo, e i sistemi seri attingono a entrambe.

La direzione comune è leggibile. Il controllo cede all’RL la capacità di lavorare senza modello e su spazi complessi; l’RL prende in prestito dal controllo la struttura, i vincoli duri e i certificati di stabilità. Il punto di arrivo non è “uno vince sull’altro”, ma metodi ibridi che, problema per problema, mettono il modello dove c’è e l’apprendimento dove serve. Per chi progetta oggi, saper riconoscere quale parte di un problema è “da controllo” e quale “da RL” vale più che essere fedele a una delle due scuole.

Il bridge agentico: comportamento controllato contro comportamento appreso

Per chi progetta agenti basati su modelli linguistici, la stessa dicotomia “modello noto più garanzie” contro “appreso più flessibile” si ripresenta come una scelta di design sul comportamento dell’agente.

Vale la pena svolgerla, perché è il punto più vicino al lavoro quotidiano di chi usa questa wiki, ed è il motivo per cui un capitolo di teoria del controllo trova posto in una wiki sull’AI.

C’è un approccio control-like: il comportamento dell’agente va controllato con guardrail, macchine a stati, vincoli espliciti, validatori, allowlist. Specifichi a mano cosa l’agente può e non può fare. È il corrispettivo del controllo classico: noto il “modello” del comportamento desiderato, lo imponi con vincoli duri verificabili a runtime.

È forte su garanzie e interpretabilità — puoi dimostrare che certe azioni non avverranno mai — ma debole se il dominio è troppo vario per essere coperto da regole scritte a mano, esattamente come il controllo classico è forte sui sistemi modellabili e debole su quelli che non sai scrivere. La letteratura recente lo esplora: AGENT-C, per esempio, introduce un linguaggio dedicato per esprimere proprietà temporali sull’ordinamento delle azioni di un agente e usa un SMT solver (un risolutore che verifica meccanicamente se una formula logica è soddisfacibile) per garantire a runtime che l’agente non le violi.

E c’è un approccio RL-like: il comportamento va appreso e ottimizzato dai dati. RLHF (Reinforcement Learning from Human Feedback, la tecnica con cui si allinea un modello linguistico modellandone il comportamento durante il training) e l’ottimizzazione della policy plasmano il comportamento di base.

È flessibile, copre casi non anticipati, ma è statico — fissato al momento del training, non consapevole delle policy specifiche della tua applicazione — e poco interpretabile. È il corrispettivo dell’RL classico: cattura ciò che non sapresti scrivere a mano, al prezzo di garanzie e leggibilità.

Il framing pratico, sostenuto tra l’altro da un lavoro del 2025, From Refusal to Recovery: A Control-Theoretic Approach to Generative AI Guardrails (arXiv:2510.13727), è che i due approcci non competono: si stratificano, esattamente come MPC e RL nel robot che cammina.

RLHF (RL-like) dà il comportamento di base accettabile; i guardrail e le macchine a stati (control-like) impongono i limiti duri e verificabili che il deployment specifico richiede. Quel lavoro propone guardrail control-theoretic dinamici — che ragionano sulle conseguenze e sterzano l’agente lontano da esiti catastrofici preservando la performance — come alternativa principled sia ai guardrail statici “segnala-e-blocca” sia all’RLHF da solo.

La classe di questa affermazione va marcata con cura, perché è esattamente il tipo di legame che scivola. Tra controllo e RL c’è identità di problema, documentata e argomentata in Optimal control.

Tra “regole esplicite uguale control-like, RLHF uguale RL-like” applicato agli agenti c’è invece analogia metodologica: lo schema decisionale — sapere e vincolare contro imparare e ottimizzare — è lo stesso, ma un guardrail su un agente non è un controllore con un’equazione di Riccati, e RLHF non è un Q-learning su un MDP fisico. Lo schema è identico; gli oggetti su cui gira no. Riconoscere lo schema aiuta a progettare; confonderlo con un’identità porta a cercare equazioni di controllo dove non ce ne sono.

Per chi progetta, la lezione operativa è la stessa che guida la scelta tra controllo e RL sui sistemi fisici, trasposta.

Dove il comportamento desiderato è specificabile a mano ed è critico che certe cose non avvengano mai — non cancellare file fuori dalla working directory, non eseguire comandi distruttivi senza conferma, non chiamare due strumenti in un ordine vietato — conviene l’approccio control-like: lo specifichi e lo imponi a runtime, con la stessa logica con cui un MPC impone un vincolo duro.

Dove il comportamento è troppo sfumato e vario per essere scritto in regole — produrre risposte utili, di buon tono, ben argomentate — conviene l’approccio RL-like: lo modelli dai dati con RLHF, accettando che sia statico e poco interpretabile.

I due si stratificano, e capire quale strato fa cosa è esattamente il tipo di chiarezza progettuale che il confronto controllo/RL allena. La domanda “questo va vincolato o appreso?” sull’agente è la trasposizione diretta di “questo va modellato o imparato?” sul sistema fisico.

Dove si rompe

Il confronto controllo/RL è utile esattamente nella misura in cui non lo si trasforma in slogan. Ecco i modi in cui si rompe, dal più insidioso al più tecnico.

“RL è meglio perché è moderno e usa il deep learning.” È il fraintendimento più comune e il più dannoso. RL e controllo non sono in classifica: sono strumenti per regimi diversi. Con un buon modello, il controllo è più efficiente in campioni, più garantito, più interpretabile. L’RL vince quando il modello manca o lo spazio è troppo complesso. Scegliere RL dove un modello affidabile esiste significa, di solito, buttare via campioni e garanzie per inseguire una moda. La domanda giusta non è “quale è più avanzato”, ma “quale si adatta a questo problema”.

Credere che model-free sia l’unico RL. Tutta una metà del campo — il model-based RL — impara un modello e ci pianifica sopra, ed è il ponte verso il controllo, non il suo opposto. Chi ragiona come se RL significasse solo “policy gradient agnostico al modello” si preclude proprio la famiglia di metodi che spesso è la risposta giusta nei sistemi con interazioni costose.

Confondere “ottimo rispetto al modello” con “robusto e sicuro”. Vale in entrambi i mondi, ed è una trappola simmetrica. Un controllore LQR è ottimo sul modello ma può non avere margini di robustezza, come mostrò il controesempio di Doyle del 1978 sull’LQG (lo riprende Robustezza a rumore, incertezza e disturbi).

Allo stesso modo, una policy RL ottima in simulazione può fallire sul sistema reale per il sim-to-real gap. Ottimalità e robustezza sono garanzie diverse: la prima, comprata senza la seconda, è una promessa solo sulla carta. Che il modello sia dato (controllo) o appreso/simulato (RL) non cambia la sostanza: ottimo su un modello non significa buono sul mondo.

Trattare i vincoli allo stesso modo nei due mondi. L’MPC onora hard constraints nativamente; l’RL li gestisce come penalità nel reward o come limiti sull’aspettativa (CMDP), che sono soft. Trasporre un vincolo di sicurezza duro — “mai superare questa pressione” — in una penalità nel reward è un errore ricorrente: produce violazioni rare ma potenzialmente catastrofiche, perché una penalità scoraggia ma non impedisce, e un ottimizzatore abbastanza furbo può decidere che vale la pena pagarla. È una variante del reward hacking che la Parte XVI (in preparazione) tratta a fondo.

Pensare che le due comunità siano alternative esclusive o nemiche. Erano separate per ragioni storiche — lessici e dipartimenti diversi — ma oggi convergono visibilmente: Recht dal lato del controllo, Bertsekas che unifica le due discipline in un libro solo, il differentiable MPC che le fonde in un layer.

Trattarle come campi rivali fa perdere proprio gli strumenti ibridi (MBRL, RL+MPC, neural Lyapunov) che nei sistemi seri sono la risposta reale. La domanda matura non è “controllo o RL”, ma “quale parte del problema affido a quale”.

Gonfiare l’analogia agentica in identità. Dire “i guardrail sono il controllore e RLHF è l’RL dell’agente” è un’analogia metodologica utile, non un’identità. Un agente basato su un modello linguistico non ha una dinamica $f$ in forma chiusa, non risolve un’equazione di Riccati, non calcola una value function esatta sul suo “stato” (che è una finestra di contesto di decine di migliaia di token). Lo schema decisionale è lo stesso; gli oggetti matematici no. Chi confonde i due livelli finisce per cercare poli e margini di fase dentro un prompt.

Dimenticare che la parte difficile, in entrambi, è scegliere l’obiettivo. Si discute di metodi — LQR contro Q-learning, MPC contro policy gradient — come se il nodo fosse lì. Ma sia il controllo sia l’RL ottimizzano ciò che gli dici, non ciò che intendi.

Un costo mal scritto produce un controllore perfettamente ottimo del problema sbagliato; un reward mal scritto produce una policy perfettamente ottima del problema sbagliato. La scelta della funzione di costo o di reward è la decisione più importante e la più sottovalutata, e in questo i due mondi sono identici.

È la stessa lezione della legge di Goodhart e del reward hacking: ottimizzare alla lettera un obiettivo impreciso dà l’imprecisione eseguita alla perfezione. Cambiare strumento non salva da un obiettivo sbagliato.

Trascurare il problema dell’osservazione. Sia il controllo sia l’RL, nella forma base, assumono di osservare lo stato. Quasi mai è vero: si misura una proiezione rumorosa e parziale. Il controllo ha una risposta matura — lo stimatore di stato, il filtro di Kalman — che ricostruisce lo stato dalle misure e lo passa al controllore. L’RL chiama lo stesso problema POMDP (Partially Observable MDP) e lo affronta con memoria o stati ricorrenti. È un asse su cui i due mondi non divergono ma convergono: entrambi devono stimare ciò che non vedono prima di poter decidere bene, e ignorarlo porta a controllori e policy che agiscono su uno stato che non è quello vero.

Collegamenti

Optimal control: costo, dinamica, vincoli — il prerequisito diretto: stabilisce l’identità di problema tra controllo ottimo e RL (value function uguale cost-to-go, Bellman uguale HJB discreta), che qui diamo per acquisita e da cui partiamo per il confronto operativo.
Da feedback e controllo a MDP, Bellman, RL — la genealogia storica e la tavola di corrispondenze cibernetica-RL con le classi di legame; complemento storico di questo capitolo, che invece guarda al presente.
Controllare un sistema: plant, controller, sensore, attuatore — il vocabolario di base (plant, controllore, stato, ingresso) su cui poggia la tavola di corrispondenza controllo-RL.
Receding horizon: planning, vincoli e ri-ottimizzazione — l’arma del controllo per i vincoli duri e il planning; centrale per l’asse “gestione dei vincoli” e per la convergenza RL+MPC.
Stimare stato nascosto con modello e misure rumorose — la stima dello stato; rilevante perché sia controllo sia RL assumono di osservare lo stato, o di doverlo stimare quando l’osservazione è parziale (POMDP).
Robustezza a rumore, incertezza e disturbi — ottimalità non è robustezza; il parallelo diretto tra il controesempio di Doyle e il sim-to-real gap dell’RL.
Markov Decision Process: il framework formale del decidere nel tempo — la formalizzazione del problema dal lato RL, l’altra metà della tavola di corrispondenza.
Q-learning e DQN e Policy gradient e REINFORCE — i metodi model-free di cui qui si discute il rapporto con il controllo e la fame di campioni.
ponte-control-agenti (in preparazione) — l’agent loop letto come problema di controllo parziale; il seguito naturale del bridge agentico di questo capitolo.

Per andare oltre

B. Recht, A Tour of Reinforcement Learning: The View from Continuous Control (Annual Review of Control, Robotics, and Autonomous Systems, vol. 2, pp. 253-279, 2019; preprint arXiv:1806.09460). Il manifesto del confronto dal lato del controllo: usa l’LQR con dinamica ignota come caso di studio per mostrare il ruolo dei modelli e il costo della generalità. La fonte primaria di questo capitolo.
D. P. Bertsekas, Reinforcement Learning and Optimal Control (Athena Scientific, 2019). Tratta le due discipline come una sola; il riferimento per capire perché RL e controllo ottimo sono la stessa materia sotto lessici diversi.
B. Amos, I. Jimenez, J. Sacks, B. Boots, J. Z. Kolter, Differentiable MPC for End-to-end Planning and Control (NeurIPS 2018). Fonda l’MPC come classe di policy differenziabile: il punto di fusione tra model-based e model-free.
M. Zanon, S. Gros, Safe Reinforcement Learning Using Robust MPC (2019, arXiv:1906.04005). RL che eredita le garanzie di sicurezza usando un robust MPC come struttura della policy; un esempio concreto di convergenza RL+MPC.
R. S. Sutton, A. G. Barto, Reinforcement Learning: An Introduction (2a ed., MIT Press, 2018). Il riferimento canonico dell’RL, con il capitolo sul legame tra programmazione dinamica e controllo ottimo.