Por que os rankings de modelos de IA para código podem estar errados (e o que fazer sobre isso)

Quando olhamos para os rankings de modelos de IA especializados em programação, como os que aparecem no SWE-bench ou Terminal-Bench, costumamos assumir que as diferenças de poucos pontos percentuais entre os top models refletem variações reais de capacidade. No entanto, descobertas recentes mostram que a infraestrutura por trás desses benchmarks pode estar introduzindo um ruído muito maior do que imaginávamos — grande o suficiente para distorcer completamente as comparações.

Em experimentos internos da Anthropic, a diferença entre a configuração mais e menos otimizada no Terminal-Bench 2.0 chegou a 6 pontos percentuais (p < 0.01). Isso significa que dois modelos idênticos, rodando sob condições de hardware diferentes, podem apresentar scores que se diferenciam mais do que a margem que separa os líderes no ranking.

Como benchmarks de coding com IA funcionam de forma diferente

Benchmarks tradicionais de IA avaliam diretamente a saída do modelo — o ambiente de execução não influencia o resultado. Mas os agentic coding evals funcionam de maneira completamente diferente: os modelos recebem um ambiente completo onde podem escrever programas, executar testes, instalar dependências e iterar ao longo de múltiplos turnos.

O runtime deixa de ser um container passivo e se torna um componente integral do processo de resolução de problemas. Isso significa que dois agentes com diferentes budgets de recursos e limites de tempo não estão, na prática, fazendo o mesmo teste.

Embora os desenvolvedores de evals tenham começado a considerar isso — o Terminal-Bench 2.0, por exemplo, especifica CPU e RAM recomendados por task — especificar recursos não é o mesmo que garantir consistência na execução. E foi ao investigar essa lacuna que a equipe da Anthropic descobriu que a metodologia de enforcement pode mudar fundamentalmente o que o benchmark está medindo.

O problema descoberto durante a calibração

A Anthropic roda o Terminal-Bench 2.0 em um cluster Google Kubernetes Engine. Durante a calibração do setup, perceberam que seus scores não batiam com o leaderboard oficial do benchmark, e as taxas de erro de infraestrutura eram surpreendentemente altas: até 6% das tasks falhavam por erros de pod, na maioria dos casos não relacionados à capacidade do modelo de resolver o problema.

A discrepância nos scores estava relacionada ao enforcement. A implementação Kubernetes tratava as especificações de recursos por task tanto como um piso quanto como um teto rígido: cada container tinha os recursos especificados garantidos, mas era terminado no momento em que os excedia.

Container runtimes aplicam recursos através de dois parâmetros separados: uma alocação garantida (os recursos reservados antecipadamente) e um limite rígido no qual o container é terminado. Quando esses valores são iguais, não há margem para picos transientes: uma flutuação momentânea de memória pode matar um container que, de outra forma, teria sucesso.

Para contornar isso, o leaderboard do Terminal-Bench usa um provider de sandboxing diferente, cuja implementação é mais leniente, permitindo overallocation temporária sem terminar o container, priorizando a estabilidade da infraestrutura.

Quantificando o impacto da configuração de recursos

Para medir o efeito do scaffold, a equipe executou o Terminal-Bench 2.0 em seis configurações de recursos diferentes:

Tudo mais permaneceu constante: mesmo modelo Claude, mesmo harness, mesmo conjunto de tasks.

Os resultados surpreendentes

As taxas de sucesso aumentaram com o headroom de recursos. Isso foi primariamente impulsionado por taxas de erro de infraestrutura que caíram monotonicamente a cada step:

• 1x (strict): 5.8% de erros de infra

• 3x: 2.1% de erros de infra (queda significativa, p < 0.001)

• Uncapped: 0.5% de erros de infra

Com mais headroom, menos containers foram terminados por exceder sua alocação.

De 1x até 3x, os scores de sucesso flutuam dentro das margens de ruído (p=0.40). A maioria das tasks que estavam crashando em 1x teriam falhado de qualquer forma — algo observado nos dados. O agente explora, atinge uma barreira de recursos e é interrompido, mas nunca estava em um caminho para uma solução correta.

A mudança crítica acima de 3x

A partir de 3x, no entanto, essa tendência muda: as taxas de sucesso sobem mais rápido do que os erros de infra declinam.

Entre 3x e uncapped:

• Erros de infra caem 1.6 pontos percentuais adicionais

• Sucesso aumenta quase 4 pontos percentuais

Os recursos extras permitem que o agente tente abordagens que só funcionam com alocações generosas, como:

• Baixar dependências grandes

• Spawnar subprocessos caros

• Executar test suites que consomem muita memória

No uncapped, o lift total sobre 1x é de +6 pontos percentuais (p < 0.01).

Tasks como rstan-to-pystan e compile-compcert melhoram significativamente suas taxas de sucesso quando recebem headroom de memória.

O que isso significa para a medição de capacidade

Até aproximadamente 3x das specs do Terminal-Bench, os recursos adicionais resolvem problemas de confiabilidade da infraestrutura — nomeadamente, picos transientes de recursos. O provider de sandboxing usado pelos mantenedores do Terminal-Bench está implicitamente fazendo isso nos bastidores; o eval fica mais estável sem ficar mais fácil.

Acima da marca de 3x, entretanto, recursos adicionais começam a ativamente ajudar o agente a resolver problemas que não poderia resolver antes, o que mostra que limites podem realmente mudar o que o eval mede.

Diferentes estratégias, diferentes resultados

Limites apertados recompensam inadvertidamente estratégias muito eficientes, enquanto limites generosos são mais permissivos e recompensam agentes que conseguem explorar melhor todos os recursos disponíveis.

Um agente que escreve código enxuto e eficiente muito rápido se sairá bem sob restrições apertadas. Um agente que força soluções com ferramentas pesadas se sairá bem sob limites generosos. Ambos são aspectos legítimos para testar, mas colapsar ambos em um único score sem especificar a configuração de recursos torna as diferenças — e a generalização no mundo real — difíceis de interpretar.

Exemplo prático: bn-fit-modify

No bn-fit-modify, uma task do Terminal-Bench que requer fitting de redes Bayesianas, o primeiro movimento de alguns modelos é instalar o stack padrão de data science do Python: pandas, networkx, scikit-learn e todas as suas dependências.

• Sob limites generosos: isso funciona

• Sob limites apertados: o pod fica sem memória durante a instalação, antes que o agente escreva uma única linha de código da solução

Uma estratégia mais enxuta existe (implementar a matemática do zero usando apenas a biblioteca padrão), e alguns modelos de fato defaultam para isso. Outros não. Diferentes modelos têm diferentes abordagens default, e a configuração de recursos determina quais dessas abordagens acabam tendo sucesso.

Validação em outros benchmarks

O mesmo efeito foi replicado em diferentes modelos da Anthropic. A direção do efeito foi consistente, enquanto a magnitude variou. As mesmas tendências parecem valer para modelos além do Claude, mas não foram rigorosamente testadas.

A equipe também testou se esse padrão se mantém em evals fora do Terminal-Bench executando um experimento crossover no SWE-bench. Variaram a RAM total disponível até 5x o baseline em 227 problemas com 10 amostras cada.

O mesmo efeito se manteve, embora a magnitude fosse menor: os scores aumentaram monotonicamente com a RAM, mas foram apenas 1.54 pontos percentuais mais altos em 5x do que em 1x. As tasks do SWE-bench são menos intensivas em recursos, então um efeito menor é esperado, mas isso mostra que a alocação de recursos não é neutra lá também.

Outras fontes de variância

A alocação de recursos não é a única variável oculta. Em certas configurações, os limites de tempo também começam a desempenhar um papel.

Em princípio, cada elemento do setup de avaliação pode influenciar o score final:

• Saúde do cluster

• Especificações de hardware

• Nível de concorrência

• Bandwidth de egress

Agentic evals são testes de sistema end-to-end por construção, e qualquer componente desse sistema pode atuar como um confounding factor.

Variação por hora do dia

Foi observado anedoticamente que as taxas de sucesso flutuam com a hora do dia, provavelmente porque a latência da API varia com padrões de tráfego e incidentes. Esse efeito não foi formalmente quantificado, mas ilustra um ponto maior: a fronteira entre "capacidade do modelo" e "comportamento da infraestrutura" é mais nebulosa do que um único score de benchmark sugere.

Um provider de modelo pode proteger sua infraestrutura de eval dedicando hardware, mas avaliadores externos não conseguem fazer o mesmo facilmente.

Recomendações para a comunidade

O cenário ideal seria executar cada eval sob exatamente as mesmas condições de hardware — tanto o scaffold executando o eval quanto o stack de inferência — pois isso garantiria reprodutibilidade perfeita. No entanto, isso nem sempre é prático.

Para desenvolvedores de benchmarks

Dado como os container runtimes realmente aplicam recursos — via uma alocação garantida e um limite separado de hard kill — a recomendação é que evals especifiquem ambos os parâmetros por task, não um único valor fixo.

Um único spec exato define a alocação garantida igual ao limite de kill, deixando margem zero: os picos de memória transientes documentados em 1x são suficientes para desestabilizar o eval. Separar os dois parâmetros permite dar aos containers breathing room suficiente para evitar OOM kills espúrios, enquanto ainda aplica um teto rígido que previne inflação de score.

A banda entre eles deve ser calibrada para que os scores no piso e no teto caiam dentro do ruído um do outro. Por exemplo, no Terminal-Bench 2.0, um teto de 3x sobre as specs por task cortou as taxas de erro de infra em aproximadamente dois terços (5.8% para 2.1%, p < 0.001) enquanto mantinha o lift de score modesto e bem dentro do ruído (p = 0.40).

Para consumidores de benchmarks

Os dados sugerem que diferenças de leaderboard abaixo de 3 pontos percentuais merecem ceticismo até que a configuração do eval seja documentada e replicada. O spread observado em uma faixa moderada de configurações de recursos no Terminal-Bench fica logo abaixo de 2 pontos percentuais.

Intervalos de confiança binomiais ingênuos já abrangem 1-2 pontos percentuais; os confounding factors de infraestrutura documentados aqui se acumulam em cima disso, não dentro dele. Nos extremos da faixa de alocação, o spread atinge 6 pontos.

FAQ sobre ruído em agentic coding benchmarks

Por que benchmarks agentic são mais suscetíveis a ruído de infraestrutura?

Diferente de benchmarks estáticos que apenas avaliam a saída, agentic coding evals dão aos modelos um ambiente completo onde executam código, instalam dependências e iteram. O runtime se torna parte integral do problema, não apenas um container passivo.

Qual é o impacto real nos rankings?

Uma diferença de poucos pontos no leaderboard pode refletir uma genuína diferença de capacidade ou simplesmente hardware mais robusto. No Terminal-Bench 2.0, a variação chegou a 6 pontos percentuais apenas mudando a configuração de recursos.

Como devem ser configurados os recursos nos benchmarks?

Idealmente, especifique tanto a alocação garantida quanto o limite de kill separadamente, com um headroom calibrado (como 3x) que reduza erros de infraestrutura sem inflar artificialmente os scores.

Outros fatores além de CPU e RAM afetam os resultados?

Sim. Latência de API, hora do dia, saúde do cluster, concorrência e até bandwidth podem introduzir variância nos resultados.

Conclusão: uma liderança de poucos pontos pode ser apenas uma VM maior

Essas descobertas têm consequências práticas além da infraestrutura de eval. Scores de benchmarks são cada vez mais usados como inputs para tomada de decisão, mas esse aumento de atenção (e dependência) nem sempre veio acompanhado de rigor correspondente em como são executados ou reportados.

Como as coisas estão hoje, uma liderança de 2 pontos em um leaderboard pode refletir uma diferença genuína de capacidade, ou pode refletir que um eval rodou em hardware mais robusto, ou até em um horário mais favorável — ou ambos. Sem configurações de setup publicadas (ou padronizadas), é difícil dizer de fora, a menos que partes interessadas façam um esforço extra para reproduzir resultados objetivos sob condições idênticas.

Para labs como a Anthropic, a implicação é que a configuração de recursos para agentic evals deve ser tratada como uma variável experimental de primeira classe, documentada e controlada com o mesmo rigor que formato de prompt ou temperatura de sampling. Para mantenedores de benchmarks, publicar specs de recursos recomendados (como o Terminal-Bench 2.0 faz) é um grande passo, enquanto especificar a metodologia de enforcement fecharia a lacuna identificada.

E para qualquer um consumindo resultados de benchmarks, o takeaway central é que pequenas diferenças de score em agentic evals carregam mais incerteza do que a precisão dos números reportados sugere — especialmente porque alguns confounding factors são simplesmente difíceis demais de controlar.

Até que a metodologia de recursos seja padronizada, diferenças de leaderboard abaixo de 3 pontos percentuais merecem ceticismo até que a configuração do eval seja documentada e replicada. Uma liderança de poucos pontos pode sinalizar uma diferença real de capacidade — ou pode ser apenas uma VM maior.