idea_world_labDEV JOURNAL
Freitag, 12. Juni 2026

12. Juni 2026

  • Ich habe beschlossen, nach langer Zeit das Entwicklungs‑Review erneut zu schreiben

    • Ich habe es immer aufgeschoben, weil ich nur perfekte Aufzeichnungen hinterlassen wollte
    • Um die Versuche und Überlegungen der letzten etwa 10 Tage sinnvoll zu dokumentieren, habe ich die Recherche und den Architekturentwurf für ein auf Godot spezialisiertes Codierungsmodell zusammengefasst

  • Ich habe ein Experiment durchgeführt, um die RunPod‑Kosten zu senken, indem ich Qwen‑Modelle auf meinem lokalen PC bereitstelle

    • Ich wollte ein 9 B‑Modell unter WSL auf einer RTX 3060‑Umgebung ausführen
    • Allerdings waren Netzwerkgeschwindigkeit und Latenz problematisch, und bereits die Vorverarbeitungsphase dauerte über 5 Minuten, sodass das lokale Experiment abgebrochen wurde

  • Für das Training eines Godot‑spezifischen Modells habe ich zunächst die Datensatzerfassungsmethode untersucht

    • Das Dataset wallstoneai/godot-gdscript-dataset wurde als Referenz‑Dataset identifiziert
    • Mit Gemini habe ich analysiert, wie dieses Dataset erstellt wurde
    • Kern war, dass GitHub‑Repository‑Einheiten wie README.md, .gd‑Dateien und Projektstrukturen zu einem einzigen Text zusammengeführt werden und anhand der project.godot‑Konfigurationsdatei sowie GDScript‑Syntaxunterschiede Godot 3/4‑Versionen klassifiziert werden
    • Insbesondere zeigte sich, dass man mithilfe von Versions‑Hinweisen wie config_version, config/features, onready var, @onready, KinematicBody, CharacterBody3D auch bei nicht‑mainstream‑Sprachen ohne JSON‑Abhängigkeitsdateien eine Versionsfilterung durchführen kann

  • Um den Fine‑Tuning‑Prozess zu verstehen, habe ich ein Fine‑Tuning‑Video zu der klassischen Programmiersprache OPL angesehen

  • Ich habe den SSAFY‑Coach gefragt, wie man Daten von nicht‑mainstream‑Sprachen einer bestimmten Version effektiv sammelt

    • Die derzeit betrachteten Godot‑Daten entsprechen eher einem rohen Code‑Dataset als einem Q&A‑Dataset für das Training von Assistenten
    • Für ein Chatbot‑Produkt sollte man Rohdaten nicht unverändert verwenden, sondern mit einem LLM Frage‑Antwort‑Paare generieren und in ein Instruction‑Dataset umwandeln
    • Ohne diesen Schritt würde das Modell bei Anfragen wie „Entwirf eine Karte“ wahrscheinlich stark python‑zentrierte Antworten liefern, die es bereits gelernt hat

  • Als Kandidat für ein Instruction‑Dataset habe ich ise-uiuc/Magicoder-Evol-Instruct-110K geprüft

    • Da es überwiegend Python‑zentriert ist, ist es nicht direkt für reines Godot 4‑Training geeignet
    • Ich fragte mich, ob man das Modell dazu bringen kann, Godot‑Antworten zu geben, ohne Godot explizit zu erwähnen, kam jedoch zu dem Schluss, dass das klare Setzen des Kontextes „Godot“ die Wahrscheinlichkeit einer korrekten Antwort erhöht, weil das Ausgangs‑LLM stark auf Python gewichtet ist

  • Ich habe einen Senior‑Studenten zu RAG‑ und Prompt‑Strategien befragt

    • Statt alle Daten in das Modell zu injizieren, könnte ein Vektor‑Such‑System auf Basis von Markdown‑Dokumenten aufgebaut werden, das nur die benötigten Informationen abruft – ein pragmatischer Ansatz
    • Da das erneute Indizieren großer Dokumentmengen kosten‑ und zeitintensiv ist, erscheint in der aktuellen Phase ein auf Suche/Prompting basierendes System geeigneter als reines Training

  • Ich habe die anfängliche Architektur für ein Godot‑spezifisches Codierungsmodell entworfen

  • Anfangs dachte ich an eine einfache Struktur wie Datensatzsammlung -> Frage/Antwort-Datensatz erstellen -> Modelltraining

    • Es stellte sich jedoch das Problem, dass man die Änderungen von Godot 3 zu 4 gut kennen muss, um eine genaue Filterung und Erstellung von Antwortdaten zu ermöglichen
    • Da bei einem Fehler Godot‑3‑Code, Python‑Code oder veraltete APIs in den Antwortdaten vermischt werden könnten, habe ich die Architektur neu überdacht

  • Für die Klassifizierung und Konvertierung von Godot‑3/4‑Versionen habe ich ein Design mit einem RAG‑Chatbot an der Front konzipiert

    • Ich dachte daran, die offizielle Godot‑Migrationsdokumentation und die Godot‑4‑Dokumentation zu crawlen, einen RAG‑Chatbot zu erstellen und diesen zu nutzen, um zu bestimmen, ob gesammelte Daten zu Godot 3 oder 4 gehören
    • Anschließend soll nur der als Godot 4 identifizierte Datensatz zu einem Instruction‑Datensatz verarbeitet werden

  • Durch ChatGPT habe ich zusätzliche Einblicke in die SFT/DPO‑Lernrichtung erhalten

    • Bei SFT können Aufgaben wie Godot‑3/4‑Klassifizierung, Godot‑3 → 4‑Konvertierung, Godot‑4‑Code‑Generierung, Godot‑4‑Fehlerbehebung und Godot‑3‑API‑Ablehnung/Korrektur erstellt werden
    • Bei DPO/Preference kann man Präferenzdaten zusammenstellen, indem man schlechte Antwort = Antwort mit gemischtem Godot‑3‑Code und gute Antwort = reine Godot‑4‑Code‑Antwort definiert

  • Mit unclecode/crawl4ai wird das Crawlen der offiziellen Godot‑Dokumentation durchgeführt

    • Startdokument: https://docs.godotengine.org/en/stable/tutorials/migrating/upgrading_to_godot_4.html
    • Etwa 1 500 Seiten wurden aus der offiziellen Godot‑4‑Dokumentation, den Godot‑3 → 4‑Migrationsdokumenten, der Godot‑4‑Klassenreferenz und den Godot‑4‑Tutorials gecrawlt und dokumentiert
    • Obwohl das Volumen größer erschien, schätzte ich es im Kontext des gesamten Modell‑Kontexts auf etwa 3 % des Umfangs ein

  • Zur Disk‑I/O‑Engpass‑Problematik von Datenspeicherung und Lern‑Pipeline habe ich einen älteren Studienkollegen um Rat gefragt

    • Statt das Fine‑Tuning in Echtzeit laufen zu lassen, wurde empfohlen, Datenerfassung und Vor‑/Nachverarbeitung nahezu in Echtzeit zu erledigen und das Training batch‑weise durchzuführen
    • Wir beschlossen, ein metrikenbasiertes Batch‑Processing zu erwägen, bei dem Verstärkungs‑Learning oder Fine‑Tuning ausgelöst werden, sobald der Datensatz einen bestimmten Schwellenwert überschreitet
    • Da die Kosten für Re‑Indexierung strukturell nicht vollständig eliminiert werden können, wurde festgehalten, dass die Stabilität der Datenerfassungs‑ und Verarbeitungspipeline wichtiger ist als die Echtzeit‑Verfügbarkeit des Trainings

  • Aktuell zusammengefasste Gesamtstrategie

    • Offizielle Dokumentation crawlen, um eine RAG‑Wissensbasis für Godot 4 aufzubauen
    • Godot‑Projekte von GitHub sammeln und pro Repository README, Projektstruktur und GDScript‑Dateien zusammenführen
    • Erste Filterung mittels project.godot‑Einstellungen und Godot‑3/4‑Syntaxunterschieden
    • Mit dem RAG‑Chatbot prüfen, ob es sich um Godot 3/4 handelt, ob veraltete APIs verwendet werden und ob die Daten für Godot 4 geeignet sind
    • Aus den gefilterten Godot‑4‑Daten Instruction/Response‑Paare erzeugen
    • Mit SFT‑ und DPO/Preference‑Daten ein Godot‑4‑Coding‑Modell trainieren

  • Rückblick

    • In den letzten zehn Tagen wollte ich nur das fertige Ergebnis festhalten und habe deshalb den Prozess nicht dokumentiert
    • Ich habe jedoch erkannt, dass gescheiterte Experimente, blockierte Punkte und geänderte Entscheidungen genau die Aufzeichnungen sind, die für die nächste Richtung wichtig sind
    • Künftig werde ich nicht nur perfekte Ergebnisse festhalten, sondern kontinuierlich den Fluss von Versuchen und Entscheidungen dokumentieren und so weiterentwickeln

  • Entwicklungsrückblick: docs/retrospectives/2026-06-12.md