idea_world_labDEV JOURNAL
Donnerstag, 18. Juni 2026

18. Juni 2026

  • Gestern habe ich im Café etwa einen Liter Kaffee getrunken, und heute ging es mir sehr schlecht, sodass ich nicht richtig programmieren konnte

  • Am 17. Juni wurden alle von der Basislinie abgeleiteten Godot‑RAG‑Chunking‑/Nachbearbeitungs‑Ausgaben entfernt

    • v1 docs_chunks.jsonl, v2 docs_chunks_v2.jsonl, v3/v3.1‑Katalog/Index/Mapping‑Ausgaben gelöscht
    • Entwurfs‑Skripte für Chunking/Nachbearbeitung/Validierung sowie den ersten RAG‑Chat/Index‑Entwurf ebenfalls entfernt
    • work/godot_rag/ bleibt vorerst leer, um fehlerhafte Ausgaben nicht als Basislinie zu verwenden

  • Der Grund für die Bereinigung wurde als Rückblick festgehalten

    • Es wurde festgestellt, dass das Problem darin lag, dass das Chunking begonnen wurde, bevor die ursprüngliche offizielle Dokumentationsstruktur ausreichend analysiert war
    • Das Ziel, die gesamte offizielle Godot‑Dokumentation als Grundlage zu nutzen, wurde durch „MVP‑Kern‑APIs“, die das LLM willkürlich auswählte, sowie durch Hard‑Coding‑/Über‑Engineering‑Ansätze verwässert
    • Es wurde angegeben, dass ChatGPT/Codex eigenständig den Umfang reduzierte oder annahm, dass eine Antwort bereits vor Abschluss eines Schrittes vorlag, und daraufhin weitere Ausgaben erzeugte, obwohl ich das nicht angeordnet hatte
    • Wenn die Herkunft von LLM‑Generaten, Regex‑Kandidaten, offiziellen Dokumentationsbelegen und vom Nutzer genehmigten Regeln vermischt wird, können sie nicht als Grundlage für Labeler‑/RAG‑Entscheider verwendet werden

  • Die Mängel der aktuellen Architektur wurden erneut dokumentiert

    • Die statische Analyse‑Schicht ist schwach
    • Es fehlt eine GDScript‑AST/Parser‑basierte Validierung
    • Der Abhängigkeitsgraph des Godot‑Projekts ist unzureichend
    • Laufzeit‑/Syntax‑Validierung ist schwach
    • Das Label‑Taxonomie ist noch grob
    • Die Unterscheidung der Herkunft von LLM‑Generaten und validierten Antworten ist schwach
    • Das Design zur Vermeidung von Datenlecks/Doppelungen ist unzureichend

  • Die nächste Arbeitsrichtung wird auf die Analyse der Original‑godot_docs_full‑Dokumentation zurückgesetzt

    • Statt sofort RAG oder Katalog neu zu erstellen, wird zunächst outputs/godot_docs_full/pages selbst analysiert
    • Es muss geprüft werden, welche Markdown‑Struktur die Klassen‑Referenz, Migration und Tutorial‑Dokumente jeweils haben
    • Entsprechend der Struktur der offiziellen Godot‑Dokumentation muss neu entschieden werden, ob Chunk‑Einheiten pro Seite, pro Abschnitt oder pro API‑Member verwendet werden sollen
    • Vor dem Chunking muss zunächst ein Validierungs‑Report‑Standard definiert werden.

  • Entwicklungsrückblick: docs/retrospectives/2026-06-18-godot-rag-reset.md

2026 Juni 17

  • Die Ausrichtung des Godot 4‑Coding‑Modells wurde von reinem Q&A‑Lernen zu einem SWE‑Agent‑Trajectory‑Training umstrukturiert

    • Es wurde festgestellt, dass kleine Instruction‑Q&A‑Sets nicht ausreichen, um Projekt‑Anfragen wie „Erstelle eine Karte“ zu bearbeiten
    • Ein echter Coding‑Agent benötigt eine komplette Trajektorie: Repository‑Durchsuchung → Auswahl relevanter Dateien → Code‑Änderungen → Test/Validierung → Patch‑Erstellung
    • Als Schlüsselbegriffe wurden Long-context repository-level software engineering agent training und SWE-agent trajectory training notiert
    • Als Referenzbeispiele wurden SWE‑Agent‑Trajektorien, SWE‑smith, SWE‑Gym, CoderForge‑Preview, ACC, RepoBench/CrossCodeEval/RepoCoder, aiXcoder CoLT, godot‑dodo, wallstoneai‑Datensatz zusammengefasst

  • Der gesamte Roadmap für die Entwicklung eines Godot‑LLM wurde in Bild‑ und Textform festgehalten

    • Der Gesamtfluss wurde in die Phasen Daten → 1. RAG‑Chatbot → SFT → DPO → SWE‑Agent unterteilt
    • Von Stage 0 (Vorbereitung) bis Stage 6 (kontinuierliche Verbesserung) wurden Datenakquise/‑strukturierung, 1. RAG‑Chatbot, Daten‑Labeling, Modell‑Training, SWE‑Agent‑Entwicklung sowie Betrieb/‑Retraining beschrieben
    • Der Kern besteht darin, zuerst einen 1. RAG‑Chatbot als Godot‑Dokumentations‑Experten zu bauen, diesen zum Labeln/Verarbeiten von GitHub‑Daten zu nutzen und anschließend das Modell sowie den SWE‑Agent zu erweitern

  • Ergänzende Notiz zur Daten‑Generierung auf Basis eines Godot‑RAG‑Judgers

    • Die endgültige Label‑Entscheidung wird nicht dem LLM überlassen, sondern vom System‑Pipeline‑Mechanismus getroffen
    • Das LLM übernimmt ausschließlich unterstützende Generierungsaufgaben wie korrigierten Code, Erklärungen, SFT‑Fragen/‑Antworten, DPO‑Negative‑Beispiele oder Patch‑Entwürfe
    • Der Ablauf umfasst: API‑Mapping‑DB, offizielle Dokumentations‑Vektor‑DB, Label‑Prototype‑DB → Symbol‑Extraktion → Suche → Label‑Scoring → JSONL‑Zusammenstellung/‑Validierung
    • Die zu erzeugenden Datensätze wurden in acht Kategorien eingeteilt: Version‑Classification, API‑Mapping, Migration‑Fix, Instruction‑SFT, DPO‑Preference, Repo‑Explorer, Patch‑Generation, Metadata‑Verification

  • Separate Notiz zum MVP‑Entwicklungsfluss vom Godot‑RAG‑Judger zum Qwen 3.6‑Coding‑Modell

    • Vom Aufbereiten der Original‑Dokumente godot_docs_full.zip über das Chunking mit chunk_docs.py, godot‑spezifische Nachbearbeitung bis zum Aufbau einer lokalen Such‑Infrastruktur wurde der gesamte Prozess dokumentiert
    • Durch Kombination von Vector‑DB, Keyword‑Index, Reranker, API‑Mapping‑DB und Label‑Prototype‑DB wird das Label vom System entschieden
    • Nach Strukturierung der GitHub‑Daten wird der RAG‑Judger ausgeführt, das LLM übernimmt nur noch unterstützende Rollen (korrigierter Code, Erklärungen, QA‑Beispiele)
    • Im ersten Qwen 3.6‑SFT‑Durchlauf liegt der Fokus auf Godot 4‑Priorität, GDScript‑Grundausgabe und Ablehnung von Godot 3‑APIs; anschließend folgen DPO‑ und SWE‑Erweiterungen

  • Lösung des Git‑Hub‑Contributions‑Grafik‑Problems durch Anpassung von Git‑Author/Email

    • Globale Git‑Konfiguration auf yyeongjin <appsky1888@gmail.com> geändert
    • Es wurde festgestellt, dass im bisherigen main‑Verlauf Author‑/Committer‑E‑Mails aus localhost, Naver und GitHub‑noreply gemischt waren
    • Author und Committer des main‑Verlaufs wurden einheitlich auf yyeongjin <appsky1888@gmail.com> gesetzt und remote gepusht
    • Der Zustand vor dem Rewrite wurde in dem lokalen Backup‑Branch backup/before-author-email-rewrite-2026-06-17 gesichert

  • Dokumentation

2026 Juni 14

  • Im Bus nach Seoul wurden die offenen Fragen zum Godot 4‑Datensatz/RAG‑Pipeline erneut strukturiert

    • Zuvor war geplant, die offizielle Godot‑Dokumentation zu crawlen, GitHub‑Projekte in md‑ bzw. jsonl‑Formate zu konvertieren und über einen RAG‑Chatbot zu entscheiden, ob es sich um Godot 3 oder Godot 4 handelt
    • Es stellte sich jedoch die Frage, ob der gesamte Projekt‑Kontext plus die gefundenen Dokumenten‑Snippets gleichzeitig in das Modell‑Eingabekontext passen

  • Überlegungen zu den Eingabekontext‑Grenzen eines RAG‑Chatbots

    • Ein einzelnes GitHub‑Projekt enthält README, Verzeichnisstruktur, zahlreiche .gd‑Dateien, Szenen‑Dateien und Ressourcen‑Pfade
    • Werden zusätzlich noch per RAG gefundene offizielle Dokumente angehängt, wächst das Eingabevolumen stark; daher ist die Auswahl relevanter Dateien und Dokumenten‑Snippets wichtiger als das bloße Sammeln von Material

  • Fragen zur Form des Frage‑Antwort‑Datensatzes

    • Anfragen wie „Erstelle eine Karte“ enden nicht zwangsläufig mit einem einzigen Code‑Snippet
    • Vielmehr sind mehrere Inferenz‑Schritte nötig: Projektstruktur erfassen, benötigte Assets prüfen, bestehenden Code‑Stil analysieren, Godot 4‑Syntax prüfen, zu ändernde Dateien bestimmen usw.
    • Daraus ergibt sich die Diskussion, ob ein Instruction‑Datensatz nur den finalen Code enthalten sollte oder ob auch Such‑ und Entscheidungsprozesse dokumentiert werden müssen

  • Mögliche Rückkehr zu stärker gewichteten Python‑Tokens bei Chunk‑Verarbeitung

    • Selbst bei der Anfrage „Godot 4, erstelle eine Karte“ könnte das Modell während des Chunk‑basierten Lesens wieder auf vortrainierte Python‑Gewichte zurückgreifen
    • Deshalb muss Godot 4‑Kontext bereits zu Beginn des Prompts stark hervorgehoben und im Daten‑Pre‑Processing rigoros gefiltert werden, um Vermischungen mit Godot 3‑Code oder Python‑Antworten zu vermeiden

  • Zusammenfassung des Tages

    • RAG oder Crawling allein lösen das Problem nicht; entscheidend ist, zu entwerfen, welche Kontext‑Informationen das Modell liest und wie es daraus Schlüsse zieht
    • Der Projekt‑Kontext soll nach Datei‑/Rollen‑/Abhängigkeits‑Kriterien segmentiert werden; das Instruction‑Dataset kann neben der finalen Antwort auch, falls nötig, den Such‑ und Entscheidungsablauf enthalten
    • Um zu verhindern, dass Godot 4‑Kontext im Inferenz‑Prozess verwässert wird, müssen Prompt, Tags, Filter und Präferenz‑Daten stärker auf Godot 4 ausgerichtet werden

  • Entwicklungs‑Retrospektive: docs/retrospectives/2026-06-14.md