Avaliações do Claude Opus 4.5: o que os testes comparam e até onde permitem chegar a conclusões

Uma pontuação só faz sentido quando acompanhada do protocolo

As avaliações de modelos de linguagem não medem uma única capacidade. Um teste pode examinar a resolução de tarefas de programação por um agente com ferramentas; outro, o desempenho em uma suíte interna; um terceiro, as respostas a perguntas de conhecimento. Mesmo que todos publiquem um número ou uma posição, isso não significa que meçam a mesma coisa ou que permitam ordenar os modelos de forma intercambiável. Para interpretar uma pontuação, são necessários, no mínimo, a tarefa, o conjunto avaliado, a métrica e as condições de execução.

No caso do Claude Opus 4.5, as fontes fornecidas identificam vários tipos de material: uma comunicação da Anthropic que menciona testes com o Junie, o agente de programação da empresa; o System Card do modelo; um trabalho independente sobre modelos como agentes de IDE; e uma ficha agregadora de benchmarks. Também foi proposta a análise de um estudo da Artificial Analysis, mas não há, entre as fontes verificadas fornecidas, uma página dessa organização. Portanto, não é possível documentar aqui o método nem a posição atribuída ao modelo nessa análise.

As evidências disponíveis permitem descrever o escopo geral de alguns documentos e indicar quais informações precisariam ser conferidas nas versões completas. Não bastam, porém, para reconstruir protocolos completos, verificar cada resultado ou estabelecer uma classificação geral. Essa distinção não é um juízo sobre a qualidade do modelo: é um limite do que se pode sustentar com os materiais disponíveis.

O que as fontes localizadas acrescentam

A página oficial da Anthropic sobre o Claude Opus 4.5 é uma fonte do próprio fornecedor. O trecho disponível afirma que, segundo testes com o Junie, seu agente de programação, o Opus 4.5 supera o Sonnet 4.5 nos benchmarks mencionados naquela comunicação e precisa de menos etapas para resolver tarefas. No entanto, o material fornecido não enumera esses benchmarks nem detalha as tarefas, o número de execuções, as ferramentas ativas ou o critério exato para definir “menos etapas”. Por isso, a afirmação deve ser apresentada como uma declaração da Anthropic, não como uma comparação independente cujo protocolo tenha sido reconstruído.

A nota de verificação da mesma página acrescenta uma referência ao GitHub Copilot, enquanto o trecho citado menciona o Junie. Os dados fornecidos não permitem determinar se isso se refere a trechos diferentes da página, a uma descrição imprecisa ou a uma divergência no registro. Convém consultar a página completa antes de descrever com precisão o ambiente utilizado. Não se deve resolver essa ambiguidade presumindo que Junie e GitHub Copilot fizeram parte do mesmo experimento.

O System Card da Anthropic é um documento institucional original. As informações fornecidas indicam que ele compara o Opus 4.5 com outros modelos em uma suíte de tarefas, mas não incluem os nomes dos testes, as métricas nem as condições específicas. A existência de uma comparação no documento não basta para afirmar que todas as tarefas representam programação ou uso de agentes: essa caracterização depende da consulta ao conteúdo completo.

O trabalho localizado no arXiv trata da avaliação de modelos como agentes de IDE em ambientes reais e, segundo a nota disponível, menciona variabilidade no caso do Opus 4.5. O resumo fornecido não identifica as tarefas específicas, o conjunto de modelos, o harness, o número de execuções nem o cálculo dessa variabilidade. Em particular, não permite verificar o valor de desvio padrão de 0,027 mencionado nas perguntas de revisão, nem saber a que métrica ou conjunto de resultados ele se aplicaria.

Por fim, o BenchLM apresenta uma ficha agregada que atribui ao Opus 4.5 uma posição e uma pontuação geral, calculadas a partir de linhas de resultados exibidas pela própria ficha. Trata-se de uma fonte secundária de agregação, não de uma descrição primária dos protocolos originais. Sem saber como as linhas são selecionadas, normalizadas e combinadas, essa pontuação não deve ser tratada como uma medida universal de capacidade.

Testes com o Junie: uma afirmação do fornecedor, não um protocolo completo

O trecho da Anthropic ajuda a identificar uma afirmação concreta: em testes realizados com o Junie, o Opus 4.5 teria superado o Sonnet 4.5 nos benchmarks mencionados e precisado de menos etapas para resolver tarefas. A formulação é da Anthropic e deve ser atribuída à empresa. Com o material fornecido, não é possível confirmar os conjuntos de avaliação, o tamanho da amostra nem se cada modelo recebeu o mesmo contexto, as mesmas ferramentas e o mesmo orçamento.

“Menos etapas” também não equivale, por si só, a melhor desempenho geral. Para interpretar essa medida, seria necessário saber o que conta como etapa, se tentativas malsucedidas ou o uso de ferramentas são penalizados, se as tarefas precisam ser concluídas corretamente e como uma solução parcial é tratada. Um número menor de interações poderia ser relevante em determinado ambiente, mas não informa automaticamente sobre custo, latência, confiabilidade ou qualidade do código.

A página sobre o Opus 4.5 também aparece associada nas notas ao GitHub Copilot. Como não foi fornecido o texto completo que explica essa referência, não é possível determinar se ela descreve outro contexto de avaliação, uma integração ou uma tarefa diferente. Uma auditoria rigorosa manteria as duas menções separadas até que suas condições fossem consultadas, em vez de reuni-las em um único experimento.

System Card: um documento pertinente, mas com detalhes ainda não verificados

O System Card do Claude Opus 4.5 é uma fonte primária do fornecedor e, portanto, é o lugar apropriado para conferir quais avaliações a Anthropic decidiu publicar e como as apresenta. A nota de verificação disponível apenas confirma que o documento compara o Opus 4.5 com outros modelos em uma suíte de tarefas. Ela não fornece os nomes das tarefas nem permite reconstruir os resultados por categoria.

Para interpretar essa suíte, seria necessário examinar cada teste e verificar qual capacidade pretende medir, quais modelos são comparados e que métrica é utilizada. Também seria preciso determinar se os modelos receberam o mesmo formato de instruções, as mesmas ferramentas e o mesmo orçamento. Se o System Card informar resultados de tarefas distintas, não convém resumi-los como se constituíssem uma única medida de “inteligência” ou de desempenho em programação.

A documentação da plataforma da Anthropic identifica uma página de descrição do Opus 4.5 que pode ajudar a verificar informações sobre identificadores e limites do modelo. No entanto, a nota fornecida não inclui o identificador exato, os limites específicos nem uma relação entre essa documentação e as execuções de cada benchmark. Portanto, não se pode afirmar que os testes citados usaram determinada configuração antes de consultar os documentos completos e verificar a correspondência entre versão e teste.

Avaliação independente de agentes de IDE: o que falta para interpretar a variabilidade

O artigo localizado no arXiv oferece uma perspectiva diferente das comunicações do fornecedor: estuda modelos como agentes de IDE em ambientes reais. A nota de verificação indica que aborda a variabilidade dos resultados do Opus 4.5. Essa diferença de procedência é relevante, mas não basta para avaliar a independência metodológica nem para comparar seus números com os da Anthropic. Para isso, é necessário examinar o método completo, os dados e o procedimento de avaliação.

A variabilidade só pode ser interpretada quando se sabe qual resultado é repetido e sob quais condições. Um desvio padrão pode descrever diferenças entre execuções, tarefas, instâncias ou alguma outra unidade; cada escolha altera seu significado. O material disponível não confirma o que representa o valor 0,027 mencionado nas perguntas de verificação, quantas execuções o sustentam nem se ele é calculado sobre uma métrica de sucesso, uma pontuação ou outra variável. Portanto, esse valor não deve ser apresentado como um resultado verificado.

Também é necessário distinguir a variação entre execuções do modelo da variação entre tarefas. Um agente pode obter resultados semelhantes em repetições de uma mesma tarefa e, ao mesmo tempo, apresentar desempenho muito desigual entre tarefas diferentes. Para separar esses fenômenos, são necessários, no mínimo, o número de tarefas e de repetições, a unidade estatística, a definição da métrica e o método de agregação dos resultados.

O rótulo “ambientes reais” também não especifica, por si só, quais condições foram reproduzidas. Para saber o que o teste cobre, seria preciso verificar os repositórios ou projetos, as instruções, o acesso ao terminal e às ferramentas, os limites de tempo ou de interação e a forma de avaliar se uma alteração resolve o problema. As notas fornecidas não detalham esses elementos, portanto a avaliação não pode ser usada aqui para afirmar que representa o uso cotidiano de todas as equipes de desenvolvimento.

Artificial Analysis e agregadores: uma posição não substitui a metodologia

A proposta editorial sugere verificar o Omniscience Index da Artificial Analysis e a posição atribuída ao Opus 4.5. No entanto, a lista de fontes verificadas não inclui uma página da Artificial Analysis. Por esse motivo, não é possível afirmar o que esse índice mede, qual é seu método, que resultado atribui ao modelo ou em que configuração ele teria sido obtido. A questão deve permanecer em aberto até que a fonte correspondente esteja disponível e seja examinada.

A ficha do BenchLM está entre os materiais localizados. Sua nota informa uma posição, uma pontuação geral e um conjunto de linhas que a página apresenta como resultados de benchmarks. Esses dados descrevem o que o agregador publica; por si só, não validam a seleção dos testes nem a operação de combinar resultados diferentes. Para interpretar uma posição, seriam necessárias as regras de normalização, ponderação, inclusão de fontes e atualização de cada linha.

Uma classificação agregada pode ser útil para explorar resultados ou localizar testes, mas não deve ser apresentada como medida neutra de capacidade geral sem uma justificativa para a forma como foi construída. Se uma pontuação reúne tarefas heterogêneas, uma mudança na seleção ou nos pesos pode alterar a posição. Além disso, sem rastreabilidade até as publicações originais, não é possível verificar se as condições de todas as linhas são comparáveis ou se se referem à mesma versão do modelo.

Comparabilidade, contaminação e reprodutibilidade

Dois resultados só podem ser comparados diretamente quando suas condições são suficientemente equivalentes para responder à pergunta em questão. Em avaliações de agentes de IDE, isso significa examinar, entre outros aspectos, o modelo exato e sua versão, o nível de raciocínio, as instruções, as ferramentas disponíveis, o harness que conecta o modelo ao ambiente e os limites de execução. As fontes resumidas não fornecem esses dados para todos os testes citados, portanto não é possível estabelecer equivalência entre eles.

A contaminação dos conjuntos de avaliação exige uma análise específica. Para estimar esse risco, seria necessário saber como as tarefas foram construídas, quando foram incluídas, se seus enunciados ou soluções poderiam ter aparecido nos dados de treinamento e quais controles os autores aplicaram. As notas das fontes fornecidas não descrevem controles ou análises de contaminação para o System Card, os testes com o Junie, o estudo de agentes de IDE ou a agregação do BenchLM. Isso significa que o risco não foi avaliado aqui; não significa que a contaminação tenha sido comprovada.

A reprodutibilidade também depende de mais do que publicar uma pontuação. Prompts, dados de avaliação, código do harness, configuração do modelo, critérios de pontuação e registros de execução são materiais úteis. Se algum desses elementos não for publicado, deve-se explicar que parte do resultado não pode ser repetida ou inspecionada de forma independente. Com os resumos disponíveis, não é possível confirmar quais materiais acompanham cada documento nem se são suficientes para reproduzi-lo.

Essas lacunas devem ser tratadas como questões pendentes de verificação, não como falhas comprovadas das avaliações. Uma análise posterior dos documentos completos poderia fornecer os detalhes ausentes nas notas. Até lá, a opção rigorosa é manter os resultados separados, atribuir cada afirmação à sua fonte e evitar inferências sobre uma posição geral.

Conclusões proporcionais às evidências

Com as fontes e notas verificadas, é possível afirmar que a Anthropic comunica resultados favoráveis do Opus 4.5 frente ao Sonnet 4.5 em testes associados ao Junie; que o System Card compara o Opus 4.5 com outros modelos em uma suíte de tarefas; que existe um estudo independente sobre modelos como agentes de IDE que menciona variabilidade para o Opus 4.5; e que o BenchLM publica uma pontuação e uma posição agregadas. Cada afirmação corresponde a uma fonte e a um tipo diferente de evidência.

Com esse material, não é possível reconstruir os protocolos completos nem determinar se os testes utilizam o mesmo identificador de modelo, as mesmas ferramentas, o mesmo orçamento, o mesmo harness ou a mesma métrica. Também não é possível verificar o valor e a interpretação do desvio padrão mencionado, os controles de contaminação, a disponibilidade de materiais reproduzíveis ou a metodologia da Artificial Analysis. Portanto, as pontuações não formam uma classificação comum e não justificam uma conclusão geral sobre qual modelo é melhor.

Para uma equipe que avalia o Opus 4.5 em programação ou em agentes de IDE, a decisão prática é consultar ou solicitar a documentação do teste mais próximo de seu próprio fluxo de trabalho. É preciso comparar tarefas equivalentes, medir qualidade e taxa de conclusão, contabilizar custo e latência e observar a variação entre repetições. Se a metodologia não estiver publicada, essa limitação deve aparecer junto ao resultado, e a decisão não deve se apoiar em uma posição agregada isolada.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.