Receding horizon: planning, vincoli e ri-ottimizzazione

Il Model Predictive Control prende il controllo ottimo e lo rende usabile nel mondo vero con una mossa sola: invece di calcolare il piano perfetto una volta, lo ricalcola da capo a ogni passo a partire da dove il sistema si trova davvero. Da questa idea — pianifica, esegui solo il primo passo, ri-pianifica — nascono la sua robustezza, la sua gestione esplicita dei vincoli, e l’analogia più profonda di tutta la Parte con il modo in cui un agente ragiona.

Perché questo capitolo

Una raffineria degli anni Settanta è un sistema con decine di valvole, decine di temperature e pressioni che si influenzano a vicenda, e una lista di limiti da non superare: oltre una certa temperatura un catalizzatore si rovina, oltre una certa pressione una colonna è in pericolo. E il punto in cui si fanno i soldi è proprio vicino a quei limiti, non lontano: più si spinge l’impianto al confine del consentito, più resa si estrae. Nessun PID, nessun regolatore a formula fissa sa fare questo: spingere fino al bordo del consentito, su molte variabili accoppiate, senza mai sforare. Per risolvere quel problema, dentro le raffineri di Shell e nei laboratori francesi di automazione, è nato il Model Predictive Control.

Il controllo ottimo — il capitolo precedente di questa Parte — risolve un problema bellissimo e quasi sempre impraticabile così com’è: calcola la sequenza di controlli migliore su tutto l’orizzonte, in un colpo solo, assumendo di conoscere il modello alla perfezione e di non subire disturbi. Nella realtà il modello è approssimato, i disturbi arrivano, e una traiettoria ottima calcolata oggi è già subottima domani, perché il mondo non si è comportato come previsto.

Il Model Predictive Control (MPC), detto anche controllo predittivo o receding horizon control (controllo a orizzonte mobile), è l’idea che chiude questo divario. Lo schema in una frase: a ogni passo, usa un modello del sistema per simulare e ottimizzare la sequenza di azioni su un orizzonte finito futuro, applica solo la prima azione, poi al passo successivo ri-ottimizza con lo stato aggiornato.

Conta saperlo per due motivi. Il primo è ingegneristico: l’MPC è il metodo di controllo avanzato più usato nell’industria, e oggi guida anche droni, automobili e robot. Il secondo, e per questa wiki il più importante, è concettuale: lo schema dell’MPC — pianifica un po’ avanti, esegui solo il primo passo, osserva, ri-pianifica — è lo stesso schema con cui un agente che ragiona affronta un compito. Capire l’MPC è capire perché il loop “plan-act-observe-replan” di un agente è robusto, e dove quell’analogia regge e dove si rompe.

Cosa succede se ignori questa idea? Le due alternative ingenue falliscono in modi prevedibili. Se pianifichi tutto una volta sola e poi esegui senza guardare — controllo open-loop — basta un disturbo e il piano va a pezzi, perché continui a inseguire una traiettoria pensata per un mondo che non c’è più. Se invece reagisci solo all’errore presente senza guardare avanti — feedback puro, come un PID — sei robusto ma miope: non sai anticipare, non sai rispettare i vincoli prima di colpirli, non sai coordinare molte variabili che si influenzano. L’MPC è la sintesi: pianifica come l’open-loop, ma esegue e ri-pianifica come il feedback. Prende il meglio dei due.

Questa sintesi è esattamente il motivo per cui lo schema riemerge nei sistemi di AI. Un agente che pianifica un compito complesso ha lo stesso dilemma: se segue un piano rigido, un imprevisto lo manda fuori strada; se reagisce solo all’ultimo messaggio, non sa portare a termine niente di articolato. La via d’uscita è la stessa dell’MPC, e capire perché funziona nel controllo aiuta a capire perché funziona — e quando non funziona — negli agenti.

Contesto

Questo capitolo è il punto in cui i quattro capitoli precedenti della Parte XI si combinano in un singolo metodo.

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 setpoint è dove vogliamo portarlo. Eredita la nozione di costo, dinamica e vincoli dal controllo ottimo. Usa il terminal cost come funzione di Lyapunov, concetto che viene da Lyapunov a intuizione: energia che scende. E condivide con il controllo robusto il problema di fondo: agire bene nonostante il modello sia imperfetto e i disturbi reali.

Le date e i nomi che contano. L’MPC è uno dei rari casi in cui la pratica industriale ha preceduto la teoria di vent’anni. Nel 1978 Jacques Richalet e colleghi (ingegneri francesi del laboratorio ADERSA) pubblicano Model predictive heuristic control: Applications to industrial processes (Automatica, 1978), che descrive l’algoritmo IDCOM, basato su modelli a risposta impulsiva e applicato a impianti petrolchimici. Quasi in parallelo, Charles Cutler e Brian Ramaker, ingegneri di Shell Oil, sviluppano il Dynamic Matrix Control (DMC), presentato a conferenze tecniche nel 1979-1980: usa modelli a risposta al gradino e risolve un problema di minimi quadrati con vincoli. DMC diventa lo standard de facto delle raffinerie.

Le due tradizioni — quella europea di Richalet con modelli a risposta impulsiva, quella americana di Shell con modelli a risposta al gradino — convergono sullo stesso schema di fondo: prevedi con un modello, ottimizza su un orizzonte, applica il primo passo, ripeti. Che due gruppi distanti, partendo da formalismi diversi, arrivassero alla stessa idea quasi negli stessi anni dice quanto fosse matura la domanda: l’industria di processo aveva bisogno di un controllore che gestisse vincoli e variabili accoppiate, e il receding horizon era la risposta naturale che aspettava solo di essere formulata.

Perché nasce proprio nel processo chimico e petrolifero, e non altrove? Tre ragioni che vale la pena tenere a mente, perché spiegano anche dove l’MPC arriverà dopo. Primo: i sistemi di processo sono lenti, con costanti di tempo di minuti o ore, quindi anche i computer dell’epoca avevano tutto il tempo di risolvere un’ottimizzazione tra un campione e il successivo. Secondo: questi impianti hanno molte variabili accoppiate — muovere una valvola sposta tre temperature — e i metodi a anello singolo come il PID, che governano una variabile alla volta, faticano. Terzo: hanno molti vincoli e il valore economico sta nell’operare vicino a quei vincoli. L’MPC era l’unico schema che gestiva esplicitamente i vincoli mentre coordinava molte variabili insieme.

Contro cosa si è affermato. Prima dell’MPC, il controllo industriale era dominato dai loop PID, ottimi per una variabile isolata ma ciechi ai vincoli e alle interazioni. Spingere un PID vicino a un limite significava aggiungere saturazioni, logiche di override, anti-windup: un castello di toppe attorno a un controllore che, dentro di sé, non sapeva nulla del limite. L’MPC ha sostituito quel castello con un’idea sola: metti i vincoli e le interazioni dentro il problema che risolvi a ogni passo.

La teoria arriva dopo. Nel 2000 David Mayne (ingegnere del controllo britannico-sudafricano), James Rawlings (ingegnere chimico statunitense) e i colleghi Christopher Rao e Pierre Scokaert pubblicano Constrained model predictive control: Stability and optimality (Automatica, 2000): il survey che mette in ordine, dopo decenni di pratica, le condizioni sotto cui l’MPC è stabile. È un’inversione insolita: di solito la teoria precede l’applicazione; qui un metodo girava nelle raffinerie da vent’anni prima che si dimostrasse rigorosamente quando converge. Rawlings e Mayne scrivono poi il testo di riferimento, Model Predictive Control: Theory, Computation, and Design.

Perché la teoria ha tardato così tanto? Perché l’MPC, nella sua forma vincolata, non si lascia analizzare con gli strumenti del controllo lineare classico. La legge di controllo non è una formula chiusa: è la soluzione di un’ottimizzazione, che cambia forma a seconda di quali vincoli sono attivi. Dimostrare che un controllore implicito, definito da un solver, sia stabile ha richiesto idee nuove — in particolare l’uso del valore ottimo del problema come funzione di Lyapunov, che è il cuore del survey del 2000. Fino ad allora, gli ingegneri sapevano che funzionava perché lo vedevano funzionare, ma non sapevano dire quando avrebbe potuto fallire.

L’intuizione

Tre angoli, prima di qualunque formula. Il primo è la metafora del guidatore che guarda avanti e ricorregge: spiega il receding horizon. Il secondo è strutturale: l’MPC sostituisce la formula del controllore con un solver, e questo è ciò che gli dà i suoi superpoteri e i suoi costi. Il terzo isola la qualità che distingue l’MPC da ogni controllore reattivo: la capacità di anticipare ciò che del futuro è già noto.

Primo angolo: il guidatore che guarda avanti e ricorregge

Guidi un’auto su una strada di montagna. Non pianifichi tutta la salita con un unico, irrevocabile programma di sterzate deciso in partenza. Fai un’altra cosa, e la fai senza pensarci: guardi avanti di qualche centinaio di metri — non oltre, perché oltre la curva non vedi — e ti fai un’idea di come affrontare le prossime curve. Su questa idea dai una piccola correzione al volante adesso. Poi l’auto avanza di qualche metro, e tu guardi di nuovo, con la strada aggiornata sotto gli occhi, e ri-pianifichi.

Tre cose in questa scena sono l’essenza dell’MPC.

La prima: guardi avanti di un tratto finito, non fino all’arrivo. Questo è l’orizzonte di predizione. Pianificare fino alla destinazione sarebbe inutile (la strada lontana non la vedi) e costoso.

La seconda: applichi solo la prima azione. Il piano mentale che ti sei fatto sulle prossime cinque curve serve a decidere bene la sterzata di adesso. Le altre quattro le butti via, perché tra un istante rifarai il piano da capo.

La terza: ri-pianifichi sull’osservazione reale. Se una raffica di vento o una buca ti sposta, non stai eseguendo un piano vecchio basato su dove pensavi di essere: ne fai uno nuovo a partire da dove sei davvero. È qui che entra il feedback. L’orizzonte di “guardare avanti” scorre con te, in avanti, a ogni istante. In inglese recede: si allontana mentre tu avanzi. Da qui “receding horizon”, orizzonte che scorre.

Questa terza proprietà è il motivo per cui lo schema funziona in un mondo imperfetto. Il piano è sempre fatto a partire dalla realtà misurata, mai dalla previsione di ieri.

Secondo angolo: il controllore è un solver, non una formula

Tutti i controllori visti finora calcolano il comando con una formula. Il PID combina errore, integrale e derivata secondo tre coefficienti. L’LQR — il regolatore lineare quadratico del controllo ottimo — moltiplica lo stato per una matrice di guadagno fissa, calcolata una volta sola offline: dato lo stato $x$ , il comando è $u = -Kx$ , una moltiplicazione.

L’MPC fa qualcosa di radicalmente diverso. Il comando non viene da una formula: viene dall’output di un problema di ottimizzazione risolto da zero a ogni passo. A ogni ciclo di campionamento, l’MPC imposta un piccolo problema di controllo ottimo sull’orizzonte futuro, lo dà in pasto a un solver, e legge la prima azione della soluzione.

Sembra uno spreco — perché risolvere un’ottimizzazione completa solo per ricavarne una mossa che butterai via tra un istante? Ma è esattamente questo a dare all’MPC ciò che le formule non hanno. Una formula come $u = -Kx$ non sa cosa siano i vincoli: può “chiedere” il 150% di apertura di una valvola, e poi qualcuno deve tagliare quel comando a posteriori. Un solver, invece, ha i vincoli dentro il problema: la soluzione che produce li rispetta per costruzione. E una formula è miope — reagisce allo stato di adesso; un solver guarda l’intero orizzonte e anticipa: se sa che tra cinque passi colpirà un limite, agisce ora per non finirci contro.

Vale la pena fissare un legame esatto, perché illumina cos’è l’MPC. Togli i vincoli e fai tendere l’orizzonte all’infinito: l’MPC lineare-quadratico coincide con l’LQR. Non gli somiglia: è la stessa legge di controllo. Questa è un’equivalenza in senso stretto, dimostrabile, e va detta come tale. L’MPC è, in un certo senso, il fratello “vincolato e a orizzonte finito” dell’LQR: quando spegni vincoli e finitezza dell’orizzonte, i due si fondono.

Terzo angolo: anticipare, non solo reagire

C’è una terza qualità dell’MPC che né la metafora del guidatore né il confronto con l’LQR mettono a fuoco del tutto: l’MPC sa anticipare il futuro noto. Un PID reagisce all’errore presente — vede dove sei rispetto a dove vuoi essere, e corregge. È puramente retrospettivo: non sa nulla di ciò che sta per arrivare.

L’MPC, simulando l’orizzonte in avanti, può incorporare informazione sul futuro che già conosci. Se sai che tra dieci passi il setpoint cambierà (un robot che dovrà accelerare in vista di un tratto rettilineo, un edificio in cui il prezzo dell’energia salirà alle 18), l’MPC inizia a prepararsi ora, distribuendo lo sforzo nel tempo invece di farsi cogliere impreparato. Questa capacità di guardare avanti a riferimenti e disturbi futuri noti — una forma di feedforward integrata nell’ottimizzazione — è qualcosa che un controllore puramente reattivo non potrà mai avere. È la differenza tra frenare quando vedi il muro e rallentare perché sai che il muro arriverà.

I tre angoli si tengono insieme. Il receding horizon spiega come l’MPC resta robusto (ri-pianifica sulla realtà); il solver al posto della formula spiega cosa sa fare in più (vincoli, multivariabile); l’anticipazione spiega perché è qualitativamente diverso dal feedback reattivo (agisce sul futuro previsto, non solo sull’errore presente). Tienili a mente tutti e tre quando, più avanti, ritroverai lo schema negli agenti: ciascuno illumina un aspetto diverso del perché funziona.

La meccanica

Mettiamo in formule lo schema del primo angolo. Useremo il tempo discreto, perché l’MPC vive a passi di campionamento: a ogni passo si misura, si ottimizza, si applica.

Il periodo tra un campione e l’altro è esso stesso una scelta di progetto: abbastanza breve da reagire ai disturbi in tempo, abbastanza lungo da lasciare al solver il tempo di finire la sua ottimizzazione prima che serva il comando successivo. Questo vincolo temporale — l’ottimizzazione deve concludersi entro il ciclo — è ciò che separa l’MPC su carta dall’MPC che gira davvero su un sistema.

Il problema risolto a ogni passo

Sia $k$ l’istante corrente e $x_k$ lo stato del sistema misurato adesso. L’MPC risolve questo problema di controllo ottimo a orizzonte finito $N$ :

$\min_{u_0,\, u_1,\, \dots,\, u_{N-1}} \; V_f(x_N) + \sum_{i=0}^{N-1} \ell(x_i, u_i)$

soggetto, per ogni passo $i$ dell’orizzonte, a:

$x_{i+1} = f(x_i, u_i), \qquad x_0 = x_k, \qquad x_i \in \mathbb{X}, \qquad u_i \in \mathbb{U}, \qquad x_N \in \mathbb{X}_f$

Spieghiamo ogni pezzo, perché ciascuno porta un’idea.

Le variabili decisionali sono $u_0, u_1, \dots, u_{N-1}$ : la sequenza di azioni che il solver è libero di scegliere lungo l’orizzonte. Sono $N$ azioni future ipotetiche.

La prima riga di vincoli, $x_{i+1} = f(x_i, u_i)$ , è la dinamica del modello: dato lo stato $x_i$ e l’azione $u_i$ , il modello predice lo stato successivo. È il “modello” di Model Predictive Control. Il solver, simulando questa dinamica passo per passo, sa prevedere dove finirà il sistema per ogni sequenza di azioni che considera.

$x_0 = x_k$ è il punto in cui entra il feedback: la simulazione parte dallo stato misurato ora, non da una previsione. Questo singolo vincolo è ciò che rende l’MPC un controllore in anello chiuso e non una pianificazione cieca.

$x_i \in \mathbb{X}$ e $u_i \in \mathbb{U}$ sono i vincoli su stato e controllo: lo stato deve restare in una regione ammissibile $\mathbb{X}$ (temperatura entro limiti, posizione lontana dagli ostacoli), il controllo dentro $\mathbb{U}$ (una valvola tra 0% e 100%, un motore entro la sua spinta massima). Sono vincoli duri: la soluzione li rispetta sempre.

$x_N \in \mathbb{X}_f$ è il vincolo terminale: forza lo stato alla fine dell’orizzonte dentro una regione “sicura”. Serve alla stabilità, e lo vediamo tra poco.

Nel costo, $\ell(x_i, u_i)$ è lo stage cost (costo di percorso): quanto paghi a ogni passo. La forma tipica è quadratica:

$\ell(x_i, u_i) = x_i^\top Q\, x_i + u_i^\top R\, u_i$

In parole povere: il primo termine penalizza l’errore di stato (quanto sei lontano dall’obiettivo, qui posto nell’origine), il secondo penalizza lo sforzo di controllo (quanto stai spingendo). Le matrici $Q$ e $R$ sono i pesi: alzare $Q$ dice “voglio arrivare all’obiettivo in fretta, costi quel che costi”; alzare $R$ dice “vai pure piano, ma non sprecare energia”. Scegliere $Q$ e $R$ è la prima decisione di progetto.

$V_f(x_N)$ è il terminal cost (costo terminale): approssima il costo di tutto ciò che succede dopo la fine dell’orizzonte. È un surrogato del futuro che non simuliamo esplicitamente. Su questo torniamo nella sezione stabilità: è il pezzo che fa la differenza tra un MPC che funziona e uno che diverge.

Il loop, in pseudocodice

ogni passo di campionamento k:
    x_k = misura_stato()              # feedback: lo stato reale, non predetto

    # risolvi il problema di ottimizzazione a orizzonte N
    u_seq* = argmin   V_f(x_N) + somma_{i=0..N-1} stage_cost(x_i, u_i)
             tale che  x_0 = x_k
                       x_{i+1} = f(x_i, u_i)     # modello del sistema
                       x_i in X,  u_i in U       # vincoli espliciti
                       x_N in X_f                # vincolo terminale

    applica( u_seq*[0] )              # SOLO la prima azione
    # le restanti N-1 azioni vengono scartate

Il punto da non perdere è l’ultima riga di commento: ogni ciclo butta via $N-1$ azioni appena calcolate. Non è inefficienza accidentale, è il cuore del metodo. Il piano calcolato assumeva una certa evoluzione; lo stato vero al passo successivo sarà diverso (per disturbi ed errori di modello); quindi al passo successivo si ripianifica da capo dallo stato vero. Lo scarto è la feature, non il bug: è ciò che trasforma un piano open-loop fragile in un controllo closed-loop robusto.

Detto altrimenti: il piano completo serve a decidere bene la prima azione, non a essere eseguito. È un piano “usa e getta”, calcolato non per il futuro ma per il presente — per dare alla prossima azione il contesto di dove porterebbe. Questa è la chiave per non fraintendere l’MPC: non è un pianificatore che esegue piani, è un decisore che usa la pianificazione come strumento per scegliere una mossa alla volta.

L’orizzonte che scorre, passo dopo passo

Vale la pena seguire l’orizzonte mentre scorre, perché è il movimento che dà il nome al metodo. Diciamo $N = 5$ .

Al passo $k = 0$ , il controllore misura $x_0$ e pianifica le azioni per gli istanti $0, 1, 2, 3, 4$ . Applica solo l’azione per l’istante $0$ . Gli istanti $1$ – $4$ del piano vengono dimenticati.

Al passo $k = 1$ , il controllore misura $x_1$ — che riflette ciò che è successo davvero, disturbi inclusi — e pianifica per gli istanti $1, 2, 3, 4, 5$ . La finestra si è spostata in avanti di uno: ora vede fino all’istante $5$ , che prima non guardava. Applica solo l’azione per l’istante $1$ , e scarta il resto.

Al passo $k = 2$ , la finestra copre $2, 3, 4, 5, 6$ . E così via. La finestra di predizione, sempre lunga $5$ , scivola in avanti di un passo a ogni ciclo, sempre ancorata sul lato sinistro allo stato misurato adesso. Questo scorrimento — la finestra che recede mentre il tempo avanza — è precisamente il “receding horizon”.

QP o NLP: cosa risolve davvero il solver

Che tipo di problema sia dipende dalla forma di $f$ , $\ell$ e dei vincoli.

Se la dinamica $f$ è lineare, lo stage cost e il terminal cost sono quadratici, e i vincoli sono lineari, allora il problema è un Quadratic Program (QP): minimizzare una forma quadratica soggetta a vincoli lineari. È il caso più comune e più maneggevole, perché il QP è convesso — ha un solo minimo, e i solver lo trovano in modo affidabile e veloce. Questa è una proprietà preziosa, che richiama la convessità come garanzia di un unico minimo globale.

La convessità conta più di quanto sembri in un sistema che gira non-stop. Un solver su un problema convesso trova sempre la stessa, unica soluzione, in un tempo prevedibile: non resta intrappolato in minimi locali, non dipende da dove parte. Su un sistema di controllo che deve produrre un comando affidabile a ogni ciclo, questa prevedibilità è quasi importante quanto l’ottimalità. È uno dei motivi per cui, quando possibile, si preferisce formulare il problema in modo che resti un QP convesso, anche a costo di approssimare una dinamica leggermente nonlineare con una lineare.

Se la dinamica è nonlineare, il problema diventa un Nonlinear Program (NLP): più costoso, e senza garanzia di trovare il minimo globale (può fermarsi in un minimo locale). È il nonlinear MPC (NMPC), oggi sempre più praticabile grazie all’hardware moderno, ma con un conto computazionale e teorico più pesante.

Come si regola: i pesi e l’orizzonte

Mettere in piedi un MPC vuol dire scegliere alcune manopole, e ciascuna ha un significato chiaro. Le matrici di peso $Q$ e $R$ bilanciano “arrivare in fretta” contro “non sprecare sforzo”: il loro rapporto è la prima cosa da tarare, ed è leggibile — alza $Q$ e il controllore diventa aggressivo, alza $R$ e diventa cauto. L’orizzonte $N$ decide quanto lontano guarda. Il periodo di campionamento decide ogni quanto ri-ottimizza. E i vincoli $\mathbb{X}$ , $\mathbb{U}$ codificano i limiti fisici e di sicurezza.

Questa leggibilità è uno dei motivi del successo industriale dell’MPC: a differenza di una rete neurale di controllo, le manopole hanno un significato fisico, e un ingegnere può ragionare su cosa cambierà se le muove. Un controllore i cui parametri si capiscono è un controllore di cui ci si può fidare in un impianto dove un errore costa milioni.

Una distinzione utile è tra orizzonte di predizione (quanti passi avanti si simula) e orizzonte di controllo (per quanti passi le azioni sono libere di variare). Spesso il secondo è più corto del primo: dopo i primi passi liberi, si assume che il controllo segua una legge fissa fino alla fine dell’orizzonte di predizione. Questo riduce il numero di variabili decisionali — e quindi il costo del problema — senza accorciare quanto lontano si guarda. È uno dei tanti modi con cui la pratica industriale ha reso l’MPC abbastanza leggero da girare in tempo reale.

Esempi

Tre esempi eterogenei: uno numerico minimale, uno in codice, uno scenario reale.

Esempio numerico: il doppio integratore con un limite

Un carrello su un binario senza attrito. Lo stato è $x = (p, v)$ : posizione e velocità. Il controllo $u$ è l’accelerazione, limitata: $|u| \le 1$ (il motore non spinge oltre). Vogliamo portarlo da $p = 10$ , fermo, all’origine $p = 0$ con velocità nulla, spendendo poca accelerazione. Lo stage cost è $\ell = p^2 + 0{,}1\, u^2$ : pesa molto l’errore di posizione, poco lo sforzo.

Con orizzonte $N = 20$ , a ogni passo l’MPC risolve un QP nelle 20 accelerazioni future. La soluzione tipica: all’inizio spinge al massimo consentito verso l’origine ( $u = -1$ , contro il limite), poi a metà strada inverte e frena ( $u = +1$ , di nuovo al limite) per arrivare fermo. È il classico profilo “bang-bang” tipico dei problemi a controllo limitato: la soluzione vive sul bordo del vincolo, non a metà.

Questo è anche un esempio di come il vincolo $|u| \le 1$ cambi qualitativamente la soluzione. Senza il limite, l’MPC userebbe un’accelerazione iniziale enorme per annullare l’errore in un istante; con il limite, deve distribuire lo sforzo nel tempo, e la forma ottima diventa “spingi al massimo, poi frena al massimo”. Il controllore sa del limite mentre pianifica, e progetta una traiettoria che lo rispetta dall’inizio alla fine — non una che lo viola e va tagliata dopo, come accadrebbe con un PID saturato.

Concretamente, al primo passo il solver guarda i prossimi 20 istanti, vede che il modo più economico di annullare un errore di posizione di 10 è accelerare con forza verso l’origine, e propone una sequenza di 20 accelerazioni. Di queste, applica solo la prima — diciamo $u_0 = -1$ , spinta massima — e scarta le altre 19. Al passo successivo lo stato è cambiato (il carrello si è mosso un po’), il solver rifà i conti su un nuovo orizzonte di 20 istanti che parte da lì, e di nuovo applica solo la prima azione.

Il punto da osservare è cosa succede quando interviene un disturbo. Supponiamo che una piccola spinta esterna abbia frenato il carrello meno del previsto: lo stato misurato non coincide con quello che il modello aveva predetto al passo prima. L’MPC non se ne cura: misura lo stato vero e ri-risolve il QP da lì. La traiettoria pianificata cambia leggermente, ma l’azione applicata resta sensata, perché parte sempre dalla realtà. Un controllo open-loop che avesse pre-calcolato tutte le 20 accelerazioni e le applicasse in sequenza, invece, avrebbe accumulato l’errore del disturbo: ogni istante in più si sarebbe allontanato dalla traiettoria reale, perché eseguiva un piano fatto per un mondo che non c’era più.

Esempio in codice: la struttura di un passo MPC

Lo scheletro di un passo MPC, in pseudo-Python con un solver di ottimizzazione generico:

def mpc_step(x_now, N, f, stage_cost, terminal_cost, X, U, Xf):
    # variabili decisionali: stato e controllo lungo l'orizzonte
    x = [Var(shape=n_state) for _ in range(N + 1)]
    u = [Var(shape=n_ctrl)  for _ in range(N)]

    cost = terminal_cost(x[N])
    constraints = [x[0] == x_now]            # feedback: parto dallo stato vero

    for i in range(N):
        cost += stage_cost(x[i], u[i])
        constraints += [x[i+1] == f(x[i], u[i])]   # dinamica del modello
        constraints += [x[i] in X, u[i] in U]      # vincoli
    constraints += [x[N] in Xf]               # vincolo terminale

    solve(minimize=cost, subject_to=constraints)
    return value(u[0])                        # applico solo la prima azione

# loop di controllo
while True:
    x_now = sensor.read()         # misura reale a ogni ciclo
    u0 = mpc_step(x_now, N, ...)   # ri-ottimizzo da capo
    actuator.apply(u0)
    wait_until_next_sample()

La struttura rivela tutto: il vincolo x[0] == x_now è il feedback, il loop for i costruisce la predizione dal modello, return value(u[0]) è l’esecuzione del solo primo passo, e il while esterno è il receding horizon che ri-ottimizza a ogni campione. Nel caso lineare-quadratico, solve invoca un solver QP; con warm-start si parte dalla soluzione del ciclo precedente, quasi giusta, e si converge in poche iterazioni.

Scenario reale: gestione termica di un edificio

Un sistema HVAC (riscaldamento, ventilazione, condizionamento) deve tenere un edificio a temperatura confortevole minimizzando la bolletta. Qui l’MPC mostra il suo valore pieno. Il modello è la dinamica termica dell’edificio (come la temperatura risponde al riscaldamento e alla temperatura esterna). L’orizzonte è lungo, per esempio 24 ore. Il costo è il prezzo dell’energia, che varia nella giornata. I vincoli sono il comfort (temperatura in una banda accettabile) e i limiti dell’impianto.

L’MPC pianifica su tutte le 24 ore usando le previsioni di prezzo e di meteo: per esempio, pre-riscalda l’edificio quando l’energia costa poco, anticipando le ore in cui costerà di più. Ma applica solo la decisione della prossima ora. Poi le previsioni si aggiornano (meteo reale, prezzo reale), e ri-pianifica. La capacità di anticipare riferimenti futuri noti — i prezzi di domani — è qualcosa che un PID non potrebbe mai fare: il PID reagisce solo all’errore presente, non al futuro previsto.

MPC, PID e LQR a confronto

Conviene fissare il posto dell’MPC rispetto ai due controllori più comuni, perché le differenze sono nette e si ricordano facilmente.

Il PID (PID senza formalismo pesante) calcola il comando da errore presente, integrale dell’errore e sua derivata. Governa una variabile alla volta, non conosce i vincoli (li si aggiunge a posteriori con saturazioni), non usa un modello del sistema, non anticipa. È semplice, robusto, ovunque: copre la grande maggioranza dei loop industriali. Ma su problemi con molte variabili accoppiate e molti vincoli è inadeguato.

L’LQR moltiplica lo stato per una matrice di guadagno fissa, calcolata una volta offline minimizzando un costo quadratico su orizzonte infinito. Usa implicitamente un modello (serve a calcolare il guadagno), è ottimo nel suo caso ideale, gestisce naturalmente sistemi multivariabili. Ma il guadagno è una formula fissa: non gestisce vincoli, non si adatta se il problema cambia.

L’MPC risolve a ogni passo un problema di ottimizzazione su orizzonte finito, con il modello dentro e i vincoli dentro. Usa un modello esplicito, gestisce vincoli su stato e controllo, anticipa il futuro noto, coordina molte variabili. Paga questo con il costo computazionale (un’ottimizzazione per ciclo) e con la dipendenza dalla qualità del modello. È il controllore di riferimento quando i vincoli e l’accoppiamento contano e c’è tempo (o hardware) per ottimizzare.

Vale ricordare che non sempre l’MPC è la scelta giusta: per un loop singolo, senza vincoli stringenti e senza bisogno di anticipare, un PID ben tarato fa il lavoro a una frazione del costo. L’MPC paga quando il problema è abbastanza ricco da giustificare l’ottimizzazione ripetuta. Scegliere il controllore più semplice che risolve il problema è buona ingegneria; l’MPC è l’attrezzo per i problemi che gli attrezzi semplici non reggono.

In una riga: il PID reagisce, l’LQR reagisce in modo ottimo con una formula fissa, l’MPC pianifica e ri-pianifica con vincoli e modello. Salendo si guadagna capacità e si paga in calcolo e in dipendenza dal modello.

Applicazioni pratiche

L’MPC è oggi il metodo di controllo avanzato più diffuso, con quattro grandi famiglie di impiego.

La prima è l’industria di processo, il suo terreno d’origine e tuttora dominante: raffinerie, impianti chimici, colonne di distillazione con decine di variabili accoppiate e vincoli di qualità e sicurezza, operate vicino ai limiti per massimizzare la resa. In una raffineria moderna, un singolo MPC può coordinare decine di ingressi e centinaia di vincoli, tenendo l’impianto in un punto di funzionamento che un operatore umano non riuscirebbe a mantenere a mano. È qui che il valore economico dell’MPC è più tangibile: anche una frazione di punto percentuale di resa in più, su un impianto che lavora ventiquattro ore al giorno, vale moltissimo.

La seconda sono i sistemi veloci moderni, dove l’MPC è arrivato con l’aumento della potenza di calcolo: cruise control predittivo e controllo di trazione nell’automotive, controllo d’assetto di droni e quadrirotori, gestione di convertitori di potenza, traiettorie di robot mobili con collision avoidance.

Quest’ultimo caso merita un dettaglio, perché mostra la potenza dei vincoli espliciti. Un robot che deve raggiungere un punto evitando ostacoli formula il problema così: il costo penalizza la distanza dall’obiettivo, e gli ostacoli diventano vincoli $x_i \in \mathbb{X}$ — la regione ammissibile $\mathbb{X}$ è lo spazio meno gli ostacoli. L’MPC pianifica una traiettoria che, per costruzione, non attraversa nessun ostacolo lungo tutto l’orizzonte, e ri-pianifica man mano che il robot avanza o che gli ostacoli si muovono. Un approccio reattivo (sterza quando l’ostacolo è vicino) fallirebbe in spazi stretti, perché non anticipa; l’MPC vede l’ostacolo dieci passi prima e curva per tempo.

La terza è l’energia: gestione di microgrid e, come nello scenario sopra, di edifici, dove si pianifica su un orizzonte lungo con previsioni e si ri-pianifica man mano che arrivano i dati reali. Qui la capacità di anticipare riferimenti futuri noti è decisiva: si carica una batteria quando l’energia costa poco perché si sa che costerà di più tra qualche ora. È controllo che agisce sul futuro previsto, non solo sul presente misurato.

A queste si aggiunge un quinto territorio in crescita: il model-based RL vero e proprio, dove l’MPC è l’algoritmo di pianificazione su un modello appreso. Metodi che imparano la dinamica dai dati e poi pianificano con essa alla maniera dell’MPC — simulando rollout e scegliendo l’azione — sono diventati un filone importante del reinforcement learning orientato all’efficienza campionaria, perché pianificare su un modello costa meno che provare azioni nel mondo reale.

La quarta — quella che rende questo capitolo pertinente a una wiki sull’AI — è l’AI e gli agenti. Qui l’MPC compare in due forme. Come algoritmo vero e proprio, dentro il model-based reinforcement learning: metodi in cui un agente impara un modello dell’ambiente e poi pianifica con esso esattamente alla maniera dell’MPC, simulando rollout futuri e scegliendo l’azione migliore. E come schema concettuale, lente per leggere il modo in cui un agente che ragiona pianifica e ri-pianifica. È il filo della prossima sezione e del ponte finale.

Il trade-off dell’orizzonte e la stabilità

Due decisioni di progetto governano se un MPC funziona: la lunghezza dell’orizzonte e la scelta del terminal cost. Sono legate.

L’orizzonte: lungo vede meglio, corto costa meno

Un orizzonte lungo ( $N$ grande) lascia al controllore vedere più lontano: anticipa meglio, si avvicina al vero ottimo a orizzonte infinito, tende a essere più stabile. Ma il problema di ottimizzazione ha più variabili decisionali ( $N$ azioni future), quindi è più grande e più costoso da risolvere a ogni ciclo.

Un orizzonte corto ( $N$ piccolo) dà un’ottimizzazione leggera e veloce, ma un controllore miope: può prendere decisioni avide che lo cacciano nei guai più avanti, fuori dalla sua vista. Un orizzonte troppo corto può addirittura rendere il sistema instabile.

Stabilità: ri-ottimizzare non basta

Qui c’è il punto contro-intuitivo. Si potrebbe pensare che, dato che l’MPC ri-ottimizza a ogni passo e parte sempre dallo stato vero, sia automaticamente stabile. Non è così. Un MPC con orizzonte troppo corto e senza un costo terminale adeguato può divergere: a ogni passo prende la decisione localmente migliore, ma l’inseguimento del minimo a corto raggio lo porta lontano dall’obiettivo.

Un’immagine per capire perché. Pensa a un orizzonte cortissimo, un solo passo. Il controllore vede solo il prossimo istante e ottimizza per quello. È come guidare guardando solo il metro davanti al cofano: prendi ogni curva all’ultimo, freni tardi, esci di strada. La miopia non è un difetto di “quanto bene” ottimizzi sul tuo orizzonte — sul tuo orizzonte sei ottimo — è un difetto di cosa vedi. L’ottimo del passo dopo può richiedere di pagare ora qualcosa che il tuo orizzonte non arriva a giustificare, e così non lo paghi, e finisci nei guai. Il terminal cost serve proprio a iniettare nell’orizzonte corto un’informazione su “quanto sarà costoso il futuro che non vedi”, così che il controllore decida come se vedesse lontano pur guardando vicino.

La teoria — il survey di Mayne, Rawlings, Rao e Scokaert del 2000 — identifica gli ingredienti che garantiscono stabilità asintotica (lo stato converge davvero all’obiettivo) e recursive feasibility (se il problema è risolvibile ora, lo è anche al passo dopo, così il controllore non resta mai “senza piano”):

il terminal cost $V_f$ deve essere una Control Lyapunov Function, cioè una funzione-energia che, vicino all’obiettivo, può essere fatta decrescere da un controllore locale noto. È il legame diretto con Lyapunov a intuizione: il terminal cost incarna “il costo dell’energia residua da smaltire dopo l’orizzonte”;
il terminal constraint $x_N \in \mathbb{X}_f$ forza lo stato finale predetto dentro una regione attorno all’equilibrio in cui quel controllore locale sa stabilizzare.

L’idea della dimostrazione, in una riga: il valore ottimo del problema, visto come funzione dello stato, decresce a ogni passo, e quindi è una funzione di Lyapunov per il sistema in anello chiuso — perciò lo stato converge. Questa è una relazione dimostrabile, un teorema, sotto ipotesi precise: non una promessa empirica.

La recursive feasibility merita una parola in più, perché è un requisito facile da trascurare. Non basta che il problema sia risolvibile adesso: serve che, dopo aver applicato la prima azione e essere passati al nuovo stato, il problema sia risolvibile ancora. Se al passo dopo non esistesse alcun piano ammissibile, l’MPC resterebbe senza comando — un disastro su un sistema in funzione. Il terminal constraint $\mathbb{X}_f$ , scelto come un insieme invariante (una volta dentro, un controllore locale ti ci mantiene), garantisce questa proprietà a catena: se riesci a raggiungere $\mathbb{X}_f$ ora, riesci a restarci, e quindi avrai sempre un piano valido. È l’ingrediente che trasforma la stabilità da “vale in questo istante” a “vale per sempre”.

Il terminal cost ha anche un risvolto pratico bellissimo: un $V_f$ ben scelto, che approssima fedelmente il costo del futuro oltre l’orizzonte, permette di usare un orizzonte corto mantenendo il comportamento di uno lungo. È il trucco che rende l’MPC praticabile: invece di un orizzonte enorme e costoso, un orizzonte corto più un terminal cost intelligente.

Costo computazionale: dal processo lento ai millisecondi

L’MPC paga un prezzo che PID e LQR non pagano: risolve un’ottimizzazione per ogni campione. Questo spiega la sua storia.

Nell’industria di processo degli anni Settanta e Ottanta il calcolo non era un ostacolo: i sistemi sono lenti, con costanti di tempo di minuti o ore, quindi tra un campione e il successivo c’era tutto il tempo di risolvere l’ottimizzazione anche con i computer dell’epoca. Non è un caso che l’MPC sia nato lì: era l’unico ambiente in cui il costo computazionale era trascurabile rispetto alla dinamica del sistema.

Questo spiega anche perché l’MPC sia rimasto a lungo confinato in quel mondo. Per controllare un motore elettrico o un drone — sistemi con dinamiche di millisecondi — risolvere un’ottimizzazione completa a ogni ciclo sembrava impensabile con l’hardware di allora. La storia dell’MPC negli ultimi vent’anni è in buona parte la storia di come si è abbattuto quel muro: hardware più veloce, sì, ma soprattutto algoritmi che sfruttano la struttura del problema per risolverlo in una frazione del tempo.

Portarlo su sistemi veloci — un drone che si stabilizza in millisecondi — ha richiesto tre famiglie di trucchi.

Il primo sono i solver QP dedicati, scritti per sfruttare la struttura ripetitiva del problema MPC (la stessa dinamica a ogni passo dell’orizzonte) e per girare su hardware embedded con memoria e calcolo limitati.

Il secondo è il warm-starting: la soluzione di un ciclo è quasi identica a quella del ciclo precedente, perché lo stato è cambiato di poco. Invece di partire da zero, il solver parte dalla soluzione di prima — già quasi giusta — e converge in poche iterazioni. È un risparmio enorme proprio perché l’MPC risolve una sequenza di problemi quasi uguali. La soluzione di prima, traslata di un passo (l’orizzonte è scorso in avanti), è una candidata eccellente per ripartire: spesso bastano una o due iterazioni del solver per raffinarla.

Il terzo è l’explicit MPC (Bemporad e colleghi, 2002). Per problemi lineari, l’intera legge di controllo — la mappa che a ogni stato associa il controllo ottimo — si può calcolare offline, una volta sola, e risulta essere una funzione affine a tratti dello stato: lo spazio degli stati si divide in regioni poliedrali, e in ciascuna il controllo ottimo è una semplice funzione lineare. A runtime non si risolve nessuna ottimizzazione: si trova in quale regione cade lo stato e si valuta la funzione lineare corrispondente, in microsecondi. Il prezzo è la memoria: il numero di regioni esplode con la dimensione del problema, quindi l’explicit MPC è praticabile solo per sistemi piccoli.

Con questi strumenti, e con l’hardware moderno, l’MPC ha smesso di essere il metodo dei soli sistemi lenti ed è entrato in automotive, robotica e power electronics. Lo stesso schema concettuale, sul piano computazionale, si è spostato di parecchi ordini di grandezza in velocità: dai minuti tra un campione e l’altro di una raffineria ai microsecondi di un convertitore di potenza.

Il ponte verso l’AI e gli agenti

Qui si capisce perché un capitolo di teoria del controllo abita in una wiki sull’intelligenza artificiale. Lo schema dell’MPC ricompare, sotto altri nomi, nel modo in cui gli agenti ragionano e pianificano. Ma ricompare con classi di legame diverse, e tenerle distinte è essenziale: si va dall’identità di schema (model-based RL) all’analogia di schema (agenti LLM, ReAct), passando per casi intermedi (MCTS). Confondere questi gradi è l’errore più comune quando si parla di “AI come controllo”, e questa sezione è costruita apposta per non commetterlo.

Il filo conduttore è uno solo: ogni volta che un sistema deve decidere ripetutamente, in un mondo incerto, guardando un po’ avanti senza poter vedere tutto, lo schema receding horizon è la risposta naturale. Cambia la macchina che lo implementa — un solver QP, una ricerca ad albero, un modello linguistico — ma la coreografia è la stessa.

Analogia di schema: l’agente che pianifica fa receding horizon

Un agente che affronta un compito complesso tende a fare cinque cose, in loop: osserva lo stato corrente; pianifica una sequenza di azioni verso l’obiettivo, su un orizzonte finito (non può pianificare all’infinito); esegue il primo passo; osserva il risultato reale, che può divergere dal previsto; ri-pianifica da capo con lo stato aggiornato.

Il loop “plan-act-observe-replan” di un agente è, come schema, lo stesso “ottimizza-applica-misura-ri-ottimizza” dell’MPC. La stessa scelta di guardare avanti di un tratto finito, la stessa scelta di eseguire solo il primo passo e buttare il resto, la stessa ri-pianificazione sull’osservazione reale come modo di assorbire l’incertezza.

Va detto con precisione la classe di questo legame: è un’analogia forte, non un’equivalenza. La struttura del controllo coincide; il meccanismo no. Un agente che ragiona su un compito non risolve un Quadratic Program, non ha un modello esplicito della dinamica, non ottimizza un costo ben definito, e non ha le garanzie di stabilità e recursive feasibility che la teoria dell’MPC dimostra. La somiglianza è di schema — e proprio per questo è illuminante: spiega perché il loop plan-act-observe-replan di un agente è robusto, per la stessa ragione per cui lo è l’MPC, cioè perché ri-pianifica sull’osservazione invece di eseguire un piano vecchio. Ma non bisogna scivolare dall’analogia di schema all’identità di meccanismo.

L’analogia è utile anche al contrario: i fallimenti dell’MPC predicono i fallimenti dell’agente. Un MPC con un modello sbagliato pianifica benissimo su un mondo che non esiste — e un agente con un modello mentale sbagliato del codebase fa lo stesso, producendo piani interni coerenti e inattuabili. Un MPC con orizzonte troppo corto è miope e instabile — e un agente che pianifica troppo poco avanti prende decisioni avide che lo cacciano nei guai. Un MPC che ri-pianifica troppo spesso può oscillare — e un agente che ri-considera il piano a ogni minimo segnale può entrare in un loop indeciso, cambiando rotta di continuo senza concludere. Lo schema condiviso porta con sé un catalogo condiviso di modi di rompersi.

Filiazione reale: model-based RL e la parentela con MCTS

C’è invece un legame più stretto, e qui la classe cambia. In model-based reinforcement learning, un agente usa un modello (spesso appreso dai dati) dell’ambiente per simulare traiettorie future, valutarle, scegliere l’azione, eseguirla e poi ri-pianificare. Questo è, letteralmente, MPC con un modello appreso al posto di un modello scritto a mano: “modello + lookahead + agisci” è lo stesso schema. Tra MPC e model-based RL c’è una parentela strutturale forte, non una semplice somiglianza didattica.

La differenza con l’MPC classico sta solo in dove viene il modello. Nell’MPC industriale il modello $f$ è derivato dalla fisica o identificato da esperimenti mirati; nel model-based RL il modello è appreso interagendo con l’ambiente, e migliora man mano che l’agente raccoglie dati. Ma una volta che hai un modello, il modo di usarlo per decidere — simula avanti, ottimizza, applica il primo passo, ripeti — è identico. È per questo che il confine tra “controllo” e “RL” è più sfumato di quanto i nomi suggeriscano, un punto che il ponte controllo-vs-rl (in preparazione) di questa Parte affronta di petto.

Il Monte Carlo Tree Search — il metodo di pianificazione dietro AlphaGo, il programma di DeepMind che nel 2016 batté un campione di Go esplorando un albero di mosse future simulandone gli esiti — condivide lo schema. MCTS simula traiettorie su un orizzonte finito, ne stima il valore, sceglie la prima mossa, e dopo la mossa dell’avversario ri-pianifica da capo dalla nuova posizione sulla scacchiera. È la stessa coreografia dell’MPC: guarda avanti su un orizzonte, scegli e applica solo la prossima azione, poi ricomincia dallo stato aggiornato. La differenza sta nello strumento: MCTS esplora un albero discreto di possibilità con simulazioni casuali guidate, l’MPC risolve un programma di ottimizzazione continuo. Lo schema è lo stesso, la macchina sotto è diversa.

Marca con cura le classi: tra MPC e model-based RL c’è filiazione/identità di schema (entrambi sono “modello + lookahead + agisci”, e il secondo è letteralmente il primo con modello appreso); tra MPC e MCTS c’è analogia di schema (lo strumento di ricerca differisce, la struttura “guarda-avanti, agisci, ri-pianifica” coincide). Questo filo si annoda con la value function di Bellman: il terminal cost dell’MPC è un’approssimazione della value function, ed è il punto matematico esatto dove controllo ottimo, MPC e reinforcement learning si toccano. Chi conosce il terminal cost dell’MPC e la value function del RL sta guardando lo stesso oggetto da due tradizioni che, per decenni, non si parlavano.

Test-time planning e LLM che ri-pianificano

I modelli linguistici che “pianificano” un compito, eseguono un passo, osservano l’esito e ri-pianificano stanno facendo, a livello di schema, receding horizon control applicato al linguaggio. Esiste un filone recente che rende questo legame esplicito. Il paper LLMPC: Large Language Model Predictive Control (Maher, arXiv 2025) inquadra il modello come ottimizzatore approssimato di una funzione di costo di pianificazione: invece di accettare il singolo piano che il modello produce, ne campiona molti candidati, ne simula gli effetti, sceglie il migliore secondo un costo esplicito, esegue il primo pezzo e ri-pianifica con lo stato aggiornato — lo schema MPC, parola per parola. Gli autori riportano che rendere esplicita questa ottimizzazione migliora i risultati: su compiti di pianificazione, passare da un singolo tentativo al campionamento multiplo con selezione e ri-pianificazione iterativa aumenta sensibilmente il tasso di successo.

Il senso di questo accostamento non è dire “un LLM è un controllore”. È dire che lo schema receding horizon — guarda avanti un po’, impegnati solo sul primo passo, osserva, ricomincia — è una ricetta generale per agire bene sotto incertezza, e che riemerge ovunque qualcuno debba decidere ripetutamente in un mondo che non conosce alla perfezione. Lo si è scoperto nelle raffinerie negli anni Settanta; lo si ritrova nel modo in cui un agente affronta un task oggi.

Un agente di coding letto come receding horizon

Concretizziamo con uno scenario familiare a chi usa un agente di coding. Il task è “aggiungi una feature a un repository”. Un agente ben costruito non scrive tutto il piano e lo esegue alla cieca. Osserva lo stato (i file, i test, l’errore corrente), pianifica i prossimi passi (modifica questo file, lancia i test, leggi l’output), esegue il primo (una modifica), osserva il risultato reale (i test passano? l’errore è quello previsto?), e ri-pianifica i passi successivi alla luce di ciò che ha visto.

Se mappiamo i termini: lo “stato” è la condizione del repository e dei test; il “modello” è il modello mentale che l’agente ha di come il codice risponderà alle sue modifiche; l‘“orizzonte” è quanti passi avanti pianifica prima di agire; il “costo” è quanto è lontano dal task completato. Eseguire solo il primo passo e poi ri-osservare è ciò che rende l’agente robusto al fatto che il suo modello del codebase è imperfetto: una modifica che pensava innocua rompe un test, lo scopre subito, e ri-pianifica — invece di proseguire un piano di dieci passi costruito su un’ipotesi sbagliata.

La classe di questo legame resta analogia di schema. L’agente non risolve un’ottimizzazione formale, non ha un modello esplicito né garanzie di convergenza. Ma la lente dell’MPC dice qualcosa di concreto su come progettare l’agente: dagli un orizzonte abbastanza lungo da non essere miope, fagli osservare la realtà dopo ogni passo invece di fidarsi del piano, e non fargli ri-pianificare così spesso da diventare indeciso. Sono le stesse tre manopole che un ingegnere del controllo regola da cinquant’anni.

Il valore di questa lettura non è etichettare l’agente come “un MPC”, ma ereditare cinquant’anni di esperienza su cosa rende robusto uno schema decisionale ripetuto sotto incertezza. La teoria del controllo non ci dà i teoremi pronti per gli agenti — quelli mancano, perché un LLM non è un sistema dinamico ben definito — ma ci dà le domande giuste da porre, e una tassonomia di modi di rompersi che vale la pena tenere d’occhio. È il senso di studiare il controllo in una wiki sull’AI: non per importare formule, ma per importare il modo di pensare.

[DATATO 2026-05] Questo filone (LLMPC e affini, 2025) è recente e in evoluzione. Gli autori argomentano un legame che sta tra l’analogia e l’equivalenza; non è un risultato consolidato del campo. Va letto come framing promettente, non come fatto stabilito.

Ri-pianificare come gestione dell’incertezza, e ReAct

Il motivo profondo per cui sia l’MPC sia un agente ri-pianificano è lo stesso: il futuro è incerto e il modello è imperfetto. Pianificare tutto una volta sola è fragile; ri-pianificare a ogni osservazione è il modo strutturale di assorbire la deviazione tra previsto e reale. È il principio del feedback negativo applicato non a un singolo comando ma a un intero piano.

Vale la pena notare la simmetria con la cibernetica. Il feedback semplice corregge un comando in base all’errore osservato; il receding horizon corregge un intero piano in base allo stato osservato. È il feedback elevato di un livello: non più “quanto sono lontano e di quanto correggo”, ma “dato dove sono davvero, qual è il piano migliore da qui in avanti”. L’MPC è, in questo senso, ciò che diventa il feedback quando il sistema è abbastanza complesso da richiedere una pianificazione e non solo una correzione. Lo stesso salto avviene quando un agente passa dal reagire a un singolo messaggio al pianificare e ri-pianificare una sequenza di azioni.

Il pattern ReAct (Reason + Act: ragiona, agisci, osserva, ripeti) è leggibile come un loop predittivo-correttivo nello stesso senso: il “reason” è una micro-pianificazione, l‘“act” applica il primo passo, l‘“observe” fornisce il feedback che corregge la pianificazione successiva. Anche qui la classe è analogia di schema, non identità: ReAct non ottimizza un costo esplicito né ha un orizzonte formalizzato. La somiglianza vive nello schema feedback-correttivo, non nella matematica. Lo sviluppano i capitoli react (in preparazione) e plan-execute (in preparazione) della Parte sugli agenti, e il ponte controllo-vs-rl (in preparazione) di questa Parte.

C’è una sfumatura che il parallelo con l’MPC chiarisce, e che la ricerca sugli agenti ha riscoperto sul campo. Ri-pianificare a ogni passo non è gratis: costa calcolo, e può rendere il comportamento instabile se ogni piccola osservazione fa cambiare idea. Nell’MPC questo si gestisce con il periodo di campionamento (non si ri-ottimizza più spesso del necessario) e con una formulazione che premia la coerenza. Negli agenti emerge lo stesso compromesso: pianificare quando serve invece che a ogni mossa, perché ri-pianificare in continuazione produce fragilità e indecisione tanto quanto non pianificare affatto. È un caso in cui guardare un sistema di controllo maturo suggerisce cosa aspettarsi — e cosa evitare — in un sistema agentico giovane. La classe resta analogia: la lezione si trasferisce come intuizione di progetto, non come teorema importato.

Dove si rompe

L’MPC è potente, ma ha limiti e fraintendimenti ricorrenti. Vale la pena elencarli, perché distinguono chi capisce lo schema da chi lo ripete.

Dipende dalla qualità del modello. L’intero metodo predice il futuro con $f$ . Se il modello è grossolanamente sbagliato, le predizioni sono sbagliate, e l’ottimizzazione produce piani impeccabilmente ottimi su un mondo che non esiste. È il limite più importante e più sottovalutato: l’MPC è preciso quanto il suo modello, non di più. Il feedback della ri-ottimizzazione mitiga gli errori piccoli, perché ogni ciclo riparte dalla realtà misurata, ma non salva da un modello fondamentalmente errato — riparti dalla realtà, ma poi predici di nuovo male. Esistono varianti — robust MPC, tube MPC, stochastic MPC — pensate per tollerare incertezza di modello esplicita, pianificando per il caso peggiore o tenendo conto della distribuzione dei disturbi; sono oltre lo scopo di questo capitolo, ma vale sapere che il problema è noto e affrontato a fondo.

Costa, e il costo è ricorrente. Risolvere un’ottimizzazione a ogni campione è incomparabilmente più pesante di valutare una formula. Su sistemi molto veloci o molto grandi, può semplicemente non esserci tempo per convergere entro il ciclo. Da qui warm-start, explicit MPC, e MPC sub-ottimo (ci si accontenta di una soluzione approssimata trovata entro il tempo disponibile).

La feasibility può perdersi. Se i vincoli sono troppo stretti o un disturbo grande spinge lo stato in una regione da cui nessun piano ammissibile esiste, il problema diventa infeasible: il solver non trova soluzione, e il controllore resta senza comando. La pratica usa vincoli “morbidi” (soft constraints, violabili a caro prezzo) per evitare di restare bloccati.

L’ottimizzazione può fallire entro il tempo. Su un sistema veloce, il solver ha una finestra rigida — il periodo di campionamento — per trovare la soluzione. Se non converge in tempo (un NLP nonlineare difficile, un problema mal condizionato), il controllore deve avere un piano B: applicare la soluzione del ciclo precedente, ricadere su un controllore semplice di backup, o accettare una soluzione sub-ottima. Un MPC che “a volte impiega troppo” è inaccettabile in un drone in volo.

Lo stato deve essere noto. L’MPC parte da $x_0 = x_k$ , lo stato misurato. Ma in molti sistemi reali lo stato non si misura direttamente: si osservano solo uscite rumorose e parziali. Serve allora stimare lo stato da quelle misure, ed è esattamente il compito del filtro di Kalman — il capitolo successivo di questa Parte. MPC ed estimatore di stato lavorano in tandem: l’uno decide l’azione, l’altro ricostruisce il punto di partenza. Se la stima dello stato è cattiva, l’MPC pianifica perfettamente a partire da un punto sbagliato — un altro modo in cui un ingrediente esterno può minare un controllore per il resto corretto.

La taratura conta. Le matrici $Q$ e $R$ , l’orizzonte, il periodo di campionamento: scelte male, producono un controllore lento, nervoso o instabile pur essendo “MPC” in piena regola. Lo schema garantisce la struttura, non la qualità: quella resta lavoro di ingegneria. È una delle ragioni per cui mettere in produzione un MPC richiede competenza, e per cui la sua leggibilità — manopole con significato fisico — è un vantaggio così apprezzato rispetto a controllori opachi.

Restano poi i fraintendimenti tipici, da correggere esplicitamente.

“L’MPC è solo controllo ottimo.” No. È controllo ottimo ripetuto a orizzonte finito con feedback. Il controllo ottimo classico calcola la traiettoria una volta su tutto l’orizzonte (open-loop); l’MPC la ricalcola a ogni passo dallo stato misurato (closed-loop). La ri-ottimizzazione continua è ciò che lo rende robusto, ed è proprio ciò che il controllo ottimo “puro” non fa.

“Ri-ottimizzare garantisce la stabilità.” No, come visto: senza terminal cost e terminal constraint adeguati, un MPC a orizzonte corto può divergere. La stabilità è un teorema con ipotesi, non una conseguenza automatica del ri-ottimizzare.

“Si applica tutta la sequenza ottima.” No: si applica solo la prima azione, e si butta il resto. Applicare l’intera sequenza sarebbe controllo open-loop, miope ai disturbi — esattamente ciò che l’MPC evita.

“Orizzonte più lungo è sempre meglio.” Migliore in qualità e stabilità, ma più costoso; e un buon terminal cost ottiene buon comportamento con orizzonte corto. La risposta giusta non è “lungo”, è “abbastanza lungo, con un buon costo terminale”.

“Un agente LLM che pianifica e ri-pianifica è un MPC.” È un’analogia di schema, non un’identità. L’agente non risolve un problema di ottimo ben definito, non ha un modello esplicito né garanzie. Confondere l’analogia con l’equivalenza è l’errore tipico di questo ponte, e va evitato con cura.

Collegamenti

Optimal control: costo, dinamica, vincoli — l’MPC è controllo ottimo ripetuto a orizzonte finito con feedback; il prerequisito diretto, da cui eredita costo, dinamica e vincoli.
Controllare un sistema: plant, controller, sensore, attuatore — il vocabolario di base (plant, stato, setpoint, anello chiuso) su cui poggia tutto il capitolo.
Robustezza a rumore, incertezza e disturbi — l’MPC ricava robustezza dal feedback della ri-ottimizzazione; le varianti robust/tube MPC affrontano l’incertezza di modello esplicita.
Lyapunov a intuizione: energia che scende — il terminal cost è una Control Lyapunov Function, e il valore ottimo del problema è la funzione di Lyapunov che dimostra la stabilità in anello chiuso.
Feedback negativo, positivo, errore, setpoint — l’MPC è un anello di feedback in cui il “calcolo del comando” non è una formula ma un’intera ottimizzazione risolta a ogni ciclo.
MCTS: intuizione, UCB1-tree, ricadute in reasoning LLM — pianificazione a orizzonte finito con esegui-il-primo-passo-e-ri-pianifica; stesso schema dell’MPC, strumento di ricerca diverso.
Bellman e programmazione dinamica — la value function è il punto matematico dove controllo ottimo, MPC e reinforcement learning si toccano.
kalman-filter-intuizione (in preparazione) — l’MPC parte dallo stato misurato; quando lo stato non è osservabile direttamente, serve un estimatore, e i due lavorano in tandem.
controllo-vs-rl (in preparazione) — il ponte esplicito tra controllo classico e RL, dove MPC e model-based RL si rivelano lo stesso schema.
ponte-control-agenti (in preparazione) — l’agent loop letto come problema di controllo parziale, con il receding horizon come schema sottostante.
react (in preparazione) — il pattern ragiona-agisci-osserva come loop predittivo-correttivo, analogia di schema con l’MPC.

Per andare oltre

D.Q. Mayne, J.B. Rawlings, C.V. Rao, P.O.M. Scokaert, Constrained model predictive control: Stability and optimality, Automatica 36(6), 2000 — il survey canonico sulle condizioni di stabilità (terminal cost, terminal constraint, recursive feasibility).
J. Richalet, A. Rault, J.L. Testud, J. Papon, Model predictive heuristic control: Applications to industrial processes, Automatica 14(5), 1978 — una delle origini industriali dell’MPC nel petrolchimico.
J.B. Rawlings, D.Q. Mayne, M.M. Diehl, Model Predictive Control: Theory, Computation, and Design, 2ª ed., Nob Hill Publishing — il testo di riferimento moderno (formulazione, stabilità, calcolo).
A. Bemporad, M. Morari, V. Dua, E.N. Pistikopoulos, The explicit linear quadratic regulator for constrained systems, Automatica 38(1), 2002 — l’explicit MPC che porta il metodo sui sistemi veloci.
G. Maher, LLMPC: Large Language Model Predictive Control, arXiv:2501.02486, 2025 — il framing recente che applica esplicitamente lo schema MPC al planning di agenti LLM.