Conteúdo
- 1. O que são as avaliações de agentes (agent evals)?
- 2. Por que diferem das avaliações de LLM (saída vs. trajectory)
- 3. O que medir: 5 dimensões
- 4. Como pontuar: 3 avaliadores e "resultado vs. caminho"
- 5. Problemas exclusivos das avaliações de agentes
- 6. O fluxo de trabalho e os benchmarks
- Resumo
- FAQ
Você montou um sistema multiagente, deu-lhe ferramentas e o executou com o Agent SDK—então, como medir se o agente está realmente fazendo o seu trabalho? Para uma única saída, você pode pontuá-la com avaliações de IA. Mas um agente planeja ao longo de muitas etapas, chama ferramentas e age com estado. Mesmo que a última frase pareça correta, ele pode ter cruzado uma ponte perigosa pelo caminho. É aqui que as avaliações de agentes ganham o protagonismo.
Este artigo expõe, com base em informações oficiais, o que são as avaliações de agentes, como diferem das avaliações de LLM, o que medir (5 dimensões), como pontuar (3 avaliadores), as armadilhas exclusivas e o fluxo de trabalho prático mais os benchmarks. Os pontos-chave de imediato. ① As avaliações de agentes medem não apenas "a saída final", mas a "trajectory" das ações. ② A Anthropic recomenda pontuar o resultado (estado final), não o caminho—porque a verificação mecânica passo a passo é frágil. ③ Comece com um conjunto de avaliação pequeno, de 20 a 50 tarefas extraídas de falhas reais, e execute pontuação automatizada.
Meça tanto "a resposta final" quanto "o caminho percorrido"
— as avaliações de saída não bastam; os agentes têm múltiplas etapas, usam ferramentas e têm estado
A Anthropic recomenda pontuar o resultado em vez do caminho—mas a trajectory diz a você por que ele falhou. Use ambos, cada um para o seu propósito.
1. O que são as avaliações de agentes (agent evals)?
As avaliações de agentes são o processo de medir sistematicamente se um "agente"—que usa ferramentas e dá várias etapas para atingir um objetivo—consegue de fato cumprir as suas tarefas. Elas são uma evolução das avaliações de LLM, que julgam a qualidade de um único prompt; o alvo se expande de "uma saída" para "uma sequência de ações".
Por que isso importa: em seu guia sobre avaliações de agentes, a Anthropic observa que "as avaliações ficam mais difíceis de construir quanto mais você espera. No início, os requisitos do produto se traduzem naturalmente em casos de teste", e recomenda que "de 20 a 50 tarefas simples extraídas de falhas reais são um ótimo ponto de partida". Em outras palavras, as avaliações de agentes transformam "parece estar funcionando" em números reproduzíveis. Isso se combina com a observabilidade de IA (observar a execução)—os traces que você observa tornam-se o material para a avaliação.
2. Por que diferem das avaliações de LLM (saída vs. trajectory)
As avaliações de LLM tradicionais essencialmente pontuam "entrada → uma saída". Mas um agente planeja, chama ferramentas, observa os resultados, decide o próximo movimento e atualiza o estado. Portanto, olhar apenas para a saída final não basta. O Google igualmente afirma que "não basta simplesmente verificar as saídas; precisamos entender o 'porquê' por trás das ações de um agente", e divide a avaliação em duas famílias: "resposta final" e "trajectory". A Microsoft, também, diz que é preciso "avaliar não apenas a saída final, mas também a qualidade e a eficiência de cada etapa", dividindo-a em avaliação de sistema (ponta a ponta) e de processo (passo a passo).
💡 A ideia central: uma "resposta final correta" pode esconder um processo quebrado. Por outro lado, a resposta pode estar certa, mas ter sido alcançada por sorte, acaso ou um atalho perigoso. Por isso, para agentes, você olha tanto o "resultado" quanto o "processo". Para os fundamentos da avaliação de saída única e do LLM-as-judge, veja o artigo sobre avaliações de IA.
3. O que medir: 5 dimensões
Aqui estão cinco lentes comumente usadas para a avaliação de agentes.
Ele atingiu o objetivo? Julgue pelo estado final—se existe uma reserva no DB—não pela fala "fiz a reserva".
Ele deu etapas razoáveis? Usou as ferramentas certas na ordem e na quantidade certas? Houve desvios inúteis ou movimentos perigosos?
Ele escolheu a ferramenta certa e passou os argumentos certos? Verifique nomes de funções, tipos de argumentos e valores (e detecte chamadas desnecessárias).
Quantas etapas, tokens, dólares e segundos? Uma resposta correta é impraticável se o custo dispara. Precisa ser vinculada às métricas observadas.
A saída é relevante, precisa e completa? Pontue conteúdo aberto com LLM-as-judge ou uma rubrica.
Observação: a 4. eficiência (tokens, custo, latência) não é formalmente codificada como uma "métrica de avaliação" por nenhum fornecedor isolado; na prática, costumam ser sinais de observabilidade trazidos para a avaliação. Ainda assim, é uma dimensão essencial para deter um agente que entra em loop e foge de controle.
4. Como pontuar: 3 avaliadores e "resultado vs. caminho"
Há, em linhas gerais, três tipos de avaliador. Seguindo o enquadramento da Anthropic, cada um tem suas compensações.
| Avaliador | Pontos fortes | Pontos fracos |
|---|---|---|
| Código (programático) | Rápido, barato, objetivo, reproduzível | Frágil diante de variações válidas / alternativas |
| LLM-as-judge (modelo) | Flexível, escalável, capta nuances | Não determinístico, mais caro, precisa de calibração com humanos |
| Humano | Padrão-ouro de qualidade | Caro, lento (evite se possível) |
A jogada padrão: pontue o que puder com código, entregue apenas as partes subjetivas e abertas a um modelo diferente como LLM-as-judge, e use humanos para verificações pontuais em momentos-chave. O design do LLM-as-judge (rubricas detalhadas, saídas discretas, viés do juiz) é tratado em profundidade no artigo sobre avaliações de LLM.
A "correspondência de trajectory" mecânica é frágil
Então, como pontuar a trajectory? Aqui a Anthropic adota uma postura firme: "Há um instinto comum de verificar se os agentes seguiram etapas muito específicas, como uma sequência de chamadas de ferramentas na ordem certa. Descobrimos que essa abordagem é rígida demais e resulta em testes excessivamente frágeis, pois os agentes regularmente encontram abordagens válidas que os projetistas de avaliação não anteciparam. Para não punir a criatividade desnecessariamente, muitas vezes é melhor pontuar o que o agente produziu, não o caminho que ele percorreu." Para uma reserva de voo, por exemplo, você mede se uma reserva de fato existe no DB SQL do ambiente como estado final—não a fala "fiz a reserva".
Enquanto isso, Google e Microsoft oferecem graus de correspondência de trajectory (exato / na ordem / em qualquer ordem, etc.) como métricas formais. As duas coisas não são contraditórias—as avaliações de trajectory são boas para diagnosticar "por que ele falhou", e as avaliações de resultado evitam punir a criatividade válida. Na prática, o meio-termo realista é evitar a correspondência exata estrita e afrouxar para uma verificação de ação-chave: "as ferramentas críticas foram chamadas?"
5. Problemas exclusivos das avaliações de agentes
As avaliações de agentes carregam dificuldades que a avaliação de saída única não tem.
- Não determinismo (a mesma entrada toma caminhos diferentes): um sucesso não significa que ele se reproduz. Você precisa de métricas de confiabilidade como se ele tem sucesso em todas as k execuções (pass^k). O artigo do τ-bench relata que "os modelos degradam consideravelmente à medida que k aumenta, revelando sua falta de confiabilidade" (os números são pontuais no tempo).
- Erros que se acumulam: se uma única etapa tem sucesso com probabilidade p, então t etapas têm sucesso a aproximadamente pt. Quanto mais longa a cadeia, mais rápido ela desmorona—razão pela qual o sucesso cai bruscamente em tarefas de longo horizonte.
- Reward hacking / specification gaming: comportamento que satisfaz a letra do avaliador sem atingir o objetivo real. No exemplo da DeepMind, um braço robótico posicionou-se entre a câmera e o objeto, enganando os avaliadores e fazendo-os pensar que havia agarrado o item quando não o tinha feito. Pegar o "parece certo, mas o caminho é perigoso" exige avaliar a trajectory e os efeitos colaterais.
- Conjuntos de avaliação ficando obsoletos / contaminação: quando um benchmark vaza para os dados de treinamento (contaminação), as pontuações deixam de refletir a capacidade real. Você tem que continuar atualizando suas avaliações de regressão à medida que o agente amadurece.
O problema do "caminho perigoso" é contínuo com os guardrails de IA. Uma avaliação que olha apenas para a resposta final passa direto por essas armadilhas.
6. O fluxo de trabalho e os benchmarks
Ancorado nas recomendações da Anthropic, o fluxo de trabalho é simples.
- Construa pequeno, a partir de falhas reais: você não precisa de centenas. Transforme de 20 a 50 falhas que aconteceram em produção em casos de teste.
- Execute pontuação automatizada: código primeiro, LLM-as-judge apenas para as partes abertas. Priorize volume em vez de qualidade pontuada à mão.
- Separe dois tipos: avaliações de capacidade (no que ele é bom?) e avaliações de regressão (ele ainda consegue fazer o que fazia?).
- Coloque-as em um ciclo de vida: ① avaliações automatizadas pré-lançamento (integradas ao CI) → ② monitoramento em produção → ③ testes A/B → ④ feedback do usuário e revisão de traces, em camadas.
- Escreva-as cedo: as avaliações ficam mais difíceis de construir quanto mais você espera.
Os benchmarks de agentes conhecidos também são referências úteis para construir suas próprias avaliações (o segredo é ler "o que cada um mede"; as pontuações variam por modelo e versão, então não as tome ao pé da letra).
| Benchmark | O que mede |
|---|---|
| SWE-bench / Verified | Resolver issues reais do GitHub com um patch, pontuado pass/fail pela suíte de testes (baseado em execução) |
| τ-bench / τ²-bench | Diálogo multi-turno ferramenta×usuário em varejo, companhia aérea, etc. + cumprimento de políticas; pontuado pelo estado final do DB |
| WebArena | Conclusão de tarefas de operação web autônoma em réplicas realistas de sites |
| GAIA | Tarefas de assistente geral fáceis para humanos, difíceis para a IA (raciocínio + ferramentas + navegação) |
| OSWorld | Uso de computador operando uma GUI em um SO real, avaliado com base em execução |
| BFCL | Precisão da chamada de funções/ferramentas (nomes de funções, estrutura de argumentos, executabilidade) |
Quanto ao ferramental, LangSmith, Braintrust, DeepEval e Arize Phoenix dão suporte à avaliação de trajectory e de chamadas de ferramentas. A maioria se baseia em traces, pontuando nos níveis de etapa, execução e dataset. Note que os Claude Managed Agents trazem embutida a pontuação baseada em resultados—em que um avaliador separado avalia contra a sua rubrica.
Resumo
As avaliações de agentes são o processo de medir se um agente que usa ferramentas e dá várias etapas consegue de fato cumprir suas tarefas. Ao contrário das avaliações de LLM, que olham para uma única saída, elas examinam tanto "a resposta final (resultado)" quanto "o caminho percorrido (trajectory)". As dimensões são ① resultado ② trajectory ③ uso de ferramentas ④ eficiência ⑤ qualidade final. Pontue com código → LLM-as-judge → humano, e a Anthropic recomenda "pontuar o resultado (estado final), não o caminho" (a verificação mecânica passo a passo é frágil).
As armadilhas exclusivas são o não determinismo (pass^k), os erros que se acumulam, o reward hacking e os conjuntos de avaliação obsoletos. Na prática, a jogada padrão é começar pequeno com 20 a 50 casos de falhas reais, executar pontuação automatizada no CI, separar avaliações de capacidade e de regressão e escrevê-las cedo. Relacionados: avaliações de IA, observabilidade, como construir um sistema multiagente, Managed Agents.
FAQ
Q. O que são as avaliações de agentes?
A. O processo de medir sistematicamente se um agente que usa ferramentas e dá várias etapas consegue de fato cumprir suas tarefas. Elas são uma evolução das avaliações de LLM, que pontuam um único prompt; o alvo se expande de "uma saída" para "uma sequência de ações". A marca registrada é olhar não apenas para a resposta final, mas para a trajectory que levou até ela (quais ferramentas foram chamadas, como).
Q. Como diferem das avaliações de LLM comuns?
A. Em olhar para "uma saída" ou para "uma cadeia de ações". Como um agente planeja, chama ferramentas e atualiza o estado, a saída final sozinha não basta. Uma resposta correta pode esconder um processo quebrado, e uma resposta certa pode ter vindo por um atalho perigoso. Por isso você avalia tanto o resultado (estado final) quanto a trajectory (processo).
Q. O que devo medir?
A. As cinco dimensões comuns: ① resultado (sucesso da tarefa = o estado final corresponde ao objetivo?) ② trajectory (etapas razoáveis?) ③ correção do uso de ferramentas (ferramenta certa, argumentos certos?) ④ eficiência (etapas, tokens, custo, latência) ⑤ qualidade da resposta final (relevante, precisa, completa?). A dimensão 4 traz sinais de observabilidade e é importante para deter fugas de controle.
Q. Devo verificar a trajectory (etapas) por correspondência exata?
A. Não—a correspondência exata estrita tende a ser frágil. A Anthropic recomenda: "verificar se as chamadas de ferramentas seguiram a ordem certa é rígido e frágil demais; os agentes encontram alternativas válidas, então é melhor pontuar o resultado, não o caminho." Na prática, evite a correspondência exata e afrouxe para uma verificação de ação-chave: "as ferramentas críticas foram chamadas?" Dito isso, a trajectory é útil para diagnosticar por que ele falhou, então use cada uma onde ela se encaixa.
Q. Como começo?
A. Comece transformando 20 a 50 falhas de produção em casos de teste. Como diz a Anthropic, "você não precisa de centenas; de 20 a 50 tarefas simples extraídas de falhas reais são um ótimo ponto de partida". Pontue automaticamente—código para o que o código consegue medir, um LLM-as-judge de modelo separado apenas para as partes abertas—e coloque no CI para pegar regressões. Separe as avaliações de capacidade (no que ele é bom) das avaliações de regressão (manter o que funcionava), e escreva suas avaliações cedo.
