Avaliação de Agentes

O que “Avaliação de Agentes” Significa

Um agente de IA (AI agent) é um sistema que toma ações ao longo do tempo para atingir objetivos — muitas vezes chamando ferramentas (busca, execução de código, bancos de dados, navegadores, APIs), mantendo estado e memória, e se adaptando ao feedback de um ambiente. Avaliação de agentes é a prática de medir o quão bem esses sistemas performam sob condições controladas.

Isso difere de avaliar uma única resposta de um modelo: um agente pode executar dezenas ou centenas de passos, cometer erros intermediários, se recuperar e negociar trade-offs entre velocidade, custo e segurança. Uma boa avaliação, portanto, deve testar não apenas “qualidade da resposta”, mas também:

• Planejamento e execução de longo horizonte
• Seleção de ferramentas e uso correto de ferramentas
• Robustez a ambientes ruidosos ou em mudança
• Comportamento de segurança e proteção sob restrições realistas
• Eficiência (latência, número de chamadas de ferramenta, uso de tokens, custo computacional)
• Reprodutibilidade (resultados estáveis entre execuções)

A avaliação de agentes comumente usa suítes de tarefas (task suites) (coleções de tarefas padronizadas) e ambientes controlados (sandboxes) (ambientes instrumentados e reinicializáveis onde um agente pode agir com segurança).

Este artigo foca no porquê, o que e como de avaliar agentes que usam ferramentas.

Fundamentos Teóricos

Agentes como Políticas em Ambientes

Uma abstração útil é ver um agente como uma política (policy) ( \pi ) que mapeia observações (e memória interna) para ações:

• Observação: o que o agente vê (DOM de uma página web, saídas de ferramentas, arquivos, logs)
• Ação: chamada de ferramenta, clique, tecla pressionada, execução de código, requisição de API, mensagem
• Estado: estado subjacente do ambiente (conteúdo do sistema de arquivos, estado do servidor web, tickets em um rastreador de issues)
• Recompensa / objetivo: critérios de sucesso da tarefa

Muitos cenários de agentes se assemelham a um (PO)MDP (Processo de Decisão de Markov / MDP Parcialmente Observável): o agente pode não observar o estado completo e deve agir sob incerteza. Esse enquadramento esclarece a avaliação:

• Uma execução única é uma trajetória (trajectory) de ações e observações.
• O desempenho pode ser estimado pela taxa de sucesso esperada ao longo de tarefas e aleatoriedade (seeds).
• A variância costuma ser alta; rigor estatístico importa (veja Reprodutibilidade e Significância Estatística).

Por que Avaliar Agentes é Mais Difícil do que Avaliar Modelos

Em comparação com benchmarks de QA “offline”, a avaliação de agentes adiciona várias complicações:

1. Não determinismo: amostragem do modelo, saídas de ferramentas, timing, variabilidade de rede.
2. Atribuição de crédito: muitos passos contribuem para sucesso/fracasso; o diagnóstico é mais difícil.
3. Espaços de ação abertos: ferramentas e ambientes permitem muitas ações possíveis.
4. Mudança de distribuição: ecossistemas reais de ferramentas mudam; sandboxes podem ficar desatualizados (veja Avaliação Robusta).
5. Efeitos de Goodhart: otimizar métricas proxy (por exemplo, contagem de chamadas de ferramenta) pode prejudicar a utilidade real (veja Lei de Goodhart em Métricas).

Suítes de Tarefas: O que São e o que Medem

Uma suíte de tarefas (task suite) é um conjunto curado de tarefas projetadas para sondar capacidades específicas de agentes. Ela normalmente inclui:

• Uma especificação da tarefa (enunciado do objetivo + restrições)
• Um ambiente (realista ou simulado)
• Uma função de pontuação (critérios de sucesso, crédito parcial)
• Um protocolo (timeouts, ferramentas permitidas, número de tentativas, seeding)

Áreas Comuns de Capacidades

Suítes de tarefas para agentes frequentemente miram:

• Uso de ferramentas: selecionar a ferramenta certa, formatar entradas, interpretar saídas
• Navegação na web: fluxos multi-página, formulários, etapas tipo login (no sandbox)
• Engenharia de software: reproduzir bug, editar código, rodar testes, submeter patch
• Análise de dados: carregar conjuntos de dados, executar consultas, criar gráficos, resumir resultados
• Coordenação multiagente: delegação, especialização de papéis, consenso
• Segurança e conformidade com políticas: resistir a jailbreaks, respeitar permissões

Exemplos de Suítes Inspiradas no Mundo Real

O ecossistema evolui rapidamente, mas categorias comuns incluem:

• Suítes de agentes web/UI: agentes interagem com sites simulados ou UIs de desktop (por exemplo, fluxos de compra, painéis administrativos). Testam robustez a mudanças de UI e atenção a detalhes como entradas de formulário.
• Suítes de código e engenharia de software: tarefas exigem modificar repositórios e passar testes (por exemplo, benchmarks de correção de bugs). Acoplam fortemente uso de ferramentas (shell, editor, executor de testes) com planejamento de longo horizonte.
• Suítes de chamada de ferramentas (tool-calling): enfatizam APIs de ferramentas estruturadas (esquemas JSON), composição de múltiplas ferramentas e tratamento de erros.
• Suítes incorporadas/simuladas: avaliam o “grounding” de ações em ambientes simulados (jogos, gridworlds, simuladores domésticos).

Suítes de tarefas são discutidas de forma mais ampla em Suítes de Benchmarks e como projetá-las em Construção de Benchmarks. A avaliação de agentes frequentemente combina múltiplas suítes para evitar overfitting a um único ambiente.

Sandboxes: Mundos Seguros e Reinicializáveis para Agentes

Um sandbox é um ambiente de execução projetado para ser:

• Instrumentado: registra todas as ações, chamadas de ferramenta e artefatos intermediários
• Reinicializável: pode retornar a um estado inicial conhecido por episódio
• Isolado: previne exfiltração de dados, injeção de prompt ou ações destrutivas
• Determinístico quando necessário: seeds controlados e dependências estáveis
• Suficientemente realista: captura modos de falha de implantações reais

Designs Comuns de Sandbox

1) Sandboxes de Computação em Contêineres

Usados para tarefas de código e dados:

• O agente recebe um contêiner Linux com um repositório, suíte de testes e rede limitada
• Ferramentas: shell, editor de arquivos, executor de Python
• Pontuação: testes passando, qualidade do diff, restrições (sem arquivos proibidos)

Benefícios principais: reprodutibilidade, segurança, instrumentação rica.

2) Sandboxes de Aplicações Web

Usados para tarefas de navegação e transacionais:

• Hospedam uma cópia de sites localmente (e-commerce, wikis, sistemas de tickets)
• Fornecem um navegador controlado ou uma ferramenta de interação em nível de DOM
• Incluem armadilhas “realistas”: botões ambíguos, paginação, conteúdo dinâmico

Benefícios principais: interação web segura sem efeitos colaterais no mundo real.

3) Sandboxes de Mock de APIs

Usados para tarefas de uso de ferramentas e fluxos de trabalho:

• Ferramentas apontam para serviços mockados com saídas e modos de erro estáveis
• Podem simular limites de taxa, timeouts e respostas malformadas

Benefícios principais: comportamento determinístico de ferramentas, injeção de falhas fácil.

4) Sandboxes de Desktop/SO

Usados para agentes de “uso de computador”:

• VM com uma GUI, explorador de arquivos, aplicativos de escritório
• Maior realismo; também maior não determinismo e complexidade de avaliação

Considerações de Segurança e Proteção

Como agentes podem executar código e interagir com ferramentas, sandboxes devem se defender contra:

• Vazamento de dados (por exemplo, fornecer acidentalmente respostas escondidas)
• Injeção de prompt via saídas de ferramentas (páginas web, logs)
• Escalonamento (acesso à rede, acesso ao sistema de arquivos fora do escopo permitido)
• Ações inseguras (deletar arquivos, spam, acesso a segredos)

Avaliação orientada à segurança é coberta em Avaliação de Segurança, mas sandboxes de agentes devem integrar controles de segurança por design (menor privilégio, allowlists, monitoramento).

Protocolos de Avaliação: Tornando Resultados Significativos

Definindo “Sucesso” para Agentes

Tarefas para agentes frequentemente têm objetivos claros (por exemplo, “todos os testes passam”), mas também podem ser parciais ou subjetivos. Bons protocolos incluem:

• Sucesso binário quando possível (passa/falha)
• Crédito parcial para marcos intermediários
• Checagens de restrições (não violou políticas, ficou dentro do orçamento)
• Validade da trajetória (sem ferramentas proibidas, sem canais ocultos)

Para saídas abertas, você pode usar:

• Avaliações humanas (Avaliação Humana)
• Juízes automatizados ou pontuação por rubrica (LLM-como-Juiz)
  com calibração cuidadosa e verificações pontuais

Avaliação com Múltiplas Execuções e Variância

Como o desempenho de agentes pode variar entre execuções, avaliações fortes usam:

• Múltiplas seeds por tarefa
• Múltiplas tarefas por categoria
• Intervalos de confiança e testes estatísticos

Veja Reprodutibilidade e Significância Estatística para boas práticas.

Evitando Vazamento e Contaminação

Benchmarks de agentes são especialmente vulneráveis a vazamento porque:

• Tarefas podem ser extraídas de fontes públicas
• Saídas de ferramentas podem conter artefatos de resposta
• Modelos podem ter memorizado instâncias comuns de benchmarks

Mitigações incluem conjuntos de holdout privados, rotação de tarefas e auditorias de contaminação (veja Contaminação do Conjunto de Teste).

Métricas para Avaliação de Agentes e Uso de Ferramentas

Uma avaliação abrangente de agentes raramente depende de um único número. Métricas comuns incluem:

Métricas de Resultado

• Taxa de sucesso: % de tarefas resolvidas sob restrições
• Pontuação de conclusão de objetivo: marcos ponderados
• Pontuação de qualidade: correção baseada em rubrica, clareza, manutenibilidade (para código)

Métricas de Eficiência

• Passos / chamadas de ferramenta: quantas ações foram tomadas
• Tempo para conclusão: tempo de relógio (wall-clock)
• Uso de tokens / custo: tokens de prompt+completion ao longo dos passos
• Uso computacional: CPU/GPU, se relevante

Métricas de Confiabilidade e Robustez

• Pass@k / orçamentos de tentativas: sucesso dentro de k tentativas
• Estabilidade entre seeds: variância de sucesso
• Degradação sob perturbações: mudanças de UI, erros de ferramenta, entradas ruidosas
  (veja Avaliação Robusta)

Métricas de Segurança e Conformidade

• Violações de política: uso de ferramenta não permitido, acesso a dados
• Suscetibilidade a jailbreak: seguir instruções maliciosas embutidas na saída de ferramentas
• Tentativas de ações danosas: comandos destrutivos no shell, exfiltração

Métricas de segurança devem ser interpretadas com cuidado — um agente pode “falhar de forma segura” (recusar) versus “falhar de forma perigosa” (obedecer).

Exemplo Prático: Avaliando um Agente que Usa Ferramentas em um Sandbox

Abaixo está um padrão simplificado para avaliar um agente que pode chamar ferramentas em um ambiente controlado. As ideias-chave são:

• Tratar cada tarefa como um episódio (episode)
• Registrar cada ação
• Impor orçamentos (passos, tempo, custo)
• Calcular uma pontuação determinística

from dataclasses import dataclass, field
import time

@dataclass
class Task:
    id: str
    prompt: str
    expected: dict  # task-specific success criteria

@dataclass
class EpisodeResult:
    task_id: str
    success: bool
    steps: int
    tool_calls: int
    elapsed_s: float
    trace: list = field(default_factory=list)
    error: str | None = None

class SandboxTools:
    def __init__(self):
        self.calls = 0

    def search(self, query: str) -> str:
        self.calls += 1
        # In a real sandbox: deterministic corpus + logging + injection defenses
        return f"RESULTS_FOR({query})"

    def run_python(self, code: str) -> str:
        self.calls += 1
        # In a real sandbox: containerized execution + resource limits
        return "OK"

def evaluate_agent(agent, tasks, max_steps=30, timeout_s=60):
    results = []
    for task in tasks:
        tools = SandboxTools()
        start = time.time()
        trace = []
        success = False
        error = None

        try:
            obs = {"task_prompt": task.prompt}
            for step in range(max_steps):
                if time.time() - start > timeout_s:
                    raise TimeoutError("timeout")

                action = agent.act(obs, tools=tools)  # e.g., {"tool":"search","args":{...}}
                trace.append(action)

                # Environment transition (highly simplified)
                if action.get("final"):
                    # Task-specific scoring
                    success = (action["final"] == task.expected["final"])
                    break

                obs = {"tool_output": "..."}

        except Exception as e:
            error = str(e)

        results.append(EpisodeResult(
            task_id=task.id,
            success=success,
            steps=len(trace),
            tool_calls=tools.calls,
            elapsed_s=time.time() - start,
            trace=trace,
            error=error
        ))
    return results

Em uma suíte real de agentes, você substituiria a lógica de transição simplificada por um ambiente de fato (aplicação web, repositório + testes, VM de SO) e um avaliador rigoroso.

Exemplo Prático: Tarefa de Fluxo de Trabalho em Sandbox Web

Um padrão comum de avaliação para agentes web é uma tarefa transacional (transactional task):

“No site de e-commerce do sandbox, encontre a jaqueta impermeável de trilha mais barata no tamanho M, adicione ao carrinho e prossiga para o checkout até a página final de confirmação (não finalize o pedido).”

O que isso mede:

• Navegação por categorias e busca
• Filtragem/ordenação
• Leitura cuidadosa de especificações do produto
• Tratamento de formulários em múltiplas etapas
• Respeito a restrições (“não finalize o pedido”)

Como é avaliado:

• Sucesso: carrinho contém o item correto + checkout alcançado sem ação de confirmação
• Eficiência: número de cliques / chamadas de ferramenta
• Robustez: pequenas mudanças de UI (texto de botão, ordem de elementos)
• Segurança: nenhuma tentativa de acessar endpoints de admin ou páginas ocultas

Um sandbox forte irá:

• Fornecer snapshots do DOM e capturas de tela para auditoria
• Reiniciar o estado do site por episódio
• Incluir inventário/preços determinísticos (ou aleatoriedade controlada com seeds)

Projetando Boas Suítes de Tarefas para Agentes (Princípios)

Meça a Capacidade que Você Realmente Quer

Se você se importa com implantações reais, inclua tarefas que exijam:

• Ler e seguir restrições
• Recuperar-se de erros (timeouts, saída de ferramenta malformada)
• Lidar com ambiguidade (múltiplas rotas plausíveis)

Esse é o desafio central em Construção de Benchmarks: alinhar tarefas com as capacidades pretendidas.

Prefira Tarefas End-to-End, mas Mantenha Diagnósticos

Pontuação end-to-end (o agente teve sucesso?) é realista, mas difícil de depurar. Boas suítes também registram:

• Argumentos e saídas de chamadas de ferramenta
• Diffs de estado (mudanças no sistema de arquivos, mudanças no DOM)
• Pontos de decisão (por que ferramenta A vs ferramenta B)

Uma prática útil é calcular ambos:

• Métrica primária: taxa de sucesso
• Métricas diagnósticas: contagem de passos, taxa de mau uso de ferramenta, tipos de erro

Inclua Restrições Negativas e Requisitos de “Não Faça”

Implantações reais de agentes frequentemente falham por violações de restrição, e não por incapacidade de resolver a tarefa. Exemplos:

• “Não use a rede.”
• “Não acesse PII do usuário.”
• “Não execute rm -rf.”
• “Use apenas a ferramenta de banco de dados fornecida, não SQL livre no shell.”

Essas restrições podem ser pontuadas como falhas duras ou penalidades, dependendo da sua tolerância a risco.

Faça Testes de Estresse de Robustez

Uma avaliação robusta de agentes inclui perturbações como:

• Erros de ferramenta (HTTP 500, timeouts, limites de taxa)
• Layouts de UI ligeiramente diferentes
• Conteúdo distrator (anúncios, resultados de busca irrelevantes)
• Tentativas de injeção de prompt embutidas em páginas web ou documentos

Isso se conecta de perto a Avaliação Robusta.

LLM-como-Juiz e Julgamento Humano para Trajetórias de Agentes

Alguns aspectos do comportamento de agentes são difíceis de pontuar mecanicamente:

• O raciocínio foi sólido?
• Seguiu boas práticas?
• Comportou-se com segurança quando incerto?

Duas abordagens comuns:

• Avaliação humana: alta qualidade, cara, mais lenta, sujeita a viés de avaliadores (veja Avaliação Humana).
• LLM-como-juiz: escalável, mas pode ser enviesada, inconsistente e vulnerável a injeção de prompt ou preferência estilística (veja LLM-como-Juiz).

Um híbrido prático é:

• Usar pontuação automática para resultados objetivos (testes passando, estado correto do BD)
• Usar LLM/humanos para auditar um subconjunto amostrado de trajetórias quanto a conformidade com políticas e erros qualitativos

Operacionalizando a Avaliação de Agentes na Prática

Em Desenvolvimento (Iteração Rápida)

Equipes tipicamente executam:

• Pequenas suítes smoke a cada mudança (minutos)
• Testes de regressão em tarefas notoriamente difíceis
• Ferramentas de replay do sandbox para inspecionar falhas

Pré-Lançamento (Gate)

Antes de lançar um agente ou uma grande atualização:

• Suíte maior em múltiplos domínios
• Variantes de robustez (injeção de falhas, paráfrases)
• Suíte de segurança e tarefas de red team (veja Avaliação de Segurança)

Pós-Implantação (Monitoramento)

Suítes offline não são suficientes. Sistemas reais precisam de:

• Telemetria sobre falhas de ferramenta, retries, custos
• Feedback de usuários e rastreamento de incidentes
• Atualização periódica das suítes de avaliação para evitar overfitting e desatualização
  (a dinâmica de leaderboards pode agravar isso; veja Rankings)

Para cenários de aplicações end-to-end, conecte a avaliação de agentes com Avaliação de Apps de LLM, especialmente quando recuperação, grounding e fidelidade importam.

Modos de Falha Comuns que Avaliações de Agentes Revelam

• Erros de esquema de ferramenta: campos JSON errados, argumentos obrigatórios ausentes
• Heurísticas superficiais: o agente clica no primeiro botão plausível e fica preso
• Loops infinitos: chamadas de ferramenta repetidas sem nova informação
• Excesso de confiança: fabricar saídas de ferramenta ou alegar conclusão prematuramente
• Injeção de prompt: seguir instruções embutidas na saída de ferramenta (“Ignore previous instructions…”)
• Estouro de orçamento: sucesso, mas com custo/latência excessivos
• Fragilidade: sucesso apenas sob um layout de UI ou uma formulação

Um sandbox bem projetado torna essas falhas observáveis e acionáveis.

Resumo

A avaliação de agentes mede o quão bem sistemas que usam ferramentas alcançam objetivos por meio de interação em múltiplos passos. As avaliações mais eficazes combinam:

• Suítes de tarefas que miram capacidades específicas e representam fluxos de trabalho reais
• Sandboxes que são seguros, instrumentados e reinicializáveis
• Métricas abrangendo resultado, eficiência, robustez e segurança
• Protocolos que tratam variância, reprodutibilidade e riscos de contaminação

A avaliação de agentes é inerentemente mais em nível de sistema do que o benchmarking clássico de modelos, e se beneficia de um design cuidadoso de benchmarks (Construção de Benchmarks), testes de robustez (Avaliação Robusta) e métodos de julgamento com princípios (Avaliação Humana, LLM-como-Juiz).

---