💬 NLP

Asuka-Bench: Benchmarking Code Agents on Underspecified User Intent and Multi-Round Refinement

O artigo apresenta o Asuka-Bench, um novo benchmark projetado para avaliar agentes de código em tarefas de desenvolvimento web ao simular ciclos de refinamento multirrodadas do mundo real, nos quais os agentes melhoram iterativamente projetos subespecificados com base em testes de interface de usuário automatizados e feedback em linguagem natural, revelando lacunas significativas de desempenho entre os modelos atuais.

Autores originais: Xin Wang, Liangtai Sun, Yaoming Zhu, Shuang Zhou, Jiaxing Liu, Fengjiao Chen, Lin Qiu, Xuezhi Cao, Xunliang Cai, Licheng Zhang, Zhendong Mao

Publicado 2026-06-05

📖 4 min de leitura☕ Leitura rápida

CC BY 4.0

Autores originais: Xin Wang, Liangtai Sun, Yaoming Zhu, Shuang Zhou, Jiaxing Liu, Fengjiao Chen, Lin Qiu, Xuezhi Cao, Xunliang Cai, Licheng Zhang, Zhendong Mao

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está contratando um arquiteto brilhante, mas levemente literal, para construir uma casa.

O Jeito Antigo (Benchmarks Existentes)
No passado, testar esses arquitetos era como dar a eles uma planta perfeita de 50 páginas que listava cada prego, fio e cor de tinta. Você dizia: "Construa isto", e eles lhe entregavam uma casa pronta. Se a casa correspondesse à planta, eles tiravam um A. Se não correspondesse, tiravam um F.

O problema é que a vida real não funciona assim. Clientes reais raramente têm uma planta perfeita de 50 páginas. Eles geralmente dizem: "Quero uma casa com uma cozinha e um lugar para dormir" e, depois de verem o primeiro rascunho, percebem: "Ah, na verdade eu queria que a cozinha fosse maior", ou "Espere, a porta abre do lado errado".

O Novo Jeito (Asuka-Bench)
O artigo apresenta o Asuka-Bench, uma nova forma de testar "Agentes de Código" (programas de IA que escrevem software). Em vez de dar à IA uma planta perfeita, os pesquisadores dão a ela um pedido vago e bagunçado, como: "Faça um site de compras com uma lista de produtos e um carrinho."

Então, eles não apenas avaliam o primeiro resultado. Eles montam uma equipe de três pessoas para encenar um ciclo de desenvolvimento do mundo real:

O Construtor (Agente de Código): Esta é a IA tentando construir o site com base no pedido vago.
O Inspetor (Agente de UI): Este é um robô que realmente visita o site em um navegador web. Ele não lê o código; ele age como um usuário humano. Ele clica em botões, tenta comprar coisas e verifica se as páginas carregam. É como um inspetor de controle de qualidade caminhando pela casa para ver se as portas abrem.
O Cliente (LLM do Usuário): Esta é outra IA que observa o Inspetor. Se o Inspetor encontrar um problema (ex: "O botão 'Comprar' não funciona"), o Cliente traduz isso em uma nota educada para o Construtor: "Ei, o botão está quebrado. Por favor, conserte-o."

O Construtor então conserta o site, e o ciclo se repete. Isso acontece por até três rodadas.

A Analogia do "DAG"
Os pesquisadores também inventaram uma maneira inteligente de fornecer feedback chamada DAG (Grafo Acíclico Dirigido). Pense nisso como uma receita.

Se você está tentando assar um bolo, não pode cobri-lo com cobertura antes de assá-lo.
Nos métodos de teste antigos, se o bolo estivesse queimado, o inspetor também poderia reclamar que a cobertura está faltando, mesmo que você não pudesse colocar cobertura em um bolo queimado.
No Asuka-Bench, o sistema conhece a ordem. Se a etapa de "assar" falhar, ele impede o inspetor de verificar a etapa de "cobertura". Ele apenas diz ao Construtor: "Você não assou o bolo". Isso evita que o Construtor fique confuso com reclamações sobre coisas que ainda não aconteceram.

O Que Eles Descobriram
Os pesquisadores testaram 8 modelos de IA diferentes usando este método. Aqui está o que descobriram:

Algumas IAs são melhores em consertar do que outras: Só porque uma IA é boa em construir o primeiro rascunho, não significa que ela seja boa em corrigir erros. Alguns modelos construíram uma ótima primeira versão, mas não conseguiram entender as notas do "Cliente" para corrigir os erros. Outros começaram bagunçados, mas melhoraram a cada rodada de feedback.
A lacuna é enorme: Os melhores modelos conseguiram completar cerca de 52% dos projetos perfeitamente após três rodadas de correção. Os piores modelos completaram apenas cerca de 8%. Essa é uma diferença massiva.
Ainda é difícil: Nem mesmo a IA mais inteligente conseguiu terminar todos os projetos perfeitamente. Isso mostra que, embora a IA esteja ficando boa, ela ainda tem dificuldades com a natureza confusa e de ida e volta das solicitações humanas reais.

Em Resumo
O Asuka-Bench é um novo "teste de direção" para programadores de IA. Em vez de pedir que dirijam um carro em uma pista perfeitamente reta e vazia (uma planta perfeita), eles são solicitados a dirigir no tráfego da cidade, receber direções de um passageiro quando erram o caminho e corrigir sua rota. Acontece que ser capaz de ouvir e corrigir erros é uma habilidade completamente diferente de apenas saber dirigir em linha reta.

Resumo Técnico: Asuka-Bench

Declaração do Problema

Os benchmarks de geração de código existentes baseiam-se predominantemente em um paradigma de "turno único, disparo único" (single-turn, one-shot), onde um agente recebe uma especificação completa e inequívoca e é avaliado por sua capacidade de produzir uma saída correta em uma única passagem. Essa abordagem diverge fundamentalmente do desenvolvimento de software no mundo real, particularmente no desenvolvimento web. Na prática, os usuários raramente articulam especificações completas antecipadamente; os requisitos muitas vezes emergem e se esclarecem apenas após a inspeção de resultados intermediários e o fornecimento de feedback corretivo. Os benchmarks atuais falham em avaliar a capacidade de um agente de interpretar intenções subespecificadas, incorporar feedback de execução e refinar iterativamente seu trabalho em direção a uma implementação correta. Além disso, muitos benchmarks web focam na fidelidade visual ou assumem entradas totalmente especificadas, negligenciando a correção funcional e a robustez derivadas de loops de interação com o usuário.

Metodologia

Os autores introduzem o Asuka-Bench, um benchmark projetado para avaliar agentes de código sob intenção de usuário subespecificada através de refinamento iterativo de múltiplas rodadas, fundamentado no comportamento observável no navegador.

Estrutura de Avaliação

O benchmark opera via um mecanismo de ciclo fechado envolvendo três agentes distintos:

Agente de Código: Recebe uma consulta de usuário deliberadamente subespecificada (ex: "Crie um site de compras...") e gera um projeto web inicial. Ele refina iterativamente este projeto com base no feedback.
Agente de UI: Implanta o projeto gerado em um ambiente de navegador e executa critérios de avaliação predefinidos como casos de teste autônomos e interativos. Diferente da análise estática de código, o Agente de UI julga os resultados com base no comportamento renderizado (ex: clicar em elementos, verificar atualizações de dados) em vez da inspeção do código-fonte.
LLM de Usuário: Sintetiza os resultados de aprovação/reprovação do Agente de UI em feedback estruturado em linguagem natural, que é retornado ao Agente de Código para a próxima rodada de refinamento.

Construção do Dataset

Fontes: O dataset compreende 50 tarefas de desenvolvimento web derivadas de três fontes: solicitações reais de usuários desidentificadas de um serviço de produção, consultas formalizadas de repositórios de código aberto do GitHub e resumos de sites estabelecidos e ricos em funcionalidades.
Formalização da Tarefa: Cada tarefa é pareada com um Documento de Requisitos de Produto (PRD) Clarificado que serve como a verdade fundamental (ground truth). A partir deste PRD, o benchmark deriva:
- Uma consulta subespecificada (a entrada para o Agente de Código).
- Dados simulados (APIs mock, perfis de usuário) para permitir a execução frontend autossuficiente.
- Critérios de Avaliação: Um conjunto estruturado de casos de teste em linguagem natural organizados em um Grafo Acíclico Dirigido (DAG).
Tipos de Critérios: As tarefas são categorizadas em Presença (existência de elemento), Funcionalidade (comportamento interativo) e Robustez (tratamento de casos de borda).
Protocolo Consciente de DAG: As tarefas de avaliação são executadas em ordem topológica. Uma tarefa só é avaliada se suas dependências pré-requisitas tiverem passado. Isso evita "falhas em cascata", onde uma causa raiz bloqueia a avaliação subsequente, garantindo que o feedback foque nas causas raízes. Um limiar de "satisfação suave" ( $T=0.5$ ) é usado, onde uma tarefa pai é considerada satisfeita se pelo menos 50% de seus subcritérios passarem, minimizando o ruído de avaliação.
Configuração Experimental: Os autores avaliaram 8 modelos de linguagem de grande escala (LLMs) de última geração através de dois frameworks de agentes: OpenHands (baseado em sandbox) e Claude Code (baseado em CLI). O número máximo de rodadas de refinamento foi definido como três. As métricas incluíram Taxa de Conclusão de Projeto (PCR), Taxa de Aprovação de Tarefa ponderada cumulativa e Taxa de Aprovação de Critério ponderada cumulativa.

Principais Contribuições

Benchmark Asuka-Bench: O primeiro benchmark de geração web a avaliar sistematicamente agentes de código sob solicitações subespecificadas com refinamento interativo de múltiplas rodadas, abordando a lacuna entre benchmarks de instrução estática e o desenvolvimento iterativo do mundo real.
Protocolo de Avaliação Centrado no Feedback do Usuário:
- Interação como Feedback: A avaliação é fundamentada no comportamento renderizado no navegador, em vez do código-fonte.
- Avaliação Iterativa Consciente de DAG: Ao executar os critérios em ordem topológica e interromper precocemente em pré-requisitos falhos, o protocolo gera uma taxa de correção de tarefa média 10,5 pontos percentuais (pp) maior, além de reduzir os custos de tokens de avaliação em 23–26%.
Análise Empírica Abrangente: O estudo fornece insights sobre como a ambiguidade de intenção e o feedback iterativo afetam o desempenho, demonstrando que a capacidade de reparar a partir do feedback é um eixo de capacidade distinto da qualidade da geração inicial.

Resultados

Diferenciação de Modelos: O Asuka-Bench diferencia efetivamente o desempenho dos modelos. A Taxa de Aprovação de Tarefa ponderada varia em 38 pontos percentuais entre os modelos após três rodadas.
Melhoria Iterativa: Embora os modelos mais fortes alcancem altas Taxas de Aprovação de Tarefa (~~90%), a Taxa de Conclusão de Projeto (que exige que todas as tarefas passem) permanece menor (~~52%), destacando a dificuldade de alcançar a correção total.
Reparo vs. Geração: A capacidade de reparar erros a partir do feedback é amplamente desacoplada da qualidade da primeira rodada de geração. Por exemplo, o Kimi-K2.6 começou com uma primeira rodada medíocre, mas melhorou significativamente nas rodadas subsequentes, superando modelos com gerações iniciais mais fortes na pontuação cumulativa final.
Saturação: O benchmark está longe de estar saturado; mesmo o modelo mais forte (Claude-4.6-Sonnet) completa apenas 52% dos projetos após três rodadas. No entanto, estender o modelo mais forte para 8 rodadas resultou em 100% de conclusão, confirmando que as tarefas são solucionáveis e o mecanismo de feedback é eficaz.
Alinhamento Humano: O agente de avaliação automatizado alcançou 93,35% de precisão e 96,52% de F1 score contra julgamentos de especialistas humanos, validando a confiabilidade do framework de ciclo fechado.

Significância

O artigo afirma que o Asuka-Bench revela um ponto cego crítico nos benchmarks existentes: a incapacidade de avaliar a capacidade de um agente de convergir sob um loop de feedback. Ao mudar de uma avaliação estática de disparo único para o refinamento iterativo baseado em intenções subespecificadas, o benchmark fornece uma medida mais realista da utilidade de um agente em implantação no mundo real. Os resultados sugerem que o "reparo-a-partir-do-feedback" é uma dimensão separável da capacidade do modelo que os atuais benchmarks de disparo único não conseguem capturar. Os autores posicionam o Asuka-Bench como um passo em direção a benchmarks que refletem a natureza iterativa e baseada em diálogo do desenvolvimento de software real, incentivando a comunidade a ir além dos paradigmas de avaliação estática.