Resumo Técnico: TeamBench: Avaliando a Coordenação de Agentes sob Separação de Funções Imposta

Declaração do Problema

Os sistemas multiagente atuais construídos sobre Modelos de Linguagem de Grande Escala (LLMs) frequentemente decompõem tarefas entre funções (por exemplo, Planejador, Executor, Verificador) especificadas via prompts. No entanto, os benchmarks existentes geralmente falham em impor essas fronteiras de função, permitindo que um único modelo acesse todas as informações, modifique o espaço de trabalho e certifique a solução simultaneamente. Esse "colapso de função" obscurece se os ganhos de desempenho derivam de uma coordenação genuína ou de um único agente efetivamente desempenhando múltiplas funções. Além disso, permanece incerto quando a separação de funções proporciona valor versus quando introduz sobrecarga ou modos de falha, particularmente quando a função "Verificador" pode simplesmente atuar como outra passagem de edição em vez de um controle de qualidade independente.

Metodologia

Os autores introduzem o TEAMBENCH, um benchmark projetado para avaliar a coordenação de agentes sob separação de funções imposta pelo sistema operacional.

1. Separação de Funções Imposta

Diferentemente de atribuições baseadas apenas em prompts, o TEAMBENCH utiliza sandboxes containerizadas com permissões estritas de sistema de arquivos para isolar três funções distintas:

• Planejador: Lê a especificação completa da tarefa (spec.md), mas não pode modificar o espaço de trabalho ou executar comandos.
• Executor: Pode editar o espaço de trabalho e executar comandos, mas recebe apenas um resumo (brief.md), não a especificação completa.
• Verificador: Revisa a especificação completa e evidências somente de leitura do Executor (logs, estado do espaço de trabalho) para emitir um veredito final de aprovação/reprovação. Não pode modificar o espaço de trabalho ou executar comandos.

Nenhuma função única possui as três capacidades (ler especificação completa, editar espaço de trabalho, certificar resposta) simultaneamente. A informação deve fluir entre as funções para a conclusão da tarefa.

2. Construção de Tarefas

• Escala: 851 modelos de tarefa expandindo para 931 instâncias de avaliação com sementes.
• Fontes: 650 relatórios de bugs do GitHub (por exemplo, Flask, Django, NumPy), 30 tarefas de ciência de dados, 10 tarefas de resposta a incidentes e 161 modelos originalmente autorais.
• Design: As tarefas são construídas para exigir assimetria de informação. Restrições críticas existem apenas na especificação completa, tornando-as invisíveis ao Executor a menos que retransmitidas pelo Planejador.
• Modos de Falha: As tarefas cobrem requisitos de retransmissão, armadilhas adversariais, implementações abertas, tarefas de descoberta e tarefas de síntese.

3. Condições de Ablação

O benchmark avalia modelos sob cinco condições para isolar contribuições marginais:

• Solo: Agente único com acesso total.
• Restrito: Agente único com apenas ferramentas de Executor (sem especificação completa).
• Equipe Completa: Planejador + Executor + Verificador.
• Equipe, Sem Planejamento: Executor + Verificador (Verificador detém a especificação completa).
• Equipe, Sem Avaliação: Planejador + Executor (sem Verificador).

O Índice de Necessidade de Trabalho em Equipe (TNI) é definido para medir quanto desempenho é recuperado quando requisitos ausentes devem ser retransmitidos através da equipe.

4. Configuração Experimental

• Modelos: 13 modelos em quatro famílias (Anthropic, Google, OpenAI, Alibaba).
• Mistura de Funções: Uma grade entre provedores (27 configurações) testando diferentes atribuições de modelos às funções.
• Estudo Humano: Um estudo piloto com 40 sessões envolvendo humanos nos modos Solo, Híbrido (humano + agentes) e Equipe (três humanos) sob as mesmas fronteiras de função.

Principais Resultados

1. Valor Condicional da Equipe

• Baixo Desempenho Solo: Equipes superam significativamente agentes únicos quando o agente Solo luta (quintil mais baixo de pontuação Solo). A Equipe Completa superou o Solo em 15,7 pontos nas tarefas mais difíceis.
• Alto Desempenho Solo: Equipes frequentemente prejudicam o desempenho em tarefas onde o agente Solo já performa bem. No quintil mais alto, a Equipe Completa ficou atrás do Solo em 6,8–10,1 pontos.
• Mecanismo: O Planejador ajuda quando o Executor carece de estrutura, mas o Verificador frequentemente introduz "retrabalho" ou sobrescreve soluções corretas em tarefas que o Executor poderia ter resolvido sozinho.

2. Falha do Verificador como Gargalo

• Aprovação Falsa: Verificadores aprovam 49,4% das submissões que falham no avaliador determinístico.
• Assimetria: Verificadores raramente rejeitam trabalhos aprovados (taxa de rejeição falsa < 19%), mas frequentemente aceitam trabalhos que falham.
• Impacto: Remover o Verificador em estudos de ablação realmente melhorou a pontuação parcial média em 5,5 pontos, indicando que o Verificador atua como um gargalo em vez de um controle de qualidade nos protocolos atuais.

3. Apenas Prompts vs. Funções Impostas

• Taxas de Aprovação: Equipes baseadas apenas em prompts e equipes impostas por sandbox alcançaram taxas de aprovação estatisticamente indistinguíveis.
• Diferenças Comportamentais: Execuções baseadas apenas em prompts produziram 3,6 vezes mais casos onde o Verificador tentou editar o código do Executor (tomada de função). A imposição reduziu essas violações, sugerindo que as taxas de aprovação por si só mascaram diferenças significativas na adesão às funções e no comportamento de coordenação.

4. Mistura entre Provedores

• Equipes mistas entre provedores podem alcançar taxas de aprovação similares ou melhores a custos significativamente menores. Por exemplo, uma equipe mista (Planejador Google, Executor Anthropic, Verificador Anthropic) alcançou uma taxa de aprovação de 26,7% a aproximadamente metade do custo de uma equipe totalmente Anthropic.
• A escolha dos modelos Executor e Verificador importa mais do que a escolha do Planejador.

5. Insights do Estudo Humano

• Colapso Híbrido: Sessões híbridas humano-IA frequentemente colapsaram em um padrão de "aprovação rápida" (mediana de 3 minutos), com humanos auto-atestando aprovações em altas taxas apesar de falhas estruturais no avaliador.
• Equipes Humanas: Equipes humanas gastaram mais tempo coordenando informações ausentes entre funções (mediana de 26 minutos) e citaram "informações ausentes entre funções" como um fator primário de falha, espelhando as restrições de design do benchmark.
• Percepção do Verificador: Humanos classificaram a função de Verificador como altamente valiosa, contrastando com as altas taxas de falha observadas em Verificadores LLM.

Principais Contribuições

1. Benchmark de Coordenação com Separação de Funções: Introdução do TEAMBENCH, que usa permissões de nível de sistema operacional para impor separação estrita de acesso à especificação, edição de espaço de trabalho e certificação, prevenindo o colapso de função.
2. Ablações Correspondentes: Um framework para isolar o valor marginal de planejamento, verificação e acesso à especificação através de condições de ablação controladas (Solo, Restrito, Equipe Completa, Sem Planejamento, Sem Avaliação).
3. Análise de Falha do Verificador: Evidência empírica de que Verificadores LLM atuais são controles de qualidade pouco confiáveis, aprovando quase metade das submissões que falham no avaliador, e que sua presença pode degradar o desempenho em tarefas solucionáveis por um único agente.
4. Métricas Comportamentais Além da Taxa de Aprovação: Demonstração de que as taxas de aprovação podem ocultar padrões distintos de interação (por exemplo, violações de função, tentativas de edição de código) e que o valor da equipe é condicional à capacidade do agente único subjacente.

Significado e Alegações

O artigo argumenta que a taxa de aprovação sozinha é insuficiente para avaliar sistemas multiagente. Uma equipe pode alcançar uma alta taxa de aprovação não através de coordenação, mas através de um único modelo desempenhando todas as funções ou de um Verificador falhar em rejeitar erros.

• Coordenação é Condicional: Equipes fornecem melhoria positiva principalmente quando agentes únicos carecem do contexto para fazer progresso. Quando agentes únicos são capazes, adicionar funções frequentemente adiciona sobrecarga e pontos de falha.
• A Imposição Importa: Embora funções baseadas apenas em prompts e funções impostas possam gerar taxas de aprovação similares, a imposição revela diferenças comportamentais críticas, como a frequência de violações de função (por exemplo, Verificadores reescrevendo código).
• Confiabilidade do Verificador: A alta taxa de aprovação falsa dos Verificadores sugere que benchmarks multiagente que dependem de juízes LLM para conclusão de marcos podem superestimar as saídas. Sistemas futuros exigem verificação assistida por ferramentas ou atestados baseados em evidências.
• Comparação Humano-IA: O estudo humano destaca que a "aprovação rápida" é um modo de falha em configurações híbridas, e que a divisão estrutural da informação (especificação vs. espaço de trabalho) é uma barreira dominante tanto para humanos quanto para agentes.

Os autores concluem que o TEAMBENCH fornece uma infraestrutura necessária para avaliar se agentes adicionais realizam trabalho distinto ou meramente replicam capacidades existentes, oferecendo um padrão mais rigoroso para benchmarks multiagente.