GPT-5.5 low vs medium vs high vs xhigh: a curva de raciocínio vista em 26 tarefas reais de um repositório open source

 (reddit.com)
5 pontos por GN⁺ 8 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Ao executar o GPT-5.5 Codex em 26 tarefas reais do GraphQL-go-tools com as configurações low, medium, high, xhigh, a diferença no esforço de raciocínio apareceu mais claramente na equivalência semântica com patches humanos e na taxa de aprovação em code review do que apenas na aprovação em testes
  • A aprovação em testes foi de 21/26 em low, 21/26 em medium, 25/26 em high e 24/26 em xhigh, mas a equivalência semântica subiu de 4/26 → 11/26 → 18/26 → 23/26, e a aprovação em code review também aumentou de 3/26 → 5/26 → 10/26 → 18/26
  • O high melhorou aprovação em testes, equivalência e aprovação em review em relação ao medium, enquanto o custo médio subiu de $3.13 para $4.49, um aumento de 1.43x, parecendo a configuração padrão mais prática neste dataset
  • O xhigh elevou bastante a equivalência e a qualidade de review em relação ao high, mas o custo médio foi para $9.77 e o tempo médio de execução para 753.3 segundos, além de gerar mais mudanças em testes, fixtures e expected outputs, aumentando também o risco de footprint
  • O efeito do esforço de raciocínio não foi monotônico por tarefa: em alguns casos o high superou o xhigh, e configurações mais altas às vezes produziram implementações plausíveis, porém incorretas; por isso, equipes devem medir isso em seu próprio harness e suas próprias tarefas, e não apenas em benchmarks globais

Objetivo do experimento e método de avaliação

  • O GPT-5.5 Codex foi executado nas mesmas 26 tarefas de um repositório open source com as configurações de esforço de raciocínio low, medium, high, xhigh, para comparar não só a aprovação em testes, mas também a equivalência semântica com PRs mesclados por humanos e a possibilidade de aprovação em review
  • O repositório avaliado foi o GraphQL-go-tools, baseado em Go, e cada tarefa foi derivada de um PR ou commit real já mesclado
  • Cada tarefa consistiu em um snapshot fixo do repositório, um prompt de solicitação de mudança e uma única tentativa de gerar um patch dentro de um contêiner Docker
  • O Stet aplicou o patch gerado e executou os testes específicos de cada tarefa em um contêiner isolado para verificar se passavam
  • Depois dos testes, houve avaliação adicional com os seguintes critérios
    • Equivalência: se o patch candidato alcançou a mesma mudança de comportamento que o patch original feito por um humano
    • Aprovação em code review: se um reviewer provavelmente aceitaria o patch considerando correção, risco de introdução de bugs, manutenibilidade e edge cases
    • Risco de footprint: quanto código extra o agente modificou em comparação com o patch humano
    • Rubrica de construção/disciplina: avaliação de clareza, simplicidade, consistência, intencionalidade, robustez, seguimento de instruções, disciplina de escopo e minimização do diff
  • Todos os modelos foram executados uma vez por tarefa, com seed única
  • O modelo de julgamento LLM foi o GPT-5.4, e o avaliador viu apenas o patch e a tarefa, sem saber qual modelo ou configuração de raciocínio gerou o patch
  • Exemplos representativos também foram verificados manualmente, mas como não houve calibração humana separada para esse conjunto de tarefas, deve-se confiar mais na direção das variações do que em qualquer pontuação absoluta isolada
  • Detalhes de execução
    • Modelo: GPT-5.5
    • Harness: Codex 0.128.0
    • Dataset: 26 tarefas reais do GraphQL-go-tools
    • Principais métricas: aprovação em testes, equivalência semântica, aprovação em code review, risco de footprint, avaliação customizada de construção/disciplina, custo e tempo de execução
  • Há gráficos interativos e análise detalhada por tarefa em https://stet.sh/blog/gpt-55-codex-graphql-reasoning-curve
  • A mesma avaliação também foi usada em um loop de pesquisa automatizado para melhorar o AGENTS.md
    • O agente cria propostas de melhoria para o AGENTS.md do repositório, executa tarefas históricas com o Stet e depois itera identificando onde houve melhora ou piora

Métricas gerais e interpretação

  • As métricas gerais mostram que, à medida que o esforço de raciocínio aumenta, a diferença aparece mais em equivalência semântica e taxa de aprovação em review do que em aprovação em testes
  • Resultados principais
    • Aprovação em testes: low 21/26, medium 21/26, high 25/26, xhigh 24/26
    • Equivalência com o patch humano: low 4/26, medium 11/26, high 18/26, xhigh 23/26
    • Aprovação em code review: low 3/26, medium 5/26, high 10/26, xhigh 18/26
    • Média de construção/disciplina: low 2.311, medium 2.604, high 2.736, xhigh 3.071
    • Custo médio por tarefa: low $2.65, medium $3.13, high $4.49, xhigh $9.77
    • Tempo médio de execução do agente: low 286.9 segundos, medium 411.0 segundos, high 579.0 segundos, xhigh 753.3 segundos
  • Low e medium tiveram a mesma aprovação em testes, 21/26, mas a equivalência subiu de 4/26 para 11/26, e a aprovação em review foi de 3/26 para 5/26
  • Em relação ao medium, o high aumentou a aprovação em testes em +15.4 p.p., a equivalência em +26.9 p.p. e a aprovação em review em +19.2 p.p., mostrando a melhora prática mais nítida
  • Em relação ao high, o xhigh teve -3.8 p.p. em aprovação em testes, mas ganhou +19.2 p.p. em equivalência e +30.8 p.p. em aprovação em review
  • O esforço de raciocínio não alterou apenas a taxa de aprovação em testes; ele também mudou o tipo de patch que o Codex produziu
  • Benchmarks públicos muitas vezes respondem apenas se a tarefa foi concluída ou não, de forma binária, mas em engenharia de software real também importa se o patch pode ser mesclado e mantido depois
  • O Terminal-Bench é focado principalmente em problemas de programação mais obscuros, o SWE-bench verified pode incluir casos em que o modelo já tinha a resposta, e o SWE-bench Pro é útil, mas tem caráter mais genérico
  • O foco deste experimento está em saber se “o agente fez, na minha codebase, o mesmo tipo de mudança que um humano mesclou” e se “eu gostaria de assumir a posse desse patch depois”

De low para medium: da heurística para a modelagem do domínio

  • Low e medium tiveram ambos 21/26 em aprovação em testes, então olhando apenas os testes eles parecem empatados
  • Mas o medium elevou a equivalência semântica de 4/26 para 11/26, e a média de construção/disciplina de 2.311 para 2.604
  • Nesse intervalo, medir só os testes faz perder a maior parte da diferença no esforço de raciocínio
  • O low, mesmo em patches aprovados, às vezes ficava em heurísticas ou implementações parciais, enquanto o medium passava a modelar melhor o repositório e a semântica do domínio
  • Exemplo do PR #1297
    • Trata-se de uma tarefa de validação de dependências nullable external @requires no GraphQL Federation
    • Quando um campo required nullable retorna null junto com erro, essa entidade contaminada não deve ser repassada para o fetch downstream dependente
    • A essência da tarefa não está em apenas adicionar um branch de validação, mas em modelar uma regra sutil de dependência de dados em federation
    • O low passou nos testes, mas tratou o matching de required-field/error de forma heurística, ignorou metadados estruturados de nullable @requires, não foi equivalente e também não passou em review
    • O medium rastreou objetos contaminados e filtrou as entradas de fetch downstream, passando em equivalência e review, enquanto a qualidade de construção/disciplina subiu de 1.350 para 3.225
    • Como high e xhigh permaneceram na mesma faixa de qualidade, essa tarefa mostra principalmente a melhora ao passar de low para medium

high: um ponto próximo de um padrão prático

  • o high melhora em relação ao medium em testes aprovados, equivalência semântica e aprovação em revisão, enquanto o aumento de custo permanece alto, mas não excessivo
  • comparação entre high e medium
    • testes aprovados: de 21/26 para 25/26
    • equivalência: de 11/26 para 18/26
    • aprovação em revisão de código: de 5/26 para 10/26
    • risco médio de footprint: de 0.268 para 0.314
    • média de craftsmanship/disciplina: de 2.604 para 2.736
    • custo médio por tarefa: de $3.13 para $4.49, 1.43x
    • tempo médio de execução: de 411.0s para 579.0s
  • o high parece ser o ponto em que tokens adicionais se convertem em ganhos reais, com maior taxa de acerto nos detalhes de integração
  • exemplo do PR #1209
    • trata-se de uma tarefa em que o datasource gRPC precisa respeitar aliases GraphQL no JSON de resposta, validar previamente tipos de mensagem protobuf referenciados e atualizar a cobertura de mapeamento do caminho de mutation de union/interface
    • low e medium passaram nos testes, mas não foram equivalentes e também falharam na revisão
    • o medium tratou boa parte da serialização de alias e da validação de mensagens ausentes, mas deixou passar a atualização do mapeamento da mutation createUser e atribuiu peso excessivo à semântica de response-key em JSONPath
    • o high introduziu tratamento explícito de response-key/alias e propagou aliases por todo o planejamento e o JSON marshaling, tornando-se a primeira aprovação estrita
    • a qualidade customizada do high subiu para 3.625, e ele não apenas adicionou mais código, mas acertou com precisão as obrigações de integração
    • o xhigh também passou, mas não melhorou a interpretação no nível da tarefa, e o tempo de execução do agente segundo o critério de resumo regenerado foi de 790.7s, maior que os 314.0s do high
  • exemplo do PR #1155
    • trata-se de um trabalho de hardening do datasource gRPC, incluindo suporte a repeated scalar field, prevenção de panic com mensagens null/inválidas, propagação de código de status gRPC, desativação do datasource e suporte a dynamic client
    • low e medium passaram nos testes, mas não foram equivalentes
    • o medium melhorou a robustez, mas serializou repeated fields inválidos como empty array, deixou passar o comportamento de planejamento de aliased-root e manteve risco no ciclo de vida do dynamic client
    • o high passou em equivalência e revisão com tratamento mais seguro de nil/inválido, propagação de status-code, comportamento de disabled-datasource e cobertura do dynamic client-provider
    • nesta tarefa, houve uma inversão em que o xhigh passou nos testes, mas tratou incorretamente a semântica de disabled datasource e o comportamento de invalid-list, não sendo equivalente e falhando também na revisão

xhigh: mais próximo de um modo de qualidade do que de um padrão

  • o xhigh elevou a qualidade semântica e de revisão em relação ao high, mas não é um caso em que simplesmente aumentar a configuração melhora tudo
  • comparação entre xhigh e high
    • testes aprovados: queda de 25/26 para 24/26
    • equivalência: de 18/26 para 23/26
    • aprovação em revisão de código: de 10/26 para 18/26
    • risco médio de footprint: de 0.314 para 0.365
    • média de craftsmanship/disciplina: de 2.736 para 3.071
    • custo médio por tarefa: de $4.49 para $9.77, 2.18x
    • tempo médio de execução: de 579.0s para 753.3s
  • o xhigh tende a cobrir mais base, alinhar-se melhor à intenção humana e produzir mudanças mais completas, mas usa muito mais tokens
  • a rubrica de revisão teve média 3.365 e mediana 3.500 no xhigh, acima da média 2.817 e da mediana 2.750 do high
  • a mediana também é maior que a média, o que sugere que a melhora do xhigh não parece ser resultado de apenas um ou dois patches excelentes puxando a média para cima
  • o xhigh é semanticamente mais completo, mas também aumenta o risco de footprint por tocar em mais código em comparação com patches feitos por humanos
  • nas 26 tarefas, o xhigh adicionou ao todo 13,144 linhas, divididas em 5,918 linhas de código de implementação e 7,226 linhas de testes, fixtures e expected-output
  • em comparação com o high, o xhigh adicionou 2,631 linhas a mais, das quais 2,436 estão em arquivos de testes, fixtures e expected-output
  • o aumento de footprint não ocorre apenas porque ele escreve um enorme volume de production code; parte importante vem também do fato de o xhigh criar mais validações e cobertura de fixtures
  • mas mudanças em testes, fixtures e expected-output também são uma superfície real que precisa ser revisada e mantida
  • exemplo do PR #1076
    • trata-se de uma tarefa de reestruturar o processamento de subscriptions para evitar uma race condition em mutex compartilhado
    • os requisitos incluíam escrita serializada por subscription, controle de heartbeat por subscription, cobertura com race detector e correção da semântica de fechamento do WebSocket
    • o medium passou nos testes, mas não foi equivalente e falhou na revisão
    • o high alcançou equivalência e conformidade com as instruções, mas falhou na revisão porque a nova worker queue podia bloquear o event loop global de subscriptions, o shutdown podia parar atrás de um worker travado, uma atualização bloqueada podia ficar sem limite, e o unsubscribe em nível de cliente ainda ignorava a subscription interna
    • o xhigh foi a primeira aprovação estrita e elevou a qualidade customizada para 3.475
    • esta tarefa é o melhor exemplo de como o xhigh funcionou como um modo de qualidade que compra limpeza de risco de revisão em tarefas pesadas em concorrência
  • exemplo do PR #1308
    • trata-se da implementação do input object GraphQL @oneOf
    • era necessário adicionar a directive embutida, expô-la na introspection, validar operation literal e runtime variable, e melhorar a source location de undefined-variable
    • medium e high passaram nos testes, mas deixaram passar semânticas importantes de @oneOf relacionadas a runtime variable, nullable variable, payload com null fornecido e shape de introspection, não sendo equivalentes e falhando também na revisão
    • o xhigh foi a primeira aprovação estrita e registrou robustez 3.7, conformidade com instruções 4.0 e qualidade customizada 3.525
    • a diferença não está em um polimento superficial, mas na cobertura de edge cases espalhados por várias partes do sistema
  • exemplo do PR #1240
    • trata-se de integrar o field-selection merging da AST GraphQL e o inline-fragment selection merging em um único normalization walk
    • low e high obtiveram aprovação estrita
    • o xhigh foi equivalente pelo critério de avaliação semântica, mas falhou na revisão por manter o prioritized subpass, alterar a ordem de AbstractFieldNormalizer e deixar um registro antigo de field-merge
    • mesmo uma configuração de raciocínio mais alta pode produzir refatorações mais sofisticadas e plausíveis, mas ainda deixar passar o comportamento exato de execução que testes e revisores consideram importante

Produção·disciplina, custo, limitações e conclusão

  • A avaliação customizada de produção·disciplina também sobe de forma geral à medida que o esforço de raciocínio aumenta, de forma semelhante à rubrica de review
  • A pontuação all-custom foi maior em xhigh, com média 3.071 e mediana 3.087, do que em high, com média 2.736 e mediana 2.688
  • Como as medianas de produção e disciplina também são mais altas, é possível interpretar que xhigh não apenas gerou alguns exemplos excepcionais, mas elevou a qualidade geral dos patches
  • Métricas de média/mediana
    • Craft aggregate: low 2.327 / 2.338, medium 2.618 / 2.525, high 2.781 / 2.787, xhigh 3.126 / 3.100
    • Discipline aggregate: low 2.295 / 2.325, medium 2.590 / 2.588, high 2.691 / 2.688, xhigh 3.015 / 3.013
    • All custom graders: low 2.311 / 2.338, medium 2.604 / 2.550, high 2.736 / 2.688, xhigh 3.071 / 3.087
  • Interpretação detalhada
    • low tem fragilidade em robustez e aderência às instruções
    • medium melhora esses pontos de forma significativa sem aumentar o total de testes aprovados
    • high melhora a precisão prática e a robustez
    • xhigh melhora quase todas as dimensões, incluindo escopo e disciplina de diff
  • Custo e tempo
    • low: custo médio de $2.65, mediana de $1.91, tempo médio de execução 286.9s, mediana 294.6s
    • medium: custo médio de $3.13, mediana de $2.87, tempo médio de execução 411.0s, mediana 371.8s
    • high: custo médio de $4.49, mediana de $3.99, tempo médio de execução 579.0s, mediana 572.9s
    • xhigh: custo médio de $9.77, mediana de $6.39, tempo médio de execução 753.3s, mediana 732.7s
  • O custo é enviesado em low e especialmente em xhigh, e o custo médio de xhigh é afetado por algumas tarefas caras
  • Mesmo pela mediana, xhigh é mais caro e mais lento que high
  • high custa cerca de 1,43x por tarefa em relação a medium, e xhigh custa cerca de 2,18x em relação a high
  • Limitações
    • foi usado apenas um seed por tarefa
    • inclui apenas 26 tarefas reais de GraphQL-go-tools
    • o julgador LLM era o GPT-5.4 e via os patches e as tarefas, mas não via os labels
    • não houve calibration do grader para esse conjunto de tarefas
    • não se pode considerar isso um resultado universal estatisticamente significativo nem um resultado transferível diretamente para outros repositórios
  • Comparações relacionadas
    • O leaderboard de tarefas reais da Voratiq também aponta em direção semelhante, embora com outra metodologia
    • Na Voratiq, GPT-5.5 xhigh marcou 1994 e GPT-5.5 high 1807, um aumento de +187 pontos, ou +10.3%
    • O custo foi de $4.23 contra $2.52, ou +67.9%, e o tempo foi de 11.9m contra 7.8m, ou +52.6%
    • No experimento do Stet, high → xhigh apareceu maior, com equivalência de +19.2%p, relativo de +27.8%, aprovação em code review de +30.8%p, relativo de +80.0%, enquanto o aggregate de produção/disciplinа foi semelhante em +12.2%
    • A Voratiq é um leaderboard em estilo preferência/seleção para trabalho em andamento, e este experimento é um recorte de um único repositório com 26 tarefas, então não é possível compará-los diretamente
  • Conclusão prática
    • xhigh é adequado para tarefas ambíguas, que atravessam várias áreas, são centradas em concorrência ou têm alto risco de review
    • high parece ser a configuração mais prática como padrão diário neste dataset
    • configurações medium ou inferiores são adequadas quando o custo é mais importante e a tarefa é rotineira ou bem definida
    • o efeito do esforço de raciocínio varia por tarefa e não é suave nem monotônico; há casos em que high vence xhigh, ou em que uma configuração mais alta produz uma implementação plausível, porém errada
    • em vez de copiar valores padrão de benchmarks globais, as equipes devem medir em seu próprio harness e em suas próprias tarefas
  • Divulgação
    • Eles estão criando o Stet.sh e executaram os experimentos com essa ferramenta de avaliação local
    • Na versão do produto, o agente de codificação cria mudanças candidatas, como melhorias em AGENTS.md, e as avalia com o Stet em tarefas históricas do repositório
    • Se uma equipe que usa muito agentes de codificação estiver diante de decisões concretas, como high vs xhigh, Codex vs Claude Code, atualizações de AGENTS.md ou decidir quais tarefas são seguras para delegar, eles estão procurando equipes para rodar testes por repositório em conjunto
    • O Stet roda totalmente em ambiente local usando assinaturas de LLM, e a lista de espera está em https://www.stet.sh/private

Leituras relacionadas

1 comentários

 
GN⁺ 8 시간 전
Opiniões do Hacker News
  • Gostei dessa comparação e também queria ver uma comparação com o 5.4
    Pela minha impressão até agora, o 5.5 não vale o custo extra. O 5.4-high se sai melhor do que a maioria dos níveis de raciocínio do 5.5, custa metade e leva muito menos tempo na prática. O 5.5-medium não conseguiu concluir as tarefas até o fim, e o 5.5-high exagerou na engenharia e criou bugs e regressões
  • Para a maioria dos trabalhos sérios, high parece ser o ponto ideal
    Acima disso, a melhora fica próxima de retornos decrescentes em relação ao custo
  • Na conta Pro, estou usando o 5.5 xHigh Codex Terminal CLI como lead principal e o Codex Desktop App 5.5 xhigh como lead secundário
    Dou a ambos acesso total perigoso e eles trabalham no mesmo projeto. Cada um recebe em média 6 subagentes do 5.5, e o CLI ou o app decide qual nível de subagente usar. Vem misturado, mas o CLI geralmente usa 5.5 Medium
    O CLI tem privilégios de administrador e só ele cuida de GitHub, Supabase, Vercel, Clerk, Linear, Symphony, além de push, merge, PR e deploy. Eu não faço nada diretamente, e também tenho 0 issues P0/P1/P2. GitHub, Vercel e Supabase estão todos verdes, sem issues, com código e produto limpos, e o frontend sai surpreendente usando apenas uma imagem de referência
    A desvantagem é que isso pode queimar 30% do limite semanal em um dia
    • Vi esse experimento e testei xhigh em algumas tarefas; é bem eficaz, mas consome tokens como um louco
      Agora voltei para high
  • Minha maior reclamação sobre o 5.5 xhigh é que ele simplesmente toca o trabalho sozinho sem nem perguntar
    Ainda assim, sinto que economizei alguns anos de vida e uma boa quantidade de tokens
    • Eu uso principalmente high, e ele faz a mesma coisa
      Ainda estou tentando descobrir que frase colocar no agents.md para ele não sair assumindo coisas por conta própria. Às vezes faço uma pergunta porque preciso saber mais antes de dar instruções de programação sobre algo, e em vez de responder ele já começa a programar. No fim, ele até inclui na resposta a resposta para a pergunta, então parece que prestou atenção no que eu disse, mas não entendeu que, se havia uma pergunta, isso significava que ele ainda não devia programar
  • Fico curioso se você executou várias vezes no mesmo PR
    Queria saber qual é o nível de variabilidade entre execuções do modelo. Mesmo que high tenha programado melhor no caso acima, se a variabilidade entre execuções for grande, talvez ainda valha mais usar xhigh
    Outro experimento interessante seria dar feedback sobre o resultado após a execução e pedir que ele atualize AGENTS.md, skills, rules etc. comparando com o que foi corrigido por humanos, e então rodar de novo high/xhigh em uma fresh session. Depois de algumas iterações de melhoria, seria bom repetir o experimento em todos os níveis de esforço; se AGENTS.md e skills/rules forem bem ajustados, talvez dê para elevar a qualidade geral da saída
    • Não executei cada variante várias vezes. O principal motivo foi custo e limite de tokens. Minha carteira não é infinita, mas é uma boa ideia para pesquisa futura
      A otimização de AGENTS.md me agrada muito e, na verdade, já fiz o Stet, que criei para rodar experimentos, fazer isso. Eu coloco o Codex para trabalhar em algumas tarefas, observo as pontuações e os padrões de falha, peço para ele modificar o AGENTS.md e depois executo de novo, tudo de forma totalmente autônoma. Funciona como uma pesquisa automatizada para AGENTS.md, e é bem interessante ver melhorias orientadas por dados sendo incorporadas de volta ao AGENTS.md
  • Agora também precisamos de um índice CPI para inflação de preços. Parece que o CPI mensal está quase em 100%