Skip to content

Como avaliar sistemas multiagentes

Um guia prático para avaliar sistemas LLM multiagentes, atribuindo falhas ao agente e à transferência responsáveis, revisando o grafo de interação e pontuando cada agente e a equipe.

Um sistema multiagente são vários agentes LLM (um planejador, um programador, um revisor e assim por diante) cooperando em uma tarefa. Avaliá-lo significa mais do que pontuar a resposta final, porque as falhas que importam acontecem entre agentes: uma restrição perdida em uma transferência, o agente errado assumindo o controle, uma equipe que nunca verifica o próprio trabalho. A unidade útil de julgamento é qual agente, qual passo e qual transferência. O Potato é uma ferramenta de código aberto para a avaliação humana de execuções multiagentes, com um conjunto de telas de anotação feitas sob medida para a estrutura da equipe.

Aqui, um sistema multiagente significa um fluxo de trabalho movido por LLM em que agentes distintos, cada um com um papel, trocam mensagens e transferem o controle. A pesquisa sobre por que esses sistemas falham (a taxonomia MAST, Why Do Multi-Agent LLM Systems Fail?) constata que uma grande parcela das falhas é entre agentes: problemas de especificação, desalinhamento entre agentes e ausência de verificação. Uma transcrição plana esconde exatamente isso.

Por que a avaliação de um único agente não basta?

Quando você avalia um único agente, julga uma única sequência de pensamentos, chamadas de ferramentas e observações. Uma equipe acrescenta modos de falha que só existem entre agentes:

  • Perda na transferência: o agente A conhece uma restrição que o agente B nunca recebe.
  • Atribuição equivocada: a execução falha, mas o agente responsável está a montante de onde o erro apareceu.
  • Falha de coordenação: cada agente é individualmente competente, mas a equipe entra em loop, trava ou nunca verifica.
  • Contenção de recursos: dois agentes tocam a mesma ferramenta ou arquivo ao mesmo tempo e entram em deadlock.

Pontuar apenas a saída final diz que a equipe falhou, mas não onde. A atribuição é o que torna os dados úteis para depuração ou treinamento.

Como atribuo uma falha multiagente?

A literatura de atribuição de falhas (Zhang et al., Which Agent Causes Task Failures and When?, ICML 2025) enquadra o rótulo como uma tripla: o agente responsável, o passo decisivo e um motivo. No Potato, o esquema failure_attribution preenche os seletores de agente e de passo a partir do próprio trace, então o anotador escolhe entre agentes e passos que de fato ocorreram:

yaml
annotation_schemes:
  - annotation_type: radio
    name: outcome
    description: "Did the system succeed?"
    labels: [success, failure]
  - annotation_type: failure_attribution
    name: attribution
    description: "If it failed: which agent, which step, and why?"
    steps_key: steps
    agent_key: agent

Combinar o esquema de resultado com a atribuição significa que a tripla só é coletada em execuções que de fato falharam.

Como reviso a estrutura da equipe, e não apenas a transcrição?

Duas telas tornam a estrutura visível. O grafo de interação renderiza os agentes como nós e as transferências como arestas, e o anotador marca o caminho crítico e sinaliza as arestas problemáticas. A revisão de transferências transforma cada transferência de controle em um cartão para sinalizar o desalinhamento e avaliar a qualidade:

yaml
annotation_schemes:
  - annotation_type: handoff_review
    name: handoffs
    description: "For each handoff: flag any misalignment and rate the quality."
    steps_key: steps
    agent_key: agent
    flags: [info_loss, dropped_constraint, garbling, goal_drift]
    quality_scale: 5

Para a pontuação, o agent_scorecard avalia cada agente quanto à fidelidade ao papel, contribuição e coordenação, e pontua a equipe em suas próprias dimensões, de modo que um agente individualmente forte dentro de uma equipe mal coordenada fica visível nos números.

Qual método devo usar?

  • Depurando um pipeline: comece com o grafo de interação e a atribuição de falhas para localizar onde as execuções quebram.
  • Comparando padrões de orquestração: adicione o scorecard para pontuar designs sequenciais vs. hierárquicos vs. group-chat nas mesmas tarefas.
  • Construindo dados de treinamento ou de recompensa: marque as falhas com granularidade de passo usando os modos MAST (via trajectory_eval) para que os rótulos se prendam ao agente e ao passo ativos.
  • Bugs de concorrência: use a linha do tempo de contenção de ferramentas para capturar deadlocks e corridas que uma transcrição não consegue mostrar.

Meça a concordância na atribuição da mesma forma que você faria para qualquer rótulo subjetivo; veja Concordância entre anotadores.

Leitura adicional