Uma pontuação de benchmark não é uma avaliação do modelo

Uma vantagem de dois pontos num benchmark de programação não significa que dois modelos vão trabalhar quase da mesma forma num repositório real. A pontuação aplica-se a um conjunto de tarefas, uma configuração de agente e uma regra de avaliação. Não indica quanta supervisão cada modelo exige, quanto custam as suas falhas ou se eu aceitaria a sua pull request.

O DeepSWE oferece um bom exemplo. Luna Max atinge 67,2% e Sol High 69,4%, embora o custo apresentado de Luna seja cerca de um sexto [2]. Este resumo faz Luna parecer a escolha óbvia. Na prática, taxas de sucesso semelhantes podem esconder grandes diferenças no tempo que gasto a orientar o modelo, verificar os seus pressupostos e reparar o seu trabalho.

Os programadores chamam por vezes a esta diferença “big model smell”: a sensação de que um modelo mais capaz compreende o trabalho com menos explicações e toma menos decisões que depois têm de ser anuladas. A expressão é informal, mas a experiência que descreve pode ser testada. Posso contar quantas vezes tenho de redirecionar o modelo, reparar o seu trabalho ou rejeitar uma patch que passou nos testes.

O que medem realmente 67% e 69%?

Nos dados do DeepSWE v1.1 da Datacurve, Luna Max passou 301 de 448 tentativas e Sol High 313 de 451 [1] [2]. Estes totais produzem as pontuações de 67,2% e 69,4%. Mostram uma diferença de 2,2 pontos percentuais neste teste, mas não que os modelos trabalhem da mesma forma no dia a dia.

O DeepSWE mantém constantes várias variáveis importantes. As suas 113 tarefas vêm de 91 repositórios open source e abrangem TypeScript, Go, Python, JavaScript e Rust [1]. Foram escritas para esta avaliação, em vez de copiadas de issues antigas do GitHub. Todos os modelos utilizaram também mini-swe-agent com a mesma ferramenta bash e o mesmo prompt base [5], e um contentor novo verificou cada patch quanto ao comportamento pedido e a regressões.

Estes controlos tornam a comparação útil, mas o resultado mantém alguma incerteza. A Datacurve atribui a Luna um intervalo de 95% entre 63,2% e 71,2%, enquanto o de Sol vai de 68,0% a 70,8% [2]. Os intervalos sobrepõem-se, por isso a diferença de 2,2 pontos é menor do que a variação observada entre execuções. A Datacurve não publica uma comparação estatística dos dois modelos nas mesmas tarefas, pelo que os dados não demonstram que a vantagem de 2,2 pontos de Sol seja repetível.

As duas configurações também utilizam níveis de esforço diferentes: max para Luna e high para Sol. A classificação muda com a medida empírica Pass@4 da Datacurve, que pergunta se pelo menos uma das tentativas registadas resolveu cada tarefa. Nesta medida, Luna cobre 90,3% das 113 tarefas e Sol 86,7% [2]. O sucesso por tentativa favorece Sol, enquanto a cobertura das tarefas favorece Luna, porque as duas medidas respondem a perguntas diferentes.

Medição	Luna Max	Sol High
Sucesso por tentativa, %	67,2	69,4
Intervalo de 95% entre execuções	63,2–71,2%	68,0–70,8%
Tentativas avaliadas	448	451
Tarefas com ≥1 sucesso, %	90,3 (Melhor valor da linha)	86,7
Custo médio por tentativa, $	0,61 (Melhor valor da linha)	3,47
Tokens de saída por tentativa, milhares	73,4	28,5 (Melhor valor da linha)
Passos do agente por tentativa	101,7	36,9 (Melhor valor da linha)

A comparação completa dá-me uma razão para testar ambos os modelos, mas não para os considerar equivalentes. Todas as medidas da figura 1 vêm das tarefas e da configuração de agente do DeepSWE. O meu repositório pode favorecer outras qualidades e revelar outras falhas.

Porque podem duas pontuações próximas parecer tão diferentes?

Dois modelos podem passar o mesmo número de tarefas e exigir quantidades de trabalho muito diferentes ao programador. Observo se o modelo encontra os ficheiros certos, preserva o design existente, pergunta antes de assumir algo arriscado, recupera de um comando falhado e para quando termina a alteração pedida. O DeepSWE reduz o resultado final a sucesso ou falha, por isso não avalia estes comportamentos em separado.

Os dados brutos do DeepSWE dão uma pista. Luna Max utilizou em média 101,7 passos do agente e 73 400 tokens de saída por tentativa, contra 36,9 passos e 28 450 tokens de Sol High [2]. Luna precisou de cerca de 2,8 vezes mais passos e 2,6 vezes mais tokens para atingir uma taxa de sucesso semelhante. Os dados não dizem se esses passos adicionais foram úteis, mas mostram claramente que os modelos não trabalharam da mesma forma.

O custo apresentado também precisa de contexto. Os ensaios de Luna foram executados a 7 de julho, quando o consumo de tokens registado custava cerca de 3,03 dólares por tentativa [2] [3]. A OpenAI reduziu os preços dos tokens de Luna em 80% a 30 de julho [4], e o DeepSWE recalculou o consumo antigo com a nova tarifa. Foi assim que 3,03 dólares passaram para os 0,61 dólares apresentados. O número mais baixo estima corretamente o custo atual do mesmo consumo, mas não o montante pago pela Datacurve quando realizou o teste.

O custo de API por tentativa também difere do custo necessário para obter uma alteração aceite. O preço da leaderboard exclui repetições, tempo de revisão, edições manuais, espera e um eventual segundo modelo usado para inspecionar ou reparar o trabalho do primeiro. Uma tentativa pode custar um sexto e continuar mais cara no total se o engenheiro tiver de supervisionar todas as decisões.

Estas diferenças no trabalho são o que a expressão “big model smell” procura descrever. As perguntas úteis são concretas: o modelo manteve presentes todas as restrições? Tomou decisões sensatas para este repositório? Evitou alterações sem relação, expressou a incerteza com clareza e falhou de uma forma fácil de detetar e reverter? Uma única taxa de sucesso não consegue responder a nenhuma delas.

Quanto pode a configuração alterar a pontuação?

Um benchmark de programação testa um sistema completo, não apenas o modelo. O prompt, as ferramentas, a política de contexto, os limites de execução, o número de tentativas e o avaliador afetam todos o resultado. Alterar um deles pode deslocar a pontuação, mesmo quando o modelo permanece exatamente igual.

O paper de SWE-agent publicado na NeurIPS oferece um exemplo controlado. Com o mesmo GPT-4 Turbo no SWE-bench Lite, uma interface limitada à shell resolveu 11% das tarefas, enquanto a interface completa de SWE-agent resolveu 18% [6]. Quando os investigadores substituíram resultados de pesquisa repetidos por uma ferramenta que os resumia, a pontuação subiu de 12% para 18%. Limitar o visualizador a 100 linhas, em vez de devolver o ficheiro inteiro, mudou-a de 12,7% para 18%. Estas alterações à interface acrescentaram cinco a sete pontos percentuais sem mudar o modelo.

O número de tentativas altera ainda mais o valor em destaque. Seis execuções da mesma combinação de GPT-4 e SWE-agent atingiram em média 17,94% na primeira tentativa. Ao considerar uma tarefa resolvida quando qualquer uma das seis tentativas passava, a cobertura subia para 32,67% [6]. Este aumento de 14,73 pontos pode ser útil se um sistema em produção executar realmente seis candidatos e souber identificar o correto. Torna-se enganador ao lado de um resultado com uma única tentativa sem uma indicação clara.

A infraestrutura também acrescenta ruído. A Anthropic manteve o modelo Claude, o harness e o conjunto de tarefas do Terminal-Bench 2.0 constantes e alterou apenas os limites de CPU, memória e duração. A configuração sem limites rígidos obteve cerca de mais seis pontos percentuais, enquanto os erros de infraestrutura caíram de 5,8% para 0,5% [7]. Por isso, uma linha de uma leaderboard deve ser lida como o resultado de um sistema testado, não como um número permanente ligado ao nome do modelo.

Alteração ao sistema	Antes	Depois	Alteração
Apenas shell → interface SWE-agent	11,0%	18,0%	+7,0 pp
Ficheiro inteiro → vista de 100 linhas	12,7%	18,0%	+5,3 pp
Uma → seis tentativas	17,94%	32,67%	+14,73 pp
Limites rígidos → sem limites	Não publicado	Não publicado	cerca de +6 pp

As quatro alterações da figura 2 superam a diferença de 2,2 pontos entre Luna e Sol. Isto não torna os benchmarks inúteis, mas faz da configuração parte do resultado. Antes de comparar duas pontuações, verifico a versão das tarefas, a configuração do agente, os recursos, o número de tentativas e a regra de avaliação.

Porque pode uma patch que passou nos testes ser rejeitada?

Passar um benchmark significa que uma patch passou nas verificações do benchmark. É um indício útil de que o código funciona, não uma revisão de código. As verificações podem não detetar uma solução incompleta e talvez não considerem a facilidade de manutenção, a arquitetura existente, alterações sem relação ou o trabalho necessário antes do merge.

O EvalPlus mostrou quanto os testes escolhidos podem afetar o resultado. Os investigadores aumentaram em cerca de 80 vezes as suites de testes do HumanEval e avaliaram 26 modelos. Com os testes mais exigentes, as taxas de sucesso dos modelos mais afetados caíram entre 19,3 e 28,9 pontos percentuais, e algumas classificações inverteram-se [8]. As respostas não mudaram; as suites maiores simplesmente detetaram mais erros.

Os benchmarks de repositórios têm o mesmo problema. Em fevereiro de 2026, a OpenAI auditou 138 tarefas do SWE-bench Verified que o o3 falhava de forma irregular em 64 execuções. Encontrou problemas materiais em 59,4% desse grupo escolhido, incluindo testes que rejeitavam soluções válidas e testes que exigiam comportamento não mencionado na issue [9]. Como a auditoria se concentrou de propósito em tarefas suspeitas, os 59,4% não descrevem as 500 tarefas. Mostram, ainda assim, que erros nas tarefas e nos testes podem distorcer as diferenças entre modelos muito capazes.

O erro inverso importa tanto: uma patch pode passar nos testes automáticos e continuar imprópria para merge. A METR pediu a maintainers que revissem 296 pull requests geradas por IA em três repositórios e 95 tarefas. A taxa de aceitação ficou 24,2 pontos percentuais abaixo da pontuação automática do SWE-bench [10]. Os revisores rejeitaram patches por falhas na função principal, problemas não relacionados, má qualidade do código e outras dificuldades de integração. Uma pontuação binária esconde todas estas razões atrás da mesma indicação de sucesso ou falha.

mais testes no EvalPlus

80×

algumas classificações inverteram-se

problemas numa auditoria dirigida

59,4%

não representa todas as 500 tarefas

diferença para os maintainers

24,2 pp

a METR reviu 296 pull requests

Em conjunto, estes resultados mostram que a qualidade dos testes e a revisão humana respondem a perguntas diferentes. “A patch passou” continua a ser uma informação útil, mas não me diz se quero que esse modelo altere todos os dias o meu branch.

O que esconde uma média sobre a fiabilidade?

Uma taxa média combina todos os sucessos e todas as falhas num único número. Não mostra se o modelo tem sucesso de forma consistente, se a fiabilidade colapsa em tarefas longas ou se uma execução falhada produz um pequeno diff errado ou danifica o estado de trabalho. Estas diferenças importam quando uso o modelo várias vezes, em vez de o testar apenas uma.

O paper de tau-bench torna a repetibilidade visível com pass^k, que pergunta se um agente resolve a mesma tarefa em todas as tentativas. O GPT-4o atingiu 61,2% nas tarefas de retalho quando visto numa única tentativa, mas o seu pass^8 de retalho caiu abaixo de 25% [11]. Um modelo que funciona três vezes e falha à quarta pode manter uma média respeitável. Como colaborador diário, parece imprevisível.

A duração da tarefa cria uma separação semelhante. A METR avaliou agentes em 170 tarefas, com cerca de oito execuções por par de modelo e tarefa. A duração em que um modelo tinha sucesso 80% das vezes era quatro a seis vezes menor do que o seu horizonte de sucesso a 50% [12]. Assim, um modelo pode receber crédito por tarefas impressionantes de duas horas ao limiar de 50% e continuar fiável apenas em trabalhos muito mais curtos.

Isto ajuda a explicar por que razão as impressões práticas podem divergir dos resultados de uma leaderboard. A utilização diária inclui tarefas repetidas, contexto do repositório fácil de ignorar, comandos avariados, requisitos ambíguos, ciclos de revisão e as consequências das piores execuções falhadas. As impressões pessoais também podem estar erradas, porque uma resposta bem apresentada ou uma única falha desastrosa podem dominar a minha memória. Em vez de escolher entre benchmarks e intuição, tenho de medir as partes do meu fluxo de trabalho que criaram essa impressão.

Como comparo modelos para o meu próprio trabalho?

Utilizo benchmarks públicos como filtro. Dizem-me que modelos merecem tempo e dinheiro para um teste, e uma avaliação controlada como o DeepSWE oferece muito mais informação do que uma demonstração de lançamento. A escolha final continua a vir de uma pequena avaliação construída com o meu trabalho.

A Anthropic recomenda começar a avaliação de um agente com 20 a 50 tarefas retiradas de verificações manuais, falhas comuns, relatórios de bugs e pedidos reais de desenvolvimento [13]. Este número basta para revelar grandes desajustes sem fingir produzir uma leaderboard universal. Num confronto próximo, executaria as mesmas tarefas mais de uma vez e manteria ambiente, ferramentas, prompts, nível de esforço e orçamento constantes.

Antes de olhar para os resultados, definiria o que significa aceitar o trabalho. Os testes vêm primeiro, mas não formam toda a grelha. Também registaria:

• se o resultado foi aceite à primeira tentativa;
• o tempo total até um resultado aceite, incluindo revisão e reparação;
• os minutos de revisão ativa, separados da latência do modelo;
• esclarecimentos, redirecionamentos, reinícios e edições manuais;
• ficheiros alterados sem necessidade e violações das convenções do repositório;
• falhas graves, como regressões de segurança, risco de perda de dados ou problemas não relacionados;
• tokens e custo de API para o resultado completo e aceite.

Para avaliar a qualidade do código, esconderia os nomes dos modelos e analisaria patches concorrentes por ordem aleatória sempre que fosse prático. Publicaria resultados por tipo de tarefa, em vez de combinar correções de bugs, revisões, refactors e features longas num único total. Se dois modelos continuarem próximos após várias tentativas, escolheria o mais barato. Se o seu custo de revisão mais elevado gastar a poupança de API, porém, não é o modelo mais barato para o meu fluxo.

O resultado do DeepSWE dá uma boa razão para testar Luna Max a sério. A sua taxa de sucesso fica dentro da incerteza em torno de Sol High e o seu preço atual de API é muito mais baixo. Isto não torna os modelos intercambiáveis. Para decidir qual é mais barato e melhor para o meu trabalho, também tenho de contar a orientação, a revisão, as reparações e as execuções falhadas que a leaderboard deixa de fora.