Guia
O que são evals de IA e como avaliar um agente
Invisible Work9 min de leitura
Em uma frase
O que é um eval, em termos simples
Um eval é um teste para um sistema de IA: você dá uma entrada e aplica uma lógica de correção à saída para medir se ele acertou.
Parece um teste automatizado de software, e a ideia é a mesma. A diferença é que um agente de IA age em vários passos, usa ferramentas e altera o estado do sistema, então um erro no meio do caminho se propaga. E a saída varia de uma execução para a outra, por isso cada tarefa costuma ser rodada mais de uma vez.
A Anthropic usa seis palavras para falar disso, e vale conhecê-las porque aparecem em qualquer conversa sobre o assunto:
Tarefa
Um teste com entrada definida e critério de sucesso. Cada vez que o agente tenta a tarefa é uma tentativa (trial).
Avaliador (grader)
A lógica que dá nota a algum aspecto do desempenho. Uma tarefa pode ter vários avaliadores.
Transcript
O registro completo da tentativa: respostas, chamadas de ferramenta, raciocínio e resultados intermediários.
Resultado (outcome)
O estado final do ambiente. Um agente de reservas pode dizer “sua passagem foi reservada”, mas o resultado é se a reserva existe no banco de dados.
Harness de avaliação
A infraestrutura que roda os evals de ponta a ponta: dá instruções e ferramentas, roda as tarefas, registra tudo, avalia e soma os resultados. Não é o mesmo harness do agente.
Suíte
Um conjunto de tarefas que mede uma capacidade ou comportamento. Por exemplo, uma suíte de suporte pode testar reembolsos, cancelamentos e escalonamentos.
Dois harness
Por que sem eval você anda às cegas
No começo, dá para ir longe com teste manual e intuição. O ponto de ruptura, segundo a Anthropic, costuma ser quando usuários dizem que o agente “ficou pior” depois de uma mudança e o time não tem como verificar, a não ser tentando e adivinhando. Sem eval, a depuração é reativa: espera a reclamação, reproduz à mão, corrige e torce para que nada mais tenha quebrado.
Com eval, as mudanças ficam visíveis antes de chegar ao usuário. A Anthropic cita também um efeito menos óbvio: quando sai um modelo novo, quem tem evals descobre em dias o que ele faz bem e ajusta, enquanto quem não tem passa semanas testando. E o custo aparece logo, enquanto o benefício se acumula depois.
Três tipos de avaliador
Os avaliadores se dividem em três famílias, e a maioria dos evals combina mais de uma.
De código
Comparação de texto, testes que passam ou falham, análise estática, verificação do estado final. São rápidos, baratos, objetivos e reproduzíveis, mas frágeis diante de variações válidas e limitados para tarefas subjetivas.
De modelo (LLM como juiz)
Notas por critérios escritos, comparação entre respostas, vários juízes. São flexíveis e lidam com resposta aberta, mas não são determinísticos, custam mais e precisam ser calibrados com pessoas.
Humanos
Revisão por especialistas, amostragem, testes A/B. É o padrão-ouro de qualidade e serve para calibrar os avaliadores de modelo, mas é caro, lento e exige acesso a especialistas.
A recomendação da Anthropic é usar avaliadores determinísticos sempre que der, de modelo quando for preciso e humanos com critério. Há dois cuidados que evitam erros comuns: avaliar o que o agente produziu, e não o caminho que seguiu, porque ele costuma achar caminhos válidos que o autor do teste não previu; e dar nota parcial, porque um agente que identifica o problema e verifica o cliente, mas falha no reembolso, é melhor do que um que falha logo de início.
Capacidade e regressão: duas perguntas diferentes
Os evals de capacidade perguntam “o que este agente faz bem?” e devem começar com taxa de acerto baixa, como uma colina para subir. Os de regressão perguntam “ele ainda faz tudo o que fazia?” e devem ficar perto de 100%: se a nota cai, algo quebrou. Quando um eval de capacidade chega a taxas altas, ele se “gradua” e passa a proteger contra regressão. Um eval a 100% não mostra mais progresso, só vigia.
Rodar uma vez não basta: pass@k e pass^k
Como a saída varia, uma única tentativa diz pouco. Duas métricas resumem o comportamento em várias. A pass@k mede a chance de pelo menos uma tentativa, entre k, dar certo. A pass^k mede a chance de todas as k darem certo. Elas partem do mesmo valor em k = 1 e se afastam a cada tentativa.
A escolha depende do produto. Para uma ferramenta em que basta uma solução funcionar, pass@k. Para um agente que atende clientes, em que a pessoa espera o mesmo comportamento sempre, pass^k, porque ela mostra a consistência que o usuário sente.
Como começar: poucas tarefas, tiradas de falhas reais
Muitos times adiam o eval porque acham que precisam de centenas de tarefas. A Anthropic diz o contrário: de 20 a 50 tarefas simples, tiradas de falhas reais, já são um bom começo. Quanto mais se espera, mais difícil fica, porque se acaba deduzindo o critério de sucesso de um sistema que já está no ar.
Comece pelo que você já testa à mão
Os comportamentos que você confere antes de cada entrega, e o que aparece no suporte e nos relatos de erro, viram as primeiras tarefas.
Escreva tarefas sem ambiguidade
Uma boa tarefa é aquela em que dois especialistas chegariam, sozinhos, ao mesmo veredito. Tenha uma solução de referência que passe em todos os avaliadores, para provar que a tarefa tem solução.
Teste os dois lados
Casos em que o comportamento deve ocorrer e casos em que não deve. Se só testar quando o agente deve buscar, você acaba com um agente que busca para tudo.
Leia os transcripts
É o que mostra se uma falha foi erro do agente ou um avaliador rejeitando uma resposta válida. As falhas devem parecer justas.
Fique de olho na saturação
Quando o agente passa em tudo que tem solução, o eval deixa de medir melhora e é hora de acrescentar tarefas mais difíceis.
Quando o problema é o eval, e não o agente
Nossa leitura: o eval é onde o conhecimento da operação vira critério
Esta parte é opinião da Invisible Work, não da fonte. O difícil de um eval não é a infraestrutura, e sim a pergunta que a Anthropic coloca como teste de uma boa tarefa: dois especialistas concordariam sobre o que é acertar? Em um projeto de IA dentro de uma empresa, quem sabe o que é uma boa resposta é quem conhece a operação, e esse conhecimento é caro de mover para fora dela. É a mesma ideia que desenvolvemos em um Insight sobre o programa de formação da Anthropic.
Em termos práticos, avaliações públicas medem capacidade genérica, e a sua operação tem casos que nenhuma delas cobre. Por isso as tarefas de um bom eval costumam sair dos erros reais do processo, e a pessoa que sabe reconhecê-los precisa estar na sala. É parte do trabalho do engenheiro que trabalha dentro do cliente e uma das frentes que descrevemos em como cada projeto deveria melhorar o próximo.
Perguntas para quem compra ou constrói um sistema de IA
São perguntas nossas, e não um padrão de mercado.
Antes de confiar na nota
- De onde vieram as tarefas? Foram tiradas de casos reais do nosso processo ou são genéricas?
- Quem decide o que é um acerto, e dois especialistas nossos concordariam?
- O que acontece com a nota quando o modelo ou o prompt muda, e quem roda de novo?
- Alguém lê os transcripts, ou só olhamos o número?