Evals para agent skills: como testar agentes com método

TL;DR

Evals para agent skills são uma forma de tratar capacidades de agentes como testes de ponta a ponta: você executa o agente com a skill ligada, captura traces e artefatos, e aplica checks ou rubricas para obter um score repetível. Isso importa porque mudanças em prompt, modelo ou ferramenta podem degradar o comportamento sem quebrar a interface; com evals, você detecta regressões antes de chegar à produção.

Na prática, o caminho mais útil combina sucesso final, qualidade da trajetória e verificadores determinísticos quando possível. Para times que operam no Brasil, isso ganha ainda mais valor quando entra em jogo LGPD, custo em BRL e latência para regiões fora do país.

O que muda quando você avalia skills em vez de só respostas

O ponto central do brief é simples: agent skills não deveriam ser avaliadas como se fossem respostas isoladas de um modelo. A ideia é tratar cada skill como uma capacidade verificável, quase como um teste de contrato. Você define a condição de execução, roda o agente com as skills ativadas, coleta o que aconteceu e mede o resultado por checks e rubricas.

Esse recorte é útil porque agentes falham de um jeito diferente de modelos “soltos”. Às vezes a resposta final parece aceitável, mas a sequência de passos foi errada, uma ferramenta foi usada fora de ordem, ou um artefato foi gerado com inconsistência. Evals para skills capturam justamente essa diferença entre “pareceu certo” e “foi executado corretamente”.

A própria documentação da OpenAI descreve esse fluxo como algo repetível: prompt, execução capturada, checagens e score. Em outras palavras, o valor da eval não está só no número final, mas em tornar o comportamento auditável ao longo do tempo.

Pipeline básico de um eval de skill

Um desenho prático costuma seguir esta estrutura:

1. Defina a skill como uma capacidade testável, não como uma intenção vaga.
2. Rode o agente com a skill habilitada e capture trace, chamadas de ferramenta e artefatos.
3. Verifique o resultado com checks determinísticos sempre que existirem.
4. Aplique uma rubrica quando o julgamento exigir critério semântico.
5. Compare ao longo do tempo para ver regressão ou ganho.

Se você já trabalha com testes automatizados, isso deve soar familiar. A diferença é que aqui o objeto testado é um fluxo de decisão, não só uma função pura.

undefined

Três camadas de avaliação que fazem diferença

O brief aponta três camadas que se complementam bem: verificador determinístico, rubrica hierárquica e julgamento por modelo. Não é preciso escolher uma só. Em sistemas reais, a combinação tende a ser mais estável do que apostar em uma métrica única.

1. Verificadores determinísticos

Quando existe regra objetiva, use isso primeiro. Se a skill exige chamar uma ferramenta específica, produzir um arquivo com nome definido ou respeitar uma ordem de passos, um verificador programático é melhor do que pedir opinião para outro modelo. Ele reduz custo, aumenta repetibilidade e deixa claro o que foi violado.

O benchmark SkillsBench, citado no brief, segue bem essa lógica ao propor verifiers determinísticos para comparar desempenho com e sem skills. Isso é particularmente útil quando você quer medir o efeito da própria skill, e não só a “boa vontade” do agente em acertar.

2. Rubricas hierárquicas

Nem tudo cabe em regra binária. Em muitos casos, você precisa separar sucesso final da qualidade do caminho. Por exemplo: o agente concluiu a tarefa, mas fez uma chamada de ferramenta desnecessária, omitiu uma etapa, ou violou uma restrição operacional. Rubricas hierárquicas ajudam a pontuar cada dimensão da trajetória.

A pesquisa recente citada no brief segue nessa direção: adaptar rubricas ao task e avaliar passo a passo. Esse tipo de avaliação é mais cara, mas costuma ser mais informativa quando o comportamento do agente importa tanto quanto o output.

3. LLM-as-judge com controles

Quando a saída é semântica, ambígua ou depende de contexto humano, o julgamento por outro modelo entra como ferramenta. O cuidado aqui é não transformar o judge em uma caixa-preta sem critério. Você precisa definir instruções, exemplos, limites e, de preferência, combinar o judge com verificação objetiva em partes do fluxo.

O risco conhecido é a eval-awareness: o agente aprende a “performar para a prova” se o formato do teste vazar sinais demais. A recomendação do brief é combinar técnicas para reduzir esse viés, em vez de achar que um único prompt de judge resolve tudo.

Como sair do “teste ad hoc” e chegar a uma matriz de regressão

Um time que quer sistematizar evals precisa pensar em repertório, não em caso isolado. O ganho vem de manter conjuntos estáveis de tarefas, rodadas registradas e comparação entre versões de modelo, prompt, ferramenta ou skill. Isso transforma a eval em uma linha de base para regressão.

Na prática, a matriz pode ser organizada por domínio e por habilidade. Por exemplo: recuperação de informação, uso de ferramenta, decisão com restrição, geração de artefato, e recuperação após erro. Cada linha mede uma coisa; cada coluna mede uma skill. Assim você descobre rapidamente onde uma mudança quebra o sistema.

Esse formato é especialmente útil em agentes que alternam entre planejamento, execução e validação. Se o modelo muda, você não quer descobrir só em produção que ele passou a ignorar uma ferramenta, ou a produzir um fluxo mais longo e mais caro para fazer a mesma tarefa.

Quando uma eval depende de versão específica de SDK, API ou CLI, documente a versão do ambiente e confira o changelog oficial antes de levar o fluxo para produção. APIs de IA mudam rápido, e um teste confiável hoje pode ficar desatualizado depois de uma atualização menor.

Métrica útil: sucesso final não basta

Se você mede apenas o acerto final, perde a parte mais valiosa do comportamento do agente. Dois runs podem terminar com a mesma resposta, mas um deles usar menos ferramentas, evitar retrabalho e respeitar a política de execução. O outro pode chegar ao mesmo fim por um caminho frágil.

Por isso, vale separar pelo menos três indicadores: sucesso da tarefa, conformidade da trajetória e custo operacional. Essa tríade é simples de comunicar e pega bastante coisa que números únicos escondem.

O papel dos traces e artefatos

Se você não captura trace, você está olhando só para o resultado e ignorando a evidência. Para agentes, o trace é o equivalente ao log de uma aplicação distribuída: ele mostra decisão, chamada de ferramenta, entrada, saída e ordem dos eventos. Já os artefatos ajudam a avaliar o que o agente produziu de fato, como arquivo, relatório, payload ou plano.

Isso é importante porque muitos erros em agentes são estruturais. O texto final pode soar competente, mas o fluxo por trás pode ter acessado a ferramenta errada, repetido uma etapa ou quebrado a sequência esperada. Sem trace, você não enxerga a falha raiz.

Em ambientes de produção, esse ponto conversa bem com observabilidade. Evals e observabilidade não são a mesma coisa, mas ficam muito mais fortes quando caminham juntas: uma mede capacidade, a outra ajuda a explicar o comportamento.

Por que isso importa pro dev brasileiro

No Brasil, o custo da errância em IA costuma aparecer mais cedo. Muitos times rodam infraestrutura em regiões fora do país, com latência maior para usuários finais, e isso pesa quando o agente faz múltiplas chamadas de ferramenta. Além disso, a LGPD exige cuidado com dados pessoais, então uma eval que captura traces e artefatos precisa ser pensada com anonimização e retenção bem definidas.

Tem também um fator de orçamento. Em reais, o custo de rodar dezenas ou centenas de execuções de agente com judge em cada merge pode virar um problema real para startups e squads internos. Por isso, faz sentido priorizar verificadores determinísticos onde houver regra objetiva e deixar o LLM-as-judge só para o que realmente pede interpretação.

Na prática brasileira, isso se conecta a um cenário bem comum: times enxutos, prazos curtos e integrações com sistemas legados. Evals sistematizadas ajudam a evitar o ciclo “mudamos uma prompt e só percebemos o impacto quando o atendimento ou a operação já sentiu”.

Uma forma simples de começar sem montar uma plataforma inteira

Você não precisa implementar tudo de uma vez. Um caminho viável é começar com uma planilha de casos críticos, um runner simples e um conjunto mínimo de checks. A primeira versão da eval pode ser incremental, desde que seja repetível.

undefined

A partir daí, você começa a registrar runs e comparar versões. O objetivo não é criar burocracia; é construir memória técnica. Quando o time trocar o modelo ou ajustar a skill, a comparação já existe.

Boas práticas que evitam ruído

• Separe teste funcional de teste semântico. Se a regra é objetiva, não terceirize para um judge.
• Use amostras estáveis. Casos que mudam toda hora tornam a comparação inútil.
• Registre versão de prompt, skill e modelo. Sem isso, a regressão vira opinião.
• Mascare dados sensíveis. Isso é especialmente importante por LGPD e governança interna.
• Compare por trajetória, não só por saída. O caminho importa em agentes.

Onde OpenAI, Anthropic e pesquisa recente se encaixam

O material do brief indica uma convergência prática. A OpenAI mostra a mecânica de transformar skills em evals e de manter execuções comparáveis ao longo do tempo. A Anthropic chama atenção para a integridade do teste e para o fato de que agentes são complexos demais para uma abordagem única. Já trabalhos como SkillsBench e a linha de rubricas adaptativas tentam tornar a avaliação mais específica para tarefas e trajetórias.

O valor dessa convergência não está em “escolher um vencedor”. Está em perceber que o problema de avaliação está amadurecendo: menos foco em respostas soltas, mais foco em capacidade observável, trajetória e robustez. Para quem constrói agentes, isso muda o jeito de pensar QA.

Conclusão

Se você quer agentes mais confiáveis, trate skills como algo testável. Comece com casos críticos, capture trace e artefatos, prefira verificação determinística onde houver regra e use judge só para a parte semântica. O ganho real está em saber, com rastreabilidade, o que mudou quando o comportamento do agente mudou.

Em até 1 hora, escolha uma skill do seu sistema, escreva três casos de teste com critérios objetivos e rode uma execução manual capturando trace e artefatos. Se possível, anote a versão do modelo e a ordem das tool calls; isso já vira a base do seu primeiro eval de regressão.

Conteúdos da DIO para quem quer aprofundar

• Aceleração Microsoft AI Agents — evento prático sobre agentes e ferramentas de IA, com workshops sobre co-criação de sistemas, GitHub Copilot e Azure IA Foundry.
• Bradesco - GenAI & Dados — trilha que combina Python, dados e IA generativa, com atividades mão na massa e um app de voz com Whisper e Python.
• CAIXA - Inteligência Artificial na Prática — bootcamp sobre fundamentos de IA aplicados a finanças, carreira e criação de soluções práticas com IA.
• Microsoft AI for Tech - OpenAI Services — trilha para integrar serviços da OpenAI no Azure e construir aplicações com chat, texto e cenários cloud.