Conteúdo
Depois de construir um agente de IA, você sempre esbarra no mesmo muro: "Certo, mas será que ele funciona de verdade?" Você mudou o prompt, trocou o modelo, adicionou uma ferramenta — e o mecanismo que decide se isso deixou as coisas melhores ou piores com dados em vez de intuição são os evals (avaliações).
Um LLM pode produzir uma saída diferente a cada vez para a mesma entrada (é probabilístico). Por isso, entregar com base em "parece funcionar" leva a regressões silenciosas e falhas em casos extremos na produção. Este artigo cobre o que são evals, cinco formas de medir a qualidade, a avaliação específica de agentes e como começar pequeno — escrito para quem põe a mão na massa.
O essencial, em 30 segundos
Se você só for ler uma coisa
1. Por que você precisa de evals
Um software comum é determinístico: mesma entrada, mesma saída. É por isso que um teste unitário que verifica "a saída corresponde ao valor esperado?" funciona. Mas um LLM é probabilístico — até a mesma pergunta volta redigida ou enquadrada de forma um pouco diferente a cada vez. Nos termos de agentes de IA vs RPA, não é uma "mão" determinística, mas um "cérebro" probabilístico, então testes de correspondência exata não funcionam como estão.
Três modos de falha costumam aparecer aqui.
Você testa alguns exemplos na mão e decide que "parece melhor". Você nunca percebe que outro caso quebrou.
Você muda um prompt ou modelo e só um tipo de entrada piora. Você descobre por uma reclamação da produção.
"Às vezes ele retorna algo estranho." Como é probabilístico, uma tentativa não reproduz, então você não consegue rastrear a causa.
Os evals previnem os três de uma vez. Prepare um conjunto de dados de avaliação, pontue todo o conjunto a cada mudança e compare as pontuações — só isso já transforma "intuição" em "dados" e torna as regressões visíveis. Quanto mais julgamento você delega a um agente, mais os evals se tornam a base da qualidade, lado a lado com as guardrails.
2. O que são evals
Evals (avaliações) = medir se a saída de uma IA ou o comportamento de um agente funciona de forma correta e estável, como esperado. Em termos humanos, é dar nota. Os blocos de construção são simples e se dividem em três partes.
O conjunto de entradas sobre o qual você avalia. Reúna exemplos de uso real, logs antigos e casos extremos esperados.
Como você transforma a saída em uma pontuação: correspondência exata, verificações por regras ou nota dada por outra IA.
Pontue todo o conjunto e compare o antes e o depois de uma mudança para decidir se ficou melhor ou pior.
Evals não são "construa uma vez e pronto" — a essência é executá-los como teste de regressão toda vez que você muda um prompt, modelo ou ferramenta. Como código de teste, é um ativo que você cultiva.
3. Cinco formas de medir a qualidade
Existem cinco abordagens representativas de pontuação. A regra geral é escolher pela natureza da tarefa e combinar várias.
Prepare a saída esperada (gold label) para cada entrada e pontue pela taxa de acerto. Ideal para tarefas com resposta fixa: classificação, extração, sim/não.
Verifique mecanicamente regex, correspondência exata, validade do JSON, presença de chaves obrigatórias. Forte para conferir "sempre precisa retornar neste formato" — rápido e barato.
Faça outro LLM dar nota segundo uma rubrica. Para tarefas em que a resposta não é única: qualidade de resumo, tom, relevância.
Compare as pontuações no mesmo conjunto de dados antes e depois de uma mudança de prompt/modelo. Captura uma "regressão oculta" em que o todo sobe mas uma parte cai.
Pontue e observe continuamente os logs ao vivo. Acompanhe taxa de falhas, custo, latência e desvio nas entradas para pegar degradação cedo.
| Método | Adequado para | Custo | Objetividade |
|---|---|---|---|
| ① Gabarito | Classificação, extração, decisões | Baixo | ◎ Alta |
| ② Baseado em regras | Verificações de formato / estrutura | Baixo | ◎ Alta |
| ③ LLM-as-judge | Resumo, geração, qualidade de diálogo | Médio | ○ Depende da rubrica |
| ④ Regressão | Detectar regressões de mudanças | Médio | ◎ Relativa |
| ⑤ Monitoramento em produção | Detectar degradação ao vivo | Médio–Alto | ○ Contínua |
A chave está no encadeamento: "meça mecanicamente o que der (① ②), use LLM-as-judge para a qualidade que não dá (③) e mantenha rodando por regressão e produção (④ ⑤)." O LLM-as-judge (③) é prático, mas o próprio LLM que julga varia, então escreva a rubrica de forma explícita e, quando possível, calibre contra notas humanas.
4. Avaliação específica de agentes
Para uma única resposta (uma entrada → uma saída), os cinco acima bastam. Mas um agente de IA executa múltiplos passos, chama ferramentas por conta própria e toma decisões pelo caminho. Então você precisa avaliar não apenas a saída final, mas o processo.
Ele atingiu o objetivo no fim (por exemplo, fez a reserva certa)? A métrica primária de agentes.
Ele chamou a ferramenta certa, com os argumentos certos, na ordem certa? Pegue chamadas erradas ou redundantes.
O caminho de passos e decisões é razoável? Avalie desvios, loops infinitos e retentativas desnecessárias.
Para o mesmo sucesso, menos tokens, passos e menos latência é melhor. Isso importa na produção.
Observar isso exige tracing que registra cada passo (entrada, raciocínio, chamada de ferramenta, resultado). Muitos frameworks e as ferramentas abaixo já vêm com tracing e avaliação juntos. Para uma configuração multiagente, mantenha traces hierárquicos para conseguir apontar qual agente falhou.
5. Como começar — construa pequeno
Você não precisa de uma plataforma de eval perfeita desde o primeiro dia. Começar com um conjunto de dados de 20 itens é realista.
- Colete exemplos de falha: primeiro, 10–20 "entradas que deram errado". Logs reais e reclamações são uma mina de ouro — este é o núcleo do conjunto de eval.
- Escreva o comportamento esperado: anexe uma "resposta correta" ou "condições a satisfazer" a cada entrada. Nem tudo precisa de uma resposta rígida (meça a qualidade com ③).
- Escolha um pontuador: verificações de formato → ② baseado em regras; resposta fixa → ① gabarito; qualidade → ③ LLM-as-judge. Um ou dois para começar já está bom.
- Rode uma vez e crie a baseline: registre a pontuação atual. Esse é o seu ponto de referência.
- Rode a cada mudança: após mudar prompt/modelo, rode de novo e compare com a regressão ④. Se cair, não entregue.
- Adicione observação em produção: uma vez no ar, continue acompanhando taxa de falhas e custo com o monitoramento ⑤, e realimente os exemplos reais ruins de volta no conjunto de eval.
💡 Dica: pese o seu conjunto de eval para "as falhas que você não quer que aconteçam", e não para "os sucessos comuns". Incluir casos extremos, entradas adversárias e pedidos vagos permite proteger-se proativamente contra o que quebra a cada mudança. Uma boa rubrica, como um bom design de prompt, fica mais reproduzível quanto mais concreta for.
6. Armadilhas comuns
- Conjunto de dados pequeno demais / enviesado demais: coletar só sucessos ignora as falhas do mundo real. Misture deliberadamente falhas e casos extremos.
- Confiar cegamente no LLM-as-judge: o LLM que julga também varia e tem vieses. Escreva a rubrica de forma explícita e calibre periodicamente contra notas humanas. Cuidado com o conflito de interesse (o mesmo modelo escreve e elogia a própria saída).
- Olhar só para a saída final: o processo é tudo para agentes. Sem chamadas de ferramenta, trajetória e custo, você vai abençoar um resultado que "deu sorte".
- Decidir com uma única execução: como é probabilístico, para evals importantes rode várias vezes e observe a variância.
- Não atualizar os evals: especificações e uso mudam. Continue adicionando novas falhas de produção ao conjunto de eval.
7. Ferramentas principais
Você pode começar com seus próprios scripts, mas há um conjunto crescente de ferramentas dedicadas que cuidam de tracing e avaliação juntos. Exemplos representativos (todos os sites oficiais).
| Ferramenta | O que faz |
|---|---|
| Anthropic Console / Evals | Teste e avalie prompts para o Claude em uma UI. Também para comparar escolhas de modelo. |
| OpenAI Evals | Um framework OSS para definir e rodar evals. O formato básico de conjunto de dados + pontuador. |
| LangSmith | Tracing + avaliação. Registra cada passo do agente, passando por regressão e monitoramento em produção. |
| Langfuse | Observabilidade OSS de LLM. Tracing, avaliação e monitoramento de custo juntos. |
| Ragas | Avaliação especializada em RAG (geração aumentada por recuperação): relevância, fidelidade e mais. |
Seja qual for a que você use, a essência é a mesma: um conjunto de dados + um pontuador + a disciplina de comparar. As ferramentas apenas facilitam isso. O melhor começo é um pequeno conjunto de eval, mesmo que num script na sua máquina.
Resumo
- O que são evals: uma "correção de prova" que mede a saída e o comportamento da IA com números — decidir melhor/pior com dados, não com intuição.
- Por que você precisa deles: LLMs são probabilísticos e variam, então testes unitários não se encaixam e regressões e casos extremos passam despercebidos.
- Cinco métodos: ① gabarito ② baseado em regras ③ LLM-as-judge ④ regressão ⑤ monitoramento em produção. Meça mecanicamente o que der, julgue a qualidade com um LLM e mantenha rodando.
- Agentes também precisam de avaliação de processo: taxa de sucesso da tarefa, chamadas de ferramenta, trajetória, custo. O tracing é pré-requisito.
- Como começar: 20 exemplos de falha. Crie a baseline deles e depois rode a cada mudança.
Entre "eu construí" e "está utilizável" há uma ponte chamada evals. Se as guardrails são a defesa que impede o comportamento descontrolado, os evals são o ataque que mede a qualidade e a mantém em ascensão. Um único pequeno conjunto de eval transforma o desenvolvimento de agentes de "intuição" em engenharia.
FAQ
P. Como os evals diferem dos testes unitários comuns?
Testes unitários verificam "a saída corresponde exatamente ao valor esperado?". Mas um LLM é probabilístico e produz uma saída diferente a cada vez, então a correspondência exata não funciona como está. Os evals se diferenciam por combinar medição adequada a saídas probabilísticas — verificações baseadas em regras, nota dada por um LLM e observação da variância entre várias execuções — em cima da correspondência com o gabarito.
P. Posso confiar no LLM-as-judge (deixar uma IA dar nota)?
É prático, mas não é uma bala de prata. O LLM que julga pode variar e ter vieses. O que importa é escrever uma rubrica concreta, calibrar periodicamente contra notas humanas e separar os papéis/modelos de geração e de avaliação para evitar o conflito de interesse. A comparação relativa (qual de A ou B é melhor) tende a ser mais estável do que pontuações absolutas.
P. De quantos itens de eval eu preciso?
Você pode começar bem com 10–20. Até uns poucos ajudam na comparação relativa de "a pontuação subiu ou caiu depois de uma mudança?". Na prática, faça-o crescer adicionando falhas encontradas na produção. Mais importante que a quantidade é incluir corretamente falhas, exceções e casos extremos.
P. Eu realmente preciso avaliar a "trajetória" de um agente?
Se você o roda em produção, sim. Mesmo quando a saída final está correta, desvios, chamadas de ferramenta desnecessárias e loops infinitos prejudicam o custo e a confiabilidade. Adicione tracing que registra cada passo e olhe o processo junto com a taxa de sucesso da tarefa. Quanto mais o caso de uso envolve permissões e efeitos colaterais — como casos de uso de automação de negócios ou automação de operações em nuvem — mais a avaliação de processo compensa.
