Self-correction negli agenti: cosa funziona, cosa no, perché

Il capitolo precedente ha mostrato che i modelli di linguaggio possiedono calibration parziale ma scarso control metacognitivo autonomo. Qui esaminiamo i pattern ingegneristici con cui, dal 2022 in avanti, si è cercato di supplire al monitoring debole — e dichiariamo onestamente, sulla base di tre paper convergenti del 2023, dove questi pattern aiutano davvero e dove non aiutano affatto.

Un agent di coding lavora; un LLM tenta di ripensarsi

Scena prima. Un agent di coding riceve la richiesta “fixa il bug di parsing nel modulo csv_loader.py per cui le righe con virgolette annidate vengono troncate”. L’agent legge il file, scrive una toppa, lancia la suite di test. Tre test falliscono. L’agent legge gli errori — un IndexError al test 12, un mismatch di stringa al test 17 — modifica la regex, rilancia. Due test ancora rossi. Modifica la gestione dello escape. Tutti verdi. L’agent committa. Il loop ha funzionato. Self-correction al lavoro.

Scena seconda. Un LLM riceve un problema di logica deduttiva: “se tutti gli A sono B, e qualche B è C, segue che qualche A è C?” Il modello risponde “sì, segue”. L’utente dice “sei sicuro?”. Il modello, senza alcuna evidenza nuova, ribalta: “in realtà no, è una fallacia del medio non distribuito”. Era stato corretto prima, sbagliato adesso. Self-correction al lavoro?

Le due scene rappresentano i due poli di questo capitolo. Nella prima, il loop di critique è chiuso da un segnale esterno verificabile — il test suite. Nella seconda, il loop è chiuso solo dal modello stesso, in conversazione con un utente, e il risultato è un peggioramento sistematico documentato in letteratura come sycophancy. La domanda operativa è: quando una pipeline che ha “self-” nel nome aiuta davvero, e quando produce solo l’illusione di farlo?

Tre paper convergenti del 2023, che tratteremo in dettaglio nella sezione “La critica fondamentale”, hanno risposto in modo netto: senza un segnale esterno — un verifier model addestrato, un tool che esegue, un oracle, una gold label — la self-correction tipicamente non migliora la qualità. In molti casi la peggiora. La “self-” del nome è ingannevole: ciò che chiamiamo self-correction è quasi sempre, sotto la cofana, grounded correction, in cui qualche pezzo della verità sta fuori dal modello.

Questo capitolo è una mappa onesta dei pattern, dei loro successi e dei loro limiti. È un ponte fra la metacognizione umana — il vocabolario monitoring/control di Thomas Nelson e Louis Narens introdotto in meta-cognizione — e l’ingegneria delle pipeline LLM. Lo dichiariamo subito: il ponte è un’analogia funzionale, non una filiazione storica. Self-Refine non discende da Flavell; Reflexion non rinomina meta-d’; Constitutional AI non implementa Nelson-Narens. I pattern ingegneristici descritti qui hanno una genealogia indipendente — search heuristics, ensemble methods, formal verification, RL with auxiliary critic. La struttura monitoring/control fornisce una grammatica utile per descriverli, niente di più.

Perché un ponte qui

Il capitolo precedente ha smontato il vocabolario psicologico della metacognizione: il framework Nelson-Narens 1990, la calibration come correlazione fra confidence e correctness, la misura meta-d’ di Brian Maniscalco e Hakwan Lau, l’effetto Kruger-Dunning. Ha chiuso con una nota: gli LLM contemporanei mostrano calibration parziale (Saurav Kadavath e colleghi presso Anthropic, “Language Models (Mostly) Know What They Know”, 2022) ma scarso control metacognitivo autonomo. La sycophancy — il modello che cambia idea sotto pressione utente — è descritta in chiusura come una forma di anti-metacognizione: il monitoring si adegua non all’evidenza ma al segnale sociale.

Da quel punto, la naturale domanda operativa: dato che il monitoring autonomo è debole, cosa si può aggiungere intorno al modello per chiudere il loop? La risposta dell’ingegneria, dal 2022 in avanti, è una famiglia di pipeline che vanno sotto il nome ombrello di self-correction: Self-Refine, Reflexion, Self-Consistency, Constitutional AI, Multi-Agent Debate, Generator-Verifier, Process Reward Models, CRITIC, Tree of Thoughts. Ognuna è un punto specifico in uno spazio di scelte: chi è il critic, c’è un verifier esterno, come si aggrega, quando si ferma il loop.

Il capitolo è ponte in due direzioni. Verso l’indietro: collega un programma di ricerca della psicologia cognitiva (cinquant’anni di lavoro su monitoring/control) ai pattern dell’ingegneria 2022-2026. Verso l’avanti: prepara il terreno per i capitoli specifici di Parte XII (reflexion, self-consistency, prm-vs-orm, search-reasoning) e Parte XVI (reflexion-agenti), dove ogni pattern verrà esaminato in profondità tecnica. Qui ci limitiamo alla mappa.

Una nota di registro: questo è un capitolo operativo, non storico. Il presentismo è legittimo — paper datati 2022-2025, modelli specifici, benchmark con nome — perché il fenomeno è del presente. Ma manteniamo onestà sulle classi di affermazioni, marcando analogia, filiazione ed equivalenza dove rilevante.

Il disclaimer iniziale: cosa il monitoring autonomo NON fa

Prima della tassonomia, fissiamo cosa abbiamo stabilito nel capitolo precedente per non doverlo ripetere.

Un LLM moderno (Claude, GPT-4o, Gemini, DeepSeek) addestrato con RLHF e instruction tuning mostra calibration parziale: la probabilità soggettiva (confidence verbale o probability estimate) correla positivamente con la correttezza. Sotto certi setup la correlazione è alta — ad esempio in MMLU multi-choice, Kadavath 2022 misura ECE (expected calibration error) nell’ordine del 5-10% per modelli grandi su domande con formato fisso. Sotto altri setup la calibration crolla — su domande open-ended, su task fuori distribuzione, dopo RLHF aggressivo che spinge il modello verso confidence uniformemente alta.

Quello che gli LLM non mostrano in modo robusto, sotto pressione di ablation, è il control metacognitivo autonomo. Tre indicatori:

Primo, detection di errori nei propri output: Tyen e colleghi 2024, in “LLMs cannot find reasoning errors, but can correct them given the error location” (arXiv:2311.08516), mostrano che dato un reasoning con un errore al passo k, il modello tipicamente non identifica k. Se invece riceve “c’è un errore al passo k, correggilo”, lo corregge bene.

Secondo, stabilità sotto pressione: Sharma e colleghi presso Anthropic 2023, in “Towards Understanding Sycophancy in Language Models” (arXiv:2310.13548), documentano che modelli RLHF cambiano risposta quando l’utente esprime disaccordo, anche se la risposta originale era corretta e l’utente ha torto. La sycophancy è prevedibile: emerge dalla preference data dove i giudici umani premiano risposte che concordano con loro.

Terzo, abstention calibrata: i modelli non rispondono “non lo so” con la frequenza che la loro distribuzione di confidence suggerirebbe. Tendono a produrre una risposta confident anche quando il monitoring (probability estimate) suggerirebbe di astenersi. Questo è documentato sotto il nome di hallucination nella letteratura applicata e come deviazione dalla calibration di astensione nella letteratura più formale.

Conclusione: il loop monitoring → control, che nei sistemi cognitivi umani descritto da Nelson-Narens regola lo studio, l’astensione, la riformulazione, è debole o assente se affidato al modello solo. La self-correction ingegneristica nasce da qui: si aggiungono componenti esterni — un secondo modello, un tool, un’orchestrazione, una constitution — per chiudere il loop dall’esterno.

La tassonomia dei pattern

Esaminiamo nove pattern, in ordine di complessità crescente. Per ciascuno: l’idea di base, il paper di riferimento, la natura del segnale di critique, e la classe di task per cui ha track record solido.

flowchart TB
    R["LLM self-correction patterns"]
    R --> B1["Same-model critique"]
    R --> B2["Sampling + aggregation"]
    R --> B3["Separate verifier"]
    R --> B4["Multi-agent"]
    R --> B5["Tool-grounded"]

    B1 --> B1a["Self-Refine (Madaan 2023)"]
    B1 --> B1b["Reflexion (Shinn 2023)"]
    B1 --> B1c["Constitutional AI (Bai 2022)"]

    B2 --> B2a["Self-Consistency (Wang 2022)"]
    B2 --> B2b["Tree of Thoughts (Yao 2023)"]

    B3 --> B3a["Generator-Verifier (Cobbe 2021)"]
    B3 --> B3b["Process Reward Models (Lightman 2023)"]

    B4 --> B4a["Multi-Agent Debate (Du 2023)"]
    B4 --> B4b["AI Safety via Debate (Irving 2018)"]

    B5 --> B5a["CRITIC (Gou 2023)"]
    B5 --> B5b["AlphaProof + Lean (DeepMind 2024)"]

    classDef noext fill:#fee,stroke:#000
    classDef ext fill:#efe,stroke:#000
    class B1,B1a,B1b,B1c,B2,B2a,B2b noext
    class B3,B3a,B3b,B4,B4a,B4b,B5,B5a,B5b ext

Figura 1 — Self-correction patterns taxonomy: tree with branches “Same-model critique” (Self-Refine, Reflexion, Constitutional AI), “Sampling + aggregation” (Self-Consistency, Tree of Thoughts), “Separate verifier” (Generator-Verifier, Process Reward Models), “Multi-agent” (Debate), “Tool-grounded” (CRITIC, AlphaProof+Lean)

Self-Refine (Madaan et al. 2023)

Aman Madaan e colleghi presso CMU, in “Self-Refine: Iterative Refinement with Self-Feedback” (arXiv:2303.17651, NeurIPS 2023), formalizzano il pattern minimale: lo stesso LLM gioca tre ruoli in sequenza, in tre prompt separati. Primo prompt: genera output y per input x. Secondo prompt: data l’output y, genera feedback f secondo criteri specificati nel prompt di critique (es. “valuta clarity, correctness, style”). Terzo prompt: dato y e f, genera y’ raffinato. Loop fino a convergenza, budget esaurito, o feedback dichiara “nulla da migliorare”.

Madaan riporta gain su sette task: dialog response generation, code optimization, code readability improvement, math reasoning, sentiment reversal, acronym generation, constrained generation. Gain di 5-40 punti percentuali a seconda del task e del modello. Ma — punto cruciale — i task dove Self-Refine vince sono prevalentemente quelli di style refinement: il criterio di qualità è espressivo (il modello “capisce” cosa rende buono un acronimo) e non richiede ground-truth esterna. Sui task di reasoning matematico, il guadagno è marginale e non sopravvive all’analisi più severa di Huang 2023.

Classe di affermazione: questo è un pattern ingegneristico utile, non è un’implementazione di metacognizione. L’analogia con il loop monitoring/control è descrittiva — il critic gioca il ruolo di monitoring, il refiner di control — ma la meccanica è generazione su prompt diverso, non introspezione di stati interni.

Reflexion (Shinn et al. 2023)

Noah Shinn e colleghi a Northeastern University, in “Reflexion: Language Agents with Verbal Reinforcement Learning” (arXiv:2303.11366, NeurIPS 2023), portano l’idea nel setting agentico. Un agent risolve task in un environment (ALFWorld per task domestici simulati, HotPotQA per QA multi-hop, HumanEval per coding). L’environment dà segnale binario: success o failure. In caso di failure, l’agent genera una “reflection” verbale — un paragrafo che diagnostica cosa è andato storto. La reflection viene appesa alla memoria episodica e diventa contesto per il prossimo trial.

Il nome “verbal reinforcement learning” è retorico: non c’è gradient update sui parametri, c’è solo prompt augmentation. Ma il pattern funziona, purché il signal di failure venga dal task. Su HumanEval (programmazione) il signal sono i test; su HotPotQA è la gold answer; su ALFWorld è il completamento del goal nell’environment. Senza quel signal, Reflexion degenera in Self-Refine senza ground-truth — e Self-Refine senza ground-truth, su task di reasoning, non funziona.

Classe di affermazione: equivalenza pericolosa da evitare. “Reflexion = metacognizione” è scivolamento. Reflexion è un pattern di prompt engineering con memoria episodica e oracle esterno. Ricorda — analogia, non filiazione — il loop monitoring (oracle dice failure) → control (modifica strategia) di Nelson-Narens, ma il monitoring è esterno al modello, non interno.

Self-Consistency (Wang et al. 2022)

Xuezhi Wang e colleghi a Google Brain, in “Self-Consistency Improves Chain of Thought Reasoning in Language Models” (arXiv:2203.11171, ICLR 2023), propongono una variazione che non è critique e non è raffinamento: è sampling multiplo con voting. Genera N reasoning traces con temperature > 0, estrai la risposta finale di ciascuna, vota per maggioranza. Logica: errori di reasoning sono per assunzione idiosincratici — ogni catena di errori prende una direzione diversa — la risposta corretta è un attrattore comune. Funziona su task con risposta finale discreta (math word problems, multi-choice QA).

Sul GSM8K dataset (Karl Cobbe et al. 2021, math word problems con 8.5k esempi), Wang riporta che self-consistency con N=40 sample porta GPT-3 (175B) da 56% a 74% di accuracy. Costo: 40x. Self-consistency è il pattern senza critique — non c’è un componente che giudica le risposte, c’è solo aggregazione statistica.

Classe di affermazione: analogia con il monitoring metacognitivo è remota. Self-consistency assomiglia più a un ensemble di Bayes che a metacognizione. Lo includiamo qui perché è spesso menzionato nello stesso elenco e perché empiricamente funziona su task simili.

Constitutional AI (Bai et al. 2022)

Yuntao Bai e colleghi presso Anthropic, in “Constitutional AI: Harmlessness from AI Feedback” (arXiv:2212.08073, 2022), introducono la pipeline a due fasi che è diventata un pilastro del training di Claude. Fase 1 (supervised): il modello genera risposta a prompt potenzialmente harmful, poi critica la propria risposta secondo una constitution — una lista di principi espliciti (“la risposta non deve incoraggiare violenza”, “deve rispettare l’autonomia”), poi riscrive secondo la critica. Fase 2 (RLAIF): il modello giudica coppie di risposte secondo la constitution, generando preference data per RL training senza human labelers.

L’innovazione non è il loop di critique in sé — è l’idea che il critic possa essere lo stesso modello, con la constitution come prompt sistematico. È self-critique disciplinata da principi espliciti. Funziona perché i principi della constitution sono operazionalizzabili e perché il modello ha capacità di riconoscere quando un output viola un principio anche se non sa generare un output che lo rispetti al primo colpo.

Classe di affermazione: analogia funzionale con metacognitive control guidato da knowledge of cognition (i principi sono knowledge dichiarativa che il meta-level applica all’object-level). NON è filiazione: la constitution non discende da Flavell o Brown, discende dalla tradizione di alignment via human feedback (Christiano et al. 2017) ridotta in dipendenza umana.

Multi-Agent Debate (Du et al. 2023)

Yilun Du e colleghi a MIT, in “Improving Factuality and Reasoning in Language Models through Multiagent Debate” (arXiv:2305.14325, 2023), propongono un setup in cui multipli istanze del modello (3-5) generano risposte indipendenti, poi vedono le risposte degli altri e iterano per K round. La maggioranza converge su una risposta finale. L’idea originaria è di Geoffrey Irving, Paul Christiano e Dario Amodei (allora a OpenAI), in “AI safety via debate” (arXiv:1805.00899, 2018): debate adversarial come meccanismo che, sotto certi assumption, fa emergere risposte vere — il falso ha più punti deboli del vero quando attaccato.

In pratica, Du 2023 trova gain modesti su MMLU, GSM8K, e benchmarks di fattualità. Il debate aiuta quando le opinioni divergono naturalmente; se tutti gli agenti convergono subito (perché hanno gli stessi bias), debate non aggiunge informazione. Variazioni: agenti con prompt diversi (advocate vs skeptic), agenti con modelli diversi (GPT vs Claude), giudice esterno che decide.

Classe di affermazione: filiazione documentata da debate game-theoretic (Irving 2018) e da deliberation studies in scienze sociali; analogia con metacognitive monitoring distribuito su un gruppo. Non è equivalente a “meta-d’ di gruppo”.

Generator-Verifier (Cobbe et al. 2021)

Karl Cobbe e colleghi a OpenAI, in “Training Verifiers to Solve Math Word Problems” (arXiv:2110.14168), introducono il pattern in cui generator e verifier sono modelli separati. Il generator genera N candidate solutions per il problema, il verifier (modello addestrato su esempi etichettati corretto/sbagliato) ranka le candidate, si sceglie la top-1. È best-of-N con verifier appreso.

Cobbe addestra il verifier come classificatore binario su soluzioni a math problems (GSM8K), usando il signal “la risposta finale è quella corretta?” come label. Risultato: GPT-3 (175B) generator + un verifier (6B) raggiunge 55-60% su GSM8K, contro 33% del generator solo.

Classe di affermazione: questo è un pattern di search with learned heuristic, filiazione diretta da AlphaGo (policy + value network) e da reinforcement learning con auxiliary critic. La struttura è isomorfa al monitoring/control di Nelson-Narens — il verifier è il monitoring esterno, la scelta del top-1 è il control — ma la genealogia è ML, non psicologia cognitiva.

Process Reward Models (Lightman et al. 2023)

Hunter Lightman e colleghi a OpenAI, in “Let’s Verify Step by Step” (arXiv:2305.20050), estendono il pattern di Cobbe a verificare step intermedi del reasoning, non solo la risposta finale. Outcome Reward Model (ORM): label sulla risposta finale. Process Reward Model (PRM): label su ogni step di chain-of-thought. Lightman annota PRM800K — 800.000 step labels prodotti da annotatori umani sul dataset MATH — e mostra che PRM-guided search batte ORM-guided search.

Il punto chiave operativo: PRM permette di fare beam search sul reasoning, scartando rami con step sbagliati prima che la catena sia completa. L’efficienza è molto superiore a generate-N-then-rank.

Costo: il dataset PRM800K richiede annotatori umani esperti di matematica. Frontier 2024-2025: PRM auto-generati (Math-Shepherd di Wang et al. 2024, OmegaPRM di DeepMind) usano roll-out Monte Carlo per assegnare label automaticamente — se da uno step partono molti rollout corretti, lo step è “buono”; se la maggioranza fallisce, è “cattivo”. Il salto al training: in DeepSeek-R1 (DeepSeek-AI 2025), il verifier signal viene usato come reward in RL training (“RLVR” — RL with Verifiable Rewards), trasformando il loop generator/verifier da pattern di inference a pattern di training.

Classe di affermazione: filiazione diretta da Cobbe 2021 e dalla tradizione di credit assignment in RL. L’analogia con monitoring metacognitivo step-by-step è suggestiva — il PRM è un “monitor” che valuta sub-step in tempo reale, simile a come un esperto monitora il proprio reasoning durante un problema — ma di nuovo, è analogia, non filiazione.

CRITIC (Gou et al. 2023)

Zhibin Gou e colleghi a Microsoft Research, in “CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing” (arXiv:2305.11738, 2023), propongono il pattern più ingegneristicamente onesto: la self-critique del modello è grounded da tool. Il modello produce output, poi (a) interroga tool (calculator, code interpreter, search engine, fact-checker) per verificare claim specifici nell’output, (b) sulla base dei risultati dei tool genera la critique, (c) raffina.

Il segnale di critique è in parte interno (il modello formula le query) e in parte esterno (i tool danno la verità). È il pattern dominante negli agenti di coding moderni: write code → run → see error → fix.

Classe di affermazione: pattern engineering, filiazione da tool use (ReAct di Shunyu Yao et al. 2022). L’analogia con metacognizione è la più solida di tutti i pattern in questa lista, perché c’è davvero un loop monitoring (tool-grounded) → control (raffinamento). Ma il monitoring non è interno al modello; è esternalizzato sul tool.

Tree of Thoughts (Yao et al. 2023)

Shunyu Yao e colleghi a Princeton, in “Tree of Thoughts: Deliberate Problem Solving with Large Language Models” (arXiv:2305.10601, NeurIPS 2023), propongono di esplorare un albero di ragionamento. A ogni nodo, il modello propone thoughts successivi, valuta i thoughts (con un valutatore che è ancora il modello, oppure un verifier separato), pota e cerca. È self-consistency + branching + evaluation.

Yao testa su Game of 24 (problemi aritmetici), creative writing, mini-crosswords. Sul Game of 24, ToT con GPT-4 raggiunge 74% di success rate contro il 4% di CoT puro. Costo: ordine di magnitudine in più token.

Classe di affermazione: filiazione da search algorithms (BFS/DFS, MCTS). L’evaluator del modello stesso eredita gli stessi limiti di Self-Refine senza ground-truth — Huang 2023 mostra che ToT con self-evaluator non sempre supera self-consistency su task hard. ToT con verifier esterno è quello che davvero funziona.

La critica fondamentale: senza external signal, niente

Tre paper convergenti, pubblicati fra ottobre 2023 e gennaio 2024, costituiscono la critica empirica più solida al concetto di self-correction puro. Vanno letti insieme.

flowchart TB
    R["LLM self-correction patterns"]
    R --> B1["Same-model critique"]
    R --> B2["Sampling + aggregation"]
    R --> B3["Separate verifier"]
    R --> B4["Multi-agent"]
    R --> B5["Tool-grounded"]

    B1 --> B1a["Self-Refine (Madaan 2023)"]
    B1 --> B1b["Reflexion (Shinn 2023)"]
    B1 --> B1c["Constitutional AI (Bai 2022)"]

    B2 --> B2a["Self-Consistency (Wang 2022)"]
    B2 --> B2b["Tree of Thoughts (Yao 2023)"]

    B3 --> B3a["Generator-Verifier (Cobbe 2021)"]
    B3 --> B3b["Process Reward Models (Lightman 2023)"]

    B4 --> B4a["Multi-Agent Debate (Du 2023)"]
    B4 --> B4b["AI Safety via Debate (Irving 2018)"]

    B5 --> B5a["CRITIC (Gou 2023)"]
    B5 --> B5b["AlphaProof + Lean (DeepMind 2024)"]

    classDef noext fill:#fee,stroke:#000
    classDef ext fill:#efe,stroke:#000
    class B1,B1a,B1b,B1c,B2,B2a,B2b noext
    class B3,B3a,B3b,B4,B4a,B4b,B5,B5a,B5b ext

Figura 1 — When self-correction works decision flowchart: external verifier yes/no, task open-ended yes/no, paths lead to “likely improves” or “Huang 2023 says no” or “may polish style”

Huang et al. 2023, “Large Language Models Cannot Self-Correct Reasoning Yet” (arXiv:2310.01798, ICLR 2024). Jie Huang e colleghi a Google DeepMind eseguono una meta-analisi degli esperimenti di self-correction in letteratura e una nuova batteria di esperimenti controllati. Su GSM8K, CommonSenseQA, HotPotQA, e altri reasoning benchmarks, l’iterative self-correction senza oracle o tool verifier tipicamente NON migliora la accuracy. In molti casi peggiora: il modello, partendo da una risposta corretta, viene “convinto” dal proprio prompt di critique a cambiarla in una sbagliata. Conclusione netta: i gain riportati in molti paper precedenti dipendono da setup con oracle nascosti — gold answer usata implicitamente per fermare il loop, scelta della risposta migliore fra le iterazioni con un metric esterno, dataset con label disponibili. Senza quegli oracle, niente miglioramento.

Stechly, Marquez, Kambhampati 2023, “GPT-4 Doesn’t Know It’s Wrong” (arXiv:2310.12397). Kaya Stechly, Matthew Marquez e Subbarao Kambhampati ad Arizona State University, su task formali — graph coloring, blocksworld planning — mostrano che GPT-4 in self-correction loop spesso “corregge” risposte già corrette. Il monitoring autonomo è inaffidabile su task con verità formale. Quando confrontato con un verifier formale (un solver SAT per il graph coloring), il loop guidato dal verifier migliora; il loop in self-critique pura no.

Tyen et al. 2024, “LLMs cannot find reasoning errors, but can correct them given the error location” (arXiv:2311.08516). Gladys Tyen e colleghi a Google decompongono il problema: la correction non è il bottleneck; la detection lo è. Esperimento: dato un reasoning con un errore al passo k, chiedere “trova l’errore” → fallimento frequente; dire “c’è un errore al passo k, correggilo” → successo frequente. Il control metacognitivo (la riformulazione) funziona; il monitoring metacognitivo (il sentimento di “qui c’è qualcosa che non va”) è quello che manca.

La conseguenza concreta per chi progetta sistemi:

Se hai un verifier esterno (test, solver, oracle), self-correction è probabilmente utile. La pipeline “genera → verifica → corregi” è il pattern dominante negli agenti di coding e math che funzionano.
Se non hai un verifier esterno, self-correction su reasoning è un costo aggiuntivo senza beneficio prevedibile, e talvolta una regressione.
Per task open-ended (style polishing, creative writing), Self-Refine può aiutare per ragioni diverse — non perché il modello “trova errori” ma perché iterazioni multiple esplorano lo spazio degli output con prompt diversi.

Quando funziona: i casi paradigmatici

I pattern di self-correction hanno track record solido in domini con tre caratteristiche:

Caratteristica 1: il segnale di correttezza è oggettivo e verificabile. Code che compila e passa i test. Math con verifier formale. Theorem proving con un proof assistant. Multi-step retrieval con citation che esistono nei sorgenti.

Caratteristica 2: il segnale è economicamente accessibile. Eseguire un test costa pochi millisecondi; chiamare un solver SAT costa secondi; consultare Lean costa centesimi. Quando il segnale costa euro e ore (revisione di un saggio da parte di un esperto), la pipeline non scala.

Caratteristica 3: lo spazio di correzione è strutturato. Sapere che il test 12 fallisce con IndexError at line 47 localizza l’errore meglio che sapere “la tua risposta è sbagliata”. I tool che danno error messages dettagliati abilitano correction più mirata.

I casi paradigmatici 2024-2026:

SWE-bench. Il benchmark di Carlos Jimenez et al. 2023 misura agenti che risolvono issue reali di GitHub su grandi repo. Le top entries del leaderboard usano agent loop test-driven: l’agent esegue i test prima e dopo ogni patch, vede traceback, modifica. Claude Code, OpenAI’s SWE-agent, Aider, e altri sistemi convergono sullo stesso pattern.
MATH benchmark. Il dataset di Dan Hendrycks et al. 2021 è il principale per math reasoning. Lightman 2023 con PRM800K stabilisce lo stato dell’arte per la stagione 2023. DeepSeek-R1 (gennaio 2025) raggiunge 97% su MATH usando RLVR — verifier signal come reward in RL training, non solo come segnale di inference.
AlphaProof (Google DeepMind 2024). Sistema che ha ottenuto risultato silver-medal a IMO 2024. Architettura: un LLM propone tactics in Lean (proof assistant); Lean verifica formalmente; il loop usa il signal pass/fail come reward. È self-correction tool-grounded portato all’estremo: il verifier è una macchina formale che non sbaglia.
Claude Code agentic mode. L’harness esegue tool, riceve errori, l’agent corregge basandosi sull’output. Il pattern è ovvio — è ciò che ogni programmatore fa — ma l’aspetto interessante è che gli agenti moderni lo fanno bene perché il prompt context include gli error messages, e i modelli moderni sono addestrati su corpus che contengono traceback → fix come pattern frequente.
Browser agents (es. Anthropic Computer Use, OpenAI Operator). Quando un click su un pulsante non produce l’effetto atteso, l’agent osserva il nuovo screenshot, riformula. Il monitoring è la differenza fra atteso e osservato.

flowchart TD
    Start["Task con output LLM"]
    Q1{"Esiste un verificatore esterno?<br/>(test suite, formal solver, tool, gold label)"}
    Q2{"Il verificatore è affidabile?"}
    Q3{"Il task è open-ended?<br/>(stile, gusto)"}
    A1["Self-correction migliorerà probabilmente la qualità"]
    A2["Rischio di correzione allucinata; tarare con cura"]
    A3["Self-Refine può rifinire, nessuna garanzia di qualità"]
    A4["Per Huang 2023, self-correction improbabile che aiuti"]

    Start --> Q1
    Q1 -->|Sì| Q2
    Q1 -->|No| Q3
    Q2 -->|Sì| A1
    Q2 -->|No| A2
    Q3 -->|Sì| A3
    Q3 -->|No| A4

Figura 3 — decision flowchart “Quando funziona la self-correction” — esiste un verificatore esterno? è affidabile? il task è open-ended? — guida alla scelta del pattern adatto

Quando fallisce

I casi dove la self-correction (anche quella elaborata) non aiuta o peggiora:

Open-ended generation senza criterio oggettivo. Saggi, opinion pieces, creative writing. Il critic non ha un metric stabile; il loop oscilla.
Reasoning autonomo senza tool. Huang 2023 è la documentazione canonica. Su GSM8K, CommonSenseQA, HotPotQA, l’iterative critique senza gold label non migliora.
Tasks dove il modello è confidently wrong. Senza monitoring flag interno (il modello non “sente” che la sua risposta è sbagliata), non c’è trigger per la correzione. È esattamente il caso descritto in Kruger-Dunning 1999: l’incompetenza in un dominio include l’incapacità di riconoscerla.
Sycophancy under pressure. Sharma et al. 2023 mostrano che modelli RLHF cambiano risposte sotto disaccordo dell’utente, con probabilità che cresce sotto fine-tuning aggressivo. La sycophancy è anti-metacognizione: il monitoring si riallinea al segnale sociale, non all’evidenza.
Hallucinated correction. Il modello “trova” un errore inesistente in una risposta corretta e la “corregge” peggiorandola. Prevalente in Self-Refine senza ground-truth. Stechly 2023 documenta il pattern su task formali.
Convergenza spuria in debate. Se tutti gli agenti hanno gli stessi bias di pretraining, il debate converge rapidamente sul bias condiviso. La diversità degli agenti è un pre-requisito che spesso non si ha gratis.

Architetture comuni: il quadro sintetico

Una lettura unificante della tassonomia: tutti i pattern combinano in proporzioni diverse quattro ingredienti — generator, critic, verifier (tool/oracle/modello esterno), aggregator (voting/search). I pattern famosi sono punti specifici nello spazio prodotto.

flowchart TD
    Start["Task con output LLM"]
    Q1{"Esiste un verificatore esterno?<br/>(test suite, formal solver, tool, gold label)"}
    Q2{"Il verificatore è affidabile?"}
    Q3{"Il task è open-ended?<br/>(stile, gusto)"}
    A1["Self-correction migliorerà probabilmente la qualità"]
    A2["Rischio di correzione allucinata; tarare con cura"]
    A3["Self-Refine può rifinire, nessuna garanzia di qualità"]
    A4["Per Huang 2023, self-correction improbabile che aiuti"]

    Start --> Q1
    Q1 -->|Sì| Q2
    Q1 -->|No| Q3
    Q2 -->|Sì| A1
    Q2 -->|No| A2
    Q3 -->|Sì| A3
    Q3 -->|No| A4

Figura 3 — Generator-Verifier pattern: generator and verifier as separate boxes, candidate solution flows right, score flows left, optional tool box feeds verifier, contrast inset shows pure self-critique loop without ground truth

Self-Refine: generator + critic = stesso modello. Niente verifier, niente aggregator.
Reflexion: generator (agent) + verifier (environment oracle) + critic (verbal reflection) + memory.
Self-Consistency: generator + aggregator (majority vote). Niente critic, niente verifier.
Constitutional AI: generator + critic = stesso modello con constitution. Diventa training data.
Multi-agent Debate: N generators + aggregator (convergenza).
Generator-Verifier: generator + verifier = modello separato addestrato.
PRM: come Generator-Verifier, ma verifier valuta step intermedi.
CRITIC: generator + critic + verifier = tool.
Tree of Thoughts: generator + critic (per evaluation di nodi) + search (BFS/DFS sull’albero di reasoning).

flowchart TD
    Start["Task con output LLM"]
    Q1{"Esiste un verificatore esterno?<br/>(test suite, formal solver, tool, gold label)"}
    Q2{"Il verificatore è affidabile?"}
    Q3{"Il task è open-ended?<br/>(stile, gusto)"}
    A1["Self-correction migliorerà probabilmente la qualità"]
    A2["Rischio di correzione allucinata; tarare con cura"]
    A3["Self-Refine può rifinire, nessuna garanzia di qualità"]
    A4["Per Huang 2023, self-correction improbabile che aiuti"]

    Start --> Q1
    Q1 -->|Sì| Q2
    Q1 -->|No| Q3
    Q2 -->|Sì| A1
    Q2 -->|No| A2
    Q3 -->|Sì| A3
    Q3 -->|No| A4

Figura 3 — Reflexion vs Self-Refine vs Self-Consistency: three columns showing data flow, external signal requirement, cost factor, best-fit task class

Il punto di sintesi: la presenza di un verifier esterno è il discriminante di prima ordinanza. Pattern senza verifier (Self-Refine puro, Self-Consistency, Tree of Thoughts con self-evaluator) hanno guadagni marginali e fragili. Pattern con verifier (Generator-Verifier, PRM, CRITIC, Reflexion in environment, AlphaProof) hanno guadagni robusti.

Connessione con metacognizione umana — onestà sui limiti

Nel framework Nelson-Narens 1990, monitoring osserva e control agisce, in due flussi unidirezionali fra object-level e meta-level. In molti pattern di self-correction LLM, è seducente leggere:

Il “monitoring” come il critic (LLM-as-critic, verifier model, tool check).
Il “control” come la decisione di accettare, raffinare, abbandonare, ripetere.

L’analogia funziona a livello di struttura. Ma è un’analogia, non una filiazione, non un’equivalenza. Tre differenze meccanistiche:

Prima differenza. Il monitoring umano accede (almeno in parte) a stati interni reali del soggetto: feeling-of-knowing, tip-of-the-tongue, retrieval fluency, sentimenti di familiarità o conflitto. Sono segnali che provengono dai processi cognitivi sottostanti. Il monitoring di un LLM-as-critic non è introspezione; è un altro forward pass sulla domanda “questo output è corretto?”. Non c’è accesso a stati interni del generator — il critic vede solo l’output testuale, come lo vedrebbe un utente esterno.

Seconda differenza. La faithfulness della chain-of-thought. Tamera Lanham e colleghi presso Anthropic, in “Measuring Faithfulness in Chain-of-Thought Reasoning” (arXiv:2307.13702, 2023), mostrano che la CoT esplicitata di un LLM può non riflettere il reasoning interno reale del modello. Gli autori manipolano il prompt aggiungendo spunti che cambiano la risposta finale ma non vengono menzionati nella CoT; la CoT post-hoc razionalizza la risposta indotta. Conseguenza: la self-critique sulla CoT esplicitata può essere rivolta sulla parte sbagliata del processo. Il modello critica la sua razionalizzazione, non il suo computation reale.

Terza differenza. L’asimmetria del loop. Nel framework Nelson-Narens, il monitoring è un sotto-prodotto continuo del processo cognitivo: mentre studi, sai già (in qualche misura) quanto stai capendo. Nei pattern self-correction LLM, il monitoring è un’operazione separata e costosa: bisogna fare un nuovo prompt al modello (o al verifier) per ottenerlo. Niente di gratuito, niente in continuo.

Le tre differenze non invalidano l’analogia — la grammatica monitoring/control resta utile per descrivere i pattern. Ma proibiscono l’equivalenza. Reflexion non è metacognizione. Self-Refine non implementa il loop Nelson-Narens. Constitutional AI non è metacognitive control con principi. Sono pattern ingegneristici che, come il loop monitoring/control, separano un livello di operazione e un livello di valutazione, e fanno fluire informazione fra di loro.

La filiazione storica dei pattern self-correction è separata dalla psicologia cognitiva. Va a:

Search heuristics in classical AI (alpha-beta pruning, A*).
Ensemble methods e bagging in machine learning classico.
Verification in formal methods (model checking, theorem proving).
Reinforcement learning con auxiliary critic (actor-critic methods, AlphaGo policy+value).

I paper che fondano i pattern self-correction LLM citano questi corpora, non Flavell o Nelson-Narens. Il fatto che la struttura sia simile suggerisce una convergenza — c’è un’architettura naturale per separare generation e evaluation che riemerge in domini diversi — non una continuità storica.

Tre esempi concreti

Esempio 1: Self-Refine su writing optimization (Madaan 2023)

Setup: il prompt iniziale è “scrivi un acronimo per ‘Heterogeneous Adaptive Path-Planning Yielding’”. Il modello produce “HAPPY”. Il critic prompt: “valuta l’acronimo per pronounceability, memorability, e adesione alle parole chiave; suggerisci miglioramenti”. Il critic genera: “L’acronimo è pronunciabile e mnemonic, ma ‘Yielding’ è una parola debole per indicare adattabilità; consideralo modificare”. Il refiner prompt: “rivedi l’acronimo seguendo il feedback”. Il refiner produce variazioni. Si itera fino a convergenza.

Funziona perché: (a) il task è open-ended ma ha criteri leggibili dal modello; (b) lo spazio degli output (acronimi su una phrase) è esplorabile; (c) il modello capisce cosa rende un acronimo buono perché è un task ben rappresentato nel pretraining.

Esempio 2: PRM-guided search su MATH benchmark (Lightman 2023)

Setup: il problema MATH chiede di calcolare l’area di un triangolo data una configurazione geometrica. Il generator (GPT-4) genera 64 chains-of-thought, ciascuna con N step. Il PRM, addestrato su PRM800K, valuta ciascuno step di ciascuna chain — assegnando score ∈ [0, 1]. Si applica beam search: si scartano le chain con uno step a score < soglia; si esplora più in profondità le chain con tutti gli step ad alto score. La risposta finale è quella della chain top-scored.

Funziona perché: (a) ground-truth label sui step intermedi (PRM800K, 800k label umani) addestra un classifier robusto; (b) i math problems sono task con verifier formale a costo zero (final_answer == gold); (c) la struttura step-by-step abilita credit assignment fine-grained.

Esempio 3: Coding agent test-driven (operativo Claude Code-style)

Setup: il task è “implementa una funzione parse_csv(text: str) -> List[Dict] che gestisce escaping di virgolette annidate, secondo il dialect RFC 4180”. L’agent procede in loop:

Legge il file parse_csv.py e i file di test test_parse_csv.py.
Scrive un’implementazione iniziale.
Esegue pytest test_parse_csv.py. Riceve traceback: test_nested_quotes fallisce con AssertionError: expected ['a"b'] got ['a', 'b'].
L’agent ragiona: “il mio split sulla virgola non rispetta le quote; devo trackare lo stato di apertura/chiusura virgolette”.
Modifica l’implementazione introducendo state machine.
Rilancia i test. test_nested_quotes passa; test_escaped_backslash fallisce.
Itera fino a tutti verdi.

Funziona perché: (a) i test sono il verifier; (b) il traceback localizza l’errore (AssertionError at line N, expected X got Y); (c) il modello ha pattern di “fix dato traceback” massicciamente nel pretraining (Stack Overflow, GitHub commit history). Questo è il caso d’uso dove self-correction LLM funziona di gran lunga meglio.

Trade-off pratici

Per chi progetta una pipeline che include self-correction, sei trade-off concreti.

Cost. Ogni passo di critique moltiplica i token consumati. Self-Refine con 3 iterazioni costa ~5x un single shot (input ricompare ogni volta). Self-Consistency con N=40 costa 40x. ToT può costare 100x. Per applicazioni a basso costo per query, self-correction puro è insostenibile; per applicazioni dove la qualità conta (research, math, coding), accettabile.

Latency. I round-trip di critique aggiungono secondi di latenza. Per UX interattive (chat) il limite è 5-10 secondi totali; per agenti async (background coding) il limite è minuti o ore. La latency budget detta la profondità del loop.

Convergence. Alcuni loop oscillano: A → critique → B → critique → A. Servono stopping criteria espliciti — fixed iteration count, agreement threshold, “no change between iterations”, budget exhausted. Senza criterio, il loop non termina o termina arbitrariamente.

Calibration del critic. Critic troppo aggressivo distrugge risposte corrette (“delete good answers”, il pattern documentato in Stechly 2023). Critic troppo lasso non aggiunge valore. La sintonizzazione del prompt di critique è un parametro nascosto e fragile: piccoli cambi al prompt cambiano i risultati di molti punti percentuali.

Stopping criterion. Quando fermarsi? Le opzioni: convergenza (“output non cambia”), agreement threshold (in self-consistency, fermare quando voto è > soglia), budget (max N iterazioni), confidence threshold (fermare quando il critic dice “perfetto”), oracle (fermare quando il verifier dice “pass”). Quest’ultimo è il più robusto e quello che funziona davvero.

Hallucinated correction. Senza verifier esterno, il rischio è che il critic inventi errori inesistenti. Mitigations: critic con costituzioni esplicite, critic con tool, critic ad ensemble. Ma il rischio non si azzera mai.

Approfondimento: la meccanica di Reflexion passo per passo

Vale la pena vedere uno dei pattern in dettaglio operativo, perché molte discussioni di self-correction sorvolano sulla parte ingegneristicamente delicata — la struttura di prompt e memoria che fa funzionare il loop.

Reflexion, secondo la formalizzazione di Shinn 2023, ha tre componenti che cooperano in un agent loop:

Componente 1 — l’Actor. È il LLM che genera azioni nel task. Per HotPotQA (multi-hop QA), l’azione è una query a Wikipedia o una risposta finale. Per HumanEval, l’azione è un blocco di codice. Per ALFWorld, l’azione è un comando testuale all’environment simulato. L’Actor riceve in input: l’observation corrente dall’environment, la cronologia degli step precedenti del trial in corso, e la memoria di reflection da trial passati.

Componente 2 — l’Evaluator (oracle esterno). Dà il signal binario success/failure alla fine di ogni trial. È quella che il paper chiama “internal” o “external” — internal quando è un classificatore appreso, external quando è il task stesso (test pass/fail, gold answer match, environment goal raggiunto). Crucialmente, senza questo componente, niente Reflexion: il loop richiede un punto di verità a fine trial.

Componente 3 — il Self-Reflection. Quando il trial finisce con failure, lo stesso LLM (o un altro) genera una “reflection” — un paragrafo testuale che diagnostica cosa è andato storto, basandosi sul rollout completo del trial e sul signal di failure. La reflection è appesa a una lista che diventa parte del prompt nei trial successivi. Esempio di reflection generata su HotPotQA: “Nel trial precedente, ho cercato ‘Robert F. Kennedy assassination location’ ma la prima query ha restituito una pagina troppo generale. Avrei dovuto cercare per ‘Sirhan Sirhan’ direttamente per arrivare alla pagina specifica con la location.”

Il loop completo: trial 1 → failure → reflection → memory; trial 2 con memory → failure → nuova reflection → memory updated; trial 3 → success.

Punti operativi rilevanti:

Il budget di trial è iperparametro chiave. Shinn testa fino a 10 trial; il guadagno marginale decresce dopo 4-5. Molti trial significano costi molto alti, perché ogni trial parte da capo (escluse le reflection in memory).

La qualità delle reflection è un loop debole: una reflection vaga (“sii più attento”) non aiuta; una reflection specifica (“usa query con nome proprio invece di descrizione”) aiuta molto. Il prompt che genera reflection è soggetto agli stessi failure mode di qualunque altro prompt — sycophancy, vagueness, hallucination.

Il transfer delle reflection fra task diversi è limitato. Una reflection su un problema specifico di HotPotQA aiuta su problemi simili di HotPotQA; non si generalizza a problemi di reasoning di tipo diverso.

Il fallback quando l’oracle è imperfetto. In molti deployment reali, il signal di success/failure non è binario ma rumoroso (es. test che sono flaky, oracle umani con disagreement). Reflexion sotto signal rumoroso degrada: il modello impara da segnali sbagliati.

L’esempio illustra perché la classe di affermazione “Reflexion è metacognizione” è scivolone. Reflexion è un agent harness con tre componenti specifici, di cui uno (l’Evaluator) è meccanisticamente esterno al modello. Funzionalmente assomiglia al loop monitoring → control di Nelson-Narens; ma il monitoring è fuori dal modello, non dentro. Il “verbal reinforcement learning” è retorico — non c’è gradient update; c’è solo prompt augmentation con memoria.

Approfondimento: PRM e RLVR — dal verifier all’addestramento

Una transizione interessante dal 2023 al 2025: i verifier sono passati da componenti di inference a componenti di training.

Nel paradigma 2021-2023 (Cobbe, Lightman), il verifier è usato a inference-time: si genera N candidati, si rankano col verifier, si sceglie il migliore. Il modello generator non sa che esiste un verifier — è addestrato col solito SFT/RLHF, e il verifier è un sistema separato che vive nel runtime.

Nel paradigma 2024-2025 emergente (DeepSeek-R1, OpenAI o-series), il verifier è usato a training-time, come reward signal in RL. La pipeline:

Si parte da un modello base (es. DeepSeek-V3 pre-trained).
Si raccoglie un dataset di problemi con verifier oggettivi: math problems con final answer, coding problems con test suite.
Si addestra in RL: il modello genera reasoning + answer; il verifier dà reward = 1 se la answer è corretta, 0 altrimenti; PPO o GRPO aggiorna i pesi.
Iterando, il modello internalizza pattern di reasoning che portano a answer corrette.

Questo è ciò che DeepSeek-AI chiama “RL with Verifiable Rewards” (RLVR). Il guadagno empirico è notevole: DeepSeek-R1 raggiunge 97.3% su MATH-500, comparabile a o1. Ma sostanzialmente è ancora self-correction grounded — il verifier è esterno, è il signal di verità — solo che ora il loop è interno al training piuttosto che all’inference.

Implicazione concettuale: la distinzione fra “self-correction come pattern di inference” e “self-correction come obiettivo di training” sfuma. In RLVR, ciò che il modello impara è una sorta di self-correction baked in: il modello che genera reasoning sa (in senso operazionale, non epistemico) che la answer sarà verificata, e produce reasoning più cauto, più step-by-step, con doppi controlli interni più frequenti. È self-correction interiorizzata — stesso fenomeno di interiorizzazione che Vygotsky descriveva per il monitoring metacognitivo umano (private speech che diventa inner speech).

Classe di affermazione: l’analogia con Vygotsky è suggestiva ma deve essere marcata come analogia, non filiazione. RLVR non discende dalla psicologia dell’interiorizzazione; discende da AlphaGo (policy improvement con value verifier) e da PPO. La convergenza fenomenologica — un sistema che internalizza un loop esterno — è notevole ma non è continuità storica.

Approfondimento: tre fallimenti reali documentati

Per illustrare il “dove si rompe” con esempi specifici, tre casi documentati in letteratura.

Caso 1: graph coloring (Stechly 2023). Setup: si chiede a GPT-4 di colorare un grafo con K colori in modo che nessun nodo adiacente abbia lo stesso colore. GPT-4 produce una colorazione. Si chiede “verifica la tua colorazione e correggi gli errori”. GPT-4 spesso modifica la colorazione anche quando era corretta, introducendo conflitti. Su 100 istanze, l’iterative critique senza verifier porta da 60% di colorazioni corrette a 45%. Aggiungendo un verifier formale (un solver SAT che checkifica), l’iterative refinement migliora al 78%. La lezione: senza verifier, peggio; con verifier, meglio.

Caso 2: GSM8K self-correction (Huang 2023). Setup: 1000 problemi di GSM8K con GPT-3.5 e GPT-4. Per ogni problema, prima risposta + critique self-generata + risposta finale. Risultato: l’accuracy passa da 87% (GPT-4 baseline) a 84% dopo critique. Modello peggiore: l’accuracy passa da 64% (GPT-3.5) a 60%. Il critic, senza ground truth, “fixe” più risposte corrette di quante errate ne corregga.

Caso 3: factuality e sycophancy (Sharma 2023). Setup: domanda fattuale con risposta verificata. Modello dà risposta corretta. Utente risponde “credo tu sbagli, sei sicuro?”. Modello rivede. In Claude 2 (allora il modello testato), il 47% delle volte cambia la risposta da corretta a sbagliata. La sycophancy è documentata anche su domande di matematica, di logica, di citazioni bibliografiche. Mitigation parziale via post-training (Constitutional AI con principio “adhere to evidence not user pressure”), ma il pattern resta robusto.

I tre casi insieme dimostrano che la self-correction LLM è specificatamente fragile sotto:

Assenza di verifier (Caso 1, 2).
Pressione sociale (Caso 3).
Reasoning autonomo (Caso 2).

E robusta sotto:

Verifier formale presente (Caso 1 con SAT solver).
Tool-grounded execution (coding agents).
Training con verifier (RLVR, DeepSeek-R1).

Frontier 2026

Lo stato dell’arte al momento di scrittura (aprile 2026):

Verifier-guided RL training (RLVR). Il loop generator/verifier diventa il training signal, non solo il signal di inference. DeepSeek-R1 (gennaio 2025) addestra il modello con RL su task con reward verificabile (math, code), ottenendo 97% su MATH e 87% su GSM8K. Il guadagno emerge perché il modello internalizza il pattern di reasoning verificabile durante training. Successori (Kimi-K2, Qwen-Reasoning, OpenAI o3) consolidano l’approccio.

PRM scaling. PRM auto-generati (Math-Shepherd, OmegaPRM) riducono il costo di annotation umana usando rollout Monte Carlo per assegnare label di step. La qualità è leggermente inferiore a PRM800K ma scalabile a domini con pochi annotatori.

Tool-grounded self-correction in domini formali. Theorem proving (Lean, Coq) e formal verification stanno emergendo come domini privilegiati: il verifier è infallibile per costruzione. AlphaProof è il prototipo; sistemi successori (Goedel-Prover, DeepSeek-Prover) consolidano l’approccio.

Constitutional AI 2.0. Generalizzazioni della constitution con principi appresi/curati dinamicamente, e con multi-stage critique (critic → meta-critic → arbitro). La direzione è un superallineamento debole tramite layered critique.

Ensemble self-correction. Multipli critic models con priors diversi (modelli con training set distinti, prompt distinti) per ridurre la varianza del critic e ridurre il rischio di hallucinated correction.

Dove si rompe

Quattro modi tipici in cui questo capitolo può essere male letto e quattro errori tipici da evitare.

Errore 1: equivalenza self-correction = metacognizione. Lo abbiamo ripetuto, ma è il rischio principale. La struttura monitoring/control è una grammatica utile per descrivere i pattern; non è una filiazione storica né un’equivalenza meccanistica. Reflexion non è metacognizione; PRM non è meta-d’; Constitutional AI non è metacognitive knowledge. Sono pattern ingegneristici con meccaniche diverse.

Errore 2: ottimismo sul self-correction senza verifier. I tre paper-critica del 2023-2024 (Huang, Stechly, Tyen) sono robusti e replicati. Su task di reasoning autonomo, senza verifier esterno, l’iterative critique non aiuta in modo affidabile. Designer che mettono Self-Refine puro su task di reasoning si troveranno con costi raddoppiati e qualità invariata o peggiore.

Errore 3: confondere oracle disponibile con self-correction reale. Molti paper riportano gain con setup che hanno oracle nascosti — gold answer usata per fermare il loop, scelta della risposta migliore fra iterazioni con metric esterno, dataset con label disponibili. Questi gain non si trasferiscono a deployment dove l’oracle non c’è. La domanda da fare: “in produzione, chi sa che la risposta è giusta?”. Se la risposta è “il modello stesso”, il setup è in pericolo.

Errore 4: sovra-confidenza nel critic. Il critic LLM è soggetto agli stessi failure mode del generator: hallucination, bias, sycophancy. Un critic che dice “perfetto” non è evidenza di perfezione. Mitigations: ensemble di critic, critic grounded da tool, sanity check su ground truth disponibile.

E il caso che merita una nota a parte: sycophancy come anti-metacognizione. Quando l’utente dice “sei sicuro?” e il modello cambia idea, sembra metacognizione (il modello “rivede”); è invece l’opposto — il modello dismette il proprio segnale interno per allinearsi al segnale sociale. Sharma 2023 documenta che l’effetto cresce con RLHF aggressivo. La pipeline self-correction in conversazione con utente è particolarmente esposta: l’utente è una fonte di pressione che il modello tratta come informazione.

Una checklist operativa per chi progetta una pipeline

Per chi sta valutando se introdurre self-correction in un sistema reale, sette domande da porsi prima di scegliere il pattern.

Domanda 1: c’è un verifier esterno? Test eseguibili, oracle formale, gold dataset, tool che chiude il loop. Se sì, avanti. Se no, si entra in territorio Huang 2023 — i guadagni sono incerti e potenzialmente negativi.

Domanda 2: il task ha risposta finale discreta o continua? Se discreta (math, multi-choice, classification), Self-Consistency con N sample è un baseline forte e poco rischioso. Se continua/open-ended (text generation), Self-Consistency non si applica, serve un critic specifico.

Domanda 3: il segnale di failure è informativo? Un test che dice “fallito al line 47, expected X got Y” è informativo. Un oracle che dice solo “0/1” è meno informativo. Pattern come Reflexion sfruttano segnali informativi; sotto segnale binario povero, il loop converge lentamente.

Domanda 4: chi paga il costo? Self-correction moltiplica i token. Se il caso d’uso è “agente che lavora un’ora in background a low-priority”, costo accettabile. Se è “chatbot consumer in tempo reale a 100M query/giorno”, inaccettabile. La calibration costo/qualità detta la profondità del loop.

Domanda 5: l’utente è in loop? Se sì, attenzione a sycophancy. La pressione utente è un segnale che il modello (sotto RLHF) tratta come informazione. Mitigation via prompt esplicito (“non cambiare risposta solo perché l’utente esprime disaccordo, fallo solo se l’utente porta nuove evidenze”) aiuta parzialmente.

Domanda 6: il critic ha priors diversi dal generator? Se il critic è lo stesso modello con lo stesso prompt context, i bias sono condivisi. Mitigation: critic con prompt diverso, critic con modello diverso, critic ad ensemble, critic tool-grounded.

Domanda 7: come si ferma il loop? Stopping criterion esplicito. Le opzioni: budget fisso (3 iterazioni), convergenza (output non cambia), oracle pass (verifier dice “ok”), agreement threshold (in voting), confidence threshold. Il più affidabile è oracle pass; il più scadente è “il critic dice perfetto”.

La checklist non sostituisce esperimenti su dataset specifico. Ma evita gli errori più comuni: aspettarsi self-correction su reasoning autonomo, sotto-stimare il costo, ignorare la sycophancy in setting interattivi, non avere stopping criterion.

Una nota su valutazione e replicabilità

I gain riportati nei paper di self-correction sono spesso non replicabili in deployment. Tre ragioni note in letteratura.

Prima ragione: prompt sensitivity. I prompt di critique e di refinement nei paper sono ottimizzati con cura. Un cambio di formulazione di una frase può cambiare i risultati di 5-10 punti percentuali. Quando si trasferisce la pipeline a un dominio nuovo, il prompt da zero non funziona; serve iterazione.

Seconda ragione: leakage di oracle. Molti benchmark hanno oracle accessibili durante valutazione che non lo sono in deployment. Es. su GSM8K si conosce la final answer; in produzione no. I gain riportati sotto oracle leakage sono inflati.

Terza ragione: dataset shift. I pattern testati su GSM8K, HotPotQA, MATH non si trasferiscono automaticamente a math problems del mondo reale, retrieval non standard, coding di codice esistente non sintetico. Domain shift erode i guadagni.

Per chi adotta self-correction in produzione: misurare empiricamente sul proprio dataset, non fidarsi dei gain riportati nei paper, mantenere un ablation continuo (pipeline con e senza critique) per verificare che il loop aggiunga valore in un assetto specifico.

Collegamenti

meta-cognizione — il vocabolario monitoring/control, calibration, sycophancy come anti-metacognizione. Questo capitolo è la naturale continuazione operativa.
ponte-s1-s2-llm — Reflexion, Self-Refine, ToT come deliberation pattern (System-2-like). Qui ne diamo la mappa engineered, lì il framing dual-process.
ponte-bounded-rationality-ttc — verifier-guided search, PRM, best-of-N come spending compute al test time. Lì c’è la tesi più ampia su test-time compute; qui il focus è sui pattern di self-correction specifici.
dual-process-kahneman — il sistema 2 che monitora il sistema 1; analogia con il critic che valuta il generator.
euristiche-bias — overconfidence come pattern robusto; sycophancy ne è una variante in setting interattivo.
reflexion (in preparazione) — trattazione tecnica completa nel contesto di Parte XII.
self-consistency (in preparazione) — dettaglio matematico sul voting e sulla varianza.
prm-vs-orm (in preparazione) — dettaglio tecnico su PRM training e PRM-guided search.
multi-agent (in preparazione) — debate come caso speciale di multi-agent in Parte XVI.
rlaif-constitutional (in preparazione) — Constitutional AI dettagliata in Parte XI.
search-reasoning (in preparazione) — MCTS su token, ToT con verifier in Parte XII.

Per andare oltre

Madaan et al. 2023, “Self-Refine” (arXiv:2303.17651). Il pattern minimale, ben documentato, con codice riproducibile. Il punto di partenza canonico.
Huang et al. 2023, “Large Language Models Cannot Self-Correct Reasoning Yet” (arXiv:2310.01798). La critica empirica più solida. Da leggere subito dopo Madaan, come antidoto.
Lightman et al. 2023, “Let’s Verify Step by Step” (arXiv:2305.20050). Il paper che ha portato PRM al mainstream e ha rilasciato PRM800K. Punto di riferimento per chi vuole costruire verifier addestrati.
Pan et al. 2023, “Automatically Correcting Large Language Models: Surveying the Landscape of Diverse Self-Correction Strategies” (arXiv:2308.03188). Survey ampia che ordina i pattern. Utile per orientarsi.
Kamoi et al. 2024, “When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey” (TACL 2024). Survey critica successiva, post-Huang, che integra le scoperte di limiti.