Do LLMs Need to See Everything? A Benchmark and Study of Failures in LLM-driven Smartphone Automation using Screentext vs. Screenshots

Título: Os LLMs Precisam Ver Tudo? Um Benchmark e Estudo de Falhas na Automação de Smartphones Impulsionada por LLMs usando Screentext vs. Capturas de Tela

1. Problema e Motivação

Com o avanço dos Grandes Modelos de Linguagem (LLMs), agentes móveis autônomos emergiram como ferramentas promissoras para automatizar tarefas em smartphones, simulando interações humanas em interfaces gráficas (GUI). No entanto, esses agentes enfrentam desafios críticos:

• Baixa Precisão: Falhas frequentes na interpretação de instruções e execução de tarefas complexas.
• Falta de Análise de Falhas: Pouco trabalho investigou sistematicamente por que e onde esses modelos falham em cenários do mundo real.
• Questão de Privacidade e Invasividade: A maioria dos agentes atuais depende de capturas de tela (screenshots) como entrada. Isso levanta preocupações sérias sobre privacidade, pois as imagens podem expor mensagens privadas e dados sensíveis.
• Dúvida Central: É realmente necessário o uso de imagens (screenshots) para que os agentes funcionem bem, ou a representação textual da interface (screentext/UI Tree) seria suficiente?

O objetivo do artigo é preencher essa lacuna, investigando as causas das falhas e comparando a eficácia de diferentes modalidades de entrada (texto vs. multimodal) em tarefas cotidianas.

2. Metodologia

2.1. O Benchmark: DailyDroid

Os autores introduzem o DailyDroid, um novo benchmark projetado especificamente para avaliar agentes móveis em cenários do "mundo real" (in-the-wild).

• Estrutura: 75 tarefas distribuídas em 25 aplicativos Android populares.
• Categorias: As tarefas cobrem 5 cenários diários: Produtividade & Ferramentas, Utilitários & Sistema, Acesso à Informação, Mídia & Entretenimento e Comunicação.
• Níveis de Dificuldade: Cada aplicativo possui 3 tarefas (Simples, Média, Difícil), variando desde sequências lineares simples até tarefas multi-etapa com dependências de estado e ambiguidades.
• Reprodutibilidade: As tarefas foram projetadas para evitar dados sensíveis reais e transações pagas, permitindo execução segura e repetível.

2.2. Configuração Experimental

• Modelos de LLM: Foram testados dois modelos da OpenAI:
  • GPT-4o: Modelo base multimodal.
  • o4-mini: Modelo focado em raciocínio (reasoning-oriented).
• Modalidades de Entrada:
  1. Text-Only (Screentext): Utiliza apenas a árvore de interface do usuário (UI Tree) extraída via serviços de acessibilidade do Android (formato HTML simplificado).
  2. Multimodal (Screentext + Screenshot): Combina a árvore de texto com a captura de tela visual da interface.
• Framework: Utilização do framework de código aberto AutoTask para orquestrar percepção, planejamento, ação e memória.
• Escopo: 300 execuções no total (75 tarefas × 2 modalidades × 2 modelos).

2.3. Métricas de Avaliação

• Taxa de Sucesso da Tarefa: Binária (sucesso/fracasso).
• Tipos de Falha: Classificação em falhas de nível de sistema (bloqueios de infraestrutura) e nível de agente (erros de raciocínio).
• Eficiência: Tempo total, tempo efetivo (excluindo latência da API), contagem de passos e uso de tokens.
• Custo: Custo monetário baseado no preço da API da OpenAI.

3. Principais Contribuições

1. DailyDroid Benchmark: Um conjunto de dados padronizado e reprodutível focado em falhas cotidianas, preenchendo a lacuna de benchmarks que priorizam apenas a reprodutibilidade técnica em detrimento da complexidade do mundo real.
2. Análise Comparativa de Modalidades: A primeira comparação sistemática entre entrada puramente textual (screentext) e multimodal (texto + imagem) para automação móvel, abordando o trade-off entre privacidade e desempenho.
3. Manual de Falhas (Failure Handbook): Uma taxonomia detalhada de falhas, categorizando erros em níveis de sistema (recuperação de UI, parsing, lógica) e nível de agente (previsão, reflexão, limites de passos).
4. Diretrizes de Design: Recomendações para desenvolvedores de aplicativos, designers de UI e criadores de agentes para melhorar a acessibilidade e a automação.

4. Resultados Chave

4.1. Desempenho Geral

• Sucesso da Tarefa: As taxas de sucesso foram baixas em geral, variando de 26,7% a 33,3%.
  • O modelo o4-mini superou ligeiramente o GPT-4o (31,3% vs 29,3% de sucesso geral).
  • A modalidade Multimodal teve uma taxa de sucesso marginalmente superior (+4% a +5,7%) em comparação com a modalidade apenas de texto.
• Custo vs. Benefício: A modalidade multimodal aumentou drasticamente o custo (aprox. 25x a 26x mais caro) e o tempo de latência devido ao processamento de imagens, oferecendo apenas um ganho marginal de desempenho.

4.2. Análise de Falhas (Taxonomia)

As falhas foram divididas em duas categorias principais:

• Falhas de Nível de Sistema (~40-42% das falhas): Ocorrem devido a problemas na infraestrutura ou na representação da UI.
  • Recuperação de UI (UI Retrieval): A maior causa de falha (>30%). O agente não consegue acessar elementos da interface (ex: botões ocultos, menus dinâmicos) via API de acessibilidade. Mesmo com screenshots, se o elemento não estiver acessível no sistema, a tarefa falha.
  • Parsing de UI: Dificuldade em mapear a estrutura textual para ações.
    ** Falhas de Nível de Agente (~25-30% das falhas): O sistema funciona, mas o LLM comete erros de raciocínio.
  • Previsão do LLM: O agente entende a tela, mas escolhe a ação errada (ex: confundir campos de entrada).
  • Reflexão: Falha em reconhecer que a tarefa foi concluída ou em corrigir erros anteriores.
  • Limite de Passos: O agente entra em loops ou demora demais, atingindo o limite máximo de passos (10 passos no experimento).

4.3. Impacto dos Modelos e Modalidades

• o4-mini (Raciocínio): Mostrou maior capacidade de auto-correção e adaptação a lógica complexa, mas falhou mais frequentemente ao atingir o limite de passos devido a tentativas de correção iterativa.
• GPT-4o: Tinha mais erros de previsão direta, mas tendia a falhar mais rápido (menos tentativas de correção).
• Modalidade: O uso de screenshots ajudou em tarefas que dependem de pistas visuais não textuais (ícones, cores, layouts complexos), mas não resolveu falhas causadas por falta de acessibilidade na API do sistema.

5. Significado e Implicações

5.1. Acessibilidade de UI é o Gargalo Principal

O estudo revela que a maior barreira para a automação móvel não é a inteligência do LLM, mas a acessibilidade da interface do aplicativo. Muitos aplicativos não expõem elementos críticos via APIs de acessibilidade (screentext), forçando os agentes a dependerem de imagens ou falhando.

• Recomendação: Desenvolvedores devem garantir que todos os elementos interativos tenham identificadores únicos e descrições acessíveis.

5.2. Privacidade vs. Desempenho

Embora a modalidade multimodal (com screenshots) ofereça uma vantagem marginal de desempenho, o custo de privacidade e financeiro é alto.

• Conclusão: Para a maioria das tarefas, o screentext (texto) deve ser priorizado para reduzir riscos de privacidade e custos, a menos que a tarefa dependa estritamente de pistas visuais não textuais.

5.3. Design de Aplicações para Agentes

O artigo propõe que o ecossistema Android precisa evoluir para suportar melhor a automação:

• Criar protocolos de parsing consistentes entre dispositivos.
• Desenvolver APIs padronizadas para interação entre LLMs e Apps (ex: Model Context Protocol - MCP).
• Projetar interfaces que sejam intuitivas tanto para humanos quanto para agentes (ex: evitar lógica de UI contra-intuitiva).

5.4. Limitações e Futuro

O estudo não avaliou a modalidade "apenas screenshot" (sem texto) devido a limitações do framework utilizado, o que é uma área para pesquisa futura. Além disso, a instabilidade das APIs de acessibilidade em versões mais recentes do Android (Android 14+) dificultou a execução em dispositivos de ponta, exigindo o uso de emuladores mais antigos.

Conclusão

O artigo "Do LLMs Need to See Everything?" demonstra que, embora os LLMs estejam evoluindo rapidamente, a automação móvel robusta ainda é limitada pela qualidade da representação da interface do usuário e pela acessibilidade dos aplicativos. A dependência excessiva de screenshots não é uma solução sustentável devido a questões de privacidade e custo. O futuro da automação móvel depende de uma colaboração entre desenvolvedores de apps (para melhorar a acessibilidade), designers de UI e pesquisadores de IA para criar sistemas que sejam eficientes, seguros e confiáveis.