Engenheiro de IA escreve uma só função de recompensa para equipes de agentes: taxa de vitória sobe de 51% para 90%

Treinar uma equipe de robôs ou de unidades de jogo para agir em conjunto só funciona se for possível avisá-los, na hora certa, de que estão fazendo a coisa certa. Essas dicas se chamam função de recompensa. Se o pagamento vier apenas pela vitória final, os agentes quase não entendem quais ações levaram até ela.

Por isso, os engenheiros adicionam incentivos intermediários manualmente e os refazem do zero sempre que o mapa ou a composição da equipe muda. D. Urgun, da Universidade de Karabük (Turquia), propôs o método GARDEN, que transfere esse trabalho para um modelo de linguagem.

Ele vai além dos sistemas anteriores: a recompensa é escrita uma única vez para toda uma família de cenários parecidos e transferida para os novos sem nenhuma edição.

O que foi testado e quais foram os números

O método foi testado na biblioteca JaxMARL, em dois benchmarks.

• Overcooked. Dois cozinheiros preparam sopa numa cozinha apertada: colocam ingredientes na panela, retiram o prato pronto e levam o prato até a entrega. A recompensa padrão dá 20 pontos por prato e pequenos bônus por etapas intermediárias: 3 por ingrediente na panela, 3 por prato e 5 por sopa pronta. A disposição das bancadas determina como os cozinheiros dividem o trabalho.
• SMAX. É uma versão do benchmark StarCraft Multi-Agent Challenge reescrita em JAX: um esquadrão de unidades aliadas enfrenta inimigos controlados por scripts embutidos. A recompensa é 1 se os inimigos forem destruídos e pelo menos uma unidade aliada sobreviver. A média por episódio coincide com a taxa de vitórias. O bônus padrão é concedido pelo dano causado aos inimigos.

Quatro cenários eram novos para a recompensa. No Overcooked, duas disposições de cozinha: uma com bancada divisória e outra com bancada central. No SMAX, um combate contra um grupo ampliado de fuzileiros e um combate com tipos e posições iniciais aleatórios das unidades. Nesses cenários, o retorno total no Overcooked ficou 58,2% e 52,5% acima da recompensa padrão. A taxa média de vitórias no SMAX subiu de 51,0% para 89,9%. Para comparação, foram usadas duas abordagens com o mesmo número de candidatos e de execuções de prova. Um relatório diagnóstico fixo chegou a 84,2%, e a reflexão no estilo Eureka (o modelo corrige a recompensa com base nas estatísticas de treinamento) chegou a 79,2%.

Como o modelo descobre sozinho o que há de errado com a recompensa

Na maioria dos métodos anteriores, incluindo o Eureka, o formato do feedback é definido de antemão: o modelo recebe curvas de treinamento resumidas e reescreve o código com base nelas. Se o problema de coordenação não aparece nessas curvas, ele passa despercebido. No GARDEN, o LLM-engenheiro trabalha como uma pessoa no terminal. Por meio de um shell de comandos restrito, ele lê o código-fonte do ambiente e do algoritmo, a lógica da recompensa padrão, as configurações, as trajetórias, as perdas e os checkpoints. Quando necessário, escreve seus próprios scripts de análise. Não recebe uma lista pronta de verificações.

As hipóteses são testadas com treinamentos de prova. Trata-se de um número limitado de execuções do rascunho em um dos cenários de desenvolvimento, com o mesmo algoritmo, o mesmo orçamento e a mesma seed aleatória da avaliação final. A cada versão da recompensa, o modelo anexa um relatório curto: quais dados examinou, qual mecanismo supõe e quais são os pontos fracos.

O processo avança por gerações de candidatos:

• Cada candidato trabalha em uma sessão independente e não vê os rascunhos nem as provas dos "irmãos" da mesma geração. Os resultados das gerações anteriores ficam disponíveis para ele.
• Depois que a versão é fixada, ela é treinada e avaliada em cada cenário de desenvolvimento.
• A recompensa final é escolhida por uma fórmula: a melhora média sobre a recompensa padrão nos cenários de desenvolvimento. Em caso de empate, olha-se o pior cenário, depois o resultado médio e, por fim, o identificador. As preferências do modelo e os dados dos novos cenários não participam da escolha.
• O código escolhido é congelado, seu hash é calculado e novos agentes são treinados do zero nos cenários ocultos.

O modelo não sabe o número do cenário e precisa inferi-lo a partir da geometria do mapa ou da composição da equipe. Ele pode ler o código da recompensa padrão, mas não pode chamá-lo a partir do próprio código. A "memória" treinável da recompensa é limitada e zerada no início de cada episódio. Os cenários ocultos são protegidos por pastas de trabalho limpas e por um registro de ações.

O que isso muda na prática e onde estão os limites

A transferência aqui diz respeito à própria recompensa, e não às políticas treinadas: nos novos mapas, os agentes são treinados de novo. Os autores ressaltam que medem a generalização do sinal de aprendizado. Para os engenheiros, isso significa economia: uma única recompensa escrita automaticamente pode substituir a reescrita para cada disposição ou composição de esquadrão. Para robótica e logística, com configurações de equipe variáveis, isso é especialmente importante.

Há limitações. Os experimentos cobrem duas famílias de tarefas e quatro cenários ocultos. O autor não oferece garantias de transferência: a escolha se baseia em dados de desenvolvimento, e os resultados nos cenários ocultos não são conhecidos de antemão. Para uma comparação justa, o shaping padrão no Overcooked foi mantido constante, embora na configuração de referência do JaxMARL ele decaia. Caberá à comunidade testar o método em outros ambientes: o código, os prompts e as configurações estão no repositório aberto DoganUrgun/GARDEN.