Dopo aver letto l'articolo "cannot self-correct" la settimana scorsa, una domanda naturale successiva è: se gli LLM non possono controllare in modo affidabile il proprio output, quale formato di azione offre agli agenti la migliore possibilità di rilevare e recuperare automaticamente dagli errori? CodeAct, pubblicato da Xingyao Wang et al. e accettato a ICML 2024, sostiene che la risposta sia il codice Python — non perché il codice sia magico, ma perché un interprete Python fornisce esattamente il tipo di feedback esterno e deterministico di cui la letteratura sull'autocorrezione mostra che gli LLM hanno disperatamente bisogno.
L'articolo
"Executable Code Actions Elicit Better LLM Agents" (arXiv:2402.01030) di Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng e Heng Ji propone di sostituire i formati di azione JSON e testo comuni negli agenti con chiamate a strumenti con codice Python eseguibile. L'idea centrale è che il codice sia una lingua franca migliore per le azioni degli agenti rispetto sia alle istruzioni in linguaggio naturale che al JSON strutturato, perché il codice già codifica il flusso di controllo, le dipendenze dei dati e la composizione multi-passaggio — e perché gli LLM sono stati fortemente pre-addestrati su di esso.
L'articolo fornisce tre contributi: (1) un argomento concettuale per il codice come spazio di azione unificato; (2) M3ToolEval, un nuovo benchmark di 82 attività curate da umani che richiedono composizione multi-strumento; e (3) CodeActAgent, un modello 7B perfezionato addestrato su CodeActInstruct, un set di dati di 7.139 traiettorie basate su codice multi-turno che abbracciano recupero di informazioni, pacchetti software, memoria esterna e pianificazione robotica.
Idee chiave
- Su M3ToolEval, GPT-4 con CodeAct raggiunge un tasso di successo del 74,4% contro il 53,7% con azioni testuali — un miglioramento assoluto di circa 20 punti percentuali nell'ambiente multi-strumento più impegnativo.
- CodeAct richiede circa il 30% in meno di turni di interazione rispetto agli agenti basati su JSON sulle stesse attività. Meno turni è importante: ogni passaggio aggiuntivo è un'ulteriore opportunità per la propagazione degli errori.
- L'interprete Python agisce come un segnale di errore automatico e a costo zero. Un calcolo intermedio errato solleva immediatamente un'eccezione; l'agente vede il traceback e può rivedere senza un passaggio di critica separato.
- I modelli open-source beneficiano più di quelli closed-source. CodeActAgent (Mistral 7B) raggiunge il 12,2% su M3ToolEval contro il 3,7% del precedente agente open-source più forte (Lemur-70B con testo). La leva è maggiore perché Python è abbondante nei dati di pre-addestramento; i formati specializzati di chiamata a strumenti in JSON non lo sono.
- CodeActInstruct si addestra su quattro domini specificamente scelti per testare la composizione: ricerca di informazioni, chiamate a pacchetti, manipolazione di memoria esterna e pianificazione robotica. Queste sono tutte attività multi-passaggio e dipendenti dallo stato — gli esatti modi di fallimento in cui gli agenti JSON si rompono.
Cosa regge — e cosa no
Il miglioramento del 20% su M3ToolEval è reale, ma M3ToolEval ha solo 82 attività. Questo è un campione piccolo, e l'articolo non riporta intervalli di confidenza. Il benchmark è inoltre curato dallo stesso team che propone il metodo, il che è standard nel settore ma vale la pena segnalarlo. Vorrei vedere questa replicata su un benchmark completamente indipendente prima di considerare il 74,4% come una cifra affidabile.
L'affermazione sull'efficienza — il 30% in meno di turni — è plausibile ma confonde due cose. Meno turni potrebbe significare che l'agente è più accurato per passaggio, oppure che i fallimenti terminano prima. L'articolo non analizza questo aspetto in modo pulito.
Il divario riconosciuto tra modelli open-source e closed-source è ampio e non viene spiegato da CodeAct. CodeActAgent (Mistral 7B) al 12,2% è molto meglio di Lemur-70B al 3,7%, ma GPT-4 con CodeAct è al 74,4%. Il formato aiuta, ma non colma un divario di capacità di 60 punti. Chiunque pianifichi di distribuire un agente Beancount open-source dovrebbe leggere quel numero con attenzione.
La questione del sandboxing riceve un solo paragrafo. L'esecuzione di codice arbitrario in un contesto finanziario non è un caso limite scomodo — è la principale preoccupazione di sicurezza. L'articolo non affronta cosa succede quando l'agente genera codice che elimina file, effettua chiamate di rete o importa librerie impreviste. Per un agente contabile in produzione, la progettazione del sandbox è almeno importante quanto il formato dell'azione.
Perché questo è importante per l'IA finanziaria
Il problema della scrittura su Beancount è essenzialmente il problema per cui CodeAct è stato progettato: un agente deve comporre più operazioni (leggere il saldo corrente, convalidare una transazione, scrivere una nuova registrazione, verificare l'equazione di bilancio) in un ordine specifico, con dati che fluiscono tra i passaggi. Le chiamate a strumenti in JSON gestiscono questo male perché ogni chiamata è isolata. Python lo gestisce in modo naturale.
Più concretamente: un agente Beancount in stile CodeAct potrebbe esprimere un intero flusso di lavoro di riconciliazione come un singolo script Python — interrogando il registro tramite una libreria, calcolando i delta, proponendo nuove voci ed eseguendo bean-check sul risultato — tutto prima di impegnare qualsiasi modifica. L'interprete intercetta gli errori ovvi; l'LLM deve solo gestire quelli semantici. Questa è una migliore divisione del lavoro rispetto a chiedere all'LLM di convalidare il proprio JSON.
La preoccupazione per la sicurezza va nell'altra direzione. Un agente con esecuzione Python senza restrizioni su un registro finanziario è una superficie di attacco significativa. La progettazione corretta è quasi certamente un sandbox pesantemente limitato — nessuna scrittura su filesystem al di fuori di una directory temporanea designata, nessun accesso alla rete, nessun comando shell — combinato con un gate obbligatorio bean-check prima che qualsiasi file venga toccato. CodeAct fornisce il formato dell'azione; devi comunque costruire la gabbia.
Cosa leggere dopo
- OpenHands (ex OpenDevin) — il sistema agente di produzione basato su CodeAct dello stesso gruppo di ricerca; mostra come sono effettivamente implementati il sandboxing e l'ambiente di esecuzione (arXiv:2407.16741)
- ToolBench / ToolLLM — benchmark e dati di addestramento per agenti con chiamate a strumenti che utilizzano API REST anziché Python; un utile contrasto con l'approccio incentrato sul codice di CodeAct (arXiv:2307.16789)
- SWE-bench — valuta gli agenti su problemi reali di GitHub, che richiedono esecuzione di codice multi-passaggio e modifica di file; il benchmark esistente più vicino a ciò che un agente di scrittura su Beancount dovrebbe superare (arXiv:2310.06770)