Resumo Técnico: LEMON

Definição do Problema

Sistemas multiagente (MAS) baseados em Modelos de Linguagem de Grande Escala (LLM) dependem fortemente do design de orquestração — especificamente a definição de papéis dos agentes, atribuições de capacidade e estruturas de dependência — para determinar a qualidade da solução e a eficiência de execução. As abordagens existentes enfrentam duas limitações primárias:

1. Design Decomposto: Os métodos atuais frequentemente otimizam componentes de orquestração (topologia, fluxo de trabalho, roteamento) separadamente ou sequencialmente. Isso falha em tratar o design de papéis, a atribuição de capacidade e a construção de dependências como decisões mutuamente dependentes dentro de uma única especificação executável, potencialmente levando a sistemas subótimos ou ineficientes.
2. Atribuição de Crédito Esparsa: Os sinais de treinamento para orquestradores são tipicamente anexados a resultados de execução de ponta a ponta (por exemplo, sucesso final da tarefa). Esse feedback "esparso" torna difícil determinar quais decisões locais específicas (por exemplo, uma definição de papel específica ou um único link de dependência) contribuíram para o sucesso ou fracasso, levando à confusão entre escolhas necessárias e incidentais durante as atualizações da política.

Metodologia: LEMON

Os autores propõem o LEMON (Learning Executable Multi-agent OrchestratioN via Counterfactual Reinforcement Learning — Aprendizado de Orquestração Multiagente Executável via Aprendizado por Reforço Contrafactual), um framework que trata a orquestração de MAS como a geração de uma única especificação executável.

1. Geração de Orquestração Executável Composicional

Em vez de otimizar componentes isolados, a política do LEMON ($\pi_\theta$) gera uma especificação estruturada em YAML para cada tarefa de entrada. Esta especificação define simultaneamente:

• Agentes: O conjunto de trabalhadores a serem instanciados.
• Papéis: Deveres específicos da tarefa, papéis base herdados e responsabilidades personalizadas.
• Capacidade: O tamanho específico do modelo LLM (por exemplo, Pequeno, Médio, Grande) atribuído a cada agente.
• Dependências: A estrutura de fluxo de informações (arestas) conectando os agentes.

A especificação é validada contra um esquema, compilada em um grafo acíclico direcionado (DAG) e executada por agentes trabalhadores.

2. Pipeline de Treinamento

O LEMON emprega um processo de treinamento em duas etapas:

• Ajuste Fino Supervisionado (SFT): A política é inicializada usando especificações YAML executáveis geradas por um professor. Isso garante que o modelo possa produzir saídas válidas e compatíveis com o esquema antes do início do aprendizado por reforço, reduzindo a frequência de execuções inválidas.
• Aprendizado por Reforço (RL): A política é otimizada usando uma combinação de objetivos globais e localizados:

  • Recompensa Global no Nível de Orquestração (GRPO): O sistema utiliza Otimização de Política Relativa em Grupo (GRPO) baseada na utilidade de execução. A recompensa ($R_{orch}$) combina sucesso da tarefa, eficiência de tokens (uso de tokens pelo trabalhador) e custo estrutural (contagem de agentes/dependências).

  • Atribuição de Crédito Contrafactual Localizada: Para abordar a atribuição de crédito esparsa, o LEMON introduz um mecanismo contrafactual. Para uma especificação gerada válida, o sistema aplica uma "mutação" a um único campo:

    • Deleção de Dependência: Remover uma referência para testar a necessidade.
    • Reversão de Papel: Reverter um dever personalizado para um papel base.
    • Degradar Capacidade: Reduzir o tamanho do modelo atribuído a um agente.

    A especificação mutada (contrafactual) é executada e a diferença de recompensa ($\Delta_c$) é calculada. Este contraste de recompensa é aplicado apenas aos intervalos de tokens editados na especificação original. Isso permite que a política aprenda quais decisões locais específicas impulsionaram a mudança de desempenho, em vez de reforçar toda a sequência indiscriminadamente.

Contribuições Principais

1. Geração de Orquestração Composicional: O artigo formula a orquestração de MAS como a geração de uma especificação executável unificada que compõe o design de papéis, perfis de capacidade e estrutura de dependência, em vez de otimizar essas decisões isoladamente.
2. Aprendizado por Reforço Contrafactual Localizado: Os autores introduzem um método para converter diferenças de recompensa no nível de execução em supervisão no nível de intervalo. Ao editar campos específicos de orquestração e comparar recompensas, o sistema atribui crédito às decisões específicas responsáveis pelas variações de desempenho, mitigando o problema da atribuição de crédito esparsa.
3. Validação Empírica: Experimentos extensivos demonstram que o LEMON supera o prompting de agente único, MAS de estrutura fixa, métodos de design de topologia e baselines de fluxo de trabalho adaptativo em benchmarks de raciocínio e codificação.

Resultados Experimentais

Os autores avaliaram o LEMON em seis benchmarks: MMLU, GSM8K, AQuA, MultiArith, SVAMP e HumanEval.

• Desempenho: O LEMON alcançou uma pontuação média state-of-the-art de 90,72%, superando a baseline de agente único mais forte (SC-CoT, 86,76%), o MAS de estrutura fixa mais forte (Tree-MAS, 88,53%) e a baseline de design de topologia mais forte (AgentPrune, 88,13%). Alcançou os melhores resultados em cinco dos seis benchmarks.
• Eficiência de Tokens: O LEMON demonstrou trade-offs superiores de precisão para tokens. Em benchmarks como MMLU e AQuA, alcançou alta precisão com significativamente menos tokens de trabalhador em comparação com baselines de topologia de alto custo, frequentemente situando-se na ou perto da fronteira de Pareto.
• Estudos de Ablação:
  • Remover o objetivo contrafactual localizado (Apenas RL Global) resultou em menor precisão e maior uso de tokens.
  • Remover componentes específicos de geração (Papel, Capacidade ou Estrutura) consistentemente degradou o desempenho, confirmando a necessidade de otimização conjunta.
  • Remover o início quente SFT causou uma queda drástica de desempenho (por exemplo, a precisão no MMLU caiu de 84,32% para 48,53%), destacando a importância da inicialização para uma exploração válida.
• Estudos de Caso: A análise qualitativa mostrou que o LEMON gera estruturas alinhadas à tarefa (por exemplo, etapas de raciocínio específicas para problemas de matemática) em vez de papéis genéricos e repetidos frequentemente encontrados em outros métodos.

Significado e Alegações

O artigo alega que o LEMON avança o campo ao deslocar o foco da otimização de decisões isoladas de topologia ou fluxo de trabalho para a própria especificação executável. Ao gerar conjuntamente papéis, capacidades e dependências, e ao utilizar sinais contrafactuais localizados para refinar essas decisões, o LEMON produz sistemas multiagente que são tanto mais eficazes (maior precisão) quanto mais eficientes (menor custo de tokens) do que os métodos existentes de orquestração adaptativa. Os autores enfatizam que essa abordagem fornece uma maneira mais sistemática de construir especificações de orquestração adaptativas à tarefa, tornando os sistemas multiagente mais fáceis de estudar e implantar sob orçamentos de recursos controlados.

Os autores notam limitações, incluindo o custo de treinamento não trivial associado à avaliação contrafactual (embora a inferência permaneça eficiente) e o foco atual em benchmarks de raciocínio e codificação baseados em texto, deixando cenários mais amplos, como o uso de ferramentas de longo horizonte, para trabalhos futuros.