idea_world_labDEV JOURNAL
Mittwoch, 17. Juni 2026

2026-06-17 Godot RAG Erkennungsmodul -> Qwen 3.6 Codierungsmodell Entwicklungsablauf Notiz

Struktur Bild

Entwicklungsablauf vom Godot RAG Erkennungsmodul zum Qwen 3.6 Codierungsmodell

Kernablauf

Godot-Officialdokumentation Vorbereitung
-> Erstes Chunking
-> Godot-spezifische Nachbearbeitung
-> Aufbau einer lokalen Suchinfrastruktur
-> Sammlung und Strukturierung von GitHub-Daten
-> Ausführung des RAG-Detektors
-> Erstellung eines Trainingsdatensatzes
-> Training des Qwen 3.6 Coding‑Modells

Diese Notiz fasst den MVP‑Ablauf zusammen, bei dem zunächst ein Godot‑RAG‑Detektor erstellt und dieser dann verwendet wird, um einen auf Qwen 3.6 basierenden Godot‑Coding‑Modell‑Datensatz zu erzeugen.

Zusammenfassung der Schritte

1. Vorbereitung der offiziellen Dokumentation

  • godot_docs_full.zip vorbereiten
  • Verwendung der fertig gecrawlten offiziellen Dokumentation
  • Noch im Originaldaten‑Zustand, nicht als RAG verarbeitet
  • Eingabe ist ein Bündel von .md‑Dokumenten

2. Erstes Chunking

  • chunk_docs.py ausführen
  • Chunking basierend auf Überschriften
  • Große Blöcke werden mit max_chars und overlap neu aufgeteilt
  • Das erste Ergebnis ist docs_chunks.jsonl

3. Godot‑spezifische Nachbearbeitung

  • Entfernen von Sphinx‑Überbleibseln
  • Extrahieren von Symbolen
  • Hinzufügen von Klassen‑/Methoden‑/Eigenschafts‑Metadaten
  • Extrahieren von Migrationsregeln

Ergebnis:

docs_chunks.jsonl
api_mapping.jsonl
label_prototypes.jsonl

4. Aufbau einer lokalen Suchinfrastruktur

  • Vector DB: Dokumenteinbettung
  • Keyword Index: Präzise Suche
  • Reranker: Neuordnung der Suchergebnisse
  • API Mapping DB / Label Prototype DB

Wichtiger Hinweis:

Das Label wird vom System bestimmt.

5. GitHub‑Daten sammeln und strukturieren

  • .gd, .tscn, .tres, project.godot, README sammeln
  • Repository‑Baum erstellen
  • Code‑/Szene‑/Einstellungsdateien strukturieren

Ergebnis:

GitHub Structured Data JSONL

6. RAG-Entscheider Ausführen

Der RAG-Entscheider verwendet sowohl das lokale System als auch ein entferntes LLM.

Verantwortung des lokalen Systems:

  • GitHub-Chunk-Eingabe
  • Symbolextraktion
  • Vektor- + Schlüsselwortsuche
  • Neurankierung
  • Labelbestimmung

Verantwortung des entfernten LLM:

  • Erstellung von Korrekturen
  • Erstellung von Erklärungen
  • Erstellung von QA-Beispielen
  • Erstellung von DPO-Kandidaten

Der endgültige JSON wird vom Python-Code zusammengesetzt.

7. Erzeugter Datensatz

version_classification
api_mapping
migration_fix
instruction_sft
dpo_preference
repo_explorer
patch_generation
metadata_verification

Es wurde festgehalten, dass es für das initiale MVP ausreicht, zunächst 10.000 ~ 40.000 Stichproben zu erzeugen.

8. Modelltraining

Erstes Training:

Qwen 3.6 SFT

Ziel:

  • Godot 4 vorrangig behandeln
  • GDScript Grundausgabe
  • Godot 3 API ablehnen

Zweite Lernphase:

DPO

Ziel:

  • Bevorzugung von Godot 4‑Antworten verstärken

Weitere Erweiterungen:

SWE‑Erweiterung

Ziel:

  • repo explorer
  • patch
  • trajectory

Kernprinzipien

  • Erstelle zunächst einen RAG‑Detektor basierend auf der offiziellen Dokumentation.
  • Das Label wird nicht vom LLM, sondern vom System festgelegt.
  • LLM ist nur für die Generierungshilfe verantwortlich.
  • Das endgültige Ziel ist das Qwen 3.6 Godot Codierungsmodell.