Étude de cas, projet personnel

Leon

Un agent qui joue seul, du premier bloc de bois à l’armure en netherite.

Un programme autonome qui joue à Minecraft sans personne aux commandes, piloté par un plan de progression déterministe et par un modèle de langage qui tourne sur ma propre machine. Sans service distant ni clé d’API.

Parler de ce projet

En clair

Un programme qui joue à Minecraft tout seul, en suivant un plan étape par étape, et qui n’appelle une intelligence artificielle que quand il est bloqué. Ce n’est pas le jeu qui m’intéressait, mais la façon de faire cohabiter une règle stricte et un modèle imprévisible.

Le détail technique suit.

Le problème posé

Faire jouer un programme à un jeu ouvert met face à face deux approches qui échouent chacune de leur côté. Un modèle de langage laissé seul invente des recettes qui n’existent pas et perd sa position en quelques minutes. Un script seul ne tient pas non plus, parce que le jeu fabrique en permanence des situations qu’aucune cascade de conditions n’avait prévues.

Toute la difficulté tient donc au partage : qui décide, à quel moment, et qui a le dernier mot. C’est un problème d’ordonnancement et d’arbitrage bien avant d’être un problème de jeu vidéo.

Ce que j’ai écrit

Une couche de décision complète, écrite par-dessus une base ouverte existante.

Partage des rôles

Le modèle n’a jamais les commandes

Un plan de progression en huit paliers, du bois jusqu’au netherite, empêche de sauter une étape : partir chercher du diamant sans équipement complet revient à mourir en boucle. Ce plan est déterministe, donc reproductible d’une session à l’autre.

Le modèle n’est réveillé que sur blocage avéré, et son autorité est plafonnée à trois tentatives avant que le plan ne reprenne la main de force. L’arbitrage se joue sur le numéro de palier, et non sur une recherche de mots dans un texte d’état.

Le principe, et il revient partout chez moi

Quatre de mes projets font tourner un modèle de langage, et aucun ne lui confie le pilotage. Ici, il est plafonné à trois interventions. Ailleurs, il se contente de traduire une phrase du joueur. Ailleurs encore, il lui est interdit de toucher aux émotions. Et sur mon outil juridique, il n’intervient qu’à la toute dernière étape, une fois le calcul fait par du code.

Savoir où ne pas mettre un modèle sert davantage que savoir en brancher un. Deux de ces quatre projets tournent d’ailleurs en local, sans qu’aucune donnée ne sorte de la machine.

Conception

Apprendre à un programme à s’en tenir à sa décision

L’agent faisait des allers-retours entre deux filons et laissait du minerai à moitié extrait. Le code n’était pas en cause : deux mécanismes se combattaient sans arbitre. La boucle de décision reprenait son raisonnement de zéro à chaque tour, comme si observer à nouveau obligeait à décider à nouveau, pendant que le système d’interruption l’autorisait à tout lâcher en cours de route.

J’ai ajouté une couche d’intention. L’agent retient ce qu’il a décidé de faire, la ressort avant toute nouvelle délibération, et ne peut se la faire voler que par une cible à la fois plus importante et deux fois plus proche.

Arbitrage

Cet engagement est volontairement limité : il tombe si la cible s’éloigne, au bout d’un temps donné, ou après deux tours sans le moindre progrès.

Sans ces limites, on ne fait que remplacer un défaut par son symétrique : à force de vouloir supprimer les hésitations, on récolte de l’entêtement, ce qui est pire.

Fiabilité

Revoir ce que l’agent avait sous les yeux au moment de décider

Pour juger un programme autonome, la console ne sert à rien : elle raconte ce qu’il a fait, jamais ce qu’il percevait au moment de le décider. C’est pourtant la seule chose qui sépare une mauvaise décision d’un coup de malchance.

Chaque décision écrit donc sa propre ligne dans un journal : ce que l’agent avait en main, où il en était, ce qu’il voyait réellement autour de lui, puis le résultat, et surtout ce que son inventaire a gagné ou perdu. Un rapport relit ce journal en flux, pour qu’une session de plusieurs heures n’ait pas à tenir en mémoire, et répond à trois questions : où part le temps, qu’est-ce qui tourne en rond, et à quel moment le modèle est intervenu.

Détail qu’on ne rencontre qu’en conditions réelles : l’horloge repart à zéro à chaque redémarrage de l’agent. Sans correction, une étape à cheval sur un redémarrage affiche une durée négative.

Ce que ces mesures ont révélé

Le modèle était structurellement hors d’atteinte. Des garde-fous filtraient sur un bloc de texte entier, si bien qu’un simple mot placé n’importe où faisait sauter une étape complète, et trois paliers se trouvaient exclus sans condition.

Le relevé donne une seule sollicitation du modèle sur toute une session, et elle portait sur une étape que l’agent n’avait même pas atteinte. La moitié de l’architecture ne servait à rien, sans que rien ne l’indique. Sans le journal, ça pouvait durer des mois.

L’état du chantier

L’agent parcourt la progression complète et tient sur des sessions longues. La dernière campagne d’observation a duré quatre heures dans un monde neuf, et a livré le diagnostic le plus intéressant du projet : un blocage qui ne venait d’aucune action, mais de l’ordonnanceur lui-même. Plus personne ne pouvait réveiller personne, et le programme tournait quand même en apparence normalement.

La suite tient en deux chantiers : des tests automatiques, qui remplaceront des rejeux d’état faits à la main, et l’élargissement du périmètre de jeu.

← Tous les travaux Projet suivant : Kartenn