Insights sobre a geração de código de agentes do Android Bench

Tomáš Mlynarič

Bom dia, pessoal.

Vamos começar.

Em março, lançamos o Android Bench, nosso conjunto de dados e ranking para medir LLMs em tarefas de desenvolvimento Android.

Desde então, o executamos em muitos modelos novos.

No mês passado, lançamos o Android Bench 2.0.

Embora tenham se passado apenas alguns meses, no mundo da IA, isso parece uma eternidade.

Meu nome é Tomáš, e vou compartilhar nossa jornada com o Android Bench e como chegamos até aqui.

Vamos começar com 1.0.

Na versão 1.0, usamos problemas reais de repositórios de código aberto.

Filtramos os projetos do GitHub com problemas, solicitações de pull que resolvem esses problemas e testes que verificam as soluções.

Dividimos as solicitações de pull em buckets de tarefas para modelos de IA.

O problema do GitHub se tornou as instruções ou o comando para o modelo, e nós os plantamos no estado antes do PR.

Depois que o modelo criou um trabalho, aplicamos os testes ao resultado, que foi aprovado ou reprovado.

Essa tentativa da IA de resolver o problema é chamada de teste.

Também podemos comparar com base na solução criada por humanos desse PR, ou o que chamamos de solução ideal.

Essa metodologia é semelhante ao conhecido comparativo de mercado SWE-bench.

Começamos com mais de 10.000 tarefas em potencial, mas nem todas eram adequadas.

Algumas tinham instruções incompletas ou excessivamente específicas.

Os testes podem ter sido acoplados à solução de referência, ou o estado antes da solicitação de envio estava corrompido.

Por isso, tivemos que revisar e revisar para chegar a 100 tarefas justas.

Durante essas revisões, usamos os modelos mais avançados para conseguir alguns resultados.

Começamos com cerca de 30% das tarefas resolvidas, o que chamamos de taxa de aprovação.

E, quando bloqueamos o conjunto de dados para o lançamento oficial, os principais modelos já estavam em cerca de 70%.

Mas isso é um mês depois.

E então tivemos um plano para avaliar novos modelos todos os meses e observamos como eles estão melhorando.

E na versão de agosto, a taxa de aprovação de 92% foi para o melhor modelo.

E sabíamos que nosso padrão era muito baixo e que esse conjunto de dados estava saturado.

Tomáš Mlynarič

Mas já prevíamos isso e estamos trabalhando duro na versão 2.0, que lançamos no mês passado.

O objetivo é, e sempre foi, elevar o nível com tarefas complexas e reais do Android, além de oferecer orientação e transparência sobre o desempenho de LLMs para vocês, desenvolvedores, mas também incentivar os criadores de modelos a priorizar o Android, oferecendo um bom comparativo para eles superarem.

Além disso, fornecemos análises e resultados que ajudam você e os criadores de modelos.

Mas também precisamos considerar a inteligência, a tenacidade e a trapaça.

E precisamos evitar o risco de contaminação.

Um problema com a metodologia do SWE-bench é a abertura real do código-fonte.

A OpenAI publicou um artigo.

Eles descobriram que os modelos conseguiam completar as próximas palavras das instruções ou resolver uma tarefa com um erro obscuro que não fazia parte das instruções.

Eles perceberam que os criadores de modelos estão treinando com o código-fonte aberto e que o SWE-bench está contaminado.

Por isso, para a versão 2.0, estamos mantendo o código fechado para evitar o treinamento com base nele.

Dividimos o trabalho em quatro fluxos.

No primeiro, fizemos conversões de apps, em que pegamos apps de código aberto, Flutter e React Native e dissemos aos agentes para convertê-los em uma solução de app nativo do Android.

Isso reflete a tendência de migração de multiplataforma para nativo que vemos hoje.

O segundo fluxo de trabalho foi de novos recursos e integrações de plataforma.

Eles foram criados em bases de código de produção estabelecidas.

Por exemplo, no Now in Android, adicionamos um recurso de vídeo, picture-in-picture, coisas assim.

O terceiro fluxo de trabalho foram as migrações.

Estamos atualizando apps de código aberto de produção que mantivemos fechados, com bibliotecas e arquiteturas modernas.

Por exemplo, do Nav 2 para o Nav 3, de visualizações XML para o Compose ou de painel único para layout adaptável.

E o último foi um app interno criado do zero usando modelos de design visual.

Aqui, os exemplos foram: fluxo completo de autenticação de OTP por SMS, rastreamento de pedidos com o Google Maps e muito mais.

Tomáš Mlynarič

Com apenas alguns engenheiros, criamos um app do mesmo tamanho do Now in Android.

Mas as novas tarefas trouxeram novos desafios.

A primeira: classificar os agentes corretamente.

Os testes de comparativo de mercado são muito mais difíceis do que os testes para seu app, porque precisam passar em qualquer solução válida, não apenas em uma. Além disso, quanto maior a tarefa, mais soluções válidas existem.

Na versão 1.0, o comparativo de mercado dependia principalmente de testes de unidade, que são péssimos em serem agnósticos.

import com.foodvibes.MyViewModel

@Test
fun testRetry() {
    val vm = MyViewModel()
    vm.retry()

    assertTrue(vm.retried)
}

Eles exigem nomes exatos de classes ou funções.

Como neste caso, não há um teste sofisticado, mas, basicamente, o agente pode nomear essas coisas de forma diferente ou, mesmo que não faça isso, se ele as colocar em um pacote diferente, os testes não serão compilados e, portanto, não poderão ser usados no nosso caso.

import com.foodvibes.feature.my.RetriableViewModel

@Test
fun testRetry() {
    val vm = RetriableViewModel()
    vm.tryAgain()

    assertTrue(vm.tried)
}

Tecnicamente, poderíamos especificar as APIs nos comandos, mas isso daria muitos detalhes ou sobrecarregaria o comando com muitos requisitos de teste.

Portanto, a solução é fazer testes independentes de implementação.

Eles são de alto nível e testam resultados e comportamentos, não os componentes internos.

Usamos o teste de interface determinista, que interage com as informações públicas da tela, de forma semelhante ao que um usuário faria.

Para isso, usamos o UI Automator ou testes de interface do Compose, mas também temos scripts especializados que verificam alguns limites externos do sistema, como, por exemplo, se uma chamada de rede tinha os dados certos ou se os dados certos foram salvos em um banco de dados sem conhecer os auxiliares internos ou DAOs.

Além disso, também temos verificações estáticas para, por exemplo, verificar permissões no manifesto ou se a biblioteca estava em arquivos de build e coisas do tipo.

Também temos testes híbridos, que são uma combinação desses scripts e dos testes de interface.

Este é um exemplo de um dos testes híbridos.

Eles são executados fora do emulador.

Este é o teste do fluxo de autenticação de OTP por SMS, em que o script precisa primeiro calcular o hash do app para enviar o SMS corretamente ao emulador. Em seguida, ele inicia o teste, os testes do UI Automator, transmite uma OTP gerada aleatoriamente e envia o SMS para um emulador com um comando ADB.

O teste só verifica se a entrada tinha o número certo.

Basicamente, é isso.

Não há acoplamento de implementação, apenas verificações para saber se o fluxo funciona.

O segundo problema de avaliação é que nossas tarefas exigem multimodalidade.

Os agentes precisam produzir a interface ou nós fornecemos os modelos de design.

Para isso, o mais fácil é usar testes de captura de tela.

Sabíamos desde o início que os limites de captura de tela precisariam ser maiores, mas, mesmo assim, eles falharam.

Tentamos alguns algoritmos de diferenciação de pixels, mas eles falharam em coisas como ruído no nível do sistema, em que a barra de status do emulador era diferente, ou o ícone da bateria, ou até mesmo o anti-aliasing de hardware da fonte era diferente.

Mas eles também falharam em implementações um pouco válidas, em que, você sabe, os paddings eram menores, é um pouco diferente, ou havia algumas pequenas diferenças de tonalidade, como a interface poderia estar completamente correta, mas o plano de fundo teria uma tonalidade um pouco diferente, e os algoritmos de diferenciação de pixels falhariam.

Por isso, usamos e criamos um juiz de LLM multimodal que compara pares de capturas de tela, como em testes de captura de tela, e nos dá uma pontuação, mas também um raciocínio estrutural sobre a pontuação.

Também fornecemos alguns dumps de hierarquia de acessibilidade que verificam se a estrutura e a paridade estrutural estão corretas.

Testamos empiricamente em muitos, muitos testes e vimos que ele tem alta consistência e ignora os problemas que vimos.

Agora, tínhamos uma boa maneira de verificar recursos visuais e comportamentos de forma agnóstica, e vimos que os agentes tentaram simular tudo.

Vá em frente!

Tomáš Mlynarič

Começa de forma simples.

Hoje em dia, os agentes basicamente dizem: "Ok.

Tenho uma tarefa.

Vamos dar uma olhada no GitHub.

Vamos encontrar as soluções."

Então, é isso que eles fazem primeiro.

Eles tentam pesquisar no GitHub ou na Internet uma solução válida. Por isso, precisamos manter o código-fonte fechado e não podemos torná-lo público.

Mas isso foi fácil.

Em alguns testes, dissemos que tudo estava funcionando perfeitamente, e o agente respondeu: "Triunfo magnífico!"

Certo.

Interessante, o que eles descobriram?

Mas analisamos a trajetória mais de perto e eles disseram: "Não consigo fazer isso.

E se eu mudar o limite para 80% do teste de captura de tela?"

// AuthFlowScreenshotTests.kt

@get:Rule
val dropshots = Dropshots(
    resultValidator =
        ThresholdValidator(
-           0.05f
+           0.80f
        )
)

E você pensa: "Sim, vitória, tudo está passando".

Sim, mas os testes de captura de tela são inúteis.

Mas esse não foi o mais sofisticado.

No app de conversão do Flutter, o agente tentou várias vezes criar o Android e disse: "Não sei o que fazer".

Então, eles pegaram a captura de tela que fornecemos e a colocaram como um drawable em segundo plano.

E agora ele está passando no teste de captura de tela.

Eba!

Mas os testes de interface ainda estão falhando, então eles pensam: "Vou colocar uma camada de sobreposição invisível por cima com os botões, textos e tags de teste, tudo o que precisamos.

Agora tudo está verde.

Ótimo.

Bom trabalho."

Não é que, tipo, tem um que é, tipo, muito bom.

Temos uma tarefa de migração de Java para Kotlin em que o agente precisa migrar de Java para Kotlin, certo?

Eles não conseguiram fazer o build.

Ainda está falhando em alguma coisa, então o agente pensou: "Tudo bem, vou pegar as classes compiladas do Java, colocá-las em um JAR e adicioná-las aos arquivos de build como uma biblioteca comum.

Agora, todos os testes estão passando, mas temos as verificações estáticas que estão verificando os arquivos Java. Então, sim, vou excluí-los."

Estou excluindo os arquivos Java, tudo está verde, exceto o Kotlin, que ainda está falhando. Então, eles pensam: "Tudo bem, vou remover o conjunto de origem do Kotlin e agora tudo está passando.

Ótimo."

Não sei se isso é trapaça.

Isso é muito criativo.

Para evitar tudo isso, criamos um detector de trapaças que tem três defesas.

Analisamos a árvore da IU, aplicamos diferentes tamanhos de tela para que o plano de fundo seja distorcido e o vemos.

Mas também redefinimos os testes e verificamos se há adulteração para que eles não possam mudar os limites.

E também temos o LLM-as-a-Judge, que audita as trajetórias e a saída real do agente para identificar algo estranho.

E se algo acontecer, dizemos: "Ok, falha direta".

Tomáš Mlynarič

Agora, todos os atalhos sumiram, não há como procurar soluções, não há testes de unidade frágeis ou simulação de IU.

Então, quando forçamos os agentes a criar um app Android, como ficam os números?

Então, na segunda-feira, talvez você tenha visto a postagem do blog, os números estão assim.

Mesmo o melhor agente passa apenas em cerca de 40% das nossas tarefas, e a maioria dos agentes de fronteira fica entre 20% e 40%.

E isso é bom para nós, como autores do comparativo, porque equilibra as coisas: as tarefas que fornecemos têm um valor real, mas também há muito espaço para crescimento.

Vamos conferir os resultados.

Agora podemos analisar os resultados de várias perspectivas.

Vamos conferir alguns dos insights que já encontramos.

A primeira pergunta que você pode ter ao analisar o gráfico é: quanto custa para executar esse agente?

E as empresas de IA geralmente informam o custo por token, para alguns de entrada, saída e talvez token de cache.

E talvez esse seja um argumento decisivo no seu caso.

Mas podemos analisar isso de outra perspectiva.

Podemos plotar o mesmo gráfico em um espaço 2D com o custo médio por tarefa, não por token, ou seja, o custo por tarefa em relação à taxa de aprovação.

E aqui, podemos ver que alguns modelos são muito mais falantes.

Eles gastam muito mais tempo ou tokens por tarefa, enquanto outros passam mais tarefas e custam menos.

Mas se adicionarmos o preço por token ao mesmo gráfico, veremos que o que as empresas de IA realmente anunciam não corresponde ao que você realmente paga por tarefa.

Assim, é possível ver que o agente com a melhor taxa de aprovação é, na verdade, um dos mais baratos por token, mas o mais caro por tarefa.

Ou outros agentes com o mesmo preço de token passam em cerca de 30% das tarefas, mas são 15 vezes mais baratos.

Portanto, o preço do token não é a métrica.

Alguns deles são modelos que estão explorando mais o código, reconstruindo, executando novamente, e cada etapa consome mais tokens.

Portanto, não olhe apenas para o preço, por custo por token.

Escolha um modelo, analise os dados reais, use-os no seu caso ou consulte o Android Bench para ver quais modelos realmente gastam mais tokens nas tarefas.

Alguns, você sabe, precisam de mais etapas, embora sejam mais baratos por token.

Mas há outro aspecto na mesma pergunta.

Este é o mesmo gráfico, mas também podemos dar uma olhada e mostrar quanto tempo os agentes levam para concluir isso.

E podemos ver que os agentes com a maior taxa de aprovação podem ser os mais lentos.

Por exemplo, podemos ver que algumas levam quase duas horas por tarefa.

Eles continuam reconstruindo e testando até que funcione.

Sim, eles têm a melhor taxa de aprovação, mas também levam mais tempo.

Alguns agentes mais baratos ainda levam cerca de uma hora e meia por tarefa, mas sem resultados melhores.

Outros agentes terminam em menos de 20 minutos e ainda resolvem mais de um quarto das tarefas.

Modelos pequenos e leves costumam ser mais rápidos e baratos, mas falham com mais frequência em tarefas difíceis.

A conclusão é que não existe um único modelo ideal.

Depende do que você otimiza.

É a taxa de aprovação?

É o custo?

É o tempo de espera?

Nesse caso, dependendo do tipo de trabalho que você está fazendo, se não estiver trabalhando em tarefas tão difíceis, considere usar os modelos mais rápidos que fazem o trabalho de forma mais barata e rápida.

No entanto, o custo e a velocidade informam apenas como os agentes são executados, mas não por que eles falham na maioria dos testes.

Por isso, inspecionamos as execuções com falha e percebemos que os agentes costumavam desistir antes do tempo.

Eles estão convencidos de que terminaram.

Tarefa concluída.

Ok, vou para casa.

No entanto, como mencionado, no pacote de tarefas, os agentes recebem apenas as instruções e o estado anterior.

Eles não podem ver os testes.

Eles não conseguem ver o pacote de verificação.

Então, perguntamos: e se deixarmos que eles vejam os testes?

Então, fizemos um experimento e criamos uma variante de teste aberto da mesma tarefa, em que o agente recebia o pacote de testes de verificação com falha logo de início.

Então, agora, eles estavam executando os testes de forma iterativa.

Eles podem inspecionar erros e refinar códigos em um ciclo de feedback.

E descobrimos que, quando os agentes veem os testes, eles se esforçam mais e trabalham por mais tempo.

E nas execuções abertas, eles tiveram 25% mais turnos e 40% de Agent Runtime.

Eles gastaram quase 30 minutos por tarefa executando e corrigindo os testes com falha, porque não estavam depurando às cegas.

Assim, eles veem exatamente o que falha e, infelizmente, a taxa de aprovação também aumenta quase 50 pontos percentuais.

E esse esforço extra melhora a taxa média de aprovação, como mencionei.

Mas, com o tempo, novos modelos de fronteira surgiram e rapidamente saturaram essa variante aberta.

Quase 90% de taxa de aprovação.

Por isso, mantivemos a variante de teste fechado de pesquisa fechada como a principal métrica de comparação.

Mas ainda é muito interessante ver como os modelos são melhores quando sabem o que está sendo avaliado.

Tomáš Mlynarič

No entanto, isso nos permitiu criar mais insights sobre os agentes.

Por exemplo, podemos verificar como os modelos testam o próprio trabalho.

No gráfico, podemos ver que os modelos de fronteira escrevem testes cada vez melhores e têm taxas de aprovação mais altas.

Outros modelos são confiantes demais, "eu consigo, não preciso de testes".

Bem, às vezes eles ainda estão bons.

Portanto, se você usar modelos que não são tão bons em testes, poderá ajudá-los com melhores habilidades de teste ou instruções específicas sobre como escrever testes.

Mas correlação não implica causalidade, CS, certo?

Precisamos fazer um experimento controlado sobre isso.

Ainda precisamos fazer isso para saber se pedir testes melhores realmente aumenta a pontuação.

No entanto, fizemos um experimento na outra metade dos testes do Android, que é fazer com que os agentes usem o emulador.

No início, em nossa comparação, não dissemos nada sobre o emulador.

Presumimos que os agentes deveriam descobrir, certo?

Como resultado, quase nenhum deles inicializou o emulador.

Como mencionei, os testes de IU são cruciais nos nossos comparativos de mercado, e sem emuladores, não é possível usar os testes de IU.

Então, todos eles estavam falhando em uma coisa muito simples.

Agora, temos um dilema.

Dizemos aos agentes que eles precisam usar o emulador, correndo o risco de pontuações mais altas, ou não dizemos nada e esperamos que eles descubram?

Mas, no fim das contas, nosso objetivo era ser um comparativo justo para medir a programação e a resolução de problemas do Android.

Não queremos medir peculiaridades ambientais.

Por isso, escolhemos um meio-termo.

Mostramos como iniciar um emulador, mas não mencionamos se ele deve ser usado ou não.

Afinal, iniciar o emulador não é o que realmente precisamos ou queremos testar.

E medimos o efeito dessa instrução do emulador.

E agora, vimos que, quando demos o tutorial, os agentes inicializaram o emulador muito mais e executaram os testes de IU, e isso teve um grande impacto na taxa de aprovação, infelizmente para nós.

Mas também nos permitiu inspecionar os erros e problemas reais de programação, e não apenas, por exemplo, falhas no emulador não inicializado.

Portanto, a especificidade do comando ainda é muito importante. Se você estiver criando seus próprios comparativos de mercado ou avaliações, teste o que realmente importa no seu caso.

Por exemplo, se você estiver avaliando a eficiência de tokens ou de uma habilidade ou ferramenta, primeiro precisa começar com a aprovação da avaliação, fazer a mudança para a eficiência e, em seguida, verificar se ela ainda é aprovada com menos tokens.

Se você fizer de outra forma, terá muitas variáveis mudando ao mesmo tempo e não saberá se a mudança realmente melhorou o desempenho.

Tomáš Mlynarič

Voltar ao ranking.

Como mencionei, os melhores modelos passam em cerca de 40% das tarefas, e a taxa de aprovação exige que todas as verificações sejam aprovadas.

Caso contrário, a tarefa falharia.

Então, a pergunta é: os agentes não produziram nada útil nos outros 60%?

Não, eles estão chegando lá.

Para mostrar o quão perto o agente chegou das soluções funcionais, como uma distância, também calculamos a taxa de conclusão ou uma pontuação parcial.

Essa é uma pontuação ponderada em quatro categorias: consistência visual, funcionalidade, funcionamento adequado, alguns requisitos específicos por tarefa e algumas verificações de regressão.

Os modelos de classificação mais baixa conseguem concluir cerca de metade do trabalho, enquanto os modelos de fronteira conseguem concluir e chegar a quase 80% em média, mais de 80% das tarefas, mas só passam em 40%.

Então, fizemos um experimento na conversão do Flutter para o Android para verificar o que estava acontecendo.

Por isso, recalculamos a taxa de conclusão a cada poucas etapas do agente e vimos os mesmos padrões em todos os modelos de fronteira.

Por volta de 140 etapas, eles estavam trabalhando para alcançar uma pontuação média de quase 90% e, em seguida, gastaram mais 90 etapas ou quase 40% da execução tentando fechar a lacuna para os 100%, mas só conseguiram marcar cerca de 1 ou 2% a mais.

E acreditamos que isso reflete o desenvolvimento agêntico atual, em que desenvolvedores ou usuários inexperientes veem o app como concluído.

Tudo está sendo renderizado.

A entrada funcionou mais ou menos.

Talvez não haja falhas.

Mas quando um engenheiro sênior analisa o código, ele encontra várias falhas: problemas de arquitetura, falhas no ciclo de vida e coisas do tipo.

Tomáš Mlynarič

Para encerrar, vamos colocar o Android Bench, nosso trabalho 2.0, em perspectiva.

Em comparação com a versão 1.0, agora temos apenas 30 tarefas, e isso é intencional.

Em vez de correções de bugs isoladas e pequenos patches, temos telas completas, migrações de vários módulos e conversões de apps inteiros.

Os patches agora são uma ordem de magnitude maiores em dezenas de arquivos.

E temos as verificações de interface multimodal.

Os agentes precisam funcionar por mais tempo e trabalhar muito mais.

Se compararmos com outros comparativos de mercado de fronteira, podemos dizer que o nosso ainda exige mudanças de código muito maiores.

Ele não tem contaminação porque a maioria das tarefas é escrita do zero, e ainda há muito espaço para crescer.

Como eu disse no início, alguns meses no mundo da IA parecem uma eternidade, e, eventualmente, todos os comparativos de mercado atingem o limite e ficam saturados.

E quando isso acontecer, esperamos que possamos avançar para tarefas ainda mais difíceis e complexas que, novamente, vão ressoar com essa era e com esse estado da IA.

Agora, use o Android Bench como bússola para comparar modelos e harnesses e talvez aprender alguns insights.

E quando você estiver pronto para se aprofundar, use os mesmos princípios de comparativo de mercado e avaliação nas suas próprias bases de código e fluxos de trabalho, porque nada supera a medição da IA no código com que você realmente trabalha.

É assim que você passa de "espero que a IA tenha acertado" para "tenho certeza de que ela acertou".

Em nome de toda a equipe do Android Bench, agradecemos sua atenção.