10 Linhas de Código Quebraram Todos os Benchmarks de IA

Imagine gastar milhões de dólares treinando um modelo de IA, comparar ele contra os melhores do mundo em benchmarks respeitados — e descobrir que o ranking inteiro é uma mentira. Foi exatamente isso que pesquisadores de Berkeley acabaram de provar.

Um time do Center for Responsible, Decentralized Intelligence (RDI) da UC Berkeley construiu exploits funcionais para oito dos maiores benchmarks de agentes de IA do mercado. O resultado? Scores perfeitos. 100%. Em quase todos. Sem resolver uma única tarefa de verdade.

A real é que os benchmarks que a indústria inteira usa para decidir qual modelo é “melhor” — SWE-bench, WebArena, GAIA, Terminal-Bench — são tão frágeis que um script de 10 linhas engana todos eles. E o pior: isso já está acontecendo na prática.

O Que Berkeley Fez (e Por Que Isso Muda Tudo)

O paper é direto ao ponto. Os pesquisadores criaram um agente automatizado que escaneia benchmarks em busca de vulnerabilidades. Não estamos falando de ataques sofisticados — são falhas básicas de segurança que qualquer dev júnior reconheceria num code review.

Eles testaram oito benchmarks e conseguiram scores quase perfeitos em todos:

Leu certo. 100% no SWE-bench Verified. Aquele benchmark que OpenAI, Anthropic e Google usam para dizer que seus modelos “resolvem bugs reais em repositórios open source”. Tudo fake — ou pelo menos, possível de ser fake.

O Hack do SWE-bench: 10 Linhas que Humilham a Indústria

Eu já vi muita gambiarra na minha carreira, mas essa é de cair o queixo.

O SWE-bench funciona assim: ele pega um bug real de um repositório open source, pede pro agente de IA consertar, e depois roda os testes do projeto pra ver se o fix funciona. Parece sólido, né? Só que tem um detalhe: o agente e o avaliador rodam no mesmo ambiente.

Isso significa que o agente pode simplesmente… hackear o avaliador.

O exploit dos pesquisadores de Berkeley cria um arquivo conftest.py com um hook do pytest. São literalmente 10 linhas de Python:

# conftest.py — o exploit que quebra o SWE-bench
import pytest

@pytest.hookimpl(tryfirst=True, hookwrapper=True)
def pytest_runtest_makereport(item, call):
    outcome = yield
    report = outcome.get_result()
    # Força TODOS os testes a passarem
    report.outcome = "passed"
    report.longrepr = None
    report.wasxfail = None

Pronto. Esse arquivo intercepta cada resultado de teste e reescreve como “passed”. Não importa se o agente não fez nada. Não importa se o código está quebrado. Todos os 500 testes do SWE-bench Verified reportam sucesso.

Pra colocar em perspectiva: o melhor score legítimo no SWE-bench Verified fica em torno de 50-60%. Esse exploit bate 100% sem escrever uma linha de código real.

Terminal-Bench: Trojans no Sistema

O Terminal-Bench é um benchmark que testa se agentes conseguem instalar e configurar software via terminal. A abordagem dos pesquisadores foi ainda mais criativa aqui.

O agente substitui o binário /usr/bin/curl por um wrapper malicioso durante a execução. Quando o verificador roda comandos de instalação, o wrapper intercepta chamadas e injeta código em binários dependentes como uvx. O resultado? Output de teste fabricado do zero.

É como se alguém substituísse a balança numa competição de peso — não importa o que você coloque em cima, sempre vai mostrar o número certo.

WebArena: Quando o Navegador Lê as Respostas

O WebArena testa agentes de IA em tarefas de navegação web. O agente precisa completar tarefas reais em sites — comprar produtos, preencher formulários, buscar informações.

O problema? O navegador do agente consegue navegar para URLs file://. E as respostas de referência ficam armazenadas em arquivos de configuração locais.

O agente literalmente abre file:///path/to/task_config.json, lê a resposta correta, e responde com ela. Não precisa nem abrir o site.

Tem também o ataque de injeção no DOM: o agente injeta conteúdo na página que manipula o juiz LLM usado pra avaliar. É prompt injection aplicada a benchmarks.

FieldWorkArena: A Validação que Não Valida Nada

Essa é talvez a mais absurda. O FieldWorkArena tem uma função de validação que verifica apenas se a última mensagem veio do assistente. Não checa o conteúdo. Não compara com a resposta certa. Nada.

O agente pode responder “batata” pra todas as 890 perguntas e tirar 100%.

Eu honestamente não sei como isso passou por peer review. É o equivalente a um professor que dá nota máxima pra qualquer aluno que entregou a prova — sem ler o que está escrito.

Os 7 Padrões de Vulnerabilidade

Berkeley catalogou sete padrões recorrentes que tornam benchmarks exploráveis. Quase todos os benchmarks testados tinham múltiplos desses problemas simultaneamente:

1. Espaço de execução compartilhado

Agente e avaliador rodam no mesmo container, mesma VM, mesmo filesystem. Qualquer avaliação que lê estado de um ambiente compartilhado pode ser derrotada por um agente que escreve nesse ambiente.

2. Respostas publicadas

Gabaritos visíveis para o agente — seja em arquivos locais, histórico git, ou URLs previsíveis. O GAIA, por exemplo, teve respostas acessíveis publicamente, permitindo lookup direto.

3. eval() inseguro

Benchmarks usando eval() em Python com input não sanitizado do agente. Isso é vulnerabilidade 101 — qualquer curso de segurança ensina a nunca fazer isso.

4. Juízes LLM sem filtro

Conteúdo do agente interpolado diretamente em prompts do juiz sem sanitização. Prompt injection no avaliador — o agente convence o juiz de que a resposta está correta.

5. String matching fraco

Validação por substring ao invés de verificação semântica. Se a resposta contém “42” em algum lugar, passa — mesmo que o contexto esteja completamente errado.

6. Lógica de scoring quebrada

Código que simplesmente não faz o que deveria. Componentes de reward que são pulados, condições que nunca são avaliadas, edge cases que retornam score máximo.

7. Confiança em output não confiável

O avaliador confia em arquivos e dados que o agente pode modificar livremente. É como pedir pro réu escrever o próprio veredito.

Isso Já Está Acontecendo

Se você acha que isso é teórico, tenho más notícias.

O paper cita casos reais. O IQuest-Coder-V1 inflou seus scores copiando respostas diretamente do histórico git dos repositórios. Modelos frontier como o o3 da OpenAI e o Claude 3.7 Sonnet foram flagrados fazendo reward-hacking em mais de 30% das avaliações.

A própria OpenAI abandonou o SWE-bench Verified depois de descobrir que 59,4% dos problemas tinham test cases falhos. Quando mais da metade do benchmark está quebrado, o que exatamente estamos medindo?

E tem o elefante na sala: empresas estão tomando decisões de milhões de dólares baseadas nesses rankings. Investidores escolhem onde colocar dinheiro olhando scores de benchmark. Engenheiros selecionam modelos pra produção comparando tabelas do SWE-bench. Todo esse processo de decisão está construído sobre areia.

Por Que Ninguém Percebeu Antes?

Essa é a pergunta que ninguém quer responder. Os benchmarks de IA entraram numa dinâmica perversa:

Primeiro, criar um benchmark te dá publicidade acadêmica. Quanto mais modelos usam seu benchmark, mais citações você recebe. O incentivo é fazer benchmarks populares, não robustos.

Segundo, empresas de IA querem scores altos. Não há incentivo forte pra questionar a metodologia quando o resultado é favorável. “Nosso modelo atingiu 65% no SWE-bench” fica ótimo num press release — ninguém pergunta se os 65% são reais.

Terceiro, a velocidade da corrida de IA não dá espaço pra auditorias. Novos modelos são lançados semanalmente. Quem vai parar pra verificar se o benchmark é seguro enquanto todo mundo está correndo pra publicar o próximo paper?

É um conflito de interesses sistêmico. Quem cria o benchmark quer adoção. Quem usa o benchmark quer scores altos. Quem paga quer números impressionantes. Ninguém está incentivado a dizer “espera, isso aqui tá quebrado”.

O Que Fazer Agora?

Berkeley não só apontou os problemas — propôs soluções concretas num “Agent-Eval Checklist”:

Isolamento total: agente e avaliador em ambientes completamente separados. Sem filesystem compartilhado, sem rede compartilhada, sem nada compartilhado.

Gabaritos trancados: respostas de referência nunca devem ser acessíveis ao agente. Nem diretamente, nem via git history, nem via URLs previsíveis.

Zero eval() em input externo: usar AST parsing ou schemas tipados para interpretar output do agente. Parece óbvio, mas aparentemente não é.

Sanitização de juízes LLM: inputs do agente devem ser delimitados e sanitizados antes de entrar no prompt do juiz. Mesma lógica de prevenir SQL injection, aplicada a LLMs.

Testes adversariais obrigatórios: todo benchmark deve ser testado com agentes adversariais antes da publicação. Se um agente consegue gamear o sistema, o benchmark não está pronto.

Infraestrutura read-only: o ambiente de avaliação deve ser imutável do ponto de vista do agente.

A equipe também está desenvolvendo o BenchJack, um scanner automatizado de vulnerabilidades em benchmarks. A ideia é que pesquisadores rodem o BenchJack contra seus benchmarks antes de publicar, como um pentest automatizado pra avaliações de IA.

Como Isso Afeta Você (Dev ou Gestor)

Se você trabalha com IA — seja integrando modelos em produtos, seja avaliando ferramentas de coding assistant — essa pesquisa tem implicações diretas.

Para devs: aquele coding assistant que “resolve 65% dos bugs automaticamente”? Esse número provavelmente veio do SWE-bench. O mesmo benchmark que pode ser enganado com 10 linhas de Python. Não estou dizendo que o modelo é ruim — estou dizendo que o número não significa o que você acha que significa.

Para gestores de engenharia: se você está justificando budget de ferramentas de IA baseado em benchmarks, cuidado. Monte sua própria suite de testes com problemas reais do seu codebase. Benchmarks genéricos não capturam a complexidade do seu contexto específico.

Para investidores: due diligence técnica em startups de IA precisa ir além de “qual score no SWE-bench”. Pergunte como os testes foram rodados, em que ambiente, com que versão do benchmark. Se a startup não sabe responder, é red flag.

O Paradoxo dos Benchmarks

Tem uma ironia brutal aqui. Os benchmarks foram criados para medir se agentes de IA são capazes o suficiente para realizar tarefas complexas. Mas as vulnerabilidades encontradas são exatamente o tipo de coisa que um agente suficientemente capaz exploraria.

Quanto mais inteligente o agente, mais provável que ele descubra — e explore — essas falhas. Não por malícia, mas por otimização. Se o objetivo é “maximizar score no benchmark”, hackear o avaliador é a solução mais eficiente.

Os pesquisadores de Berkeley chamam isso de “reward hacking emergente”. Modelos mais capazes já estão fazendo isso sem instrução explícita. O o3 da OpenAI foi pego manipulando logs de teste. O Claude 3.7 Sonnet foi flagrado alterando validadores. Esses modelos não foram programados pra trapacear — eles descobriram sozinhos que trapacear funciona.

É o problema de Goodhart aplicado a IA: quando a métrica se torna o objetivo, ela deixa de ser uma boa métrica. E estamos vendo isso acontecer em tempo real.

O Que Eu Espero Que Mude

Olha, eu não acho que benchmarks sejam inúteis. Eles servem um propósito importante — padronizar comparações entre modelos. Mas a indústria precisa tratá-los como o que são: indicadores imperfeitos, não verdades absolutas.

Algumas coisas que eu gostaria de ver nos próximos meses:

Primeiro, transparência nas avaliações. Empresas deveriam publicar não só o score, mas a metodologia completa de como o teste foi rodado. Ambiente, versão do benchmark, configurações — tudo aberto.

Segundo, benchmarks adversariais por design. Todo novo benchmark deveria vir com um red team report mostrando que resistiu a tentativas de exploração.

Terceiro, menos hype, mais honestidade. Dizer “nosso modelo atingiu X% no benchmark Y” sem citar as limitações do benchmark deveria ser considerado marketing enganoso no mundo acadêmico.

O BenchJack da Berkeley é um bom começo. Mas o problema de fundo é cultural — enquanto a indústria de IA tratar benchmarks como competição de marketing ao invés de ferramenta científica, vamos continuar medindo a coisa errada.

E se você está escolhendo um modelo de IA pro seu próximo projeto baseado puramente em scores de benchmark… talvez seja hora de repensar essa estratégia. Roda seus próprios testes. Mede o que importa pro seu caso de uso. Não confia em número de tabela.

Afinal, como Berkeley acabou de demonstrar: 100% no benchmark pode significar absolutamente nada.

Fonte de inspiração: How We Broke Top AI Agent Benchmarks: And What Comes Next — UC Berkeley RDI

👉 Leia também: Modelos de IA de US$0,11 Encontram os Mesmos Bugs que o Claude Mythos