Claude Opus 4.7 vs GPT-5.5 Spud: o que os benchmarks realmente provam

O que um benchmark prova — e o que não prova

Um benchmark mostra como um modelo se saiu em um conjunto específico de tarefas, com um harness específico — isto é, scripts, prompts, regras de execução, ferramentas permitidas, política de tentativas e método de pontuação. Ele não prova, sozinho, superioridade universal.

Essa diferença é crucial. A literatura de avaliação de LLMs, ou modelos de linguagem de grande porte, alerta que benchmarks estáticos podem sofrer com saturação, contaminação de dados e pouca replicação independente. Esses problemas pesam ainda mais quando um lado da comparação é documentado e o outro ainda não aparece em fonte primária.

Para uma comparação confiável entre Claude Opus 4.7 e GPT-5.5 Spud, o mínimo necessário seria:

1. Uma fonte primária da OpenAI confirmando o Spud.
2. Um identificador de modelo estável.
3. Condições de acesso reprodutíveis para os dois modelos.
4. Configurações de benchmark publicadas, incluindo prompts, ferramentas, tentativas e pontuação.
5. Replicação independente em condições comparáveis.

A evidência fornecida sobre Spud não chega a esse patamar.

Contaminação pode virar o placar de cabeça para baixo

Contaminação e vazamento de benchmark importam porque uma nota alta pode refletir exposição prévia a perguntas, respostas, padrões de solução ou artefatos públicos do teste — e não necessariamente uma capacidade geral mais robusta. Pesquisas recentes sobre benchmarks apontam esse risco, especialmente em conjuntos estáticos ou públicos.

Uma pesquisa posterior sobre benchmarks de LLMs afirma que desenhos dinâmicos, como o LiveBench, podem reduzir risco de vazamento de dados. Isso não transforma nenhum leaderboard em verdade final, mas torna testes frequentemente atualizados e com menor risco de contaminação mais informativos do que benchmarks estáticos antigos ao comparar modelos de fronteira.

LiveBench é um sinal forte, não uma sentença

O LiveBench é um dos sinais públicos mais fortes entre as fontes fornecidas porque foi construído com tarefas de contaminação limitada, perguntas atualizadas com frequência a partir de fontes recentes, geração procedural de questões e pontuação objetiva com respostas verificáveis. O site também reúne leaderboard, detalhes, código, dados e paper, o que torna a avaliação mais inspecionável do que um gráfico isolado de lançamento.

Ainda assim, LiveBench deve ser visto como um bom sinal público, não como uma decisão de compra ou migração por si só. Um benchmark público ajuda a reduzir a lista de candidatos, mas não substitui teste com seus próprios prompts, base de código, limites de latência, custos e tolerância a falhas.

SWE-bench é útil, mas fácil de exagerar

Avaliações no estilo SWE-bench são valiosas para comparar modelos em tarefas de programação e agentes de engenharia de software. Mas o nome sozinho não basta. Variante, harness, acesso a ferramentas, estado dos repositórios, política de novas tentativas e sistema de pontuação podem mudar o resultado.

O SWE-bench Live foi desenhado para reduzir contaminação de pré-treinamento ao restringir as tarefas a issues criadas entre 1º de janeiro de 2024 e 20 de abril de 2025; seus autores também observam que configurações de leaderboards podem diferir bastante. O SWE-bench Pro é apresentado como um benchmark mais difícil e resistente à contaminação para tarefas de engenharia de software de horizonte mais longo.

As ressalvas são importantes. O SWE-Bench++ argumenta que benchmarks de software baseados em repositórios open source enfrentam risco crítico de contaminação e que vazamento de soluções pode distorcer rankings. Uma análise de 2026 dos leaderboards do SWE-bench também relata submissões recentes ao SWE-bench Verified com contaminação de dados.

Há ainda o problema da saturação. Um estudo sobre infraestrutura de benchmarking afirma que resultados no SWE-bench Verified podem cair para 23% no SWE-bench Pro. Separadamente, o SWE-ABS argumenta que o leaderboard do SWE-bench Verified está se aproximando da saturação e pode exibir taxas de sucesso infladas até que as tarefas sejam fortalecidas de forma adversarial.

Uma escada prática de confiança

Use benchmarks públicos como filtros, não como vereditos finais.

Como testar antes de trocar de modelo

Se a sua equipe está comparando Claude Opus 4.7 com qualquer modelo da OpenAI, Google, Anthropic ou modelos abertos, comece pela qualidade da evidência e termine com a sua própria carga de trabalho.

1. Confirme o ID exato do modelo. Para o Claude Opus 4.7, a Anthropic documenta claude-opus-4-7 para uso via Claude API. Para o GPT-5.5 Spud, este conjunto de evidências não traz um identificador primário da OpenAI.
2. Use o mesmo harness para todos os modelos. O SWE-bench Live alerta que configurações de leaderboard podem variar muito; setups diferentes podem criar rankings falsos.
3. Prefira tarefas recentes, privadas ou resistentes à contaminação. Benchmarks dinâmicos e avaliações de engenharia de software resistentes à contaminação foram desenhados para reduzir risco de vazamento.
4. Registre restrições práticas. Anote número de tentativas, latência, custo, permissões de ferramentas, modos de falha e se o modelo resolveu a tarefa de forma limpa ou só depois de tentativas caras.
5. Repita a avaliação. Um resultado isolado de leaderboard deve ser tratado como hipótese até que testes internos ou replicações de terceiros deem suporte à conclusão.

O que mudaria a conclusão

O veredito mudaria se as fontes incluíssem um anúncio primário da OpenAI, model card, system card ou documento de API para o GPT-5.5 Spud; um identificador estável de modelo; acesso reprodutível; e entradas independentes de benchmark com harnesses e permissões de ferramentas comparáveis.

A evidência ficaria ainda mais forte se esses resultados aparecessem em avaliações com contaminação limitada ou resistente, como LiveBench, SWE-bench Live ou SWE-bench Pro, e se equipes independentes conseguissem reproduzi-los.

Limitações importantes

Esta análise se limita às fontes fornecidas. A ausência de uma fonte primária da OpenAI para o GPT-5.5 Spud aqui não prova que tal fonte não exista em outro lugar; significa apenas que a alegação não foi verificada pelas fontes disponíveis neste conjunto.

Além disso, várias fontes metodológicas citadas são registros em arXiv, OpenReview ou SSRN, e não necessariamente artigos finais de periódicos. Elas são úteis para entender desenho de avaliação, risco de contaminação e problemas de replicação, mas seu status de publicação deve ser levado em conta.

Em resumo

O Claude Opus 4.7 está verificado nas fontes fornecidas; o GPT-5.5 Spud não está verificado aqui por documentação primária da OpenAI. Portanto, um vencedor em Claude Opus 4.7 vs GPT-5.5 Spud não deveria ser anunciado até que Spud seja confirmado, acessível por um ID estável e testado em condições comparáveis.

Para escolher modelos, dê mais peso a benchmarks com método inspecionável, menor risco de contaminação e testes repetidos. LiveBench, SWE-bench Live e SWE-bench Pro são mais informativos do que testes estáticos ou gráficos apenas de fornecedor, mas nenhum deles substitui uma avaliação controlada na sua própria carga de trabalho.