Une équipe entraîne un agent sur les parties d’autres joueurs et termine 436e à Kaggriculture

La nouvelle version de l’agent a gagné davantage d’argent. Peut-on la mettre à disposition des utilisateurs ? Il est encore trop tôt : elle a peut-être bénéficié d’un marché plus favorable. Des participants à Kaggriculture se sont précisément heurtés à ce problème. Ils ont comparé les versions sur des parties identiques, puis appris au modèle à reproduire les décisions de joueurs expérimentés. Cette démarche est utile aux développeurs d’agents : il faut d’abord disposer d’un moyen de mesurer les changements, avant de choisir une architecture.

Dans une analyse publiée sur Habr, l’équipe indique avoir terminé 436e sur 10 148 équipes et remporté une médaille d’argent. En deux mois, les participants ont testé six approches, allant de règles prédéfinies à un transformer d’environ 20 millions de paramètres. Selon leur évaluation, le modèle le plus performant était un transformer entraîné par clonage comportemental, ou behavior cloning : à partir de l’état du jeu, il apprenait à sélectionner les actions issues de parties enregistrées.

Distinguer d’abord la qualité de l’agent des conditions de marché favorables

Dans Kaggriculture, deux agents gèrent des fermes voisines et vendent leur production sur un marché commun. Au bout de 30 jours de jeu, celui qui possède le plus d’argent gagne. Si les deux produisent beaucoup de lait, son prix baisse. Si une boutique de fils à tricoter ouvre, elle crée une demande supplémentaire de laine. Produire davantage ne suffit pas : il faut comprendre ce qui pourra se vendre.

Les commerces présents sont déterminés aléatoirement et influencent fortement les revenus. Dans l’échantillon étudié par l’équipe, la partie elle-même expliquait 88,8 % de la variance de la trésorerie finale. Cela ne signifie pas que le hasard détermine 88,8 % des victoires : cet indicateur décrit la dispersion des sommes gagnées.

Pour comparer les versions, les développeurs reconstituaient une partie avec la même graine du générateur de nombres aléatoires. Le nouvel agent remplaçait l’ancien, tandis que l’adversaire rejouait ses actions enregistrées. Ils comptaient ensuite combien de défaites devenaient des victoires et combien de victoires étaient perdues.

Cette méthode présente une limite importante : l’adversaire enregistré ne réagit pas au nouveau comportement. Ce banc d’essai permet de sélectionner les modifications, mais ses résultats ne peuvent pas être présentés comme un taux de victoire dans un tournoi avec des adversaires réactifs. Pour une équipe produit, l’analogie est claire : un ensemble fixe de tâches facilite la comparaison des versions, mais il faut aussi tester séparément les interactions avec un environnement changeant.

Copier les exemples s’est révélé utile, mais seulement au début

La première méthode d’imitation ne nécessitait pas d’entraîner un réseau de neurones. L’équipe avait rassemblé 782 enregistrements de parties d’un joueur performant. L’agent recherchait une situation similaire selon la disposition des objets, les commerces et les prix récents, puis reproduisait l’action tirée de l’enregistrement correspondant.

Cela fonctionnait bien en début de partie, car les ouvertures se répétaient souvent. Plus tard, les états du jeu divergeaient et les suites adaptées devenaient plus rares. Lors des tests dans les états exacts rencontrés par le joueur d’origine, la copie reproduisait ses actions dans 85 % des cas entre les jours 6–14, puis dans seulement 2,5 % des cas à partir du 15e jour.

Ce constat fournit un diagnostic utile aux développeurs. Un agent peut maîtriser le début familier d’un processus, puis perdre ses repères après quelques décisions prises de lui-même. Une précision moyenne ne suffit donc pas : il faut examiner séparément les étapes de la tâche et les moments où les exemples pertinents viennent à manquer.

Le réseau de neurones avait besoin de décisions cohérentes

L’étape suivante a été un transformer. L’état de la ferme était représenté par 197 tokens : cases, ouvriers, marchandises, marché et autres entités. Le modèle recevait des informations sur les deux fermes, tandis qu’une mémoire conservée entre les tours lui permettait de tenir compte des observations et des actions précédentes.

L’entraînement a révélé un problème d’annotation. Plusieurs chemins de même longueur pouvaient mener à une case, mais l’enregistrement n’en contenait qu’un seul. L’équipe a modifié la fonction de perte pour que le modèle ne soit pas pénalisé lorsqu’il choisissait un autre déplacement équivalent vers le même objectif. La leçon pratique est simple : lorsque plusieurs bonnes décisions sont possibles, l’apprentissage doit en tenir compte.

Mélanger les enregistrements de joueurs performants ne garantissait pas non plus une amélioration. Leurs stratégies reposaient sur des investissements différents : une action pertinente après l’achat de terres pouvait ne pas convenir à une ferme ayant dépensé son argent dans des animaux. Lors des premières expériences, le modèle faisait la moyenne de ces décisions et jouait moins bien.

Ce cas propose une démarche concrète pour expérimenter avec des agents : construire une version de référence simple, préparer des scénarios reproductibles, vérifier la cohérence des démonstrations et analyser les erreurs par étape. Une médaille d’argent dans une simulation de jeu ne prouve pas que la méthode est prête pour des applications métier. Mais les vérifications décrites aident à comprendre pourquoi une complexification supplémentaire du modèle a réellement fonctionné, ou a simplement paru convaincante.