WebArena: O Benchmark de 812 Tarefas que Mede o que Agentes Web Realmente Podem e Não Podem Fazer

O benchmark de 812 tarefas do WebArena é o antecessor direto do WorkArena, que cobri ontem. Lê-los em sequência esclarece uma distinção fundamental: o WorkArena mede o trabalho de conhecimento empresarial em uma única plataforma (ServiceNow), enquanto o WebArena estabelece o patamar básico de capacidade de agentes web gerais em softwares abertos realistas. Quero entender esse patamar com precisão antes de pensar em agentes Beancount que eventualmente operarão em ambientes de navegador.

O artigo

Zhou et al. (ICLR 2024, arXiv:2307.13854) apresentam o WebArena, um benchmark reproduzível de 812 tarefas em quatro sites auto-hospedados: uma loja de e-commerce Magento, um fórum social Postmill, uma instância do GitLab e um portal administrativo de CMS Magento, suplementados por um espelho do OpenStreetMap e uma cópia offline da Wikipedia. Diferente das tarefas sintéticas de brinquedo do MiniWoB++, cada site do WebArena executa software de código aberto real com escala autêntica: aproximadamente 90.000 produtos, 95 subreddits com mais de 127.000 postagens e 300 repositórios Git em 1.000 contas de desenvolvedores. As tarefas abrangem três categorias — busca de informação, navegação no site e mudanças de conteúdo/configuração — e são avaliadas quanto à correção funcional: se o resultado pretendido aparece no banco de dados ou corresponde a uma resposta exata/aproximada (fuzzy), e não se o agente seguiu a sequência de ações esperada.

Ideias principais

• O GPT-4 atinge 14,41%; humanos atingem 78,24%. A lacuna é de 63,8 pontos percentuais. O GPT-3.5 pontua 8,75%, e a base de referência do Google Text-Bison-001 pontua apenas 5,05%. O prompting de cadeia de pensamento (chain-of-thought) adiciona cerca de 2,3 pontos para o GPT-4 — útil, mas não transformador.
• A falha mais comum é a falsa impossibilidade. O GPT-4 rotulou incorretamente cerca de 54,9% das tarefas realizáveis (428 de 812) como inviáveis, retornando [N/A] em vez de tentá-las. Este é o modo de falha dominante, não sequências de ações ruidosas ou erros de ferramentas.
• Correção funcional, não repetição de trajetória. A avaliação verifica quatro tipos de evidências: correspondência exata, verificações de palavras-chave obrigatórias, correspondência aproximada baseada em LLM e validação programática via consultas ao banco de dados ou JavaScript. Isso torna a métrica robusta a paráfrases, mas ainda suscetível a especificações de tarefas ambíguas.
• A auto-hospedagem em contêineres permite a reprodutibilidade. Todos os quatro sites são distribuídos como contêineres Docker, o que benchmarks posteriores (WorkArena, OSWorld) replicaram. Você pode resetar o estado e garantir condições iniciais idênticas, algo impossível com web scraping ao vivo.
• Modelos de tarefas evitam a memorização cega. 241 modelos geram 812 tarefas instanciadas (3,3 variantes cada), o que ajuda um pouco, mas não impede que um modelo determinado aprenda padrões de modelos em vez de princípios de navegação web.
• A complexidade real do DOM é ordens de magnitude maior que a do MiniWoB++. Uma página típica do WebArena se serializa em milhares de tokens; trabalhos relacionados relatam árvores DOM excedendo 100.000 tokens para visualizações de portais complexos.

O que se sustenta — e o que não

A metodologia central é sólida: software real, avaliação baseada em resultados e ambientes reproduzíveis estão exatamente corretos. O número de 14,41% provou-se duradouro em reproduções independentes, e a taxonomia de falhas (falsa inviabilidade, comportamentos de loop, recusa tímida) foi confirmada por vários artigos subsequentes.

As limitações são reais, no entanto. Primeiro, 812 tarefas derivadas de 241 modelos significam que o benchmark é finito e sistematicamente coberturável; um agente que memorize padrões de modelos poderia sofrer overfitting sem generalizar. O WebArena Verified (2024–2025) descobriu e reparou verificações de avaliação desalinhadas, o que significa que parte da cifra original de 14,41% pode refletir ruído de avaliação em vez de pura capacidade. Segundo, os quatro tipos de sites — e-commerce, fórum, hospedagem de código, CMS — são plausíveis, mas não uma amostra fundamentada da web. Não há SaaS corporativo, nenhum portal governamental repleto de formulários, nenhuma interface bancária. Terceiro, o benchmark ignora inteiramente a segurança e a confiabilidade: um agente que obtém sucesso em "deletar esta postagem" ganha a mesma pontuação, quer delete a postagem correta ou dez outras. O ST-WebAgentBench (2024) foi projetado especificamente para abordar essa lacuna.

A descoberta da falsa inviabilidade é o resultado mais interessante e subestimado. Sugere que os LLMs são calibrados para evitar ações sob incerteza — uma premissa razoável para modelos treinados com feedback humano — mas que essa calibração conservadora é exatamente errada para tarefas de agentes, onde não agir é, por si só, um erro dispendioso.

Por que isso importa para a IA financeira

A lacuna entre 14,41% e 78,24% calibra diretamente o que um agente de navegador Beancount pode alcançar hoje sem engenharia especializada. Se o GPT-4 não consegue concluir de forma confiável tarefas web rotineiras — encomendar um produto, criar um issue no GitLab, postar em um fórum — ele certamente não pode ser confiável para navegar na interface web do Fava sem supervisão. Isso não é um conselho de desespero; motiva o tipo de interfaces construídas para propósitos específicos e espaços de ação estruturados que o SWE-agent demonstrou funcionar para edição de código. A lição correta é que a capacidade bruta do LLM medida em tarefas genéricas não é o que importa; o que importa é o quanto o ambiente é projetado para suportar o agente.

O problema da falsa inviabilidade tem um análogo direto na contabilidade: um agente que retorna "Não consigo determinar se esta transação é uma duplicata" em vez de verificar está falhando da mesma maneira conservadora, porém errada. Agentes de gravação (write-back) precisam de uma etapa explícita de verificação de viabilidade que force o comprometimento em vez da abstenção, combinada com redes de segurança de rollback para que um comprometimento incorreto seja recuperável.

Especificamente para o Beancount, a porção de CMS + portal administrativo do WebArena (admin do Magento) é o análogo estrutural mais próximo da interface web do Fava: uma interface administrativa de várias páginas com formulários complexos, navegação aninhada e estado que persiste entre as sessões. O teto de 14,41% nessa classe de tarefa é o que devo tratar como a suposição padrão até demonstrarmos algo melhor.

O que ler a seguir

• VisualWebArena (Koh et al., 2024, arXiv:2401.13649) — estende o WebArena para agentes multimodais usando capturas de tela, o que importa para o Fava, já que nem todo estado relevante está no DOM.
• OSWorld (Xie et al., NeurIPS 2024, arXiv:2404.07972) — benchmark de ambiente de desktop completo; 12,24% para o melhor modelo multimodal vs. 72,36% humano, estendendo a lacuna de capacidade para a automação de interface gráfica (GUI) além do navegador.
• ST-WebAgentBench (arXiv:2410.06703) — aborda diretamente a lacuna de segurança no WebArena, medindo se os agentes web respeitam as restrições de política ao concluir tarefas.