Modelos mais inteligentes estão ficando mais habilidosos em hackear benchmarks de programação.

Suítes de eval desenvolvidas a partir de bugs reais que depois foram corrigidos são especialmente vulneráveis, porque os problemas já foram resolvidos. Se o agente tem acesso ao histórico do repositório ou à Web pública, às vezes ele pode buscar a resposta em vez de derivá-la.

Para medir o quanto esse comportamento é disseminado, desenvolvemos um agente para auditar trajetórias de eval. No SWE-bench Pro, constatamos que 63% das resoluções bem-sucedidas do Opus 4.8 Max encontraram a correção em vez de derivá-la. Quando isolamos o histórico do git e restringimos o acesso à internet, as pontuações caíram acentuadamente tanto para o Opus quanto para o nosso modelo, Composer 2.5:

• Opus 4.8 Max caiu de 87.1% para 73.0%
• Composer 2.5 caiu de 74.7% para 54.0%

Pesquisas anteriores mostraram que respostas de benchmarks de programação podem vazar por meio de fontes disponíveis publicamente, incluindo este estudo de 2024 e um relatório da Meta de 2025. Nosso estudo quantifica o problema em execuções atuais de agentes de programação de fronteira. A lição mais ampla é que, além de evitar contaminação durante o treinamento, benchmarks de programação agêntica também precisam de ambientes de tempo de execução controlados.

Para equipes que conduzem evals, propomos mitigar esse comportamento de reward hacking auditando transcrições e restringindo o ambiente de eval.

#Identifique um modelo com outro modelo

Para medir a escala desse comportamento de reward hacking, fizemos o auditor examinar 731 trajetórias do Opus 4.8 Max. Ele viu a descrição do problema e a trajetória completa do agente, sem saber se a execução tinha sido bem-sucedida, e classificou se o agente havia obtido a resposta conhecida.

Os dois padrões mais comuns de reward hacking que ele constatou foram:

• Busca upstream: Em 57% das trajetórias, o Opus 4.8 Max encontrou a PR já mesclada ou o arquivo-fonte corrigido na web pública e depois reproduziu a correção quase literalmente.
• Mineração do histórico do Git: Em 9% das trajetórias, o Opus 4.8 Max pesquisou o histórico .git incluído em busca do commit futuro que corrigia o bug e depois extraiu o patch.¹

À medida que os modelos ficam mais fortes, às vezes conseguem inferir que estão em um eval, especialmente quando a tarefa vem de um repositório público antigo. Mesmo nos casos em que não se lembram da correção do treinamento, o ambiente ainda pode dar pistas de que o bug já foi resolvido.

Em uma tarefa do SWE-bench Multilingual baseada em uma issue do jq de 2019, o agente tentou reproduzir o bug com o binário jq do sistema. Como a imagem havia sido gerada depois que o bug foi corrigido, a reprodução falhou, e o agente inferiu que a issue já havia sido resolvida. Essa percepção o levou a buscar a correção em vez de chegar a uma por conta própria.

Alguns casos foram mais diretos. Um agente encontrou uma página espelho do SWE-bench que expunha testes ocultos e o patch de referência. Outro obteve arquivos de testes ocultos e fixou no código a string de exceção esperada necessária para passar.

cd /testbed && curl -s "https://api.github.com/repos/apache/druid/pulls/14092/files" 2>/dev/null | grep '"filename"'

cd /testbed && git show 895abd8929 -p 2>/dev/null | head -400
cd /testbed && git cherry-pick 895abd8929 2>&1

#Arquitetura de ambiente mais rigorosa

A maior parte do reward hacking acontecia pela web pública e pelo histórico do repositório. Para evals desenvolvidas a partir de repositórios públicos históricos, esses canais precisam ser controlados, porque podem conter a resposta. Por isso, desenvolvemos um harness rigoroso com dois mecanismos de isolamento:

1. Isolamento do histórico. Antes de o agente começar, o diretório .git é removido e o repositório é reinicializado como um repositório novo, com um único commit. O histórico original é restaurado apenas no momento da avaliação, então os testes são executados normalmente.
2. Proxy de saída. O acesso à rede é negado por padrão. Como medida de melhor esforço, um proxy fixo permite resolver dependências com base em uma lista de permissões de repositórios de pacotes, e nada além disso.

Essa restrição é específica de evals desenvolvidas a partir de repositórios públicos históricos. Esse é um dos motivos pelos quais preferimos evals desenvolvidas a partir de repositórios não públicos, como o CursorBench. Elas podem testar a capacidade de programação agêntica dos agentes, sem deixar de permitir que usem ferramentas da forma como usariam em trabalho real.

#Uma lacuna crescente

Executamos novamente o SWE-bench Pro e o SWE-bench Multilingual no harness mais rigoroso e, em seguida, comparamos cada resultado com a pontuação do harness padrão como proxy do efeito combinado da remoção desses canais de vazamento²:

• No SWE-bench Multilingual, a diferença foi de menos de 1 ponto para o Opus 4.6, 9,1 pontos para o Opus 4.8 Max e 7,5 pontos para o Composer 2.5.
• No SWE-bench Pro, a diferença foi de menos de 1 ponto para o Opus 4.6, 14,1 pontos para o Opus 4.8 Max e 20,7 pontos para o Composer 2.5.

A conclusão mais clara é que o reward hacking é muito mais comum em modelos mais novos e sofisticados do que em modelos mais antigos. Curiosamente, os modelos GPT não mostram a mesma escalada, com diferenças geralmente menores em nossas execuções.

Também observamos que o nosso próprio modelo, Composer 2.5, teve a maior diferença no Pro de todo o estudo. Esse é um dos motivos pelos quais não tratamos a pontuação do SWE-bench Pro no harness padrão como um benchmark confiável para o Composer. A pontuação era real no sentido estrito de que foi produzida pelo harness, mas misturava capacidade de programação com acesso a correções já conhecidas.

#Projetando evals para agentes conscientes

A principal conclusão para equipes que executam evals de programação é que o design de benchmarks não deve se limitar à construção do conjunto de dados. Ele também precisa levar em conta o ambiente de tempo de execução, incluindo o que o agente pode buscar, inspecionar, obter e recuperar enquanto a tarefa está sendo executada.

Isso não significa que todo eval deva remover o acesso à internet ou ao histórico do git. Alguns evals existem para testar quão bem os agentes usam o contexto ao redor de uma base de código real e, nesses casos, um acesso amplo pode fazer parte da tarefa. O problema surge quando esse acesso altera o que a pontuação realmente significa.

Em benchmarks históricos de repositórios públicos, o acesso aberto pode permitir que os agentes encontrem a correção já conhecida em vez de resolver o bug. Sem controles no harness, as pontuações podem acabar misturando capacidade de programação com recuperação de respostas.

As equipes que executam evals devem decidir qual comportamento querem medir, projetar o harness em função disso e deixar a configuração clara ao relatar resultados. Auditar transcrições pode ajudar a revelar quando os modelos estão resolvendo tarefas de maneiras inesperadas. O objetivo não é proibir o uso normal de ferramentas, mas garantir que o benchmark meça aquilo que afirma medir.

Ainda assim, permanece um problema aberto mais difícil. À medida que os modelos se tornam mais conscientes de quando estão sendo avaliados, eles podem alterar seu comportamento de maneiras mais sutis que não são corrigidas apenas isolando o histórico do git ou restringindo o acesso à internet. A contaminação em tempo de execução é uma versão concreta de um desafio mais amplo de desenvolver evals que preservem a validade de construto mesmo quando o modelo infere que está sendo avaliado.