Claude Sonnet 4.5 nas ciências da vida: o que os resultados demonstram e como revalidá-los

O que significa superar uma referência humana em um teste delimitado

Uma pontuação de benchmark responde a uma pergunta específica: qual foi o desempenho de um modelo em determinado conjunto, tarefa, instruções e condições. Ela não responde automaticamente a outra questão, muito mais ampla: se o modelo consegue ler corretamente os protocolos de um laboratório, interpretar seus dados e apoiar conclusões científicas com confiabilidade. Para decidir se o Claude Sonnet 4.5 pode ajudar em um fluxo de trabalho real, é preciso manter essas duas afirmações separadas.

O cartão de sistema do Claude Sonnet 4.5 informa resultados do LAB-Bench para várias tarefas, entre elas Protocol QA, FigQA, SeqQA e Cloning, e apresenta uma referência humana. No gráfico indicado para Protocol QA, a pontuação do Sonnet 4.5 é 0,833 com k=10; a do Sonnet 4 é 0,741. Esses números correspondem ao resultado publicado pela Anthropic, não a uma validação independente do desempenho em qualquer documentação ou laboratório.

Portanto, uma pontuação superior a uma referência humana em uma avaliação específica não significa que o modelo seja melhor do que pesquisadores em geral, que acerte todas as perguntas ou que suas respostas possam ser usadas com segurança como instruções experimentais. A interpretação depende das perguntas feitas, de como foram avaliadas e de quem compôs o grupo de comparação humana. As informações disponíveis nas fontes não bastam para extrapolar o resultado a outros documentos, equipes ou decisões.

Identificar com precisão o modelo avaliado

“Claude Sonnet 4.5” é o nome de uma família ou versão comercial, mas uma avaliação reproduzível precisa registrar o identificador usado na solicitação. A documentação da Anthropic diferencia identificadores datados de aliases e identifica o snapshot do Sonnet 4.5 como claude-sonnet-4-5-20250929. Registrar esse identificador, junto com a data e a configuração do teste, reduz a ambiguidade ao comparar resultados.

Essa precaução também vale para a comparação com modelos posteriores. A fonte oficial fornecida sobre o Sonnet 5 anuncia esse modelo, mas não demonstra que ele tenha sido avaliado nas mesmas tarefas do LAB-Bench ou BixBench, segundo o mesmo protocolo e com o mesmo conjunto que o Sonnet 4.5. A documentação fornecida tampouco permite afirmar que exista uma comparação equivalente para o Sonnet 4.6. O lançamento de uma versão posterior, por si só, não é evidência de melhora nessas tarefas.

Uma comparação útil precisa fixar a tarefa e as condições; não basta confrontar nomes de modelos. Se mudarem o conjunto de perguntas, o número de exemplos apresentados ao modelo, as ferramentas disponíveis ou o método de pontuação, as diferenças podem decorrer dessas variações, além da versão do modelo.

Três benchmarks, três tipos de evidência

LAB-Bench é um conjunto de tarefas para medir capacidades de modelos de linguagem relacionadas à pesquisa em biologia. O artigo original descreve perguntas de múltipla escolha e uma comparação com pesquisadores especialistas. Seu escopo é o das tarefas incluídas no benchmark; não equivale à observação direta do trabalho em laboratório nem a uma avaliação de todas as etapas de uma pesquisa.

Protocol QA, integrante do LAB-Bench, concentra-se em responder perguntas sobre protocolos. O resultado publicado para o Sonnet 4.5 oferece evidência sobre seu desempenho nessa tarefa nas condições relatadas na avaliação. Não demonstra que o modelo execute um protocolo, detecte todas as suas ambiguidades ou adapte corretamente uma instrução a reagentes, instrumentos e procedimentos locais. Compreender uma pergunta documental e realizar uma operação experimental são capacidades distintas.

O LAB-Bench também inclui tarefas relacionadas à leitura de figuras, sequências e clonagem. O fato de o cartão de sistema informar resultados nessas categorias amplia o panorama da avaliação, mas não torna as pontuações intercambiáveis: cada tarefa testa capacidades e formatos diferentes. Um bom resultado em perguntas sobre protocolos não permite inferir automaticamente um resultado equivalente na interpretação de uma figura.

BixBench aborda biologia computacional por meio de perguntas abertas que exigem trajetórias analíticas de várias etapas. O artigo original descreve avaliações iniciais com GPT-4o e Claude 3.5 Sonnet, não com Claude Sonnet 4.5. Portanto, BixBench é útil para explicar um tipo de avaliação de análise computacional, mas os resultados iniciais não são resultados do Sonnet 4.5 e não devem ser apresentados como tal.

O repositório do BixBench descreve um harness e uma configuração para executar avaliações que incluem análise de notebooks e código. Essa estrutura permite planejar uma reprodução controlada do benchmark, mas não elimina a necessidade de verificar qual versão, quais ferramentas e quais condições foram usadas em cada experimento. Para o LAB-Bench, o repositório dos autores documenta formatos e scripts de avaliação e alerta que o material público não contém o conjunto completo. Essa limitação importa se o objetivo for reconstruir exatamente um resultado publicado.

Por que não se deve combinar números de Protocol QA sem verificá-los

As evidências fornecidas incluem um resultado de Protocol QA no cartão de sistema do Sonnet 4.5: 0,833 para o Sonnet 4.5 com k=10 e 0,741 para o Sonnet 4. A proposta editorial indica que algumas publicações da Anthropic mostram pontuações diferentes para tarefas chamadas Protocol QA. No entanto, as fontes fornecidas não documentam informações suficientes para determinar se esses números vêm do mesmo conjunto, de partições diferentes, de prompts distintos ou de outras mudanças metodológicas.

A coincidência no nome da tarefa não garante que duas medições sejam equivalentes. Antes de apresentá-las como uma evolução ou discrepância, seria necessário verificar a versão exata do modelo, o conjunto avaliado, o formato das perguntas, os exemplos incluídos no prompt, a disponibilidade de ferramentas, a regra de pontuação e o tratamento dado a respostas parciais. Também seria preciso esclarecer o que k=10 significa no gráfico e como as respostas foram agregadas, caso se queira interpretar esse parâmetro com precisão.

A comparação humana exige uma auditoria semelhante. O cartão de sistema apresenta uma referência humana, mas os materiais aqui descritos não fornecem detalhes suficientes para caracterizar com segurança a população, o número de participantes, sua experiência ou as instruções recebidas. Sem esses dados, não é rigoroso apresentar essa referência como um padrão universal de desempenho especializado.

A conclusão adequada não é que os resultados sejam incompatíveis, nem que algum número esteja errado: é que as informações disponíveis não permitem resolver se são comparáveis. Uma redação rigorosa informa cada número em seu contexto e explicita a incerteza, em vez de calcular uma tendência ou combinar pontuações.

Do benchmark ao laboratório: a lacuna que permanece

Um benchmark pode avaliar se uma resposta corresponde a um gabarito, mas um laboratório precisa saber se ela está correta para sua documentação vigente e no contexto da pergunta. Pode haver protocolos com variantes locais, nomes internos, notas de revisão ou condições relevantes que não apareçam no material de referência de um teste público. A capacidade de responder a perguntas gerais não verifica se o modelo encontrou e aplicou a versão pertinente.

Além disso, responder sobre um protocolo não equivale a executá-lo. A execução depende de pessoas, equipamentos, amostras, materiais e controles, aspectos que uma pontuação de perguntas e respostas não demonstra. Da mesma forma, produzir uma interpretação plausível de uma figura não prova que ela seja válida nem que a conclusão científica se sustente diante do conjunto completo de dados.

O uso de ferramentas acrescenta outra dimensão. Em uma tarefa de análise computacional, a capacidade de produzir ou executar código pode influenciar o resultado; em uma tarefa documental, talvez o modelo responda apenas com base no prompt. Para atribuir a diferença a uma versão do modelo, a comparação deve manter as ferramentas constantes e registrar quando foram usadas. As fontes disponíveis descrevem elementos de avaliação dos benchmarks, mas não bastam para reconstruir todas as condições de cada número publicado.

Por essas razões, um resultado favorável serve como motivo para avaliar um uso delimitado — por exemplo, localizar uma resposta candidata na documentação e preparar um rascunho para revisão —, não como autorização para substituir a verificação de especialistas nem como demonstração de validade científica.

Como elaborar uma validação retrospectiva útil

Um teste interno não precisa automatizar experimentos nem expor informações sensíveis para avaliar a compreensão documental. Pode ser construído com um corpus autorizado e congelado: documentos que a equipe tenha permissão para usar, uma versão identificável de cada arquivo e um registro do material disponível no momento da resposta. Congelar o corpus evita que mudanças posteriores nos documentos alterem a interpretação dos resultados.

Especialistas familiarizados com os documentos devem redigir e revisar perguntas representativas, junto com respostas de referência verificadas na fonte. Convém incluir perguntas com resposta explícita, perguntas cuja resposta exija combinar partes do documento e perguntas impossíveis de resolver com o material disponível. Essa última categoria permite verificar se o sistema reconhece os limites das evidências, em vez de preencher lacunas com uma resposta plausível.

Cada resposta deve ser avaliada segundo uma rubrica antes da comparação entre modelos. A rubrica pode separar exatidão do conteúdo, respaldo na fonte, identificação da versão pertinente, omissões importantes e afirmações sem respaldo. As respostas devem ser revisadas por pessoas que não dependam da marca ou da versão do modelo para julgar o resultado, e as divergências entre avaliadores precisam ser registradas e resolvidas com critérios acordados previamente.

Para comparar o Sonnet 4.5 com versões posteriores, devem ser usadas as mesmas perguntas, documentos, instruções, ferramentas e regras de pontuação. É necessário registrar o identificador exato de cada modelo. Se uma plataforma não permitir fixar uma versão ou um parâmetro, essa limitação faz parte do resultado e não deve ser omitida. Repetições também ajudam a identificar se o sistema responde de maneira estável; o número de repetições deve ser definido de acordo com o custo e o risco da aplicação, não deduzido das fontes públicas.

O teste deve ser retrospectivo e restrito à compreensão de documentação passível de revisão. Não é necessário pedir ao modelo que planeje, modifique ou execute experimentos para descobrir se ele encontra informações, interpreta o texto ou reconhece que uma pergunta não está respondida. Se forem avaliadas figuras ou resultados analíticos, a equipe deve dispor de referências verificadas e separar esse resultado das pontuações de perguntas sobre protocolos.

Classificar os erros que importam

Uma única taxa geral de acertos pode ocultar falhas de gravidade diferente. Na leitura de protocolos, uma omissão pode deixar de fora uma condição importante; inverter etapas pode alterar o sentido de uma instrução; confundir unidades pode fazer uma resposta parecer precisa sem ser. A equipe deve registrar esses casos separadamente, sem presumir que todas as respostas incorretas impliquem o mesmo risco.

Em perguntas sobre figuras, convém distinguir entre descrever um elemento visível, atribuir uma relação que não está representada e propor uma explicação causal. Em tarefas computacionais, é preciso diferenciar uma análise reproduzível de uma conclusão que não decorre dos dados. Também devem ser sinalizadas referências que não sustentam a resposta, citações a seções erradas e confiança injustificada diante de informações ausentes.

A avaliação de segurança editorial deve permanecer no campo documental: verificar se o modelo representa fielmente o conteúdo autorizado e se sinaliza incertezas. Não é necessário incluir instruções experimentais sensíveis nem solicitar ações que não façam parte da tarefa de leitura. O objetivo é descobrir se o sistema serve como apoio sujeito a revisão, não transformar o benchmark interno em validação de procedimentos.

Uso delimitado e conclusão

Se uma avaliação interna favorável confirmar que o Sonnet 4.5 encontra informações e as apresenta com respaldo verificável, a equipe poderá testá-lo como assistente de leitura ou gerador de rascunhos sujeitos a revisão. A resposta final continuará dependendo do processo de verificação acordado pelo laboratório. A pontuação pública, por si só, não justifica usar uma saída como instrução experimental nem como determinante de uma interpretação científica.

A comparação com sucessores deve ser planejada como um novo teste controlado. A documentação fornecida permite identificar o Sonnet 4.5 e indica um anúncio oficial do Sonnet 5, mas não apresenta resultados equivalentes deste último em Protocol QA, LAB-Bench ou BixBench. Tampouco permite estabelecer uma comparação controlada com o Sonnet 4.6. Portanto, essas fontes não permitem inferir qual modelo posterior tem melhor desempenho nas mesmas tarefas.

A conclusão verificável é mais limitada, mas útil: a Anthropic publica resultados favoráveis do Sonnet 4.5 em tarefas específicas do LAB-Bench, incluindo Protocol QA, enquanto o BixBench avalia outra classe de trabalho e os resultados iniciais citados não correspondem ao Sonnet 4.5. Esses dados justificam formular uma hipótese de utilidade para leitura e análise, não afirmar confiabilidade em um laboratório real. As evidências que faltam devem ser obtidas com documentos autorizados, perguntas revisadas por especialistas, referências rastreáveis e comparações em condições equivalentes.

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.