Dez evals para agentes de IA

Por que a origem dos evals para agentes de IA importa

Praticamente todas as dez práticas que formam o repertório padrão de avaliação de agentes adaptam técnicas antigas. Elas vêm de teste de software, de estatística aplicada e de operação de sistemas em produção.

Essa constatação não diminui o valor das práticas. Ela muda o modo de estudá-las.

Quando uma técnica tem trinta anos de literatura, suas armadilhas já foram catalogadas e, muitas vezes, resolvidas.

Por isso, ignorar essa genealogia significa repetir erros que a engenharia de software documentou muito antes dos modelos de linguagem.

A seguir, percorremos os dez evals para agentes de IA, com a origem e o modo de falha já registrado de cada um.

Golden set

O golden set é um conjunto fixo de casos com saídas esperadas, executado após cada alteração no sistema.

A técnica é o teste de caracterização, descrito por Michael Feathers em Working Effectively with Legacy Code, de 2004. Um teste de caracterização não descreve o comportamento desejado do código; ele registra o comportamento atual e o congela como expectativa.

Feathers observa que a prática também aparece na indústria como pinning test e golden master testing.

A armadilha é estrutural: quem escolhe os casos define implicitamente o alvo de otimização. Em poucas semanas de iteração, o agente de IA passa a acertar exatamente aquele conjunto.

Com isso, a cobertura reportada deixa de medir qualidade e passa a medir a memorização do próprio teste.

A mitigação prática consiste em separar o conjunto em duas partes. Uma parte serve para a iteração diária, enquanto a outra permanece intocada e só aparece em marcos de decisão, como conjunto de validação cega.

Além disso, o golden set precisa de versionamento explícito. Um caso corrigido silenciosamente invalida qualquer comparação histórica entre evals para agentes de IA.

LLM as judge

A prática usa um modelo como avaliador das respostas de outro, a partir do prompt, da resposta e do critério.

O nome se fixou com o artigo Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, de Zheng e colaboradores. Pesquisadores da LMSYS e de Berkeley apresentaram o trabalho no NeurIPS de 2023.

O artigo relata concordância superior a oitenta por cento entre o GPT-4 como juiz e as preferências humanas. Esse patamar equivale à concordância entre os próprios humanos.

No entanto, o mesmo artigo catalogou os vieses que limitam a técnica: posição, verbosidade e auto-preferência.

O viés de posição é o mais direto de verificar. A maioria dos juízes testados favorecia a primeira resposta, e apenas o GPT-4 mantinha resultado consistente em mais de sessenta por cento dos casos com a ordem invertida.

Já o viés de verbosidade faz o avaliador premiar respostas longas, mesmo quando elas não são mais precisas.

Portanto, nota absoluta isolada é instável, enquanto a comparação entre duas respostas é bem mais confiável.

Em qualquer eval de agentes de IA com juiz automático, o teste mínimo de sanidade é repetir a avaliação com a ordem invertida. Se o veredito muda, o número não mede qualidade, mede posicionamento.

Rubric scoring

O rubric scoring decompõe a avaliação em dimensões separadas, cada uma com critério explícito. A herança é a avaliação escolar por rubrica.

Em inteligência artificial, a implementação séria de referência é o HealthBench, publicado pela OpenAI em maio de 2025. O benchmark reúne cinco mil conversas multi-turno, avaliadas por rubricas específicas de cada caso.

Essas rubricas vieram de 262 médicos de 26 especialidades. Ao todo, o conjunto soma 48.562 critérios, cada um com peso proporcional à importância atribuída pelo médico que o redigiu.

Na prática, o ponto central do HealthBench é que o modelo avaliador não atribui nota. Ele apenas responde se a resposta atende ou não atende a cada critério.

Essa decisão explora uma assimetria conhecida. Modelos são pouco confiáveis ao produzir um número em escala contínua, mas razoavelmente confiáveis em um julgamento binário sobre um critério bem redigido.

Segundo a OpenAI, a concordância entre o avaliador automático e os médicos ficou próxima da concordância entre médicos.

Nos evals para agentes de IA, a armadilha do rubric scoring está na agregação. Média simples entre dimensões produz números sem significado operacional.

Afinal, segurança alta não compensa custo alto, e correção alta não compensa violação de política. Por isso, algumas dimensões devem funcionar como condição eliminatória, e não como parcela de uma média.

Trajectory eval

A trajectory eval avalia o caminho percorrido pelo agente, e não apenas a resposta final. O vocabulário vem do aprendizado por reforço, em que trajetória designa a sequência de estados e ações de um episódio.

Dois trabalhos consolidaram a prática: o WebArena, da Carnegie Mellon (julho de 2023), e o τ-bench, da Sierra (junho de 2024).

O WebArena traz 812 tarefas de longo horizonte em ambientes web autocontidos e avalia por correção funcional. Ou seja, verifica se o estado final do ambiente corresponde ao objetivo, aceitando múltiplos caminhos válidos.

No WebArena, o melhor agente baseado em GPT-4 concluía 14,41% das tarefas, contra 78,24% de desempenho humano.

Já o τ-bench acrescentou a dimensão que mais mudou a discussão: consistência. A métrica pass^k mede a fração de tarefas em que o agente acerta em todas as k tentativas independentes.

O resultado original é o argumento mais forte contra a avaliação de tentativa única. Agentes que resolviam mais de sessenta por cento das tarefas de varejo em uma tentativa caíam para cerca de vinte e cinco por cento em pass^8.

A armadilha da trajectory eval é exigir o caminho exato, o que pune soluções corretas e mais eficientes. Portanto, a verificação útil se limita ao que não pode faltar no eval do agente de IA.

Por exemplo, confirmar um dado antes de uma ação destrutiva ou encerrar a busca quando a informação já basta.

Tool unit tests: o eval mais barato para agentes de IA

Aqui a herança é a mais direta de todas: teste unitário convencional aplicado às ferramentas do agente, com o modelo fora do circuito.

A referência específica para chamada de função é o Berkeley Function Calling Leaderboard, do projeto Gorilla, iniciado em 2024. O BFCL introduziu a avaliação por árvore sintática abstrata.

Essa abordagem compara a invocação prevista com a referência de forma determinística. Com isso, evita o custo e a variância de um juiz baseado em modelo.

A evolução do benchmark mostra a maturação da área: a primeira versão trouxe a árvore sintática, e a segunda, funções corporativas e da comunidade. Em seguida, a terceira adicionou interações multi-turno e a quarta passou a avaliar cenários agênticos.

O modo de falha mais comum em produção não é raciocínio insuficiente. Na maioria das vezes, é erro mal descrito.

Uma ferramenta que retorna mensagem genérica, código numérico sem contexto ou stack trace bruto não ajuda o agente a se corrigir. Então, ele repete a chamada com o mesmo parâmetro inválido e esgota o orçamento de passos.

No fim, o agente falha por um motivo que a camada de ferramentas poderia ter comunicado em uma frase. Se você usa o Microsoft Agent Framework, o artigo sobre tools no Microsoft Agent Framework mostra como expor ferramentas ao modelo.

Por isso, trate a mensagem de erro como parte do contrato da ferramenta e teste-a com o mesmo rigor do caminho de sucesso.

Regression suite

Gravar execuções e reproduzi-las depois é prática antiga de teste, conhecida como record and replay. Aplicada aos evals para agentes de IA, porém, ela falha no primeiro ponto em que a nova versão divergir da gravação.

Afinal, a gravação contém as respostas das chamadas antigas, mas não a resposta da chamada nova que a versão atual decidiu fazer.

Daí em diante, o replay não tem o que devolver, e a suíte reporta falha onde pode haver melhoria.

O segundo problema é estatístico. Uma execução por caso não mede mudança de comportamento; mede apenas uma amostra de um processo estocástico.

Comparar uma execução da versão anterior com uma da versão atual produz um delta de variância desconhecida. A correção é executar cada caso várias vezes e comparar distribuições, o que leva de volta à métrica pass^k.

A/B in prod

O A/B in prod é experimentação controlada, com literatura madura. A referência mais citada é Trustworthy Online Controlled Experiments, de Ron Kohavi, Diane Tang e Ya Xu (Cambridge University Press, 2020).

O livro se baseia em organizações que executam mais de vinte mil experimentos por ano.

Um capítulo inteiro trata da unidade de randomização e recomenda o usuário como unidade padrão para audiências online.

A razão é a consistência de experiência. Se a divisão ocorre por requisição, o mesmo usuário alterna entre versões durante uma sessão, o que contamina as métricas e inviabiliza a interpretação causal.

Nos evals para agentes de IA, o risco é maior, porque memória, histórico e estado de conversa atravessam requisições.

A segunda armadilha é a leitura do resultado médio. Um ganho agregado de doze por cento em conversão pode esconder um segmento que piorou de forma significativa.

O livro trata explicitamente de análise por segmentos e do paradoxo de Simpson. Essa recomendação se aplica sem adaptação aos evals para agentes de IA.

Além disso, defina as métricas de guarda, como custo por interação e latência de cauda, antes do experimento, e nunca depois de ver os resultados.

Human review como base dos evals para agentes de IA

A revisão humana de uma amostra de execuções é a prática que calibra todos os demais evals para agentes de IA. O trabalho de referência é Who Validates the Validators, de Shreya Shankar e colaboradores, apresentado no UIST de 2024.

Segundo os autores, avaliadores gerados por modelos herdam os problemas dos modelos que avaliam e, portanto, exigem validação humana explícita.

O artigo propõe o EvalGen, abordagem de iniciativa mista em que o usuário refina critérios e classifica exemplos para alinhar as funções de avaliação.

O achado de maior consequência prática é o limite imposto pela concordância entre revisores. Se dois revisores humanos discordam sobre o mesmo caso, nenhum avaliador automático alcançará concordância maior com ambos.

Quando isso ocorre, o problema está na formulação do critério, e não no modelo avaliador.

Assim, human review não é auditoria periódica, mas o mecanismo permanente de correção do LLM as judge, com amostragem contínua e definida.

Shadow run

O shadow run executa a versão candidata em paralelo à produção, sobre tráfego real, sem entregar as saídas ao usuário.

A prática vem da operação de sistemas e aparece como dark launch, shadow deployment ou traffic mirroring. Hoje, ela costuma ser implementada no nível do service mesh ou do gateway.

Em sistemas convencionais, o espelhamento é seguro porque o tráfego duplicado é somente leitura. Nos evals para agentes de IA, essa garantia não existe por padrão.

Um agente que decide chamar uma ferramenta de escrita vai executar essa escrita. Assim, o efeito colateral é real, mesmo que a resposta ao usuário seja descartada.

Só existe sombra de verdade se a camada de ferramentas registrar a intenção de chamada sem executá-la. Isso exige um modo de execução simulada explícito e auditável.

O ganho principal do shadow run não é comparar textos de resposta. Na verdade, é observar custo por interação, número de passos e latência de cauda sob a distribuição real de entradas.

Essa distribuição nunca coincide com a de um ambiente de homologação. Para acompanhar esses sinais, vale conhecer a observabilidade de agentes e workflows no Microsoft Agent Framework.

Red team nos evals para agentes de IA

Em inteligência artificial, o trabalho que estabeleceu a prática é Red Teaming Language Models to Reduce Harms, de Ganguli e colaboradores. A Anthropic publicou o estudo em 2022, com quase 39 mil ataques adversariais coletados e divulgados.

Já o termo prompt injection foi cunhado por Simon Willison em setembro de 2022. Ele fez uma analogia direta com a injeção de SQL, porque o problema estrutural é o mesmo: concatenar conteúdo confiável e não confiável no mesmo contexto.

Willison distingue explicitamente prompt injection de jailbreak, e essa distinção importa porque muda o vetor a ser testado.

A injeção raramente chega pela mensagem do usuário. Em geral, ela chega pela página que o agente lê, pelo e-mail que ele resume ou pelo documento que ele processa.

Em 2025, Willison sistematizou a condição de risco no que chamou de tríade letal. Ela combina acesso a dados privados, exposição a conteúdo não confiável e capacidade de comunicação externa.

Quando as três condições coexistem, a exfiltração de dados se torna viável. Nenhuma redação de prompt elimina esse vetor, porque o modelo não distingue com segurança instrução legítima de instrução injetada.

Dessa forma, o que limita o dano são as permissões efetivas do agente, ou seja, arquitetura e escopo de ferramentas.

Ordem de adoção dos evals para agentes de IA

A sequência de implantação segue o custo de construção e a dependência entre as práticas. Primeiro, vêm os tool unit tests, porque são determinísticos, baratos e eliminam a classe de falha mais frequente.

Em seguida, entra o golden set, que estabelece a linha de base congelada. Depois, o rubric scoring define os critérios em linguagem verificável antes de qualquer automação de nota.

Só então entra o LLM as judge, que passa a operar sobre critérios já escritos e revisados. A trajectory eval vem logo depois, seguida da regression suite, que depende de gravações e de execução repetida.

O shadow run exige a camada de simulação de ferramentas e, por isso, vem depois. Por fim, o A/B in prod só produz informação útil quando existe volume de tráfego e métricas de negócio instrumentadas.

O human review não ocupa posição na fila. Ele corrige o LLM as judge de forma permanente, do primeiro dia ao último, em todos os evals para agentes de IA.

Conclusão

Em resumo, a leitura genealógica das dez práticas produz três conclusões operacionais. A primeira é que a maior parte do risco nos evals para agentes de IA é risco de engenharia de software conhecido.

A segunda é que as métricas mais citadas são as menos confiáveis quando aparecem isoladas. Nota única de juiz automático sobre execução única é o caso extremo dessa fragilidade.

A terceira é que o único controle efetivo contra a injeção por conteúdo lido pelo agente é a restrição de permissões.

Quem tratar evals para agentes de IA como disciplina de engenharia estará aplicando literatura madura a um objeto novo. Isso significa linha de base congelada, critérios revisados por humanos, repetição estatística e escopo mínimo de permissões.

Por outro lado, quem tratar a avaliação como um conjunto de dashboards estará medindo apenas a própria suíte de testes.

FAQ

Qual eval implementar primeiro em um projeto que ainda não tem nenhum?

Comece pelos tool unit tests, porque são determinísticos, baratos e independentes do modelo. Eles cobrem a falha mais frequente em produção: ferramenta com contrato mal definido e mensagem de erro inútil.

Nota de juiz automático serve para alguma decisão?

Serve para comparação relativa entre duas versões, com ordem invertida e várias execuções. Como número absoluto de qualidade, não serve, porque a escala é instável e sensível a comprimento e posição.

Por que a média entre dimensões da rubrica é problemática?

Porque dimensões de naturezas diferentes não se compensam, como segurança e custo. Algumas devem funcionar como condição eliminatória, reprovando a execução independentemente das demais notas.

Uma execução por caso é suficiente na suíte de regressão?

Não, porque agentes são estocásticos e uma execução mede só uma amostra. A comparação precisa ser entre distribuições de várias execuções, na linha da métrica pass^k.

Shadow run pode causar efeito colateral em produção?

Sim, se a camada de ferramentas não tiver modo de execução simulada. Um agente que decide escrever executará a escrita, mesmo que a resposta seja descartada.

Instrução de sistema resolve prompt injection?

Não, porque o vetor principal é o conteúdo externo lido pelo agente. O que limita o dano é o escopo de permissões e a separação entre conteúdo não confiável e ferramentas privilegiadas.