Agente de 8B para iOS supera o Gemini-3.5-Flash no UINavBench e empata com o Gemini-3.1-Pro

Uma equipe de pesquisadores propôs um jeito de treinar modelos pequenos de navegação por interfaces não com demonstrações gravadas, mas em interação ao vivo com aplicativos iOS de verdade. O agente resultante, com 8 bilhões de parâmetros, superou o Gemini-3.5-Flash e o Qwen3.8-27B no UINavBench — um benchmark de apps iOS reais cujo sucesso é verificado por um juiz VLM — e empatou com o Gemini-3.1-Pro. No AndroidWorld, ou seja, em outro sistema operacional que o agente não viu no treinamento, a taxa de sucesso é quase sete vezes maior que a do modelo base após o SFT.

Por que dividir o agente em planejador e «apontador»

O problema que motiva o trabalho é conhecido por quem já tentou construir agentes de UI. Os modelos de fronteira dão conta de navegar pela tela, mas chegam a custar alguns dólares por tarefa, o que é caro demais para o uso diário. Modelos pequenos treinados com SFT ou RL offline decoram as trajetórias dos dados de treino. Basta o app mostrar uma tela inesperada para o agente não saber como voltar ao caminho.

Os autores dividiram o sistema em duas partes. O planejador olha a captura de tela, guarda o histórico dos passos anteriores e, por meio de uma cadeia de raciocínio, produz o passo atual e um plano de longo prazo. Um modelo separado de ancoragem (grounding) transforma esse passo em uma ação concreta e nas coordenadas do toque.

A ancoragem é uma tarefa quase determinística, e o SFT comum a resolve bem. Por isso, o RL, que é caro, é usado apenas no planejador. Ele parte do Qwen3-VL-8B-Instruct, ajustado com trajetórias humanas, incluindo o conjunto público GUIOdyssey, voltado a cenários de troca entre aplicativos.

O planejador também tem uma ação de esclarecimento: se a tarefa foi formulada de modo incompleto, ele pode perguntar as preferências ao usuário.

Recompensa a cada passo e estabilização do crítico

O treinamento se baseia em um LLM juiz que emite dois sinais. A recompensa densa avalia cada passo: se ele aproxima da meta e se não há alucinações nem ciclos sem sentido. A recompensa terminal verifica se a tarefa foi concluída por inteiro. O sinal denso é necessário onde o sucesso final é raro: o agente recebe retorno mesmo em episódios fracassados e aprende a sair de estados inesperados.

A otimização usa PPO com estimativa de vantagem por passo (GAE). Aqui os autores descrevem um problema conhecido: quando os passos são recompensados, o agente passa a alongar a trajetória. Para evitar isso, aplicaram desconto assimétrico: as recompensas locais pelo processo são descontadas, e a recompensa pela conclusão da tarefa não.

A segunda novidade é o GiGPPO. O método estima o valor do estado levando em conta recompensas de estados visualmente parecidos em trajetórias paralelas. Isso estabiliza o crítico. Os autores destacam a diferença em relação ao GiGPO, em que a linha de base é calculada sobre estados que se repetem exatamente: no ambiente deles, esses estados quase sempre são únicos. Por isso, o sinal passa por uma função de valor treinável. Segundo os autores, tanto a recompensa densa quanto o GiGPPO aceleram a convergência, e o resultado é melhor que o do SFT e o do RL com apenas recompensa terminal.

Infraestrutura: 512 iPhones virtuais

O RL online exige um número enorme de interações reais. Os autores montaram um pool de dispositivos iOS virtuais na nuvem, controlados por VNC com um conjunto de ações como tap, swipe, type, long press, home e wait. Cada dispositivo é configurado uma vez: instalam-se os apps, faz-se login no Apple ID e tira-se um snapshot. Depois, cada episódio termina com a volta ao snapshot, em vez de recriar a sessão, e a reinicialização leva cerca de 10 segundos. Rodam 512 trajetórias simultâneas, cada uma com seu próprio dispositivo. Os autores afirmam que este é o primeiro treinamento em larga escala de agentes de UI inteiramente em dispositivos iOS reais com aplicativos de verdade.

O que levar em conta

É um preprint, e a descrição disponível não traz percentuais exatos de sucesso nos benchmarks. Por isso, o «quase sete vezes» se refere à base SFT, que é baixa, no AndroidWorld, e não a um patamar absoluto. A avaliação no UINavBench depende de um juiz VLM, enquanto as recompensas do treinamento vêm de um juiz LLM, então erros dos juízes podem afetar tanto o treinamento quanto a medição. A comparação com o Gemini foi feita em um benchmark específico de apps iOS reais e não necessariamente se transfere para quaisquer tarefas.

A conclusão prática para equipes que desenvolvem agentes móveis: separar planejamento e ancoragem, somado à recompensa por passo dada por um juiz, permite extrair de um modelo de 8B qualidade de nível de modelos de fronteira em um domínio estreito. O custo dessa abordagem é ter uma fazenda própria de dispositivos virtuais, e, pelo que o trabalho indica, é ela que se torna a principal condição para escalar.