Ir al contenido principal

AgentBench: Evaluación de LLMs como agentes — Lecciones para la fiabilidad de la IA en finanzas

· 7 min de lectura
Mike Thrift
Mike Thrift
Marketing Manager

Cuando me pregunto qué es lo que un agente de escritura de Beancount realmente necesita hacer de manera confiable, la respuesta no es "generar texto", sino "tomar una secuencia de acciones en un entorno estructurado sin salirse de control". AgentBench (Liu et al., Tsinghua, ICLR 2024) es uno de los primeros intentos serios de medir esa capacidad a escala, y las cifras del análisis de 2023 aún contienen lecciones que vale la pena extraer.

El artículo

2026-05-06-agentbench-evaluating-llms-as-agents

AgentBench, desarrollado por Xiao Liu y otros 21 coautores de la Universidad de Tsinghua, define ocho entornos diseñados para poner a prueba los LLM como agentes interactivos en lugar de generadores de texto pasivos. Cinco entornos son originales: SO (interacción con bash), Base de datos (generación de SQL y recuperación de errores), Grafo de conocimiento (consultas estructuradas basadas en herramientas), Juego de cartas digitales (competencia estratégica de múltiples turnos) y Acertijos de pensamiento lateral (diálogo deductivo). Tres son adaptados de conjuntos de datos anteriores: Gestión del hogar de ALFWorld, Compras web de WebShop y Navegación web de Mind2Web. El artículo evalúa 27 modelos —modelos de API comerciales y modelos de código abierto de hasta 70B— a través de aproximadamente 4,000 generaciones de división de desarrollo y 13,000 de división de prueba, e informa tanto las tasas de éxito por entorno como una puntuación general compuesta.

Ideas clave

  • GPT-4 lidera con una puntuación general de 4,01. Claude-2 obtiene 2,49 y GPT-3.5-turbo 2,32. CodeLlama-34B, el modelo de código abierto más sólido en el momento de la presentación, puntúa solo 0,96. Los modelos basados en API promedian 2,24 en total frente a 0,42 de los de código abierto.
  • GPT-4 obtiene un 42,4% en SO, un 32,0% en Base de datos y un 78,0% en Gestión del hogar; la dispersión revela qué entornos premian el seguimiento de instrucciones frente al razonamiento estructurado.
  • "Límite de tareas excedido" es el modo de fallo dominante: el 67,9% de los fallos en Grafos de conocimiento agotaron el presupuesto de pasos antes de resolver la tarea. Este es un fallo de razonamiento de largo horizonte, no un fallo de conocimiento.
  • Los errores de cumplimiento de formato representan el 53,3% de los fallos en las tareas de Base de datos: el agente produce un SQL sintácticamente incorrecto o envuelve las consultas en prosa que el evaluador no puede analizar.
  • La selección de acciones inválidas motiva el 64,1% de los fallos en Gestión del hogar: el agente nombra una acción que no está disponible en el estado actual.
  • El entrenamiento en código tiene "impactos ambivalentes en las tareas": ayuda en entornos de seguimiento de procedimientos, pero puede perjudicar el razonamiento general en entornos con mucha carga de diálogo.

Qué se mantiene — y qué no

La elección del diseño principal —evaluación interactiva, de múltiples turnos y múltiples entornos— es correcta y sigue siendo poco utilizada. La mayoría de los benchmarks de LLM todavía miden la calidad de la generación de un solo turno; AgentBench insiste correctamente en que los agentes deben seguir tomando decisiones hasta que se complete una tarea o se agote el presupuesto.

Dicho esto, la instantánea está fechada de una manera que importa. La brecha entre GPT-4 (4,01) y el mejor modelo de código abierto (0,96) parecía alarmante a mediados de 2023, pero se ha cerrado en gran medida para 2025. Modelos como Llama 3.1 70B o Qwen 2.5 72B ahora superan listones de seguimiento de instrucciones y cumplimiento de formato que eran obstáculos novedosos hace dos años. Leer el artículo como evidencia de que "el código abierto no puede realizar tareas agénticas" sería un error; leerlo como evidencia de que "el cumplimiento del formato y la consistencia de largo horizonte son los problemas difíciles" sigue siendo válido.

También hay una tensión entre amplitud y profundidad. Ocho entornos suenan exhaustivos, pero cada uno es relativamente superficial. WebArena (Zhou et al., 2024) cubre la navegación web por sí sola con 812 tareas de largo horizonte basadas en plantillas; OSWorld (Xie et al., 2024) evalúa 369 tareas reales de escritorio en Ubuntu y Windows. AgentBench puede ofrecer una señal a través de varios entornos, pero no sustituirá a un benchmark específico de dominio una vez que hayas identificado el entorno que te interesa.

La taxonomía de modos de fallo en la Tabla 4 es probablemente la contribución más duradera. Los autores descomponen los fallos en Límite de tareas excedido, Error de formato, Acción inválida, entre otros. Estos no son errores de implementación: son debilidades estructurales en cómo los LLM mantienen el estado, rastrean las acciones disponibles y producen resultados analizables bajo la presión de múltiples turnos. Cualquier sistema de agentes serio debe abordarlos.

Por qué esto importa para la IA financiera

Los tres modos de fallo dominantes se corresponden casi directamente con lo que esperaría que rompiera un agente de escritura de Beancount.

Límite de tareas excedido es el modo de fallo de la conciliación del libro mayor. Conciliar un cierre de período de múltiples cuentas requiere verificar los saldos iniciales, cuadrar cargos y abonos, identificar discrepancias y proponer correcciones; una cadena que puede alcanzar fácilmente los 10 o 20 pasos. Un agente que agote su contexto o presupuesto de pasos a mitad de la cadena y se rinda no solo falla con elegancia, sino que puede dejar el libro mayor en un estado parcialmente modificado.

Error de formato es el modo de fallo de la entrada de transacciones. Beancount tiene una sintaxis estricta: un asiento mal formado (moneda faltante, sangría incorrecta, etiqueta inválida) es un error de análisis que corrompe el archivo. Un agente que genere prosa alrededor de su salida de Beancount, o que produzca una sintaxis que parezca correcta pero con el formato equivocado, es inútil. Este es el problema central del artículo CRITIC aplicado a un dominio más estricto.

Acción inválida es el problema de la seguridad de la escritura. Un agente de Beancount que opere en un libro mayor real tiene un conjunto limitado de operaciones seguras: añadir una transacción, corregir una etiqueta, mover un asiento. Alucinar una acción fuera de ese conjunto —por ejemplo, eliminar una cuenta que aún tiene posiciones abiertas— es un fallo de corrección que podría no detectarse hasta una auditoría.

El hallazgo de que "el entrenamiento en código tiene impactos ambivalentes" también es relevante. La escritura de Beancount está más cerca de la generación de código que de la recuperación de conocimientos, por lo que un modelo preentrenado en código debería ser un ajuste natural. Pero si el entrenamiento en código degrada el seguimiento de diálogos en entornos de múltiples turnos, es necesaria una evaluación híbrida (como la de AgentBench) para detectar esos compromisos antes del despliegue.

Qué leer a continuación

  • WebArena (Zhou et al., 2024; arXiv:2307.13854) — 812 tareas de navegación web en un entorno de navegador real; el seguimiento profundo del nivel basado en web de AgentBench.
  • OSWorld (Xie et al., 2024; NeurIPS 2024) — benchmark completo de entorno de escritorio que incluye tareas de sistema de archivos y GUI; el entorno de SO de OSWorld es un sucesor directo y más profundo del nivel de SO de AgentBench.
  • TAU-bench (Yao et al., 2024) — evalúa agentes en entornos de API de comercio minorista y aerolíneas con uso de herramientas reales y simulación de usuarios; el benchmark publicado más cercano a un entorno de libro mayor de Beancount.