2026-06-27 Rückblick

Heute scheint das Ziel gewesen zu sein, die Konsistenz des am 26. erstellten Dokuments zum source-to-AST Eingabefluss zu verbessern.

Bis gestern war die gesamte Schicht im Kopf unterschieden, aber in Dokumenten oder Code blieb sie zu abstrakt. Begriffe wie AST, Retriever, LLM‑Validierung, JSONL‑Begründung konnten unterschieden werden, aber es war nicht konkretisiert, welche Datei in welcher Reihenfolge entfaltet wird, welcher Text in den AST‑Parser gelangt und welcher Chunk unverändert an den Retriever übergeben wird, wenn ein echtes Projekt kommt.

Im Kopf dachte ich, ich verstehe es, aber das Unbehagen war stark, dass der Code, wenn ich jetzt damit anfange, nicht in die gewünschte Richtung gehen würde. Deshalb wollte ich heute zuerst die Gesamtstruktur neu erfassen und diese Struktur in einer GUI‑Form entwerfen, die Menschen mit den Augen prüfen können.

Warum die Konkretisierung nötig war

Die Rollen von AST und Retriever waren tatsächlich unterschieden.

.gd‑Dateien gehen in den AST‑Parser und müssen nach Funktionen oder Deklarationen geschnitten werden. Der Retriever muss die daraus resultierenden Code‑Stücke nehmen und in der DB nach zugehörigen JSONL‑Begründungen suchen. Und die LLM‑Validierung muss anhand von Prompt, aktuellem Chunk und gefundenem JSONL beurteilen, ob die Begründung tatsächlich relevant ist.

Aber wenn man das nur verbal zusammenfasst, bleibt es vage. Besonders im tatsächlichen Projektablauf wird die Datei zuerst in der Form # <relativer Pfad> entfaltet, darunter wird der Text dateibasiert aufgeteilt, ein bestimmter Funktions‑ oder Deklarations‑Chunk einer .gd‑Datei wird zum Chunk, und nur das chunkText dieses Chunks darf an den Retriever übergeben werden.

Ich wollte diesen Ablauf klar sehen. Welcher Text einer Datei wurde zu welchem Chunk, ist die Eingabe des Retrievers exakt dieser Chunk, vermischen sich Dateipfade, Zeilennummern oder Prompt nicht mit den Such‑Inputs – das alles wollte ich direkt im Web‑Interface prüfen.

Deshalb dachte ich, es sei nicht nur ein Dokument, sondern ein Werkzeug nötig, das dem Nutzer eine leicht verständliche GUI zur Überprüfung bietet.

Source Flow Debugger

Letztlich wurde durch das Erstellen des Source Flow Debugger der AST‑ und Retriever‑Fluss auf einem Bildschirm sichtbar.

Zunächst wollte ich nur klären, wie Quellcode an den AST‑Teil übergeben wird, doch dabei landeten AST‑Chunk, Direct‑Chunk, Retriever‑Eingabe, DB‑Such‑Button und Qwen‑Validierungs‑Preview auf einem Bildschirm. So entstand eine integrierte Struktur von AST, Retriever und LLM‑Validierung, die komfortabler ist als erwartet.

Der clevere Punkt war, dass ich das nicht von Anfang an als fertiges System bauen wollte, sondern als Beobachtungs‑Tool. In dieser Phase ging es nicht um ein „automatisches Antwort‑Tool“, sondern um ein Werkzeug, das prüft, ob Daten dem beabsichtigten Fluss folgen.

Heute wurde Folgendes bestätigt:

• Godot‑Projekt wird in der Form # <relativer Pfad> entfaltet.
• .gd‑Dateien werden in AST‑artige Chunks aufgeteilt.
• Text‑Ressourcen wie .godot, .tscn werden in Direct‑Chunks aufgeteilt.
• Dokumentdateien wie README.md werden im source‑analysis‑Modus ausgeschlossen und der Grund wird im UI angezeigt.
• Der Retriever‑Eingabe werden nur chunkText ohne Dateipfad, Zeilennummer oder Prompt übergeben.
• Unter jedem Chunk können docs_chunks, api_mapping, label_prototypes tabellarisch durchsucht werden.
• Anschließend wird die Qwen‑Validierung mit der Struktur prompt + chunkText + retrieved JSONL durchgeführt.

Bei einem kleinen Godot‑Projekt ergab die Aufteilung 5 files, 14 chunks, AST 9, Direct 5. Damit scheint der Chunk‑basierte Zerlegungs‑Fluss weitgehend zu funktionieren.

GPT‑Demo‑Test

Ursprünglich wollte ich anhand eines gesammelten JSONL‑Sets ein passendes GitHub‑Repository finden, dieses klonen und testen.

Doch ich erkannte, dass es nicht zwingend nötig ist, von Anfang an ein echtes GitHub‑Repo zu suchen. Was ich prüfen wollte, war: „Entscheidet das LLM korrekt, ob das gefundene JSONL wirklich mit dem aktuellen Godot‑Code‑Chunk zusammenhängt?“ Deshalb erschien es schneller, dem GPT Demo‑Chunks von Godot sowie zugehörige und nicht‑zugehörige JSONL zu geben und zuerst zu testen.

Daher erstellte ich bewusst einen Godot 3‑Code‑Chunk, passende Godot 3 → 4‑Konvertierungs‑JSONL und völlig irrelevante JSONL, um sie gemeinsam zu testen.

Zuerst fragte ich einfach:

Enthält diese JSONL den entsprechenden Quellcode?  
Antwort nur Ja / Nein.

Dann erschien das zugehörige JSONL ebenfalls mit 예, und das nicht verwandte JSONL ebenfalls mit 예.

Am Anfang könnte das enttäuschend wirken, aber ich dachte, es sei eher ein Glücksfall. Wäre dieses Problem in diesem Stadium nicht aufgetaucht, könnte das LLM später, wenn die eigentliche Datenbanksuche hinzugefügt wird, irrelevante JSONL‑Einträge mit seinem eigenen Wissen plausibel anhängen.

Deshalb habe ich die Eingabeaufforderung stärker geändert.

Du bist ein JSONL‑Beweis‑Matching‑Entscheider.

Bestimme für den untenstehenden **SOURCE_CODE**, ob das nachfolgende JSONL eine direkte Transformations‑Begründung enthält.

Entscheidungskriterien:
- Einer der Werte **source_api**, **source_pattern**, **match_terms**, **required_when_seen_in_code** oder **before_code** im JSONL muss exakt mit einem tatsächlichen String oder API‑Aufruf im **SOURCE_CODE** übereinstimmen, damit die Antwort „Ja“ lautet.
- Das bloße Auftreten allgemeiner Begriffe wie *Godot*, *Godot3*, *Godot4*, *migration*, *2D*, *physics* gilt nicht als relevant.
- Negative Formulierungen im JSONL wie „does not describe“, „not related“, „unrelated“, „does not apply“ werden nicht als Beweis anerkannt.
- Handelt das JSONL von einer anderen API, einem anderen Node oder einem anderen System, lautet die Antwort „Nein“.
- Verwende ausschließlich die im JSONL angegebenen Zeichenketten als Beweis und greife nicht auf dein eigenes Godot‑Wissen zurück.
- Die Antwort muss ausschließlich **„Ja“** oder **„Nein“** sein.

So ändern wir es: Zugehörige JSONL sind 예, nicht zugehörige JSONL sind 아니오 getrennt.

Heute ist das in diesem Experiment gewonnene Kriterium wichtig. Nachdem der Retriever JSONL‑Kandidaten abgerufen hat, darf man den LLM nicht nur nach einer breiten semantischen Ähnlichkeit prüfen lassen. Stattdessen muss zuerst geprüft werden, ob Felder wie source_api, source_pattern, match_terms, required_when_seen_in_code, before_code in der JSONL direkt mit dem tatsächlichen String/API‑Aufruf des aktuellen Chunks übereinstimmen.

Aufgaben für morgen

Morgen sollten wir weitere Demo‑Sets erstellen.

Es ist nötig, mehrere zu Godot‑Chunks zugehörige JSONL und nicht zugehörige JSONL zu erzeugen und zu testen, wie Qwen die Antworten ableitet. Ein‑ oder zweimaliger Erfolg reicht noch nicht aus, um das Kriterium sofort festzulegen.

Besonders folgende Fälle müssen noch genauer geprüft werden.

• Wenn mehrere verschiedene JSONL‑Dateien gemischt sind, wählt Qwen die tatsächlichen Belege korrekt aus?
• Werden irrelevante JSONL‑Einträge, die nur thematisch ähnlich sind, von Qwen korrekt mit „Nein“ verworfen?
• Unterscheidet Qwen anhand von Zeichenketten‑Belegen den Unterschied zwischen api_mapping und label_prototypes?
• Können JSONL‑Dateien im Stil von docs_chunks, die erklärende Dokumentation enthalten, auf dieselbe Weise verifiziert werden?
• Führt Qwen bei scheinbarem Godot‑3‑Code, dem jedoch keine JSONL‑Belege zugrunde liegen, keine willkürliche Migration durch?

Heute war ein Tag, an dem ich die abstrakte Struktur vollständig in die tatsächliche Benutzeroberfläche und den Eingabefluss überführt habe. Was ich im Kopf bereits zu kennen glaubte, wurde durch das Aufklappen, Zerlegen und Suchen im Web deutlich klarer.

Der nächste Schritt besteht nun darin, die tatsächliche Datenbanksuche und die Qwen‑Validierung mehrfach zu wiederholen, um sicherzustellen, dass dieser Ablauf nicht ins Wanken gerät.