WebArena: El benchmark de 812 tareas que mide lo que los agentes web realmente pueden y no pueden hacer

El benchmark de 812 tareas de WebArena es el predecesor directo de WorkArena, del cual hablé ayer. Leerlos consecutivamente aclara una distinción clave: WorkArena mide el trabajo de conocimiento empresarial en una sola plataforma (ServiceNow), mientras que WebArena establece el suelo de capacidad general de los agentes web en software abierto realista. Quiero entender ese suelo con precisión antes de pensar en agentes de Beancount que eventualmente operarán en entornos de navegador.

El artículo

Zhou et al. (ICLR 2024, arXiv:2307.13854) presentan WebArena, un benchmark reproducible de 812 tareas en cuatro sitios web autoalojados: una tienda de comercio electrónico Magento, un foro social Postmill, una instancia de GitLab y un portal de administración de CMS Magento, complementados por un espejo de OpenStreetMap y una copia offline de Wikipedia. A diferencia de las tareas sintéticas de juguete de MiniWoB++, cada sitio de WebArena ejecuta software real de código abierto con una escala auténtica: aproximadamente 90.000 productos, 95 subreddits con más de 127.000 publicaciones y 300 repositorios Git en 1.000 cuentas de desarrolladores. Las tareas abarcan tres categorías: búsqueda de información, navegación por el sitio y cambios de contenido/configuración, y se evalúan según la corrección funcional: si el resultado previsto aparece en la base de datos o coincide con una respuesta exacta/difusa, no si el agente siguió la secuencia de acciones esperada.

Ideas clave

• GPT-4 alcanza el 14,41%; los humanos alcanzan el 78,24%. La brecha es de 63,8 puntos porcentuales. GPT-3.5 obtiene un 8,75%, y la línea base de Google Text-Bison-001 obtiene solo un 5,05%. El prompting de cadena de pensamiento (Chain-of-thought) añade aproximadamente 2,3 puntos para GPT-4, lo cual es útil pero no transformador.
• El fallo más común es la falsa imposibilidad. GPT-4 etiquetó incorrectamente aproximadamente el 54,9% de las tareas realizables (428 de 812) como inviables, devolviendo [N/A] en lugar de intentarlas. Este es el modo de fallo dominante, no las secuencias de acciones ruidosas o los errores de herramientas.
• Corrección funcional, no repetición de trayectoria. La evaluación comprueba cuatro tipos de evidencia: coincidencia exacta, comprobación de palabras clave obligatorias, coincidencia difusa basada en LLM y validación programática mediante consultas a la base de datos o JavaScript. Esto hace que la métrica sea robusta ante paráfrasis, pero sigue siendo susceptible a especificaciones de tareas ambiguas.
• El autoalojamiento en contenedores permite la reproducibilidad. Los cuatro sitios se distribuyen como contenedores Docker, que es lo que replican los benchmarks posteriores (WorkArena, OSWorld). Puedes restablecer el estado y garantizar condiciones iniciales idénticas, algo imposible con el web scraping en vivo.
• Las plantillas de tareas evitan la memorización ciega. 241 plantillas generan 812 tareas instanciadas (3,3 variantes cada una), lo que ayuda un poco, pero no evita que un modelo determinado aprenda los patrones de las plantillas en lugar de los principios de navegación web.
• La complejidad real del DOM es órdenes de magnitud mayor que en MiniWoB++. Una página típica de WebArena se serializa en miles de tokens; trabajos relacionados informan de árboles DOM que superan los 100.000 tokens para vistas de portales complejos.

Qué se mantiene y qué no

La metodología principal es sólida: el software real, la evaluación basada en resultados y los entornos reproducibles son exactamente lo correcto. La cifra del 14,41% ha demostrado ser duradera a través de reproducciones independientes, y la taxonomía de fallos (falsa inviabilidad, comportamientos en bucle, rechazo tímido) ha sido confirmada por múltiples artículos posteriores.

Sin embargo, las limitaciones son reales. Primero, 812 tareas derivadas de 241 plantillas significan que el benchmark es finito y sistemáticamente abarcable; un agente que memorice los patrones de las plantillas podría sobreajustarse sin generalizar. WebArena Verified (2024–2025) descubrió y reparó comprobaciones de evaluación mal alineadas, lo que significa que parte de la cifra original del 14,41% puede reflejar ruido de evaluación en lugar de capacidad pura. Segundo, los cuatro tipos de sitios web (comercio electrónico, foro, alojamiento de código, CMS) son plausibles pero no representan una muestra razonada de la web. No hay SaaS empresarial, ni portales gubernamentales con muchos formularios, ni interfaces bancarias. Tercero, el benchmark ignora por completo la seguridad y la confiabilidad: un agente que logra "borrar esta publicación" obtiene la misma puntuación si borra la publicación correcta o diez más. ST-WebAgentBench (2024) fue diseñado específicamente para abordar esta brecha.

El hallazgo de la falsa inviabilidad es el resultado más interesante y menos valorado. Sugiere que los LLM están calibrados para evitar la acción ante la incertidumbre (una prioridad razonable para modelos entrenados con retroalimentación humana), pero esa calibración conservadora es exactamente incorrecta para tareas de agentes donde no actuar es en sí mismo un error costoso.

Por qué esto importa para la IA financiera

La brecha entre el 14,41% y el 78,24% calibra directamente lo que un agente de navegador de Beancount puede lograr hoy en día sin ingeniería especializada. Si GPT-4 no puede completar de manera confiable tareas web rutinarias (pedir un producto, crear un ticket en GitLab, publicar en un foro), ciertamente no se puede confiar en él para navegar por la interfaz web de Fava sin supervisión. Esto no es un consejo de desesperación; motiva el tipo de interfaces diseñadas específicamente y espacios de acción estructurados que SWE-agent demostró que funcionan para la edición de código. La lección correcta es que la capacidad bruta del LLM medida en tareas genéricas no es lo que importa; lo que importa es cuánto está diseñado el entorno para apoyar al agente.

El problema de la falsa inviabilidad tiene un análogo directo en la contabilidad: un agente que devuelve "No puedo determinar si esta transacción es un duplicado" en lugar de verificarlo, está fallando exactamente de la misma manera conservadora pero errónea. Los agentes de escritura necesitan un paso explícito de verificación de viabilidad que fuerce el compromiso en lugar de la abstención, emparejado con redes de seguridad de reversión (rollback) para que cometer un error al comprometerse sea recuperable.

Específicamente para Beancount, la parte de CMS + portal de administración de WebArena (administración de Magento) es el análogo estructural más cercano a la interfaz web de Fava: una interfaz de administración de varias páginas con formularios complejos, navegación anidada y un estado que persiste entre sesiones. El techo del 14,41% en esa clase de tareas es lo que debo tratar como la suposición por defecto hasta que demostremos algo mejor.

Qué leer a continuación

• VisualWebArena (Koh et al., 2024, arXiv:2401.13649): extiende WebArena a agentes multimodales utilizando capturas de pantalla, lo cual es importante para Fava ya que no todo el estado relevante está en el DOM.
• OSWorld (Xie et al., NeurIPS 2024, arXiv:2404.07972): benchmark de entorno de escritorio completo; 12,24% para el mejor modelo multimodal frente al 72,36% humano, extendiendo la brecha de capacidad a la automatización de GUI más allá del navegador.
• ST-WebAgentBench (arXiv:2410.06703): aborda directamente la brecha de seguridad en WebArena, midiendo si los agentes web respetan las restricciones de políticas mientras completan las tareas.