Factorio-Lernumgebung – Ein Agent, der eine Fabrik baut

 (jackhopkins.github.io)
1 Punkte von GN⁺ 2025-03-12 | 1 Kommentare | Auf WhatsApp teilen
  • FLE 0.3.0 wurde veröffentlicht, um mit dem Fabrikautomatisierungsspiel Factorio die langfristige Planung und räumliche Schlussfolgerung von Agenten zu prüfen; enthalten ist auch eine Demo, die Claude Code mit Factorio verbindet
  • Die neue Version erleichtert Forschungsexperimente durch Headless-Ausführung, einen Renderer für Pixel-Beobachtungen, eine OpenAI-Gym-kompatible Schnittstelle, CLI-basierte Evaluierung sowie Logging und Analysetools für Weights and Biases
  • Ein Beispiel-Agent debuggt wiederholt Stromerzeugung, Eisenerzabbau, Verhüttung, das Platzieren von Montagemaschinen und das Verbinden von Förderbändern und erreicht so das Ziel von 16 iron gear wheel pro Minute
  • Der Lab-play-Benchmark bewertet mit Stand September 2025 starke Modelle per Pass@8 und setzt Produktionsziele von 16 pro Minute für feste Items und 250 pro Minute für Fluide bei einem Limit von maximal 64 Schritten
  • Frontier-Modelle haben sich gegenüber v0.2.0 verbessert, doch manuelles Transportieren, Kistenpuffer, API-Fehlgebrauch und Fehleinschätzungen dynamischer Spielzustände bleiben bestehen, sodass Factorio eine anspruchsvolle Umgebung für langfristige Planung und dynamische Wiederherstellung bleibt

Was sich in FLE 0.3.0 geändert hat

  • FLE 0.3.0 ist ein großes Update der Lernumgebung, die anhand der Factorio-Aufgabe des Fabrikbaus langfristige Planung, Schlussfolgerung und World Modeling testet
  • Im früheren FLE paper zeigten Frontier-Modelle Schwierigkeiten bei der Anpassung an veränderliche Umgebungen, beim Setzen langfristiger Ziele und bei dynamischer Wiederherstellung; 0.2.0 führte Multi-Agency, Backtracking-Agenten und Vision ein
  • Zentrale Änderungen in 0.3.0:
    • Verbindung von Claude Code mit Factorio über FLE und Vorführung auf Twitch
    • Unterstützung für Headless-Skalierung für groß angelegte Experimente, indem die Abhängigkeit vom Factorio-Spielclient entfernt wurde
    • Ein neuer Headless-Game-Renderer liefert realistische Pixel-Beobachtungen für die Forschung an multimodalen Agenten
    • Die Evaluierungsumgebung passt sich an die OpenAI Gym-Schnittstelle an und lässt sich damit leichter in bestehende Forschungs-Codebasen integrieren
    • Die FLE-CLI unterstützt Experimente per Shell-Befehl in einer Zeile; außerdem werden Evaluierungscode sowie Weights-and-Biases-Logging, Sweep-Resume und Analysetools als Open Source bereitgestellt

Schnellstart

# 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 wird mit uv installiert, der Factorio-Server-Cluster mit fle cluster start gestartet und die Evaluierung anschließend mit den API-Schlüsseln in .env und einer Konfigurationsdatei ausgeführt

Beispiel einer automatischen iron gear wheel-Fabrik

  • Der Beispiel-Agent startet in der lab-play-Welt mit einem Item-Inventar und dem Ziel, eine iron gear wheel-Fabrik aufzubauen
  • Er interagiert mit der Spielumgebung, indem er die FLE-API in Python aufruft, und beobachtet Standardausgabe und Fehlermeldungen jedes Ausführungsergebnisses

  • Stromaufbau

    • Mit nearest(Resource.Water) wird die Wasserposition gefunden und eine offshore pump platziert
    • Danach werden Boiler und Steam Engines platziert, per connect_entities mit Rohren verbunden und die Boiler mit coal versorgt
    • Nach 5 Sekunden Wartezeit wird der energy-Wert der Steam Engine geprüft, um die Stromerzeugung zu verifizieren

  • Eisenabbau und Verhüttung

    • Nach dem Finden der iron ore-Position werden zwei electric mining drill und ein electric furnace platziert
    • Es wird berechnet, dass für 16 iron gear wheel/Minute 32 iron plate/Minute nötig sind und ein electric mining drill 30 ore pro 60 Sekunden abbaut, sodass zwei Drills benötigt werden
    • Die Drills und der Elektro-Ofen werden mit medium electric pole an das Stromnetz der Steam Engines angeschlossen

  • Platzierung der Montagemaschine

    • Eine AssemblingMachine2 wird mindestens 20 Tiles vom Abbaugebiet entfernt platziert
    • Das Rezept der Montagemaschine wird auf Prototype.IronGearWheel gesetzt, Eingabe- und Ausgabe-Inserter werden platziert und an das Stromnetz angeschlossen
    • Assembling machine 2 kann 90 iron gear wheel pro 60 Sekunden herstellen, sodass für den Zieldurchsatz eine Maschine ausreicht

  • Förderbandverbindung und Fehlerbehebung

    • Zunächst wurde versucht, den furnace output inserter direkt per Förderband mit dem assembler input inserter zu verbinden, doch eine storage chest blockierte den Pfad
    • Zwei blockierende wooden chest wurden geleert und entfernt, aber die input buffer chest auf der Seite des Assemblers blieb bestehen, wodurch erneut ein Fehler auftrat
    • Am Ende wurde auch die assembler input chest entfernt und ein auf transport belt basierendes Logistiknetz verbunden, sodass das automatische iron gear wheel-System den Zieldurchsatz erreichte

Beobachtungsraum und Agent-Harness

  • In jedem Schritt erhält der Agent ein strukturiertes Observation-Objekt mit dem Spielzustand
  • Wichtige Felder:
    • raw_text: Standardausgabe und Fehlermeldungen der zuletzt ausgeführten action program-Ausführung sowie Quellcodezeilennummern
    • entities: alle Entitäten in der Spielwelt und Attribute wie Position, Typ, Richtung, Inventar und Warnungen
    • inventory: Item-Typen und Mengen im persönlichen Inventar des Agenten
    • research: erforschte Technologien, aktueller Forschungsfortschritt sowie verfügbare Technologien mit Voraussetzungen und Kosten
    • game_info: Tick-Zahl, verstrichene Zeit, Spielgeschwindigkeit
    • flows: Ein-/Ausgaberaten, hergestellte Items, gesammelte Ressourcen und optionale Preislisten für ökonomische Bewertungen
    • messages: Nachrichten zwischen Agenten zur Multi-Agenten-Koordination
    • task_info: Zielbeschreibung, Anweisungen, Task-Identifier und maximale Trajektorienlänge
    • task_verification: Metadaten zu Erfolg, Misserfolg und Ziel-Fortschritt
    • serialized_functions: zuvor definierte helper function und Abstraktionen
    • map_image: base64-kodiertes PNG des Fabriklayouts für visuelle Agenten
  • Dieser Beobachtungsraum unterstützt räumliche Wahrnehmung, das Nachverfolgen von Produktionsmetriken, Fehler-Debugging und die Planung mehrstufiger Automatisierung
  • Das Agent-Harness für Evaluierungen hängt diese Felder zu einem formatierten Markdown-String zusammen

Konfiguration des Lab-play-Benchmarks

  • Lab-play ist eine eingeschränkte Umgebung mit festen Ressourcen und einer einzelnen Zielentität, in der der Produktionsdurchsatz maximiert wird
  • Open-play ist deutlich komplexer, da dort auf prozedural generierten Karten ohne Startinventar begonnen wird und mit knapperen Ressourcen sowie komplexeren Zielen umgegangen werden muss
  • Mit Stand September 2025 wurde die Methodik des ursprünglichen FLE paper für starke Modelle auf das Lab-play-Setup übertragen
  • Das standardisierte Agent-Harness ergänzt die Umgebungsinteraktionen fortlaufend in einem einzigen Gesprächsverlauf; wenn das Token-Budget knapp wird, werden ältere Einträge zusammengefasst, damit die Schlussfolgerung weiterlaufen kann
  • Die in FLE 0.2.0 verwendete Backtracking- oder Reflection-Logik wird nicht evaluiert

  • Evaluierungsbedingungen

    • Ziel: Produktionsdurchsatz von 16 pro Minute für feste Items und 250 pro Minute für Fluide erreichen
    • Prompt: FLE-API-Dokumentation, Factorio-Rezepte, allgemeine Leitfäden für Muster
    • Inventar: nützlicher Satz an Items zum Bau einer funktionsfähigen Fabrik
    • Maximale Schritte: 64 Schritte, mit vorzeitigem Ende bei Abschluss
    • Reasoning: Für Modelle mit Unterstützung für reasoning wird die Standardeinstellung {"enabled": true} angewendet

Modellleistung und verbleibende Grenzen

  • Open-Source-Modelle haben die im Mai 2025 in v0.2.0 beobachtete aktuelle Bestleistung erreicht; es gibt erfolgreiche Beispiele für die Automatisierung von electronic circuits, steel plate, sulfur und plastic
  • Neueste Frontier-Modelle haben sich gegenüber FLE v0.2.0 deutlich verbessert und schaffen erstmals auch die schwierigere Hälfte der Tasks, die mehr als 12 ingredient dependency erfordern
  • Im FLE lab-play lagen Rangfolge und Leistungsabstände fortgeschrittener Modelle ungefähr bei Claude > GPT > Gemini > Grok und ähneln am stärksten OpenAIs GDPVal
  • Im Gegensatz dazu zeigen statische prüfungsartige Benchmarks wie Humanity's Last Exam, AIME 25, GPQA und MMMU teils höhere Leistungen bei Modellen, die in FLE schwächer sind
  • Selbst erfolgreiche Agenten verlassen sich bei komplexen Tasks häufig auf halbmanuelle Strategien statt auf robuste Automatisierung
    • Sie transportieren Ressourcen direkt
    • Sie verwenden storage chest als Ressourcenpuffer
    • Sie umgehen den Aufbau vollständig automatischer Logistikketten
  • Zwischenpuffer können die Durchsatzprüfung vorübergehend bestehen und erschweren dadurch die Messung
  • Die Evaluierung mildert dieses Problem, indem geprüft wird, ob der Agent die Vorgaben auch nach einer holdout period erfüllt, in der die Fabrik 60 Sekunden unverändert weiterläuft
  • Höhere Durchsatzziele würden ein Bestehen mit manueller Logistik erschweren und könnten angemessene Automatisierung erzwingen

Fehlertypen und Unterschiede zwischen Modellen

  • Frontier-Modelle haben weiterhin Schwierigkeiten, Fehler zu beheben, wenn sich diese aufstauen
  • Vergleich der durchschnittlichen Fehlerraten: {b:23,25,27,41}
  • Durchschnittliche Fehlerraten:
    • Claude Opus 4.1: 22.99%
    • GPT-5: 25.05%
    • Gemini 2.5 Pro: 27.29%
    • Grok 4: 40.89%
  • Grok 4 gerät oft in regressive Debug-Loops, während GPT-5 Muster einer eleganteren Wiederherstellung zeigt
  • Bei den meisten Modellen steigt die Fehlerrate im mittleren Abschnitt der Trajektorien, wenn die Fabrikkomplexität zunimmt

  • Fehlertypen

    • Syntaxfehler: ungültiger Python-Code, Grammatikfehler und Fehler, die die Ausführung selbst blockieren
    • Semantische Fehler: Fehlgebrauch von FLE-Befehlen oder Tool-Argumenten, Missverständnisse der Dokumentation, TypeError, AttributeError, NameError usw.
    • Praktische Fehler: falsche Schlussfolgerungen über den aktuellen Spielzustand, etwa der Versuch, Items einzufügen, die sich nicht im Inventar befinden
    • Planungs- und Kontrollfehler: primitive sind zwar bekannt, werden aber nicht konsistent zu Handlungen verknüpft, was zu ineffizienten oder unvollständigen Trajektorien führt
    • Diese Kategorie erfordert die Betrachtung strategischer Konsistenz auf höherer Ebene und lässt sich daher per automatischer Trajektorienanalyse nur schwer zuverlässig quantifizieren

  • Fehlerverteilung nach Modell

    • Claude Opus 4.1 hat keine Syntaxfehler und 97.7% seiner Fehler liegen im Bereich praktischer Fehler; die Codegenerierung ist also stark, aber das Aufrechterhalten eines präzisen mentalen Modells des Spielzustands fällt schwer
    • Gemini 2.5 Pro, Grok 4 und GPT-5 zeigen API-Verständnisfehler von 12 bis 17%, was auf Schwierigkeiten bei der präzisen Nutzung der FLE-API-Dokumentation hindeutet
    • GPT-5 und Grok 4 zeigen Syntaxfehler von 21% bzw. 17%, sodass selbst bei aktuellen SOTA-Modellen für Coding-Benchmarks häufig die Erzeugung gültigen Python-Codes scheitert
    • Nur Gemini 2.5 Pro zeigt derzeit einen Ansatz, bei dem helper function und Abstraktionen definiert und verwendet werden

Claude Code und MCP

  • In v0.2.0 wurde ein MCP server veröffentlicht, damit externe Agenten mit FLE interagieren können
  • In v0.3.0 wurde dies erweitert und ein Claude Code-Adapter aufgenommen
  • Den Claude Code-Stream beim Spielen von Factorio gibt es auf Twitch

Nächste Forschungsrichtungen

  • Aktuelle Frontier-Modelle sind nach menschlichen Maßstäben noch weit davon entfernt, in Factorio wirklich gut zu sein, und haben Schwierigkeiten mit dynamischer Umgebungsrepräsentation und -modellierung sowie mit der Entwicklung formaler Abstraktionen als künftige Werkzeuge
  • Dennoch haben sich die Fähigkeiten von Frontier-Modellen im lab-play im Verlauf von 2025 stetig verbessert
  • Factorio kann weiterhin als Umgebung dienen, die allgemeine Modellfähigkeiten wie langfristige Planung, Domänenanpassung, World Modeling und räumliche Schlussfolgerung sichtbar macht
  • FLE v0.3.0 etabliert lab-play als ersten formalen Benchmark, ist aber eher ein Ausgangspunkt für die Forschungsagenda

  • Kurzfristige Aufgaben

    • Menschliche Baseline: menschliche Leistung systematisch nach Task-Schwierigkeit messen, um Agentenfähigkeiten zu kalibrieren
    • Gegen Reward Hacking: das Problem angehen, dass Agenten bei komplexen Items manual crafting statt angemessener Automatisierung einsetzen
    • METR-style task scaling: ein Skalierungsdiagramm entwickeln, das Task-Schwierigkeit systematisch mit den erforderlichen Fähigkeiten verknüpft

  • Langfristige Aufgaben

    • Erweiterung auf Open-play und Megabase: die Schwierigkeit von begrenztem lab-play zu prozedural generierten Karten, mehrstufigen Zielen und Megabases mit Tausenden verbundenen Maschinen ausweiten
    • Echtzeitleistung unter Latenzbeschränkungen: derzeit ist die Denkzeit zwischen Aktionen unbegrenzt, künftig soll in Benchmarks mit weiterlaufendem Factorio die Balance zwischen Antwortlatenz und Lösungsqualität bewertet werden
    • Multi-Agenten-Koordination: Kooperation, Konkurrenz, emergent market dynamics, Arbeitsteilung, Verhandlung über Ressourcenverteilung und die Bildung komparativer Vorteile behandeln
    • Mod-basierte Out-of-Distribution-Umgebungen: evaluieren, ob sich kausale Strukturen unter neuen tech tree und Spielmechaniken neu erlernen lassen
    • Native computer-use interface: Agenten nicht über die Python-API, sondern über eine menschenähnliche Tastatur-, Maus- und Vision-Schnittstelle bewerten
    • Adversariale Dynamiken und Robustheit: hostile aliens und nichtdeterministische Umgebungsherausforderungen einführen, um adaptive control und resilience zu bewerten

Mitmachen

  • Sowohl der Code als auch die Missionen von FLE sind Open Source
  • Gesucht werden insbesondere:
    • Forschende, die neue Architekturen für langfristige Planung und räumliche Schlussfolgerung erkunden
    • Ingenieurinnen und Ingenieure, die Infrastruktur für groß angelegte Evaluierung und Training optimieren
    • Modder, die neue Challenge-Domänen entwerfen
  • Wer sich für eine Mitarbeit im Team interessiert, findet es auf Discord

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-12
Meinungen auf Hacker News

  • Jetzt bin ich komplett angefixt und will mich sofort beim Factorio-Forschungslabor von Anthropic bewerben.
    Nur anhand des Papers oder der Kommentare kann ich nicht erkennen, ob multimodale Daten zurückgesendet werden; da mehrere Modelle nicht multimodal sind, vermutlich eher nicht. Einige können es aber, und das kürzlich erschienene Qwen 2.5 VLM wirkt für seine Größe ziemlich stark.
    Es wurde recht stark auf den Mangel an räumlichen Fähigkeiten hingewiesen und auch auf die Schwierigkeiten sowohl bei Planung als auch bei räumlicher Planung. Ich frage mich daher, ob auch Bilder wie Screenshots gesendet werden. Falls nicht, würde mich interessieren, was ihr dazu denkt.
    Nebenbei: Per MCP Python-Bibliotheken zu aktivieren, damit jedes LLM mit Tool-Nutzung Factorio spielen kann, wirkt wie etwas, das man ganz selbstverständlich unbedingt machen sollte.

    • Derzeit ist es eine reine Textumgebung, aber visuelle Eingaben sind für die Zukunft geplant.
      In einigen Tests hat das Einbeziehen von Screenshots des Spielzustands die Leistung von Standardmodellen nicht verbessert. Je komplexer der Spielzustand wurde und je mehr Entitäten auf dem Screenshot waren, desto stärker wurden die Modelle verwirrt; sie halluzinierten Richtungen oder Entitäten und konnten auch auffällige Fehler wie fehlende Transportbänder oder falsch gedrehte Greifarme nicht korrigieren.
      Wir vermuten, dass aktuelle VLMs bei Bildern mit vielen Details schlecht im räumlichen Schlussfolgern sind; durch Fine-Tuning könnte sich das deutlich verbessern. MCP ist derzeit ebenfalls stark im Kommen, daher werden wir uns das ansehen.
    • Wenn eine textuelle Beschreibung des Fabrikzustands leichter zu interpretieren ist und weniger Verwirrung stiftet, sehe ich nicht, wozu Screenshots nötig wären.
      Das Spiel findet auf einem Raster statt, daher sollte es ziemlich einfach sein, den Spielzustand in eine ASCII-Darstellung zu überführen.

  • Vor Kurzem gab es auf HN einen Beitrag eines Teams, das mit Reinforcement Learning einen Agenten trainiert hat, der Pokémon Red durchspielt. Sie sagten, sie hätten die Kostenfunktion so anpassen müssen, dass es kleine Belohnungen für Erkundung und große Belohnungen für Pflichtaufgaben wie das Besiegen von Arenen gibt.
    Ich frage mich, ob derselbe Ansatz auch für Factorio funktionieren könnte. In der Pokémon-Red-Analogie wären die wichtigsten Pflichtaufgaben in Factorio der Aufbau der Automatisierung neuer Items und neuer Wissenschaftspakete.
    Kleine Belohnungen für die Produktionsrate jedes Items pro Sekunde, mittlere Belohnungen für die Automatisierung neuer Items und große Belohnungen für die Automatisierung neuer Wissenschaftspakete könnten eine gute Reward Function ergeben.
    Einem Factorio-Agenten einfach zu sagen: „Baue eine große Fabrik“, ist so, als würde man einem Pokémon-Red-Agenten sagen: „Spiel das Spiel durch“; man muss es in kleinere Schritte und eine sehr sorgfältig abgestimmte Reward Function aufteilen.
    Beim Nachdenken darüber bekomme ich Lust, bei diesem Projekt mitzumachen.

    • Aus der Perspektive von jemandem mit 2.000–3.000 Stunden Factorio: Das Ziel, die „größtmögliche Fabrik“ zu bauen, ist zu vage und nicht die richtige Metrik.
      Wenn Factorio-Spieler große Megabases bauen, zielen sie nicht auf Größe an sich, sondern auf Science per Minute (SPM). Die Metrik für den Agenten sollte SPM sein, nicht die „größte“ Basis.
    • In FLE haben wir Zugriff auf Meilensteine, die anzeigen, wann eine neue Entität zum ersten Mal erstellt wurde; aber Belohnungen nach Automatisierungsgrad zu schichten, wäre wirklich interessant. Wäre schön, das gemeinsam auszuprobieren.
    • Das ist ein interessanter Punkt. In lab-play konnte Claude Pflichtaufgaben und einfache Automatisierung wie eine Fabrik für Eisenzahnräder erledigen, aber in der Spielepisode „die größte Fabrik bauen“ hat es das nicht einmal versucht.
      Die Modelle können solche Pflichtaufgaben ausführen, aber wenn sie ein allgemeines Ziel wie „schließe das Spiel ab“ bekommen, fehlt ihnen die langfristige Planungsebene, um sie überhaupt anzugehen. Oft bauten sie nur kleine, unkoordinierte Strukturen, statt eine bestehende Fabrik zu erweitern.
      Eines der Ziele war auch herauszufinden, wie Modelle sich verhalten, wenn sie vage und allgemeine Ziele erhalten.
    • Derselbe Ansatz lässt sich auch aufs Leben anwenden.
    • Ich frage mich, ob du die Seite gelesen hast. Tatsächlich gab es Belohnungen für jedes produzierte Item, und für komplexere Items gab es höhere Belohnungen.

  • Interessant ist der Teil, dass sechs Frontier-Sprachmodelle in zwei Settings evaluiert wurden, aber es gibt auch viele deutlich einfachere dynamische Benchmarks, die die Planungsfähigkeiten nicht-reasoning-basierter Modelle sättigen können.
    Schon eine Liste von Flugverbindungen zwischen Städten zu geben und nach einer Reiseroute zwischen ihnen zu fragen, bringt all diese Modelle durcheinander, sobald der kürzeste Pfad zwischen zwei Knoten lang genug wird.
    Der längste kürzeste Pfad zwischen Städten, den sie für jede Länge in 8 von 10 Fällen zuverlässig finden konnten, war wie folgt:
    | 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 |

    • Stimmt. Es gibt einfachere Benchmarks, die die Planungsfähigkeiten solcher Modelle ausreizen.
      Wir wollten jedoch eine Evaluierungsumgebung mit breiterem Spektrum schaffen, die mehrere Fähigkeiten gleichzeitig testet und auch in Zukunft relevant bleiben kann.

  • Dass alle Modelle beim Bau von Fabriken mit mehreren Bereichen Grenzen in der räumlichen Planung zeigten, leuchtet ein. Gemeint sind typische Fehlschläge wie Entitäten zu dicht zu platzieren, keinen Platz für Verbindungen freizuhalten oder Greifarme falsch zu setzen.
    Ich verstehe, warum LLMs bei räumlichem Schlussfolgern schwach sind: Es gibt nicht viel passende Trainingsdaten dafür. Ich frage mich, welche zusätzlichen Reasoning-Fähigkeiten auftauchen würden, wenn räumliches Schlussfolgern gelöst wäre.

    • Dass es nicht viele räumliche Daten gibt, leuchtet mir nicht ganz ein.
      Schon mit dem einfachsten Simulator könnte man doch praktisch unendlich viele erzeugen, oder?
      Wenn man zum Beispiel Tic-Tac-Toe auf einem unendlichen Raster in etwa 10 Zeilen Code implementiert, kann man damit ein unbegrenztes Trainingsset generieren.

  • Als weitere Kategorie für „Lab Play“-Aufgaben würde ich gern Balancer-Design sehen.
    Selbst kleine Balancer können ziemlich komplex sein (https://factorioprints.com/view/-NopheiSZZ7d8VitIQv9); es wäre interessant zu sehen, wie gut Modelle sie entwerfen und Probleme dabei lösen können.

  • Eine großartige Idee
    Es scheint hier viele interessante Experimente zu geben, die man ausprobieren könnte. Zeitaspekte in das lab-play-Szenario einzubauen, klingt nach einer guten Idee. Die meisten Factorio-Spieler, die mit aktivierten Beißern spielen, werden das als Kombination aus Zeit- und Raumconstraints behandeln, und wenn man dem Agenten ein Zeitlimit setzt, ermöglicht das eine Art Proxy-Vergleich mit realen Spielsituationen
    Mir gefällt, dass das Design dieses Frameworks etwas anderes testet als die Fähigkeit zum Micromanagement, wie man sie aus Experimenten mit DOTA 2 oder StarCraft 2 kennt. Gerade in StarCraft 2 führt unbegrenzte APM zu Verhalten wie extremem Fine-Tuning der Arbeiter, um ein klein wenig mehr Mineralien abzubauen
    Solches Verhalten ist in einem engen Kontext ein interessantes Lernergebnis, in der Praxis aber bedienaufwendig und selbst für Profispieler fehleranfällig. Außerdem scheint es keine zusätzlichen Einsichten in die langfristige Planung, Ausführung und Analyseleistung des Agenten zu liefern
    In dieser Hinsicht ist FLE als höher angesetztes Framework zur Bewertung von Denkfähigkeiten deutlich interessanter. Ich frage mich auch, ob es Pläne für Layout-Optimierungs-Benchmarks gibt, etwa die Performance zu optimieren, wenn eine gegebene Fabrikzelle X Eingänge und Y Ausgänge hat

    • Wir sprechen darüber, Aufgaben zu bauen, die eher in Richtung Tower Defense gehen, bei denen Beißer etwa alle X Stufen oder X Sekunden freigelassen werden
      Ziel ist es, die Fähigkeit eines Agenten zu testen, einen militärisch-industriellen Komplex aufzubauen. Ein lustiges Problem bei der Ausarbeitung dieser Idee war, dass Frontier-Modelle sich offenbar sträuben, Entitäten mit Namen wie „GunTurret“ zu erstellen. Sie scheinen das für verfassungswidrig zu halten. Vielleicht müssen wir den Geschützturm in etwas wie „SuperSoaker“ umbenennen
      Über Layout-Optimierungs-Benchmarks haben wir tatsächlich gestern gesprochen. Ich denke, wir brauchen zwei Arten von Layout-Aufgaben: 1) eine subtil kaputte Fabrik reparieren, 2) den Durchsatz dieser Fabrik verbessern. Die Implementierung dürfte relativ einfach sein, daher wäre es gut, sich das einmal anzusehen

  • Ich verstehe es nicht ganz. Wurden diese Modelle nachträglich trainiert, um Factorio zu spielen?
    A) Falls ja: Wie ist das bei Modellen ohne öffentliche Gewichte wie Claude möglich? B) Falls nein: Woher weiß der Agent, was die API macht? Selbst wenn er aus der englischen Bedeutung der API-Befehle schließen kann, dass place_entity_next_to zum Beispiel eine Entität neben etwas platziert – woher kennt er die Rezepte? Wenn er es ausprobiert und daraus lernt, sind wir wieder bei A
    Nachdem ich das PDF gelesen habe, scheint es keine Nachschulung gegeben zu haben; dann weiß ich aber nicht, wie die Fragen unter B erklärt werden
    Wenn es wirklich keine Nachschulung gab und erwartet wurde, dass die Rezeptsuche im Kontextfenster stattfindet, halte ich das für zu kurz für Verbesserungen im Stil von Reinforcement Learning
    Kurz gesagt: Ich weiß nicht, ob man diese Modelle mit Nachschulung hätte testen können, und wenn es ohne Nachschulung geschah, haben sie alle unglaublich gut abgeschnitten
    Falls die Autoren das sehen: Mich würde interessieren, wie viele Paare aus API-Anfrage und API-Antwort durchschnittlich im Kontextfenster stehen. Und anschließend, ob sich die Ergebnisse verbessern, wenn man die Namen der API-Aufrufe abkürzt, sodass mehr Antwortpaare in ein Kontextfenster passen

    • In Bezug auf die Tools hatten die Agenten Zugriff auf die Funktionssignaturen, also Tool-Docstrings, Eingabe- und Ausgabetypen, und zu jedem Tool gab es auch ein kleines „Handbuch“
      Dieses Handbuch erklärte, was das Tool tut, welche Auswirkungen es auf den Spielzustand hat, und enthielt einige Nutzungsbeispiele, etwa wie man mit place_entity_next_to einen Inserter neben eine bestehende Kiste setzt
      Wie Jack sagte, gab es keinerlei Nachschulung, aber alle Agenten hatten eine vollständige API-Beschreibung im Kontext, einschließlich Tools, Entitäten und Forschung. Insofern zeigen die Ergebnisse bis zu einem gewissen Grad, wie gut moderne Agenten eine völlig Out-of-Distribution-API nutzen können, wenn sie passend dokumentiert ist
    • Diese Modelle wurden nicht nachträglich trainiert, sondern waren alle unveränderte Standardmodelle
      In den Kontext passen maximal etwa 128 Paare, aber da die Performance bei 32 Paaren gleich war, haben wir uns wegen Kosten und Latenz letztlich für 32 Paare entschieden
      Wenn Ein- und Ausgaben kürzer codiert wurden, verschlechterte sich die Performance. Beschreibende Namen scheinen vortrainierten Modellen zu helfen, weil sie ihnen eine Intuition dafür geben, was etwas tut
    • Wenn man die Fußnote in der Autorenvorstellung liest, scheint eine Person bei Anthropic zu arbeiten. Vermutlich gab es internen Zugriff

  • Interessant ist, dass es nur wenige komplexe Szenarien gibt. Ich habe immer gedacht, dass ein ML-Spielagent, um die Spielmechanik wirklich zu lernen, Hunderte sehr kleiner Puzzles mit jeweils Hunderten Varianten bräuchte
    Zum Beispiel so etwas: Die Fabrik hat keinen Strom, also den fehlenden Strommast setzen; der Fabrik fehlen Items, also das fehlende Fließband platzieren; 200 Montagemaschinen herstellen und platzieren; eine Montagemaschine steht aus irgendeinem Grund still, also reparieren; die Produktionsmenge der Fabrik ist zu niedrig, also verdoppeln; so schnell wie möglich zu einem anderen Punkt in der Fabrik gelangen; Strommangel beheben; und all diese Aufgaben jeweils mit und ohne Roboter
    Ein paar Tausend solcher Beispielszenarien sollten sich relativ leicht programmatisch erzeugen lassen. Anschließend könnte man sie wie einen Aufgabenpool für IQ-Tests verwenden, daraus etwa 12 Aufgaben ziehen und die Performance jeweils nach Zeit und verwendeten Materialien bewerten
    Ich denke, ein ML-Agent würde schneller lernen, wenn er anhand von Stichproben aus einem großen Szenarienpool mit sanft steigender Komplexität bewertet wird und ihm komplexere Szenarien erst präsentiert werden, nachdem er auf niedriger Komplexität ausreichend hohe Punktzahlen erreicht hat

    • Wie vorgeschlagen, Szenarien als Text zu generieren, ist einfach; den korrekten Fabrik-Spielzustand als Ausgangspunkt zu erzeugen, ist aber deutlich schwieriger
      Soweit ich weiß, läuft es am Ende auf dieselbe Arbeit hinaus: den Anfangszustand und die zu erledigende Aufgabe manuell zu entwerfen
    • Für zusätzliches Training denken wir über einen solchen Curriculum-Ansatz nach
      Die aktuelle Arbeit war jedoch auf Evaluation ausgerichtet, deshalb haben wir das nicht gemacht. Die „Schwierigkeit“ verschiedener Aufgaben ist ziemlich subjektiv, sodass man willkürliche Entscheidungen treffen müsste, die die Evaluation beeinflussen könnten. Zum Beispiel, welche Aufgabe nach welchem Szenario kommen sollte, oder ob alle Schwierigkeitsstufen ausreichend abgedeckt sind

  • Ich frage mich, ob es für diese Art von Interface einen Benchmark mit menschlichen Spielern gibt. Nicht, dass das unbedingt nötig oder relevant wäre; ich bin nur neugierig, wie sich programmatisches Factorio anfühlt
    Räumliches Schlussfolgern rund um Textprompts dürfte auch für menschliche Spieler ziemlich schwierig sein

    • Der menschliche Benchmark in Factorio sind Speedrunner, die auf den ersten Raketenstart hinarbeiten
      Der aktuelle Rekord liegt im Einzelspiel bei etwas über 4 Stunden und im Team bei 90 Minuten. Schon daran sieht man, dass ein multitaskingfähiges LLM Menschen übertreffen könnte

  • Ich frage mich, ob in ein paar Jahren alle Gegner in Spielen LLMs sein könnten, die Zugriff auf solche Game-Control-APIs haben.
    Außerdem frage ich mich, ob es bestimmte Aufgabentypen gab, die den Modellen besonders schwerfielen, oder ob der Schwierigkeitsgrad vor allem mit der Anzahl der zu platzierenden Items steigt.

    • Es ist sehr unwahrscheinlich, dass LLMs in großem Maßstab als Gegner eingesetzt werden. Die Gegner-KI der meisten Spiele braucht nicht die Komplexität, die maschinelles Lernen erfordert. Selbst wenn man die Rechenkosten einmal beiseitelässt.
      Das Hauptziel von Gegner-KI ist nicht, das schwierigste Wesen der Welt zu sein, sondern dem Spieler eine interessante, überwindbare Herausforderung zu bieten. In den meisten Spielen ist es nicht unbedingt schwer, eine extrem leistungsfähige KI zu bauen, aber dadurch wird es nicht automatisch spaßiger, gegen sie zu spielen.
      Die meisten Spiele haben einen endlichen logischen Zustand und sind nur groß genug, dass Menschen nicht alle Lösungen finden können. Menschen sind allerdings sehr gut darin, an den Rändern solcher Zustände zu drücken und Umgehungswege zu finden.
      Selbst bei Spielen mit deutlich größeren Zustandsräumen als üblich will man selten eine Super-KI. In einem FPS spielt zum Beispiel niemand gern gegen einen Aimbot.
      Factorio ist insofern eine Ausnahme gegenüber gewöhnlichen Spielen, als die eigentliche Bedingung für „Sieg“ fast vollständig beim Spieler liegt. In Factorio ohne DLC kann man die Rakete, die Siegbedingung des Spiels, auch bauen, ohne nennenswert eine Fabrik zu errichten, abgesehen von den grundlegendsten Strukturen für Dinge, die man nicht von Hand herstellen kann. Es wäre extrem langsam, aber es ist eine mögliche Option. Daher ist bei einem solchen Benchmark Effizienz wichtiger als „funktioniert es“.
    • Ich halte das für möglich. Denn für den Betrieb ist kein separater Trainingsaufwand nötig. Wenn nur eine API bereitgestellt wird, lassen sich verschiedene Modelle sehr einfach Plug-and-play an ein neues Spiel anbinden.
      Die Modelle haben vor allem in zwei Bereichen Schwierigkeiten. Erstens beim räumlichen Schließen. Die Modelle erzeugen häufig Off-by-one-Fehler, und Fabriken reagieren, ähnlich wie Programmierung, sehr empfindlich auf solche Fehler, sodass sie sich nur schwer davon erholen.
      Zweitens bei der langfristigen Planung: also der Fähigkeit, strategisch zu erkennen, was zu tun ist, bevor taktische Teilziele formuliert werden.
      Bei lab-play ist der Schwierigkeitsgrad in der Regel proportional zur Tiefe der Produktionskette. Wenn man für ein Item zuerst mehrere Fabrikabschnitte braucht, wird es deutlich schwieriger. Das scheint mit Planung zusammenzuhängen, weil die Modelle eher dazu neigen, sich in Details zu vergraben und kleine Probleme zu reparieren, statt zuerst einen großen Plan zu entwerfen.
    • Wenn man „Claude plays Pokémon“ anschaut, sieht man, wie es am Mount Moon scheitert — genauso ging es mir mit vier Jahren auch.
    • Warum muss es ein LLM sein? Ist so etwas nicht genau das, worin AlphaZero gut ist? Es gibt außer LLMs noch viel mehr nützliche Machine-Learning-Modelle!