PulseFlow Tecnologia
← Insights
·7 min de leitura·guia-tecnico·evals·mlflow·testes-de-agentes
PulseFlow Tecnologia

Como aplicar evals em agentes de IA

Avaliar um agente de IA não é o mesmo que avaliar um chatbot: a resposta de texto pode estar perfeita e o agente ainda ter chamado a ferramenta errada, gasto tempo e dinheiro desnecessários, ou tomado uma ação que nenhum humano aprovaria. Este guia usa como base as práticas documentadas pelo MLflow para agentes prontos para produção e os dados da pesquisa State of AI Agents da LangChain sobre o que empresas já fazem - e o que ainda não fazem.

Passo 1: defina critérios de sucesso além de "a resposta parece certa"

O MLflow recomenda rastrear especificamente "faithfulness" (precisão factual), completude e suficiência da resposta - três dimensões distintas de "parece bom". Uma resposta pode ser factualmente precisa e ainda assim incompleta, ou completa e ainda assim insuficiente para a tarefa.

Passo 2: estabeleça ground truth antes de medir drift

Capture a distribuição de qualidade no momento do lançamento do agente. Sem essa linha de base, não há como saber se uma queda de qualidade é real ou apenas ruído - o MLflow recomenda estabelecer limites estatísticos que disparem alerta quando o desvio for anormal, comparado a essa distribuição inicial.

Passo 3: teste tool use, não só texto

Um agente que responde bem mas chama a ferramenta errada, ou passa o parâmetro errado, falha de um jeito que avaliação de texto não captura. Testes de tool use precisam verificar especificamente: a ferramenta certa foi chamada, com os parâmetros certos, na ordem certa.

Passo 4: testes de segurança como categoria própria

O OWASP Agentic Skills Top 10 mapeia riscos de segurança específicos das camadas de comportamento de agentes - isso não é a mesma coisa que testar qualidade de resposta. Testes de segurança avaliam se o agente resiste a tentativas de manipulação, se respeita limites de escopo, e se falha de forma segura quando algo dá errado.

Passo 5: regressão a cada mudança

Toda mudança em prompt, ferramenta ou contexto é candidata a quebrar algo que já funcionava. Testes de regressão rodando a cada mudança pegam isso antes de produção, não depois.

Passo 6 e 7: custo e latência como evals, não como métrica de infra à parte

Custo e latência não deveriam ser medidos só pela equipe de infraestrutura - eles são parte do eval, porque uma resposta correta que custa 10x mais ou demora 10x mais pode não ser aceitável para o caso de uso.

Passo 8: rastreabilidade como parte da avaliação

Um agente que decide corretamente mas não deixa rastro de por que decidiu assim falha em auditoria, mesmo passando em todos os outros testes. Avaliar rastreabilidade significa verificar se o log gerado é suficiente para reconstruir a decisão depois.

Passo 9: avaliação incorporada ao fluxo, com LLM-as-a-Judge para escala

A abordagem que o MLflow descreve, baseada em orientação do NIST, incorpora "avaliação probes... em workflows agentic ativos", com resultados em "trilhas de auditoria legíveis por máquina". Para não depender de revisão humana em cada resposta, a abordagem LLM-as-a-Judge do MLflow automatiza a maior parte da avaliação, reservando revisão humana para os casos que o próprio julgamento automatizado sinaliza como duvidosos.

Passo 10: monitoramento contínuo, não avaliação pontual

Eval não é uma etapa que se faz uma vez antes do lançamento - é um processo contínuo. Os dados da LangChain mostram que ferramentas de rastreamento e observabilidade já são o controle mais citado entre empresas com agentes em produção, precisamente porque avaliação pontual não pega degradação que acontece meses depois do lançamento.

Fontes