O que é O que é um eval?
O que é um eval (What an eval is) é um fundamento de engenharia de IA para quem trabalha com LLMs. Testes para sistemas que não respondem sempre igual, do caso unitário ao benchmark.
Conteúdo da trilha
Capítulos
Transcrição
Abertura
O time de back office tem um extrator de notas que funciona bem. Um dia, alguém repara que o prompt diz: extraia o valor total. E muda para: extraia o valor total, com duas casas decimais.
Parece inofensivo. O deploy sai numa sexta-feira.
Na segunda, o financeiro reclama. Notas com desconto estão entrando pelo valor bruto. Uma mudança de uma frase alterou o jeito de o modelo ler o campo. E ninguém tinha como saber antes, porque o único teste era abrir três arquivos e olhar.
Com código comum, você teria um teste unitário. Com um modelo, a mesma entrada pode gerar respostas diferentes, e certo nem sempre é igual. O teste feito para esse mundo se chama eval. Nesta primeira aula da trilha de evals e confiabilidade, você vai aprender do que ele é feito, como dar nota, e como ler os números sem se enganar.
A ideia
Um eval é um teste para a saída do modelo. Ele tem três partes.
Um conjunto de casos. Entradas, cada uma com o resultado esperado.
Um jeito de rodar o sistema em todos eles.
E uma regra de nota, que transforma cada saída num placar.
Como funciona
Os casos vêm de dados reais, anonimizados, com a resposta esperada rotulada.
O sistema inteiro roda, com o mesmo prompt, modelo e ferramentas da produção.
Cada caso gera uma saída, guardada junto com a versão do prompt.
A nota compara a saída com o resultado esperado.
Cada caso recebe um placar. Passou ou falhou, ou um valor de zero a um.
E o relatório mostra a taxa geral, a taxa por categoria e a diferença para a versão anterior.
Os três arquivos de sexta falharam no passo um e no passo seis. Três exemplos no olho não são um conjunto. E olhar não é regra de nota. Na segunda, o time descobriu um tipo de nota, com desconto, que não estava entre os três.
Três jeitos de dar nota
São três jeitos de dar nota. Comparação exata. O código compara campo a campo, ou confere se a saída cabe num schema. Use quando existe resposta certa, como numa classificação, numa extração ou numa consulta ao banco. No extrator de notas, o total é comparado exatamente com o número rotulado.
Uma regra no código. Funções conferem propriedades. Tem citação, fica abaixo de cem palavras, nunca cita concorrente. Use quando o texto varia, mas existem critérios objetivos.
E um modelo como juiz. Outro modelo dá nota à saída, com uma rubrica escrita. Use para qualidade aberta. Tom, utilidade.
A regra é começar pelo mais simples que resolve. Comparação exata é barata, rápida e nunca erra. Um juiz custa dinheiro, e também precisa ser avaliado. Ele herda a variação do modelo, e pode concordar com o erro.
Aqui está um caso em que isso importa. Um eval de tom de e-mails usava só um modelo como juiz. E o juiz aprovava e-mails que prometiam um desconto que a loja não oferece. Um juiz maior não resolveria. Ele ainda pode achar a promessa útil. Coloque regras no código primeiro. Não inventar preço, não citar concorrente. Depois use o juiz no que sobra.
Um desafio
Uma pergunta para você. O extrator acerta quarenta e oito de cinquenta casos. Os dois erros são notas com desconto, as únicas duas desse tipo no conjunto. O time comemora 96%. O que esse número esconde?
Ele esconde a taxa por categoria. No tipo de nota que o financeiro mais teme, a taxa é zero de dois. O número geral diluiu justamente o caso que quebra o sistema contábil.
E chamar de ruído não ajuda. Pode ser ruído no geral, e ainda é 100% de falha nos descontos. Você precisa de mais casos desses, não de um tapinha nas costas. Preencha essa fatia, corrija, e só então olhe o número geral.
De onde vêm os casos
Existem três tamanhos de eval. O caso unitário. Um bug visto em produção vira um caso. É o equivalente a um teste de regressão.
O dataset de eval. De cinquenta a algumas centenas de casos, cobrindo as categorias do seu produto. Ele roda a cada mudança.
E o benchmark público. Conjuntos conhecidos que medem modelos em geral. Eles ajudam a escolher um modelo candidato. Não dizem se o seu sistema funciona. Se o produto quer trocar de modelo porque um benchmark público subiu dois pontos, e o seu eval interno caiu um ponto, o seu eval vence. Você não entrega um benchmark. Você entrega o seu classificador.
E aqui está a armadilha de quem começa. Tratar o dataset como uma lista morta. Os melhores casos nascem em produção. A nota que o financeiro devolveu. O ticket que o classificador mandou para o time errado. Cada incidente vira mais uma linha no arquivo. Seis meses depois, esse arquivo vale mais que o prompt. Um prompt você reescreve numa tarde. Um bom dataset leva meses para juntar.
Lendo os números
Como a saída varia, uma rodada só pode enganar. Para casos importantes, rode de três a cinco vezes e olhe a taxa de acerto, não o resultado de uma rodada.
Uma queda de 92 para 90% em cinquenta casos é um caso só. Pode ser ruído.
E cinquenta casos típicos não cobrem uma categoria rara. Se as notas com desconto são 5% do volume, e você pegou vinte arquivos do topo da pasta, esse tipo pode nunca entrar. Estratifique. Inclua um pouco de cada categoria que o negócio teme, não só o que aparece primeiro.
Experimente
Na página tem um eval que roda em poucos segundos. Cinco mensagens de clientes, cada uma rotulada como cobrança, pedido ou outro.
O modelo classifica cada uma, e o código conta quantas batem exatamente com o rótulo.
Agora mude o prompt para: responda com a categoria e uma justificativa curta. Rode de novo, e os cinco falham, mesmo com a categoria certa no começo da frase.
Isso não é o modelo piorando. A sua nota está presa ao formato antigo. O eval e o prompt são o mesmo contrato. Se a saída ganha um motivo, a nota lê o campo de categoria, não a frase. É exatamente isso. Um eval transforma acho que melhorou num número, e mostra na hora o que uma mudança quebrou.
Em produção
Então, o que muda? Nenhuma mudança de prompt, de modelo ou de ferramenta sai sem rodar o eval antes.
Testar cinco perguntas na mão antes de um deploy não é eval. Isso é um smell chamado vibe check eval.
E o eval precisa rodar sozinho, no seu pipeline, ou com um comando só. Esse padrão se chama eval harness.
Um último caso. O seu pipeline roda oitenta casos a cada pull request. Alguém ainda testou mais quatro perguntas num chat na sexta, e publicou. O pipeline passou. O financeiro reclamou mesmo assim. Onde vazou? Naquelas quatro perguntas. Se eram diferentes dos oitenta, deviam ter virado casos antes do merge. Se não eram, o chat só trouxe falsa confiança.
Fechamento
Então, a ideia para levar. Um eval é como você para de adivinhar. Casos reais com a resposta certa, o sistema de verdade rodando neles, e uma nota que não depende do humor de ninguém. Leia por categoria, rode a cada mudança e alimente com cada incidente.
Na próxima aula, vamos ver o que acontece quando um time não tem eval: o untested prompt. Até lá.
O que é um eval
What an eval is
O que é um eval (What an eval is) é um fundamento de engenharia de IA para quem trabalha com LLMs. Testes para sistemas que não respondem sempre igual, do caso unitário ao benchmark.
- Elemento
- 10/13
- Nível
- Iniciante
- Leitura
- 4 min
- Atualizado
A situação
O time de backoffice tem um extrator de notas fiscais que funciona bem. Alguém percebe que o prompt diz “extraia o valor total” e muda para “extraia o valor total, com duas casas decimais”. Parece inofensivo. O deploy sai numa sexta.
Na segunda, o financeiro reclama: notas com desconto estão entrando com o valor bruto. A mudança de uma frase alterou como o modelo lia o campo, e ninguém tinha como saber antes, porque o único teste era abrir três PDFs e olhar.
Com código comum você teria um teste unitário. Com um modelo, a mesma entrada pode gerar respostas diferentes, e “certo” nem sempre é uma igualdade exata. O teste que serve para esse mundo se chama eval.
O conceito
Um eval é um teste para saída de modelo. Ele tem três partes: um conjunto de casos (entradas com o resultado esperado), uma forma de rodar o sistema em todos eles, e uma regra de correção que transforma cada saída em nota.
flowchart LR
D[("1. Casos de teste")]:::store --> R["2. Rodar o sistema"]:::tool
R --> S(["3. Saída do modelo"]):::llm
S --> G{"4. Corrigir"}
G --> N["5. Nota por caso"]:::tool
N --> A(["6. Relatório e comparação"]):::io
- Os casos vêm de dados reais, anonimizados, com a resposta esperada anotada.
- O sistema roda inteiro, com o mesmo prompt, modelo e ferramentas de produção.
- Cada caso gera uma saída, que é guardada junto com a versão do prompt.
- A correção compara a saída com o esperado.
- Cada caso recebe uma nota: passou ou falhou, ou uma pontuação de 0 a 1.
- O relatório mostra a taxa geral, a taxa por categoria e a diferença para a versão anterior.
A sexta-feira das três PDFs falhou no item 1 e no item 6. Três exemplos no olho não são um conjunto, e “olhar” não é uma regra de correção. Na segunda, o time descobriu um tipo de nota (com desconto) que não estava nos três.
Três jeitos de corrigir
| Tipo | Como funciona | Use quando |
|---|---|---|
| Comparação exata | Código compara campo a campo, ou checa se a saída bate com um schema | A saída tem resposta certa: classificação, extração, SQL |
| Regra em código | Funções checam propriedades: tem citação, não passa de 100 palavras, não cita concorrente | O texto varia, mas há critérios objetivos |
| LLM como Juiz | Outro modelo dá nota com uma rubrica escrita | Qualidade de texto aberto, tom, utilidade |
Comece sempre pelo tipo mais à esquerda que resolve. Comparação exata é barata, rápida e não erra. O juiz custa dinheiro e precisa ser avaliado também.
No extrator de NF-e, valor_total é comparação exata contra o número anotado. “O e-mail de cobrança está educado?” não tem igualdade. Aí entra regra (não passa de N palavras, contém o vencimento) e, se ainda faltar, um juiz com rubrica. Não comece pelo juiz: ele herda a variação do modelo e pode concordar com o erro.
Do caso unitário ao benchmark
- Caso unitário. Um bug que apareceu em produção vira um caso. É o equivalente a um teste de regressão.
- Dataset de eval. De 50 a algumas centenas de casos que cobrem as categorias do seu produto. É o que roda a cada mudança. O padrão que cuida disso é o Dataset de Ouro.
- Benchmark público. Conjuntos famosos que medem modelos em geral. Servem para escolher um modelo candidato, não para dizer se o seu sistema funciona.
A nota de um benchmark público não substitui os seus casos. Um modelo que brilha em matemática ainda pode errar o campo de desconto da sua NF-e. Os casos que importam são os do seu produto, com o seu schema, no seu idioma.
A armadilha de quem começa é tratar o dataset como uma lista morta. Os melhores casos nascem de produção: a nota que o financeiro devolveu, o ticket que o classificador mandou para o time errado. Cada incidente vira uma linha no arquivo. Daqui a seis meses, esse arquivo vale mais que o prompt.
Por que rodar mais de uma vez
Como a saída varia, uma única execução pode enganar. Para casos importantes, rode 3 a 5 vezes e olhe a taxa de acerto, não o resultado de uma rodada. Uma queda de 92% para 90% em 50 casos é um caso só, e pode ser ruído.
Cinquenta casos também não cobrem uma categoria rara. Se notas com desconto são 5% do volume e você sorteou 20 PDFs “típicas”, o tipo pode nem entrar. Estratifique: um pouco de cada categoria que o negócio teme, não só o que aparece primeiro na pasta.
Experimente
Este eval de classificação roda em poucos segundos. Ele usa o SDK da Anthropic (pip install anthropic e a variável ANTHROPIC_API_KEY).
import anthropic
client = anthropic.Anthropic()
PROMPT = "Classifique a mensagem do cliente em uma palavra: fatura, pedido ou outro."
CASES = [
("Quero a segunda via do boleto de setembro", "fatura"),
("Meu pedido 4521 ainda não chegou", "pedido"),
("Fui cobrado duas vezes no cartão", "fatura"),
("Vocês abrem no feriado?", "outro"),
("Quero trocar o tamanho da camiseta", "pedido"),
]
def classify(message: str) -> str:
reply = client.messages.create(
model="claude-haiku-4-5",
max_tokens=20,
system=PROMPT,
messages=[{"role": "user", "content": message}],
)
return reply.content[0].text.strip().lower().rstrip(".")
passed = 0
for message, expected in CASES:
got = classify(message)
ok = got == expected
passed += ok
print(f"{'ok ' if ok else 'FAIL'} {expected:7} {got:10} {message}")
print(f"\n{passed}/{len(CASES)} casos passaram")Agora mude o prompt para “Responda com a categoria e uma justificativa” e rode de novo. A comparação exata vai falhar, e você vai ver na hora o que a mudança quebrou. É esse o ponto: o eval transforma “acho que melhorou” em um número.
Cinco casos servem para sentir o mecanismo. Não servem para publicar. O dataset de verdade começa quando cada categoria tem exemplos, inclusive os chatos: boleto de pedido, cobrança duplicada, mensagem em maiúsculas, ticket com CPF já mascarado.
O que isso muda
- Nenhuma mudança de prompt, modelo ou ferramenta sai sem rodar o eval antes. Esse é o smell Prompt Sem Eval e a refatoração Criar Eval Antes de Mexer no Prompt.
- Testar cinco perguntas na mão antes do deploy não é eval. É o smell Eval no Olhômetro.
- O eval precisa rodar sozinho, na CI ou num comando só. O padrão é a Bancada de Evals.
- Cada padrão deste catálogo tem uma seção “Como avaliar”. Ela diz qual métrica olhar e como montar o primeiro caso.
- Os casos de eval são o ativo mais valioso de um sistema com IA. O prompt você reescreve numa tarde; um dataset bom leva meses de produção para juntar.
Teste seu entendimento
Checagem da aula
Responda as 6 perguntas para concluir a aula. Só assistir não conclui: a checagem é o que conta para a trilha e para o certificado.
Perguntas rápidas
Para ir além
Relações
- Aparece nas trilhas 1