FactorSmith: Agentic Simulation Generation via Markov Decision Process Decomposition with Planner-Designer-Critic Refinement

Die Arbeit stellt FactorSmith vor, ein Framework, das mittels faktorisierter POMDP-Zerlegung zur Kontextreduktion und eines hierarchischen Agenten-Workflows mit Planer-, Designer- und Kritiker-Rollen spielbare Simulationen aus natürlichen Sprachbeschreibungen mit verbesserter Codequalität und geringeren Laufzeitfehlern generiert.

Das Wesentliche

🎮 FactorSmith: Der clefe Game-Designer mit einem Team aus drei Köpfen

Stell dir vor, du möchtest ein neues Videospiel programmieren, aber du hast keine Programmierkenntnisse. Du schreibst einfach einen Text: „Mach ein Spiel, in dem ein Ball von einer Leiter fällt und von einem Frosch gefangen wird."

Früher haben große Sprach-KIs (wie ein sehr gut lesender, aber manchmal verwirrter Assistent) versucht, das ganze Spiel auf einmal zu schreiben. Das Problem? Wenn der Text zu lang oder das Spiel zu komplex wird, verliert der Assistent den Faden. Er erfindet Funktionen, die nicht existieren, oder vergisst Regeln. Das ist, als würde man versuchen, einen ganzen Hochhauskomplex in einem einzigen Satz zu beschreiben – es wird chaotisch.

FactorSmith ist eine neue Methode, die dieses Problem löst. Sie kombiniert zwei geniale Ideen: Zerlegung und Teamarbeit.

1. Die Zerlegung: „Nimm dir nicht zu viel auf einmal vor" 🧩

Stell dir vor, du musst ein riesiges Puzzle bauen. Wenn du versuchst, alle 10.000 Teile auf einmal zu sortieren, wirst du verrückt.
FactorSmith macht etwas anderes: Es zerlegt das Puzzle in kleine, handliche Stapel.

• Der Trick: Das Spiel wird nicht als ein riesiger Block betrachtet, sondern als eine Reihe von kleinen Schritten (z. B. erst den Ball programmieren, dann die Schwerkraft, dann den Frosch).
• Der Vorteil: Der KI-Assistent bekommt für jeden Schritt nur die Informationen, die er wirklich braucht. Er muss nicht das ganze Puzzle sehen, sondern nur den kleinen Stapel, an dem er gerade arbeitet. Das nennt man im Fachjargon „faktorierte Zerlegung", aber denk einfach an Fokus.

2. Das Team: Der Planer, der Designer und der Kritiker 🎭

Das ist die eigentliche Magie. Bei früheren Methoden hat der Assistent versucht, den Code sofort perfekt zu schreiben. Wenn er einen Fehler machte, musste er raten, ob er es nochmal versuchen sollte.

FactorSmith führt stattdessen ein Dreier-Team ein, das bei jedem kleinen Schritt zusammenarbeitet:

• Der Planer (Der Dirigent): Er hält den Takt. Er sagt: „Okay, wir machen jetzt den Ball." Er überwacht den Prozess und entscheidet, wann wir weitermachen oder zurückgehen müssen.
• Der Designer (Der Architekt): Er schreibt den Code. Er nimmt die Anweisung des Planers und baut das kleine Modul. Aber er ist nicht perfekt – er macht Fehler.
• Der Kritiker (Der strenge Chef): Er schaut sich den Code des Designers genau an. Er hat eine Checkliste (Ist es korrekt? Fehlt etwas? Sieht es gut aus?). Er gibt eine Punktzahl (z. B. 6 von 10) und sagt: „Hier fehlt eine Kollisionserkennung."

Das Spiel:

1. Der Designer schreibt etwas.
2. Der Kritiker prüft es und sagt: „Nicht schlecht, aber 6/10. Hier ist ein Fehler."
3. Der Planer sagt: „Okay, Designer, mach es nochmal!"
4. Der Designer verbessert den Code.
5. Der Kritiker prüft wieder: „Jetzt sind es 9/10!"
6. Der Planer sagt: „Perfekt! Wir speichern das und gehen zum nächsten Schritt."

Wenn der Designer beim zweiten Versuch schlechter wird (z. B. 4/10), sagt der Planer: „Stopp! Wir gehen zurück zum letzten guten Stand (Checkpoint)." Das verhindert, dass das Projekt in die falsche Richtung abdriftet.

Warum ist das so erfolgreich? 🚀

In den Tests (mit Spielen wie „Snake" oder „Flappy Bird") hat FactorSmith gezeigt, dass es viel weniger Fehler macht als andere Methoden.

• Ohne Team: Der Assistent schreibt alles auf einmal, wird verwirrt und das Spiel funktioniert nicht.
• Mit Team: Der Assistent arbeitet in kleinen Schritten, wird ständig geprüft und verbessert, bis alles perfekt ist.

Die Zusammenfassung in einem Satz

FactorSmith ist wie ein Baumeister, der ein riesiges Schloss nicht in einem Rutsch baut, sondern Stockwerk für Stockwerk (Zerlegung) und dabei jedes Stockwerk von einem Architekten entwerfen, von einem Prüfer kontrollieren und von einem Bauleiter genehmigen lässt, bevor das nächste Stockwerk gebaut wird.

Das Ergebnis sind Spiele, die nicht nur funktionieren, sondern auch stabil und fehlerfrei sind – alles automatisch aus einem einfachen Textbefehl heraus.

Technische Zusammenfassung

1. Problemstellung

Die Generierung ausführbarer Simulationen (z. B. Spiele oder Umgebungen für Reinforcement Learning) aus natürlichen Sprachbeschreibungen stellt eine erhebliche Herausforderung dar. Große Sprachmodelle (LLMs) stoßen bei großen, miteinander verknüpften Codebasen an ihre Grenzen:

• Kontextüberlastung: LLMs neigen dazu, bei umfangreichen Kontexten zu halluzinieren, nicht existierende Funktionen zu erfinden oder Teile der Spezifikation zu ignorieren.
• Mangelnde Selbstkorrektur: Bestehende Ansätze wie FactorSim zerlegen zwar das Problem in kleinere Schritte, verwenden aber einen „Single-Shot"-Ansatz pro Schritt. Wenn der LLM-Ausgang fehlerhaft ist, gibt es keinen Mechanismus zur systematischen Selbstkorrektur, außer einem einfachen Retry mit Debugging.
• Fehlende Struktur: Ansätze wie SceneSmith nutzen zwar Multi-Agenten-Workflows für 3D-Szenen, nutzen aber nicht die strukturellen Eigenschaften von Code-Simulationen zur Kontextreduktion.

2. Methodik: FactorSmith

FactorSmith vereint zwei komplementäre Konzepte, um hochwertige, ausführbare Simulationen zu generieren:

A. Faktorierte POMDP-Zerlegung (Kontextreduktion)

Das Framework basiert auf der Darstellung von Simulationen als Partially Observable Markov Decision Process (POMDP).

• Zerlegung: Die Simulation wird in modulare Schritte ($q_1, \dots, q_K$) zerlegt.
• Kontextauswahl: Anstatt den gesamten Codebase in jeden LLM-Aufruf einzuspeisen, wird für jeden Schritt nur eine minimale Teilmenge relevanter Zustandsvariablen ($S[Z_k]$) und abhängiger Funktionen ausgewählt. Dies reduziert den „Kontext-Fenster"-Overhead drastisch.
• MVC-Muster: Jeder Schritt wird weiter in drei Komponenten unterteilt, die dem Model-View-Controller-Muster entsprechen: Eingangslogik (Controller), Zustandsübergang (Model) und Rendering (View).

B. Agente Workflow: Planner–Designer–Critic

Innerhalb jedes faktorierten Schritts wird ein iterativer Verfeinerungsprozess durch ein Trio von Agenten durchgeführt:

1. Designer (D): Er schlägt Code-Änderungen oder neue Artefakte vor, basierend auf dem eingeschränkten Kontext.
2. Critic (C): Bewertet den Vorschlag des Designers anhand domänenspezifischer Kriterien (Korrektheit, Vollständigkeit, Zustandsnutzung, Codequalität). Er liefert strukturierte numerische Scores (0–10) und textuelles Feedback.
3. Planner (P): Koordiniert den Prozess. Er entscheidet basierend auf den Scores, ob der Entwurf akzeptiert, eine weitere Verfeinerung angefordert oder ein Checkpoint-Rollback durchgeführt wird (falls die Qualität sinkt).

Der Ablauf pro Schritt:

1. Zustandsauswahl: Identifikation relevanter Variablen.
2. Zerlegung: Aufteilung der Aufgabe in MVC-Komponenten.
3. Iterative Verfeinerung: Für jede Komponente läuft ein Loop, in dem Designer und Critic interagieren, bis ein Schwellenwert ($\tau$) erreicht ist oder die maximale Anzahl an Runden erreicht ist.
4. Integration: Der beste Zustand wird in die globale Simulation integriert.

3. Schlüsselbeiträge

1. Formalisierte Framework: Eine neue Architektur, die den Planner–Designer–Critic-Workflow in jeden Schritt einer faktorierten POMDP-Generierungspipeline integriert.
2. Mathematische Analyse: Eine Herleitung, wie die agente Verfeinerung mit der kontextuellen Auswahl zusammenspielt, inklusive einer Analyse der Rechenkosten und der Garantie einer nicht-abnehmenden Qualität (durch Checkpoint-Rollback).
3. Open-Source-Implementierung: Eine auf dem OpenAI Agents SDK basierende Implementierung mit SQLite-unterstütztem Session-Management und strukturiertem Scoring.
4. Experimentelle Validierung: Nachweis der Überlegenheit gegenüber nicht-agente Baselines und reinen Faktorisierungsansätzen.

4. Ergebnisse

Die Evaluation erfolgte auf dem PyGame Learning Environment (PLE) Benchmark mit acht 2D-Spielen (z. B. Flappy Bird, Snake, Pong).

• Vergleichsgruppen: FactorSmith wurde gegen Vanilla (Single-Shot), Self-Debug, CoT + Self-Debug, FactorSim (nur Faktorisierung) und AgentCoder (Multi-Agenten ohne Faktorisierung) getestet.
• Leistung: FactorSmith erzielte in allen Spielen die höchste System-Test-Pass-Rate.
  • Im Vergleich zu FactorSim (dem stärksten Baseline) wurden konsistente Verbesserungen erzielt (z. B. +8 Prozentpunkte bei Catcher und Waterworld).
  • Die größten Gewinne wurden bei Spielen mit komplexen Zustandsinteraktionen erzielt, wo einzelne Schritte oft subtile Fehler enthalten, die ein Critic identifizieren kann.
• Ablationsstudie:
  • Das Entfernen des Critics führte zu einem Leistungsabfall von 7 %, was die Notwendigkeit iterativer Bewertung unterstreicht.
  • Das Entfernen der Faktorisierung (Verwendung des vollen Kontexts) führte zum größten Rückgang (–12 %), was bestätigt, dass Kontextreduktion der wichtigste Faktor ist.
• Token-Effizienz: Obwohl FactorSmith durch die mehrstufige Verfeinerung mehr Token verbraucht als FactorSim, ist es effizienter als CoT + Self-Debug, da der strukturierte Score eine frühere Terminierung ermöglicht und der Kontext pro Aufruf kleiner ist.

5. Bedeutung und Ausblick

Bedeutung:
FactorSmith demonstriert, dass strukturelle Zerlegung (Faktorisierung) und agente Verfeinerung (iteratives Feedback) synergistisch wirken. Die Faktorisierung verhindert, dass das Modell von großen Kontexten überwältigt wird, während das Agenten-Trio lokale Fehler in einem gut definierten Kontext korrigiert. Dies überwindet die Grenzen von reinen „Single-Shot"-Generierungen und reinen Test-basierten Multi-Agenten-Ansätzen (die oft fehleranfällige Testfälle generieren).

Zukünftige Richtungen:

• Integration von Ausführungs-Feedback (Execution-based feedback), bei dem der generierte Code tatsächlich ausgeführt wird, um das Feedback des Critics zu validieren.
• Erweiterung auf 3D-Simulationen für Robotik.
• Nutzung der faktorierten Struktur für parallele Generierung unabhängiger Zweige.
• Training spezialisierter, kleinerer Modelle für die Rollen von Designer und Critic zur Kostensenkung.

Zusammenfassend bietet FactorSmith einen robusten, modularen Ansatz für die LLM-gesteuerte Simulationserstellung, der durch die Kombination von mathematischer Struktur und agentenbasiertem Qualitätsmanagement neue Maßstäbe in der Code-Generierung setzt.