2026-06-18 Godot RAG Arbeits‑Reset Rückblick

Aktueller Stand

Gestern habe ich im Café etwa einen Liter Kaffee getrunken, und heute geht es mir besonders schlecht. Deshalb konnte ich nicht richtig programmieren. Trotzdem notiere ich jetzt, was mir eingefallen ist, und warum ich die gestrige Arbeit dokumentiert habe.

Fehlende Teile in der aktuellen Architektur

In der aktuellen Godot LLM/RAG‑Architektur fehlen folgende Punkte. Diese müssen später verbessert werden.

Die statische Analyseebene ist schwach  
Keine GDScript AST/Parser-basierte Validierung  
Der Abhängigkeitsgraph des Godot-Projekts ist schwach  
Ausführungs‑/Syntaxprüfung ist schwach  
Die Label‑Taxonomie ist noch grob  
Die Unterscheidung der Herkunft von LLM‑Generaten und verifizierten Antworten ist schwach  
Das Design zur Vermeidung von Datenlecks/Deduplizierung ist schwach

Besonders gibt es Teile, die man nicht allein mit RAG lösen kann. Die Bestimmung von Godot‑Code ist nicht nur ein Problem der Dokumentensuche, sondern erfordert auch das tatsächliche GDScript‑Syntax, die Abhängigkeiten von Szenen/Resourcen, die Projektstruktur und die Unterschiede zwischen Godot 3 und 4 API. Gestern jedoch verlief der Ablauf so, dass man die offizielle Dokumentation chunkte, das Ergebnis erneut an ein LLM übergab und dort Feedback erhielt. Dieses Vorgehen wirkte nach außen hin schnell, aber in Wirklichkeit schwankte die Validierungsgrundlage ständig.

Grund für die Zusammenfassung der Arbeit vom 17. Juni

Am 17. Juni ließ man das LLM das Chunking übernehmen und das Ergebnis wieder an GPT senden, um Feedback zu bekommen. Trotzdem schien mir dieses Vorgehen nicht richtig zu sein.

Der Grund, die offizielle Dokumentation zu crawlen, war, die gesamte Godot‑Dokumentation als Grundlage zu nutzen. Während der Arbeit jedoch entschied das LLM, bevor es die Dokumente gründlich analysiert hatte, dass bestimmte APIs wie „MVP‑Kern“ besonders wichtig seien, und begann, Schlüsselwörter hart zu kodieren oder den Kontext übermäßig zu verstärken. Dadurch wurde aus einem auf der gesamten offiziellen Dokumentation basierenden RAG‑System ein Suchwerkzeug, das nur auf ein paar Schlüsselwörter ausgerichtet war.

Das Problem war nicht nur, dass das Ergebnis mir nicht gefiel. Ohne meine eigene Überprüfung ließ das LLM eigenständig Kriterien festlegen, Dateien nach diesen Kriterien erzeugen und dann das Ergebnis erneut bewerten, um weitere Entscheidungen zu treffen. So entstanden Halluzinationen, weil die ursprüngliche Dokumentenstruktur nicht mehr berücksichtigt wurde, und schließlich wusste das LLM selbst nicht mehr, nach welchen Kriterien welche Datei erstellt worden war.

Betrachtet man das größer, zeigte sich, dass ChatGPT bzw. Codex den Umfang eigenmächtig einschränkten oder änderten, ohne dass ich das so angeordnet hatte. Ich wollte die gesamte offizielle Dokumentation als Basis sehen, nicht „ein paar MVP‑Kern‑APIs“ auswählen und hart kodieren. Trotzdem entschied das LLM zwischendurch selbst, dass „dies das MVP‑Kern ist“, und produzierte bereits ein weiteres Ergebnis, obwohl der Schritt noch nicht abgeschlossen war.

Das problematische Muster lässt sich wie folgt zusammenfassen.

Der Benutzer wünscht eine Analyse der gesamten offiziellen Dokumentenstruktur  
→ Das LLM legt eigenständig den MVP‑Umfang fest  
→ Einige APIs werden als Kernkomponenten betrachtet  
→ Zuerst werden Hard‑Coding, Verstärkungen und Katalogerstellung durchgeführt  
→ Vor der Validierung werden die nächsten Arbeitsergebnisse erstellt  
→ Das Ergebnis wird in plausibel wirkende Zahlen verpackt  
→ In Wirklichkeit sind die Originalstruktur und die Kennzeichnungsgrundlage kontaminiert

Das ist nicht nur ein einfacher Implementierungsfehler, sondern ein Problem der Arbeitsweise. ChatGPT oder Codex neigten dazu, bereits anzunehmen, dass eine Antwort existiert, obwohl sie noch nicht ausgegeben wurde, und zum nächsten Schritt überzugehen, bevor der aktuelle Schritt abgeschlossen war. Es wirkte, als würden sie Anweisungen befolgen, doch in Wirklichkeit interpretierten sie den Anweisungsumfang neu, ignorierten ihn völlig oder versuchten zuerst, eine „gut aussehende fertige Form“ zu erzeugen.

Bei dieser Aufgabe war besonders gefährlich, dass das LLM die Vertrauenswürdigkeit seiner eigenen Zwischenergebnisse nicht korrekt einordnen konnte. Fakten aus der offiziellen Dokumentation, zufällig durch Regex gefundene Wörter, vom Nutzer direkt genehmigte Regeln und vom LLM vermutete Ergänzungsinformationen wurden vermischt. Als man das LLM dann erneut die Ergebnisse bewerten ließ, entstand ein Kreislauf, in dem das LLM das von ihm selbst Erstellte plausibel zu rechtfertigen versuchte.

Warum das Chunking‑Ergebnis gelöscht wurde

Heute habe ich die gestern erstellten Dateien zum RAG‑Chunking aufgeräumt.

Die bereinigten Objekte gehören zu folgender Reihe:

v1 docs_chunks.jsonl
v2 docs_chunks_v2.jsonl
v3/v3.1 catalog/index/mapping Ergebnis
Chunking/Nachbearbeitung/Verifizierungs-Entwurfsskript
Initialer RAG-Chat/Index-Entwurf

Zunächst dachte ich, das Problem liege nur bei v3/v3.1, aber bei genauerem Hinsehen stellte sich heraus, dass auch v1 und v2 von Grund auf neu betrachtet werden müssen. Eigentlich hätte man bereits die einzelnen Chunks analysieren müssen. Zum Beispiel, wie die Godot‑Klassenreferenz tatsächlich strukturiert ist, wie Methoden‑/Property‑Einheiten im Originaldokument dargestellt werden und wie das Sphinx‑Konvertierungsergebnis dabei zerbricht.

In der Praxis jedoch kam die Erzeugung der Chunk‑Ergebnisse der Analyse des Originaldokuments vor. Das Ergebnis war, dass v1 eher an einer Zeichen‑basierenden Fragmentierung orientiert war und v2 darauf eine Nachbearbeitung aufsetzte. Sichtbar wurden Zahlen wie die Chunk‑Anzahl, erfolgreiches JSONL‑Parsing und die Verteilung von doc_type, doch die entscheidende Frage „Kann dieser Chunk als Grundlage für die Unterscheidung von Godot 3/4 verwendet werden?“ war nicht ausreichend geprüft.

Insbesondere musste man prüfen, ob Strukturen wie CharacterBody2D.move_and_slide in der Klassenreferenz stabil erhalten bleiben, ob Properties wie velocity korrekt getrennt werden und wie man aus Migrationsdokumenten die alte/neue Beziehung extrahiert. Ohne diese Überprüfung würden Bezeichnungen wie trusted_api_symbols, syntax_symbols, api_mapping nur scheinbar plausible, aber verfälschte Daten erzeugen.

Deshalb habe ich heute die Chunk‑Ausgaben bis einschließlich v1/v2 geleert. Das bedeutet nicht, dass die Arbeit aufgegeben wurde, sondern dass eine fehlerhafte Basis nicht länger als Basis bezeichnet wird.

Fazit des Tages

Das Fazit des Tages ist einfach.

Das Chunking muss von vorne beginnen.  
Davor muss die ursprüngliche Dokumentenstruktur von `outputs/godot_docs_full/pages` analysiert werden.  
Zwischenresultate, die vom LLM erstellt wurden, dürfen nicht ohne Überprüfung als Grundlage für den nächsten Schritt verwendet werden.

Ich habe es nicht einmal überprüft, aber wenn das LLM nach eigenem Ermessen entscheidet und dabei den Originaltext nicht richtig betrachtet und sogar Halluzinationen einmischt, endet es schließlich darin, dass das LLM nicht weiß, was es getan hat. In diesem Zustand führt das fortwährende Erstellen von Dateien nur zu einer Zunahme von Debug‑Dateien, und man verliert den Überblick darüber, was die Grundlage ist.

Von nun an vertraue ich nicht darauf, dass ChatGPT oder Codex „von selbst in die richtige Richtung“ erweitern und implementieren. Besonders bei Aufgaben, bei denen Kriterien entscheidend sind, wie Datensätze, Annotatoren oder RAG‑Detektoren, ist das folgende Prinzip erforderlich.

Wenn das LLM willkürlich den MVP‑Umfang festlegt, abbrechen  
Wenn nicht vom Benutzer genehmigtes Hardcoding eingefügt wird, abbrechen  
Wenn Ergebnisse ohne Analyse der Originalstruktur erstellt werden, abbrechen  
Wenn ohne Validierungsbericht zum nächsten Schritt übergegangen wird, abbrechen  
Wenn die Herkunft von LLM‑Generaten und verifizierten Antworten vermischt wird, abbrechen

Wenn du es morgen noch einmal machst, ist die erste Aufgabe nicht die Erstellung eines neuen Katalogs. Zuerst muss godot_docs_full selbst analysiert werden. Das heißt, du musst prüfen, welche Struktur die offiziellen Dokumentations‑Markdown‑Dateien in outputs/godot_docs_full/pages tatsächlich haben, und basierend auf dieser Struktur überlegen, welche Einheiten du zu Chunks zusammenfassen willst.

Die jetzt relevante Frage ist nicht „Welche API sollten wir zuerst einbinden?“, sondern kommt eher in die Richtung:

Wie ist das Muster des Klassennachschlagewerks im Verzeichnis **godot_docs_full** aufgebaut?  
Sind die Listen von Methoden/Eigenschaften/Signalen/Konstanten im Original‑Markdown zuverlässig trennbar?  
In welcher Form liegen die Tabellen/Listen/Satzstrukturen des Migrationsdokuments vor?  
Darf man bei Tutorial‑Dokumenten nicht dieselben Chunk‑Kriterien wie beim Klassennachschlagewerk verwenden?  
Muss die Chunk‑Granularität je nach Dokumenttyp unterschiedlich festgelegt werden?  
Welches Element – Seiten‑, Abschnitts‑ oder API‑Member‑Ebene – sollte als Standard‑Chunk dienen?  
Welchen Validierungs‑Report muss man vor dem Chunk‑Vorgang zuerst definieren?

Letztendlich besteht die nächste Aufgabe nicht darin, „RAG neu zu erstellen“, sondern darin, godot_docs_full zu analysieren und zunächst das Chunk‑Design an die offizielle Godot‑Dokumentation anzupassen. Erst danach sollte das Chunking erneut durchgeführt werden.