LLM benchmark: como interpretar as notas dos modelos

Um LLM benchmark deve ajudar você a decidir o que testar em seguida. O SWE-bench Verified mede o desempenho em 500 problemas de software selecionados; uma nota alta não diz se um agente consegue seguir sua política de reembolso. Antes de olhar a pontuação vencedora, entenda a tarefa, a configuração do teste e o critério de avaliação.

Conferido nas páginas dos autores dos benchmarks e na ficha técnica do modelo do Google em 15 de outubro de 2026. As descrições abaixo explicam cada teste; as pontuações usadas no exemplo são os resultados publicados pelo Google. A interpretação e o roteiro de avaliação são nossos.

Para um assistente de programação, comece por tarefas em repositórios ou no terminal. Para um agente de atendimento, comece pelo uso de ferramentas em conversas e pelo cumprimento de políticas. Para um assistente de documentos, comece pelo raciocínio em contextos longos. Uma nota de conhecimentos gerais pode apoiar essas decisões, mas não tomá-las por você.

O que um LLM benchmark mede?

Um benchmark mede o desempenho em um conjunto específico de tarefas, sob regras específicas. Está mais para uma prova esportiva do que para um atestado de inteligência: o tempo em uma corrida de velocidade traz uma informação útil, mas não define quem deve conduzir um resgate na montanha.

O conjunto de dados, ou dataset, contém as perguntas ou tarefas. O protocolo de avaliação define o que o modelo recebe, quais recursos de apoio pode usar e como o resultado será corrigido. O harness, também chamado de scaffold, é o software que envolve o modelo: seus prompts, ferramentas e ciclo de execução.

Essa distinção importa quando um anúncio de lançamento diz que um modelo sabe programar. Escrever uma função a partir de um prompt curto é uma tarefa diferente da de um agente que pesquisa um repositório, edita arquivos, executa testes e se recupera de um erro. Nesse segundo caso, a nota é do sistema em funcionamento, incluindo seu harness.

O ranking do SWE-bench deixa isso claro ao distinguir as configurações de avaliação, incluindo um ambiente compartilhado com mini-SWE-agent. Seu produto de programação pode oferecer outras ferramentas, instruções ou limites. Antes de aplicar a pontuação ao seu fluxo de trabalho, identifique o que estava rodando ao redor do modelo.

Os benchmarks que aparecem nos anúncios de modelos

Antes de comparar notas, relacione o benchmark ao trabalho que você precisa realizar. Estas são as famílias que vale reconhecer nos anúncios de modelos de uso geral, programação e voz em 2026, além dos testes de contexto que ajudam a interpretar suas alegações. Cada nome leva à página ou ao repositório dos autores.

Mantenha a versão junto do nome. O HLE-Diamond contém 1,000 perguntas refinadas, enquanto a versão final do HLE original contém 2,500. O Terminal-Bench 4.0 mudou recursos e tarefas. O repositório atual do tau documenta tanto novas modalidades quanto correções no sistema de avaliação. Uma nota nova ao lado de uma antiga pode refletir uma mudança na prova, não uma melhora no modelo.

Quais pontuações importam para o seu trabalho?

Escolha a família que se parece com a falha que você precisa evitar. Um fundador escolhendo um recurso de IA, um CTO aprovando um agente e um profissional responsável por chamados de suporte não devem dar o mesmo peso a todas as linhas da tabela de lançamento.

Benchmarks de agentes de programação

Quem mantém um produto existente deve começar por correções em repositórios e trabalho no terminal. O SWE-bench oferece evidências úteis sobre a resolução de problemas; o Terminal-Bench, sobre a execução de tarefas em um shell. LiveCodeBench e HumanEval ajudam a responder perguntas mais restritas sobre programação. Nenhum deles, sozinho, mede se será fácil manter uma alteração na sua base de código.

Imagine alguém que desenvolve um produto sozinho pedindo a um agente para alterar a exclusão de contas. Produzir uma função auxiliar correta é apenas parte do trabalho. O agente precisa encontrar todos os pontos de chamada afetados, preservar permissões, atualizar testes e evitar inconsistências nos registros dos clientes. Sua avaliação deve incluir essa mudança completa, com o mesmo acesso ao repositório e as mesmas ferramentas que você pretende oferecer.

Critério de decisão: se o trabalho envolve vários arquivos e etapas de execução, exija evidências de tarefas realizadas por agentes antes de selecionar candidatos. Use notas de funções isoladas como informação de apoio. Mantenha a revisão de código no processo de aceitação até que seus próprios casos justifiquem reduzir esse esforço.

Benchmarks de raciocínio de LLMs

GPQA, HLE, MMLU-Pro, AIME e ARC-AGI examinam tipos diferentes de raciocínio. São sinais úteis do que investigar, sobretudo quando a tarefa exige resolver problemas científicos ou matemáticos difíceis. Mas substituem mal a evidência direta sobre o cumprimento das suas regras operacionais.

As 198 perguntas do GPQA Diamond formam um conjunto de ciência selecionado deliberadamente. Um CTO avaliando um assistente interno de pesquisa pode usar esse sinal para montar uma lista de candidatos e depois testar o assistente com perguntas cujas respostas dependam do material da própria empresa. Já quem lidera o suporte deve dar mais atenção ao uso de ferramentas sujeito a políticas e ao encaminhamento de casos.

No caso do Humanity's Last Exam, separe a ambição do nome daquilo que é medido. Os autores distinguem explicitamente o desempenho acadêmico em perguntas com resposta fechada da pesquisa autônoma. Responder a uma pergunta difícil com solução conhecida não demonstra que um sistema consegue escolher um problema relevante, reunir evidências confiáveis e reconhecer quando está errado.

Contexto longo e voz exigem evidências próprias

Uma janela de contexto representa capacidade: quanto conteúdo de entrada um sistema aceita. A avaliação de contexto longo pergunta o que ele consegue fazer com esse conteúdo. Testes de recuperação localizam informações; testes de raciocínio exigem conectá-las. Os autores do RULER mostram por que encontrar um fato escondido não deve servir como medida geral de desempenho em contexto longo.

Para quem revisa contratos, o teste útil é verificar se o assistente conecta uma exceção em um anexo a uma cláusula do contrato principal e cita ambas corretamente. Inclua documentos em que a resposta esteja ausente, tenha sido substituída ou seja contradita. Um sistema que combina versões incompatíveis com confiança falhou, mesmo que tenha recuperado cada trecho.

Para voz, separe escuta, raciocínio, fala e controle da conversa. O FLEURS pode apoiar a avaliação de transcrição; o Big Bench Audio trata do raciocínio a partir de perguntas faladas; o VoiceBench abrange tarefas com instruções faladas. A família tau atual também avalia interações por voz. São medições distintas.

Um piloto de atendimento telefônico deve incluir ruído de fundo, nomes, interrupções, correções e transferência para uma pessoa. Ouça a interação e confira a ação final. A transcrição pode parecer correta enquanto a conversa falada é frustrante ou a conta errada é atualizada.

Benchmarks de desempenho de LLMs

Para decidir pela adoção, defina desempenho como trabalho aceito dentro dos limites do seu fluxo. Qualidade da resposta, confiabilidade na conclusão e tempo de resposta são requisitos separados. Um benchmark executado com raciocínio extenso pode ser relevante para uma investigação que roda durante a noite e inadequado para um atendimento ao vivo.

Quem compra deve pedir resultados nos recortes de tarefa necessários e na configuração real do produto. Quem opera deve examinar falhas e recuperação. Quem desenvolve deve conseguir reproduzir as configurações. Se o fornecedor não consegue identificar a configuração avaliada, a nota não basta como evidência para assumir um compromisso de uso em produção.

Como ler uma tabela de lançamento em cinco minutos

Use este roteiro de cinco minutos para decidir se um lançamento merece uma avaliação mais aprofundada. É um procedimento de leitura; esse tempo não basta para estabelecer se um modelo é seguro ou útil na sua aplicação.

1. 1

   Minuto 1: defina sua tarefa

   Escreva o resultado de que você precisa: corrigir problemas em repositórios, resolver solicitações de suporte, responder com base em documentos ou atender chamadas de voz. Marque as linhas que se parecem com essa tarefa. Deixe as vitórias sem relação com ela fora da decisão de adoção.

2. 2

   Minuto 2: identifique a prova exata

   Anote a edição do benchmark, o subconjunto, o idioma e a janela temporal das tarefas. Procure qualificadores como Diamond, Verified, offline, apenas texto ou com ferramentas. Consulte a página do próprio benchmark quando o rótulo estiver incompleto.

3. 3

   Minuto 3: confira a configuração

   Localize o harness, as ferramentas, o nível de raciocínio, o tempo disponível e a política de tentativas. Verifique se seu produto usará essas condições. Acesso a buscas, execução de código ou mais chances de tentar novamente podem mudar o que uma nota representa.

4. 4

   Minuto 4: entenda a métrica

   A acurácia é a proporção de respostas consideradas corretas. O F1 equilibra quantos itens retornados estão corretos com quantos dos itens necessários foram encontrados. A pontuação parcial pode recompensar avanço sem conclusão. Em uma taxa de erro, quanto menor, melhor. Leia a definição antes de interpretar uma porcentagem como trabalhos concluídos.

5. 5

   Minuto 5: descubra quem executou o teste

   Identifique quem rodou o teste: o fabricante, o organizador do benchmark ou outro avaliador. Leia a nota de rodapé de cada linha, sem presumir que a tabela inteira usou um único procedimento. Salve a fonte e as configurações e escolha um candidato para seus próprios testes.

O resultado deve ser uma nota de decisão curta: “Família de tarefas relevante, versão atual, configuração compreendida, vale testar nos nossos casos.” Se não conseguir preencher isso, registre o detalhe que falta antes de mudar um sistema que funciona.

Exemplo na prática: a tabela do Gemini 4 Argon do Google

O Gemini 4 Argon, modelo de IA de uso geral do Google, é um bom exemplo porque sua tabela mistura famílias de tarefas e critérios de pontuação. As linhas abaixo reproduzem os resultados do Google na ficha técnica de outubro, conferidos em 15 de outubro de 2026. São resultados atribuídos à empresa, não medições feitas para este artigo.

Leia o rótulo da linha e as notas junto de cada valor. Essas porcentagens não têm um denominador nem um significado em comum.

BFS significa busca em largura: percorrer as conexões de um grafo por nível de profundidade. Tokens são as unidades usadas para medir o contexto do modelo; não são a mesma coisa que palavras.

Leia as notas de rodapé antes de tirar conclusões

A metodologia de avaliação do Google informa que o Argon geralmente usa o nível máximo de raciocínio e pass@1, com exceções. O resultado de DeepSWE usa um harness mini-swe. O resultado de Terminal-Bench foi calculado pelo próprio Google, enquanto os resultados de comparação vêm do ranking oficial. Os resultados de GraphWalks foram calculados pelo Google para todos os modelos. No OSWorld, vale o máximo entre três execuções, com pontuação parcial no subconjunto offline.

Isso reúne diferentes arranjos de avaliação; não é evidência de que todas as células vieram de um único experimento controlado. Para quem desenvolve, a próxima pergunta é se o harness de programação se parece com o agente pretendido. Para quem compra, é se a configuração proposta para a aplicação corresponde às evidências. Para quem opera, é se a métrica recompensa a conclusão do resultado esperado.

Nossa conta: 99.7 menos 84.2 dá uma diferença de 15.5 pontos percentuais entre os resultados F1 publicados para GraphWalks. Essas linhas usam subconjuntos de comprimentos diferentes, portanto a subtração não isola o efeito causal do comprimento em perguntas idênticas. Mas mostra por que citar apenas a linha de contexto mais curto deixaria de fora uma evidência relevante para um fluxo de trabalho com documentos longos.

A interpretação do uso de computador é igualmente concreta: não traduza a pontuação parcial como “o agente conclui essa proporção das nossas tarefas de desktop”. Avançar parte do trabalho pode ter valor para um assistente que o devolve a uma pessoa. Um processo sem supervisão precisa de evidências de resultados completos e corretos.

Para entender o contexto de adoção desse modelo, veja o guia do Gemini 4 Argon e a comparação entre Gemini 4 Argon e Opus 5.5, em outro artigo.

Por que uma nota alta pode enganar?

Uma nota alta pode ser válida e, ainda assim, responder à pergunta errada para o negócio. O caminho útil é identificar a limitação e decidir qual evidência seria necessária para esclarecê-la.

Contaminação e otimização para o teste

Há contaminação quando perguntas ou respostas da avaliação entram no material de treinamento. O modelo pode se beneficiar da exposição prévia em vez de resolver um problema inédito. Testes públicos também podem virar alvos de otimização: ajustar prompts ou scaffolds repetidamente às mesmas tarefas reduz seu valor como verificação com material novo.

O LiveCodeBench usa problemas com datas identificadas para que os avaliadores possam selecionar tarefas publicadas depois do corte de treinamento. É um recurso útil do teste, não uma autorização para presumir que qualquer resultado com “Live” no nome está livre de contaminação. Confira a janela real dos problemas. Um salto grande a ponto de causar desconfiança é motivo para examinar o protocolo, não prova de má conduta.

Na sua própria avaliação, mantenha um conjunto reservado que não seja usado para ajustar prompts. Quando uma falha virar exemplo de desenvolvimento, acrescente casos novos ao conjunto reservado. Caso contrário, o sistema pode ficar excelente nos exemplos conhecidos e continuar frágil nos demais.

O scaffold pode mudar o sistema que está sendo comparado

O ambiente de execução importa. Um modelo com busca, ferramentas de arquivos, novas tentativas e instruções bem elaboradas constitui um sistema diferente do mesmo modelo respondendo a um único prompt. Melhorar o scaffold pode ser um avanço valioso de engenharia; o erro é atribuir todo o resultado ao modelo que está por baixo dele.

Use um harness compartilhado quando quiser isolar a troca de modelo. Avalie o produto completo quando estiver escolhendo entre produtos completos. Essas perguntas podem, legitimamente, levar a conclusões diferentes.

Um teste do fornecedor tem valor, mas não equivale a reprodução independente

O resultado de um fabricante é útil quando o método é claro, e o resultado de um organizador de benchmark é útil quando sua configuração se ajusta à comparação. Nenhum desses rótulos dispensa a leitura do protocolo. Distinga um resultado enviado a um ranking de outro reproduzido de forma independente sob condições comuns.

Procure o prompt, o identificador do modelo, o harness, o método de correção, as exclusões e a incerteza. Uma diferença pequena, sem informação suficiente sobre a variabilidade, não deve decidir uma migração. Um resultado omitido é evidência ausente; não é automaticamente um zero.

Examine também a agregação. Uma média geral incorpora as tarefas e os pesos escolhidos pelo avaliador. Sua fila de suporte pode ter muitos casos de exceção que mal afetam essa média. Não tire a média de porcentagens de benchmarks sem relação entre si para criar sua própria nota de inteligência.

Um bom avaliador ainda pode medir o resultado errado

Testes unitários, gabaritos, modelos avaliadores e preferências humanas recompensam coisas diferentes. A cobertura dos testes pode deixar passar um defeito; um gabarito pode conter um erro; um modelo avaliador pode preferir uma explicação bem escrita a uma ação correta. Uma vitória por preferência mede o que os participantes preferiram naquele procedimento.

O repositório atual do tau documenta correções nas tarefas e na avaliação. Esses ajustes melhoram o teste e, ao mesmo tempo, tornam essencial acompanhar as versões. Um teste é um sistema de medição que exige manutenção, não uma fonte de verdade incontestável.

Quando fazer suas próprias avaliações?

Faça suas próprias avaliações quando a decisão depender dos seus dados, políticas, ferramentas, usuários ou tolerância a falhas. As notas públicas de benchmarks de IA bastam para identificar candidatos plausíveis. São insuficientes para aprovar um agente que altera registros de clientes ou responde com base em documentos privados.

Aja agora se uma melhora em um benchmark relevante abordar uma falha conhecida do seu sistema atual: rode uma comparação controlada para essa classe de falha. Adie a migração se a melhora envolver tarefas sem relação com seu trabalho ou se a configuração publicada não estiver disponível no seu produto. Mantenha o sistema atual se ele já atender aos critérios de aceitação e o novo candidato não tiver demonstrado melhora relevante.

Para uma equipe de suporte de uma empresa de médio porte, um piloto inicial prático poderia conter 50 casos: 20 solicitações de rotina, 10 exceções de política, 10 entradas com informações ausentes ou contraditórias e 10 casos de permissão ou encaminhamento. Essas quantidades são sugestões para desenhar o piloto, não uma afirmação de que a amostra é estatisticamente suficiente para a implantação. Defina o tamanho final em função das taxas de falha e das diferenças que você precisa detectar.

Defina o resultado esperado antes de rodar os candidatos. Um caso de reembolso pode exigir a elegibilidade correta, a conta e o valor certos, nenhuma ação sem autorização e uma explicação clara. Um caso de encaminhamento deve ser aprovado quando o agente transfere o atendimento corretamente, mesmo que não resolva a solicitação por conta própria.

Rode cada candidato com os prompts, a recuperação de informações, as ferramentas e as permissões previstos para o uso real. Examine o registro final e o histórico das ações, não apenas a última mensagem. Repita casos instáveis, acompanhe a latência separadamente e revise divergências antes de declarar uma melhora. Mantenha um conjunto reservado para a decisão final.

O Promptfoo é uma ferramenta de avaliação para comparar prompts, modelos e aplicações com casos de teste e asserções. Sua documentação apresenta o modelo de execução; nossa análise do Promptfoo explica onde ele se encaixa e o que continua sob sua responsabilidade.

Use verificações determinísticas para fatos que você pode conferir diretamente, como a conta selecionada ou uma ação proibida. Para qualidades que exigem julgamento, como verificar se uma explicação é completa e fundamentada, use uma rubrica e calibre-a com avaliações humanas. O guia de LLM como avaliador aborda essa camada de avaliação e suas possíveis falhas.

Para colocar em prática na segunda-feira: escolha um fluxo de trabalho, escreva seus critérios de aceitação, reúna casos recentes e compare o sistema atual com um candidato nas mesmas condições. Decida a implantação com base nos resultados e nas falhas que importam para seus usuários.

Dúvidas sobre tabelas de benchmarks

Quais são os benchmarks de LLM mais comuns?

Comece reconhecendo as famílias: SWE-bench e Terminal-Bench para agentes de programação, GPQA e Humanity's Last Exam para perguntas acadêmicas, a família tau para uso de ferramentas em conversas e testes específicos de contexto longo e voz. Mantenha a edição e as configurações associadas a cada nota.

Qual é o melhor benchmark de LLM para programação?

Use o benchmark mais próximo da tarefa. O SWE-bench trata da resolução de problemas em repositórios; o Terminal-Bench, do trabalho no terminal; o HumanEval, da geração de funções; e o LiveCodeBench inclui tarefas de competição com datas identificadas. As alterações no seu próprio repositório é que mostram se a evidência se aplica ao seu caso.

O que é um dataset de benchmark de LLM?

Um conjunto de dados fornece as perguntas ou tarefas. Um resultado de benchmark comparável também exige um protocolo: prompts, ferramentas, limites, tentativas e pontuação. Compartilhar apenas o nome do conjunto de dados não garante que dois resultados sejam comparáveis.

Para receber orientações práticas sobre avaliação e adoção de IA, assine a newsletter.