Avaliar a IA com uma planilha de 20 a 50 tarefas reais

Uma planilha com 20 a 50 tarefas tiradas de falhas reais, cada uma rodada mais de uma vez e corrigida por código, por uma pessoa ou por um modelo julgador calibrado, decide se um sistema com IA sobe para produção. Serve a quem aprova prompt, agente ou troca de modelo. Monte hoje as cinco primeiras linhas.

A demonstração do fornecedor mostra o caso que funciona. A operação quebra no caso que já quebrou uma vez: o sinistro com três coberturas, o cliente que escreve tudo em maiúsculas, o contrato com aditivo. Sem uma bateria fixa de provas, ninguém sabe se a troca de modelo do mês passado melhorou ou piorou o atendimento, e a reunião vira disputa de gosto.

Avaliação, ou eval no jargão, é essa bateria de provas que o sistema refaz a cada mudança, como o check-list do piloto antes de cada decolagem. Em 2026 ela cabe numa planilha e num ciclo de duas a quatro semanas.

O que mudou na forma de avaliar

A Anthropic publicou em 09/01/2026 o guia Demystifying evals for AI agents com uma receita curta: comece com 20 a 50 tarefas simples tiradas de falhas reais, corrija o estado final em vez do caminho percorrido e leia as transcrições (transcripts), o registro de tudo o que o modelo fez, como a caixa-preta de um avião. A leitura mostra se errou o modelo ou o avaliador que rejeitou uma solução válida.

Hamel Husain e Shreya Shankar, no guia de perguntas sobre evals revisto em 21/09/2026, põem a análise de erros (error analysis) antes de qualquer métrica: anotar à mão ao menos 30 transcrições, agrupar as anotações numa lista de tipos de falha e só então escrever os testes. Em 2024 o comum era adotar métricas genéricas de prateleira; hoje a suíte nasce dos defeitos da sua operação, e cada tipo de falha ganha rótulo binário, passa ou falha, no lugar da nota de 1 a 5.

A contagem também mudou. Pass@k pergunta se ao menos uma de k tentativas acertou; pass^k pergunta se todas acertaram, conta que a Sierra usou no τ-bench, em 2024, para medir consistência. Segundo a Anthropic, um sistema com 75% de acerto por tentativa fica em cerca de 42% de pass^3. Se o erro chega ao cliente sem revisão, exija pass^k; se um analista escolhe entre três rascunhos, pass@k basta.

Como a planilha fica

Cada linha é uma tentativa de uma tarefa. O critério é escrito antes da primeira execução, em forma de passa ou falha, para que nenhuma saída plausível seja aceita depois do fato. A coluna de erro recebe o nome de um tipo de falha da lista, o que permite contar, ciclo a ciclo, qual defeito diminuiu. Toda falha nova de produção vira linha nova, com a data em que entrou.

Quando o juiz é outro modelo

Modelo julgador (LLM-as-judge) é um segundo modelo que corrige a saída do primeiro, como o revisor que confere a prova com o gabarito. Ele cobre o que código não confere: tom, aderência à oferta, fidelidade a um contrato. A Anthropic pede um juiz isolado por dimensão, calibração contra especialistas humanos e uma opção Unknown (indeterminado) para quando o material não permite decidir, o que reduz o veredito inventado.

Husain e Shankar tratam o juiz como classificador de passa ou falha, medido dos dois lados: quantas falhas reais ele pega (TPR, taxa de verdadeiros positivos) e quantos acertos ele aprova (TNR, taxa de verdadeiros negativos). Para medir, separe de 100 a 200 exemplos rotulados por tipo de falha e leia cada desacordo antes de mexer no prompt do juiz.

Os vieses do juiz têm nome desde o MT-Bench (Zheng e coautores, 2023): posição, quando ele prefere a resposta mostrada primeiro; verbosidade, quando prefere a mais longa; autopreferência, quando favorece texto do próprio modelo. Um estudo de abril de 2026 achou preferência por respostas longas na maioria dos juízes testados, e o Claude Sonnet 4 foi o único a preferir concisão.

Onde rodar a suíte

Três ferramentas cobrem a maior parte dos casos em 2026. O promptfoo é uma linha de comando de código aberto, com testes escritos em YAML (um arquivo de configuração em texto simples), que roda no computador ou na integração contínua (a esteira que testa cada mudança antes de publicar) contra qualquer provedor. O Braintrust é uma plataforma hospedada que junta rastreio da produção (o registro de cada chamada real), avaliação e bloqueio de publicação quando a nota cai. O OpenAI Evals, em Python, integra os modelos da OpenAI e aceita correção por modelo. Em qualquer uma delas, a planilha é o desenho e a ferramenta só automatiza a rodada.

Três usos fora do marketing

O mesmo ciclo vale para qualquer saída que alguém aprova. Nos casos ilustrativos abaixo, a conta e o tipo de avaliador mudam conforme o risco do fluxo.

Montar o juiz de copy com rubrica binária

Texto publicitário é onde a equipe mais confia no gosto e menos mede. O guia usa um anúncio fictício de uma escola de idiomas; o prompt roda igual em Claude, GPT, Gemini ou Grok, e só o parâmetro de saída estruturada muda de nome em cada API.

Por que essa saída serve

O juiz reprovou três dimensões com o trecho literal ao lado, e qualquer pessoa confere cada veredito em segundos. A imagem ausente virou INDETERMINADO e foi para revisão humana, sem palpite. Na OpenAI o mesmo esquema entra em text.format com strict ligado, e no Gemini e no Grok, em response_format.

A conta errada aprova o fluxo errado

A pergunta que mais aparece na mesa de aprovação é qual número o fornecedor mostrou. O caso abaixo é fictício e mostra como a mesma bateria muda de leitura conforme a conta.

Faça hoje

Abra uma planilha com as cinco colunas do modelo, puxe as cinco falhas mais recentes do fluxo de maior consequência e escreva, para cada uma, a entrada exata e o critério de passa ou falha. Rode cada tarefa três vezes, em cerca de 40 minutos. Deu certo quando a aba de resumo mostra acerto por tentativa e pass^3 com o denominador ao lado, e cada linha reprovada tem um tipo de falha na coluna de erro.