Un ingénieur IA écrit une seule fonction de récompense pour des équipes d'agents : le taux de victoire passe de 51% à 90%

On ne peut apprendre à une équipe de robots ou d'unités de jeu à agir de concert qu'à condition de leur signaler à temps ce qu'ils font correctement. Ces signaux s'appellent la fonction de récompense. Si l'on ne récompense que la victoire finale, les agents comprennent à peine quelles actions y ont mené.

Les ingénieurs ajoutent donc à la main des récompenses intermédiaires, puis les refont de zéro dès que la carte ou la composition de l'équipe change. D. Ourgoun, de l'université de Karabük (Turquie), propose la méthode GARDEN, qui délègue ce travail à un modèle de langage.

Elle va plus loin que les systèmes précédents : la récompense est écrite une seule fois pour toute une famille de scénarios proches, puis transférée à de nouveaux scénarios sans la moindre modification.

Ce qui a été testé et quels sont les chiffres

La méthode a été évaluée dans la bibliothèque JaxMARL, sur deux benchmarks.

• Overcooked. Deux cuisiniers préparent une soupe dans une cuisine exiguë : ils mettent les ingrédients dans la marmite, sortent le plat cuit et apportent l'assiette. La récompense standard accorde 20 points par plat, plus de petits bonus pour les étapes intermédiaires : 3 par ingrédient dans la marmite, 3 par assiette, 5 par soupe prête. La disposition des plans de travail détermine comment les cuisiniers se répartissent la tâche.
• SMAX. Il s'agit du benchmark StarCraft Multi-Agent Challenge réécrit en JAX : un groupe d'unités alliées affronte des ennemis pilotés par des scripts intégrés. La récompense vaut 1 si les ennemis sont détruits et si au moins une unité alliée a survécu. La moyenne sur les épisodes correspond au pourcentage de victoires. Le bonus standard est attribué pour les dégâts infligés aux ennemis.

Quatre scénarios étaient nouveaux pour la récompense. Dans Overcooked, deux agencements de cuisine : l'un avec un comptoir de séparation, l'autre avec un comptoir central. Dans SMAX, un combat contre une équipe de marines élargie et un combat avec des types d'unités et des positions de départ aléatoires. Sur ces scénarios, le résultat final d'Overcooked dépasse celui de la récompense standard de 58,2% et 52,5%. Le pourcentage moyen de victoires dans SMAX passe de 51,0% à 89,9%. Pour comparaison, deux approches ont été retenues, avec le même nombre de candidats et d'essais. Un rapport de diagnostic fixe atteint 84,2%, et une réflexion de type Eureka (le modèle corrige la récompense à partir des statistiques d'entraînement) atteint 79,2%.

Comment le modèle cherche lui-même ce qui cloche dans la récompense

Dans la plupart des méthodes antérieures, Eureka comprise, le format du retour d'information est fixé d'avance : le modèle reçoit des courbes d'entraînement agrégées et réécrit le code à partir d'elles. Si le problème de coordination n'y apparaît pas, il passe inaperçu. Dans GARDEN, le LLM-ingénieur travaille comme un humain dans un terminal. Via un interpréteur de commandes restreint, il lit le code source de l'environnement et de l'algorithme, la logique de la récompense standard, les configurations, les trajectoires, les pertes et les checkpoints. Au besoin, il écrit ses propres scripts d'analyse. On ne lui fournit aucune liste de vérifications toute faite.

Il teste ses hypothèses par des entraînements d'essai : un nombre limité de lancements du brouillon sur l'un des scénarios de développement, avec le même algorithme, le même budget et la même graine aléatoire que dans l'évaluation finale. À chaque version de la récompense, le modèle joint un court rapport : quelles données il a examinées, quel mécanisme il suppose et quelles sont les faiblesses.

Le processus avance par générations de candidats :

• Chaque candidat travaille dans une session indépendante et ne voit ni les brouillons ni les essais de ses « frères » de la même génération. Il a accès aux résultats des générations précédentes.
• Une fois la version figée, elle est entraînée et évaluée sur chaque scénario de développement.
• La récompense finale est choisie par une formule : l'amélioration moyenne par rapport à la récompense standard sur les scénarios de développement. En cas d'égalité, on regarde le pire scénario, puis le résultat moyen, puis l'identifiant. Les préférences du modèle et les données des nouveaux scénarios n'interviennent pas dans le choix.
• Le code retenu est figé, son hash est calculé, et de nouveaux agents sont entraînés de zéro sur les scénarios cachés.

Le modèle ne connaît pas le numéro du scénario et doit le déduire de la géométrie de la carte ou de la composition de l'équipe. Il peut lire le code de la récompense standard, mais ne peut pas l'appeler depuis son propre code. La « mémoire » apprenable de la récompense est limitée et réinitialisée au début de chaque épisode. Les scénarios cachés sont protégés par des dossiers de travail nettoyés et par un journal des actions.

Ce que cela apporte en pratique et où sont les limites

Le transfert porte ici sur la récompense elle-même, et non sur les politiques entraînées : sur les nouvelles cartes, les agents sont réentraînés. Les auteurs soulignent qu'ils mesurent la généralisation du signal d'apprentissage. Pour les ingénieurs, c'est un gain de temps : une seule récompense écrite automatiquement peut remplacer une réécriture pour chaque agencement ou chaque composition d'escouade. Cela compte particulièrement en robotique et en logistique, où la configuration des équipes varie.

Les limites existent. Les expériences couvrent deux familles de tâches et quatre scénarios cachés. L'auteur ne donne aucune garantie de transfert : le choix repose sur les données de développement, et les résultats sur les scénarios cachés sont inconnus d'avance. Pour une comparaison équitable, le shaping standard d'Overcooked est resté constant, alors qu'il s'atténue dans la configuration de référence de JaxMARL. Il reviendra à la communauté de tester la méthode sur d'autres environnements : le code, les prompts et les configurations se trouvent dans le dépôt ouvert DoganUrgun/GARDEN.