Avaliar um agente de IA exige verificar se ele cumpre objetivos claros ao longo de toda a execução — não apenas se a resposta final parece convincente. Para criar um processo repetível, transforme tarefas reais em critérios, teste caminhos e exceções, compare execuções em condições estáveis e leve as falhas observadas de volta aos testes.
Como montar uma avaliação repetível
O fluxo proposto pelo Google parte de uma jornada crítica do usuário e avança por cenários, revisão de traces, verificações automatizadas e controles de regressão. O Google publicou essa orientação em 15 de outubro de 2026; trata-se de uma proposta de processo, não de um resultado medido de desempenho. A sequência completa está no guia do Google.
1. Defina o sucesso pela jornada do usuário
Escolha uma tarefa concreta e descreva quem a executa, qual objetivo precisa alcançar, quais restrições se aplicam e como o resultado será verificado. O Google chama esse conjunto de jornada crítica do usuário. Cada condição vira um ponto de avaliação: em uma tarefa de análise, por exemplo, a equipe pode verificar se o agente identifica uma transação contestada e confere os dados necessários antes de redigir uma resposta.
Esse recorte impede que uma resposta bem escrita esconda uma etapa incorreta. Se o agente precisa consultar uma ferramenta, a avaliação deve considerar também se ele a acionou e usou o retorno de forma adequada.
2. Crie cenários e examine os traces
Monte cenários de caminho esperado e casos extremos, como uma solicitação incompleta, uma informação ausente ou uma conversa em várias etapas. Usuários simulados permitem começar antes de haver traces de produção; depois, casos reais podem ampliar a cobertura. O Google recomenda inspecionar manualmente os registros da execução — prompts, etapas intermediárias, argumentos enviados às ferramentas e saídas — e transformar padrões de falha em verificações repetíveis.
Um trace é o registro encadeado das etapas percorridas pelo agente. Ele ajuda a localizar onde a execução saiu do esperado, em vez de atribuir toda falha à resposta final. Comece pela revisão manual e automatize os problemas recorrentes que ela revelar.
3. Controle a variação entre execuções
Uma única tentativa pode não representar o comportamento de um agente cujas trajetórias variam. A Braintrust recomenda repetir cada tarefa e estabilizar dependências externas com serviços simulados (stubs) ou dados congelados em snapshots. Assim, mudanças em uma API ou base de dados não se confundem tão facilmente com mudanças no agente. O guia também descreve ambientes isolados e injeção de falhas — por exemplo, timeouts e respostas malformadas — para exercitar a recuperação. Essas são recomendações da Braintrust; o guia não define um número universal de tentativas.
Na prática, compare as execuções com os mesmos casos e condições controladas. Se o agente ou uma dependência mudou ao mesmo tempo, fica mais difícil identificar o que provocou a diferença.
4. Combine verificações e calibre o juiz LLM
O Google agrupa as verificações em quatro categorias: testes unitários, métricas determinísticas, rubricas avaliadas por um modelo de linguagem e testes de integração. Elas respondem a perguntas diferentes. Um teste unitário pode conferir uma função específica; uma métrica determinística verifica uma condição objetiva; um juiz LLM avalia critérios expressos em uma rubrica; e um teste de integração examina o comportamento de componentes em conjunto. Compare as avaliações automatizadas com traces revisados por pessoas.
A IBM Technology explica duas formas de usar um juiz LLM: avaliar cada resposta com uma rubrica ou comparar duas respostas entre si. A apresentadora Zahra Ashktorab também descreve vieses de posição, verbosidade e autoaperfeiçoamento. Para investigar o primeiro, inverta a ordem das respostas candidatas e veja se o julgamento muda. Esse teste examina o viés de posição; não avalia, por si só, os outros dois.
5. Mantenha a referência estável e bloqueie regressões
Durante uma comparação, mantenha fixo o conjunto de testes de referência e altere uma variável por vez. Se a lista de casos muda junto com o agente, uma pontuação diferente pode refletir a mudança na cobertura, não uma mudança de comportamento.
O Google recomenda combinar uma meta geral de aprovação com a ausência de regressões em métricas centrais que já passavam. Também sugere acompanhar medidas operacionais, como latência, uso de tokens, custo de API e quantidade de chamadas a ferramentas, além da qualidade das respostas. Um resultado agregado sozinho não explica onde ocorreu uma falha.
O Google afirma que a abordagem descrita padroniza traces de OpenTelemetry com convenções OpenInference e dá suporte a Google ADK, LangGraph e ambientes próprios. Essa integração pode ser útil para equipes que trabalham com diferentes estruturas de agentes; é uma capacidade descrita pelos autores do toolkit.
6. Transforme divergências em casos de regressão
Quando um revisor humano e o avaliador automatizado discordarem, registre a decisão e a versão da regra aplicada, esclareça o critério e acrescente casos contrastantes ao conjunto de regressão. Participantes de uma discussão na comunidade de agentes de IA propuseram esse caminho como prática de trabalho; não é um padrão formal da indústria. A discussão reúne essas sugestões.
7. Use observações da produção para atualizar os testes
A avaliação também pode acompanhar interações reais. A Microsoft descreve um ciclo em que observações da produção ajudam a atualizar os dados e casos usados na avaliação offline. O Google recomenda incorporar ao conjunto de referência os casos extremos encontrados em produção. Assim, situações que escaparam dos cenários iniciais podem passar a fazer parte das próximas verificações. A Microsoft descreve esse ciclo de avaliação.
