Environnement d’apprentissage Factorio – des agents qui construisent des usines

 (jackhopkins.github.io)
1 points par GN⁺ 2025-03-12 | 1 commentaires | Partager sur WhatsApp
  • FLE 0.3.0, qui utilise le jeu d’automatisation d’usines Factorio pour évaluer la planification à long terme et le raisonnement spatial des agents, a été publié ; une démo reliant Claude Code à Factorio est également incluse
  • La nouvelle version facilite les expériences de recherche avec une exécution headless, un moteur de rendu d’observations en pixels, une interface compatible OpenAI Gym, l’exécution d’évaluations en CLI, ainsi que la journalisation Weights and Biases et des outils d’analyse
  • L’agent d’exemple atteint l’objectif de production de 16 iron gear wheels par minute en déboguant de façon itérative la production d’électricité, l’extraction de minerai de fer, la fonte, le placement de machines d’assemblage et la connexion des tapis roulants
  • Le benchmark Lab-play évalue Pass@8 sur des modèles puissants en date de septembre 2025, avec des objectifs de production de 16 unités par minute pour les objets solides et 250 unités par minute pour les fluides, ainsi qu’une limite maximale de 64 étapes
  • Les modèles frontier se sont améliorés par rapport à la v0.2.0, mais le transport manuel, les buffers de coffres, le mauvais usage de l’API et les erreurs d’appréciation de l’état dynamique du jeu persistent ; Factorio reste donc un environnement exigeant qui révèle les capacités de planification à long terme et de récupération dynamique

Ce qui change dans FLE 0.3.0

  • FLE 0.3.0 est une mise à jour majeure de l’environnement d’apprentissage qui teste la planification à long terme, le raisonnement et la modélisation du monde à travers des tâches de construction d’usines dans Factorio
  • Dans le précédent article FLE, les modèles frontier avaient montré des difficultés à s’adapter à des environnements changeants, à fixer des objectifs de long terme et à récupérer dynamiquement ; la version 0.2.0 avait introduit le multi-agent, des agents avec backtracking et la vision
  • Principaux changements de la version 0.3.0 :
    • Claude Code est connecté à Factorio via FLE et présenté en démonstration sur Twitch
    • Suppression de la dépendance au client de jeu Factorio, avec prise en charge du passage à l’échelle headless pour les expériences à grande échelle
    • Un nouveau moteur de rendu de jeu headless fournit des observations en pixels réalistes pour la recherche sur les agents multimodaux
    • L’environnement d’évaluation est aligné sur l’interface OpenAI Gym, ce qui facilite son intégration aux bases de code de recherche existantes
    • La CLI FLE permet de lancer des expériences avec une seule commande shell, et le code d’évaluation, la journalisation Weights and Biases, la reprise de sweeps et les outils d’analyse sont fournis en open source

Démarrage rapide

# 1. Install FLE with uv
uv add factorio-learning-environment



# 2. Start a Factorio server cluster
fle cluster start



# 3. Run an evaluation (with API keys in .env)
fle eval --config configs/gym_run_config.json
  • FLE s’installe avec uv ; on démarre ensuite un cluster de serveurs Factorio avec fle cluster start, puis on lance l’évaluation avec les clés d’API dans .env et un fichier de configuration

Exemple d’usine automatisée d’iron gear wheels

  • L’agent d’exemple démarre dans le monde lab-play avec un inventaire d’objets et l’objectif de construire une usine d’iron gear wheels
  • Il interagit avec l’environnement de jeu en appelant l’API FLE depuis Python, et observe la sortie standard et les messages d’erreur de chaque exécution

  • Configuration électrique

    • Il trouve l’emplacement de l’eau avec nearest(Resource.Water) et place une offshore pump
    • Il place une chaudière et une machine à vapeur, relie les tuyaux avec connect_entities, puis met du coal dans la chaudière
    • Après une attente de 5 secondes, il vérifie la valeur energy de la machine à vapeur pour confirmer la production d’électricité

  • Extraction et fonte du fer

    • Il trouve l’emplacement du iron ore, puis place deux electric mining drills et un electric furnace
    • Il calcule que 16 iron gear wheels par minute nécessitent 32 iron plates par minute, et qu’un electric mining drill extrait 30 minerais en 60 secondes ; deux foreuses sont donc nécessaires
    • Les foreuses et le four électrique sont raccordés au réseau électrique de la machine à vapeur via un medium electric pole

  • Placement de la machine d’assemblage

    • Il place une AssemblingMachine2 à au moins 20 tuiles de la zone d’extraction
    • Il définit la recette de la machine d’assemblage sur Prototype.IronGearWheel, place les inserters d’entrée et de sortie, puis la raccorde au réseau électrique
    • Une Assembling machine 2 peut fabriquer 90 iron gear wheels en 60 secondes ; une seule machine suffit donc pour le débit visé

  • Connexion des tapis et récupération d’erreurs

    • Il tente de relier directement l’inserter de sortie du furnace à l’inserter d’entrée de l’assembler avec un tapis, mais découvre qu’un storage chest bloque le chemin
    • Il retire les iron plates de deux wooden chests qui bloquaient le passage et supprime les coffres, mais une nouvelle erreur survient car l’input buffer chest côté assembler est resté en place
    • À la fin, il retire aussi l’input chest de l’assembler et connecte un réseau logistique basé sur des transport belts, ce qui permet au système automatisé d’iron gear wheels d’atteindre le débit cible

Espace d’observation et harnais d’agent

  • À chaque étape, l’agent reçoit un objet Observation structuré décrivant l’état du jeu
  • Champs principaux :
    • raw_text : sortie standard et messages d’erreur de la dernière exécution de l’action program, avec numéros de ligne du code source
    • entities : toutes les entités du monde de jeu avec leurs propriétés, notamment position, type, direction, inventaire et alertes
    • inventory : types d’objets et quantités dans l’inventaire personnel de l’agent
    • research : technologies recherchées, recherche en cours, technologies disponibles avec prérequis et coûts
    • game_info : nombre de ticks, temps écoulé, vitesse de jeu
    • flows : ratios d’entrée/sortie, objets fabriqués, ressources collectées, grille de prix optionnelle pour l’évaluation économique
    • messages : messages entre agents pour la coordination multi-agent
    • task_info : description de l’objectif, instructions, task identifier, longueur maximale de trajectory
    • task_verification : métadonnées de réussite/échec et de progression vers l’objectif
    • serialized_functions : helper functions et abstractions définies précédemment
    • map_image : plan d’usine PNG encodé en base64 pour les agents visuels
  • Cet espace d’observation prend en charge la conscience spatiale, le suivi des métriques de production, le débogage des erreurs et la planification d’une automatisation en plusieurs étapes
  • Le harnais d’agent utilisé pour l’évaluation concatène ces champs sous forme de chaînes Markdown formatées

Configuration du benchmark Lab-play

  • Lab-play est un environnement contraint qui fournit des ressources fixes et une entité objectif unique, avec pour but de maximiser le débit de production
  • Open-play est nettement plus complexe : il démarre sur une carte générée procéduralement, sans inventaire initial, avec des ressources plus rares et des objectifs plus difficiles
  • En date de septembre 2025, la méthodologie de l’article FLE original est reproduite et adaptée à la configuration lab-play pour des modèles puissants
  • Le harnais d’agent standardisé continue d’ajouter les interactions avec l’environnement à un unique historique de conversation ; lorsque le budget de tokens vient à manquer, les anciens échanges sont résumés pour poursuivre le raisonnement
  • La logique de backtracking ou de reflection utilisée dans FLE 0.2.0 n’est pas évaluée

  • Conditions d’évaluation

    • Objectif : atteindre un débit de production de 16 unités par minute pour les objets solides et de 250 unités par minute pour les fluides
    • Prompt : documentation de l’API FLE, recettes Factorio, guide des patterns généraux
    • Inventaire : ensemble d’objets utiles pour construire une usine fonctionnelle
    • Nombre maximal d’étapes : 64 étapes, avec arrêt anticipé en cas de réussite
    • Raisonnement : pour les modèles prenant en charge le reasoning, application du réglage par défaut {"enabled": true}

Performances des modèles et limites restantes

  • Les modèles open source ont rattrapé le meilleur niveau observé en mai 2025 avec la v0.2.0, avec des réussites dans l’automatisation des electronic circuits, steel plates, sulfur et plastic
  • Les modèles frontier récents se sont nettement améliorés par rapport à FLE v0.2.0 et réussissent pour la première fois dans la moitié la plus difficile des tasks, qui peuvent exploiter plus de 12 ingredient dependencies
  • Dans FLE lab-play, le classement des modèles avancés et les écarts de performance étaient proches de l’ordre Claude > GPT > Gemini > Grok, ce qui correspond le plus à GDPVal d’OpenAI
  • Le contraste est marqué avec les benchmarks statiques de type examen, comme Humanity's Last Exam, AIME 25, GPQA ou MMMU, où des modèles faibles dans FLE affichent parfois de meilleures performances
  • Même les agents qui réussissent s’appuient souvent, dans les tasks complexes, sur des stratégies semi-manuelles plutôt que sur une automatisation robuste
    • Ils transportent les ressources eux-mêmes
    • Ils utilisent des storage chests comme buffers de ressources
    • Ils contournent la construction d’une chaîne logistique entièrement automatisée
  • Les buffers intermédiaires peuvent satisfaire temporairement les contrôles de débit, ce qui complique la mesure
  • L’évaluation atténue ce problème en vérifiant le respect du quota après une période de holdout pendant laquelle l’agent laisse l’usine fonctionner seule pendant 60 secondes
  • Des objectifs de débit plus élevés rendent plus difficile la réussite par logistique manuelle et peuvent imposer une automatisation appropriée

Types d’erreurs et différences entre modèles

  • Les modèles frontier continuent d’avoir du mal à récupérer lorsque les erreurs s’accumulent
  • Comparaison du taux d’erreur moyen : {b:23,25,27,41}
  • Taux d’erreur moyen :
    • Claude Opus 4.1 : 22,99 %
    • GPT-5 : 25,05 %
    • Gemini 2.5 Pro : 27,29 %
    • Grok 4 : 40,89 %
  • Grok 4 tombe souvent dans des boucles de débogage régressives, tandis que GPT-5 montre des patterns de récupération plus élégants
  • La plupart des modèles voient leur taux d’erreur augmenter au milieu de la trajectory, lorsque la complexité de l’usine s’accroît

  • Types d’échecs

    • Erreurs de syntaxe : code Python invalide, erreurs grammaticales, erreurs empêchant l’exécution elle-même
    • Erreurs sémantiques : mauvais usage des commandes FLE ou des arguments d’outils, mauvaise compréhension de la documentation, TypeError, AttributeError, NameError, etc.
    • Erreurs pratiques : raisonnement incorrect sur l’état courant du jeu, par exemple tentative d’insertion d’un objet absent de l’inventaire
    • Erreurs de planification et de contrôle : incapacité à enchaîner les actions de manière cohérente malgré la connaissance des primitives, menant à une trajectory inefficace ou incomplète
    • Cette catégorie exige d’examiner la cohérence stratégique de haut niveau plutôt que des types d’erreurs isolés ; elle est donc difficile à quantifier de façon fiable par analyse automatique de trajectory

  • Répartition des erreurs par modèle

    • Claude Opus 4.1 n’a aucune erreur de syntaxe et 97,7 % de ses erreurs relèvent plutôt d’erreurs pratiques, ce qui montre une forte génération de code mais des difficultés à maintenir un mental model exact de l’état du jeu
    • Gemini 2.5 Pro, Grok 4 et GPT-5 affichent 12 à 17 % d’erreurs de compréhension de l’API, signe de difficultés à utiliser correctement la documentation de l’API FLE
    • GPT-5 et Grok 4 présentent respectivement 21 % et 17 % d’erreurs de syntaxe, ce qui est fréquent pour des modèles de coding benchmark pourtant au meilleur niveau actuel
    • Seul Gemini 2.5 Pro montre une approche consistant à définir et utiliser les helper functions et abstractions disponibles

Claude Code et MCP

  • Dans la v0.2.0, un MCP server a été publié pour permettre à des agents externes d’interagir avec FLE
  • La v0.3.0 l’étend en incluant un adapter Claude Code
  • Le stream de Claude Code jouant à Factorio est disponible sur Twitch

Prochaines pistes de recherche

  • Les modèles frontier actuels restent loin d’être très bons à Factorio selon des critères humains, et rencontrent des difficultés dans la représentation et la modélisation d’environnements dynamiques ainsi que dans le développement de formal abstractions utilisables comme futurs outils
  • Malgré cela, les capacités des modèles frontier dans lab-play se sont régulièrement améliorées au cours de 2025
  • Factorio peut continuer à servir d’environnement révélant des capacités générales des modèles, comme la planification à long terme, l’adaptation à un domaine, la modélisation du monde et le raisonnement spatial
  • FLE v0.3.0 établit lab-play comme premier formal benchmark, mais ce n’est qu’un point de départ pour le programme de recherche

  • Tâches à court terme

    • Référentiel humain : mesurer systématiquement les performances humaines par niveau de difficulté des tasks afin de calibrer les capacités des agents
    • Lutte contre le reward hacking : traiter le problème des agents qui utilisent le manual crafting pour les objets complexes au lieu d’une automatisation appropriée
    • METR-style task scaling : développer un scaling chart reliant systématiquement la difficulté des tasks et les capacités requises

  • Tâches à long terme

    • Extension à Open-play et aux megabases : faire monter la difficulté depuis le lab-play contraint jusqu’aux cartes générées procéduralement, aux objectifs multi-étapes et aux megabases comportant des milliers de machines connectées
    • Performances en temps réel sous contrainte de latence : actuellement, le temps de réflexion entre deux actions est illimité ; un benchmark où Factorio continue de tourner permettrait d’évaluer l’équilibre entre latence de réponse et qualité des solutions
    • Coordination multi-agent : traiter la coopération, la compétition, les emergent market dynamics, la division du travail, la négociation de l’allocation des ressources et la formation d’avantages comparatifs
    • Environnements hors distribution basés sur des mods : évaluer la capacité à réapprendre la causal structure dans de nouveaux tech trees et mécanismes de jeu
    • Native computer-use interface : évaluer les agents avec une interface clavier-souris-vision semblable à celle d’un humain, plutôt qu’avec une API Python
    • Dynamiques adversariales et robustesse : introduire des hostile aliens et des défis environnementaux non déterministes pour évaluer l’adaptive control et la resilience

Comment participer

  • Le code comme les missions de FLE sont open source
  • Les profils recherchés sont les suivants :
    • des chercheurs explorant de nouvelles architectures pour la planification à long terme et le raisonnement spatial
    • des ingénieurs optimisant l’infrastructure d’évaluation et d’entraînement à grande échelle
    • des modders concevant de nouveaux challenge domains
  • Les personnes intéressées par l’équipe peuvent la retrouver sur Discord

À lire aussi

1 commentaires

 
GN⁺ 2025-03-12
Commentaires Hacker News

  • Je suis maintenant complètement ferré, et j’ai très envie de postuler tout de suite au laboratoire Factorio d’Anthropic
    Rien qu’en lisant l’article et les commentaires, je ne sais pas s’ils renvoient des données multimodales, mais comme plusieurs modèles ne sont pas multimodaux, j’imagine que non. Certains le peuvent quand même, et le récent Qwen 2.5 VLM semble assez puissant pour sa taille
    Ils ont beaucoup insisté sur le manque de capacités spatiales, ainsi que sur les difficultés à la fois de planification et de planification spatiale, donc je me demande s’ils envoient aussi des images comme des captures d’écran. Si ce n’est pas le cas, je serais aussi curieux d’avoir leur avis là-dessus
    Au passage, activer une bibliothèque Python via MCP pour permettre à tous les LLM capables d’utiliser des outils de jouer à Factorio semble naturellement être quelque chose qu’il faut absolument faire

    • Pour l’instant, c’est un environnement texte uniquement, mais ils prévoient de prendre en charge des entrées visuelles plus tard
      Dans quelques tests, inclure des captures d’écran de l’état du jeu n’a pas amélioré les performances des modèles du commerce. Plus l’état du jeu devenait complexe et plus il y avait d’entités sur la capture, plus les modèles étaient désorientés ; ils hallucinaient ou omettaient des directions ou des entités, et ne parvenaient pas non plus à corriger des erreurs évidentes comme des convoyeurs manquants ou des bras robotisés mal orientés
      Ils pensent que cela vient du fait que les VLM actuels gèrent mal le raisonnement spatial sur des images riches en détails, et qu’un fine-tuning pourrait probablement apporter de fortes améliorations. MCP monte aussi très vite en ce moment, donc ils comptent s’y intéresser
    • Si une description textuelle de l’état de l’usine est plus facile à interpréter et moins source de confusion, je ne vois pas pourquoi il faudrait des captures d’écran
      Le jeu se déroule sur une grille, donc convertir l’état du jeu en représentation ASCII devrait être simple

  • Il y a peu, il y a eu sur HN un billet d’une équipe qui entraînait un agent à finir Pokémon Red avec de l’apprentissage par renforcement. Ils disaient avoir dû ajuster la fonction de coût pour donner de petites récompenses à l’exploration et de grosses récompenses aux tâches obligatoires comme battre les arènes
    Je me demande si on pourrait utiliser la même approche pour Factorio. Si on reprend l’analogie avec Pokémon Red, les grandes tâches obligatoires de Factorio sont de mettre en place l’automatisation de nouveaux objets et de nouveaux packs de science
    De petites récompenses pour le débit de production de chaque objet, des récompenses intermédiaires pour l’automatisation de nouveaux objets, et de grosses récompenses pour l’automatisation de nouveaux packs de science pourraient constituer une bonne fonction de récompense
    Dire simplement à un agent Factorio « construis une grande usine », c’est comme dire à un agent Pokémon Red « termine le jeu » ; il faut découper cela en étapes plus petites avec une fonction de récompense calibrée avec beaucoup de soin
    À force d’y penser, ça me donne envie de me lancer dans ce projet

    • En complément, en tant que joueur ayant 2 000 à 3 000 heures sur Factorio, l’objectif de construire « la plus grande usine possible » est trop vague et ce n’est pas la bonne métrique
      Quand les joueurs de Factorio construisent de très grosses mégabases, ils ne visent pas la taille en soi, mais le SPM (science par minute). La métrique à donner à l’agent ne devrait pas être la « plus grande » base, mais le SPM
    • Dans FLE, on a accès à des jalons indiquant le moment où chaque nouvelle entité a été créée pour la première fois, mais une approche où l’on hiérarchise les récompenses selon les niveaux d’automatisation serait aussi vraiment intéressante. Ce serait sympa d’essayer ensemble
    • C’est un point intéressant. Claude pouvait accomplir dans lab-play des tâches obligatoires et des automatisations simples comme une usine à roues dentées en fer, mais dans les épisodes de jeu « construire la plus grande usine », il n’essayait même pas
      Les modèles sont capables d’accomplir ce type de tâches obligatoires, mais lorsqu’on leur donne un objectif général comme « terminer le jeu », ils manquent du niveau de planification à long terme nécessaire pour essayer réellement d’y parvenir. Souvent, ils n’essaient pas d’étendre une usine existante et se contentent de petites structures non coordonnées
      L’un des objectifs était aussi de voir comment les modèles se comportent lorsqu’on leur donne des objectifs ambigus et généraux
    • On peut appliquer la même approche à la vie aussi
    • Je me demande si vous avez lu la page. En pratique, ils attribuaient une récompense à chaque objet effectivement produit, avec des récompenses plus élevées pour les objets plus complexes

  • La partie sur l’évaluation de six modèles de langage de frontière dans deux configurations est intéressante, mais il existe aussi beaucoup de benchmarks dynamiques bien plus simples qui suffisent à saturer les capacités de planification des modèles non raisonneurs
    Il suffit par exemple de leur donner une liste de liaisons aériennes entre des villes et de leur demander un itinéraire ; dès que le plus court chemin entre deux nœuds devient assez long, tous ces modèles se perdent
    Voici, pour chaque modèle, la plus grande longueur de plus court chemin qu’il pouvait encore trouver de façon fiable au moins 8 fois sur 10
    | Model | Path Length | |------------------+-------------| | Claude Sonnet3.5 | 10 | | GPT-4o | 7 | | GPT-4o-mini | 4 | | Deepseek-v3 | 6 | | Gemini-2-Flash | Not tested | | Llama3.3-70B-Ins | 4 |

    • Exact. Il existe des benchmarks plus simples qui saturent les capacités de planification de ce type de modèles
      Cela dit, nous voulions construire un environnement d’évaluation couvrant un spectre plus large, capable de tester plusieurs aptitudes à la fois et de rester pertinent à l’avenir

  • L’idée que tous les modèles ont montré des limites de planification spatiale lorsqu’il s’agissait de construire une usine répartie sur plusieurs zones me paraît convaincante. Les échecs fréquents incluent le placement d’entités trop proches les unes des autres, l’absence d’espace pour les connexions, ou des bras robotisés mal posés
    Je comprends pourquoi les LLM sont faibles en raisonnement spatial. Il n’existe pas beaucoup de données d’entraînement adaptées. Je me demande quelles capacités de raisonnement supplémentaires apparaîtraient si le raisonnement spatial était résolu

    • Je ne comprends pas bien l’idée qu’il n’y aurait pas beaucoup de données spatiales
      Avec même le simulateur le plus simple, on peut en produire une quantité pratiquement infinie, non ?
      Par exemple, il suffit d’implémenter un morpion sur une grille infinie en une dizaine de lignes de code pour générer un jeu d’entraînement illimité

  • Comme autre catégorie de tâches « Lab Play », j’aimerais voir de la conception de balancers
    Même de petits balancers peuvent être assez complexes (https://factorioprints.com/view/-NopheiSZZ7d8VitIQv9), et ce serait intéressant de voir comment les modèles les conçoivent et résolvent ce type de problème

  • Excellente idée.
    Il semble y avoir beaucoup d'expériences intéressantes à mener ici. Ajouter des éléments liés au temps dans les scénarios lab-play me paraît être une bonne idée. La plupart des joueurs de Factorio qui jouent avec les biters activés traiteraient cela comme une combinaison de contraintes spatio-temporelles, et imposer une limite de temps à l'agent permettrait une sorte de comparaison par proxy avec des situations de jeu réelles.
    J'aime le fait que la conception de ce framework teste autre chose que les capacités de microgestion qu'on voyait dans les expériences sur DOTA 2 ou StarCraft 2. En particulier, dans StarCraft 2, avec un APM infini, on obtient des comportements où l'on microgère les ouvriers de manière extrême pour extraire un peu plus de minerais.
    Ce genre de comportement est un résultat d'apprentissage intéressant dans un contexte étroit, mais en pratique la charge de manipulation est élevée et même les joueurs professionnels risquent de faire des erreurs. Cela ne semble pas non plus apporter beaucoup d'éclairages supplémentaires sur les capacités de planification à long terme, d'exécution et d'analyse de l'agent.
    De ce point de vue, FLE est bien plus intéressant comme framework d'évaluation du raisonnement de haut niveau. Je me demande aussi s'il est prévu de créer un benchmark d'optimisation de disposition du type : étant donné une cellule d'usine avec X entrées et Y sorties, optimiser les performances.

    • On parle justement de créer une tâche plus proche du tower defense, où les biters sont libérés tous les X niveaux ou toutes les X secondes.
      L'objectif est de tester la capacité de l'agent à construire un complexe militaro-industriel. Le problème amusant rencontré en développant cette idée, c'est que les modèles de frontier hésitent à créer des entités portant des noms comme GunTurret. Ils semblent considérer cela comme contraire à leur constitution. Il faudra peut-être renommer les tourelles en quelque chose comme SuperSoaker.
      Nous avons justement discuté hier du benchmark d'optimisation de disposition. Nous pensons qu'il faut deux types de tâches de layout : 1) réparer une usine subtilement défectueuse, 2) améliorer le débit de cette usine. L'implémentation devrait être relativement simple, donc cela vaudrait la peine d'y jeter un œil.

  • Je ne comprends pas bien. Ces modèles ont-ils été post-entraînés pour jouer à Factorio ?
    A) Si oui, comment est-ce possible avec des modèles sans poids publics comme Claude ? B) Sinon, comment l'agent sait-il ce que fait l'API ? Même s'il déduit le sens anglais des commandes de l'API, par exemple que place_entity_next_to signifie placer une entité à côté de quelque chose, comment connaît-il les recettes de fabrication ? S'il procède par essais et apprentissage, on revient alors au point A.
    En lisant le PDF, j'ai l'impression qu'il n'y a pas eu de post-entraînement, mais dans ce cas je ne vois pas comment expliquer les questions du point B.
    S'il n'y a vraiment pas eu de post-entraînement et que l'exploration des recettes de fabrication était censée se faire dans la fenêtre de contexte, cela me semble trop court pour une amélioration de type apprentissage par renforcement.
    En résumé, je ne sais pas s'il a été possible de tester ces modèles avec du post-entraînement, et si cela a été fait sans post-entraînement, alors ils ont tous obtenu des résultats presque incroyablement bons.
    Si les auteurs passent par ici, je serais curieux de savoir combien de paires requête API / réponse API tiennent en moyenne dans la fenêtre de contexte. Et dans la foulée, je me demande si les résultats s'améliorent lorsqu'on abrège les noms des appels API afin de faire tenir davantage de paires réponse dans une même fenêtre de contexte.

    • Concernant les outils, les agents avaient accès aux signatures de fonction, c'est-à-dire aux docstrings des outils, ainsi qu'aux types d'entrée et de sortie, et il y avait aussi un petit « manuel » pour chaque outil.
      Ce manuel expliquait ce que fait l'outil, quel effet il a sur l'état du jeu, ainsi que quelques exemples d'utilisation, comme comment placer un inserteur à côté d'un coffre existant avec place_entity_next_to.
      Comme l'a dit Jack, il n'y a eu absolument aucun post-entraînement, mais tous les agents disposaient dans leur contexte d'une description complète de l'API, incluant les outils, les entités et les recherches. Ces résultats montrent donc dans une certaine mesure à quel point les agents modernes peuvent bien utiliser une API totalement hors distribution lorsqu'elle est correctement documentée.
    • Ces modèles n'ont pas été post-entraînés et ont tous été utilisés tels quels.
      Il était possible de faire tenir jusqu'à environ 128 paires dans le contexte, mais comme les performances étaient identiques à 32 paires, nous avons finalement retenu 32 pour des raisons de coût et de latence.
      Encoder les entrées et sorties de manière plus courte dégradait les performances. Il semble que, pour les modèles préentraînés, des noms descriptifs aident en donnant une intuition de ce qu'ils font.
    • Si on lit la note de bas de page de la présentation des auteurs, on dirait que l'un d'eux travaille chez Anthropic. Il a peut-être eu un accès interne.

  • Je trouve intéressant qu'il n'y ait que quelques scénarios complexes. J'ai toujours pensé que, pour qu'un agent de jeu ML apprenne réellement les mécaniques d'un jeu, il faudrait des centaines de très petits puzzles, chacun avec des centaines de variantes.
    Par exemple : l'usine n'a pas d'électricité, donc placer le poteau électrique manquant ; l'usine manque d'objets, donc placer le convoyeur manquant ; fabriquer et déployer 200 assembleurs ; réparer un assembleur qui s'est arrêté pour une raison quelconque ; doubler la production d'une usine dont le débit est trop faible ; se déplacer aussi vite que possible vers un autre point de l'usine ; corriger un manque de puissance ; et diviser toutes ces tâches entre les cas avec robots et sans robots.
    Il devrait être relativement facile de générer par programme quelques milliers de scénarios d'exemple de ce type. On pourrait ensuite les utiliser comme une banque de questions de test de QI : on en tire une douzaine, puis on évalue la performance de chacune selon le temps et les matériaux utilisés.
    Je pense que les agents ML apprennent plus vite lorsqu'ils sont évalués sur des échantillons tirés d'une grande banque de scénarios dont la complexité augmente progressivement, après avoir obtenu des scores suffisamment élevés sur les niveaux de complexité inférieurs, puis qu'on leur présente des scénarios plus complexes.

    • Générer les scénarios en texte, comme vous le proposez, est facile, mais créer le bon état de jeu de l'usine servant de point de départ est bien plus difficile.
      À ma connaissance, cela revient finalement au même travail consistant à concevoir manuellement l'état initial et la tâche à accomplir.
    • Nous envisageons une telle approche par curriculum pour l'entraînement supplémentaire.
      En revanche, le travail actuel était centré sur l'évaluation, donc nous ne l'avons pas fait. La « difficulté » des différentes tâches est assez subjective, ce qui obligerait à prendre des décisions arbitraires susceptibles d'influencer l'évaluation. Par exemple, quelle tâche doit venir après quel scénario, ou encore si tous les niveaux de difficulté sont suffisamment couverts.

  • Je me demande s'il existe un benchmark de jeu humain pour ce type d'interface. Je ne dis pas que c'est indispensable ou nécessairement pertinent ; je suis simplement curieux de savoir ce que donne Factorio joué de manière programmatique.
    Faire du raisonnement spatial à partir de prompts textuels me semble assez difficile, même pour des joueurs humains.

    • Le benchmark humain de Factorio, ce sont les speedrunners qui visent le premier lancement de fusée.
      Le record actuel est d'un peu plus de 4 heures en solo et de 90 minutes en équipe. Rien que cela montre qu'il existe une marge pour que des LLM multitâches dépassent les humains.

  • Je me demande si, dans quelques années, tous les adversaires dans les jeux seront des LLM capables d’accéder à ce type d’API de contrôle du jeu.
    Je me demande aussi s’il y avait des types de tâches particulièrement difficiles pour les modèles, ou si la difficulté augmente surtout en fonction du nombre d’objets à placer.

    • Il est très peu probable que les LLM soient massivement utilisés comme adversaires. L’IA ennemie de la plupart des jeux n’a pas besoin du niveau de complexité qu’exige l’apprentissage automatique, même en laissant de côté le coût de calcul.
      L’objectif principal d’une IA ennemie n’est pas de devenir l’entité la plus difficile au monde, mais de proposer au joueur un défi intéressant qu’il puisse surmonter. Dans la plupart des jeux, créer une IA ultra-performante n’est pas forcément difficile, mais cela ne la rend pas plus amusante à affronter.
      La plupart des jeux ont un nombre fini d’états logiques, simplement assez vaste pour qu’un humain ne puisse pas tous les explorer. Bien sûr, les humains sont très doués pour pousser les limites de ces états et trouver des moyens de contournement.
      Même dans les jeux où l’espace d’états est bien plus grand que la normale, vouloir une super IA reste rare. Par exemple, personne n’aime affronter un aimbot dans un FPS.
      Factorio fait exception par rapport aux jeux classiques, car la véritable condition de “victoire” dépend presque entièrement du joueur. Dans Factorio sans DLC, on peut fabriquer la fusée, qui constitue la condition de victoire du jeu, presque sans construire d’usine en dehors des structures les plus élémentaires nécessaires pour les choses qu’on ne peut pas fabriquer à la main. Ce serait extrêmement lent, mais c’est possible. C’est pourquoi, dans un benchmark comme celui-ci, l’efficacité compte davantage que le simple fait de “fonctionner”.
    • Je pense que oui. Parce qu’aucun calcul d’entraînement supplémentaire n’est nécessaire pour le faire fonctionner. Dès lors qu’une API est fournie, il devient très facile de connecter en plug-and-play différents modèles à un nouveau jeu.
      Les modèles rencontrent surtout des difficultés dans deux grands domaines. Le premier est le raisonnement spatial. Les modèles produisent souvent des erreurs de type off-by-one, et une usine, comme un programme, est très sensible à ce genre d’erreurs, dont il est difficile de se remettre.
      Le second est la planification à long terme : la capacité à déterminer, sur le plan stratégique, ce qu’il faut faire avant de définir des sous-objectifs tactiques.
      Dans lab-play, la difficulté est généralement proportionnelle à la profondeur de la chaîne de production. S’il faut d’abord plusieurs segments d’usine pour fabriquer un objet, cela devient bien plus difficile. Cela semble lié à la planification, car les modèles ont tendance à s’enliser dans les détails pour corriger de petits problèmes, au lieu d’établir d’abord un plan d’ensemble.
    • Quand on regarde “Claude plays Pokémon”, on le voit galérer dans Mount Moon, et moi aussi à quatre ans, j’en étais là.
    • Pourquoi faut-il que ce soit un LLM ? N’est-ce pas justement le genre de chose qu’AlphaZero fait bien ? Il existe bien d’autres modèles de machine learning utiles que les seuls LLM !