Anthropic descreve evals para agentes de IA: três tipos de graders e SWE-bench de 40% a 80%

A Anthropic publicou um guia de engenharia sobre como avaliar agentes de IA, e a ideia central é bem pé no chão: sem evals, depois da primeira ida para produção a equipe passa a consertar uma coisa e quebrar outra. O agente chama ferramentas, altera o estado do ambiente e se ajusta a resultados intermediários ao longo de muitas etapas, então os erros se acumulam. Avaliar um sistema assim exige combinar métodos. Para ilustrar, os autores citam números: no SWE-bench Verified, os modelos foram de 40% para mais de 80% em um único ano, e a Bolt montou um sistema de avaliação funcional em três meses.

Do que é feito o eval de um agente

A Anthropic começa pela terminologia, porque o setor usa os termos de forma inconsistente. Uma tarefa (task) é um teste com dados de entrada e critérios de sucesso. Cada tentativa se chama trial, e elas são executadas várias vezes, já que a saída do modelo muda de uma execução para outra. O grader é a lógica que avalia um aspecto específico do trabalho, e uma mesma tarefa pode ter vários. O transcript é o registro completo da tentativa: mensagens, chamadas de ferramentas, raciocínios. O outcome é o estado final do ambiente.

A diferença entre os dois últimos é fundamental. Um agente de reservas pode escrever "Seu voo foi reservado", mas o que deve contar é apenas a existência do registro no banco SQL. Outro esclarecimento diz respeito ao objeto da medição: ao avaliar um agente, você avalia o conjunto formado pelo modelo e pelo harness, e não o modelo isolado. Como exemplo, os autores citam o caso do Opus 4.5 no teste τ2-bench. O modelo encontrou uma brecha nas regras de reserva de voos e, pelos critérios formais, "reprovou" na tarefa, embora tenha criado para o usuário uma solução melhor.

Três tipos de graders

Os evals de agentes costumam ser montados com três tipos de verificação:

• Graders baseados em código: verificações de string e regex, testes fail-to-pass, análise estática, checagem do estado final e das chamadas de ferramentas. São rápidos, baratos e reproduzíveis, mas frágeis diante de variações corretas da resposta. • Graders baseados em modelos: rubricas, afirmações em linguagem natural, comparação em pares, consenso de vários juízes. São flexíveis e escaláveis, mas não determinísticos, mais caros e exigem calibração com humanos. • Graders humanos: revisão por especialistas, crowdsourcing, amostragem para controle, testes A/B. São o padrão-ouro de qualidade, mas lentos e caros.

A nota final da tarefa pode ser ponderada, binária (todos os graders precisam passar) ou híbrida. A segunda bifurcação é entre capability evals e regression evals. Os primeiros devem começar com pass rate baixo e dar à equipe uma rampa para subir. Os segundos devem passar em quase 100% e detectar regressões. Quando o conjunto de capability se satura, suas tarefas são "graduadas" para o pacote de regressão.

Agentes de código e conversacionais

Para agentes de código, as verificações determinísticas são naturais: o código roda, os testes passam. O SWE-bench Verified entrega ao agente issues do GitHub de repositórios Python populares e só considera a solução correta se os testes que falhavam forem corrigidos e os existentes não forem quebrados. O Terminal-Bench testa tarefas técnicas de ponta a ponta, como compilar o kernel do Linux a partir do código-fonte ou treinar um modelo de ML.

Além dos testes, a Anthropic recomenda avaliar o transcript: heurísticas de qualidade de código e rubricas para o comportamento do agente. No YAML ilustrativo para a tarefa "corrigir o bypass de autenticação", todos os tipos de verificação aparecem juntos, incluindo testes, ruff, mypy, bandit e métricas de número de turnos, tokens e latência. Na prática, ressalvam os autores, bastam testes unitários e uma rubrica de LLM para a qualidade do código.

Os agentes conversacionais (suporte, vendas, coaching) se distinguem porque a qualidade da própria interação faz parte do que se avalia. Nesse caso, usam-se um estado final verificável e rubricas que cobrem tanto a execução da tarefa quanto a qualidade da comunicação.

Por onde começar

Os argumentos da Anthropic a favor dos evals são práticos. No início, eles obrigam a definir o que conta como sucesso: dois engenheiros com a mesma especificação entendem de formas diferentes o comportamento em casos-limite. Depois, fornecem linhas de base de latência, consumo de tokens, custo por tarefa e taxa de erros. Também aceleram a migração para novos modelos: equipes com evals avaliam pontos fortes e fracos em dias, enquanto as demais testam por semanas.

Os exemplos da prática são estes. O Claude Code evoluiu primeiro com base em feedback, depois ganhou evals de concisão e de edição de arquivos e, em seguida, de excesso de complexidade nas soluções. A Descript avalia o agente por três critérios: não quebre nada, faça o que foi pedido, faça bem feito. A equipe passou da verificação manual para graders de LLM com calibração humana periódica. A Bolt começou tarde, quando o agente já estava em uso em massa.

A conclusão prática: não espere por um conjunto perfeito. Pegue as tarefas em que o agente erra hoje e transforme-as em um capability eval. Adicione graders de código sobre o estado final do ambiente. Use um juiz de LLM só para o que o código não consegue verificar e confira-o com avaliações de pessoas. Execute cada tarefa várias vezes e leve para o pacote de regressão as que passam de forma estável.