CodeAct: Por qué el código ejecutable de Python hace que los agentes LLM sean un 20% más precisos

Tras leer la semana pasada el artículo sobre "no se puede autocorregir", surge una pregunta natural: si los LLM no pueden auditar sus propios resultados de forma fiable, ¿qué formato de acción ofrece a los agentes la mejor oportunidad de detectar y recuperarse de errores automáticamente? CodeAct, publicado por Xingyao Wang et al. y aceptado en ICML 2024, sostiene que la respuesta es el código Python — no porque el código sea mágico, sino porque un intérprete de Python proporciona exactamente el tipo de retroalimentación externa y determinista que la literatura sobre autocorrección muestra que los LLM necesitan desesperadamente.

El artículo

"Executable Code Actions Elicit Better LLM Agents" (arXiv:2402.01030) de Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng y Heng Ji propone reemplazar los formatos de acción de JSON y texto habituales en los agentes de llamada a herramientas por código Python ejecutable. La idea central es que el código es una mejor lingua franca para las acciones de los agentes que las instrucciones en lenguaje natural o el JSON estructurado, porque el código ya codifica el flujo de control, las dependencias de datos y la composición de varios pasos — y porque los LLM han sido entrenados intensivamente con él.

El artículo presenta tres contribuciones: (1) un argumento conceptual a favor del código como un espacio de acción unificado; (2) M3ToolEval, un nuevo benchmark de 82 tareas seleccionadas por humanos que requieren la composición de múltiples herramientas; y (3) CodeActAgent, un modelo 7B ajustado entrenado con CodeActInstruct, un conjunto de datos de 7.139 trayectorias basadas en código de múltiples turnos que abarcan la recuperación de información, paquetes de software, memoria externa y planificación de robots.

Ideas clave

• En M3ToolEval, GPT-4 con CodeAct logra una tasa de éxito del 74,4% frente al 53,7% con acciones de texto — una mejora absoluta de aproximadamente 20 puntos porcentuales en el entorno multiherramienta más exigente.
• CodeAct requiere aproximadamente un 30% menos de turnos de interacción que los agentes basados en JSON en las mismas tareas. Menos turnos importan: cada viaje de ida y vuelta adicional es otra oportunidad para la propagación de errores.
• El intérprete de Python actúa como una señal de error automática y sin coste. Un cálculo intermedio incorrecto lanza una excepción de inmediato; el agente ve el trazado de error (traceback) y puede revisar sin necesidad de un paso de crítica separado.
• Los modelos de código abierto se benefician más que los de código cerrado. CodeActAgent (Mistral 7B) alcanza el 12,2% en M3ToolEval frente al 3,7% del agente de código abierto más fuerte anteriormente (Lemur-70B con texto). La ventaja es mayor porque Python abunda en los datos de preentrenamiento; los formatos especializados de llamada a herramientas JSON, no.
• CodeActInstruct entrena en cuatro dominios elegidos específicamente para poner a prueba la composición: búsqueda de información, llamadas a paquetes, manipulación de memoria externa y planificación de robots. Todas estas son tareas de varios pasos y dependientes del estado — precisamente los modos de fallo donde los agentes JSON fallan.

Lo que se mantiene — y lo que no

La mejora del 20% en M3ToolEval es real, pero M3ToolEval tiene 82 tareas. Es una muestra pequeña y el artículo no informa sobre intervalos de confianza. El benchmark también está curado por el mismo equipo que propone el método, lo cual es habitual en el campo pero digno de mención. Me gustaría ver esto replicado en un benchmark totalmente independiente antes de tratar el 74,4% como una cifra fiable.

La afirmación de eficiencia — un 30% menos de turnos — es plausible pero confunde dos cosas. Menos turnos podría significar que el agente es más preciso por paso, o podría significar que los fallos terminan antes. El artículo no descompone esto con claridad.

La brecha reconocida entre los modelos de código abierto y cerrado es grande y CodeAct no la explica del todo. CodeActAgent (Mistral 7B) con un 12,2% es mucho mejor que Lemur-70B con un 3,7%, pero GPT-4 con CodeAct está en un 74,4%. El formato ayuda, pero no cierra una brecha de capacidad de 60 puntos. Cualquiera que planee desplegar un agente de Beancount de código abierto debería leer ese número con atención.

La cuestión del sandboxing recibe un solo párrafo. La ejecución de código arbitrario en un contexto financiero no es un caso extremo inconveniente — es la principal preocupación de seguridad. El artículo no aborda qué sucede cuando el agente genera código que borra archivos, realiza llamadas de red o importa librerías inesperadas. Para un agente de contabilidad en producción, el diseño del sandbox es al menos tan importante como el formato de la acción.

Por qué esto es importante para la IA financiera

El problema de la escritura en Beancount es esencialmente el problema para el que CodeAct está diseñado: un agente necesita componer múltiples operaciones (leer el saldo actual, validar la transacción, escribir un nuevo asiento, verificar la ecuación de balance) en un orden específico, con datos fluyendo entre pasos. Las llamadas a herramientas JSON gestionan esto deficientemente porque cada llamada está aislada. Python lo maneja de forma natural.

Más concretamente: un agente de Beancount al estilo CodeAct podría expresar todo un flujo de trabajo de conciliación como un único script de Python — consultando el libro mayor a través de una librería, calculando deltas, proponiendo nuevas entradas y ejecutando bean-check sobre el resultado — todo antes de confirmar nada. El intérprete captura los errores obvios; el LLM solo necesita manejar los semánticos. Es una mejor división del trabajo que pedirle al LLM que valide su propio JSON.

La preocupación por la seguridad va en sentido contrario. Un agente con ejecución de Python sin restricciones sobre un libro contable financiero es una superficie de ataque significativa. El diseño correcto es casi con seguridad un sandbox fuertemente restringido — sin escritura en el sistema de archivos fuera de un directorio temporal designado, sin acceso a la red, sin comandos de shell — combinado con una puerta de enlace obligatoria de bean-check antes de tocar cualquier archivo. CodeAct te da el formato de acción; tú todavía tienes que construir la jaula.

Qué leer a continuación

• OpenHands (antes OpenDevin) — el sistema de agentes de producción construido sobre CodeAct por el mismo grupo de investigación; muestra cómo se implementan realmente el sandboxing y el entorno de ejecución (arXiv:2407.16741).
• ToolBench / ToolLLM — benchmarks y datos de entrenamiento para agentes de llamada a herramientas utilizando APIs REST en lugar de Python; un contraste útil para el enfoque de CodeAct centrado en el código (arXiv:2307.16789).
• SWE-bench — evalúa agentes en problemas reales de GitHub, lo que requiere ejecución de código en varios pasos y edición de archivos; el benchmark existente más cercano a lo que un agente de escritura de Beancount necesitaría superar (arXiv:2310.06770).