idea_world_labDEV JOURNAL
Freitag, 12. Juni 2026

12. Juni 2026

  • Nach langer Zeit beschlossen, das Entwickler‑Retrospektive erneut zu schreiben

    • In der Zwischenzeit habe ich mich zu sehr darauf konzentriert, nur perfekte Aufzeichnungen zu hinterlassen, und habe dadurch das Schreiben immer wieder aufgeschoben
    • Um die Versuche und Überlegungen der letzten etwa 10 Tage sinnvoll festzuhalten, habe ich die Recherche und den Architektur‑Entwurfsprozess für ein Godot‑spezifisches Codierungsmodell dokumentiert

  • Ein Experiment durchgeführt, um die RunPod‑Kosten zu senken, indem ein Qwen‑Modell auf dem lokalen PC bereitgestellt wird

    • Versucht, ein 9B‑Modell unter WSL auf einer RTX 3060‑Umgebung zu betreiben
    • Allerdings waren Netzwerk‑Durchsatz und Latenz problematisch; bereits die Vorverarbeitungsphase dauerte über 5 Minuten, sodass das lokale Experiment abgebrochen wurde

  • Untersuchung der Datensatzerfassungsmethode für das Training eines Godot‑spezifischen Modells

    • Das Dataset wallstoneai/godot-gdscript-dataset auf Hugging Face als Referenz‑Datensatz geprüft
    • Mit Gemini analysiert, wie dieses Dataset erstellt wurde
    • Kern war, GitHub‑Repository‑Einheiten – README.md, .gd‑Dateien, Projektstruktur – zu einem einzigen Text zusammenzuführen und anhand von project.godot‑Konfigurationsdateien sowie GDScript‑Syntax‑Unterschieden Godot 3/4 zu klassifizieren
    • Insbesondere zeigte sich, dass Version‑spezifische Hinweise wie config_version, config/features, onready var, @onready, KinematicBody, CharacterBody3D es ermöglichen, selbst bei nicht‑mainstream‑Sprachen ohne JSON‑Abhängigkeitsdateien eine Versionsfilterung vorzunehmen

  • Um den Fine‑Tuning‑Ablauf zu verstehen, ein Video zum Fine‑Tuning der klassischen Programmiersprache OPL angesehen

  • Den Coach von SSAFY nach effektiven Methoden gefragt, um Daten von weniger verbreiteten Sprachen einer bestimmten Version zu sammeln

    • Die aktuelle Godot‑Datensammlung ist eher ein Roh‑Code‑Datensatz als ein Q&A‑Datensatz für das Training von Assistenten
    • Für ein Chat‑Bot‑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 gut gelernt hat

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

    • Da es überwiegend Python‑basiert ist, ist es nicht direkt für reines Godot‑4‑Training geeignet
    • Die Frage, ob man das Modell dazu bringen kann, Godot‑Antworten zu geben, ohne Godot explizit zu erwähnen, blieb offen; jedoch erhöht das klare Einbringen des Kontexts „Godot“ die Wahrscheinlichkeit einer korrekten Antwort, weil das Ausgangs‑Modell stark auf Python gewichtet ist

  • Einen Senior‑Studenten zu RAG‑ und Prompt‑Strategien befragt

    • Statt alle Daten dem Modell zuzuführen, könnte ein Vektor‑Such‑System auf Basis von Markdown‑Dokumenten aufgebaut werden, das gezielt 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 Such‑/Prompt‑basiertes System geeigneter als reines Training

  • Erste 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 falscher Handhabung Godot‑3‑Code, Python‑Code und veraltete APIs in den Antwortdaten vermischt werden könnten, wurde die Architektur neu überdacht

  • Für die Klassifizierung und Konvertierung von Godot‑3/4‑Versionen wurde ein RAG‑Chatbot auf Basis offizieller Dokumentation an der Front platziert

    • Man stellte sich vor, die offiziellen Godot‑Migrationsdokumente und die Godot‑4‑Dokumentation zu crawlen, einen RAG‑Chatbot zu erstellen und diesen zu nutzen, um gesammelte Daten als Godot 3 oder 4 zu klassifizieren
    • Anschließend wurde ein Workflow entworfen, bei dem nur als Godot 4 erkannte Daten zu einem Instruction‑Datensatz verarbeitet werden

  • Durch ChatGPT wurden zusätzliche Einblicke in SFT/DPO‑Lernansätze gewonnen

    • 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 wurde das Crawlen der offiziellen Godot‑Dokumentation durchgeführt

    • Startdokument: https://docs.godotengine.org/en/stable/tutorials/migrating/upgrading_to_godot_4.html
    • Es wurden etwa 1 500 Seiten inklusive der offiziellen Godot 4‑Dokumentation, der Godot 3 → 4‑Migrationsdokumente, der Godot 4‑Klassenreferenz und der Godot‑4‑Tutorials gecrawlt und dokumentiert
    • Obwohl das Volumen größer erschien, wurde es im Kontext des gesamten Modell‑Kontexts auf etwa 3 % geschätzt

  • Zur Disk‑I/O‑Flaschenhals‑Problematik in Speicher‑ und Lern‑Pipelines wurde ein Senior‑Kollege um Rat gefragt

    • Statt das Fine‑Tuning in Echtzeit laufen zu lassen, wurde empfohlen, Datenerfassung und Vor‑/Nachverarbeitung fast in Echtzeit zu erledigen und das Training batch‑weise durchzuführen
    • Man entschied, bei Erreichen einer bestimmten Datenmenge Reinforcement‑Learning oder Fine‑Tuning batch‑weise nach Metriken auszuführen
    • Da die Kosten für Re‑Indexierung strukturell nicht vollständig eliminiert werden können, wurde festgehalten, dass die Stabilität der Daten‑Erfassungs‑ und Verarbeitungs‑Pipeline wichtiger ist als Echtzeit‑Training

  • Aktuell zusammengefasste Gesamtstrategie

    • Offizielle Dokumente crawlen, um eine RAG‑Wissensbasis für Godot 4 aufzubauen
    • GitHub‑Godot‑Projekte sammeln und pro Repository README, Projektstruktur und GDScript‑Dateien zusammenführen
    • project.godot‑Einstellungen und Godot‑3/4‑Syntaxunterschiede für die erste Filterung nutzen
    • Mit dem RAG‑Chatbot Godot‑3/4‑Status, Nutzung veralteter APIs und Godot 4‑Kompatibilität zusätzlich bestimmen
    • Aus den bereinigten Godot‑4‑Daten Instruction/Response‑Paare erzeugen
    • Godot‑4‑Coding‑Modell mit SFT‑ und DPO/Preference‑Daten trainieren

  • Rückblick

    • In den letzten zehn Tagen wollte ich nur die fertigen Ergebnisse festhalten, wodurch ich den Prozess nicht dokumentierte
    • Doch gescheiterte Experimente, blockierte Punkte und geänderte Entscheidungen sind genau die Aufzeichnungen, die für die nächste Richtung wichtig sind
    • Künftig will ich nicht nur perfekte Ergebnisse festhalten, sondern kontinuierlich den Verlauf von Versuchen und Entscheidungen dokumentieren und weiterentwickeln

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