Evals para Agentes de IA: O Sistema Operacional de Qualidade da Era Agêntica

A maioria das equipes que constrói agentes de IA passa por uma fase previsível. No início, o produto melhora rápido: alguns prompts, algumas ferramentas, um pouco de dogfooding, correções baseadas em exemplos isolados, e o agente começa a parecer útil. Depois vem a fase perigosa. Uma mudança de modelo melhora determinados casos, mas piora outros. Um novo tool-call corrige um fluxo, mas cria latência excessiva. Um prompt mais “proativo” aumenta a taxa de resolução, mas também aumenta o uso indevido de ferramentas. Usuários começam a dizer que o agente “ficou pior”, e a equipe já não consegue distinguir regressão real de ruído estocástico.

Esse é o ponto em que evals deixam de ser um acessório de QA e se tornam infraestrutura central de produto. Sem evals, equipes passam a depurar de forma reativa, esperando reclamações, reproduzindo falhas manualmente e tentando adivinhar se uma mudança de fato melhorou o sistema. Em agentes de IA, esse problema é mais severo do que em aplicações tradicionais porque o comportamento não é apenas probabilístico; ele é também sequencial, instrumental e ambiental. O agente não só responde. Ele planeja, escolhe ferramentas, consulta fontes, altera estado, conversa em múltiplos turnos e pode executar ações com consequências reais.

A tese deste artigo é simples: avaliar agentes de IA é avaliar trajetórias, não apenas respostas. Uma resposta final correta pode esconder uma trajetória insegura, cara ou frágil. Uma resposta final incorreta pode decorrer de um erro de recuperação, de uma ferramenta mal especificada, de um roteador ambíguo, de uma política contraditória ou de um ambiente de teste mal controlado. Por isso, a disciplina moderna de evals precisa combinar testes determinísticos, juízes baseados em modelos, revisão humana, observabilidade, macro-evals, CI/CD, segurança e governança.

Por que agentes quebram a lógica tradicional de testes

Em software clássico, testes unitários e de integração funcionam porque a relação entre entrada, execução e saída costuma ser determinística. Em LLMs single-turn, a avaliação já se torna mais difícil porque a mesma pergunta pode receber múltiplas respostas válidas. Em agentes, a dificuldade cresce novamente: o mesmo objetivo pode ser alcançado por caminhos diferentes, com ferramentas diferentes, números diferentes de passos e graus diferentes de risco.

Um agente de suporte, por exemplo, pode resolver um reembolso em quatro turnos ou em dez. Pode verificar identidade antes ou depois de consultar a política. Pode usar a ferramenta certa com parâmetros errados. Pode dizer ao usuário que o reembolso foi processado, embora o banco de dados não tenha sido atualizado. Pode seguir uma instrução maliciosa escondida em um e-mail ou documento recuperado. A resposta final, sozinha, não captura esses modos de falha.

Os Três Pilares de Graders: Código, Modelo e Humanos

Dividimos graders de agentes em três famílias: code-based, model-based e human graders. A escolha correta depende do que se quer medir. Um erro comum é tentar resolver tudo com LLM-as-a-judge. Outro erro é tentar resolver tudo com verificações determinísticas. O primeiro gera custo, subjetividade e risco de viés. O segundo é barato e reprodutível, mas frequentemente frágil para tarefas abertas.

• Code-based: Barato, rápido, objetivo, reprodutível e fácil de depurar. Excelente para testes unitários, validação de JSON, estado de banco e schemas.
• Model-based: Flexível, escalável e capaz de avaliar nuance em linguagem natural. Ótimo para qualidade de síntese, tom, coerência e aderência a rubricas.
• Human-based: Padrão-ouro para julgamento especializado e subjetivo. Essencial para calibração de LLM judges e auditoria de alto risco.

Capability Evals vs. Regression Evals

Dois tipos de evals têm objetivos diferentes. Capability evals perguntam: “O que este agente consegue fazer bem?”. Elas devem conter tarefas difíceis, muitas vezes com baixa taxa inicial de aprovação, porque servem para criar uma colina de melhoria. Regression evals perguntam: “O agente ainda faz o que já fazia?”. Elas devem ter taxa de aprovação próxima de 100%, porque sua função é detectar retrocessos (backsliding).

Com o tempo, capability evals podem “graduar” para regression evals. Quando uma capacidade deixa de ser experimental e passa a ser esperada, ela deve entrar no cinturão de segurança do produto. O inverso também é verdadeiro: quando uma suite satura, deixa de oferecer sinal de melhoria. Uma avaliação com 100% de aprovação pode ser excelente como regressão, mas é inútil para comparar avanços de fronteira.