GenUI-Harness leva modelo de 4B de 9,33% a 58% em Pass@3 e supera o Claude Opus 5

A equipe por trás de um artigo no arXiv propôs o GenUI-Harness: uma camada multiagente em que o modelo responde a uma solicitação complexa não com um parágrafo de texto, mas com uma interface temporária, com formulários, listas e seleção de parâmetros. Após o treinamento por reforço, um modelo de 4 bilhões de parâmetros subiu de 9,33% para 58,00% em Pass@3 e superou o Claude Opus 5, que marcou 46,67%. Em uma pesquisa com avaliadores, a duração média do diálogo caiu de 3,4 para 1,2 rodadas.

Dois agentes em vez de um chat

A arquitetura é simples. O Tool Agent cuida da busca de informações e da execução de tarefas: acessa bancos de dados e chama ferramentas. O GUI Coder Agent analisa a solicitação e o resultado, identifica ambiguidades e escreve o código de front-end de uma interface estruturada. Se o usuário pede para "trocar o voo", o agente não faz cinco perguntas de esclarecimento em sequência. Ele exibe um formulário com as opções reais do banco de dados.

Os autores partem da premissa de que o texto, como canal para tarefas complexas, sobrecarrega a pessoa. Ele gera ambiguidade, ruído informacional e uma digitação lenta. Uma interface montada para dados específicos e para uma etapa específica da tarefa elimina esses problemas.

Como treinar um gerador de interfaces

A principal contribuição de engenharia do trabalho está em como treinar o GUI Coder com RL. Há dois problemas, e cada um tem sua solução.

Primeiro: uma recompensa verificável para uma UI interativa exige a execução real do código, o que é caro. Para isso, os autores criaram o Dynamic UX, um pacote leve que oferece, em um único sandbox, interação dinâmica e coleta de recompensas.

Segundo: quando a recompensa vem de um LLM usado como juiz, o modelo aprende rápido a enganá-lo. Contra o reward hacking, foi proposto o Reward Auditor, uma metarrecompensa. Ele acompanha a distribuição das recompensas, identifica padrões de diagnóstico e os reúne em uma rubrica comum e em uma especificação de avaliação. O juiz não permanece fixo ao longo do treinamento.

Benchmark e números

Para a validação, os autores criaram o UI-TAU Bench. Ele é construído sobre 10 bases de dados de domínios reais, provenientes de fontes abertas, e se baseia na formulação do Tau-Bench para tool use. Há versões Lite (300 tarefas) e Full (1000 tarefas).

• Ganho médio de Pass@3 sobre o smolagents no Lite: 4,48 p.p.
• Modelo de 4B após o treinamento no GenUI-Harness: de 9,33% para 58,00% em Pass@3.
• Claude Opus 5 no mesmo benchmark: 46,67%.
• Robustez: o sistema se mantém tanto em solicitações ambíguas quanto nas não ambíguas.
• Pesquisa com avaliadores: o diálogo cai de 3,4 para 1,2 rodadas.

Os 9,33% iniciais do modelo de 4B mostram o quanto a tarefa é difícil para a versão base, sem especialização. O salto para 58% indica que RL com auditoria de recompensas rende mais do que o tamanho do modelo. Mas a comparação é feita em um benchmark criado pelos próprios autores, para a formulação que eles mesmos definiram, e os modelos de fronteira não foram treinados especificamente para ele.

O ganho de 4,48 p.p. sobre o smolagents parece bem mais modesto do que o salto do modelo de 4B, e vale ter esses dois números em mente juntos.

A pesquisa com avaliadores também não substitui um experimento com usuários comuns. Os próprios autores limitam suas conclusões aos "cenários avaliados com bancos de dados".

Onde isso pode ser útil

Os casos mais próximos da prática são aqueles em que o agente tem um back-end estruturado: atendimento ao cliente, reservas, painéis administrativos internos, gestão de pedidos. Nesses cenários, um diálogo de esclarecimento sai caro, e as opções de resposta são finitas e estão no banco de dados.

Quem desenvolve agentes deve olhar para duas técnicas transferíveis. A primeira: separar o executor de tarefas do gerador de interface e treiná-los separadamente. A segunda: monitorar a distribuição das recompensas do LLM-juiz como uma entidade à parte, em vez de confiar em uma rubrica escrita uma única vez. A segunda técnica é útil em qualquer pipeline de RL com juiz, não só na geração de UI.

Por ora, trata-se de um artigo de preprint na versão v1: o código, a reprodutibilidade e o comportamento em dados fora dos dez domínios ainda precisam ser verificados.