Praxis · Grundlagen

Wie ein Weltmodell
lernt, träumt und plant.

25. August 2026 · Lesezeit ca. 8 Minuten

Ein Weltmodell ist ein Programm, das vorhersagt, wie sich eine Umgebung nach einer Handlung verändert. Ich habe eins in einer einzigen Python-Datei gebaut, ohne PyTorch und ohne Grafikkarte. Dieser Text erklärt, aus welchen vier Teilen so etwas besteht und wozu der Aufwand gut ist.

Das Problem, das ein Weltmodell löst

Wer schon einmal eine Spiel-KI geschrieben hat, kennt den Aufbau. Man braucht eine Funktion naechster_zustand(zustand, zug), spielt damit mögliche Zugfolgen durch, bewertet die Ergebnisse und führt den besten ersten Zug aus. Bei Schach oder Tic-Tac-Toe schreibt man diese Funktion selbst hin, weil die Regeln bekannt sind.

Sobald die Eingabe aus Sensordaten besteht, kann das niemand mehr. Ein Roboter sieht ein Kamerabild, kein Koordinatensystem. Für die Frage „Wie sieht das Bild aus, wenn ich mich nach rechts drehe?“ gibt es keine Regel zum Hinschreiben. Also lernt man sie aus aufgezeichneten Daten. Dieses gelernte naechster_zustand ist ein Weltmodell.

Der Ansatz stammt aus der Forschung an Agenten, die aus Bildern lernen. David Ha und Jürgen Schmidhuber trainierten 2018 eine Steuerung teilweise in einer gelernten Simulation statt in der Umgebung selbst (World Models). Die Dreamer-Arbeiten von Danijar Hafner und Kollegen gingen denselben Weg weiter und lernten Verhalten aus vorgestellten Abläufen (Dream to Control). Mein Versuch ist eine Nummer kleiner: eine Rasterwelt, zwei kleine Netze, ein Planer, der würfelt.

Die Welt besteht aus 49 Pixeln

Die Umgebung ist ein Raum aus 7×7 Feldern. # ist eine Wand, Z das Ziel, o der Agent:

#######
#..#..#
#..#..#
#..o..#
#.##..#
#....Z#
#######

Vier Aktionen, eine Belohnung von 1 auf dem Zielfeld, sonst nichts. Wichtig ist, was der Agent nicht bekommt: keine Koordinate, keine Karte, keine Liste von Wänden. Seine Beobachtung besteht aus 49 Grauwerten, einer pro Feld. Wand ist 1,0, das Ziel 0,6, er selbst 0,3, freie Felder 0. Alles, was er über seine Welt weiß, muss er aus diesen 49 Zahlen ziehen.

Das ist die abgespeckte Version des Roboterproblems. Klein genug, dass ein Durchlauf zwei Minuten auf einem Notebook dauert, und groß genug, dass die typischen Fehler auftreten.

Schritt 1: ziellos herumlaufen und alles mitschreiben

Ein Modell braucht Trainingsdaten, und die gibt es hier nur durch Ausprobieren. Der Agent läuft 3.000 Schritte lang zufällig durch den Raum. Jeder Schritt wird als Zeile mitgeschrieben: Bild vorher, Aktion, Bild nachher, Belohnung, Episode zu Ende ja oder nein. Das ist eine Logdatei, mehr nicht.

In meinem Lauf waren das 94 Episoden, in denen der Zufall 38-mal auf dem Ziel landete. 1,3 Prozent der 3.000 Zeilen enthalten überhaupt eine Belohnung. Mit dieser Ausbeute muss alles Weitere auskommen. Wer schon mit unausgewogenen Datensätzen gearbeitet hat, ahnt das Problem: Ein Modell, das stur „Belohnung 0“ vorhersagt, liegt in 98,7 Prozent der Fälle richtig und ist für die Planung wertlos.

Schritt 2: 49 Zahlen auf 8 eindampfen

Direkt auf Pixeln zu planen ist teuer. Deshalb kommt zuerst ein Autoencoder. Das ist ein Netz mit Sanduhrform: Es presst die 49 Werte durch einen Engpass von 8 Zahlen und muss aus diesen 8 Zahlen das Originalbild wieder herstellen. Trainiert wird gegen den eigenen Eingang, Beschriftungen braucht es keine.

Der Trick liegt im Engpass. Durch 8 Zahlen passt nicht viel, also muss das Netz sich aussuchen, was wichtig ist. Wände und Ziel stehen in jedem Bild an derselben Stelle und tragen deshalb keine Information. Neu ist nur, wo der Agent steht. Wenn die Kompression funktioniert, steht in den 8 Zahlen im Wesentlichen seine Position, hergeleitet ohne dass ihm jemand gesagt hätte, dass es so etwas wie eine Position gibt. Der Fachbegriff dafür ist latenter Zustand.

Hier ist mein erster Anlauf danebengegangen, und der Fehler ist der lehrreichste Teil des Projekts. Der Rekonstruktionsfehler fiel auf 0,0015 und blieb dort. Das sieht nach einem sauber austrainierten Netz aus. Tatsächlich war es genau der Fehler, den man bekommt, wenn man Wände und Ziel perfekt malt und den Agenten weglässt: Ein falsches Pixel von 49 fällt im Durchschnitt nicht auf. Das Netz hatte die Karte auswendig gelernt und die einzige veränderliche Sache ignoriert.

Schritt 3: der Traum

Jetzt kommt das eigentliche Weltmodell. Ein zweites Netz bekommt die 8 Zahlen und eine Aktion und sagt voraus: die 8 Zahlen danach, die Belohnung, und ob die Episode endet. Es sieht kein einziges Pixel mehr. Dieser Bruch ist der Grund für den Aufwand aus Schritt 2. Ein Planungsschritt kostet damit acht Zahlen statt neunundvierzig.

Weil das Modell aus seiner Ausgabe wieder eine Eingabe machen kann, läuft es in einer Schleife: eine Beobachtung am Anfang, danach nur noch Aktionen. Das Programm nennt das einen Traum. Der Decoder aus Schritt 2 macht aus den 8 Zahlen wieder ein Bild, damit man zuschauen kann. Links die Wirklichkeit, rechts die Vorstellung, aus einem Lauf von heute:

Welt       Traum
#######    #######
#..#..#    #..#..#
#..#..#    #..#..#
#.....#    #.....#
#.##o.#    #.##o.#
#....Z#    #....Z#
#######    #######

1. rechts  Belohnung echt 0 / getraeumt 0.00
#.##.o#    #.##.o#

2. rechts  Belohnung echt 0 / getraeumt 0.00
#.##.o#    #.##..#

3. runter  Belohnung echt 1 / getraeumt 0.00
#....o#    #..o.Z#

Schritt 1 stimmt. In Schritt 2 verliert der Traum den Agenten, in Schritt 3 setzt er ihn an die falsche Stelle und übersieht die Belohnung. So sieht der Zerfall aus, wenn ein Modell seine eigenen Fehler weiterverarbeitet.

Wie weit der Traum trägt

Diesen Zerfall kann man messen. Das Modell bekommt ein Bild und danach nur noch Aktionen. Gezählt wird, ob der geträumte Agent auf dem richtigen Feld steht. Daneben läuft ein Vergleichsmodell, das behauptet, es ändere sich überhaupt nichts. Das ist die Latte, die ein Weltmodell mindestens reißen muss.

Der Traum zerfällt langsam und vorhersehbar. Daraus folgt die Betriebsregel für den nächsten Schritt: Der Agent plant nur wenige Züge weit und liest danach wieder die Wirklichkeit ein.

Schritt 4: planen heißt würfeln und aussortieren

Der Planer ist der einfachste Teil des Programms und lernt gar nichts. Vor jedem echten Zug würfelt er 100 zufällige Aktionsfolgen von je sechs Zügen. Jede Folge spielt er im Traum durch und addiert die vorhergesagten Belohnungen. Von der besten Folge führt er nur den ersten Zug aus, schaut sich die echte Welt an und würfelt neu. Das Verfahren heißt Random Shooting mit Model Predictive Control und macht ungefähr das, was ein Navigationsgerät an jeder Abzweigung tut.

Zum Vergleich läuft derselbe Planer mit den echten Spielregeln statt mit dem gelernten Modell, im Programm „Orakel“ genannt, und einer, der nur zufällig läuft. 20 Episoden, Abbruch nach 40 Schritten, Planungshorizont 6:

Der Träumer schlägt die Wirklichkeit, weil er sich irrt

Ein gelerntes Modell kann nicht genauer sein als das Original, das es nachahmt. Trotzdem steht da 20/20 gegen 19/20, und der Träumer braucht ein Drittel der Schritte. Ich habe nachgesehen, woher der Vorsprung kommt.

Er kommt von den Startfeldern, die weiter als sechs Züge vom Ziel entfernt sind. Dort findet das Orakel unter 100 gewürfelten Folgen keine einzige, die das Ziel erreicht. Alle 100 bekommen den Wert 0, es gibt nichts zu vergleichen, der Planer wählt praktisch zufällig. Das Weltmodell sagt dagegen kleine Belohnungen zwischen 0,00003 und 0,77 vorher, wo es gar keine gibt. Diese Fehler häufen sich auf Wegen in Richtung Ziel. Aus einer Belohnung, die nur auf einem einzigen Feld existiert, wird dadurch ein Gefälle über den ganzen Raum.

Der Vorsprung war also geborgt. Bei Horizont 12, wenn das Orakel die Belohnung selbst findet, zieht es mit 20 von 20 gleich. Die Unschärfe wirkt auch in die andere Richtung: Bei Horizont 3 sagt das Weltmodell Belohnungen an Stellen vorher, die nirgendwohin führen, und fällt auf 8 von 20 zurück. Das ist schlechter als reines Würfeln mit 9 von 20.

Was davon im normalen Entwickleralltag hängen bleibt

• Ein guter Durchschnitt kann den einen wichtigen Fall verstecken. Der Rekonstruktionsfehler von 0,0015 sah nach Konvergenz aus, während das Netz den Agenten übersah. Eine zweite Kennzahl, die genau das misst, worum es fachlich geht, kostete zwölf Zeilen.
• Eine billige Vergleichslinie gehört von Anfang an dazu. Das starre Modell „nichts ändert sich“ trifft nach einem Schritt in 35 Prozent der Fälle. Ohne diesen Wert wüsste ich nicht, ob 95 Prozent viel sind.
• Ein gutes Endergebnis beweist nicht, dass die Teile stimmen. Der Planer war erfolgreich, weil das Modell falsch lag. Wer nur die Erfolgsquote misst, hält ein kaputtes Modell für ein gutes.
• Zwanzig Episoden und ein einziger Zufallsstartwert sind keine Statistik. 20/20 gegen 19/20 ist ein Unterschied von einer Episode. Die Erklärung dahinter habe ich nachgemessen, den Zahlenvorsprung selbst würde ich ohne mehrere Startwerte nicht verteidigen.

Selbst laufen lassen

Das Programm braucht Python ab 3.6 und kein einziges pip-Paket. Ein vollständiger Durchlauf dauert etwa zwei Minuten, der größte Teil davon entfällt auf das Training des Autoencoders.

python weltmodell.py zeigen        # Umgebung ansehen
python weltmodell.py sammeln       # 3000 Übergänge aufnehmen
python weltmodell.py trainieren    # Autoencoder und Dynamiknetz
python weltmodell.py traeumen      # Traum und Wirklichkeit nebeneinander
python weltmodell.py planen 6      # Weltmodell gegen Orakel gegen Zufall
python weltmodell.py warum         # woher der Vorsprung kommt

Die Messwerte in diesem Beitrag stammen aus einem Lauf von heute auf einem Windows-Notebook mit Python 3.8.10. Sie decken sich mit den protokollierten Werten des ursprünglichen Beitrags, weil alle Zufallsstartwerte fest gesetzt sind. Über verschiedene Startwerte, Karten oder Rechner sagt das nichts aus.