Pontuações próximas num benchmark escondem modelos diferentes

Pontuações próximas em benchmarks de IA podem esconder modelos muito diferentes num repositório real. No DeepSWE, Luna Max fica 2,2 pontos atrás de Sol High, mas usa quase três vezes mais passos do agente. A taxa de sucesso não me diz quanta supervisão um modelo exige nem se eu aceitaria a sua pull request.

O que mede uma pontuação de 67% contra 69%?

Mede o sucesso por tentativa numa configuração específica do DeepSWE. Os 69,4% de Sol High superam os 67,2% de Luna Max por 2,2 pontos, mas essa diferença é menor do que a incerteza entre execuções nos mesmos dados [2]. O resultado dá-me uma razão para testar ambos os modelos, não uma avaliação completa de cada um.

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)

Os dados do DeepSWE v1.1 da Datacurve registam 301 tentativas bem-sucedidas em 448 para Luna Max e 313 em 451 para Sol High [1] [2]. São estes totais que produzem as pontuações principais da figura 1.

O DeepSWE mantém constantes várias variáveis importantes. As suas 113 tarefas vêm de 91 repositórios de código aberto 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]. Um contentor novo verificou se cada patch cumpria o comportamento pedido e se introduzia regressões.

Estes controlos tornam a comparação útil, mas o resultado continua a ter 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, portanto os dados não estabelecem que a vantagem de Sol se repita.

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.

Todas as medições da figura 1 pertencem às tarefas e à configuração de agente do DeepSWE. O meu repositório pode valorizar outras qualidades e expor outras falhas, por isso importa perceber como cada modelo chega ao resultado.

Pontuações próximas podem esconder quase três vezes mais passos

Uma taxa de sucesso ignora como o modelo chegou ao patch, por isso duas pontuações semelhantes podem 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 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 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 de 2026, 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 de 2026 [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 novas tentativas, 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.

Os programadores chamam por vezes a estas diferenças “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 medida. Posso contar quantas vezes redireciono o modelo, reparo o seu trabalho ou rejeito um patch que passou nos testes.

Isso transforma a impressão em perguntas concretas. O modelo acompanhou todas as restrições, tomou decisões sensatas para este repositório e evitou alterações sem relação? Quando falhou, foi fácil detetar e reverter o problema? Uma única taxa de sucesso não responde a estas perguntas.

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

Nos exemplos publicados abaixo, alterações à configuração do benchmark deslocaram as pontuações entre cerca de 5 e 15 pontos percentuais sem mudar o modelo [6] [7]. É mais do que a diferença de 2,2 pontos entre Luna e Sol. Um benchmark de programação mede o prompt, as ferramentas, os limites de execução, o número de tentativas e o avaliador juntamente com o modelo.

O artigo sobre 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 que 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.

As quatro alterações abaixo deslocaram as pontuações mais do que a diferença principal entre Luna e Sol.

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 → execução sem limites	Não publicado	Não publicado	cerca de +6 pp

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. A reavaliação do Muse Spark 1.3 no índice da Artificial Analysis é um caso recente em que a configuração decide a posição.

Porque pode um patch que passou nos testes ser rejeitado?

Um patch pode passar num benchmark e ser rejeitado numa revisão de código. O resultado é um indício útil de que o código funciona, mas as verificações podem não detetar uma solução incompleta. Também podem ignorar a facilidade de manutenção, a arquitetura existente, alterações sem relação ou o trabalho necessário antes do merge.

O artigo sobre EvalPlus da NeurIPS mostrou quanto os testes escolhidos podem afetar o resultado. Os investigadores aumentaram em cerca de 80 vezes os conjuntos 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; os conjuntos 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: um patch pode passar nos testes automáticos e continuar impróprio para merge. A METR pediu aos responsáveis pelos projetos que analisassem 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 responsáveis

24,2 pp

a METR analisou 296 pull requests

Em conjunto, estes resultados mostram que a qualidade dos testes e a revisão humana respondem a perguntas diferentes. “O patch passou” continua a ser informação útil, mas não me diz se quero que esse modelo faça alterações todos os dias no meu branch. As ferramentas podem tornar essa revisão mais fácil de saltar, e por isso escrevi sobre o Agents Window do Cursor e como voltar a pôr o código à frente.

O que esconde uma média? Repetibilidade e tarefas longas

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 cai 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 artigo sobre tau-bench publicado no arXiv 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 que falham, requisitos ambíguos, ciclos de revisão e as consequências das piores execuções. 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. O Opus 5 é o caso que conheço melhor: depois de cinco semanas de uso diário, expliquei porque o Opus 5 não é tão mau como a internet diz.

Como devo comparar 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, refatorizações e funcionalidades longas num único total. Se dois modelos continuarem próximos após várias tentativas, escolheria o mais barato. Se o custo adicional de revisão anular a poupança de API, porém, deixa de ser o modelo mais barato para o meu fluxo.

O DeepSWE já fez o suficiente para colocar Luna Max na minha lista de testes. Na próxima comparação, manteria as tarefas e as ferramentas constantes e contaria todo o percurso até um patch aceite: orientação, revisão, reparação e execuções falhadas. Se o preço de API mais baixo de Luna sobreviver a esses custos, o modelo é mais barato para o meu trabalho. Caso contrário, o preço da leaderboard não é o preço que eu pago. Fiz esse tipo de comparação no meu próprio trabalho em Claude contra Codex em grandes funcionalidades multiagente.