CodeAct: Per què el codi Python executable fa que els agents LLM siguin un 20% més precisos

Després de llegir l'article "cannot self-correct" la setmana passada, una pregunta natural que sorgeix és: si els LLM no poden auditar amb fiabilitat la seva pròpia producció, quin format d'acció ofereix als agents la millor oportunitat de detectar i recuperar-se dels errors automàticament? CodeAct, publicat per Xingyao Wang et al. i acceptat a l'ICML 2024, argumenta que la resposta és el codi Python, no perquè el codi sigui màgic, sinó perquè un intèrpret de Python proporciona exactament el tipus de retroalimentació externa i determinista que la literatura sobre l'autocorrecció mostra que els LLM necessiten desesperadament.

L'article

"Executable Code Actions Elicit Better LLM Agents" (arXiv:2402.01030) de Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng i Heng Ji proposa substituir els formats d'acció de text i JSON comuns en els agents que utilitzen crides d'eines per codi Python executable. La idea central és que el codi és una millor llengua franca per a les accions dels agents que les instruccions en llenguatge natural o el format JSON estructurat, perquè el codi ja codifica el flux de control, les dependències de dades i la composició de diversos passos, i perquè els LLM han estat entrenats intensament amb ell.

L'article fa tres contribucions: (1) un argument conceptual per al codi com a espai d'acció unificat; (2) M3ToolEval, un nou banc de proves de 82 tasques curades per humans que requereixen una composició multi-eina; i (3) CodeActAgent, un model 7B ajustat entrenat amb CodeActInstruct, un conjunt de dades de 7.139 trajectòries basades en codi de diversos torns que abasten la recuperació d'informació, els paquets de programari, la memòria externa i la planificació de robots.

Idees clau

• A M3ToolEval, el GPT-4 amb CodeAct aconsegueix una taxa d'èxit del 74,4% en comparació amb el 53,7% amb accions de text, una millora absoluta d'uns 20 punts percentuals en l'entorn multi-eina més exigent.
• CodeAct requereix aproximadament un 30% menys de torns d'interacció que els agents basats en JSON per a les mateixes tasques. Menys torns és important: cada viatge d'anada i tornada addicional és una altra oportunitat per a la propagació d'errors.
• L'intèrpret de Python actua com un senyal d'error automàtic i sense cost. Un càlcul intermedi erroni genera una excepció immediatament; l'agent veu la traça (traceback) i pot revisar-la sense un pas de crítica separat.
• Els models de codi obert es beneficien més que els de codi tancat. CodeActAgent (Mistral 7B) arriba al 12,2% a M3ToolEval enfront del 3,7% de l'agent de codi obert més fort anteriorment (Lemur-70B amb text). L'efecte palanca és més gran perquè Python és abundant en les dades d'entrenament previ; els formats especialitzats de crides d'eines JSON no ho són.
• CodeActInstruct entrena en quatre dominis escollits específicament per posar a prova la composició: cerca d'informació, crides a paquets, manipulació de memòria externa i planificació de robots. Totes aquestes són tasques de diversos passos i dependents de l'estat, precisament els modes de fallada on els agents JSON solen fallar.

Què es manté i què no

La millora del 20% a M3ToolEval és real, però M3ToolEval té 82 tasques. Es tracta d'una mostra petita i l'article no informa dels intervals de confiança. El banc de proves també està comissariat pel mateix equip que proposa el mètode, cosa que és habitual en el camp però que val la pena assenyalar. M'agradaria veure això replicat en un banc de proves totalment independent abans de considerar el 74,4% com una xifra fiable.

L'afirmació d'eficiència (un 30% menys de torns) és plausible, però combina dues coses. Menys torns podria significar que l'agent és més precís a cada pas, o podria significar que els errors acaben abans. L'article no desglossa això clarament.

La bretxa reconeguda entre els models de codi obert i els de codi tancat és gran i CodeAct no l'explica. CodeActAgent (Mistral 7B) amb un 12,2% és molt millor que Lemur-70B amb un 3,7%, però GPT-4 amb CodeAct està en el 74,4%. El format ajuda, però no tanca una bretxa de capacitat de 60 punts. Qualsevol que planegi desplegar un agent de Beancount de codi obert hauria de llegir aquest número amb atenció.

La qüestió de l'aïllament (sandboxing) rep un sol paràgraf. L'execució de codi arbitrari en un context financer no és un cas extrem inconvenient: és la principal preocupació de seguretat. L'article no aborda què passa quan l'agent genera codi que esborra fitxers, fa crides de xarxa o importa biblioteques inesperades. Per a un agent de comptabilitat en producció, el disseny de l'entorn d'aïllament és almenys tan important com el format d'acció.

Per què això és important per a la IA en finances

El problema de l'escriptura (write-back) a Beancount és essencialment el problema per al qual s'ha dissenyat CodeAct: un agent necessita compondre múltiples operacions (llegir el saldo actual, validar la transacció, escriure un nou apunt, verificar l'equació del saldo) en un ordre específic, amb dades que flueixen entre els passos. Les crides d'eines JSON gestionen això malament perquè cada crida està aïllada. Python ho gestiona de manera natural.

Més concretament: un agent de Beancount a l'estil CodeAct podria expressar tot un flux de treball de conciliació com un únic script de Python (consultant el llibre major mitjançant una biblioteca, calculant les diferències, proposant nous assentaments i executant bean-check sobre el resultat) abans de confirmar res. L'intèrpret detecta els errors obvis; l'LLM només ha de gestionar els semàntics. Aquesta és una millor divisió del treball que demanar a l'LLM que validi el seu propi JSON.

La preocupació per la seguretat va en l'altre sentit. Un agent amb execució de Python sense restriccions sobre un llibre major financer és una superfície d'atac significativa. El disseny correcte és, gairebé segur, un entorn d'aïllament molt restringit (sin escriptura en el sistema de fitxers fora d'un directori temporal designat, sense accés a la xarxa, sense ordres de shell) combinat amb una porta de verificació bean-check obligatòria abans de tocar qualsevol fitxer. CodeAct et dona el format d'acció; tu encara has de construir la gàbia.

Què llegir a continuació

• OpenHands (anteriorment OpenDevin) — el sistema d'agents de producció basat en CodeAct pel mateix grup de recerca; mostra com s'implementen realment l'aïllament i l'entorn d'execució (arXiv:2407.16741)
• ToolBench / ToolLLM — bancs de proves i dades d'entrenament per a agents de crida d'eines que utilitzen API REST en lloc de Python; un contrast útil amb l'enfocament basat primer en el codi de CodeAct (arXiv:2307.16789)
• SWE-bench — avalua agents en problemes reals de GitHub, cosa que requereix l'execució de codi en diversos passos i l'edició de fitxers; el banc de proves existent més proper al que hauria de superar un agent d'escriptura per a Beancount (arXiv:2310.06770)