2026-06-17 Godot RAG‑Erkennungs‑basiertes Daten‑Erzeugungs‑Struktur‑Memo

Struktur‑Bild

Kernidee

Der Kern dieser Struktur ist, dass die endgültige Label‑Entscheidung nicht dem LLM überlassen wird. Das LLM übernimmt unterstützende Generierungs‑Aufgaben wie Korrektur‑Code, Erklärungen, SFT‑Fragen/‑Antworten, DPO‑schlechte Antworten, Patch‑Entwürfe, während das eigentliche Label und das Zusammen‑ und Validieren des finalen JSONL von der lokalen System‑Pipeline entschieden wird.

Zusammengefasst lautet das Prinzip wie folgt.

LLM ist ein Generierungsassistent  
Das Label wird vom System bestimmt  
Das endgültige JSONL wird von der Pipeline zusammengebaut/validiert

Gesamtablauf

Dokumentvorbereitung
-> Lokale DB einrichten
-> GitHub-Quelldaten eingeben
-> Symbole extrahieren
-> Regel-/Vektor-/Schlüsselwortsuche
-> Label-Scoring und Entscheidung
-> Unterstützung bei LLM-Erstellung
-> Endgültige JSONL-Erstellung

Diese Struktur ist ein Entwurf, um Godot 3/4‑Klassifizierung, API‑Mapping, Migrations‑Fix, Instruction SFT, DPO‑Präferenz, Repo‑Explorer, Patch‑Generierung und Metadaten‑Verifizierung in einer einzigen Pipeline zu erstellen.

1. Dokumentenvorbereitung

Im Offline‑Schritt werden die offiziellen Godot‑Dokumente gesammelt und bereinigt.

• Offizielle Godot‑Dokumente sammeln
• Unnötige Formulierungen entfernen
• Dokumenttyp klassifizieren
• Strukturbasiertes Parsen
• Dokument‑Chunks erzeugen
• Einbettungen und Index erstellen

Erzeugte Standard‑Ausgabe:

docs_chunks.jsonl

2. Drei zentrale Datenbanken, die aufgebaut werden

API‑Mapping‑Datenbank

Speichert die Änderungsbeziehungen zwischen der Godot‑3‑API und der Godot‑4‑API.

Beispiel:

KinematicBody2D -> CharacterBody2D
yield -> await
export var -> @export
move_and_slide(v) -> move_and_slide()

Gespeicherte Datei:

api_mapping.jsonl

Offizielle Dokumentations-Vektor‑DB

Dokument‑Chunks werden eingebettet, um eine Vektor‑DB für die Begründungssuche zu erstellen.

Verwendungszwecke:

• Suche nach relevanten offiziellen Dokument‑Chunks
• Bereitstellung von Transformationsbegründungen
• Erklärung von API‑Änderungsgründen
• Reduzierung von Halluzinationen

Label‑Prototyp‑DB

Speichert Prototypen für die Ähnlichkeitssuche von Label‑Kandidaten.

Beispiel‑Label:

godot3_code
godot4_code
mixed_code
broken_code

Gespeicherte Datei:

label_prototypes.jsonl

3. Such‑/Label‑Entscheidung

Wenn die aus GitHub gesammelten Rohdaten eintreffen, analysiert das System zunächst den Code und die Dokumentation.

Beispiel‑Eingabe:

repo: owner/repo
file_path: scripts/Player.gd
content: ...
repo_tree: ...

Das System extrahiert Symbole.

(Keine zu übersetzenden Inhalte vorhanden.)

KinematicBody2D
move_and_slide(velocity)
export var
yield

Danach wird die folgende Suche durchgeführt.

• API‑Mapping‑DB abfragen
• Offizielle Dokumentations‑Vektor‑DB durchsuchen
• Label‑Prototyp‑DB durchsuchen

Das endgültige Label wird nicht vom LLM, sondern durch ein System‑Scoring bestimmt.

Beispiel:

label: godot3
confidence: 0.93
bad_apis:
  - KinematicBody2D
  - move_and_slide(v)
  - export var
replacement_apis:
  - CharacterBody2D
  - move_and_slide()
  - @export

4. LLM‑Erzeugungsunterstützung

LLM entscheidet die Labels nicht selbst, sondern unterstützt die Erzeugungsaufgabe, indem es die vom System festgelegten Labels und Begründungen als Eingabe erhält.

Mögliche Erzeugungsaufgaben:

• Erzeugung von Korrekturen im Code
• Erzeugung von Erklärungen/Begründungen
• Erzeugung von SFT‑Fragen/‑Antworten
• Erzeugung von schlechten DPO‑Antworten
• Erzeugung von Dateibrowser‑Lösungen
• Unterstützung bei der Patch‑Erstellung
• Validierung/Analyse von Problemen

Wesentliche Punkte sind folgende.

Das Ergebnis der LLM-Erstellung ist ein Entwurf.  
Label, endgültiges Schema, confidence, und ob verifiziert wurde, werden vom System verwaltet.

5. Endgültige JSONL-Erstellung

Die Pipeline fügt Systemergebnisse und von LLM erzeugte Ergebnisse zu einem einzigen JSON‑Objekt zusammen.

In der Validierungsphase wird Folgendes überprüft:

• Vorhandensein erforderlicher Felder
• Konsistenz der Labels
• Vorhandensein fehlerhafter API‑Reststücke
• Neuberechnung des confidence‑Werts
• Zusammenhang zwischen Dokumentationsnachweis und Ausgabe

Die 8 erzeugten Datensätze

1. Versionsklassifizierungs‑Daten

Datei:

version_classification.jsonl

Inhalt:

• Godot 3/4/mixed/broken Klassifizierung
• valid_for_godot4 Beurteilung
• bad_apis extrahieren

2. API‑Mapping‑Daten

Datei:

api_mapping.jsonl

Inhalt:

• old_api → new_api Mapping
• change_type, category usw.

3. Transformations‑/Korrekturdaten

Datei:

migration_fix.jsonl

Inhalt:

• before/after Code
• Grund für die Änderung
• Liste der Einstellungen

4. Fragen/Antworten SFT Daten

Datei:

instruction_sft.jsonl

Inhalt:

• instruction/input/output
• Beispiele für verschiedene Muster

5. DPO Präferenzdaten

Datei:

dpo_preference.jsonl

Inhalt:

• chosen
• rejected
• Grund/Bedingung

6. Repo Explorer Daten

Datei:

repo_explorer.jsonl

• Dateien vorhersagen, die zum Lösen von Aufgaben/Fehlern gelesen werden müssen
• Grund, warum sie gelesen werden müssen

7. Patch‑Daten

Datei:

patch_generation.jsonl

Inhalt:

• before/after
• unified diff / patch
• Grund für die Anwendung

8. Meta-/Validierungsinformationen

Datei:

metadata_verification.jsonl

Inhalt:

• Vertrauen
• Punktzahl
• Begründung
• Quellendokument Chunk-ID
• Qualitäts-/Risiko-Informationen

Ausführungszusammenfassung

GitHub Quelldaten
-> Symbolextraktion
-> Regel/DB-Suche
-> Label-Scoring
-> LLM-Erstellungshilfe
-> Endgültige JSON-Zusammenstellung und -Speicherung

Grundprinzipien

• Das Label wird vom System bestimmt.
• LLM übernimmt nur die unterstützende Rolle bei der Generierung.
• Die endgültige JSONL wird von der Pipeline zusammengebaut und verifiziert.
• Belegdokumente, Score, Confidence und Quelleninformationen werden zusammen gespeichert.
• Es muss unbedingt geprüft werden, ob fehlerhafte Godot‑3‑APIs noch vorhanden sind.