Feedback vs feedforward: correggere l'errore o anticipare il disturbo

Due modi opposti di tenere un sistema sul bersaglio: misurare lo scarto e reagire, oppure prevedere il disturbo e agire prima. Questo capitolo li separa con precisione, mostra perché si combinano sempre, e spiega perché lo stesso vocabolario governa un termostato, un anello di training e un agente che scrive codice.

Perché questo capitolo

Il 2 agosto 1927 un ingegnere ventottenne dei Bell Laboratories attraversa l’Hudson in traghetto, da Staten Island a Manhattan. Si chiama Harold Black. Sta pensando a un problema che la compagnia telefonica considera grave: gli amplificatori che rilanciano il segnale sulle linee a lunga distanza distorcono la voce e cambiano comportamento col tempo. Non ha carta. Prende l’unica cosa scrivibile che ha in tasca — una pagina del New York Times di quel giorno — e ci schizza sopra uno schema, lo firma, lo data. L’idea è controintuitiva fino al paradosso: prendere parte del segnale che esce dall’amplificatore, invertirlo, e re-iniettarlo all’ingresso. Buttare via guadagno di proposito. In cambio, l’amplificatore diventa quasi perfettamente fedele e stabile.

Quel gesto — far tornare l’uscita all’ingresso, con il segno giusto — è il feedback, la retroazione. È uno dei pochi schemi che ricompaiono identici in domini lontanissimi: la macchina a vapore, il corpo umano che regola la temperatura, un missile che insegue un bersaglio, una rete neurale che impara, un agente che scrive codice e rilegge l’errore del compilatore. Ovunque un sistema debba restare su un obiettivo nonostante un mondo che non collabora, la retroazione è una delle due risposte fondamentali.

Vale la pena fermarsi un istante su quanto sia inusuale uno schema così. La maggior parte dei concetti tecnici è legata a un dominio: una nozione di chimica resta in chimica, una di teoria dei grafi resta nei grafi. Il feedback no: è una forma, non un contenuto, e per questo attraversa l’ingegneria, la biologia, l’economia, le scienze cognitive e l’informatica con lo stesso identico significato strutturale. Imparare a riconoscerlo è imparare a vedere una cosa sola in posti dove sembrano esserci problemi diversi. Questo è anche il motivo per cui un capitolo di teoria dei sistemi, e non un capitolo di ingegneria del controllo, è il posto giusto per introdurlo.

L’altra risposta è il suo opposto temporale. Invece di aspettare che lo scarto si manifesti per poi correggerlo, si può prevedere il disturbo e agire prima che faccia danno. È il feedforward, il controllo anticipatorio. Un guidatore esperto fa entrambe le cose senza pensarci: corregge la traiettoria quando sente l’auto scartare (feedback), e dà un filo di volante in anticipo quando vede arrivare la raffica di vento (feedforward).

Le due risposte hanno un rapporto preciso con il tempo, ed è la prima cosa da fissare. Il feedback guarda al passato prossimo: misura un errore che è già accaduto e reagisce. Il feedforward guarda al futuro prossimo: stima un disturbo che non ha ancora fatto effetto e previene. Detta così sembra che il feedforward sia in vantaggio — chi previene di solito vince su chi rincorre. Ma il feedforward paga la sua anticipazione con una dipendenza pesante da un modello, e dove il modello è assente o sbagliato il feedforward non è semplicemente disponibile. Tutto il capitolo gira attorno a questo scambio.

Questo capitolo conta per chi costruisce sistemi AI per un motivo concreto e uno terminologico. Il motivo concreto: il loop di un agente moderno — osserva, ragiona, agisci, ri-osserva — è, strutturalmente, un anello di feedback. I modi in cui un anello di feedback si rompe (oscilla, diverge, si auto-rinforza) sono esattamente i modi in cui un agente si rompe, e avere il vocabolario giusto cambia la diagnosi. Il motivo terminologico: la parola “feed-forward” compare dentro ogni transformer, nella “feed-forward network”, con un significato che non ha nulla a che vedere con il controllo anticipatorio. È un’omonimia che confonde, e questo capitolo la disinnesca esplicitamente.

C’è una ragione più generale, che riguarda il modo di ragionare sui sistemi. Quando un sistema con un obiettivo si comporta male, ci sono due famiglie di spiegazioni. Una guarda i componenti: “il modello ha sbagliato”, “il tool ha restituito un errore”, “il sensore era starato”. L’altra guarda la struttura del loop: “la correzione arriva troppo tardi”, “il guadagno è troppo alto”, “questo anello si auto-rinforza”. Le due famiglie portano a interventi diversi. La prima fa cambiare un pezzo; la seconda fa ridisegnare il modo in cui i pezzi sono collegati. Molti malfunzionamenti che sembrano colpa di un componente sono in realtà colpa del disegno del loop — e si riconoscono solo se si ha il vocabolario di feedback, guadagno e ritardo. Imparare quel vocabolario qui, sul caso più pulito (un termostato, un regolatore meccanico), è il modo per saperlo applicare poi al caso più sporco (un agente che scrive codice).

Contesto

Per situare feedback e feedforward nel grafo della wiki, conviene partire da dove ci troviamo. I capitoli precedenti della Parte IX hanno costruito il vocabolario statico e dinamico del sistema: cosa è un sistema e dove passa il suo confine, cosa significa che è aperto o chiuso, come si descrive il suo stato e la sua traiettoria, cosa è un equilibrio e quando è stabile, e cosa si può misurare e governare. Feedback e feedforward sono il passo successivo: non descrivono com’è un sistema, ma come lo si tiene su un obiettivo. Sono strategie di regolazione.

La retroazione, come dispositivo, è antica. Il regolatore a galleggiante che mantiene costante il livello dell’acqua è di epoca ellenistica: lo stesso principio dello sciacquone moderno, dove un galleggiante chiude la valvola di carico quando l’acqua raggiunge il livello giusto. Per millenni questi dispositivi sono esistiti come trucchi pratici, costruiti da artigiani che ne capivano il funzionamento ma non avevano un linguaggio per descriverlo come istanze di un unico schema. Ma il caso che ha fatto storia è il governor di Watt. James Watt (ingegnere scozzese, 1736-1819) non inventò il regolatore centrifugo a sfere, però intorno al 1788 lo applicò alla macchina a vapore. Il meccanismo: due sfere metalliche ruotano, trascinate dall’albero del motore; se il motore accelera, la forza centrifuga le solleva; il loro sollevamento, tramite un sistema di leve, chiude parzialmente la valvola del vapore; meno vapore significa meno spinta, e il motore rallenta. L’uscita del sistema — la velocità — regola il proprio ingresso — il vapore. Per quasi un secolo questo congegno funzionò senza che nessuno avesse una teoria di perché funzionasse, e soprattutto di perché a volte non funzionasse: certi regolatori, invece di stabilizzare il motore, lo facevano oscillare sempre più forte.

Figura in preparazione

fig-1: il governor centrifugo di Watt; due sfere su bracci articolati che ruotano attorno a un albero verticale collegato al motore a vapore; frecce che mostrano il circolo: motore accelera, sfere salgono, valvola si chiude, vapore diminuisce, motore rallenta; etichetta “feedback negativo: l’uscita regola il proprio ingresso”

Quel comportamento — un regolatore che doveva calmare il motore e invece lo faceva sobbalzare — era un mistero pratico vero. Verso metà Ottocento, con i motori a vapore che diventavano più grandi e più veloci, l’instabilità dei regolatori era un problema ingegneristico sentito: alcune installazioni “andavano in caccia” (hunting, nel gergo dell’epoca), oscillando attorno alla velocità voluta senza assestarsi. Nessuno aveva una teoria per prevedere quali regolatori sarebbero stati stabili e quali no.

Il vuoto era doppio: mancava un modo per prevedere la stabilità di un regolatore prima di costruirlo, e mancava perfino un modo di parlarne in termini generali, separando ciò che era essenziale al fenomeno da ciò che era dettaglio meccanico del singolo dispositivo. Era il tipico stato di un campo prima che arrivi la sua teoria: pratica abbondante, linguaggio assente.

La teoria arrivò nel 1868 con James Clerk Maxwell (fisico e matematico scozzese, 1831-1879, lo stesso delle equazioni dell’elettromagnetismo). Il suo articolo “On Governors”, pubblicato nei Proceedings of the Royal Society of London, è il primo trattamento matematico serio di un sistema a retroazione. La mossa di Maxwell: scrivere le equazioni del moto del regolatore, linearizzarle attorno alla velocità di equilibrio (cioè approssimarle con equazioni lineari valide per piccole deviazioni) e ridurre la domanda “il regolatore è stabile?” a una domanda puramente algebrica sulle radici di un certo polinomio. Era nata l’analisi di stabilità. Maxwell, nello stesso lavoro, distingue due tipi di dispositivo: i “moderatori”, in cui la coppia correttiva è proporzionale all’errore di velocità, e i “governori” veri, che aggiungono anche un termine proporzionale all’integrale dell’errore — cioè all’errore accumulato nel tempo. È, con cinquant’anni di anticipo, la distinzione tra l’azione proporzionale e l’azione integrale che diventeranno la P e la I del controllore PID. Il paper rimase a lungo poco letto perché considerato ostico; fu Norbert Wiener, nel 1948, a riportarlo alla luce, ed è per quel lavoro che Maxwell viene oggi chiamato il padre della teoria del controllo.

Il filo si riannoda con Black. La retroazione negativa — quella che si oppone alla deviazione — diventa, nel 1927, uno strumento ingegneristico deliberato e non solo un fenomeno meccanico osservato. Vale la pena capire perché l’idea di Black sembrava paradossale ai suoi colleghi. Un amplificatore serve ad amplificare: buttare via guadagno, di proposito, re-iniettando una frazione invertita dell’uscita all’ingresso, sembrava autolesionismo. Il guadagno effettivo dell’amplificatore crollava. Ma in cambio succedeva una cosa preziosa: il comportamento dell’amplificatore smetteva di dipendere dalle valvole — componenti imprecisi, che invecchiavano e derivavano — e cominciava a dipendere quasi solo dalla rete di feedback, fatta di resistori e condensatori, componenti passivi stabili e fabbricabili con precisione. Si barattava guadagno (di cui si poteva fare scorta a buon mercato aggiungendo stadi) contro fedeltà e stabilità (che non si potevano comprare in nessun altro modo). Era un baratto vantaggioso, e divenne il modo standard di costruire amplificatori. Black depositò il brevetto US 2,102,671, “Wave Translation System”, che gli fu concesso nel 1937; la sua retroazione negativa è alla base degli amplificatori operazionali e di gran parte dell’elettronica analogica del Novecento.

L’ultimo tassello del contesto è la sintesi concettuale. Nel 1948 Norbert Wiener (matematico statunitense, 1894-1964) pubblica Cybernetics: Or Control and Communication in the Animal and the Machine (MIT Press, 1948). Wiener conia il termine “cibernetica” dal greco kybernetes, “timoniere” — perché il timone di una nave, con il timoniere che corregge la rotta osservando la deriva, è uno dei feedback più antichi e raffinati. La tesi di Wiener è che il feedback informativo è ciò che dà a una macchina un comportamento teleologico, cioè orientato a uno scopo, senza che nessuno la guidi istante per istante. Una macchina con retroazione “sembra” voler raggiungere un bersaglio.

Questa idea — che lo scopo possa emergere da un meccanismo — sfidava il behaviorismo dell’epoca, per cui la finalità era un concetto troppo metafisico per la scienza. Wiener radicava la tesi in un lavoro precedente, il paper “Behavior, Purpose and Teleology” (1943), scritto con il fisiologo Arturo Rosenblueth e l’ingegnere Julian Bigelow, dove i tre sostenevano che un comportamento “intenzionale” si potesse definire operativamente proprio come comportamento guidato da feedback negativo verso un bersaglio. La mossa intellettuale è notevole: invece di chiedersi se una macchina possa “davvero” avere uno scopo, si ridefinisce lo scopo in termini di una struttura — l’anello di feedback — che si può costruire e osservare. La cibernetica mette così feedback, controllo e informazione sotto un unico tetto valido per animali, macchine e sistemi sociali. Questo capitolo è, in un certo senso, l’anticamera della Parte X, interamente dedicata alla cibernetica: qui si introduce il meccanismo, lì se ne esplorano le conseguenze su scala di intere discipline.

Il feedforward, come concetto esplicito e con quel nome, è più tardo. Nasce nell’ingegneria del controllo di processo — raffinerie, impianti chimici — a metà Novecento, quando ci si accorge che aspettare l’errore costa troppo se il disturbo è grande e lo si può misurare a monte, prima che entri nel processo. La differenza di “anzianità” tra i due concetti non è casuale: il feedback è un meccanismo che si può scoprire per caso, costruendo un dispositivo che per sua natura si auto-regola, senza capirne la teoria — è successo proprio così con i regolatori a sfere. Il feedforward, invece, richiede di aver già un modello del processo: non lo si inciampa per caso, lo si progetta deliberatamente. Per questo arriva dopo, in un’epoca in cui i processi industriali erano abbastanza ben modellati da permettere di calcolare in anticipo l’effetto di un disturbo.

Una nota di confine con i capitoli vicini chiude il contesto. La stabilità descrive cosa fa un sistema lasciato a sé stesso; l’osservabilità e la controllabilità descrivono cosa di un sistema si può misurare e governare. Feedback e feedforward usano quelle proprietà ma rispondono a una domanda ulteriore: date le leve e gli strumenti di misura, con quale strategia li si adopera per tenere il sistema sull’obiettivo? Sono il primo capitolo della Parte che parla non di proprietà del sistema, ma di strategie di chi lo regola.

L’intuizione

Prima di qualsiasi formula conviene afferrare la coppia da tre angoli distinti. Il primo è una metafora concreta di guida; il secondo è strutturale e riguarda la forma delle frecce causali; il terzo riguarda il tipo di informazione che ciascuno schema usa. Tre angoli diversi sullo stesso oggetto, perché un concetto afferrato da più lati si dimentica meno facilmente.

Primo angolo: guidare con il vento laterale

Stai guidando su una strada dritta. Soffia vento da destra, a raffiche. Il vento è il disturbo: spinge l’auto fuori dalla corsia. Il tuo obiettivo — stare al centro della corsia — è il setpoint, il riferimento. Hai due modi di tenerti al centro, e li puoi vivere entrambi.

Il modo feedback: tieni le mani morbide sul volante e senti l’auto. Quando una raffica la spinge a sinistra, percepisci lo spostamento — vedi la riga di mezzeria avvicinarsi — e correggi sterzando a destra quel tanto che serve. Aspetti che lo scarto si manifesti, lo misuri, reagisci. Il pregio: funziona qualunque sia la causa dello scarto. Vento, una buca, una leggera pendenza della strada, una gomma un po’ sgonfia: non importa, tu vedi la deriva e la correggi. Il difetto: c’è sempre un po’ di scarto prima della correzione. Reagisci a un errore che è già accaduto.

Il modo feedforward: davanti a te, sul ciglio, una bandiera sventola tesa da destra. La vedi. Prima ancora che la raffica raggiunga l’auto e la faccia scartare, dai un filo di volante a destra — perché sai, da un modello costruito con l’esperienza, che quel vento spingerà l’auto a sinistra di una certa quantità. Hai agito sul disturbo, non sull’errore. Se il tuo modello del vento è buono, l’auto non scarta affatto: la tua sterzata anticipata e la spinta del vento si cancellano. Il pregio: nessuna deriva, correzione istantanea. Il difetto: funziona solo per i disturbi che vedi arrivare e che il tuo modello sa tradurre in una sterzata. La buca improvvisa che non avevi visto, il feedforward non la coglie.

Il punto cruciale: nessun guidatore esperto usa solo uno dei due. Usa il feedforward per i disturbi visibili in anticipo (la raffica annunciata dalla bandiera) e il feedback per tutto il resto (la buca, l’errore del proprio modello del vento). Il feedforward fa il grosso del lavoro, in fretta; il feedback ripulisce ciò che il modello ha sbagliato. Questa combinazione non è un dettaglio: è lo schema standard, e ci torneremo.

C’è un dettaglio della metafora che vale la pena spremere, perché illumina il ruolo del modello nel feedforward. Il guidatore che vede la bandiera e sterza in anticipo non sta reagendo alla bandiera in sé: sta usando la bandiera come indicatore di un disturbo — il vento — e poi un modello mentale (“vento da destra di questa intensità sposta l’auto a sinistra di tanto”) per tradurre quell’indicatore in una sterzata. Se il modello è sbagliato — il guidatore è su un’auto pesante e usa il modello di un’auto leggera — sterza troppo, e di fatto introduce lui un errore che prima non c’era. Il feedforward è potente quanto è buono il suo modello, e pericoloso quando il modello è sbagliato. Il feedback, invece, non ha bisogno di sapere cosa causa la deriva: la vede e la corregge. Questa asimmetria — il feedforward ha bisogno di capire, il feedback no — è il cuore di tutto il capitolo.

Figura in preparazione

fig-2: due pannelli affiancati, stessa auto su strada con vento laterale. Pannello sinistro “feedback”: l’auto ha già scartato verso sinistra, una freccia di correzione la riporta al centro, etichetta “reagisce DOPO l’errore”. Pannello destro “feedforward”: una bandiera sventola in lontananza, l’auto sterza in anticipo e resta al centro, etichetta “agisce PRIMA dell’errore, sul disturbo previsto”

Secondo angolo: la catena che si chiude in anello

Il secondo angolo è più astratto ma porta dritto al cuore della cibernetica, ed è una questione di forma delle frecce causali.

In un sistema senza feedback, le frecce vanno tutte nella stessa direzione. Ingresso, poi processo, poi uscita. È una catena: l’acqua scorre dal rubinetto al lavandino e non torna su. Ogni cosa ha una causa a monte e un effetto a valle, e i due ruoli non si confondono mai.

Il feedback fa una cosa sola, ma la cambia tutta: prende l’uscita e la riporta indietro a essere ingresso. La catena si chiude in un anello. Da questo momento la domanda lineare “qual è la causa e quale l’effetto?” perde senso. Lungo l’anello, ogni variabile è causa ed effetto di sé stessa, con un ritardo. La velocità del motore di Watt causa il sollevamento delle sfere, che causa la chiusura della valvola, che causa la diminuzione del vapore, che causa una nuova velocità del motore. Dove comincia? Da nessuna parte: è un cerchio. Questo è il salto mentale della cibernetica — smettere di pensare per catene e cominciare a pensare per cicli. Chi continua a cercare “la causa” dentro un anello di feedback fa diagnosi sbagliate.

Questa chiusura dell’anello ha una conseguenza che a prima vista sorprende: un sistema con feedback può fare cose che nessuno dei suoi componenti, preso da solo, sa fare. Un anello di feedback negativo “insegue” un bersaglio, lo “difende” dai disturbi, sembra “volere” che l’uscita stia su un valore. Eppure nessun singolo componente — il sensore, il controllore, l’attuatore — vuole alcunché: ognuno applica una regola fissa. Lo scopo apparente emerge dalla chiusura dell’anello. È esattamente l’osservazione che colpì Wiener: il comportamento orientato a un fine non richiede un’intenzione dentro la macchina, basta che ci sia un anello di feedback. È anche il motivo per cui pensare per cicli, e non per catene, è il prerequisito per capire come un sistema possa avere un comportamento “intelligente” senza che nessun pezzo lo sia.

Da questo angolo, la distinzione tra feedback negativo e positivo diventa nitida. Percorri l’anello una volta e tieni traccia del segno a ogni tratto. Se, tornato al punto di partenza, una deviazione iniziale verso l’alto produce — dopo aver fatto tutto il giro — una spinta verso il basso, l’anello si oppone alle deviazioni: è feedback negativo, e tende a stabilizzare. Se invece una deviazione verso l’alto produce, a fine giro, un’altra spinta verso l’alto, l’anello rinforza le deviazioni: è feedback positivo, e tende a destabilizzare. Il feedforward, in questo linguaggio, non chiude nessun anello: è semplicemente una freccia in più che entra nella catena dal lato del disturbo. Resta una catena, solo con un ingresso aggiuntivo.

C’è un dettaglio che vale la pena fissare, perché sfata un’idea istintiva. Si è tentati di pensare che il feedforward sia “il feedback fatto bene”, una versione superiore. Non lo è: sono strumenti con costi e prerequisiti diversi. Il feedback ha un prerequisito minimo — basta saper misurare la propria uscita — ma paga il prezzo del ritardo. Il feedforward ha un prerequisito pesante — devi vedere il disturbo in anticipo e devi avere un modello di come ti influenzerà — ma in cambio elimina il ritardo. Dove non hai il modello, o non puoi misurare il disturbo a monte, il feedforward semplicemente non è disponibile, e il feedback è l’unica strada. Per questo il feedback è ovunque, e il feedforward solo dove le condizioni lo permettono.

Una conseguenza di questo angolo merita di essere detta esplicitamente, perché orienta la lettura del resto del capitolo. Poiché il feedforward non chiude un anello, non può diventare instabile da solo. Non c’è un giro lungo cui un errore possa rincorrersi e amplificarsi: l’informazione entra dal disturbo, attraversa il modello, esce come azione, e finisce lì. Tutta l’instabilità — l’oscillazione, la divergenza — è un fenomeno degli anelli, cioè del feedback. Il feedforward ha altri difetti, gravi, ma non quello. Questa asimmetria spiega perché, nelle sezioni sui limiti, l’instabilità comparirà solo a proposito del feedback: è una proprietà dei cicli, e il feedforward cicli non ne ha.

Terzo angolo: chi porta l’informazione

Un terzo modo di guardare la coppia, più astratto, lega questo capitolo al pensiero sull’informazione, ed è utile perché chiarisce perché feedforward e feedback hanno punti ciechi opposti.

In un anello di feedback, l’informazione che guida la correzione viene dall’uscita del sistema — da $y$, da ciò che è già successo. È informazione affidabile, perché è una misura del mondo reale, non una previsione. Ma è informazione vecchia: descrive uno stato che, quando la correzione finalmente agisce, potrebbe essere già cambiato. Il feedback compra affidabilità al prezzo della freschezza.

In un controllo feedforward, l’informazione che guida la correzione viene dal disturbo misurato a monte e da un modello. È informazione fresca — anzi, anticipata: parla di qualcosa che non ha ancora fatto effetto. Ma la sua affidabilità dipende interamente dalla qualità del modello: se il modello sbaglia, la correzione è sbagliata, e niente la smentisce. Il feedforward compra freschezza al prezzo dell’affidabilità.

Detto così, diventa ovvio perché i due si combinino e perché i loro buchi siano complementari. Il feedforward porta informazione anticipata ma fragile; il feedback porta informazione affidabile ma in ritardo. Un sistema che usa entrambi ha, a ogni istante, sia una stima anticipata di dove sta andando sia una misura verificata di dov’è. È la stessa ragione per cui un pilota guarda insieme la rotta pianificata e gli strumenti.

Questo terzo angolo è anche quello che lega il capitolo al pensiero sull’AI in modo più diretto. Un agente che pianifica sta facendo, in fondo, feedforward: costruisce un modello di come andrà il mondo e calcola le azioni in anticipo. Un agente che osserva il risultato di ogni azione sta facendo feedback: usa informazione verificata, ma vecchia di un passo. La domanda di disegno “quanto pianificare in anticipo, quanto adattarsi passo per passo” è, alla lettera, la domanda “quanto pesare informazione anticipata-ma-fragile contro informazione affidabile-ma-in-ritardo”. Non è una metafora: è lo stesso compromesso, sotto due nomi.

Feedback negativo e feedback positivo

La parola “feedback” da sola è ambigua. I due tipi fanno cose opposte, e confonderli è il primo errore da evitare.

Il feedback negativo è correttivo. L’azione che l’anello genera si oppone all’errore: lo riduce, riporta il sistema verso il setpoint. È il feedback dei sistemi che funzionano. Il termostato che spegne il riscaldamento quando fa troppo caldo. Il governor di Watt che chiude il vapore quando il motore accelera. Il corpo che suda quando la temperatura interna sale. L’aggettivo “negativo” non è un giudizio di valore: indica solo che il segnale di ritorno ha segno opposto rispetto alla deviazione. Negativo come il segno meno, non come “cattivo”.

Il feedback positivo è amplificante. L’azione rinforza la deviazione invece di opporvisi. Una piccola spinta in una direzione genera una spinta ancora più grande nella stessa direzione, che ne genera una ancora più grande, e così via. Gli esiti sono crescita esponenziale, valanga, esplosione, oppure il blocco del sistema in uno stato estremo da cui non torna.

Il feedback positivo ha una firma riconoscibile: nei suoi stadi iniziali sembra “non succedere niente”, poi tutto accade in fretta. La crescita è lenta finché i numeri sono piccoli e improvvisa quando diventano grandi — è la forma di ogni esplosione e di ogni contagio.

Tre esempi di feedback positivo, da tre mondi diversi. Il microfono che fischia: il microfono capta un suono, l’amplificatore lo rilancia dall’altoparlante, il microfono ricapta il suono amplificato, lo rilancia ancora più forte. In una frazione di secondo il sistema satura in un fischio acuto — l’effetto Larsen. La corsa agli armamenti: una nazione si arma perché teme la rivale, il che spinge la rivale ad armarsi di più, il che spinge la prima ad armarsi ancora di più. L’effetto valanga: un piccolo distacco di neve trascina altra neve, che ne trascina altra ancora; la massa in movimento cresce mentre scende.

Il feedback positivo non è sempre patologico. È il motore della crescita di una popolazione, della formazione di una decisione netta in un cervello (un gruppo di neuroni che si eccita a vicenda fino a “vincere”), e in biologia ha funzioni precise e vitali: durante il parto l’ormone ossitocina aumenta le contrazioni dell’utero, e le contrazioni stimolano il rilascio di altra ossitocina — un anello positivo che si ferma solo quando il bambino è nato. La coagulazione del sangue funziona allo stesso modo. Sono casi in cui serve un’escalation rapida e tutto-o-niente. Ma fuori da questi casi, un feedback positivo non controllato finisce sempre male: o satura, o esplode. Tipicamente lo si lascia agire solo finché un limite fisico o un feedback negativo che subentra non lo fermano.

Una regola mnemonica che riassume tutto: il feedback negativo cerca un equilibrio e ci si aggrappa; il feedback positivo fugge dall’equilibrio.

Vale la pena spendere una frase su come riconoscere il segno di un anello quando non è ovvio. Il trucco operativo è quello già visto nel secondo angolo dell’intuizione: immagina una piccola perturbazione in una direzione, percorri l’anello passo per passo tenendo conto di ogni inversione di segno, e guarda con che segno la perturbazione torna al punto di partenza. Tornata con segno opposto: anello negativo. Tornata con lo stesso segno: anello positivo. È un conto qualitativo, non richiede numeri, e funziona anche su anelli intricati: basta non perdere il conto delle inversioni. Molti errori di analisi nascono dal saltare questo passaggio e “indovinare” il segno dall’intenzione del progettista invece di calcolarlo dalla struttura.

C’è anche un modo di vedere i due tipi che torna utile quando si analizzano sistemi reali complicati, in cui non c’è un singolo anello pulito ma molti anelli intrecciati. Un sistema può contenere allo stesso tempo anelli positivi e anelli negativi, e il comportamento osservabile dipende da quale famiglia “vince” in un dato regime. Una popolazione di conigli cresce per feedback positivo (più conigli fanno più conigli) finché il cibo è abbondante; quando il cibo scarseggia, subentra un feedback negativo (più conigli, meno cibo a testa, meno conigli) che frena la crescita e la porta verso un equilibrio. Lo stesso sistema, due anelli, due regimi. Riconoscere quali anelli sono attivi e con che segno è il primo passo per capire un sistema dinamico — e questo modo di leggere i sistemi come reti di anelli con segno è il cuore della system dynamics, la disciplina che la Parte sul pensiero sistemico riprenderà.

Un’ultima osservazione, perché è il ponte con il capitolo sull’equilibrio e la stabilità. Lì un equilibrio stabile è stato descritto come un punto verso cui il sistema ritorna se perturbato. Adesso possiamo dire da dove viene quella stabilità: viene da un feedback negativo. Un equilibrio è stabile esattamente quando, attorno a esso, gli anelli di feedback dominanti sono negativi — riportano indietro. Un equilibrio è instabile quando attorno a esso domina un feedback positivo — allontana. La stabilità non è una proprietà magica del punto: è il segno degli anelli che lo circondano.

La meccanica

Ora il formalismo, un pezzo alla volta, restando sul caso più semplice e più istruttivo. Il caso semplice qui è il controllore proporzionale — l’azione è proporzionale all’errore, niente di più — e un processo lineare a tempo discreto. Non è il caso più realistico, ma è quello in cui ogni effetto si calcola a mano e si vede nudo. Le complicazioni del caso reale — azione integrale e derivativa, dinamica continua, non linearità — sono materia dei capitoli di control theory; aggiungerle qui nasconderebbe le intuizioni invece di chiarirle.

L’anello di feedback, componente per componente

Un anello di controllo a retroazione ha sempre gli stessi pezzi. Li nominiamo una volta, con il loro simbolo.

• Il riferimento o setpoint, $r$: dove vogliamo che sia l’uscita. La temperatura impostata sul termostato.
• L’uscita misurata, $y$: dove l’uscita è davvero. La temperatura che la stanza ha adesso.
• L’errore, $e = r - y$: lo scarto tra dove vogliamo essere e dove siamo. Se la stanza è più fredda del voluto, $e$ è positivo.
• Il controllore: la funzione che trasforma l’errore in un’azione. La forma più semplice è il controllo proporzionale, $u = K \cdot e$, dove $u$ è l’azione e $K$ è un numero chiamato guadagno. In parole povere: l’azione è proporzionale all’errore, e $K$ dice quanto reagiamo forte.
• Il processo (in inglese plant): il sistema fisico che subisce l’azione $u$ e i disturbi $d$, e produce la nuova uscita $y$.
• Il sensore: misura $y$. Non è gratis né istantaneo: introduce ritardo e rumore.

Il ciclo gira così, all’infinito: misura $y$, calcola $e = r - y$, calcola $u = K \cdot e$, applica $u$ al processo, il processo produce un nuovo $y$, ricomincia. In parole povere, l’anello dice: “guarda quanto sei lontano dal bersaglio, e spingi verso il bersaglio con una forza proporzionale a quella distanza”.

Un’osservazione su questa lista di componenti. Sembrano sei pezzi distinti, ma il cuore concettuale è uno solo: il nodo dove si calcola $e = r - y$. È lì che il sistema “confronta” dove vuole essere con dove è, ed è quel confronto a far funzionare tutto. Togli quel nodo e i pezzi restano, ma l’anello non si chiude più: hai un sistema che agisce e un sistema che misura, scollegati. Il feedback, ridotto all’osso, è quel singolo atto di confronto, ripetuto. Tutto il resto — il controllore, il processo, il sensore — sono il contorno necessario perché quel confronto possa avvenire e tradursi in azione.

Figura in preparazione

fig-3: schema a blocchi dell’anello di feedback. Blocchi collegati da frecce: nodo di somma (r meno y) produce errore e, errore entra nel blocco “controllore”, esce azione u, u entra nel blocco “processo”, su cui agisce anche una freccia laterale “disturbo d”, esce uscita y; y torna indietro attraverso il blocco “sensore” fino al nodo di somma. Etichetta sul ramo di ritorno “retroazione”. Tipo: mermaid o vector-svg

Il guadagno di loop

C’è una grandezza che riassume il comportamento dell’intero anello. Percorri l’anello una volta e moltiplica il guadagno di ogni blocco che incontri: controllore, processo, sensore. Il prodotto si chiama guadagno di loop, e lo indichiamo con $L$.

Il guadagno di loop governa il carattere dell’anello. Se $L$ è grande in modulo, con il giusto segno negativo, la correzione è forte: l’errore a regime — lo scarto che rimane quando il sistema si è assestato — è piccolo, ma cresce il rischio che il sistema oscilli. Se $L$ è piccolo, la correzione è debole: rimane un errore residuo grande, ma il comportamento è docile e tranquillo. Se per qualche motivo $L$ diventa effettivamente positivo (vedremo subito come può accadere anche partendo da un feedback pensato come negativo), l’anello amplifica invece di correggere, e il sistema diventa instabile.

La lezione, in una frase: non esiste “il guadagno giusto” in assoluto. C’è un compromesso tra prontezza della correzione e rischio di instabilità, e va calibrato.

Vale la pena fissare l’intuizione di perché un guadagno troppo basso lascia un errore residuo. Con un controllore proporzionale puro, l’azione è $u = K \cdot e$: per produrre un’azione diversa da zero serve un errore diverso da zero. Se c’è un disturbo costante che spinge sempre nella stessa direzione, il sistema non può assestarsi a errore zero, perché a errore zero l’azione sarebbe zero e il disturbo vincerebbe. Si assesta invece a un errore piccolo ma non nullo, quel tanto che basta a generare l’azione che bilancia il disturbo. Più alto è $K$, più piccolo è quell’errore residuo — ma, come visto, non si può alzare $K$ all’infinito. È proprio per superare questo limite che i controllori reali aggiungono l’azione integrale, quella che Maxwell distingueva già nei “governori”: un termine che accumula l’errore nel tempo e quindi può produrre un’azione non nulla anche quando l’errore istantaneo è zero. Ma quello è il PID, ed è materia di un capitolo della Parte XI.

Il ritardo, e perché un feedback negativo può oscillare

Questo è il punto più sottile e più utile del capitolo. Un anello di feedback negativo dovrebbe stabilizzare. Eppure i regolatori di Watt a volte oscillavano sempre più forte. Perché?

La risposta è il ritardo (in inglese lag). Ogni anello reale impiega tempo a fare il suo giro: il sensore impiega tempo a misurare, il controllore a calcolare, l’attuatore ad agire, il processo a rispondere. La correzione che applichi adesso è stata calcolata sull’errore di prima.

Se il ritardo è piccolo rispetto a quanto velocemente cambia il sistema, non è un problema: la correzione arriva ancora “in tempo”. Ma se il ritardo è grande, succede una cosa precisa e brutta. La correzione, calcolata per opporsi a un errore positivo, arriva quando l’errore ha già cambiato segno ed è diventato negativo. A quel punto la tua correzione, che doveva opporsi all’errore, lo rinforza. Il feedback negativo, a causa del ritardo, si è di fatto trasformato in feedback positivo. Il sistema oscilla. E se il guadagno è alto, le oscillazioni crescono di ampiezza a ogni giro: instabilità.

L’esempio domestico perfetto è la doccia con il boiler lontano. Apri il rubinetto del caldo. Per qualche secondo non cambia nulla — è il ritardo, l’acqua calda deve ancora arrivare. Tu, impaziente, apri ancora di più. Poi arriva tutta insieme l’acqua bollente che hai chiamato in due tempi: ti scotti. Chiudi di colpo. Dopo qualche secondo arriva il freddo che hai appena ordinato. E così oscilli tra scottato e gelato, magari per tutta la doccia. Non c’è nessun guasto: è il ritardo nell’anello, da solo, a generare l’oscillazione. La doccia con il miscelatore termostatico moderno non oscilla perché il ritardo è quasi azzerato.

C’è un modo di vedere il fenomeno che lo rende inevitabile. Una correzione sfasata di mezzo ciclo rispetto all’errore non lo riduce: lo sostiene. Immagina di spingere un’altalena. Se spingi quando l’altalena si sta allontanando da te, le dai energia e l’oscillazione cresce. Se spingi quando ti si avvicina, le togli energia e l’oscillazione si smorza. La differenza tra smorzare e amplificare è solo il tempismo della spinta — il suo sfasamento rispetto al moto. Un anello di feedback con troppo ritardo è un bambino che spinge l’altalena sempre al momento sbagliato: ogni “correzione” aggiunge energia all’oscillazione. Il segno dell’anello dice che la spinta vorrebbe essere correttiva; il ritardo decide se lo è davvero.

Le cure sono tre, e si capiscono tutte da qui. Ridurre il guadagno: correzioni più caute danno meno overshoot, e l’oscillazione, se nasce, nasce più piccola e si smorza. Ridurre il ritardo: sensori e attuatori più veloci accorciano il giro dell’anello, e la correzione arriva ancora “in tempo”. Oppure aggiungere un termine anticipatorio — qualcosa che provi a indovinare dove sta andando il sistema invece di reagire a dov’è già. Nel controllore PID questo è il termine derivativo, che reagisce alla velocità dell’errore e non solo al suo valore; nel mondo del controllo di processo è il feedforward vero e proprio. Questa terza cura è il ponte verso la prossima sezione.

Figura in preparazione

fig-4: due grafici temporali sovrapposti, asse x tempo, asse y uscita y, con linea tratteggiata orizzontale al setpoint r. Curva A “ritardo piccolo”: sale e converge dolcemente al setpoint. Curva B “ritardo grande, stesso guadagno”: oscilla attorno al setpoint con ampiezza crescente, etichetta “la correzione arriva sfasata e rinforza l’errore”. Tipo: vector-svg

Il controllo feedforward, componente per componente

Il feedforward ha una struttura diversa da quella del feedback, ed è più corta da descrivere perché non c’è un anello da chiudere. È una catena di tre elementi.

Si parte dal disturbo $d$, che il feedforward deve poter misurare a monte — o almeno prevedere. È il primo prerequisito, e non è scontato: ci sono disturbi che semplicemente non si vedono prima che facciano effetto, e su quelli il feedforward non si può applicare. Vale la pena insistere: il feedforward non agisce sui disturbi “futuri” in senso magico, agisce su disturbi che sono già misurabili adesso ma il cui effetto sull’uscita non si è ancora prodotto. C’è una finestra temporale — tra il momento in cui il disturbo è osservabile a monte e il momento in cui intacca l’uscita — e il feedforward vive interamente dentro quella finestra. Se la finestra è ampia, il feedforward ha tempo di agire; se è nulla, il feedforward collassa nel feedback. Si dispone poi di un modello $M$ che dice: dato questo disturbo $d$, quanto sposterà l’uscita $y$, e in quale direzione? È il secondo prerequisito, ed è il più pesante: senza un modello quantitativo del processo, il feedforward non ha niente da calcolare. Con il modello in mano si calcola un’azione $u_{ff}$ che, secondo il modello, cancella in anticipo l’effetto del disturbo. E si applica $u_{ff}$ subito, nell’istante stesso in cui il disturbo viene misurato, prima che il disturbo abbia avuto il tempo di muovere $y$.

Il punto strutturale: $y$ non compare da nessuna parte in questo calcolo. Il feedforward non guarda mai il risultato. Se il modello $M$ è perfetto e il disturbo $d$ è misurato con esattezza, l’uscita non devia di un millimetro. Ma se $M$ è impreciso — e ogni modello del mondo lo è — resta un errore residuo, e il feedforward non lo correggerà mai, perché per definizione non guarda $y$.

Vale la pena vedere il calcolo nel caso più semplice, quello lineare. Supponi che il processo, in assenza di azione, traduca il disturbo nell’uscita con un fattore $g_d$: senza fare nulla, $y$ cambia di $g_d \cdot d$. E supponi che la tua azione $u$ influenzi l’uscita con un fattore $g_u$: l’azione cambia $y$ di $g_u \cdot u$. Vuoi che i due effetti si cancellino, cioè $g_u \cdot u_{ff} + g_d \cdot d = 0$. Risolvendo per l’azione feedforward:

$u_{ff} = -\frac{g_d}{g_u} \cdot d$

In parole povere: misura il disturbo, moltiplicalo per il rapporto tra “quanto il disturbo sposta l’uscita” e “quanto la tua azione la sposta”, cambia il segno, e applica il risultato. Il rapporto $g_d / g_u$ è il modello $M$. Se lo conosci con precisione, la cancellazione è perfetta. Se lo conosci male — perché $g_d$ e $g_u$ in realtà non sono costanti, o cambiano con la temperatura, o li hai stimati male — il feedforward compensa solo in parte, e quel “solo in parte” è esattamente l’errore residuo che il feedback dovrà ripulire.

Questo rende concreto il prerequisito pesante del feedforward menzionato nell’intuizione: per usarlo devi conoscere $g_d / g_u$, cioè devi avere un modello quantitativo del processo. Il feedback, invece, non chiede di conoscere né $g_d$ né $g_u$: misura $y$, calcola l’errore, corregge. È più lento, ma non ha bisogno di un modello. Questa è la ragione profonda per cui il feedback è il default e il feedforward è l’aggiunta.

Perché in pratica si combinano: feedforward più feedback trim

Da soli, i due schemi hanno ciascuno un buco preciso e complementare. Il feedforward è veloce ma cieco: corregge solo i disturbi che ha modellato e misurato; tutto il resto gli passa accanto. Il feedback è universale ma sempre in ritardo: per agire deve prima vedere lo scarto, quindi un po’ di scarto c’è sempre.

La soluzione standard nell’ingegneria di controllo di processo si chiama feedforward più feedback trim e mette i due in serie sulla stessa azione. Il feedforward fa il lavoro grosso: prende i disturbi grandi, misurabili, prevedibili, e li compensa in fretta, prima che facciano danno. Il feedback fa la rifinitura — il “trim”: corregge tutto ciò che il modello del feedforward ha sbagliato, i disturbi che nessuno ha misurato, la deriva lenta dei componenti. Il feedforward dà velocità; il feedback dà robustezza all’ignoranza. Ognuno tappa il buco dell’altro. Praticamente nessun sistema di controllo serio usa solo uno dei due.

In termini di schema a blocchi, l’azione totale applicata al processo è la somma di due contributi: $u = u_{ff} + u_{fb}$. Il primo, $u_{ff}$, è calcolato dal ramo feedforward a partire dal disturbo misurato $d$. Il secondo, $u_{fb}$, è calcolato dal controllore a retroazione a partire dall’errore $e = r - y$. Quando il feedforward fa bene il suo lavoro, l’errore $e$ resta piccolo, e quindi $u_{fb}$ resta piccolo: il feedback lavora poco, solo sulla rifinitura. Quando il feedforward sbaglia — perché il disturbo era diverso dal previsto, o perché è arrivato un disturbo che nessuno misurava — l’errore cresce, e il feedback si attiva per riassorbirlo. Il sistema si auto-bilancia: il feedback fa esattamente tanto lavoro quanto ne serve a coprire ciò che il feedforward non ha coperto.

Vale la pena mettere in fila le differenze, perché è la tabella mentale da portarsi via:

• Su cosa agisce: il feedback agisce sull’errore misurato; il feedforward sul disturbo misurato o previsto.
• Quando agisce: il feedback dopo che lo scarto si è manifestato; il feedforward prima.
• Cosa gli serve: al feedback basta saper misurare la propria uscita; al feedforward serve misurare il disturbo a monte e avere un modello del processo.
• Punto cieco: il feedback è sempre in ritardo; il feedforward è cieco a tutto ciò che non ha modellato.
• Modo di fallire: il feedback con troppo guadagno o ritardo oscilla e diverge; il feedforward con un modello sbagliato compensa male, o nella direzione sbagliata.
• Quando usarlo da solo: il feedback si usa da solo spesso (è il default); il feedforward quasi mai, perché senza un feedback che lo rifinisca accumula errore.

Figura in preparazione

fig-5: schema a blocchi del controllo combinato. In alto un ramo “feedforward” parte dal disturbo d, passa per un blocco “modello” e produce u-ff. In basso il ramo “feedback” parte dal nodo di somma r meno y, passa per il blocco “controllore” e produce u-fb. I due contributi si sommano in un nodo e l’azione totale u entra nel “processo”, su cui agisce anche d; l’uscita y torna al nodo di somma del ramo feedback. Etichette: “feedforward: anticipa il disturbo noto”, “feedback: corregge cio che resta”. Tipo: mermaid o vector-svg

Esempi

Quattro esempi deliberatamente eterogenei: uno numerico che si calcola a mano, uno in codice, uno scenario del mondo reale, e uno che mostra i due schemi che lavorano insieme.

Esempio 1 — numerico: l’anello che oscilla al variare del guadagno

Prendiamo un processo elementare a tempo discreto. Lo stato è un numero $y$, e a ogni passo evolve così:

$y[t+1] = y[t] + u[t] + d[t]$

In parole povere: il nuovo valore è quello vecchio più l’azione $u$ che applichiamo più il disturbo $d$. Vogliamo portare $y$ al setpoint $r = 100$. Usiamo un controllore proporzionale, $u[t] = K \cdot e[t]$ con $e[t] = r - y[t]$. Partiamo da $y[0] = 0$ e per ora senza disturbo, $d = 0$.

Caso $K = 0.5$. Passo 0: $e = 100$, $u = 50$, quindi $y[1] = 0 + 50 = 50$. Passo 1: $e = 50$, $u = 25$, $y[2] = 75$. Poi $87.5$, $93.75$, $96.875$… La successione sale dolcemente verso 100 e ci si assesta. Feedback negativo sano: ogni passo dimezza la distanza residua.

Caso $K = 1$. Passo 0: $e = 100$, $u = 100$, $y[1] = 100$. Bersaglio centrato in un colpo solo, e ci resta. È il controllo cosiddetto deadbeat, il guadagno esattamente giusto per questo processo.

Caso $K = 2$. Passo 0: $e = 100$, $u = 200$, $y[1] = 200$ — abbiamo superato il bersaglio del doppio. Passo 1: $e = 100 - 200 = -100$, $u = -200$, $y[2] = 200 - 200 = 0$. Passo 2: $e = 100$ di nuovo, e siamo tornati al punto di partenza. La successione è $0, 200, 0, 200, \dots$: oscilla per sempre. Con $K = 2.5$ l’oscillazione cresce di ampiezza a ogni passo e diverge.

La morale numerica è netta: è lo stesso anello, con lo stesso feedback negativo (l’azione si oppone sempre all’errore, $u$ ha sempre il segno di $e$). Cambia solo il numero $K$, il guadagno, e il comportamento passa da convergenza dolce a oscillazione perpetua a esplosione. Il segno del feedback non basta a garantire la stabilità: conta il guadagno.

Un’ultima nota su questo esempio prima di aggiungere il disturbo. La soglia oltre cui l’anello oscilla — qui $K = 2$ — non è un numero universale: dipende dal processo. Per un processo diverso la soglia sarebbe altrove. Ma il fenomeno è universale: per ogni anello di feedback esiste un guadagno oltre il quale la correzione, anziché smorzare l’errore, lo fa rimbalzare. Questo è il senso profondo dell’esempio numerico: non insegna “usa $K$ minore di 2”, insegna “esiste sempre un confine, e va trovato”.

Aggiungiamo ora un disturbo per vedere il feedforward al lavoro sullo stesso processo. Supponi che a ogni passo entri un disturbo costante $d = -10$ (qualcosa che, lasciato fare, abbassa $y$ di 10 a ogni passo). Con il solo feedback proporzionale a $K = 0.5$, il sistema non raggiunge più esattamente 100: si assesta a un valore dove l’azione $u$ riesce appena a compensare il disturbo, e resta un piccolo errore a regime. Il feedback con la sola azione proporzionale non azzera mai del tutto un disturbo costante — gli serve l’errore residuo proprio per generare l’azione che tiene testa al disturbo.

Ora il feedforward. Il disturbo $d$ entra nell’equazione con coefficiente 1, e così l’azione $u$: nel linguaggio della formula del feedforward, $g_d = 1$ e $g_u = 1$, quindi $u_{ff} = -(g_d/g_u)\cdot d = -d = +10$. Misuriamo $d$ a ogni passo e aggiungiamo all’azione un contributo fisso di $+10$ che lo cancella esattamente. Con il feedforward attivo, l’equazione effettiva diventa $y[t+1] = y[t] + u_{fb}[t] + 10 + d[t]$, e poiché $d = -10$ il disturbo sparisce: il feedback torna a lavorare come se il disturbo non ci fosse, e $y$ converge a 100 pulito. È la dimostrazione numerica del principio: il feedforward toglie di mezzo il disturbo noto, il feedback fa il resto. E se avessimo sbagliato la misura — credendo $d = -8$ invece di $-10$ — il feedforward avrebbe aggiunto solo $+8$, lasciando un disturbo residuo di $-2$ che il feedback avrebbe poi assorbito. Esattamente il modello impreciso più il trim.

Esempio 2 — in codice: il loop agentico è feedback, il piano rigido è feedforward

Ecco un agente che lavora a un obiettivo osservando i risultati delle proprie azioni.

def agente_feedback(obiettivo, ambiente, max_passi=20):
    for passo in range(max_passi):
        osservazione = ambiente.stato()           # misura: y
        errore = valuta(osservazione, obiettivo)  # errore: e = r - y
        if errore.risolto:
            return "completato"
        azione = decidi(osservazione, errore)     # controllore: e -> u
        ambiente.esegui(azione)                   # applica u al processo
    return "budget esaurito"

I commenti dicono tutto: questo è un anello di feedback negativo. L’agente esegue un’azione, osserva il risultato, misura quanto manca all’obiettivo, e sceglie la prossima azione per ridurre quel gap. Il setpoint è l’obiettivo del task; l’errore è ciò che ancora non va; il controllore è il modello che decide. Il pattern ReAct (Reason+Act, introdotto in Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models”, arXiv 2022) è esattamente questa struttura. Si noti il max_passi: è un limite messo apposta, e in termini di controllo è una garanzia di terminazione che protegge dal caso in cui l’anello non converge. Un anello di feedback agentico, a differenza di un termostato, può non assestarsi mai — e il budget di passi è la rete di sicurezza che impedisce a un loop patologico di girare all’infinito.

Confrontalo con un agente puramente feedforward:

def agente_feedforward(obiettivo, ambiente):
    piano = pianifica_tutto(obiettivo)   # un modello, una previsione, una volta
    for azione in piano:
        ambiente.esegui(azione)          # esegue alla cieca, nessuna ri-osservazione
    return "piano eseguito"

Qui l’agente costruisce un piano completo all’inizio — sulla base del suo modello di come andrà il mondo — e poi lo esegue dalla prima all’ultima azione senza mai guardare i risultati intermedi. Veloce, prevedibile, tracciabile. Ma fragile: appena una sola azione produce un risultato diverso dal previsto, tutte le azioni successive del piano sono calcolate su uno stato del mondo che non esiste più, e l’agente non se ne accorge. È la cecità del feedforward, vista in codice.

Un dettaglio sul segno, perché qui l’analogia con il feedback negativo va presa sul serio. Nel primo agente, la funzione decidi riceve l’errore e dovrebbe scegliere un’azione che lo riduce — è questo a renderlo feedback negativo. Se invece l’agente scegliesse, passo dopo passo, azioni che allontanano dall’obiettivo (perché interpreta male l’osservazione, o perché un tool gli mente), l’anello diventerebbe a feedback positivo: ogni passo peggiora, e il peggioramento porta a un passo ancora peggiore. È esattamente ciò che si osserva in certi loop agentici patologici, dove l’agente “si convince” sempre di più di una strada sbagliata. Il codice del loop è identico nei due casi; cambia solo il segno effettivo di decidi, cioè se le sue azioni in media riducono o amplificano l’errore. Riconoscere questo segno è la prima diagnosi da fare su un agente che non converge.

Esempio 3 — scenario reale: il termostato, l’omeostasi, la fase cefalica

Il termostato di casa è il feedback negativo da manuale. Misura la temperatura della stanza $y$, la confronta con quella impostata $r$, accende il riscaldamento se $y < r$, lo spegne se $y > r$. Un dettaglio pratico: se accendesse e spegnesse esattamente a $y = r$, lo farebbe centinaia di volte attorno alla soglia, perché piccole fluttuazioni la attraversano di continuo — il fenomeno si chiama chattering. Per evitarlo, il termostato usa un’isteresi: accende quando scende sotto $r - 0.5\,°C$ e spegne solo quando supera $r + 0.5\,°C$. È un feedback negativo con una banda morta deliberata, che baratta un po’ di precisione contro molta meno usura.

Lo stesso schema, dentro un corpo, si chiama omeostasi. La temperatura interna, la glicemia, il pH del sangue sono mantenuti entro intervalli stretti da anelli di feedback negativo: se la temperatura sale, si suda e i vasi si dilatano per disperdere calore; se scende, si rabbrividisce e i vasi si restringono. Misura, confronta, correggi: identico al termostato. Il termine “omeostasi” fu coniato dal fisiologo statunitense Walter Cannon negli anni ‘20, e l’idea che la vita sia, in larga parte, un fitto intreccio di anelli di feedback negativo che difendono le variabili interne è una delle pietre angolari della fisiologia. Non è un’analogia con la teoria del controllo: è la stessa struttura, scoperta in modo indipendente in biologia.

C’è anche un esempio di feedback positivo che vale la pena nominare per contrasto, sempre dal corpo: la febbre alta non controllata, o lo shock settico, sono situazioni in cui anelli che dovrebbero essere correttivi si rovesciano e amplificano il danno. La differenza tra un corpo sano e uno in crisi è spesso, letteralmente, il segno degli anelli dominanti.

E il corpo fa anche feedforward. Quando vedi o annusi del cibo, il pancreas inizia a rilasciare insulina prima che il glucosio nel sangue salga davvero — è la cosiddetta fase cefalica della secrezione insulinica. Il corpo non sta correggendo un errore (la glicemia non è ancora cambiata): sta agendo su un disturbo previsto, il pasto in arrivo, sulla base di un modello appreso. È feedforward biologico, e si combina con il feedback negativo che poi rifinirà la glicemia durante e dopo il pasto. Lo stesso corpo, i due schemi insieme.

Esempio 4 — combinato: la caldaia industriale con disturbo misurabile

L’ultimo esempio mostra i due schemi che lavorano in tandem, ed è il caso che ha fatto nascere il feedforward come tecnica nominata. Immagina una caldaia industriale che deve mantenere l’acqua a $r = 80\,°C$. L’acqua viene prelevata da un serbatoio a temperatura $y$, riscaldata da un bruciatore, e usata da un impianto a valle.

Il disturbo dominante è la portata di acqua fredda in ingresso: quando l’impianto a valle apre una valvola e tira più acqua, entra nel serbatoio un fiotto di acqua fredda che, se nulla interviene, fa crollare $y$.

Con il solo feedback: la temperatura $y$ cala, il sensore lo rileva, il controllore alza la potenza del bruciatore. Funziona, ma c’è un buco temporale: tra l’arrivo dell’acqua fredda e il momento in cui il bruciatore ha riscaldato abbastanza da recuperare, l’acqua resta sotto i 80 gradi per parecchi secondi. Per un impianto che ha bisogno di temperatura stabile, quei secondi sono un difetto.

Con il feedforward aggiunto: un sensore di portata misura quanta acqua fredda sta entrando, nell’istante in cui entra. Un modello — semplice fisica del bilancio termico — calcola quanta potenza extra serve al bruciatore per compensare esattamente quel fiotto, e la applica subito, senza aspettare che $y$ cali. Se il modello è buono, la temperatura non cala affatto: la potenza extra entra in contemporanea con l’acqua fredda e la cancella.

E il feedback trim? Resta lì, e fa il suo lavoro residuo. Il modello del feedforward non sarà perfetto: magari sottostima un po’ la potenza necessaria, o la portata misurata ha un piccolo errore, o c’è un disturbo non misurato (la temperatura ambiente che cala lentamente). Tutto ciò che il feedforward non cattura lascia un piccolo errore $e$, e il controllore a retroazione lo riassorbe. Risultato: risposta quasi istantanea ai disturbi grandi e prevedibili (feedforward), più correzione lenta e affidabile di tutto il resto (feedback). Nessuno dei due, da solo, avrebbe dato questa combinazione di velocità e robustezza.

Si noti la divisione del lavoro: il feedforward si prende il disturbo grande, noto e misurabile, perché lì il suo modello è affidabile e la velocità conta; il feedback si prende i disturbi piccoli, ignoti, non misurati, perché lì la sua universalità conta e la sua lentezza non fa danno. È una ripartizione per “taglia e prevedibilità” del disturbo, non una gerarchia. E questa stessa ripartizione, come si vedrà nella sezione sull’AI, è quella che separa un piano agentico di alto livello dall’adattamento passo per passo: il piano gestisce la struttura grande e prevedibile del task, l’adattamento gestisce le sorprese locali.

Applicazioni pratiche

Il vocabolario di questo capitolo si applica direttamente a chi costruisce sistemi AI. Il filo comune di tutte le applicazioni che seguono è uno: davanti a un sistema che si comporta male, prima di chiedersi “quale componente ha sbagliato” conviene chiedersi “che forma ha il loop”. Spesso la risposta utile è la seconda.

Diagnosticare un agente che diverge. Quando un agente entra in un comportamento patologico, la causa è quasi sempre uno dei tre guasti dell’anello di feedback, e ciascuno ha una cura diversa. Se il problema è il ritardo — l’agente lavora su osservazioni stantie, corregge uno stato che è già cambiato — la cura è ri-osservare più spesso, restringere il passo tra azione e verifica. Se il problema è il guadagno troppo alto — l’agente sovra-corregge, fa modifiche enormi a ogni passo, l’edit successivo deve disfare il precedente — la cura è ridurre il guadagno: azioni più piccole, edit incrementali, un cambiamento alla volta. Se il problema è un feedback positivo — l’agente rinforza il proprio errore invece di correggerlo — la cura è strutturale: serve un ancoraggio esterno che spezzi l’anello, un test oggettivo o un controllo umano. La diagnosi giusta dipende dal saper distinguere i tre.

Un caso concreto rende la distinzione tangibile. Un agente che lavora su una codebase fa un edit per far passare un test, lancia i test, ne vede un secondo rotto, lo aggiusta, e quel fix rompe di nuovo il primo: ciclo infinito. Cosa è? Non è ritardo — l’agente vede risultati freschi. Non è feedback positivo in senso stretto — l’agente vuole davvero ridurre l’errore. È guadagno troppo alto: ogni edit è troppo ampio e tocca codice che non doveva toccare. La cura non è “ri-osserva di più” né “metti un umano nel loop”: è abbassare il guadagno, costringere l’agente a edit minimi, una modifica chirurgica alla volta. Saper nominare il guasto come “guadagno” e non come “ritardo” porta direttamente alla cura giusta. È questo che il vocabolario di controllo aggiunge: non risolve il problema da solo, ma fa puntare allo strumento corretto.

Scegliere il mix nei pattern agentici. Plan-and-Execute (pianifica tutto, poi esegui) è un agente di sapore feedforward; ReAct puro (osserva e decidi a ogni passo) è di sapore feedback. La scelta dipende dal task. Ambiente prevedibile e costoso da osservare a ogni passo: pende verso il feedforward, pianifica e fidati del piano. Ambiente che cambia, dove le azioni hanno esiti incerti: pende verso il feedback, ri-osserva sempre. La soluzione che quasi sempre vince è quella dell’ingegneria di processo: un piano di alto livello (feedforward) più ri-osservazione e replanning a ogni passo (feedback trim). Plan-and-Execute con replanning è letteralmente il “feedforward più feedback” applicato agli agenti.

Questa lettura rende anche più chiaro un anti-pattern comune. Un agente puramente feedforward — pianifica una lunga sequenza di azioni e la esegue senza ri-osservare — funziona benissimo nelle demo, dove l’ambiente è quello previsto, e fallisce in produzione, dove non lo è. L’errore non è “il piano era sbagliato”: è aver scelto uno schema senza feedback trim per un ambiente che ne aveva bisogno. La diagnosi corretta non porta a scrivere piani migliori, ma a chiudere l’anello: aggiungere una ri-osservazione dopo ogni azione, o almeno dei checkpoint dove l’agente confronta lo stato reale con lo stato che il piano si aspettava.

Calibrare il training. Nel training di una rete, il learning rate gioca il ruolo del guadagno di loop. Se durante il training la loss oscilla o esplode invece di scendere, la prima mossa è abbassare il learning rate — esattamente come si abbassa $K$ nell’anello proporzionale dell’Esempio 1 quando comincia a oscillare. Warmup e learning rate scheduling non sono che modi di gestire il guadagno nel tempo: piccolo all’inizio quando il sistema è lontano dall’equilibrio, poi modulato. Anche il gradient clipping — limitare la norma del gradiente per evitare aggiornamenti enormi — è leggibile in questa chiave: è un limite deliberato sull’azione, l’equivalente del vincolo di saturazione di un attuatore, messo apposta per impedire che un guadagno momentaneamente troppo alto faccia saltare il sistema. Chi conosce il vocabolario del controllo riconosce in queste pratiche, sparse e apparentemente scollegate, lo stesso problema unico: tenere il guadagno di un anello dentro la zona stabile.

Sorvegliare i sistemi con utenti. Un sistema di raccomandazione che impara dalle interazioni chiude un anello con i suoi utenti, e quell’anello può degenerare in feedback positivo. Riconoscerlo prima che produca echo chamber è un’applicazione diretta: la contromisura — iniettare esplorazione, varietà forzata — è, in termini di questo capitolo, aggiungere un feedback negativo deliberato per contrastare un feedback positivo spontaneo.

Ancorare i sistemi che valutano sé stessi. Ogni volta che un sistema usa il proprio output come input per migliorarsi — un agente che riscrive i propri prompt, un modello giudicato da un’altra istanza di sé stesso, una pipeline che genera dati sintetici per il proprio addestramento — si sta chiudendo un anello potenzialmente positivo. La regola pratica che ne deriva è semplice e netta: un anello del genere va sempre ancorato a un segnale esterno che non dipende dal sistema stesso. Un test oggettivo, un giudizio umano, un dataset di riferimento fisso. Senza quell’ancora, il feedback positivo fa derivare il sistema verso i propri bias, e il degrado è silenzioso finché non è grave.

Dimensionare il passo di osservazione. Il ritardo di un anello agentico non è solo una proprietà data: in parte lo si sceglie, decidendo ogni quante azioni l’agente ri-osserva lo stato. Ri-osservare a ogni singola azione minimizza il ritardo ma costa token e tempo; ri-osservare ogni dieci azioni è economico ma allunga il ritardo, e con esso il rischio di lavorare su uno stato superato. È la stessa scelta che un ingegnere fa decidendo la frequenza di campionamento di un sensore. Non c’è un valore giusto in assoluto: dipende da quanto velocemente cambia l’ambiente rispetto a quanto costa guardarlo.

Il ponte verso l’AI: dove l’analogia regge e dove no

Questa sezione merita cura, perché il vocabolario feedback/feedforward si applica all’AI in modi che vanno da “stessa identica struttura” a “stessa parola, concetti scollegati”. È esattamente il tipo di terreno dove le classi di affermazione — analogia, filiazione, equivalenza — si confondono se non le si marca. Qui le marchiamo a una a una: per ogni caso si dice esplicitamente se si tratta di una struttura identica, di un’analogia didattica, di un’identità causale documentata o di una pura omonimia da disinnescare. Saltare questa distinzione è il modo più rapido per scrivere qualcosa che suona profondo ed è sbagliato.

Una premessa di metodo. Quando si dice che “il loop agentico è un anello di feedback”, non si sta affermando che un agente LLM sia un termostato, né che i teoremi del controllo si applichino a un modello di linguaggio. Si sta affermando una cosa più modesta e più solida: che la struttura del sistema — il modo in cui le sue parti sono collegate da frecce causali — è la stessa, e che quella struttura porta con sé certi comportamenti indipendentemente da cosa siano fatte le parti. È questo che rende il trasferimento legittimo: non i numeri, ma la forma. E la forma di un anello chiuso è la stessa che sia fatto di sfere d’ottone o di token.

Il loop agentico come feedback — analogia forte, strutturalmente esatta. Il ciclo observe-think-act di un agente non somiglia a un anello di feedback: è un anello di feedback, nello stesso senso tecnico in cui lo è il governor di Watt. C’è un setpoint (l’obiettivo del task), c’è un’uscita misurata (l’osservazione del risultato), c’è un errore (il gap tra risultato e obiettivo), c’è un controllore (il modello che decide la prossima azione), c’è un processo (l’ambiente, il filesystem, il codice). La struttura causale chiusa è la stessa. E poiché la struttura è la stessa, lo sono i modi di rompersi: il ritardo (un agente che ragiona su output di tool ormai superati), il guadagno eccessivo (un agente che fa edit troppo aggressivi e deve poi disfarli), l’oscillazione (un agente che applica e revoca la stessa modifica in cicli). Questo non è un parallelo poetico; è la ragione per cui il vocabolario del controllo è operativamente utile per il debugging degli agenti.

Conviene essere precisi sul perché qui parliamo di analogia forte e non di pura identità. La forma logica dell’anello — misura, confronta, correggi — è identica a quella di un sistema di controllo. Ciò che differisce è la natura del “controllore”: in un termostato è una regola fissa e semplice; in un agente è un modello di linguaggio, un oggetto enormemente più complesso, non lineare, e di cui non conosciamo la dinamica interna. I teoremi della teoria del controllo, che valgono per controllori lineari, non si applicano. Quello che si trasferisce non sono i teoremi, ma le categorie di guasto — ritardo, guadagno, segno dell’anello — e queste sono robuste, perché dipendono solo dalla forma dell’anello, non dalla natura del controllore.

RLHF come feedback — analogia. In RLHF (Reinforcement Learning from Human Feedback, il metodo standard per allineare i modelli alle preferenze umane), un valutatore umano esprime una preferenza tra due risposte del modello; quella preferenza diventa un segnale di reward; il reward retroagisce sulla policy del modello modificandone il comportamento. È un anello di feedback sul comportamento del modello, percorso su scala di training anziché di inferenza. Lo trattiamo come analogia, non identità, perché il “processo” qui non è un sistema fisico con dinamica continua ma un processo di ottimizzazione su parametri — la forma logica dell’anello regge, i dettagli matematici sono altri.

C’è anche un risvolto di rischio che il vocabolario del capitolo illumina. Il reward in RLHF è una proxy delle preferenze umane vere, non le preferenze vere. Un anello di feedback chiuso su una proxy spinge il sistema a ottimizzare la proxy, e se la proxy diverge dall’obiettivo reale — fenomeno noto come reward hacking — l’anello, pur funzionando “bene” nel senso del controllo, porta il modello dove non vogliamo. È lo stesso pericolo del sensore distorto: l’anello converge fedelmente al setpoint sbagliato. La cura non è un anello migliore, ma una proxy migliore — o un secondo anello, più lento, che ricalibra la proxy.

Il training stesso come feedback loop — analogia. La discesa del gradiente è leggibile come anello di feedback negativo. La loss misura lo scarto tra la predizione del modello e il target: è l’errore. Il gradiente indica in quale direzione muovere i pesi per ridurre quello scarto: è il segnale di correzione. L’aggiornamento dei pesi è l’azione. E il learning rate, come già detto, è il guadagno di loop, con tutto ciò che ne consegue: troppo alto e la loss oscilla o diverge, troppo basso e la convergenza è lenta. La stessa intuizione del compromesso sul guadagno, vista nell’Esempio 1 numerico, vale qui — e non è una coincidenza, perché un passo di discesa del gradiente è matematicamente un passo di correzione proporzionale all’errore, esattamente come $u = K \cdot e$.

Questa lettura spiega anche un fatto pratico del training: il learning rate warmup, la pratica di partire con un learning rate piccolo e alzarlo gradualmente. All’inizio del training il modello è lontano dall’equilibrio, gli errori sono enormi: un guadagno alto su un errore enorme produce un’azione enorme, e il sistema rischia di saltare via — è l’analogo dell’anello dell’Esempio 1 con $K$ troppo grande. Tenere il guadagno basso finché il sistema non si è avvicinato all’equilibrio, e poi alzarlo, è una strategia di gestione del guadagno nel tempo. Gli ingegneri del controllo la chiamerebbero gain scheduling, e la usano da decenni per gli stessi motivi.

La “feed-forward network” del transformer — NON un’analogia, un’omonimia da disinnescare. Questo è il chiarimento più importante del capitolo, ed è un avvertimento, non un collegamento. Dentro ogni blocco di un transformer c’è un componente chiamato “feed-forward network” (FFN, a volte detta MLP). La parola “feed-forward” qui significa una cosa sola, e diversa da tutto il resto del capitolo: significa senza cicli, cioè una rete in cui l’informazione attraversa i layer dall’ingresso all’uscita senza mai tornare indietro. È in contrapposizione alle reti ricorrenti (RNN), che hanno connessioni che si richiudono su sé stesse. “Feed-forward” nel gergo delle reti neurali è l’opposto di “ricorrente”, e basta.

Non ha nulla a che vedere con il controllo feedforward di questo capitolo. La feed-forward network di un transformer non misura disturbi, non possiede un modello del mondo da cui anticipare, non agisce prima di un errore. La coincidenza è puramente lessicale: due comunità — gli ingegneri del controllo e i ricercatori di reti neurali — hanno usato la stessa parola per due idee scollegate. Lo segnaliamo in modo esplicito perché è una trappola reale: chi conosce la control theory e poi legge di transformer (o viceversa) tende a fondere i due significati, e ne escono fraintendimenti. Tienili separati: “feed-forward” nel transformer vuol dire “aciclico”, e si ferma lì.

Per completezza, vale la pena notare che anche il training di quella stessa feed-forward network, come tutto il training, è un anello di feedback — ma il feedback è nel processo di apprendimento (la loss che retroagisce sui pesi), non nell’architettura della rete. L’architettura è aciclica; il suo addestramento è un loop. Sono due livelli diversi, e confonderli è proprio l’errore che la disambiguazione vuole evitare. La parola “feed-forward”, da sola, non basta a dire di quale dei due si parla: bisogna chiedersi se si sta descrivendo come l’informazione attraversa la rete (architettura: aciclica) o come la rete viene aggiustata (training: anello di feedback).

I feedback loop nei recommender — identità causale documentata. Un sistema di raccomandazione impara dalle interazioni degli utenti; le sue raccomandazioni determinano cosa gli utenti vedono, e quindi su cosa possono interagire; quelle interazioni rientrano come dati di addestramento. L’anello è chiuso, ed è un anello reale, non un’analogia. Quando questo anello si comporta da feedback positivo, degenera: i contenuti già popolari ottengono più esposizione, quindi più interazioni, quindi ancora più esposizione, in una spirale. Il fenomeno è studiato formalmente — Jiang et al., “Degenerate Feedback Loops in Recommender Systems” (AIES 2019) — sotto il nome di degenerate feedback loop.

Il punto sottile, e il motivo per cui questi loop sono difficili da diagnosticare, è che il sistema non vede l’anello. Dal suo punto di vista, sta semplicemente imparando da dati e migliorando una metrica — il tasso di interazione. Non si accorge che quei dati sono il prodotto delle sue stesse raccomandazioni passate. È un anello chiuso che, visto da dentro, sembra una catena: ingressi (i dati), processo (l’addestramento), uscita (le raccomandazioni). La chiusura — le raccomandazioni che determinano i dati futuri — è invisibile a chi guarda un solo ciclo. Due esiti distinti emergono: l’echo chamber (l’esposizione ripetuta a un tipo di contenuto rinforza le preferenze dell’utente in quella direzione) e la filter bubble (il sistema filtra via la varietà, restringendo progressivamente ciò che l’utente vede). La mitigazione studiata — iniettare esplorazione casuale, modellare esplicitamente l’esposizione, applicare correzioni causali — è, nei termini di questo capitolo, l’aggiunta di un feedback negativo deliberato che contrasta il feedback positivo spontaneo. L’esplorazione casuale, in particolare, funziona perché spezza l’auto-rinforzo: mostrando di tanto in tanto contenuti che il loop non avrebbe mai proposto, riapre la varietà che la spirale tenderebbe a chiudere.

Feedback positivo nei loop di auto-miglioramento — analogia con un rischio concreto. Un sistema che cerca di migliorare sé stesso — un agente che riscrive i propri prompt, un modello che genera dati per il proprio fine-tuning, un sistema che valuta il proprio output — chiude un anello su sé stesso. Se quell’anello è a feedback positivo e manca di un ancoraggio esterno (un giudizio umano, un test oggettivo, dati freschi dal mondo reale), tende a degradare: il sistema rinforza i propri bias invece di correggerli. Il caso meglio documentato è il model collapse, il degrado progressivo di un modello addestrato ricorsivamente sul proprio output. È, in fondo, lo stesso meccanismo del microfono che fischia: il segnale rientra nell’anello, viene amplificato, e satura. L’analogia con l’effetto Larsen è didattica; il rischio per i sistemi reali è concreto.

Quello che rende questo rischio insidioso è che, nel breve periodo, un anello del genere sembra funzionare: il sistema “migliora” sulle proprie metriche interne, perché le metriche e i dati provengono entrambi da lui. Solo confrontandolo con un riferimento esterno e fisso si vede la deriva. È la ragione per cui il principio operativo “ancora ogni anello di auto-valutazione a un segnale esterno” non è una precauzione opzionale: è la differenza tra un feedback positivo che si autoconvalida e un anello che resta agganciato alla realtà.

Agente feedforward contro agente feedback-driven — una scelta di disegno. L’ultimo ponte non è un’analogia ma una decisione architetturale che il vocabolario di questo capitolo rende esplicita. Un agente feedforward pianifica tutto in anticipo ed esegue il piano senza ri-osservare: è il caso limite del pattern Plan-and-Execute. È veloce, prevedibile, tracciabile — sai in anticipo cosa farà — e costa pochi token, perché non ragiona a ogni passo. Ma è fragile: appena il mondo devia dal modello che ha usato per pianificare, tutte le azioni successive sono calcolate su uno stato inesistente. Un agente feedback-driven — ReAct puro — ri-osserva a ogni passo e si adatta: robusto ai cambiamenti, ma più lento, più costoso, e a rischio di oscillazione e di loop, esattamente come l’anello dell’Esempio 1. La scelta tra i due non è ideologica: dipende da quanto è prevedibile l’ambiente e da quanto costa ri-osservare. E la soluzione che vince quasi sempre è la stessa dell’ingegneria di processo: un piano di alto livello (il contributo feedforward) più ri-osservazione e replanning a ogni passo (il feedback trim). Plan-and-Execute con replanning è, letteralmente, lo schema “feedforward più feedback trim” applicato agli agenti — la stessa struttura della caldaia dell’Esempio 4, su un dominio del tutto diverso.

Dove si rompe

I limiti di questi due schemi sono importanti quanto i meccanismi, e diversi limiti hanno cause diverse.

Conviene leggere questa sezione tenendo a mente una distinzione: alcuni limiti sono strutturali — inerenti allo schema, non eliminabili — e altri sono errori di calibrazione — evitabili con un tuning corretto. Confonderli porta a sprecare sforzo: nessuna ingegneria elimina il ritardo del feedback, ma una calibrazione attenta evita l’oscillazione. Sapere quale limite si ha davanti dice se vale la pena insistere o se serve cambiare schema.

Il feedback è sempre in ritardo, per costruzione. Non è un difetto eliminabile con più ingegneria: è strutturale. Il feedback agisce dopo aver visto l’errore, quindi un po’ di errore c’è sempre. Se il disturbo è veloce e grande, il feedback da solo non basta a tenerlo sotto controllo — il sistema scarta prima che la correzione faccia effetto. È esattamente la ragione per cui esiste il feedforward.

Il feedforward è cieco a ciò che non modella. Anche questo è strutturale. Il feedforward corregge solo i disturbi che è stato progettato per misurare e che il suo modello sa tradurre in azione. Un disturbo non previsto, o un errore nel modello, passa inosservato e non viene mai corretto, perché il feedforward per definizione non guarda il risultato. Un feedforward puro accumula silenziosamente l’errore residuo. È la ragione per cui il feedforward non si usa quasi mai da solo.

Il feedback negativo con ritardo può diventare positivo. Lo abbiamo visto nella meccanica: quando il ritardo dell’anello è grande rispetto alla dinamica del sistema, la correzione arriva sfasata e rinforza l’errore invece di opporvisi. Un anello pensato come stabilizzante diventa oscillatorio o esplosivo. Questo è il fraintendimento più costoso: credere che “feedback negativo” sia sinonimo di “stabile”. Non lo è. La stabilità dipende dalla combinazione di guadagno e ritardo, non dal solo segno dell’anello.

Il guadagno alto non è gratis. È istintivo pensare che un anello che corregge più forte sia un anello migliore. Non lo è. Più guadagno significa errore a regime più piccolo, sì, ma anche oscillazioni più violente e margine di stabilità più sottile. Ogni anello reale vive in un compromesso tra prontezza e stabilità, e spingere il guadagno oltre un certo punto lo rovescia nell’instabilità — come l’anello dell’Esempio 1 che passa da convergente a oscillante quando $K$ supera una soglia.

Il feedback positivo non si “spegne” da solo. Per sua natura un anello positivo non cerca un equilibrio: o satura contro un limite fisico, o cresce finché qualcosa si rompe. Affidarsi al fatto che “prima o poi si fermerà” è pericoloso: si ferma solo se c’è un limite o un feedback negativo che subentra. Nei sistemi progettati, quel limite va messo apposta.

Misurare male l’uscita rovina l’anello. Tutto l’anello di feedback poggia sulla misura di $y$. Se il sensore è rumoroso, il controllore insegue il rumore e agita il sistema senza motivo. Se il sensore è distorto, il sistema converge al setpoint sbagliato — quello che il sensore crede, non quello vero. È il legame diretto con l’osservabilità: se l’uscita non porta informazione affidabile sullo stato, non c’è feedback che tenga.

Il feedforward su un modello sbagliato non solo non aiuta: può peggiorare. C’è un caso peggiore della cecità. Se il modello del feedforward sbaglia segno — crede che un disturbo spinga in una direzione mentre spinge nell’altra — la sua azione “correttiva” si somma al disturbo invece di cancellarlo. In quel caso il feedforward raddoppia il problema, e tocca al feedback non solo riassorbire il disturbo originale ma anche disfare il danno del feedforward. Un feedforward va aggiunto solo quando il modello è affidabile; un modello dubbio è meglio non usarlo affatto.

Il feedforward può saturare l’attuatore. Quando il feedforward anticipa un disturbo grande, chiede all’attuatore un’azione grande, tutta insieme. Se l’attuatore ha un limite — una valvola può aprirsi al massimo del 100%, un bruciatore ha una potenza massima — l’azione richiesta può superarlo. A quel punto il feedforward “ha calcolato giusto” ma il sistema non può eseguire, e la compensazione è solo parziale. È un limite che il calcolo ideale ignora e che la realtà impone sempre.

Combinare i due non li somma magicamente. Mettere insieme feedforward e feedback non garantisce che il risultato sia migliore di entrambi: se i due rami sono mal coordinati — per esempio il feedback reagisce anche all’effetto transitorio del feedforward, scambiandolo per un errore — possono interferire. Lo schema “feedforward più feedback trim” funziona perché il feedforward porta l’errore vicino a zero prima che il feedback debba intervenire; se i tempi sono mal calibrati, i due si pestano i piedi.

Il filo che lega tutti questi modi di rompersi è uno solo, e vale la pena renderlo esplicito. Feedback e feedforward non sono ricette che funzionano da sole: sono strategie i cui parametri — il guadagno, il ritardo, la qualità del modello, i limiti dell’attuatore — vanno conosciuti e calibrati. Un anello di feedback applicato senza guardare il suo guadagno e il suo ritardo è pericoloso quanto utile. Un feedforward applicato senza valutare la qualità del suo modello può peggiorare le cose. La parte difficile del controllo non è scegliere “feedback o feedforward”: è calibrare. Questo capitolo dà il vocabolario per sapere cosa calibrare; il come — i margini di stabilità, i metodi di tuning — è materia della Parte XI.

L’anello sbagliato chiuso sulla metrica sbagliata. Un feedback loop ottimizza ciò che misura. Se ciò che misuri è una proxy imperfetta di ciò che vuoi davvero, l’anello la spinge fino a scollarla dall’obiettivo reale. È il meccanismo della legge di Goodhart, trattato in goodhart-law (in preparazione): chiudere un anello di feedback su una metrica è potente, e per questo pericoloso se la metrica è quella sbagliata.

Confusioni tipiche da disinnescare

Oltre ai limiti strutturali, ci sono alcuni fraintendimenti ricorrenti che vale la pena nominare esplicitamente, perché ricompaiono ogni volta che si parla di feedback con chi lo incontra per la prima volta. Non sono errori di chi non ha studiato: sono trappole linguistiche, costruite dal fatto che parole come “feedback”, “positivo”, “feed-forward” hanno un significato comune diverso da quello tecnico. Smontarle una a una è parte del lavoro di chi vuole usare questo vocabolario senza farsi tradire.

Il primo, e il più diffuso: “feedback positivo è buono, feedback negativo è cattivo”. È falso, ed è anche invertito. La fonte della confusione è l’italiano e l’inglese di tutti i giorni, dove “feedback positivo” significa un complimento e “feedback negativo” una critica. Nella teoria dei sistemi i due aggettivi indicano il segno dell’anello, non un giudizio. Il feedback negativo è quasi sempre quello che vuoi — stabilizza, riporta sul bersaglio. Il feedback positivo è quasi sempre quello che temi — amplifica, destabilizza. Se devi ricordarne uno solo: nei sistemi che funzionano bene, l’anello dominante è negativo.

Il secondo: “il feedback negativo garantisce la stabilità”. Falso. Il feedback negativo tende a stabilizzare, ma con ritardo e guadagno alto produce oscillazioni e divergenza. Il segno dell’anello è una condizione necessaria ma non sufficiente per la stabilità: contano anche guadagno e ritardo.

Il terzo: “il feedforward è meglio del feedback perché agisce prima”. Falso come affermazione assoluta. Il feedforward agisce prima ma solo sui disturbi che ha modellato e misurato; è cieco a tutto il resto. Non è “meglio” o “peggio”: è uno strumento con un dominio di applicabilità diverso, e fuori da quel dominio non è semplicemente disponibile.

Il quarto, già anticipato e qui ribadito perché è il più insidioso per chi viene dall’AI: “la feed-forward network del transformer ha a che fare con il controllo feedforward”. Falso. Stessa parola, due significati scollegati. Nel transformer “feed-forward” vuol dire solo “senza cicli”. La sezione sul ponte verso l’AI lo tratta per esteso.

Il quinto: “in un loop posso individuare la causa”. Dentro un anello di feedback la domanda “cosa causa cosa” non ha la risposta lineare che ci si aspetta: ogni variabile è causa ed effetto di sé stessa, con un ritardo. Cercare “la causa prima” dentro un anello porta a diagnosi sbagliate; va capito il giro, non un singolo nesso.

Il sesto, e ultimo, più sottile: “se aggiungo abbastanza feedback, qualunque sistema diventa stabile”. Non è così. Ci sono sistemi che il feedback può solo migliorare entro un limite, e configurazioni in cui aumentare l’azione correttiva, oltre una certa soglia, peggiora le cose anziché migliorarle — lo si è visto numericamente nell’Esempio 1. Il feedback è uno strumento potente, ma non onnipotente: ci sono dinamiche, ritardi e vincoli sugli attuatori che nessuna quantità di retroazione cancella. Sapere quando un problema di controllo è risolvibile in linea di principio è esattamente la materia del capitolo su osservabilità e controllabilità: il feedback è la strategia, ma la fattibilità della strategia è una proprietà del sistema, non una scelta di chi lo regola.

Una chiusura che lega questi sei punti. Tutti e sei hanno la stessa radice: una parola o un’intuizione del senso comune che non coincide con la nozione tecnica. “Positivo” non vuol dire “buono”; “negativo” non garantisce “stabile”; “feed-forward” nel transformer non è feedforward; “agire prima” non è sempre meglio; “la causa” non esiste in un anello; “più feedback” non è sempre più stabilità. Imparare il vocabolario di questo capitolo è, in buona parte, imparare a non lasciarsi guidare dall’eco delle parole comuni quando si ragiona su un sistema. È un piccolo costo cognitivo, e ripaga ogni volta che un sistema si comporta in un modo che il senso comune non sa spiegare.

Collegamenti

• Sistema, ambiente, confine, stato: il vocabolario di base — feedback significa far tornare l’uscita del sistema dentro il suo ingresso: presuppone i concetti di confine, ingresso e uscita definiti lì.
• Stato, transizione, traiettoria — un anello di feedback è una dinamica sullo spazio di stato; oscillazione e divergenza si leggono come tipi di traiettoria.
• Equilibrio, stabilità, attrattori — il feedback negativo è il meccanismo che crea e difende un equilibrio stabile; il feedback positivo lo distrugge. Guadagno e ritardo si legano direttamente alla stabilità.
• Osservabilità e controllabilità: cosa posso misurare, cosa posso governare — un anello di feedback può chiudersi solo se l’uscita è osservabile e il sistema è controllabile: senza le due, non c’è retroazione possibile.
• cibernetica-definizione (in preparazione) — Wiener fonda la cibernetica proprio sul feedback come meccanismo che produce comportamento orientato a uno scopo; è il seguito naturale di questo capitolo.
• feedback-loop (in preparazione) — il capitolo della Parte X riprende setpoint, errore e segno del loop con il dettaglio cibernetico completo.
• pid-control-intuizione (in preparazione) — il controllore PID è la forma matura del feedback, con i termini proporzionale, integrale e derivativo; questo capitolo ne usa solo il proporzionale.
• react (in preparazione) — ReAct è il loop di feedback agentico per eccellenza; questo capitolo ne dà la lettura sistemica.
• rlhf-ppo (in preparazione) — il reward umano come segnale di feedback che retroagisce sulla policy del modello.
• discesa-gradiente (in preparazione) — il training come anello di feedback, con il learning rate nel ruolo del guadagno di loop.
• feed-forward (in preparazione) — la feed-forward network del transformer: l’altro uso, scollegato, della parola “feedforward”, da non confondere con questo capitolo.
• goodhart-law (in preparazione) — un feedback loop chiuso su una metrica proxy degenera: la metrica diventa target e si scolla dall’obiettivo reale.

Per andare oltre

Le fonti che seguono coprono i due versanti del capitolo: i lavori storici che hanno fondato il concetto di feedback, e i lavori recenti che mostrano gli stessi anelli operare nei sistemi AI.

• James Clerk Maxwell, “On Governors” (Proceedings of the Royal Society of London, 1868). Il paper fondante: la prima analisi matematica di un sistema a retroazione e della sua stabilità. Disponibile in PDF presso la Clerk Maxwell Foundation.
• Norbert Wiener, Cybernetics: Or Control and Communication in the Animal and the Machine (MIT Press, 1948). Il libro che mette feedback, controllo e informazione sotto un unico tetto concettuale e introduce l’idea di comportamento teleologico generato da un meccanismo.
• “Harold Black and the negative-feedback amplifier” (IEEE Control Systems Magazine, 1993). Ricostruzione storica dell’invenzione della retroazione negativa ai Bell Labs, dallo schizzo sulla pagina del New York Times al brevetto del 1937.
• Hao Jiang et al., “Degenerate Feedback Loops in Recommender Systems” (AIES 2019, arXiv:1902.10730). Analisi formale di come un anello chiuso tra raccomandazioni e interazioni degenera in echo chamber e filter bubble, e di come l’esplorazione casuale lo mitiga.
• Shunyu Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models” (arXiv:2210.03629, 2022). Il pattern observe-think-act per agenti LLM, leggibile come anello di feedback negativo applicato al ragionamento.