Benchmark expõe falha de agentes de IA diante de pedidos vagos e com histórico longo

O problema que os benchmarks atuais não testam

Um agente de GUI (sigla para interface gráfica, a tela de um aplicativo) é um sistema de IA que opera um app como uma pessoa faria: toca em botões, digita em campos, navega entre telas. A maioria dos testes usados para avaliar esses agentes dá instruções precisas e sem contexto prévio, do tipo "abra o app de agenda e marque uma reunião às 14h de quinta". É um cenário limpo, mas não é como as pessoas realmente falam com um assistente.

No uso real, o pedido costuma ser vago porque o próprio usuário já esqueceu os detalhes da ação anterior: "marca aquele compromisso que eu falei ontem" ou "manda pra ela de novo aquele arquivo que separei semana passada". O agente precisa recuperar o que falta vasculhando um histórico de interações longo e cheio de ruído, não apenas executar uma ordem completa.

Esse é o espaço que o paper MemU-Bench: Benchmarking GUI Agents on Long-Horizon User Interactions tenta preencher. O trabalho foi submetido ao arXiv em 30 de outubro de 2026 por Yizhou Liu e outros 14 coautores, sob o identificador arXiv:2611.00191, e propõe um benchmark mobile desenhado especificamente para expor esse tipo de falha.

Como o MemU-Bench mede isso

O benchmark reúne 118 tarefas vagas construídas em cima de 29 trajetórias de usuário de longo prazo, ou seja, sequências extensas de ações reais de uso de celular, espalhadas por vários aplicativos, que servem de "memória de fundo" para o agente consultar. A verificação de acerto não olha se a tela parece certa: ela checa o estado final de bancos de dados serializados dos próprios aplicativos, o que torna o critério objetivo e difícil de enganar.

Além da métrica óbvia de Success Rate (tarefa concluída ou não), os autores propõem duas métricas adicionais para evitar que um agente "ganhe" o teste na base da força bruta:

• Interaction Efficiency (IE): mede quanto esforço de interação o agente gastou para chegar ao resultado.
• Success weighted by Path Length (SPL): penaliza o sucesso quando o agente só chegou lá vasculhando exaustivamente vários apps, em vez de recuperar a informação certa de forma direta a partir da memória.

A lógica por trás do SPL é simples de entender: um agente que abre dez apps até achar o certo "acertou", mas não demonstrou que entendeu o histórico. Um agente que vai direto ao ponto, porque recuperou o contexto certo, mostra competência real de memória, e é isso que a métrica tenta capturar.

Os números mostram que ninguém resolveu isso ainda

Os resultados reportados no paper são desconfortáveis para quem já vende produto de "assistente que lembra tudo". Sem acesso ao histórico do usuário, o modelo com melhor desempenho no teste, Gemini-3.1-Pro, chegou a apenas 16,4% de SPL. Agentes de GUI ponta a ponta (sistemas que processam a tela diretamente, sem separar uma etapa de raciocínio textual de uma etapa de ação) ficaram abaixo de 5%.

Esses números batem de frente com a narrativa comum de que modelos de ponta já "entendem contexto" o suficiente para operar como assistente pessoal em apps. O que o MemU-Bench mostra é que entender uma frase vaga dentro de uma conversa é uma coisa; recuperar a informação certa dentro de um histórico longo de ações em múltiplos aplicativos é outra, e a segunda ainda quebra a maioria dos sistemas testados.

AppMem: uma camada de memória que não exige retreinar o modelo

Diante desse resultado, os mesmos autores propõem o AppMem, descrito como um framework training-free, ou seja, que não exige ajuste fino (fine-tuning) do modelo base: ele funciona como uma camada externa que qualquer agente pode usar por cima. O funcionamento tem três partes:

1. Destila o histórico bruto de interações em um banco de memória estruturado e organizado por aplicativo (app-centric), em vez de guardar tudo como texto corrido.
2. Rastreia intenções interrompidas quando o usuário troca de app no meio de uma tarefa, para não perder o fio do que ele estava tentando fazer.
3. Recupera seletivamente só as memórias relevantes usando uma etapa de inferência do app alvo (target-app inference), em vez de buscar em todo o histórico de uma vez.

O ganho reportado é expressivo: aplicado ao GPT-5.5, o AppMem eleva o SPL de 15,7% para 66,9%, um salto de 51,2 pontos percentuais. O paper também compara o AppMem contra uma linha de base mais simples, que apenas resume o histórico em texto corrido (naive summary baseline), e mostra uma vantagem de 9,3 pontos percentuais sobre essa abordagem ingênua, com ganhos consistentes em diferentes modelos de base testados.

Em resumo: o salto de desempenho não vem de um modelo maior ou mais caro, vem de organizar a memória por aplicativo e inferir qual app importa antes de buscar o contexto, em vez de jogar tudo num resumo genérico esperando que o modelo encontre a agulha no palheiro sozinho.

O que fica em aberto para quem constrói agentes

O paper não traz números de custo computacional ou de tokens gastos por chamada do AppMem, então qualquer equipe que for reproduzir essa arquitetura precisa medir isso na própria mão: cada etapa de inferência do app alvo é uma chamada extra ao modelo, o que soma latência e custo por interação além da chamada principal do agente. Isso é um trade-off real: mais acerto em troca de mais uma camada de processamento no caminho crítico.

Para quem está montando agentes que operam apps de verdade, seja um assistente de automação interno, um bot de suporte que opera sistemas internos ou uma ferramenta de RPA com IA, a lição prática do MemU-Bench é que dump de histórico de chat como contexto não é suficiente. A estrutura importa: organizar memória por aplicativo, rastrear intenção interrompida entre trocas de contexto e inferir onde buscar antes de buscar parecem fazer mais diferença do que só aumentar a janela de contexto do modelo.

Vale notar que o trabalho é uma proposta de pesquisa recém-publicada, sem menção no material a repositório de código liberado ou integração com frameworks de agentes já estabelecidos. Antes de adotar o padrão do AppMem em produção, times devem acompanhar se os autores liberam implementação de referência, porque hoje a reprodução exige construir o pipeline de memória descrito no paper do zero.

Fonte: arXiv cs.AI