Questo articolo è il diretto contraltare ai lavori su CRITIC e Reflexion che stavo leggendo. Huang et al. (ICLR 2024) presentano un argomento semplice e scomodo: quando i LLM provano ad autocorreggere il proprio ragionamento senza alcun segnale esterno, non migliorano — peggiorano. Subito dopo il LOG-013 su CRITIC, dove la critica basata su strumenti esterni aiutava davvero, questo articolo chiarisce esattamente quale tipo di "autocorrezione" è reale e quale è un artefatto della configurazione sperimentale.
L'articolo
"Large Language Models Cannot Self-Correct Reasoning Yet" di Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song e Denny Zhou (Google DeepMind / UIUC) è stato pubblicato a ICLR 2024. L'affermazione centrale è ristretta ma devastante per una certa classe di progetti di agenti: l'autocorrezione intrinseca — chiedere a un LLM di rivedere e correggere la propria risposta usando solo il proprio giudizio, senza alcun segnale di verità assoluta — degrada costantemente le prestazioni sui benchmark di ragionamento. I miglioramenti riportati in diversi articoli precedenti sull'autocorrezione, sostengono gli autori, derivano da un sottile difetto metodologico: quegli articoli usavano etichette oracolo per decidere quando fermare la correzione, il che significa che il modello correggeva solo risposte già errate. Questa non è autocorrezione; è filtraggio guidato da un oracolo.
Idee chiave
- Su GSM8K, GPT-4 parte con un'accuratezza del 95,5%. Dopo un ciclo di autocorrezione intrinseca scende al 91,5% e dopo un secondo ciclo all'89,0%. GPT-3.5 scende dal 75,9% al 74,7% dopo due cicli.
- Il calo è più drammatico su CommonSenseQA: GPT-3.5 scende dal 75,8% al 38,1% dopo un singolo ciclo di autocorrezione, riprendendosi leggermente al 41,8% nel secondo ciclo — ma comunque ben al di sotto della linea di base.
- L'analisi dei cambiamenti nelle risposte su GSM8K mostra che il modello trasforma risposte corrette in errate più spesso di quanto trasformi risposte errate in corrette. La direzione netta del cambiamento è dannosa.
- L'autocorrezione guidata da un oracolo migliora effettivamente le cose: GPT-4 su GSM8K con etichette oracolo passa dal 95,5% al 97,5% e GPT-3.5 su CommonSenseQA dal 75,8% all'89,7%. Ma questo richiede sapere quali risposte sono sbagliate — cosa che non è possibile sapere in fase di implementazione.
- Il dibattito multi-agente, un'altra idea popolare, ha prestazioni inferiori rispetto alla semplice auto-consistenza quando si eguaglia il budget di inferenza. Con 9 risposte totali, l'auto-consistenza raggiunge l'88,2% su GSM8K; il dibattito multi-agente raggiunge solo l'83,0%.
- La generazione vincolata (CommonGen-Hard) sembra inizialmente un successo per l'autocorrezione (44% → 67%), ma quel guadagno svanisce se si migliora semplicemente il prompt iniziale (81,8%). Quando il prompt di partenza è già buono, l'autocorrezione danneggia, facendo scendere l'accuratezza al 75,1%.
Cosa regge e cosa non regge
Il risultato centrale è solido: i numeri sono quelli che sono. Se si invita GPT-4 a riesaminare le proprie risposte matematiche senza dirgli quali sono sbagliate, le risposte in media peggiorano. L'intuizione offerta dall'articolo è anche corretta — i LLM non possono giudicare in modo affidabile la correttezza del proprio ragionamento, quindi quando decidono di cambiare una risposta, stanno indovinando, e indovinano male almeno tanto spesso quanto indovinano bene.
L'articolo è meno convincente nelle sue affermazioni di generalizzazione. Testa esclusivamente compiti di ragionamento e conoscenza. Ci sono domini — stile di scrittura, aderenza a vincoli di formato, riduzione della tossicità — dove la revisione iterativa presumibilmente aiuta, e l'articolo li ignora in gran parte. Gli autori lo riconoscono di sfuggita, notando che "l'autocorrezione potrebbe essere più efficace per compiti dove la valutazione è più semplice", ma non lo testano attentamente. L'esperimento di generazione vincolata CommonGen è suggestivo, ma usare un prompt iniziale inadeguato come base di confronto e chiamare il miglioramento risultante "autocorrezione" è lo stesso difetto metodologico che l'articolo critica in altri lavori.
L'articolo inoltre non affronta la questione dell'autocorrezione addestrata. Un lavoro successivo del 2025 (SCoRe, ICLR 2025, arXiv:2409.12917) mostra che l'autocorrezione addestrata con rinforzo sugli output del modello stesso raggiunge un +15,6% su MATH e un +9,1% su HumanEval — un genuino miglioramento intrinseco. Quindi il titolo "non possono autocorreggersi ancora" è invecchiato meglio di quanto permetterebbe un'interpretazione più forte; l'interpretazione corretta è "non possono essere indotti all'autocorrezione tramite prompt", non "non possono imparare ad autocorreggersi".
Perché questo è importante per la finanza AI
L'implicazione per gli agenti di registrazione contabile è concreta. Un agente che genera una registrazione in Beancount, poi si chiede "questo sembra corretto?" e la rivede, non sta ottenendo una seconda opinione — sta introducendo rumore. I dati qui mostrano che se la prima risposta era sbagliata, l'autorevisione è probabile che corrompa una risposta corretta tanto quanto che ne corregga una sbagliata.
Ciò che questo articolo conferma è il vincolo progettuale che ho tratto da CRITIC: l'autovalutazione senza un oracolo esterno è inaffidabile. Per Beancount in particolare, l'oracolo esterno è disponibile ed economico — le verifiche di bilancio vengono eseguite in millisecondi, i nomi dei conti vengono validati rispetto a un piano dei conti noto, gli importi devono quadrare al centesimo. Un'architettura di agente che invia una registrazione provvisoria, esegue bean-check e reindirizza qualsiasi errore come feedback strutturato concreto è fondamentalmente diversa da una che chiede al modello di "rivedere la tua registrazione". La prima usa il motore contabile come oracolo. La seconda si affida allo stesso meccanismo di ragionamento che ha prodotto l'errore in primo luogo.
C'è anche una lezione più sottile qui riguardo alla progettazione dei prompt. L'esperimento CommonGen mostra che quando il prompt è già preciso ed esplicito, l'autocorrezione degrada le prestazioni. Ciò significa che se investiamo sforzo nello scrivere prompt molto chiari per l'analisi delle transazioni — prompt che enunciano esplicitamente tutte le regole sintattiche di Beancount — aggiungere un ciclo di autorevisione sopra di essi potrebbe danneggiare attivamente l'accuratezza. L'architettura corretta probabilmente condiziona l'autorevisione al fallimento di un controllo esterno, non ad ogni generazione.
Cosa leggere dopo
- SCoRe: Training Language Models to Self-Correct via Reinforcement Learning (arXiv:2409.12917, ICLR 2025) — approccio basato su RL che raggiunge i primi genuini guadagni di autocorrezione intrinseca; contesto necessario per capire cosa questo articolo esclude vs. include
- When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs (TACL 2024) — tassonomia sistematica di quando l'autocorrezione funziona, distinguendo varianti intrinseche, basate su addestramento e assistite da strumenti
- Self-Refine: Iterative Refinement with Self-Feedback (NeurIPS 2023) — l'articolo principale che Huang et al. criticano; leggerli uno dopo l'altro chiarisce esattamente dove è incorporata l'assunzione dell'etichetta oracolo