Avaliações de Agentes e Benchmarking SWE-bench

1. Visão geral do conceito e problema sistêmico

O maior risco no desenvolvimento de sistemas agentic em 2026 é a chamada «degradação comportamental» (Behavioral Regression):

• Você altera uma frase no prompt do sistema para que o agente formate melhor o Markdown, mas inesperadamente ele deixa de chamar a ferramenta de leitura de arquivos.
• Você migra da versão v1.2 para v1.3 do modelo, e o agente começa a executar duas vezes mais comandos shell incorretos.
• Sem testes automatizados, projetos agentic se transformam em «xamanismo», onde os desenvolvedores avaliam a qualidade do sistema com dois ou três prompts manuais no chat.

Agent Evals é uma disciplina de engenharia que transfere os princípios clássicos de TDD e CI/CD para o mundo dos agentes linguísticos não determinísticos. Ela permite medir quantitativamente a taxa de sucesso (Pass Rate), o custo em tokens (Cost per Task) e o tempo de execução (Latency).

2. Taxonomia arquitetural e modelo mental

┌─────────────────────────────────────────────────────────────┐
│                 TAXONOMIA DE AVALIAÇÃO DE AGENTES           │
├─────────────────────────────────────────────────────────────┤
│ 1. Avaliações Baseadas em Estado (Estado final do ambiente):│
│    • Passagem de Testes Unitários / Integração              │
│      (pytest, vitest == 0)                                  │
│    • Verificação de Diff no Sistema de Arquivos             │
│      (os arquivos necessários foram criados?)               │
├─────────────────────────────────────────────────────────────┤
│ 2. Avaliações Baseadas em Trajetória                        │
│    (Avaliação da trajetória de raciocínio):                 │
│    • Precisão das Chamadas de Ferramentas                   │
│      (a ferramenta correta foi chamada?)                    │
│    • Eficiência de Etapas                                   │
│      (quantas etapas foram necessárias para atingir a meta?)│
│    • Penalidade por Ações Redundantes                       │
│      (penalidades por repetições)                           │
├─────────────────────────────────────────────────────────────┤
│ 3. Avaliações LLM-as-a-Judge                                │
│    (Verificação semântica via juiz):                        │
│    • Tom da Resposta e Adesão aos Guias de Estilo           │
│    • Completude e Conformidade com Segurança                │
├─────────────────────────────────────────────────────────────┤
│ 4. Avaliações de Recursos e Econômicas:                     │
│    • Taxa de Consumo de Tokens por Problema Resolvido       │
│    • Tempo de Execução Real (Wall-Clock)                    │
└─────────────────────────────────────────────────────────────┘

3. Pipeline técnico e mecânica interna

Um framework típico de avaliação de agentes (como Inspect AI, Braintrust ou um Docker Harness próprio) opera seguindo este ciclo:

1. Test Environment Reset: Inicialização de um container Docker isolado com o commit inicial da base de código, onde o problema ainda está presente.
2. Task Provisioning: O agente recebe apenas a descrição do bug (issue.md).
3. Agent Trajectory Recording: O agente executa comandos, lê arquivos e realiza edições. Todas as etapas são registradas em formato OpenTelemetry / JSONL (trajetória de ações).
4. Harness Evaluation:
   • O orquestrador extrai o git diff gerado.
   • São executados testes de verificação ocultos (Fail-to-Pass tests).
   • O status é registrado: RESOLVED, FAILED, TIMEOUT ou OUT_OF_BUDGET.
5. Metric Aggregation: Calcula-se a porcentagem total de tarefas resolvidas (Resolve Rate) para a release do agente.

4. Cenários práticos de engenharia em produção

01. Gate de CI/CD para atualização de prompts agentic

Antes do merge das alterações no arquivo .cursorrules ou no prompt do sistema no repositório, é disparada uma GitHub Action com 30 testes sintéticos. Se o agente resolver menos de 90% das tarefas, o pull request é bloqueado automaticamente.

02. Seleção de provedor de modelos baseada em ROI

A equipe avalia: vale a pena pagar por um modelo top-tier $15 por milhão de tokens, ou basta um novo modelo open-source por $0.50? A execução de evals em 100 tarefas próprias mostra números precisos: o modelo top-tier resolve 78% das tarefas, o barato — 74%, mas custa 20 vezes menos.

5. Armadilhas, erros comuns e segurança

• Contamination (Contaminação da amostra de treinamento): Benchmarks públicos (como o HumanEval básico) acabam nos dados de treinamento dos modelos recentes, fazendo com que o modelo "lembre" a resposta correta, mas não saiba raciocinar. Use apenas evals proprietários fechados ou SWE-bench Verified com tarefas atualizadas constantemente.
• Flaky Evals (Testes instáveis): A não determinística da temperatura do modelo pode resultar em 80% de sucesso em uma execução e 65% em outra. É necessário realizar pelo menos 3–5 execuções por tarefa (métrica Pass@k).
• Confiança cega em LLM-as-a-Judge: Usar outro modelo para avaliar código frequentemente sofre de viés a favor de respostas longas ou esteticamente agradáveis. Prefira compiladores e testes determinísticos.

6. Conclusão estratégica para o engenheiro de 2026

Sem um sistema de avaliação contínua (Agent Evals), criar sistemas autônomos é caminhar às cegas. O engenheiro de nova geração dedica 70% do tempo não à escrita de prompts, mas ao projeto de conjuntos de testes abrangentes que permitem modificar e escalar arquiteturas agentic com segurança.