LLM-RL-Visualized: ein Diagramm-Repository statt einer Bibliothek

Was hier eigentlich ausgeliefert wird

Das Repository enthält keine Python-Bibliothek, obwohl Python als Hauptsprache geführt wird. Ausgeliefert werden Bilddateien: laut README über 100 Original-Architekturbilder, im Verzeichnis src/assets abgelegt, dazu zwei PDF-Gesamtkarten, die als rl-algo-map.pdf und als LLM-Struktur-Gesamtbild verlinkt sind. Die Diagramme sind als SVG hinterlegt und werden im README als Vektorgrafiken beschrieben, die sich beliebig skalieren lassen und deren Text auswählbar bleibt. Genau darin liegt der praktische Unterschied zu einem gerasterten Screenshot aus einem Paper: ein SVG lässt sich in Folien einbetten, ohne dass die Beschriftung ausfranst. Die Zielgruppe sind Menschen, die diese Algorithmen erklären müssen oder erklären wollen: Kursleitende, Vortragende, technische Redakteure, aber auch Ingenieure, die vor dem Einstieg in eine RLHF-Pipeline erst einmal verstehen wollen, welche Modelle in welchem Verhältnis zueinander stehen. Das Repository ist als Begleitmaterial zu dem Buch aufgeführt, das über die Douban-Seite verlinkt ist. Wer eine ausführbare Implementierung braucht, sucht am falschen Ort.

Die Gliederung als eigentliche Architektur

Die elf Teile des Inhaltsverzeichnisses sind keine Sammlung von Einzelbildern, sondern eine didaktische Reihenfolge. Teil 1 setzt zwei Gesamtkarten an den Anfang, die als Orientierung dienen sollen. Teil 2 bis 4 arbeiten sich von der LLM-Struktur über SFT bis zu DPO vor, Teil 5 behandelt Verfahren ohne Gewichtsänderung von CoT über die Dekodierstrategien bis RAG und Function Calling. Ab Teil 6 beginnt der Reinforcement-Learning-Block, der mit Grundbegriffen wie Return, Value und dem Verhältnis von Q- und V-Funktion startet und erst danach zu Actor-Critic, GAE, PPO und GRPO übergeht. Teil 8 verbindet das mit RLHF und RLAIF, Teil 9 widmet sich der Reasoning-Optimierung, Teil 10 den Trainings- und Inferenzoptimierungen von Quantisierung über Gradient Checkpointing bis RoPE. Diese Ordnung ist der interessanteste Teil des Projekts: sie zwingt dazu, PPO nicht als isolierten Algorithmus zu zeigen, sondern als Endpunkt einer Kette, die bei der Wertfunktion beginnt. Wer den Stoff schon kennt, kann die Reihenfolge ignorieren; wer ihn unterrichtet, bekommt hier eine fertige Sequenz. Ein Vorbehalt: das Verzeichnis listet Titel, nicht Inhalte. Ob ein einzelnes Diagramm die Herleitung liefert oder nur das Ergebnis zeigt, lässt sich aus der Liste nicht beurteilen.

Installation gibt es nicht, nur einen Klon

Es existiert keine Installationsanleitung, weil es nichts zu installieren gibt. Der übliche Weg ist ein Klon des Standard-Branches master, also git clone https://github.com/changyeyu/LLM-RL-Visualized.git, gefolgt vom Öffnen der SVG-Dateien unter src/assets. Für die Gesamtkarten verweist das README auf die PDF-Dateien im Wurzelverzeichnis, deren Dateinamen Leerzeichen und chinesische Zeichen enthalten, was beim Verlinken aus Skripten heraus Anführungszeichen oder eine URL-Kodierung erfordert. Die README-Datei selbst ist zweisprachig: README.md auf Chinesisch, src/README_EN.md als englische Fassung. Ein Hinweis für alle, die die Bilder in eigene Dokumentation einbinden wollen: die Verweise im README zeigen teils auf Pfade wie images_chinese/rl-algo-map-preview.png für die Vorschau, während die hochauflösende Fassung als PDF danebenliegt. Wer die Vorschau einbettet und die hohe Auflösung vergisst, produziert genau die unscharfen Folien, die das Projekt vermeiden will.

Was das Repository nicht leistet

Der Name LLM-RL-Visualized legt nahe, dass hier etwas visualisiert wird, das auch läuft. Das tut es nicht. Es gibt keine Releases, keine Testdateien, keine Konfigurationsdateien für Trainingsläufe und, soweit aus dem Material ersichtlich, keine Skripte, die ein Diagramm erzeugen. Die Bilder sind gezeichnete Artefakte, keine Ausgabe eines Programms. Daraus folgen zwei Grenzen. Erstens ist die Aktualität an die Bearbeitung durch die Autoren gebunden: das README nennt ausdrücklich laufende Korrekturen und Ergänzungen, was bedeutet, dass ein Diagramm veralten kann, ohne dass ein Commit es sichtbar markiert. Zweitens fehlt jede Form der Verifikation. Ein Leser kann nicht nachprüfen, ob die dargestellte Formel der in einer Bibliothek implementierten entspricht, außer indem er selbst nachrechnet. Für Unterrichtsmaterial ist das akzeptabel, weil die Verantwortung ohnehin bei der Lehrperson liegt. Für eine technische Spezifikation ist es zu wenig. Und wer gehofft hat, aus den Diagrammen Hyperparameter-Empfehlungen abzuleiten, wird enttäuscht: das Verzeichnis nennt zwar Themen wie den Einfluss des Beta-Parameters bei DPO, aber die Diagramme sind keine Messreihen.

Der Vergleich mit Code-Bibliotheken

Der naheliegende Gegenpol ist eine Bibliothek wie TRL von Hugging Face, die SFT, DPO, PPO und GRPO als Trainer-Klassen bereitstellt. Der Unterschied liegt nicht im Umfang, sondern in der Richtung des Informationsflusses. TRL nimmt Daten und ein Modell und gibt Gewichte aus; man erfährt, was passiert, indem man den Lauf beobachtet oder den Code liest. LLM-RL-Visualized nimmt den umgekehrten Weg und liefert zuerst das Bild davon, was passieren soll, ohne dass ein einziger Tensor bewegt wird. Beide Zugänge schließen sich nicht aus, aber sie ersetzen einander nicht. Wer die Diagramme als Vorbereitung nutzt und danach in TRL einsteigt, hat einen Vorteil beim Lesen der Konfigurationsparameter. Wer die Diagramme als Ersatz für einen Lauf nutzt, wird an der ersten Fehlermeldung scheitern. Eine zweite Abgrenzung: Papers wie der PPO- oder der DPO-Text enthalten selbst Abbildungen. Deren Vorteil ist die Nähe zur Originalnotation, ihr Nachteil die Heterogenität über mehrere Quellen hinweg. Der Wert dieser Sammlung liegt in der einheitlichen Bildsprache über Themen, die sonst aus verschiedenen Papern zusammengesucht werden müssten.

Lizenz und Weitergabe

Die Metadaten nennen als Lizenz NOASSERTION. Das ist keine Lizenz, sondern die Abwesenheit einer maschinenlesbaren Kennung. Aus dem Repository selbst lässt sich damit nicht ableiten, ob die Diagramme weiterverbreitet, verändert, in kommerziellen Schulungen verwendet oder in ein eigenes Buch übernommen werden dürfen. Wer die Bilder nur lokal zum Lernen öffnet, hat damit kein Problem. Wer sie in ein öffentlich zugängliches Schulungsdeck, in ein Kursangebot oder in ein Produkt einbaut, muss die Bedingungen beim Autor klären, bevor er weitermacht. Das ist kein formaler Hinweis am Rand: ein Repository mit über hundert Grafiken, die ausdrücklich als Original bezeichnet werden, ist urheberrechtlich gerade nicht trivial, und NOASSERTION bedeutet hier nicht Freigabe. Eine rechtliche Bewertung kann dieser Text nicht liefern, und die Lizenzdatei, falls vorhanden, wurde im vorliegenden Material nicht mitgeliefert. Diese Frage ist der erste Punkt, der vor einer Übernahme geklärt werden sollte.

Pflegeaufwand beim Nachziehen

Die Wartungskosten liegen beim Autor, nicht beim Nutzer. Das ist der Vorteil eines reinen Asset-Repositories: es gibt keine Abhängigkeiten, die brechen, keine API, die sich ändert, keine Version, die man pinnen muss. Der Preis dafür zeigt sich beim Aktualisieren. Wer die Diagramme in eigene Unterlagen eingebettet hat, merkt eine Korrektur nur, wenn er den Branch erneut klont oder die Änderungen verfolgt. Es gibt keine Versionsnummer und keine Releases, an denen man sich orientieren könnte; die Metadaten zeigen lediglich einen letzten Push-Zeitpunkt. Für ein Buchbegleitprojekt ist das nachvollziehbar, für eine Referenz, auf die sich mehrere Teams verlassen, ist es eine Schwachstelle. Praktisch bedeutet das: die Bilder einmal kopieren und danach nicht mehr als Quelle der Wahrheit behandeln. Wer sie zitiert, sollte das Datum des Abrufs festhalten, weil sich der Inhalt unter demselben Pfad ändern kann.

Für wen sich der Klon lohnt

Nützlich ist das Repository für drei Gruppen. Erstens für Lehrende, die eine visuelle Klammer um SFT, DPO, PPO und GRPO brauchen und die Reihenfolge aus Teil 1 bis 11 übernehmen können. Zweitens für Ingenieure, die aus einem Codebestand kommen und die Begriffe Value, Advantage und Return zuerst in Bildern sortieren wollen, bevor sie eine Trainingskonfiguration schreiben. Drittens für technische Redakteure, die Formulierungen für die Beschriftung eigener Grafiken suchen. Nicht geeignet ist es für alle, die eine reproduzierbare Referenz brauchen: es gibt keine Tests, keine Releases und keine Versionsnummer. Ebenfalls nicht geeignet für Teams, die eine Lizenzfreigabe für eine kommerzielle Schulungsplattform benötigen, solange NOASSERTION nicht geklärt ist. Der erste konkrete Schritt vor jeder Nutzung ist ein Blick in die Datei, die die Lizenz regelt, und bei Unklarheit eine Rückfrage beim Autor. Der zweite Schritt ist ein Klon des master-Branches und ein Test, ob die SVG-Dateien im eigenen Werkzeug, etwa in einer Präsentations- oder Layout-Anwendung, mit auswählbarem Text ankommen. Wenn das nicht der Fall ist, ist der Hauptvorteil dieser Sammlung bereits verloren.

Redaktionelles Fazit

Wer Lehrmaterial, Onboarding-Folien oder eine visuelle Referenz zu SFT, DPO, PPO, GRPO und RLHF braucht, kann die SVG-Dateien direkt in eigene Unterlagen einbinden. Wer eine trainierbare Implementierung sucht, ist hier falsch und sollte zu einer Code-Bibliothek greifen. Vor jeder Verwendung außerhalb des Repositories ist die Lizenzfrage zu klären: die Metadaten nennen NOASSERTION, es gibt also keine maschinenlesbare Kennung, und ob eine kommerzielle Nutzung oder eine Aufnahme in ein Buch gestattet ist, lässt sich daraus nicht ableiten.

Offizielle Quellen

1. changyeyu/LLM-RL-Visualized on GitHub
2. Issues
3. Project website
4. README