Engenharia da Anthropic: guia prático e metodologia para avaliação (Evals) de agentes de IA

Resumo:

• Apenas benchmarks tradicionais de LLM não conseguem medir com precisão o desempenho de 'agentes de IA' que usam ferramentas e realizam raciocínio em múltiplas etapas.
• A avaliação de agentes deve combinar testes unitários (Unit Tests) e testes de integração (Integration Tests), de forma semelhante a testes de software.
• É eficaz usar uma combinação de avaliação determinística baseada em código (Code-based) e avaliação baseada em modelo com uso de LLM (Model-based).
• É necessário, ao longo do ciclo de vida de desenvolvimento de agentes, migrar de 'avaliações de capacidade (Capability Evals)' para 'testes de regressão (Regression Evals)'.

Resumo detalhado:

1. Por que é difícil avaliar agentes de IA
   Diferentemente de chatbots simples (Single-turn), agentes usam ferramentas, alteram o estado do ambiente e executam tarefas ao longo de várias etapas (Multi-turn). Por isso, não basta verificar apenas a resposta final; também é preciso avaliar de forma abrangente se o agente usou as ferramentas corretas, se o processo foi eficiente etc.

2. Estrutura de uma avaliação (Eval) de agentes
   Um sistema de avaliação eficaz é composto pelos seguintes elementos centrais.

• Tarefa (Task): um único caso de teste com entrada definida e critérios de sucesso.
• Avaliador (Grader): a lógica que atribui uma pontuação ao resultado da execução do agente.
• Transcrição (Transcript): o registro completo da execução, incluindo o processo de raciocínio do agente, chamadas de ferramentas e resultados intermediários.
• Resultado (Outcome): o estado final do ambiente após a execução do agente ter feito alterações (ex.: uma reserva foi realmente criada no DB).

3. Comparação entre tipos de avaliador (Grader)
   A Anthropic recomenda usar uma combinação de três tipos de avaliadores.

Tipo	Descrição	Vantagens	Desvantagens
Baseado em código (Code-based)	correspondência de strings, regex, análise estática, execução de testes unitários etc.	rápido, barato, objetivo, reproduzível	pode deixar passar nuances complexas, pouca flexibilidade
Baseado em modelo (Model-based)	usa um LLM como juiz (Judge) para pontuar com base em rubricas	flexível, capta nuances, adequado para perguntas abertas	pode ser não determinístico, tem custo, requer calibração humana
Humano (Human)	revisão por especialistas, crowdsourcing	'gold standard' de qualidade	muito lento e caro

4. Exemplo de avaliação de um agente de programação (configuração YAML)
   Ao avaliar um agente de programação, não se observa apenas se o código executa (teste determinístico), mas também o estilo de código e a existência de violações de segurança (análise estática/avaliação por LLM). A seguir, um exemplo hipotético de configuração de avaliação para a tarefa de 'corrigir uma vulnerabilidade de segurança'.

task:  
  id: "fix-auth-bypass_1"  
  desc: "Corrigir a vulnerabilidade de bypass de autenticação que ocorre quando o campo de senha está vazio"  
  graders:  
    # 1. Teste determinístico: verificar se o código de teste real passa  
    - type: deterministic_tests  
      required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]  
    
    # 2. Avaliação por rubrica com LLM: avaliar qualidade e estilo do código  
    - type: llm_rubric  
      rubric: prompts/code_quality.md  
    
    # 3. Análise estática: executar linter e ferramentas de segurança  
    - type: static_analysis  
      commands: [ruff, mypy, bandit]  
    
    # 4. Verificação de estado: confirmar se os logs de segurança foram registrados corretamente  
    - type: state_check  
      expect:  
        security_logs: {event_type: "auth_blocked"}  
    
    # 5. Verificação de uso de ferramentas: confirmar se os arquivos necessários foram lidos e modificados  
    - type: tool_calls  
      required:  
        - {tool: read_file, params: {path: "src/auth/*"}}  
        - {tool: edit_file}  
        - {tool: run_tests}  
  
  # Métricas a rastrear  
  tracked_metrics:  
    - type: transcript  
      metrics:  
        - n_turns # número de turnos  
        - n_toolcalls # número de chamadas de ferramenta  
        - n_total_tokens # uso de tokens  
    - type: latency  
      metrics:  
        - time_to_first_token  

5. Métricas de avaliação (Metrics)
   Para lidar com a natureza não determinística dos agentes, além da acurácia simples, usam-se também as métricas a seguir.

• pass@k: a probabilidade de obter pelo menos 1 sucesso em k tentativas (mede capacidade de exploração).
• pass^k: a probabilidade de todas as tentativas terem sucesso em k execuções (mede consistência/confiabilidade).

6. Ferramentas e frameworks
   Para construir um sistema de avaliação, sugere-se usar ferramentas como Harbor (execução em ambiente de contêiner), Promptfoo (configuração de testes baseada em YAML), Braintrust, LangSmith etc., ou criar um framework próprio ajustado ao fluxo de trabalho da equipe. O importante não é o framework em si, mas garantir casos de teste de alta qualidade.

[darjeeling]

O conteúdo é bom, então adiciono a versão traduzida para o coreano.

https://rosettalens.com/s/ko/demystifying-evals-for-ai-agents