1 pontos por GN⁺ 1 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Foram divulgados os resultados de um benchmark que compara a qualidade dos patches de três modelos — GPT-5.5, GPT-5.4 e Opus 4.7 — em 56 tarefas reais de programação extraídas de dois repositórios open source (Zod, graphql-go-tools)
  • O GPT-5.5 registrou o melhor desempenho em todas as métricas: taxa de aprovação nos testes, equivalência com patches humanos e taxa de aprovação em code review (clean pass)
  • O Opus 4.7 gera os menores patches e tem baixo risco de footprint, mas apresenta um padrão recorrente de falha com implementações incompletas por omitir trabalhos complementares
  • Passar nos testes, por si só, não basta para julgar a qualidade de um patch; é necessária uma avaliação em múltiplas camadas, incluindo aceitação pelo revisor
  • Como o ranking do mesmo modelo varia conforme o repositório, executar benchmarks no próprio codebase é essencial para escolher o modelo

Visão geral do benchmark e ambiente de execução

  • Comparação entre os três modelos em 56 tarefas reais de programação no total: 27 no Zod e 29 no graphql-go-tools
  • Cada modelo foi executado com a configuração padrão em seu harness oficial de agente: o Opus 4.7 usou Claude Code, enquanto GPT-5.4 e GPT-5.5 usaram OpenAI Codex CLI
  • O nível de reasoning de todos os modelos foi padronizado em high
  • Foi usado o framework de avaliação Stet para pontuar em múltiplas camadas além da aprovação em testes, incluindo equivalência comportamental, aceitabilidade em code review, risco de footprint e rubricas de craftsmanship e discipline
  • Execução única por tarefa com seed única; o modelo usado para julgar equivalência e rubricas foi o GPT-5.4

Resumo dos resultados gerais

  • O GPT-5.5 ficou em 1º lugar em todas as métricas, com 38/56 testes aprovados, equivalência com patches humanos em 40/56 e 28/56 clean pass
  • O Opus 4.7 teve 33/56 testes aprovados, 19/56 em equivalência e 10/56 em clean pass, ficando com a menor pontuação de qualidade
    • Ainda assim, teve o menor risco médio de footprint, de 0.20, mostrando vantagem em tamanho de patch
  • O GPT-5.4 teve 31/56 testes aprovados, 35/56 em equivalência e 11/56 em clean pass
    • Com custo de $2.39 por tarefa, foi o mais barato, mas isso não compensou a diferença em clean pass
  • O GPT-5.5 também liderou em eficiência, com tempo médio por tarefa de 6 min 56 s, 201.8M tokens de entrada e 0.72M tokens de saída

Análise por repositório

  • Zod (27 tarefas): GPT-5.5 e Opus empataram com 12 testes aprovados, mas o GPT-5.5 ficou à frente em qualidade de revisão, com 10 clean pass contra 5 do Opus
    • O Opus levou vantagem no tamanho do diff, então no Zod existe um trade-off real
  • graphql-go-tools (29 tarefas): o GPT-5.5 dominou, com 26 testes aprovados e 18 clean pass
    • O Opus passou em 21 testes, mas ficou em apenas 5 clean pass, mostrando que a estratégia de patch pequeno levou à omissão de trabalhos de integração

Métricas detalhadas de qualidade

  • Aprovação em code review: GPT-5.5 33/56, GPT-5.4 16/56, Opus 11/56
  • Média em code review (correção + segurança contra bugs): GPT-5.5 3.08, GPT-5.4 2.59, Opus 2.33
    • Apenas correção (correctness): GPT-5.5 3.16 vs GPT-5.4 2.60 vs Opus 2.11
    • Segurança quanto à introdução de bugs: GPT-5.5 3.04 vs GPT-5.4 2.56 vs Opus 2.55
  • Média no avaliador customizado (8 rubricas): GPT-5.5 2.62, GPT-5.4 2.40, Opus 2.33
  • Pontuação de craftsmanship (clarity/coherence/robustness): o GPT-5.5 ficou em 1º em todos os subitens
  • Pontuação de discipline (scope discipline/diff minimality): GPT-5.5 2.36, com leve vantagem sobre o Opus, que ficou em 2.20
    • Embora o Opus vença no footprint bruto, o GPT-5.5 fica à frente em disciplina relativa à tarefa

Passar nos testes não é o critério final

  • No Zod, Opus e GPT-5.5 empataram com 12 testes aprovados, mas em clean pass o GPT-5.5 ficou com 10 contra 5 do Opus
  • No graphql-go-tools, o mesmo padrão aparece com mais força: GPT-5.5 teve 26 testes aprovados / 18 clean pass, e o Opus 21 testes aprovados / 5 clean pass
  • No caso do GraphQL PR #1001, os três modelos passaram nos testes e foram considerados equivalentes, mas apenas o GPT-5.5 passou no code review
    • Os outros dois receberam alertas sobre formato da API, exposição de objetos HTTP brutos e robustez nos limites dos hooks

Diferenças concretas observadas no code review

  • Tarefa de codecs assíncronos e valores padrão no Zod: os três modelos falharam nos testes
    • O Opus modificou 8 arquivos, mas deixou de fora semânticas centrais (permitir undefined em valores padrão e manter síncrona a definição do codec)
    • O GPT-5.4 fez patch em 11 arquivos, foi considerado equivalente, mas restringiu demais APIs adjacentes (prefault)
    • O GPT-5.5 também falhou nos testes, mas cobriu melhor o comportamento de schema/build e recebeu a maior nota em correção e risco de bug
  • Validação de compatibilidade com GraphQL Apollo (PR #1169): os três modelos passaram nos testes, mas só o GPT-5.5 passou tanto em equivalência quanto em review
    • O Opus modificou 11 arquivos, mas deixou passar validações de folhas escalares em enum/wrapping
    • O GPT-5.4 modificou 12 arquivos e expandiu demais o escopo com metadados de validação incondicionais
    • O GPT-5.5 modificou 10 arquivos (6 fora de testes), sendo o menor entre eles, e ainda implementou com precisão o comportamento desejado

Características e limites do Opus 4.7

  • Gera patches conservadores, precisos e com baixo footprint
  • Vai melhor quando a tarefa é localizada e a superfície de mudança é estreita
  • Padrão recorrente de falha: implementa o comportamento central, mas não conclui o trabalho complementar (companion work)
    • No caso da árvore paralela Node/Deno no Zod, o Opus modificou apenas 4 arquivos e passou nos testes, enquanto o GPT-5.5 modificou 11 arquivos incluindo a superfície de distribuição paralela, ficando equivalente ao patch humano
  • No graphql-go-tools isso foi mais grave: no PR #1155 (mudanças em várias superfícies do engine, incluindo campos escalares repetidos em datasource gRPC), o Opus não conseguiu gerar patch algum, enquanto só o GPT-5.5 passou em testes, equivalência e review
  • Distinção central: o patch pequeno do Opus representa disciplina em tarefas locais, mas implementação incompleta em tarefas de integração

Mudanças do GPT-5.4 para o GPT-5.5

  • O GPT-5.4 costuma encontrar a direção correta, mas falha na execução
    • No Zod, teve 18 casos de equivalência (igual ao GPT-5.5), mas apenas 9 aprovações em testes
  • O GPT-5.5 mantém melhor o comportamento amplo de integração e gera menos patches quebrados
  • Comparações concretas:
    • Gerador schema→TypeScript: Opus e GPT-5.5 implementaram um visitor recursivo, enquanto o GPT-5.4 classificou a tarefa errado e acabou gerando um arquivo de orientação do repositório
    • Correção de parser recursivo: os dois modelos GPT usaram abordagem de rastreamento de número de visitas, mas o GPT-5.5 foi mais conciso ao eliminar estado desnecessário
    • Validação de CIDR: o GPT-5.5 atualizou também o mirror em Deno, enquanto o GPT-5.4 não refletiu isso no mirror, gerando problema de higiene do repositório
  • No PR #1232 do graphql-go-tools (deduplicação de single fetch idêntico + reescrita de referências de dependência), só o GPT-5.5 passou em testes, equivalência e review
  • Padrão resumido: o GPT-5.5 faz mais do trabalho chato de integração que converte correções locais inteligentes em mudanças prontas para deploy no repositório

Trade-off entre tamanho de patch e custo

  • Tamanho médio de patch no graphql-go-tools: GPT-5.5 cerca de 33KB, GPT-5.4 com 27KB e Opus com 19KB
  • Pontuação de footprint: Opus 0.19, GPT-5.4 0.32, GPT-5.5 0.34
  • Patches grandes aumentam a dificuldade de review, a chance de conflito e o risco de tocar caminhos sensíveis
    • Em workflows focados em auditabilidade, o Opus ainda tem vantagem prática
  • Porém, quando a diff minimality é avaliada de forma relativa à tarefa, o GPT-5.5 fica ligeiramente à frente
    • Ponto central: um patch de 5KB que deixa de fora a superfície necessária não é mais minimalista do que um patch de 20KB que completa a tarefa
  • Comparação de custo:
    • No Zod, Opus e GPT-5.5 foram parecidos (Opus $45.53 vs GPT-5.5 $46.69)
    • No graphql-go-tools, o Opus consumiu 186.1M tokens de entrada / 934K de saída / 8.56h de agente, enquanto o GPT-5.5 usou 151.4M / 431K / 4.16h, sendo muito mais eficiente

Resumo do comportamento de cada modelo

  • Opus 4.7 — under-reach: conservador, preciso e de baixo footprint; forte em tarefas locais, mas fraco em superfícies complementares que os testes não cobrem totalmente; seu modo de falha é “passou nos testes, mas não é a mesma mudança”
  • GPT-5.4 — forma correta, execução errada: a direção costuma ser boa, mas a execução é inconsistente; há muitos casos de mirrors desatualizados, refatorações desnecessárias e patches melhor avaliados pelo julgador do que pelos testes
  • GPT-5.5 — mais amplo, com footprint maior: mais completo em superfícies de integração, com maior taxa de atualização de código periférico, aprovação em review e conversão da intenção em código real; o risco, quando erra, é espalhar o erro por mais arquivos

Diferenças no comportamento dos agentes

  • No graphql-go-tools, o Opus fez em média 3.17 chamadas explícitas de planejamento por tarefa, enquanto o GPT-5.5 fez 0
  • O Opus fez 10.2 chamadas de patch por tarefa, contra 9.9 do GPT-5.5, números parecidos
  • O GPT-5.5 executou cerca de 2x mais chamadas de shell e também mais chamadas de busca, enquanto o Opus gastou mais orçamento em planejamento e reescrita de patches
  • Nesse repositório, uma exploração mais ampla do repositório foi mais eficaz do que refletir mais sobre patches estreitos

Por que esse resultado importa

  • A pergunta principal não é “qual modelo é o melhor?”, e sim “em qual modelo posso confiar, neste repositório, neste harness e para o tipo de trabalho que realmente vai para produção?
  • No Zod, GPT-5.5 e Opus ficam em relação de trade-off; no graphql-go-tools, o GPT-5.5 tem vantagem clara
  • Benchmarks públicos tendem a achatar o comportamento dos modelos em um único número agregado, mas no código real isso vira uma decisão de workflow baseada no codebase e nos critérios específicos

Observações

  • As 56 tarefas ainda são uma amostra pequena; a diferença de uma única tarefa pode alterar em vários pontos os percentuais no nível do repositório
  • Todos os modelos foram executados uma vez por tarefa, então alguns resultados apertados podem se inverter em nova execução
  • Como o modelo julgador de equivalência e rubricas foi o GPT-5.4, existe possibilidade de viés de família
    • Ainda assim, o GPT-5.5 superou de forma decisiva o GPT-5.4, a vantagem de footprint do Opus se manteve, e muitas das falhas de equivalência do Opus são omissões concretas de arquivos, então isso não explica sozinho o resultado geral
  • Os resultados são condicionados ao harness: Claude Code e Codex CLI têm prompts de sistema, loops de planejamento e superfícies de ferramenta diferentes
    • Rodar o Opus na Codex API, ou o GPT-5.5 no Claude Code, pode mudar os resultados
    • Estes números refletem o comportamento dos modelos dentro dos harnesses realmente usados por engenheiros

Conclusão principal

  • O GPT-5.5 é o melhor modelo padrão para deploy nesses dois repositórios
  • O Opus 4.7 continua sendo um modelo de baixo footprint, preferível quando diff estreita é o fator mais importante
  • O GPT-5.4 tem o menor custo por tarefa, mas isso não basta para compensar a diferença em clean pass
  • Olhar apenas para os testes esconde os resultados mais importantes
  • O ranking do mesmo modelo varia entre repositórios, e esse é justamente o motivo central para fazer benchmark no próprio repositório

1 comentários

 
shakespeares 34 초 전

Às vezes até parece que estão combinando entre si.