Optimal control: costo, dinamica, vincoli

Portare un sistema all’obiettivo non basta: quasi sempre ci sono infiniti modi di farlo, e differiscono per quanto costano. Il controllo ottimo trasforma “fai funzionare il sistema” in “fai funzionare il sistema al minor costo possibile”, e da quel cambio di domanda nascono il principio di Pontryagin, l’equazione di Bellman e il legame profondo con il reinforcement learning.

Perché questo capitolo

Nel 1956, a Mosca, un matematico cieco dall’età di quattordici anni e i suoi studenti risolvono un problema che la fisica e l’ingegneria si trascinavano da secoli sotto altre forme: dato un razzo con una quantità finita di carburante, qual è il profilo di spinta che ne massimizza la velocità finale? Non un profilo che funziona — di quelli ce ne sono infiniti — ma quello migliore. La risposta, il principio del massimo di Pontryagin, è uno dei due pilastri di questo capitolo.

I quattro capitoli precedenti di questa Parte rispondono tutti alla stessa domanda di fondo: come porto il sistema dove voglio e ce lo tengo?

Il PID lo fa per tentativi tarati. Il progetto via Lyapunov lo fa con una garanzia formale di stabilità. Il controllo robusto lo fa tollerando l’incertezza del modello. Tutti e tre risolvono un problema di fattibilità: esiste un ingresso che fa il lavoro, eccolo.

Il controllo ottimo cambia la domanda. Non chiede più solo “un ingresso che funziona”, ma “il migliore ingresso che funziona”, dove “migliore” è definito da un criterio quantitativo che scegli tu: minima energia spesa, minimo tempo, minimo errore quadratico accumulato, minima usura degli attuatori, o una loro combinazione pesata. Il salto è da “soddisfare un vincolo” a “minimizzare un costo soggetto a quel vincolo”.

Conta perché in quasi ogni sistema reale i modi di raggiungere l’obiettivo sono tanti e differiscono enormemente nel prezzo. Un razzo arriva in orbita con mille profili di spinta diversi: uno solo consuma il minimo carburante. Un braccio robotico raggiunge il punto di presa lungo mille traiettorie: una sola minimizza lo strappo meccanico. Un datacenter soddisfa la domanda con mille schedule di accensione: uno solo minimizza la bolletta.

Quando le risorse contano — carburante, tempo, energia, denaro, token — il controllo ottimo è il quadro che trasforma “fai funzionare” in “fai funzionare al minor costo”. Ed è anche, come vedremo, lo stesso problema che il reinforcement learning risolve quando non conosci in anticipo le regole del sistema: per questo un capitolo di teoria del controllo si trova in una wiki sull’AI, e per questo lo trattiamo con cura sulla differenza fra ciò che è davvero lo stesso problema e ciò che gli somiglia soltanto.

Contesto

Questo capitolo siede al centro di tre fili della wiki che qui si annodano.

Il primo è la Parte XI stessa. Presuppone il vocabolario di Controllare un sistema: plant, controller, sensore, attuatore: il plant è il sistema da controllare, il controllore decide l’ingresso, lo stato è la lista di numeri che riassume la condizione del sistema istante per istante.

Il controllo robusto, appena prima, ha già introdotto un personaggio che ricomparirà: l’LQG (Linear Quadratic Gaussian), il regolatore ottimo per sistemi lineari con rumore gaussiano, di cui qui costruiamo la metà “controllo” (l’LQR).

Il secondo filo è la radice matematica. Il controllo ottimo discende dal calcolo delle variazioni, la branca dell’analisi che ottimizza non numeri ma funzioni intere (Parte VI, Ottimizzare funzioni di funzioni).

Il suo problema-antenato è la brachistocrona, posta da Johann Bernoulli (matematico svizzero, 1667-1748) nel 1696: fra tutte le curve che collegano due punti a quote diverse, quale fa scendere una pallina nel minor tempo? La risposta non è la retta (è un arco di cicloide). Da lì, attraverso Leonhard Euler e Joseph-Louis Lagrange nel Settecento, si arriva all’apparato analitico che Pontryagin generalizzerà ai problemi con vincoli sul controllo.

Il terzo filo è il legame con il decision making sequenziale: la programmazione dinamica di Richard Bellman (Parte VIII, DP con esempi classici) e l’equazione di Bellman del reinforcement learning (Parte VII, Bellman e programmazione dinamica).

Questo non è un collegamento decorativo. Come argomenteremo nella sezione dedicata, RL e controllo ottimo sono in larga parte lo stesso problema visto da due comunità diverse, e l’equazione di Bellman è letteralmente il punto in cui le due tradizioni si toccano. Marcare con esattezza la classe di questo legame — fin dove è identità e dove invece è solo somiglianza — è uno degli scopi del capitolo.

Le date che contano. Il calcolo delle variazioni è settecentesco. La svolta moderna è anni ‘50: Richard Bellman (matematico statunitense, 1920-1984) sviluppa la programmazione dinamica e pubblica Dynamic Programming (Princeton University Press, 1957). Quasi in parallelo, Lev Pontryagin (matematico sovietico, 1908-1988) e i suoi studenti formulano il principio del massimo nel 1956, raccolto poi nel libro The Mathematical Theory of Optimal Processes (1962). Nel 1960 Rudolf Kalman (ingegnere e matematico statunitense di origine ungherese, 1930-2016) pubblica i risultati che fondano il regolatore lineare quadratico, il caso speciale risolvibile in forma chiusa. Tre punti di partenza diversi per la stessa disciplina, nati quasi nello stesso decennio ai due lati della cortina di ferro.

Vale la pena notare che questa nascita parallela non fu un caso. Gli anni ‘50 sono il decennio della corsa missilistica e spaziale: i problemi che premevano — guidare un razzo, intercettare un bersaglio, spendere il minimo carburante — erano esattamente problemi di controllo ottimo, e venivano attaccati simultaneamente a Mosca e negli Stati Uniti.

Pontryagin, che fino agli anni ‘50 aveva lavorato in topologia pura, si volse al controllo proprio sotto la spinta di questioni applicate poste da ingegneri. Bellman, dall’altra parte, lavorava alla RAND Corporation, un centro di ricerca statunitense legato a questioni strategiche e militari.

Che due tradizioni così diverse — una più analitica e variazionale (Pontryagin), una più ricorsiva e computazionale (Bellman) — arrivassero quasi insieme allo stesso territorio, partendo da problemi pratici condivisi, è il motivo per cui oggi abbiamo due vie alla stessa soluzione invece di una. La loro equivalenza profonda — il fatto che la costate di Pontryagin sia il gradiente della value function di Bellman — fu chiarita solo dopo, a riconciliare due scoperte indipendenti.

L’intuizione

Tre angoli prima di qualunque formula. Il primo è strutturale: cos’è davvero un problema di controllo ottimo e perché ha due grandi vie di soluzione. Il secondo è il ponte verso il resto della wiki: perché un agente che massimizza una ricompensa sta, formalmente, risolvendo un problema di controllo ottimo. Il terzo è economico, e illumina l’oggetto più misterioso del capitolo — le variabili aggiunte di Pontryagin — leggendole come prezzi.

Primo angolo: il sentiero più economico, non il primo che funziona

Immagina di dover attraversare una valle da un punto A a un punto B. La cibernetica e il PID ti danno un sentiero che arriva a B: misurano quanto sei lontano e correggono finché ci arrivi.

Il controllo ottimo ti chiede qualcosa di diverso. Tra tutti i sentieri che arrivano a B, alcuni sono ripidi e ti sfiniscono, altri sono lunghi e lenti, altri attraversano fango che ti rallenta. Vuoi quello che minimizza una spesa totale — fatica più tempo, diciamo — accumulata lungo l’intero percorso. Non un sentiero che arriva: il sentiero più economico tra quelli che arrivano.

Tre cose definiscono il problema, e conviene tenerle separate perché il controllo ottimo le tratta in modo diverso.

La prima è la dinamica come vincolo. Non puoi teletrasportarti: a ogni passo, la tua posizione successiva dipende da dove sei e dal passo che fai, secondo regole fisse (la pendenza, il terreno). In simboli, lo stato evolve secondo una legge nota: in tempo continuo $\dot{x} = f(x, u)$ , in tempo discreto $x_{k+1} = f(x_k, u_k)$ . Qui $x$ è lo stato (dove sei), $u$ è il controllo (il passo che scegli). Questa non è una preferenza: è un vincolo duro. Ogni traiettoria che proponi deve rispettare la fisica del sistema.

La seconda è il costo da minimizzare. È un numero che valuta un intero sentiero, non un singolo istante. La forma tipica somma due pezzi: un costo terminale $\phi(x(T))$ , che misura quanto sei lontano dall’obiettivo alla fine, e un costo di percorso, accumulato istante per istante lungo la strada. In simboli:

$J = \phi(x(T)) + \int_0^T L(x, u, t)\,dt$

In parole povere, questo dice che il costo totale $J$ di una traiettoria è quanto sei messo male al traguardo, più la somma di tutto ciò che spendi lungo il cammino.

Il termine $L$ sotto integrale è il costo di percorso (anche detto running cost o Lagrangiano): a ogni istante ti dice quanto stai spendendo adesso, in funzione di dove sei ( $x$ ) e di cosa stai facendo ( $u$ ). Se $L = u^2$ stai pagando lo sforzo di controllo; se $L = x^2$ stai pagando l’errore rispetto allo zero; di solito è una combinazione dei due, e la scelta dei pesi relativi è la prima decisione di progetto.

La parola funzionale merita una sosta, perché è la radice di tutto. $J$ non è una funzione ordinaria che prende un numero e restituisce un numero. Prende in input una funzione intera — l’intera traiettoria del controllo $u(t)$ dal tempo zero al tempo $T$ — e restituisce un numero. È un numero che giudica una funzione.

Minimizzare un funzionale è il problema del calcolo delle variazioni, ed è ciò che rende il controllo ottimo diverso da una banale minimizzazione: non cerchi il punto più basso di una curva, cerchi la forma di curva migliore in uno spazio di infinite curve. È un salto di difficoltà, ed è il motivo per cui la soluzione richiede strumenti dedicati invece della sola derivata posta a zero.

La terza è l’insieme dei vincoli su stato e controllo. Il passo che puoi fare ha un limite (un motore eroga al massimo tot spinta: $|u| \le u_{max}$ ); certe zone sono proibite (un robot non attraversa un muro: $x$ resta in una regione ammissibile).

Questi vincoli sono cruciali: sono esattamente ciò che rende insufficiente il calcolo delle variazioni classico e necessario il principio di Pontryagin. Quando l’ottimo sbatte contro un vincolo — il motore va a tutta manetta, non a una manetta intermedia — la condizione “la derivata si annulla all’ottimo” salta, perché l’ottimo è sul bordo, non in un punto interno. Lo vedremo concretamente nell’esempio dell’atterraggio a minimo carburante.

A questo si aggiunge una scelta di cornice: l’orizzonte. Finito, se $T$ è dato (“atterra entro dieci minuti”); infinito, se il compito non ha scadenza (“tieni la temperatura al setpoint per sempre”). L’orizzonte infinito richiede di solito uno sconto sul futuro o un costo medio, per non sommare infiniti contributi, e tende a produrre leggi di controllo stazionarie: la stessa regola applicata a ogni istante.

Secondo angolo: un agente è un risolutore di controllo ottimo

Cambiamo dominio e teniamo la struttura. Un agente — un sistema che osserva, decide, agisce, riosserva — sta facendo esattamente la stessa cosa del controllore, con nomi diversi. Vale la pena svolgere la corrispondenza termine per termine, perché è precisa.

Lo stato $x$ è il contesto in cui l’agente opera: il contenuto del suo context window, lo stato del filesystem, l’output dei tool fin qui. Il controllo $u$ è l’azione che sceglie a ogni passo: quale tool chiamare, cosa scrivere.

La dinamica $f$ è come il mondo reagisce all’azione: esegui un comando, il filesystem cambia; mandi una query, arriva una risposta. La policy dell’agente — la regola che mappa stato in azione — è la sua legge di controllo.

E il costo? Un agente che porta a termine un task spende risorse: token, tempo, chiamate ad API, rischio. Un agente ben progettato non vuole solo completare il task: vuole completarlo bene spendendo poco.

Questa è precisamente la tensione di un costo $J$ con due pezzi: il costo terminale (quanto bene è fatto il task alla fine) e il costo di percorso (quante risorse hai bruciato lungo la strada). Il reinforcement learning di solito gira il segno e parla di ricompensa da massimizzare invece che di costo da minimizzare, ma è la stessa cosa: ricompensa $=$ costo cambiato di segno.

Va detta con precisione la classe di questo legame, perché è esattamente il tipo di affermazione che scivola se non la si marca.

Tra il controllo ottimo e il reinforcement learning c’è identità di problema, non semplice analogia: la struttura matematica — minimizzare un funzionale soggetto a una dinamica — è letteralmente la stessa, come argomenteremo nella sezione sulla meccanica e poi a fondo nella sezione dedicata.

Tra il controllo ottimo e il “framing di un agente come ottimizzatore di costo” c’è invece qualcosa di più debole, una parentela concettuale di struttura: lo schema “pesa l’obiettivo contro la spesa” è condiviso, ma un agente LLM non risolve un’equazione di Riccati e non ha una dinamica scritta in forma chiusa. Lo schema è identico; gli oggetti su cui gira no.

Tenere ferma questa distinzione — identità di problema tra RL e controllo, parentela di struttura tra controllo e agenti — è una delle discipline portanti del capitolo.

Terzo angolo: i prezzi nascosti dello stato

C’è un terzo modo di vedere la scena, ed è quello che rende intuitivo l’oggetto più astratto che incontreremo: le variabili aggiunte di Pontryagin. Pensa a un’azienda che gestisce un magazzino nel tempo. Lo stato è quanta merce ha in stock; il controllo è quanta ne produce o ne smaltisce a ogni istante; il costo combina lo spreco di sovrapproduzione e il danno di restare a corto.

A ogni istante, l’azienda può chiedersi una domanda economica precisa: quanto varrebbe per me avere un’unità di merce in più in questo momento? Se essere a corto sta per costare caro, quell’unità in più vale molto; se il magazzino è già pieno, vale poco o nulla.

Questo “valore marginale di un’unità di stato in più” è un prezzo ombra (shadow price): non è un prezzo di mercato, è quanto quell’unità vale per te nel tuo problema specifico, qui e ora. Il termine viene dall’economia, dove i prezzi ombra misurano il valore di rilassare un vincolo di una unità.

Le variabili aggiunte $\lambda(t)$ del controllo ottimo sono esattamente questo: il prezzo ombra dello stato, istante per istante. Hanno un’unità di misura precisa — costo per unità di stato — e cambiano nel tempo perché il valore di “stare in un certo stato” dipende da quanto manca alla fine e da cosa devi ancora fare.

La decisione ottima a ogni istante bilancia il costo immediato di un’azione contro il modo in cui quell’azione sposta lo stato, valutato a questi prezzi. È la stessa logica con cui un’azienda decide se produrre adesso: confronta il costo di produrre col valore della merce in più che si ritrova in mano. Tenere a mente questa lettura — le costate come prezzi — rende il principio di Pontryagin molto meno alieno quando arriveremo alla formula dell’Hamiltoniano.

La meccanica

Il problema, in forma compatta

Mettiamo insieme gli ingredienti dell’intuizione in una specifica unica. Un problema di controllo ottimo a orizzonte finito si scrive così: trova il controllo $u(t)$ che

$\text{minimizza}\quad J = \phi(x(T)) + \int_0^T L(x, u, t)\,dt$

$\text{soggetto a}\quad \dot{x} = f(x, u, t), \quad x(0) = x_0, \quad u(t) \in U$

Leggiamo riga per riga. La prima riga è l’obiettivo: il funzionale di costo, con il suo costo terminale $\phi$ e il suo costo di percorso $L$ integrato sull’orizzonte.

La seconda riga sono i vincoli: la dinamica $f$ (come lo stato evolve), la condizione iniziale $x(0) = x_0$ (da dove parti, dato), e l’insieme ammissibile $U$ in cui il controllo deve restare ( $|u| \le u_{max}$ , per esempio). I quattro ingredienti dell’intuizione — costo, dinamica come vincolo, vincoli su stato e controllo, orizzonte — sono tutti qui dentro, in due righe.

Due osservazioni sulla forma. La prima: cambiare i pesi dentro $L$ o cambiare $\phi$ cambia la soluzione, ed è la leva di progetto centrale — torneremo su questo in “Dove si rompe”, perché è anche la fonte dell’errore più comune.

La seconda: il vincolo $u(t) \in U$ è quello che separa il controllo ottimo “facile” (insieme $U$ illimitato, l’ottimo è interno, basta il calcolo delle variazioni) da quello “difficile” (insieme $U$ limitato, l’ottimo può stare sul bordo, serve Pontryagin). Tenendo ferma questa specifica, vediamo le due grandi vie per risolverla — storicamente parallele e profondamente legate — e poi il caso speciale che si risolve a mano.

Via A: il principio del massimo di Pontryagin

L’idea di Pontryagin è trasformare un problema impossibile in uno gestibile. Il problema impossibile è: cerca, tra tutte le funzioni $u(t)$ possibili, quella che minimizza $J$ . È una ricerca in uno spazio infinito-dimensionale, perché le funzioni candidate sono infinite e ciascuna è un oggetto continuo.

Il problema gestibile è invece: a ogni singolo istante, minimizza una sola quantità scalare rispetto a $u$ . Pontryagin mostra come passare dal primo al secondo, e l’ingrediente che lo permette è una quantità nuova che adesso costruiamo.

Lo strumento è l’Hamiltoniano, una quantità costruita combinando il costo di percorso con la dinamica:

$H(x, u, \lambda, t) = L(x, u, t) + \lambda^T f(x, u, t)$

In parole povere, l’Hamiltoniano somma due cose: quanto stai spendendo adesso ( $L$ ), più il “valore” del modo in cui stai muovendo lo stato ( $\lambda^T f$ , dove $f$ è la velocità dello stato e $\lambda$ è un prezzo che gli assegni).

Il vettore $\lambda$ è il pezzo nuovo e si chiama variabile aggiunta (o costate, o variabile adjoint). Sono moltiplicatori di Lagrange — gli stessi che in ottimizzazione vincolata trasformano un vincolo in un termine di penalità — ma qui variano nel tempo: c’è una $\lambda(t)$ per ogni istante. È esattamente il “prezzo ombra dello stato” del terzo angolo dell’intuizione: ora ha un nome e un ruolo dentro una formula.

Cosa rappresenta $\lambda$ , in concreto? È il prezzo ombra dello stato, l’oggetto del terzo angolo dell’intuizione: quanto migliorerebbe il costo ottimo totale se lo stato, in quell’istante, fosse marginalmente diverso.

Se trovarti un po’ più avanti lungo il percorso ti farebbe risparmiare molto, $\lambda$ è grande lì; se conta poco, è piccolo. È la valutazione, istante per istante, di quanto vale “stare in un certo stato” nel tuo problema specifico.

Il principio dice tre cose.

Primo: lungo la traiettoria ottima, il controllo $u^*(t)$ a ogni istante minimizza l’Hamiltoniano rispetto a $u$ (o lo massimizza, a seconda della convenzione di segno scelta per $H$ — la convenzione storica porta a una massimizzazione, da cui il nome “principio del massimo”). Questa è la mossa decisiva: la ricerca su uno spazio di funzioni è diventata, a ogni istante, una minimizzazione puntuale di una funzione scalare.

Secondo: lo stato evolve in avanti secondo la dinamica $\dot{x} = f$ , partendo dalla condizione iniziale data.

Terzo: le costate evolvono all’indietro nel tempo, secondo

$\dot{\lambda} = -\frac{\partial H}{\partial x}$

con una condizione al contorno fissata alla fine (legata al costo terminale $\phi$ ). In parole povere, il prezzo ombra in un istante si calcola sapendo come cambia il costo al variare dello stato, e si propaga indietro dalla fine verso l’inizio.

Il risultato netto è un problema ai valori al contorno a due punti: lo stato è noto all’inizio, le costate sono note alla fine, e devi trovare la traiettoria che le raccorda. Risolverlo dà la traiettoria ottima.

Un’avvertenza che torneremo a sottolineare in “Dove si rompe”: il principio dà condizioni necessarie, non sufficienti. Una traiettoria che le soddisfa è una candidata all’ottimalità, non automaticamente la migliore — può essere un minimo locale o un punto di sella.

Via B: programmazione dinamica e l’equazione HJB

Bellman attacca lo stesso problema da un’angolazione opposta, e l’intuizione è semplice e potente. Si chiama principio di ottimalità: se una traiettoria è ottima da A a B, allora da qualunque suo punto intermedio C in poi, il pezzo da C a B è a sua volta ottimo per il sottoproblema “vai da C a B”.

Detto altrimenti: un percorso ottimo è fatto di pezzi ciascuno ottimo. Se così non fosse, potresti migliorare il pezzo da C a B e quindi tutto il percorso, contraddicendo l’ipotesi che fosse ottimo. È un argomento per assurdo elementare, ma è il cardine di tutta la programmazione dinamica.

Questo permette di definire l’oggetto centrale di tutta la via di Bellman, la value function $V(x, t)$ : il costo ottimo per andare dallo stato $x$ al tempo $t$ fino alla fine.

È la cost-to-go — letteralmente “il costo che ti resta da pagare” se sei nello stato $x$ e ti comporti in modo ottimo da qui in avanti. Attenzione: non è il costo di una traiettoria scelta, è il costo della migliore traiettoria possibile a partire da lì. Questo nome, cost-to-go, è esattamente l’oggetto che il reinforcement learning chiama value function: lo vedremo nella sezione dedicata.

L’equazione che $V$ soddisfa è l’equazione di Hamilton-Jacobi-Bellman (HJB), una equazione differenziale alle derivate parziali:

$-\frac{\partial V}{\partial t} = \min_u \left[ L(x, u, t) + \left(\frac{\partial V}{\partial x}\right)^T f(x, u, t) \right]$

In parole povere, questa dice: il modo migliore di comportarti adesso bilancia due cose — quanto spendi nell’istante ( $L$ ) e quanto stai migliorando la tua posizione futura (il termine col gradiente di $V$ , che misura quanto un movimento dello stato riduce il costo che ti resta). Minimizzi su $u$ proprio questa somma.

Il nome onora tre persone. William Hamilton (matematico e fisico irlandese, 1805-1865) e Carl Jacobi (matematico tedesco, 1804-1851) svilupparono equazioni analoghe nella meccanica dell’Ottocento, riformulando le leggi del moto come problema di ottimizzazione; Bellman, un secolo dopo, le portò nel controllo aggiungendo il principio di ottimalità. La filiazione fra la meccanica variazionale ottocentesca e il controllo ottimo è documentata e diretta, non una somiglianza casuale.

C’è un legame preciso e bellissimo tra le due vie: lungo la traiettoria ottima, la costate di Pontryagin è il gradiente della value function di Bellman, $\lambda(t) = \partial V / \partial x$ . Il prezzo ombra dello stato (Pontryagin) e la sensibilità del costo-residuo allo stato (Bellman) sono la stessa quantità. Le due vie non sono due algoritmi scollegati per la stessa risposta: descrivono lo stesso ottimo, una lungo una traiettoria, l’altra su tutto lo spazio.

Quando il tempo è discreto, la HJB diventa l’equazione di Bellman, la stessa che fonda value iteration e Q-learning nel reinforcement learning (Parte VII):

$V(x) = \min_u \left[ L(x, u) + V(f(x, u)) \right]$

Stessa idea — il valore di adesso è il costo immediato più il valore ottimo del prossimo stato — in una sola riga ricorsiva.

Il prezzo di questa via lo dichiarò Bellman stesso, coniando un termine entrato nel linguaggio comune: la maledizione della dimensionalità (curse of dimensionality). La value function vive su tutto lo spazio di stato; se lo stato ha molte dimensioni, tabularla o calcolarla esattamente diventa intrattabile, perché il numero di stati esplode esponenzialmente con le dimensioni.

È il motivo per cui, fuori dai casi piccoli o speciali, si ricorre ad approssimazioni. Ed è esattamente lì che entra il reinforcement learning moderno, che approssima $V$ con una rete neurale invece di tabularla — pagando in esattezza per guadagnare in trattabilità.

Il caso che si risolve a mano: LQR

Quasi nessun problema di controllo ottimo ha soluzione analitica. C’è un’eccezione celebre, il workhorse del campo: il regolatore lineare quadratico (LQR, Linear Quadratic Regulator).

Si ottiene con due ingredienti speciali. Primo, una dinamica lineare: $\dot{x} = Ax + Bu$ , dove $A$ e $B$ sono matrici fisse (lo stato evolve come combinazione lineare di sé stesso e del controllo). Secondo, un costo quadratico:

$J = \int_0^\infty \left( x^T Q x + u^T R u \right) dt$

Qui $Q$ è una matrice (semidefinita positiva) che pesa l’errore di stato — quanto ti costa essere lontano da zero — e $R$ è una matrice (definita positiva) che pesa lo sforzo di controllo — quanto ti costa muovere gli attuatori. “Quadratico” significa proprio questo: il costo cresce con il quadrato di errore e sforzo, così che gli scostamenti grandi pesino sproporzionatamente più di quelli piccoli.

Il rapporto tra $Q$ e $R$ è la manopola di progetto: $Q$ grande rispetto a $R$ dice “raggiungi l’obiettivo in fretta, costi quel che costi”; $R$ grande dice “vai piano, risparmia attuatore”. Questa coppia di pesi è la stessa tensione obiettivo-contro-spesa che ricomparirà, in forma molto più informale, quando parleremo di policy agentiche.

Il risultato di Kalman (1960) è notevole: per questo caso il controllo ottimo è una retroazione lineare di stato

$u^*(t) = -K x(t), \qquad K = R^{-1} B^T P$

dove $P$ è una matrice che si ottiene risolvendo l’equazione algebrica di Riccati (per orizzonte infinito):

$A^T P + P A - P B R^{-1} B^T P + Q = 0$

In parole povere: il controllo ottimo è semplicemente “guarda lo stato attuale e applica un ingresso proporzionale ad esso, col segno giusto per riportarlo verso zero”. Tutta la difficoltà del problema infinito-dimensionale si concentra nel risolvere una sola equazione matriciale per trovare $P$ , dopodiché il controllore è banale da implementare.

Per orizzonte finito, $P$ diventa $P(t)$ e si trova integrando una versione differenziale della Riccati all’indietro nel tempo, esattamente come le costate di Pontryagin si propagano all’indietro: i due metodi, di nuovo, descrivono lo stesso ottimo.

LQR è importante per tre ragioni concrete. La prima: è l’unico caso generale risolvibile in forma chiusa, e quindi il banco di prova su cui si capisce cosa fa davvero il controllo ottimo. La seconda: è la base dei metodi non lineari pratici, perché iterative LQR e differential dynamic programming linearizzano il sistema attorno a una traiettoria e applicano LQR ripetutamente.

La terza: accoppiato a uno stimatore di stato — il filtro di Kalman, tema di kalman-filter-intuizione (in preparazione) — dà l’LQG, il regolatore ottimo per sistemi lineari con rumore gaussiano. È lo stesso LQG che il capitolo sul controllo robusto ha già messo sotto accusa: ottimo rispetto al modello, ma senza margini di robustezza garantiti, come mostrò John Doyle nel 1978. Ottimalità e robustezza sono due garanzie diverse, e questo capitolo costruisce la prima.

Esempi

Esempio numerico: LQR scalare a una dimensione

Prendiamo il caso più piccolo possibile, per vedere i numeri. Lo stato è uno scalare $x$ (una temperatura sopra il setpoint, diciamo), la dinamica è $\dot{x} = u$ (il controllo cambia direttamente lo stato), il costo è

$J = \int_0^\infty \left( x^2 + r\, u^2 \right) dt$

con $r > 0$ scalare. Qui $A = 0$ , $B = 1$ , $Q = 1$ , $R = r$ .

L’equazione di Riccati $A^T P + PA - PBR^{-1}B^TP + Q = 0$ diventa, sostituendo i valori, $0 + 0 - P^2/r + 1 = 0$ , cioè $P^2 = r$ , da cui $P = \sqrt{r}$ (prendiamo la radice positiva, l’unica che dà una soluzione stabile). Il guadagno è $K = R^{-1}B^T P = \sqrt{r}/r = 1/\sqrt{r}$ , e la legge di controllo è

$u^* = -\frac{1}{\sqrt{r}}\, x$

Leggiamo il risultato. Se il controllo è economico ( $r$ piccolo), $1/\sqrt{r}$ è grande: il controllore reagisce in modo aggressivo, spinge forte, porta $x$ a zero in fretta. Se il controllo è costoso ( $r$ grande), il guadagno è piccolo: il controllore è prudente, lascia che $x$ decada lentamente per non spendere in attuazione.

La manopola $r$ — il prezzo relativo dello sforzo — sposta con continuità il comportamento da “aggressivo” a “parsimonioso”. Questa è, in miniatura, l’intera estetica del controllo ottimo: il comportamento non lo scrivi tu a mano, emerge dalla scelta del costo. È anche, in miniatura, il motivo per cui scegliere male il costo è così pericoloso.

Esempio in codice: un passo di controllo ottimo a orizzonte ricedente

Il modo più comune di usare il controllo ottimo nei sistemi reali è risolverlo a orizzonte finito, applicare solo la prima azione, e ripianificare al passo dopo. È lo schema del model predictive control. In pseudocodice:

def passo_controllo_ottimo(x_corrente, modello, costo, orizzonte_H):
    # 1. Risolvi il problema di controllo ottimo su un orizzonte
    #    finito, partendo dallo stato osservato adesso.
    #    Restituisce la sequenza ottima u_0, u_1, ..., u_{H-1}.
    sequenza_u = risolvi_ottimo(
        stato_iniziale=x_corrente,
        dinamica=modello,         # x_{k+1} = f(x_k, u_k), il vincolo
        costo=costo,              # somma di L sui passi + costo terminale
        vincoli_controllo=...,    # es. |u| <= u_max
        orizzonte=orizzonte_H,
    )
    # 2. Applica SOLO la prima azione. Il resto si butta:
    #    al prossimo istante riosservi e ripianifichi.
    return sequenza_u[0]

# Loop di controllo: ripianifica a ogni istante (receding horizon)
while True:
    x = osserva_stato()                 # sensore
    u = passo_controllo_ottimo(x, modello, costo, orizzonte_H)
    applica(u)                          # attuatore

Il punto da notare è il commento al passo 2: si calcola un piano di $H$ mosse ma se ne usa una sola, perché allo step successivo si riosserva e si ricalcola. Questo riassorbe gli errori di modello e i disturbi — è ciò che rende il controllo ottimo a feedback invece che un piano cieco eseguito alla lettera. Il legame con gli agenti è diretto: un agente che pianifica $N$ passi, esegue il primo, riosserva l’effetto e ripianifica sta facendo esattamente questo loop.

Esempio scenario reale: l’atterraggio a minimo carburante

Il problema originale di Pontryagin era un razzo, e vale la pena vederlo perché esibisce un comportamento sorprendente. Vuoi far atterrare un veicolo spendendo il minimo carburante possibile, con un motore che può erogare spinta tra zero e un massimo $u_{max}$ . Lo stato include quota e velocità; il costo è il carburante totale bruciato; la dinamica è la fisica del moto sotto gravità e spinta; il vincolo è $0 \le u \le u_{max}$ .

La soluzione ottima, in molti casi di questo tipo, è bang-bang: il motore sta o completamente spento o completamente acceso, e commuta istantaneamente da uno all’altro a un istante preciso. Niente spinta intermedia.

Questo è esattamente il caso in cui il calcolo delle variazioni classico fallirebbe. La condizione “derivata nulla all’interno” non si applica, perché l’ottimo vive sul bordo dell’insieme ammissibile. È il motivo per cui serve il principio di Pontryagin, che gestisce nativamente i vincoli sul controllo minimizzando l’Hamiltoniano sull’insieme ammissibile: e il minimo, per un Hamiltoniano lineare in $u$ , cade sempre a un estremo, da cui il comportamento on-off.

L’intuizione fisica è semplice: se devi rallentare con la minima spesa, non ha senso “tenere il motore a metà”; conviene scegliere l’istante giusto e poi spingere a fondo. L’analogo software è un autoscaler che, invece di aggiungere capacità un po’ alla volta, calcola il momento ottimo per un singolo scatto netto di provisioning.

Esempio discreto: la value function calcolata all’indietro

Per vedere la via di Bellman al lavoro su numeri, prendiamo un problema minuscolo a tempo discreto. Un sistema ha tre stati possibili — chiamiamoli A, B, C — e due passi di tempo prima della fine. Da ogni stato puoi scegliere un’azione che ti porta a uno stato diverso al passo successivo, e ogni transizione costa qualcosa.

Lo stato finale C non costa nulla (è l’obiettivo); restare in A o in B alla fine costa molto. Vogliamo il costo minimo per arrivare a C partendo da A.

Bellman risolve questo problema all’indietro, sfruttando il principio di ottimalità. Prima riempie la value function all’ultimo passo: $V(C) = 0$ , $V(A)$ e $V(B)$ pari al loro costo terminale.

Poi indietreggia di un passo: per ogni stato, $V(\text{stato})$ è il minimo, sulle azioni disponibili, di (costo della transizione $+$ value function dello stato in cui finisci). Indietreggiando ancora di un passo si ottiene $V$ all’inizio, e leggendo a ritroso quale azione ha realizzato ogni minimo si ricostruisce la sequenza ottima di azioni.

Il punto pedagogico è triplo.

Primo: la value function si calcola dalla fine verso l’inizio, esattamente come le costate di Pontryagin si propagano all’indietro — non è una coincidenza, è la stessa struttura vista da due angoli.

Secondo: una volta che hai $V$ su tutti gli stati, hai la policy per ogni stato, non solo per quello da cui sei partito. Questo è il guadagno della via di Bellman, e insieme il suo costo: devi riempire tutto lo spazio degli stati, ed è proprio qui che morde la maledizione della dimensionalità.

Terzo: questo identico schema — riempire una tabella all’indietro, scegliendo a ogni cella il minimo costo-immediato più valore-futuro — è la programmazione dinamica della Parte VIII e la value iteration del reinforcement learning della Parte VII. Tre nomi, una procedura.

Applicazioni pratiche

Nel mondo del controllo fisico, l’LQR è ovunque ci sia un sistema linearizzabile e un costo quadratico ragionevole: assetto di satelliti, stabilizzazione di droni, sospensioni attive, convertitori di potenza. È il primo controllore “serio” che si prova quando il PID non basta e si ha un modello.

Nel mondo dell’AI, il controllo ottimo entra da tre porte.

La prima è il reinforcement learning, di cui diremo tra poco a fondo: ogni volta che addestri una policy per massimizzare una ricompensa, stai risolvendo (in modo approssimato, dai dati) un problema di controllo ottimo.

La seconda è il model predictive control come modello di planning: il pattern “pianifica un orizzonte, esegui un passo, ripianifica” che vedremo formalizzato in model-predictive-control (in preparazione) è il modo in cui molti agenti gestiscono task lunghi sotto incertezza.

La terza è più sottile e riguarda la progettazione di policy agentiche: il trade-off $Q$ contro $R$ dell’LQR — quanto pesi il raggiungere l’obiettivo contro quanto pesi lo sforzo — ricompare quando decidi quanto un agente debba “spingere” per completare un task contro quanto debba risparmiare token, chiamate, rischio. Non è la stessa equazione, ma è la stessa estetica progettuale: il comportamento che ottieni è figlio del costo che hai scritto.

C’è poi un’applicazione concettuale che vale per chiunque progetti sistemi che ottimizzano: il controllo ottimo insegna che la scelta del costo è la decisione più importante. Cambia $L$ e cambia tutto il comportamento ottimo. È la stessa lezione che, dal lato delle metriche, prende il nome di legge di Goodhart (quando una metrica diventa un bersaglio, smette di essere una buona metrica) e di reward hacking (trattati nella Parte XVI, in preparazione): se ottimizzi alla lettera un costo mal scritto, ottieni il comportamento mal scritto, eseguito perfettamente.

L’agente come problema di controllo ottimo, in concreto

Vale la pena svolgere il caso agentico con un po’ di dettaglio, perché è il più vicino al lavoro quotidiano di chi usa questa wiki. Immagina un agente di coding incaricato di risolvere un bug. A ogni passo osserva uno stato — il codice attuale, l’output dell’ultimo test, ciò che ha già provato — e sceglie un’azione: leggere un file, modificare una riga, lanciare i test. Il mondo reagisce: i test passano o falliscono, il file cambia.

Questo è, riga per riga, un problema di controllo. Il costo terminale è “il bug è risolto e i test passano” (basso) contro “il bug resta” (alto). Il costo di percorso è quante risorse l’agente brucia a ogni passo: token consumati, chiamate ad API costose, tempo, rischio di un’azione distruttiva.

Una policy che ignora il costo di percorso risolverà il bug, magari, ma dopo cinquanta tentativi ridondanti e una spesa spropositata. Una policy che pesa troppo il costo di percorso rinuncerà presto, lasciando il bug irrisolto per “risparmiare”. Il bilanciamento giusto è esattamente il trade-off $Q$ contro $R$ dell’LQR, trasposto su un sistema senza equazioni in forma chiusa.

La cautela, di nuovo, sulla classe di affermazione. Un agente LLM non risolve un’equazione di Riccati, non ha una dinamica $f$ scritta in forma chiusa, non calcola una value function esatta. Quindi non c’è identità con il controllo ottimo classico: c’è una parentela di struttura.

Lo schema — bilanciare il valore dell’obiettivo contro il costo della spesa, lungo una sequenza di decisioni sotto una dinamica — è lo stesso; gli strumenti per risolverlo sono completamente diversi. Riconoscere lo schema aiuta a progettare le policy, e a capire perché un agente “spinge troppo” o “molla troppo presto”. Confonderlo con l’identità porta invece a cercare equazioni di Riccati dove non ce ne sono.

C’è infine il legame con il planning, che il prossimo capitolo formalizza. Un agente che pianifica una sequenza di azioni, ne esegue la prima, riosserva l’effetto e ripianifica sta facendo il loop a orizzonte ricedente dell’esempio in codice — cioè model predictive control.

Il planning agentico, visto da questo angolo, è controllo ottimo risolto online e in modo approssimato, con la ripianificazione che assorbe gli errori del modello mentale dell’agente. È un legame più stretto della semplice parentela di struttura, perché qui lo schema operativo — pianifica, esegui una mossa, riosserva, ripianifica — coincide davvero. Lo riprenderemo in model-predictive-control (in preparazione).

Dove si rompe

Il controllo ottimo è potente esattamente nella misura in cui le sue assunzioni reggono, e quasi sempre non reggono del tutto. I limiti contano quanto i meccanismi: elenchiamo i modi in cui si rompe, dal più insidioso al più tecnico.

“Ottimo” non vuol dire “buono”. L’ottimo è sempre relativo al costo che hai scelto. Se scrivi male il funzionale — pesi la cosa sbagliata, dimentichi un termine, metti un peso a caso — ottieni la soluzione perfettamente ottima del problema sbagliato.

Un controllore di crociera che minimizza solo il consumo, senza un termine di comfort, ti sballotterà a ogni cambio di pendenza: è ottimo, ed è inguardabile. La trappola è confondere “ottimo” con “ciò che volevo”: il controllo ottimo ottimizza ciò che gli dici, non ciò che intendi. È la versione control-theory di una lezione che ricompare in tutta l’AI ogni volta che si specifica un obiettivo.

Pontryagin dà condizioni necessarie, non sufficienti. Una traiettoria che soddisfa il principio del massimo è una candidata. Può essere un minimo locale, un punto di sella, o un massimo travestito. Per problemi non convessi — la maggioranza — possono esserci molte soluzioni che soddisfano le condizioni necessarie, e trovare quella globalmente ottima è un problema a sé. Il principio restringe il campo, non lo chiude.

La HJB soffre la maledizione della dimensionalità. La via di Bellman dà la policy ottima ovunque, ma calcolare la value function su uno spazio di stato ad alta dimensione è intrattabile: il costo cresce esponenzialmente con il numero di dimensioni. Per un robot con decine di gradi di libertà, o per un agente il cui “stato” è un intero context window, tabularla è fuori questione.

Da qui l’intero edificio delle approssimazioni: LQR locale, MPC a orizzonte corto, RL con approssimatori di funzione. Il controllo ottimo esatto è un ideale; quasi sempre si lavora con sue ombre approssimate, e gran parte della ricerca degli ultimi sessant’anni è stata su come approssimarlo bene.

LQR non è il controllo ottimo, è un suo caso speciale. È facile, dopo aver visto l’eleganza di $u = -Kx$ , pensare che il controllo ottimo “si risolva così”. No: quella forma chiusa esiste solo perché la dinamica è lineare e il costo quadratico.

La stragrande maggioranza dei sistemi reali è non lineare, e per loro non c’è una formula chiusa: si linearizza (e si perde validità lontano dal punto di linearizzazione), si discretizza (e si paga in calcolo), o si approssima con metodi numerici. L’eleganza dell’LQR è reale, ma è l’eccezione, non la regola.

Il modello deve essere noto e giusto. Il controllo ottimo classico assume di conoscere la dinamica $f$ . Se il modello è sbagliato — e nessun modello è esatto, come martella il capitolo sul controllo robusto — la traiettoria “ottima” calcolata sul modello può essere mediocre o instabile sul sistema vero.

L’ottimalità rispetto a un modello e la robustezza rispetto all’incertezza del modello sono cose diverse, e la prima comprata senza la seconda è una garanzia solo sulla carta. È esattamente la lezione di Doyle del 1978 sull’LQG: un controllore può essere nominalmente ottimo e instabilizzarsi per una perturbazione minuscola del modello.

Il bordo tra controllo e RL è una transizione, non un muro. Si tende a dire “RL è controllo ottimo”: vero come identità di problema, ma operativamente fuorviante se lasciato nudo.

Il controllo ottimo classico parte da un modello noto e risolve il problema offline, in anticipo. Il reinforcement learning nasce per il caso in cui il modello è ignoto o troppo complesso, e impara per tentativi interagendo con l’ambiente. Stesso problema, mondi operativi diversi: chi confonde i due rischia di applicare i metodi di uno dove servono quelli dell’altro — per esempio cercando una soluzione in forma chiusa dove l’unica via è imparare dai dati.

Il legame con il reinforcement learning, marcato con cura

Questo merita una sezione propria, perché è il ponte più importante del capitolo verso il resto della wiki, ed è anche quello che si racconta peggio se non si è precisi sulla classe di affermazione.

L’affermazione forte è: il reinforcement learning è controllo ottimo quando la dinamica non è nota e la si impara dai dati. Questa è identità di problema, non analogia didattica. Argomentiamola pezzo per pezzo, perché un’identità va dimostrata, non asserita.

La value function del reinforcement learning — il valore atteso di uno stato sotto una policy — è la cost-to-go del controllo ottimo, a meno del segno: RL massimizza una ricompensa cumulata, il controllo minimizza un costo cumulato, e ricompensa è costo cambiato di segno. Stesso oggetto, due convenzioni.

L’equazione di Bellman del reinforcement learning è la versione discreta nel tempo dell’equazione di Hamilton-Jacobi-Bellman del controllo ottimo. Letteralmente la stessa equazione — il valore di adesso è il costo immediato più il valore ottimo del prossimo stato — scritta dalla stessa persona, Richard Bellman, per gli stessi motivi.

Questa è filiazione documentata, non semplice somiglianza: il termine “dynamic programming” di Bellman (1957) precede e fonda l’equazione di Bellman che la comunità del reinforcement learning usa oggi. Non sono due idee nate separate che poi si assomigliano; è una sola idea, ereditata.

Anche i metodi si corrispondono. Value iteration e policy iteration sono programmazione dinamica applicata quando il modello è noto. Q-learning e policy gradient sono le loro versioni model-free, che lavorano da campioni quando il modello non c’è.

Non è un parallelo che traccio io: il reinforcement learning è spesso descritto, in letteratura, come approximate dynamic programming o neuro-dynamic programming, due nomi che dichiarano apertamente la parentela. Bertsekas, nel suo Reinforcement Learning and Optimal Control (2019), tratta i due come un’unica disciplina; Sutton e Barto, nel canonico Reinforcement Learning: An Introduction (2018), dedicano un capitolo intero al legame con la programmazione dinamica.

La differenza che resta, e che va detta con la stessa precisione, è operativa, non strutturale. Il controllo ottimo classico assume di avere le equazioni del sistema e risolve il problema in anticipo, offline. Il reinforcement learning nasce per il caso in cui quelle equazioni non ci sono — il mondo è troppo complesso, o sconosciuto.

Allora l’RL impara la policy per tentativi, interagendo con l’ambiente, e approssima la value function (per esempio con una rete neurale) invece di calcolarla esattamente. È proprio questo approssimare che gli permette di schivare la maledizione della dimensionalità che renderebbe la HJB intrattabile. Stesso problema, due regimi: modello noto contro modello appreso. Il ponte Da feedback e controllo a MDP, Bellman, RL della Parte X percorre proprio questa strada, dal feedback e dal controllo fino a MDP, Bellman e reinforcement learning.

Collegamenti

Controllare un sistema: plant, controller, sensore, attuatore — il vocabolario di base (stato, controllo, plant, feedback) su cui tutto questo capitolo si appoggia.
Lyapunov a intuizione: energia che scende — un’altra via a un controllore con garanzia; lì la garanzia è di stabilità, qui di ottimalità rispetto a un costo. C’è anche un legame tecnico: la value function della HJB è una funzione di Lyapunov per il sistema in anello chiuso ottimo.
Robustezza a rumore, incertezza e disturbi — il rovescio della medaglia: l’LQR è ottimo rispetto a un modello, ma l’ottimalità non garantisce robustezza, come mostra il controesempio di Doyle sull’LQG.
Ottimizzare funzioni di funzioni — la radice matematica del controllo ottimo: minimizzare un funzionale. Il principio di Pontryagin generalizza l’equazione di Eulero-Lagrange ai problemi con vincoli sul controllo.
Bellman e programmazione dinamica — l’equazione di Bellman è la versione discreta della HJB; questo è il punto di contatto formale tra controllo ottimo e reinforcement learning.
DP con esempi classici — la programmazione dinamica come tecnica algoritmica generale, di cui la via di Bellman al controllo ottimo è un caso continuo.
Iterazione del valore e della policy — i metodi di programmazione dinamica per risolvere il controllo ottimo quando il modello è noto e lo stato è discreto.
Da feedback e controllo a MDP, Bellman, RL — il ponte che percorre esplicitamente il passaggio dal controllo al reinforcement learning, di cui questo capitolo dà la versione formale.
Giochi a somma zero e minimax — utile per contrasto: il controllo robusto è un min-max contro un avversario, il controllo ottimo è una pura minimizzazione contro una natura fissa.
model-predictive-control (in preparazione) — il modo operativo più comune di usare il controllo ottimo: risolverlo a orizzonte finito, applicare la prima mossa, ripianificare.
kalman-filter-intuizione (in preparazione) — la metà mancante dell’LQG: stimare lo stato da misure rumorose, da accoppiare all’LQR.

Per andare oltre

L. S. Pontryagin, V. G. Boltyanskii, R. V. Gamkrelidze, E. F. Mishchenko, The Mathematical Theory of Optimal Processes (1962, trad. inglese). Il testo fondativo del principio del massimo: Hamiltoniano, costate, condizioni necessarie. Denso ma è la fonte.
R. Bellman, Dynamic Programming (Princeton University Press, 1957). L’origine della programmazione dinamica, del principio di ottimalità e dell’espressione “curse of dimensionality”.
R. E. Kalman, “Contributions to the Theory of Optimal Control” (1960). Il paper che fonda l’LQR e l’equazione di Riccati; con i lavori paralleli sul filtro di Kalman, la base dell’LQG.
D. P. Bertsekas, Reinforcement Learning and Optimal Control (Athena Scientific, 2019). La trattazione che unifica esplicitamente le due discipline; il riferimento per capire perché RL e controllo ottimo sono lo stesso problema.
H. J. Sussmann, J. C. Willems, “300 Years of Optimal Control: From the Brachystochrone to the Maximum Principle” (IEEE Control Systems Magazine, 1997). Un percorso storico leggibile dal calcolo delle variazioni a Pontryagin, ottimo per cogliere la filiazione.