Leggendo CRITIC (Gou et al., ICLR 2024) mentre rifletto su cosa accade dopo che un agente finanziario commette un errore. Reflexion ci ha insegnato che gli agenti possono imparare dagli errori nel corso degli episodi. CRITIC pone una domanda più precisa: un LLM può individuare e correggere i propri errori all'interno di un singolo passaggio di generazione — e, in tal caso, cosa gli serve realmente per farlo?
L'articolo
CRITIC introduce un framework in cui un modello linguistico genera un output iniziale, quindi ripete un ciclo di verifica-e-correzione utilizzando strumenti esterni — un'API di ricerca per affermazioni fattuali, un interprete Python per codice e aritmetica e un classificatore di tossicità per la moderazione dei contenuti. Il ciclo viene eseguito per un numero fisso di iterazioni (l'articolo riporta risultati efficaci in circa tre correzioni), producendo un output raffinato che gli autori valutano su domande a risposta aperta (TriviaQA, AmbigNQ, HotpotQA), sintesi di programmi matematici e riduzione della tossicità.
L'affermazione centrale non è che gli LLM possano autocorreggersi da soli. È quasi l'opposto: il valore di CRITIC deriva proprio dall'ancorare la critica a un segnale esterno che il modello non può falsificare. Senza l'API di ricerca, i miglioramenti nel QA si riducono quasi a zero o si invertono. Il framework funziona perché lo strumento dice al modello qualcosa che realmente non sapeva, non perché il modello diventi un revisore affidabile di se stesso.
Idee chiave
- Applicato a ChatGPT, CRITIC ottiene un miglioramento medio di 7,7 punti F1 in tre attività di QA su dominio aperto e guadagni assoluti di 7,0 punti percentuali in tre benchmark di ragionamento matematico.
- La riduzione della tossicità è il risultato singolo più sorprendente: una riduzione del 79,2% della probabilità di tossicità nel dataset valutato.
- La rimozione dell'API di ricerca causa un plateau o un degrado delle prestazioni nel QA — la capacità intrinseca di autocritica del modello è quasi inutile per compiti fattuali.
- Il ciclo converge rapidamente: tre round di correzione catturano la maggior parte del guadagno, con rendimenti decrescenti oltre.
- Il framework è indipendente dal modello e non richiede messa a punto; funziona su API a scatola chiusa, inclusi sia Text-Davinci-003 che ChatGPT.
- CRITIC supera l'autoconsistenza (voto a maggioranza su più campioni) nella maggior parte dei compiti, il che è significativo perché l'autoconsistenza non ha alcun costo di strumento per passo.
Cosa regge — e cosa no
Il risultato empirico centrale è solido: il feedback da strumenti esterni migliora significativamente gli output, e l'ablazione che rimuove l'API di ricerca è devastante per i sostenitori dell'ingenua autocorrezione. L'articolo è anche onesto riguardo al meccanismo — i guadagni provengono dallo strumento, non da una qualche emergente capacità metacognitiva.
Ciò che trovo poco esplorato è la tassonomia delle modalità di fallimento. Quando il modello genera una critica errata che lo allontana ulteriormente dalla risposta corretta? L'articolo riporta le prestazioni medie, ma la varianza tra compiti e tipi di domande sarebbe enormemente importante per l'implementazione. In un contesto finanziario, il risultato peggiore non è "nessun miglioramento" — è una correzione che sembra plausibile ma introduce un nuovo errore.
La scelta di limitare a tre iterazioni è presentata anche come una comodità pratica piuttosto che un criterio di arresto fondato. Tre round possono funzionare per TriviaQA dove esiste una risposta di verità assoluta verso cui convergere. In un dominio come la riconciliazione di registri contabili, dove la risposta "corretta" richiede ragionamento multi-documento e conoscenza del dominio, non è ovvio che tre chiamate a strumenti siano sufficienti — o che un'API di ricerca generica fornisca il segnale di verifica appropriato.
L'articolo complementare ICLR 2024 "Large Language Models Cannot Self-Correct Reasoning Yet" (Huang et al., arXiv:2310.01798) conferma la scoperta stessa di CRITIC dall'altra direzione: senza feedback esterno, l'autocorrezione degrada in modo affidabile l'accuratezza del ragionamento. Questi due articoli insieme formano un quadro coerente — la capacità che la gente chiamava "autocorrezione" è per lo più un raffinamento guidato da feedback esterno, e la distinzione è importante.
Perché questo è importante per l'AI finanziaria
Il ciclo di CRITIC si mappa naturalmente sul problema della sicurezza di scrittura negli agenti Beancount. Oggi, quando un agente LLM propone una registrazione contabile — ad esempio, categorizzando una transazione o dividendo una spesa — non esiste un modo fondato per verificare il proprio output prima di scriverlo su disco. L'architettura di CRITIC suggerisce uno schema concreto: generare una registrazione candidata, poi eseguire la verifica contro uno strumento (una funzione di controllo del saldo, un motore di regole, un rilevatore di duplicati) e utilizzare l'output dello strumento per richiedere una revisione prima che la scrittura venga completata.
Il risultato sulla tossicità è un'analogia che trovo utile riformulare: una riduzione del 79,2% delle violazioni delle policy non deriva dall'interiorizzazione delle regole da parte del modello — deriva da un classificatore che segnala le violazioni al modello. Per un registro Beancount, l'equivalente sarebbe un verificatore di regole che segnala transazioni conteggiate due volte o violazioni di categoria, e alimenta quel segnale nel passaggio di revisione dell'agente. L'agente non deve sapere in modo indipendente che le regole sono violate; ha bisogno del segnale dello strumento.
Il limite critico per la finanza è la dipendenza dall'API di ricerca. Gli agenti finanziari hanno bisogno di strumenti di verifica specifici per dominio: controlli di integrità del saldo contabile, validatori del piano dei conti, ricerche di regole fiscali. Una ricerca web generica difficilmente riuscirà a individuare una spesa classificata erroneamente. Costruire il giusto livello di strumenti per la correzione in stile CRITIC in ambito contabile è dove risiede il vero lavoro ingegneristico — e l'articolo non affronta affatto la progettazione di strumenti specifici per dominio.
Cosa leggere dopo
- "Large Language Models Cannot Self-Correct Reasoning Yet" (Huang et al., 2023, arXiv:2310.01798) — l'argomento empirico diretto che l'autocorrezione intrinseca fallisce; dovrebbe essere letto insieme a CRITIC poiché triangolano lo stesso meccanismo da direzioni opposte.
- "Tree of Thoughts: Deliberate Problem Solving with Large Language Models" (Yao et al., NeurIPS 2023, arXiv:2305.10601) — estende l'idea di critica-e-correzione su un singolo percorso a un albero di ricerca su passaggi intermedi; rilevante per la riconciliazione a più passaggi dove l'agente deve esplorare e tornare indietro.
- "ToolBench: Facilitating Large Language Models in Mastering 16000+ Real-world APIs" (Qin et al., 2023, arXiv:2307.16789) — esamina come gli agenti imparano a selezionare e concatenare chiamate a strumenti, che è il problema a monte che CRITIC dà per scontato.