Medição, custo e evolução

Aula 36

Evals para agentes: tarefas, tentativas e graders

O artigo Demystifying evals for AI agents, da Anthropic, define o vocabulário. Uma tarefa é um problema com critério de sucesso. Uma tentativa é uma execução do agente nessa tarefa. Um grader avalia o resultado. A transcrição é o registro completo do que o agente fez. O artigo diferencia o harness de avaliação, que roda as tarefas e coleta resultados, do harness do agente, o assunto deste curso.

Há três tipos de grader, com trocas claras:

Como agentes são não determinísticos, uma tentativa só não diz muito. O artigo distingue duas métricas. pass@k é a chance de pelo menos uma de k tentativas dar certo, útil quando você pode escolher a melhor. pass^k é a chance de todas as k darem certo, que mede confiabilidade. Com 75% de sucesso por tentativa, pass^3 é cerca de 42%: um agente que acerta três de quatro vezes falha com frequência quando precisa acertar sempre.

O roteiro prático do artigo: comece com 20 a 50 tarefas tiradas de falhas reais, escreva tarefas sem ambiguidade e com solução de referência, equilibre casos positivos e negativos, isole cada tentativa (em um caso, o Claude Opus 4.5 leu o histórico do git de tentativas anteriores), avalie o resultado e não o caminho, e dê ao juiz a opção "não sei". Separe evals de capacidade, que começam com taxa baixa e medem progresso, de evals de regressão, que devem ficar perto de 100%. Um 0% em pass@100 quase sempre indica tarefa quebrada, não agente incapaz. E leia as transcrições: a nota diz se falhou, a transcrição diz por quê.

Fontes desta aula: Anthropic: Demystifying evals for AI agents

Aula 37

O harness vale o custo?

Harness não é gratuito. Cada sensor, avaliador e subagente custa tempo e tokens. Em outubro de 2026, Naresh Jain publicou no site de Martin Fowler um experimento com dez execuções da mesma tarefa, comparando modelos com e sem um harness comportamental (contratos de API e testes executáveis):

• Com o modelo otimizado para custo (GPT-6 Luna), o harness levou a taxa de builds aceitos de 3 em 10 para 10 em 10, a um custo por execução cerca de 33% menor do que usar o modelo de fronteira sem harness.
• Com o modelo de fronteira (GPT-6 Sol), o harness multiplicou o custo por cerca de 7 sem nenhum ganho de aceitação. O autor sugere, para modelos fortes, rodar as checagens uma única vez, como portão final.

O artigo da Anthropic sobre harness para aplicações longas mostra a mesma tensão. Na criação de um editor de jogos retrô, o agente sozinho levou 20 minutos e custou 9 dólares. O harness completo, com planejador, gerador e avaliador, levou 6 horas e custou 200 dólares, mais de 20 vezes mais, com resultado muito superior. Com um modelo mais novo, o time simplificou o harness, removeu os sprints e passou a rodar o avaliador só no fim. A conclusão do artigo é o princípio que fecha este curso: cada componente do harness codifica uma suposição sobre o que o modelo não consegue fazer sozinho, e o avaliador vale o custo quando a tarefa está além do que o modelo faz de forma confiável. Quando o modelo melhora, as suposições devem ser testadas de novo.

Jain chama os sensores de "atenção executável": quando uma checagem falha, ela traz de volta ao foco um requisito que o agente tinha deixado de lado. Isso explica por que harnesses rendem mais em modelos menores, que perdem requisitos com mais frequência.

Fontes desta aula: Naresh Jain: Are Harnesses Worth the Cost? · Anthropic: Harness design for long-running apps

Aula 38

Métricas de produção

Evals medem o agente em laboratório. Em produção, o que interessa é o efeito no trabalho do time. A Faros AI propõe métricas em estágios, que funcionam bem combinadas com as métricas DORA do livro Accelerate:

A métrica mais negligenciada é a última. Um registro simples de cada falha do agente, com a categoria (contexto faltando, ferramenta errada, regra ignorada, teste ausente) e a correção aplicada no harness, transforma incidentes isolados em um mapa de onde investir. É o ratchet do módulo 4 com dados.

Fontes desta aula: Faros AI: Harness engineering guide · Manus: Context Engineering for AI Agents

Aula 39

Projeto final: monte o harness do seu repositório

O projeto final junta os módulos numa sequência que pode ser aplicada em qualquer repositório onde você usa um agente de código. Faça em ordem e registre o antes e o depois.

Depois da primeira rodada, o trabalho passa a ser contínuo: cada falha nova entra no registro, ganha uma correção no mecanismo certo e uma tarefa de eval que impede a regressão. A cada nova geração de modelos, revise as suposições do harness e remova o que deixou de ser necessário. Um bom harness é pequeno, medido e sempre um pouco melhor do que na semana anterior.

Erros comuns

• Avaliar com uma tentativa só. Agentes variam. Rode várias e olhe pass^k quando precisar de confiabilidade.
• Avaliar o caminho em vez do resultado. O agente pode chegar ao resultado certo por um caminho diferente do esperado.
• Tarefas de eval ambíguas. Se uma pessoa não sabe dizer se a resposta está certa, o grader também não sabe.
• Harness completo em todo modelo. Modelos fortes podem precisar de menos checagens. Meça o custo e o ganho.
• Medir só tokens. O custo que mais pesa costuma ser o tempo de revisão humana.

Siglas usadas neste módulo

PR:

Pull Request, pedido de integração de mudanças.

DORA:

DevOps Research and Assessment, programa de pesquisa que definiu métricas de entrega de software.

API:

Application Programming Interface, interface de programação de aplicações.

MCP:

Model Context Protocol, protocolo aberto para conectar agentes a ferramentas.

KV-cache:

Key-Value cache, armazenamento do processamento de prefixos já vistos pelo modelo.

HLD:

High Level Design, design de alto nível.

LLD:

Low Level Design, design de baixo nível.

ADR:

Architecture Decision Record, registro de decisão de arquitetura.