Como criar seu próprio benchmark de LLM para o seu caso de uso (passo a passo)

O modelo que lidera o ranking público pode não ser o melhor pro SEU produto

Fala aí, beleza? Toda semana sai modelo novo no topo de algum leaderboard, e a tentação é trocar tudo correndo pro campeão da vez

Mas o ranking não sabe nada sobre os seus tickets, os seus usuários e os seus casos esquisitos…

Neste post tu vai ver como montar um conjunto de avaliação caseiro: escolher exemplos reais do produto, definir o critério de acerto, rodar o mesmo lote em modelos diferentes e registrar o resultado. Bora? 😀

Por que um benchmark interno vale mais que ranking público de LLM?

Antes do como, o porquê

O primeiro problema é o vazamento de dados. O estudo Don’t Make Your LLM an Evaluation Benchmark Cheater mostrou que, quando dados de teste vazam pro treino, os resultados em benchmark ficam bem inflados, inclusive em modelos pequenos, e a avaliação vira injusta

Aí vem a parte curiosa: um estudo de Stanford e da City University of Macau analisou 47 modelos públicos em ARC, GSM8K, HellaSwag e MMLU

A correlação de ranking entre o leaderboard padrão e uma versão controlada por paráfrase foi de 0,997

Ou seja, a contaminação infla as notas absolutas, mas quase não muda a ordem. O ranking até acerta quem é "melhor na média", só que a nota em si não é confiável como medida

E tem o lado dos rankings por votação. O paper The Leaderboard Illusion, da Cohere Labs com outras instituições, analisou 2 milhões de batalhas do Chatbot Arena entre janeiro de 2024 e abril de 2025

Se liga no que apareceu:

• Testes privados de várias variantes antes do lançamento (a Meta testou 27 variantes antes do Llama 4)
• Google com cerca de 19,2% e OpenAI com cerca de 20,4% dos dados da arena

Não quer dizer que ranking é lixo, beleza?

Quer dizer que ranking público mede a tarefa MÉDIA de um monte de gente, e não a distribuição real das tarefas do seu produto. Pra isso só tem um jeito: medir você mesmo 🙂

O que você precisa antes de começar:

A lista é curta:

• Exemplos reais do produto: logs, tickets de suporte, entradas de usuários, o que tiver
• Chaves de API dos modelos que você quer comparar
• Pra parte com Promptfoo: Node.js ^20.20.0 ou >=22.22.0 se for usar npm/npx. Se preferir, dá pra instalar com brew install promptfoo ou pip install promptfoo

Só isso, nada de PC da Nasa haha

Passo a passo para montar seu benchmark de LLM

A lógica é parecida com teste automatizado de software: se você já escreveu teste unitário, vai se sentir em casa

A diferença é que aqui a "função" testada é um modelo, e a resposta nem sempre é exata

1. Defina o critério de sucesso

A documentação da Anthropic sobre testes diz que um bom critério precisa ser específico, mensurável e alcançável

Mensurável aqui significa ter uma métrica quantitativa ou uma escala qualitativa bem definida

O exemplo deles é ótimo: em vez de "bom desempenho", escreva "classificação de sentimento precisa"

Erro comum deste passo: critério vago. "Responder bem" não dá pra medir, e o que não dá pra medir vira discussão de opinião no time kkk

2. Colete exemplos reais que espelhem a tarefa

A Anthropic recomenda que o eval seja específico da tarefa: ele precisa espelhar a distribuição real do que chega no seu produto e incluir casos de borda

E como descobrir quais são esses casos? Lendo os dados

O Hamel Husain trata a análise de erros (ler traces reais e anotar os problemas que aparecem) como a atividade mais importante dos evals. Abre os logs, lê um por um e anota onde o modelo escorrega

Erro comum deste passo: inventar exemplos idealizados. Usuário real escreve com erro de digitação, manda três perguntas numa mensagem e cola print de tela… seu eval precisa ter isso

3. Monte o golden dataset

Que golden dataset? É um conjunto de entradas confiáveis com as saídas ideais, normalmente rotuladas por humanos (muitas vezes especialistas no domínio), que serve de referência pra medir a qualidade das respostas

Na prática: cada exemplo do passo 2 ganha a resposta que deveria sair

Erro comum deste passo: rotular sem quem entende do assunto. Se o rótulo está errado, o modelo que acertar vai ser marcado como errado. Tome cuidado!

4. Escolha como corrigir

O Hamel defende avaliação binária, passa ou falha, no lugar de notas vagas

A Anthropic complementa: automatize a correção sempre que possível, com múltipla escolha, string match, correção por código ou correção por LLM

E prioriza volume sobre qualidade: mais perguntas com correção automática, mesmo com sinal um pouco menor, valem mais que poucas perguntas corrigidas à mão

Erro comum deste passo: nota de 1 a 10 sem definição. Qual a diferença entre um 6 e um 7? Ninguém sabe, nem você daqui a um mês

5. Crie o projeto no Promptfoo

O Promptfoo é uma ferramenta que roda localmente pra testar apps de LLM e comparar modelos lado a lado (OpenAI, Anthropic, Azure, Bedrock, Ollama e outros)

Pra começar um projeto:

npx promptfoo@latest init

Se quiser partir do exemplo pronto:

npx promptfoo@latest init --example getting-started

Isso gera um promptfooconfig.yaml, que é onde tudo acontece. Ele tem três partes:

• providers: os modelos que você vai testar
• prompts: templates com placeholders no formato {{var}}
• tests: as variáveis de entrada mais os asserts (as checagens)

Um exemplo ilustrativo, classificando tickets de suporte:

prompts:
  - |
    Classifique o ticket abaixo em uma categoria: cobranca, bug ou duvida.
    Responda apenas com a categoria.

    Ticket: {{ticket}}

providers:
  - '<id-do-provider-do-modelo-A>'
  - '<id-do-provider-do-modelo-B>'

tests:
  - vars:
      ticket: 'Fui cobrado duas vezes no cartão este mês'
    assert:
      - type: equals
        value: cobranca
  - vars:
      ticket: 'O app fecha sozinho quando abro o carrinho'
    assert:
      - type: contains
        value: bug
  - vars:
      ticket: 'vcs aceitam pix?? e o boleto vence qdo'
    assert:
      - type: regex
        value: '^(cobranca|bug|duvida)$'

Nos providers, troque os placeholders pelos IDs dos modelos que você quer comparar, conforme a documentação do Promptfoo

Além de equals, contains e regex, tem is-json pra quando a saída precisa ser JSON válido, e também asserts semânticos e corrigidos por modelo pra respostas abertas

Repara no terceiro ticket: é exatamente o tipo de caso de borda que o passo 2 manda incluir 😛

Erro comum deste passo: testar um modelo só. Benchmark sem comparação vira só um número solto

6. Rode o eval e veja os resultados

Dentro da pasta onde está o promptfooconfig.yaml:

npx promptfoo@latest eval

Pra abrir os resultados no visualizador web:

promptfoo view

Aí tu vê, lado a lado, onde cada modelo passou e onde falhou

Erro comum deste passo: comparar lotes diferentes entre modelos. Se o modelo A rodou em 50 tickets e o B em outros 50, a comparação não vale nada. Mesmo lote, mesmo prompt, mesmos asserts

7. Registre o resultado e repita

Guarda o resultado de cada rodada junto com a data, o prompt usado e os modelos comparados

A cada troca de modelo ou mudança de prompt, roda o MESMO lote de novo. É isso que transforma o eval num teste de regressão de verdade, e não numa foto de um dia só

Correção por código, humana ou por LLM: qual usar no seu eval?

A Anthropic compara os três métodos assim:

Método	Vantagem	Limitação	Quando faz sentido
Por código	O mais rápido e confiável	Sem nuance	Saída com formato ou resposta exata (categoria, JSON, número)
Humana	A mais flexível	Lenta e cara, evitar se possível	Montar o golden dataset e validar o juiz automático
Por LLM	Rápida e flexível	Precisa ter a confiabilidade testada antes de escalar	Respostas abertas, como resumo ou atendimento

A ordem de preferência que sai disso é simples: código sempre que der, LLM quando a resposta for aberta, humano pra criar a referência e conferir o resto

Como usar LLM como juiz sem cair nos vieses?

LLM-as-a-judge é usar um modelo pra corrigir a resposta de outro. Parece gambiarra, mas funciona razoavelmente bem

O paper de Zheng et al. sobre o MT-Bench encontrou concordância acima de 80% entre o GPT-4 como juiz e avaliadores humanos

Porém o mesmo trabalho documentou três vieses:

• Posição: o juiz favorece uma resposta pela ordem em que ela aparece
• Verbosidade: prefere a resposta mais longa, mesmo que não seja a melhor
• Autopromoção: tende a favorecer as próprias respostas

As mitigações propostas no paper:

• Trocar a ordem das respostas e ver se o veredito se mantém
• Few-shot: mostrar exemplos de correção no prompt do juiz
• Correção guiada por resposta de referência: dar ao juiz a saída ideal pra comparar

E adivinha qual é a resposta de referência? O golden dataset do passo 3, olha que massa 😀

Uma dica antes de escalar: rode o juiz numa amostra que humanos já rotularam e compare os vereditos. Se ele discorda muito, ajusta o prompt do juiz antes de confiar nele pra milhares de casos

Próximo passo: comece com poucos casos reais e cresça

Recapitulando: ranking público mede a tarefa média, o seu eval mede o que importa pro SEU produto

O caminho é: critério específico, exemplos reais com casos de borda, golden dataset rotulado por quem entende, correção passa/falha automatizada e o mesmo lote rodando em todos os modelos

O próximo passo concreto é pequeno: separa alguns exemplos reais dos seus logs, escreve o critério de passa/falha e roda o primeiro lote no Promptfoo

Se o seu produto é um fluxo de automações com agentes de IA, a lógica é a mesma: pega as entradas que chegam de verdade no fluxo e mede cada troca de modelo

Uma nota de contexto: a OpenAI anunciou a aquisição do Promptfoo em 9 de março de 2026, e o projeto informou que continua open source

Depois é só ir crescendo o dataset conforme novos erros aparecem nos logs 🙂

Até o próximo post!

Perguntas frequentes

Qual a diferença entre benchmark de LLM público e um eval interno do meu produto?

O benchmark público mede a tarefa média de milhares de usuários genéricos, em datasets como ARC, GSM8K, HellaSwag ou MMLU. Já o eval interno usa exemplos reais do seu produto e espelha a distribuição real das tarefas, incluindo os casos de borda que só aparecem no seu contexto.

Dá pra confiar no ranking do Chatbot Arena pra escolher modelo?

O paper The Leaderboard Illusion analisou 2 milhões de batalhas do Chatbot Arena entre janeiro de 2024 e abril de 2025 e encontrou testes privados de várias variantes antes do lançamento, como os 27 testes da Meta antes do Llama 4. Google e OpenAI receberam cerca de 19,2% e 20,4% dos dados da arena, o que distorce a posição de quem testa menos.

Vazamento de dados de treino invalida todo o ranking de LLM?

Não exatamente. O estudo de Stanford e da City University of Macau, com 47 modelos em 4 benchmarks, achou correlação de ranking de 0,997 entre o leaderboard padrão e uma versão controlada por paráfrase. Ou seja, a contaminação infla a nota absoluta, mas quase não muda a ordem entre os modelos.

É confiável usar outro LLM como juiz pra corrigir meu benchmark?

Dá, desde que você teste a confiabilidade dele antes de escalar. A Anthropic classifica a correção por LLM como rápida e flexível, mas com essa ressalva. Na prática, rode o juiz numa amostra que humanos já rotularam, compare os vereditos e ajuste o prompt do juiz se ele discordar muito.

Preciso de Node.js pra usar o Promptfoo?

Só se for instalar via npm ou npx, caso em que é preciso Node.js na versão ^20.20.0 ou >=22.22.0. Se preferir outro caminho, também dá pra instalar com brew install promptfoo ou pip install promptfoo.

Quantas perguntas o meu benchmark de LLM precisa ter?

A Anthropic recomenda priorizar volume sobre qualidade: mais perguntas com correção automática, mesmo com sinal um pouco menor, valem mais que poucas perguntas corrigidas à mão por humanos. Por isso vale automatizar a correção com múltipla escolha, string match, código ou LLM sempre que possível.