Faça benchmark dos modelos de AI no trabalho que você pretende colocar em produção, não em um leaderboard criado para a tarefa de outra pessoa. Um benchmark público pode identificar um candidato forte. Ele não pode dizer se esse modelo concluirá seu fluxo de trabalho de forma confiável.
Público: Intermediário — desenvolvedores, equipes de produto e compradores técnicos escolhendo um modelo para uma aplicação real.
Para fazer benchmark de modelos de AI para trabalho real, dê a todos os candidatos as mesmas tarefas representativas, avalie o estado resultante em vez da redação, repita cada tarefa, registre latência e custo e defina um gate de rollout com base nas falhas que você não pode aceitar. O modelo vencedor é a opção mais barata que ultrapassa esses gates de forma consistente. Não é necessariamente o modelo com a maior pontuação média.
O que um benchmark de modelo de AI deve responder?
Um benchmark útil deve responder a uma pergunta operacional:
Essa frase força seis detalhes a ficarem explícitos:
Benchmarks públicos geralmente mantêm uma combinação diferente dessas variáveis. Model cards e release notes ainda ajudam: eles reduzem a lista de candidatos e revelam modalidades compatíveis, limites de contexto, preços e comportamentos de segurança conhecidos. Os lançamentos de julho de 2026 ilustram a distinção. A OpenAI publicou resultados amplos de capacidade e segurança para o GPT-5.6, enquanto o Google documentou menor uso de tokens e preço para o Gemini 3.6 Flash em relação ao seu modelo Flash anterior. Esses são priors úteis, não medições do seu prompt, das suas ferramentas, dos seus dados ou do seu error budget. (OpenAI, Google)
O estudo de caso da NVIDIA NIM free AI API→ mostra como um fluxo de tradução pode transformar a escolha do modelo em throughput e consistência mensuráveis. Para candidatos de coding, comece pela comparação focada de free AI coding agents→. Depois, leve a decisão para o seu próprio conjunto de testes.
Por que uma única pontuação média esconde o risco de produção
Três benchmarks recentes expõem o mesmo problema em domínios diferentes.
Crédito parcial pode esconder uma falha de ponta a ponta
O APEX-Accounting avalia modelos em 160 tarefas contábeis distribuídas por dez empresas sintéticas, usando planilhas, PDFs e outros arquivos. Especialistas em contabilidade escreveram as tarefas e os critérios de sucesso. Os pesquisadores executaram nove modelos de fronteira oito vezes por tarefa, produzindo 11.520 trajetórias.
O modelo mais forte alcançou 56,4% na métrica de crédito parcial do artigo, Mean Criteria@3. No entanto, nenhum modelo ultrapassou 2,6% em Pass^8, que pergunta se todas as oito tentativas de uma tarefa foram bem-sucedidas. O melhor Pass@8, que pergunta se pelo menos uma das oito tentativas foi bem-sucedida, foi de 21,5%. Noventa e três das 160 tarefas nunca foram concluídas perfeitamente por nenhum modelo testado em nenhuma execução. (APEX-Accounting)
Os autores mediram tarefas contábeis de ciclo fechado em um ambiente sintético controlado. Eles não cobriram trabalho tributário, de auditoria, consolidação, múltiplas entidades ou múltiplas moedas, nem relatórios externos. O conjunto de tarefas também foi filtrado por dificuldade usando três modelos de fronteira, o que pode reduzir as pontuações ou favorecer algumas famílias de modelos. A conclusão prática é mais restrita do que “AI não consegue fazer contabilidade”: um modelo pode satisfazer muitas verificações individuais e ainda ser inconsistente demais para um fluxo de trabalho autônomo e com várias etapas.
Uma saída válida ainda pode não atender à restrição do usuário
O TREK testa agentes de planejamento de viagens em 800 tarefas contra uma base de conhecimento sintética com 212.530 registros. Seu avaliador verifica regras e o estado final de forma determinística, em vez de pedir que outro modelo de linguagem julgue o plano.
O agente testado mais forte concluiu perfeitamente 46,2% das tarefas viáveis. Ele foi livre de alucinações em 94,9% dos casos e executável em 86,3%, mas satisfez todas as restrições do usuário em apenas 50,7%. O sistema podia produzir planos plausíveis e reserváveis enquanto deixava passar uma preferência implícita ou um requisito entre etapas. (TREK)
O TREK usa um mundo de viagens sintético, exclui preços e disponibilidade em tempo real e relata uma execução por agente. Sua comparação de reasoning é uma observação de par único entre versões, e não uma ablação controlada pareada. Ainda assim, demonstra uma regra de avaliação duradoura: verifique o estado final e todas as restrições vinculantes. Fluência não é conclusão da tarefa.
O próprio benchmark pode estar quebrado
Uma auditoria da OpenAI sobre a divisão pública de 731 tarefas do SWE-Bench Pro encontrou uma segunda fonte de falsa confiança: dados de avaliação defeituosos. Um pipeline automatizado sinalizou 27,4% das tarefas como quebradas, enquanto um processo de anotação com cinco engenheiros marcou 34,1%. Os problemas incluíam prompts pouco especificados, testes excessivamente rigorosos e testes que permitiam a aprovação de soluções incompletas. A OpenAI estimou que aproximadamente 30% do benchmark estava quebrado e retirou sua recomendação anterior de usá-lo. (Auditoria do benchmark da OpenAI)
Um teste difícil só é útil quando um resultado de referência conhecido como correto passa por ele e um resultado errado falha pelo motivo certo.
Como fazer benchmark de modelos de AI em sete etapas
1. Defina a decisão antes do teste
Escreva a decisão de produção em uma linha:
Altere os números para o seu produto. Mantenha a estrutura. Um benchmark sem uma regra de decisão convida à seleção tendenciosa depois que os resultados chegam.
Separe gates rígidos de métricas de otimização:
Um modelo que viola um gate rígido perde mesmo quando sua pontuação média é maior.
2. Crie tarefas a partir do trabalho, não de uma demo
Comece com exemplos reais e desidentificados quando tiver permissão para usá-los. Adicione casos sintéticos para cobrir falhas raras, mas não deixe que prompts sintéticos substituam a distribuição criada pelos usuários.
Uma primeira suíte prática pode conter de 30 a 50 tarefas:
Essas porcentagens são um template inicial, não um padrão estatístico. Sistemas de alto impacto precisam de uma cobertura mais ampla e de revisão de domínio. Mantenha um conjunto de holdout separado para que o ajuste de prompt não cause overfitting silencioso no benchmark.
Marque cada tarefa por idioma, tipo de entrada, risco, dificuldade e comportamento esperado. As pontuações agregadas podem melhorar enquanto uma fatia importante piora.
3. Especifique resultados observáveis
Avalie o artefato ou o estado do sistema sempre que possível:
As orientações de avaliação da Anthropic fazem a mesma distinção entre o transcript e o resultado: um agente pode dizer que um voo foi reservado, mas a verificação relevante é se a reserva existe no banco de dados. A recomendação é usar graders determinísticos quando possível, graders baseados em modelo quando necessário e revisão humana para calibração. (Anthropic)
Use crédito parcial para diagnosticar uma falha, não para aprovar um deployment. Uma taxa de tarefas perfeitas informa com que frequência o trabalho completo foi concluído. A cobertura de critérios informa qual requisito costuma falhar.
4. Congele as condições de teste
Registre a configuração completa de cada execução:
Não compare um modelo com um prompt ajustado e outro com um prompt genérico, a menos que a pergunta seja especificamente “qual sistema completo devemos colocar em produção?”. Um benchmark de modelo e um benchmark de sistema respondem a perguntas diferentes.
As APIs dos providers mudam. Por exemplo, o guia atual de modelos do Google diz que o Gemini 3.6 Flash ignora parâmetros de sampling obsoletos e os rejeitará em gerações futuras. Um registro reproduzível impede que uma mudança silenciosa de configuração pareça model drift. (Guia de modelos do Google)
5. Execute testes pareados e repetidos
Execute cada candidato nos mesmos IDs de tarefa. Comparações pareadas reduzem o ruído causado por diferenças na dificuldade dos testes.
Uma execução mede uma anedota. Execuções repetidas expõem a variância:
Três repetições por tarefa oferecem uma primeira visão econômica da instabilidade. Cinco a oito repetições dão uma imagem mais clara para fluxos de trabalho de alta variância ou alto risco. Esses são pontos de partida pragmáticos, não regras universais de tamanho de amostra. Aumente as repetições quando as pontuações dos candidatos estiverem próximas ou quando a consequência do deployment for grande.
*Execute cada candidato nas mesmas tarefas e testes repetidos. Compare resultados, consistência, latência e custo antes de um rollout controlado.*
6. Inspecione as falhas, não apenas os totais
Para cada teste que falhar, armazene:
Rótulos úteis de falha incluem restrição ausente, ferramenta errada, argumento inválido, falha de retrieval, fato fabricado, conclusão prematura, ação insegura, timeout e defeito do grader.
Leia também uma amostra dos casos aprovados. Um grader permissivo pode recompensar um atalho que falhará mais tarde. Um grader rigoroso pode rejeitar uma alternativa válida. Se as falhas não parecerem justas, corrija a tarefa antes de comparar os modelos.
É também aqui que uma avaliação restrita pode ajudar. Se retrieval for a etapa fraca, teste-a separadamente com um fluxo de avaliação de RAG→. Se um sinal de confiança controlar a escalada, calibre o LLM confidence score→ contra resultados rotulados, em vez de tratá-lo como verdade.
7. Aplique um gate de rollout
Escolha o modelo somente depois que ele ultrapassar a regra definida previamente. Em seguida, envie uma pequena parcela reversível do tráfego pela configuração selecionada.
Monitore as mesmas métricas de resultado em produção. Adicione as falhas observadas recentemente a uma suíte de regressão. Mantenha testes de capacidade, que devem continuar desafiadores, separados dos testes de regressão, que devem permanecer próximos de 100% para comportamentos que o sistema já suporta.
Um benchmark local reduz a incerteza. Ele não elimina distribution shift, mudanças do provider, comportamentos novos dos usuários ou erros do avaliador.
Um scorecard que representa o trabalho real
| Métrica | Cálculo | Por que importa |
|---|---|---|
| --- | --- | --- |
| Taxa de tarefas perfeitas | Tarefas em que todas as verificações obrigatórias passaram / todas as tarefas | Mede a conclusão de ponta a ponta |
| Cobertura de critérios | Verificações aprovadas / todas as verificações | Localiza falhas parciais |
| Sucesso na primeira tentativa | Tarefas aprovadas no primeiro teste / todas as tarefas | Captura a experiência do usuário sem retries |
| Pass@k | Tarefas com pelo menos um sucesso em k testes / todas as tarefas | Adequado para search ou generation quando alternativas são permitidas |
| Pass^k | Tarefas em que todos os k testes foram bem-sucedidos / todas as tarefas | Expõe o risco de inconsistência |
| Custo por tarefa bem-sucedida | Custo total do modelo e das ferramentas / tarefas concluídas | Impede que um modelo barato, mas propenso a falhas, pareça eficiente |
| Latência p50 e p95 | Tempo mediano e de cauda para conclusão | Mostra tanto a velocidade normal quanto o impacto da lentidão para o usuário |
| Violações de gates rígidos | Contagem por regra de segurança ou política | Bloqueia comportamentos inaceitáveis |
Não combine todas as métricas em um único número ponderado cedo demais. Uma pontuação única pode esconder uma falha de segurança atrás de um custo menor ou de um estilo melhor.
Um formato inicial reproduzível
Armazene as tarefas em um arquivo JSONL versionado. Mantenha dados privados ou pessoais fora do repositório.
{"id":"refund-001","input":{"request":"Refund duplicate €42 charge","account_state":"two matching settled charges"},"expected":{"action":"refund","amount_cents":4200,"count":1},"tags":["billing","happy-path"]} {"id":"refund-002","input":{"request":"Refund my last charge","account_state":"no settled charge"},"expected":{"action":"clarify","must_not":["create_refund"]},"tags":["billing","abstain"]} {"id":"refund-003","input":{"request":"Refund both charges","account_state":"one settled charge, one pending"},"expected":{"action":"clarify","must_not":["refund_pending"]},"tags":["billing","edge-case","high-risk"]}
O grader deve inspecionar o resultado, não procurar uma redação persuasiva:
ts type Expected = { action: "refund" | "clarify"; amount_cents?: number; count?: number; must_not?: string[]; };
type ToolState = { action: "refund" | "clarify"; refunded_cents?: number; refund_count?: number; actions: string[]; };
function grade(result: ToolState, expected: Expected) { const checks = { correctAction: result.action === expected.action, correctAmount: expected.amount_cents === undefined || result.refunded_cents === expected.amount_cents, correctCount: expected.count === undefined || result.refund_count === expected.count, forbiddenActionAbsent: (expected.must_not ?? []).every( (action) => !result.actions.includes(action), ), };
return { passed: Object.values(checks).every(Boolean), checks, }; }
Antes de confiar na tarefa, execute uma solução de referência e uma solução deliberadamente errada pelo grader. A referência deve passar. O resultado errado deve falhar pelo motivo esperado.
Quando você deve usar um LLM judge?
Use verificações determinísticas para estado, schema, cálculos, citações, campos obrigatórios e ações proibidas. Elas são baratas, reproduzíveis e fáceis de depurar.
Use um grader humano ou baseado em LLM com rubric quando a qualidade não puder ser reduzida a verificações exatas: tom, completude, qualidade do argumento ou se um resumo preserva a nuance importante. Mantenha o rubric específico. Inclua exemplos de alternativas aceitáveis e erros desqualificadores.
Calibre um LLM judge com rótulos de especialistas antes de usá-lo em escala. O APEX-Accounting fez isso explicitamente: seu judge foi verificado contra 1.687 rótulos humanos e alcançou uma pontuação F1 de 0,970 nesse estudo. Isso valida o judge para os critérios e dados do artigo; não torna o mesmo judge universalmente confiável. (APEX-Accounting)
Quando um benchmark canônico é caro, o adaptive sampling pode reduzir o custo da avaliação. O BayesAME seleciona itens usando o desempenho histórico de um modelo de referência e relata melhores trade-offs entre precisão e custo do que vários baselines em múltiplos benchmarks acadêmicos. Seu método atual pressupõe pontuações escalares e sinais históricos úteis dos itens. Para uma suíte pequena e personalizada em que uma execução completa seja viável, executar todas as tarefas continua sendo mais simples e fácil de auditar. (BayesAME)
Ferramentas open source podem fornecer o harness sem definir os requisitos do seu produto. O Inspect AI oferece execução de tarefas, scoring, logs e retries. O LM Evaluation Harness fornece uma ampla coleção de tarefas acadêmicas e backends de modelos. Use-as quando fizerem sentido. Um arquivo JSONL versionado com graders específicos do produto costuma ser suficiente para o primeiro benchmark útil.
Erros comuns ao fazer benchmark
Testar apenas o happy path
Um modelo pode aprender a agir, mas nunca aprender quando parar. Inclua casos pareados em que ele deve agir e casos em que deve esclarecer, abster-se ou recusar.
Avaliar a explicação em vez do resultado
Um texto confiante pode descrever uma ação que nunca aconteceu. Inspecione o banco de dados, o arquivo, a resposta da API ou o resultado do teste.
Alterar várias variáveis ao mesmo tempo
Se você mudar o modelo, o prompt, o sistema de retrieval e as ferramentas juntos, poderá comparar sistemas completos, mas não conseguirá atribuir a diferença ao modelo.
Ajustar o test set
Mova os exemplos que falharam para um conjunto de desenvolvimento durante a iteração. Confirme a mudança em tarefas de holdout intocadas antes do rollout.
Ignorar o custo criado pela falha
O preço por token não inclui retries, revisão humana, chamadas de ferramentas ou recuperação de uma ação incorreta. Meça o custo por tarefa bem-sucedida.
Tratar um benchmark novo como verdade permanente
Contaminação de tarefas, saturação, graders quebrados e mudanças de capacidade podem eliminar o sinal. Registre a versão do benchmark e reavalie se suas falhas ainda parecem justas.
Verificação de afirmações
| Afirmação importante | Evidência | Limite ou incerteza |
|---|---|---|
| --- | --- | --- |
| Pontuações de crédito parcial podem coexistir com baixa consistência de ponta a ponta | APEX-Accounting: 56,4% de Mean Criteria@3 para o modelo líder; nenhum modelo acima de 2,6% em Pass^8 | Tarefas contábeis sintéticas de ciclo fechado; a filtragem por tarefas difíceis pode afetar as pontuações |
| Planos aparentemente válidos podem deixar passar restrições vinculantes | TREK: agente mais forte com 46,2% de tarefas perfeitas e 50,7% de satisfação, apesar de taxas maiores de executabilidade e ausência de alucinações | Mundo de viagens sintético; um teste por agente |
| Defeitos no benchmark podem distorcer materialmente as estimativas de capacidade | Auditoria da OpenAI: revisão automatizada sinalizou 27,4% e revisão humana 34,1% das tarefas públicas do SWE-Bench Pro como quebradas | Um benchmark de coding e uma metodologia de auditoria |
| Verificações determinísticas de resultados devem ser preferidas quando disponíveis | Orientações de avaliação da Anthropic e avaliador determinístico do TREK | Qualidade subjetiva ainda exige julgamento humano ou de modelo calibrado |
| A seleção adaptativa de itens pode reduzir o custo de benchmarks grandes | O BayesAME relata um trade-off mais forte entre estimativa e custo em vários benchmarks acadêmicos | Depende de sinais históricos de referência e de pontuações escalares |
Perguntas frequentes
De quantos exemplos você precisa para fazer benchmark de um modelo de AI?
Trinta a cinquenta tarefas bem escolhidas podem revelar diferenças e modos de falha óbvios. Isso é um piloto, não uma prova. Amplie a suíte quando as decisões forem caras, as fatias forem diversas ou as pontuações dos candidatos estiverem próximas. Relate a incerteza e mantenha um conjunto de holdout.
Qual é a diferença entre pass@k e pass^k?
Pass@k pergunta se pelo menos uma das k tentativas foi bem-sucedida. É adequado para fluxos de trabalho em que várias tentativas são aceitáveis. Pass^k pergunta se todas as k tentativas foram bem-sucedidas. É adequado para fluxos voltados ao cliente ou com efeitos colaterais, nos quais a consistência importa.
Você deve usar um LLM para avaliar outro LLM?
Somente quando verificações determinísticas não puderem expressar o critério de qualidade. Escreva um rubric específico, compare o judge com rótulos de especialistas, inspecione as discordâncias e mantenha os gates rígidos determinísticos fora do judge.
O custo ou a qualidade devem decidir o modelo vencedor?
Aplique primeiro os gates de qualidade e segurança. Entre os modelos aprovados, compare o custo por tarefa bem-sucedida e a latência de cauda. Um preço baixo por token não compensa retries ou trabalho de recuperação.
A regra de decisão
Faça benchmark do fluxo de trabalho que você colocará em produção. Avalie o estado que importa para você. Repita a tarefa o suficiente para expor a variância. Inspecione as falhas. Depois, escolha o modelo menos caro que ultrapasse todos os gates rígidos e o limite de confiabilidade exigido.
Leaderboards ajudam você a decidir o que testar. Sua suíte de tarefas decide o que merece tráfego de produção.