2026-06-12 Rückblick

Ich habe beschlossen, den Rückblick erneut zu schreiben

Ich hinterlasse nach langer Zeit wieder einen Rückblick. Der Grund, warum ich bisher nicht aufgezeichnet habe, war nicht nur, dass ich zu beschäftigt war, sondern vor allem, weil ich den Wunsch hatte, nur vollkommen perfekte Texte zu hinterlassen. Ich wollte nur dann festhalten, wenn das Ergebnis eindeutig strukturiert war, und fand es unangemessen, gescheiterte oder zwischenzeitlich geänderte Prozesse einfach so zu dokumentieren.

Doch im Nachhinein war gerade dieser Prozess am bedeutungsvollsten. In den letzten zehn Tagen gab es nicht viele fertige Ergebnisse, aber ich habe viel darüber gesammelt, welche Recherchen ich für ein Godot‑spezifisches Codemodell durchgeführt habe, wo ich feststeckte und welche Entscheidungen ich geändert habe. Deshalb habe ich mich heute entschlossen, den bisherigen Verlauf einmal zusammenzufassen.

Lokales Modell‑Experiment

Anfangs wollte ich wegen der Kosten für RunPod ein Qwen‑Modell auf meinem lokalen PC ausführen. Da ich eine RTX 3060 benutze, dachte ich, dass ich ein 9 B‑Modell zumindest in WSL zum Laufen bringen könnte.

In der Praxis funktionierte das jedoch nicht wie erwartet. Netzwerkgeschwindigkeit und Latenz waren problematisch, und bevor ich einmal eine Antwort erhalten hatte, dauerte bereits die Denkphase über fünf Minuten. Unter diesen Bedingungen war die Experiment‑Geschwindigkeit zu langsam, und die Integration in Entwicklungswerkzeuge schien schwierig, sodass ich das lokale Modell sofort verworfen habe.

Aus diesem Experiment wurde klar: Es ist wichtiger, jetzt die Struktur des Datensatzes und die Lern‑Pipeline zu entwerfen, als zu versuchen, ein großes Modell lokal in meiner Umgebung zu betreiben.

Godot‑Datensatz‑Recherche

Um ein Modell zu trainieren, brauchte ich zunächst Daten. Bei der Suche nach einem Datensatz, den ich für das Lernen von Godot 4‑Code verwenden könnte, stieß ich auf den Hugging‑Face‑Datensatz wallstoneai/godot-gdscript-dataset.

• https://huggingface.co/datasets/wallstoneai/godot-gdscript-dataset

Zunächst dachte ich, es handele sich einfach um einen Datensatz mit vielen .gd‑Dateien, aber nach einer Analyse mit Gemini stellte sich heraus, dass die Struktur entscheidend war. Der Kern bestand nicht darin, einzelne Dateien aus einem GitHub‑Repository zu extrahieren, sondern das gesamte Repository zu entpacken, um den Projekt‑Kontext zu erhalten.

Dieser Datensatz scheint das README.md des Repositories, .gd‑Dateien und die Verzeichnisstruktur zu einem einzigen Text zusammenzuführen und darin Projektname, Godot‑Version, Dateibaum und den Inhalt jeder Datei in Markdown‑Form zu organisieren. Auf diese Weise sieht das Modell nicht nur einzelne Code‑Snippets, sondern auch die Projektstruktur und die Beziehungen zwischen den Dateien.

Besonders wichtig war die Methode zur Unterscheidung von Godot 3/4‑Versionen. Godot hat nicht die typische Web‑Projekt‑Struktur mit package.json oder requirements.txt. Stattdessen muss man Werte wie config_version oder config/features in der project.godot‑Datei auslesen oder die Unterschiede in der GDScript‑Syntax nutzen.

Zum Beispiel verwendet Godot 3 onready var, KinematicBody usw., während Godot 4 @onready, CharacterBody3D usw. verwendet. Wenn man diese Syntax‑Unterschiede per Regex oder Parser erfasst, kann man auch bei Sprachen ohne JSON‑basierte Versionsdatei eine gewisse Versions‑Filterung erreichen.

Der Datensatz allein reichte nicht

Danach sah ich ein YouTube‑Video, in dem das Fine‑Tuning einer klassischen Programmiersprache namens OPL demonstriert wurde.

• https://www.youtube.com/watch?v=5wGD92ktQL4

Doch das Video gab mir kein vollständiges Verständnis. Der Prozess des Datensammelns und des Fine‑Tunings muss miteinander verknüpft sein, und die Frage „Was und wie soll man lernen, wenn man nur den Datensatz hat?“ blieb bestehen.

Ich fragte daher meinen SSAFY‑Coach, wie man am effektivsten Daten einer weniger verbreiteten Sprache einer bestimmten Version sammeln kann. Dabei erhielt ich eine wichtige Antwort.

Erstens ist der von mir betrachtete Datensatz eher ein Roh‑Code‑Datensatz als ein Datensatz für das Training eines Assistenten. Wenn das gewünschte Ergebnis ein Chat‑Bot sein soll, reicht es nicht, nur Roh‑Code einzuspeisen.

Zweitens muss man auf Basis des Roh‑Datensatzes Frage‑Antwort‑Paare für das LLM erzeugen. Diese Antwort machte mir klar, was als Nächstes zu tun ist: Nicht nur Godot 4‑Code sammeln, sondern Frage‑ und Antwortdaten generieren, um einen Instruction‑Datensatz zu erstellen.

Ohne diesen Schritt würde das Modell bei Anfragen wie „Erstelle eine Karte“ wahrscheinlich mit Python statt mit Godot antworten, weil frühere Modelle viel Python‑Daten gelernt haben. Fehlen klare Antwortdaten, besteht zudem die Gefahr, dass veralteter Godot‑Code oder falsche Sprachen gemischt werden.

Überlegungen zum Instruction‑Datensatz und Prompting

Als mögliche Instruction‑Datensätze schaute ich mir Magicoder-Evol-Instruct-110K an.

• https://huggingface.co/datasets/ise-uiuc/Magicoder-Evol-Instruct-110K

Die meisten Einträge waren jedoch Python‑zentriert. Wenn man sie unverändert übernimmt, ist das nicht geeignet, ein reines Godot 4‑Modell zu erstellen.

Da kam die Frage auf: „Muss man Godot explizit erwähnen?“ Wenn man viel Godot‑Daten einspeist, könnte das Modell auch ohne explizite Nennung von Godot in der Anfrage Godot‑Code liefern.

Diese Überlegung wurde durch ein Gespräch mit einem älteren Studienkollegen etwas klarer. Heutzutage kann es sinnvoller sein, statt generellem RAG ein gut gestaltetes Prompt‑ oder dokumentenbasiertes Suchsystem zu entwickeln, und nach dem Erstellen von Vektor‑Indizes für Markdown‑Dokumente dem Modell zu ermöglichen, die benötigten Daten gezielt zu finden.

Schließlich kam ich zu dem Schluss, dass in der aktuellen Phase klare Kontextangaben wie „Erstelle eine Karte mit Godot“ eher zu präzisen Antworten führen als ein allgemeines „Erstelle eine Karte“. Da die bestehenden Modelle stark auf Python‑Gewichte trainiert sind, muss die Bedingung „Godot“ bereits im Prompt stark betont werden.

Architektur‑Neugestaltung

Anfangs dachte ich, die Architektur einfach zu halten.

Datensatzerfassung → Frage/Antwort‑Datensatz erstellen → Modelltraining

Aber bald fühlte ich, dass diese Struktur zu gefährlich ist. Wenn ich Daten sammle, ohne genau zu wissen, was sich von Godot 3 zu 4 geändert hat, könnte falscher Code als korrekte Antwortdaten eindringen. Selbst wenn ich einen Frage‑/Antwort‑Datensatz erstelle, könnten Python‑Code oder Godot‑3‑Code vermischt werden.

Deshalb kam mir die Idee, die offizielle Dokumentation als Ausgangspunkt zu nehmen. Ich crawle die Migrationsdokumente von Godot 3 zu 4 und die offizielle Godot‑4‑Dokumentation, erstelle einen RAG‑Chatbot und stelle diesen an die Front‑End‑Schicht, sodass er entscheidet, ob der gesammelte Code zu Godot 3 oder 4 gehört, ob er eine alte API verwendet und ob er für Godot 4 geeignet ist.

Das beigefügte Diagramm zeigt den zu diesem Zeitpunkt erarbeiteten Entwurf der Pipeline.

Der grobe Ablauf ist folgender:

• Offizielle Godot‑Dokumentation und Migrationsdokumente crawlen, um eine RAG‑Wissensbasis zu erstellen.
• Godot‑Projekte von GitHub repository‑weise sammeln.
• README, Dateistruktur und GDScript‑Code zu einem Kontext zusammenführen.
• Durch project.godot‑Einstellungsdateien und Unterschiede in der GDScript‑Syntax eine erste Filterung nach Version durchführen.
• Mit dem RAG‑Chatbot zusätzlich prüfen, ob es sich um Godot 3/4 handelt und ob alte APIs verwendet werden.
• Nur die für Godot 4 bereinigten Daten als Instruction/Response‑Datensatz verwenden.
• Mit SFT‑ und DPO/Preference‑Daten ein Godot‑4‑Coding‑Modell trainieren.

SFT‑ und DPO‑Richtung

Im weiteren Verlauf erhielt ich durch Nachfragen bei ChatGPT auch unerwartete Richtungen. Ich hatte zunächst nur an ein „Modell, das Godot‑4‑Code erzeugt“ gedacht, konnte die Lernaufgaben aber genauer unterteilen.

Für SFT können folgende Aufgaben definiert werden:

• Klassifizierung von Godot 3/4‑Code
• Umwandlung von Godot 3‑Code in Godot 4‑Code
• Generierung von Godot 4‑Code
• Korrektur von Godot 4‑Fehlern
• Ablehnung oder Korrektur von Godot 3‑APIs

Bei DPO/Preference lässt sich klar zwischen schlechten und guten Antworten unterscheiden. Zum Beispiel wird eine Antwort, die Godot‑3‑Syntax enthält, als schlechte Antwort markiert, während eine rein in Godot 4 geschriebenen Antwort als gute Antwort gilt.

Durch diese Sichtweise entstand die Erkenntnis, dass man nicht einfach „so viele Daten wie möglich sammeln“ sollte, sondern zuerst festlegen muss, was als gute Antwort gilt.

Crawling der offiziellen Godot‑Dokumentation

Um diesen Ansatz praktisch zu testen, habe ich ein Crawling‑Tool gefunden und crawl4ai verwendet.

• https://github.com/unclecode/crawl4ai
• https://docs.godotengine.org/en/stable/tutorials/migrating/upgrading_to_godot_4.html

Ich habe die offizielle Godot‑4‑Dokumentation, die Godot‑3→4‑Migrationsdokumente, die Godot‑4‑Klassenreferenz und die Godot‑4‑Tutorials insgesamt etwa 1 500 Seiten gecrawlt und dokumentiert.

Zunächst dachte ich, das sei zu viel, aber im Vergleich zur Gesamtkontextgröße des Modells entspricht das nur etwa 3 % des Umfangs. Wenn man die Daten nicht komplett ins Modell einspeist, sondern sie für RAG‑ oder Dokumentsuch‑Strukturen nutzt, ist das gut handhabbar.

Daten‑Pipeline und I/O‑Überlegungen

Beim erneuten Entwerfen der Architektur kamen Disk‑I/O und Lern‑Timing ins Spiel. Wenn Datensammlung, Vorverarbeitung, Nachbearbeitung, Speicherung, Re‑Indexierung und Training nahtlos aneinandergereiht werden, entsteht zwangsläufig ein Engpass.

Auch hier habe ich einen älteren Studenten um Rat gefragt. Die erhaltene Antwort war, dass es besser sei, das Fine‑Tuning nicht in Echtzeit laufen zu lassen, sondern zuerst Daten zu sammeln und aufzubereiten und das Training batch‑weise durchzuführen.

Beispielsweise führt man Reinforcement‑Learning oder Fine‑Tuning nur aus, wenn ein Datensatz einen bestimmten Schwellenwert überschreitet. Wie bei einem Replication‑Slot reduziert das die I/O‑Engpässe, und bei zeitkritischen Teilen liegt der Fokus eher auf Datenbeschaffung und -aufbereitung als auf dem eigentlichen Training.

Die Kosten für Re‑Indexierung lassen sich strukturell nicht vollständig eliminieren. Statt zu versuchen, diese Kosten zu entfernen, ist es realistischer, klare Kriterien festzulegen, wann re‑indiziert und wann trainiert wird.

Zusammenfassung des Tages

Wenn man den Verlauf der letzten zehn Tage zusammenfasst, begann alles mit dem vagen Gedanken „Ich muss ein Godot‑Coding‑Modell bauen“. Jetzt gibt es eine konkretere Struktur.

Ein reiner Roh‑Code‑Datensatz reicht nicht aus. Man benötigt bereinigte Code‑Daten, die auf Godot 4 basieren, ein auf offizieller Dokumentation beruhendes Bewertungssystem, Instruction/Response‑Daten, SFT‑Aufgaben und DPO/Preference‑Kriterien.

Außerdem ist es mit meinem derzeitigen Kenntnisstand unrealistisch, ein Coding‑Modell von Grund auf ohne ein großes Modell wie Qwen zu erstellen. Der Vergleich zwischen einem lokalen Anfangs‑Modell und den Coding‑Fähigkeiten von ChatGPT zeigte, dass Unterschiede in Modellgröße und Vor‑Training nicht zu ignorieren sind.

Dennoch ist die Richtung jetzt viel klarer. Man kann eine Wissensbasis auf Basis der offiziellen Godot‑4‑Dokumentation aufbauen, gesammelte Daten filtern und anhand von Kriterien für gute und schlechte Antworten Trainingsdaten erzeugen.

Rückblick

Beim Schreiben dieses Rückblicks fiel mir am stärksten auf, dass man die Schwelle für das Festhalten von Aufzeichnungen senken muss. Wenn man nur perfekte Ergebnisse dokumentiert, gehen die wirklich wichtigen Prozesse verloren. Fehlgeschlagene Experimente, unsichere Entscheidungen und geänderte Architekturen bilden das Material für zukünftige Entscheidungen – wenn man sie nicht festhält, versteht man später nicht, warum man bestimmte Wege gewählt hat.

Künftig will ich nicht nur fertige Ergebnisse hochladen, sondern den Prozess selbst häufiger dokumentieren. Statt den Rückblick wegen eines vorzeitigen Scheiterns aufzuschieben, möchte ich sowohl Misserfolge als auch Überlegungen festhalten, weil das meiner Meinung nach der bessere Weg ist.

Ich möchte ab jetzt konsequent Rückblicke schreiben. Es muss kein perfekter Text sein, und auch Zwischenschritte sind okay. Wichtig ist, dass ich festhalte, was ich versucht habe, was ich gelernt habe und nach welchen Kriterien ich beim nächsten Mal handeln will.