2026-07-28 Source Flow Debugger Tatsächlicher Quellcode‑Suchbericht

Ziel

In den bisherigen Aufzeichnungen wurde nur vermerkt, dass das eigentliche Godot‑Projekt in 134 Chunks aufgeteilt und durchsucht wurde und dass die zugehörige Dokumentation in den oberen Ergebnissen enthalten war. Diese Formulierung lässt jedoch offen, was jeder Chunk zurückgegeben hat, ob das zurückgegebene JSONL tatsächlich in SQLite existiert und ob vorhandene, direktere Dokumente in SQLite durch die Rangfolge übergangen wurden.

Dieser Bericht behandelt die folgenden drei Fragen getrennt:

Welche JSONL‑Kandidaten hat der Source Flow Debugger pro Chunk zurückgegeben?
Stimmen die zurückgegebenen Kandidaten exakt mit den verifizierten Original‑JSONL‑Einträgen in der commit‑basierten SQLite‑Datenbank überein?
Befanden sich die direkt nachgewiesenen Einträge in SQLite oben in den Ergebnissen, oder ist eine Rangverbesserung nötig?

Der Qwen‑Endpunkt war nicht verfügbar, daher wurden in diesem Durchlauf nur die Suche und der Abgleich mit SQLite durchgeführt. Die Klassifizierung der Godot‑Versionen durch Qwen sowie die Genehmigungs‑/Ablehnungs‑Ergebnisse der Kandidaten wurden nicht protokolliert, und das bloße Auftauchen eines Suchkandidaten wird nicht als erfolgreicher End‑to‑End‑Test gewertet.

Eingabedaten

Repository:
godotengine/godot-demo-projects
Lizenz: MIT
Commit: cae8dc567a56d3e7936f171bcb85f0ccb9634ad0
Projekt: 2d/hexagonal_map
Eingabedateien: project.godot, map.tscn, tileset.tres,
tileset_edit.tscn, troll.gd, troll.tscn
Anzahl Eingabedateien: 6
Erzeugte Chunks: 134
AST‑Chunks: 3
Direkte Chunks: 131

Die für die Ausführung genutzte SQLite‑Datei ist
outputs/godot-rag-sqlite/godot-rag.sqlite3. Zum Zeitpunkt der Ausführung enthielt sie
docs_chunks 2 265 Einträge, api_mapping 1 133 Einträge, label_prototypes 2 Einträge und 3 399 Embeddings.

Ausführungsstatus

Schritt	Status	Bedeutung dieses Laufs
SQLite FTS5 + Okapi BM25	aktiv	Alle 134 Chunks wurden durchsucht
embedding	inaktiv	Kein API‑Key für Query‑Embedding gesetzt
reranker	inaktiv	Kein Provider‑API‑Key gesetzt
Qwen validator	inaktiv	Qwen‑Endpunkt ist ausgefallen

Daher stellt die nachfolgende Rangliste nicht das Endergebnis des gesamten F‑Strategie‑Workflows dar, sondern das Ergebnis der lexical/BM25‑Phase.

Gesamtergebnis des Abgleichs

Kennzahl	Ergebnis
Chunks	134
Pro Chunk zurückgegebene BM25‑Kandidaten	80
Mit SQLite abgeglichene Rückgaben	10 720
Nach Duplikatenbereinigung	844
Kandidaten, die in SQLite nicht gefunden wurden	0
Kandidaten, deren `provenance` nicht `verified` ist	0
Kandidaten, bei denen `raw_json` von SQLite abweicht	0
Rückgaben aus `docs_chunks`	10 713
Rückgaben aus `api_mapping`	7
Rückgaben aus `label_prototypes`	0

Die Konsistenz der Rückgabedaten war korrekt. Alle 10 720 IDs, die der Source Flow Debugger in seiner Tabelle anzeigte, konnten in SQLite nachgeschlagen werden, ihr provenance war verified und das zurückgegebene raw_json entsprach exakt dem gespeicherten Eintrag.

Dennoch bedeutet das nicht, dass die Suchqualität durchweg optimal war. Da alle 134 Chunks die Obergrenze von 80 Kandidaten füllten, konnten die lexical‑Kandidaten nicht weiter eingegrenzt werden. Außerdem führte der Schutz von Dateianker‑Begriffen dazu, dass in neun Chunks ein Dokument mit niedrigerem BM25‑Score auf Platz 1 aufstieg.

Beispielhafte Chunk‑Ergebnisse

Gut gefundene Fälle

Chunk	Eingabe‑Zusammenfassung	Rückgabe‑Ergebnis	SQLite‑Abgleich
1	Beschreibung des Dateiformats `project.godot`	`Manually editing project.godot` (Platz 1)	gleiche ID und Originaltext
13	`TileMapLayer`, `tile_map_data`, `TileSet`	`TileMapLayer` (Platz 1), Methode (Platz 2), `TileData` (Platz 3)	alle verifizierten `docs_chunks`
42	`TileSetAtlasSource`, Textur‑Region	`TileSetAtlasSource` (Platz 1), `TileSetSource` (Platz 2)	direkter Klassen‑Nachweis
125	`_physics_process`, `Input.get_axis`, `move_and_slide`	`Physics process` (Platz 1), 2D‑Bewegungs‑Dokumente (Platz 5‑7), `CharacterBody2D` (Platz 8)	Bewegungs‑ und Physik‑Dokumente vorhanden
130	`CharacterBody2D`‑Node	`CharacterBody2D`‑Klasse (Platz 1)	direkter Klassen‑Nachweis

Der erste Platz von Chunk 1 wurde nicht allein durch den BM25‑Score erreicht, sondern blieb dank des lexical‑Anchor‑Schutzes für project.godot erhalten. In diesem Fall stimmt die Dateiformats‑Beschreibung exakt, sodass der Schutz gerechtfertigt war.

Fälle, bei denen eine Rangverbesserung erforderlich ist

Chunk 123: `extends CharacterBody2D`

Tatsächlicher Rang 1: Collision exceptions
Dokumentation der Klasse CharacterBody2D: Rang 17
Zuordnung KinematicBody2D -> CharacterBody2D: Rang 6

In SQLite gab es die korrekte Dokumentation der Klasse CharacterBody2D, aber sie wurde nach den umfangreicheren Dokumenten zu Kollision / Bewegung platziert. Es handelt sich nicht um fehlende Daten, sondern um ein Rangproblem. Bei kurzen Deklarations‑Chunks muss ein exakt übereinstimmender Klassenname und Struktur‑Felder stärker gewichtet werden als allgemeine Kontext‑Token.

Chunk 124: `tan(deg_to_rad(30))`

Tatsächlicher Rang 1: Setting up the spring arm and camera
Evaluating expressions: Rang 2 und 3

Im Rang‑1‑Dokument gibt es zwar ein Beispiel für deg_to_rad, sodass es nicht völlig irrelevant ist, aber das Dokument, das den Aufruf selbst erklärt, wurde von einem 3D‑Tutorial überholt. Eine Neuordnung, die reine API‑Beschreibungen von einfachen Anwendungsbeispielen trennt, ist nötig.

Strukturkandidaten, die einer erneuten Qwen‑Validierung bedürfen

Chunk 13: `PackedByteArray` in `map.tscn` enthalten

Die Zuordnung PackedByteArray -> byte[] landete auf Rang 48. Das gespeicherte JSONL beschreibt die Migration von C#‑Kollektionen, während die Eingabe eine GDScript‑Szenen‑Ressource ist. Die Token stimmen überein, aber Sprache und Anwendungskontext unterscheiden sich, sodass sie in der Suchphase nicht final akzeptiert werden dürfen.

Chunk 130: Knoten, der bereits `CharacterBody2D` verwendet

Die Zuordnung KinematicBody2D -> CharacterBody2D erreichte Rang 3. Diese Zuordnung ist für die Versionsbestimmung relevant, aber im aktuellen Chunk fehlt die alte API KinematicBody2D. Sie ist kein Kandidat für eine Migrationswarnung; Qwen muss JSONL und Original‑Chunk gemeinsam betrachten und sie als Godot 4‑Begründung oder als nicht anzuwenden klassifizieren.

Der ursprüngliche SQLite‑JSONL‑Text beider Fälle wurde unverändert im reviewCases‑Abschnitt des maschinellen Leserapports erhalten.

Warum `label_prototypes` 0 Einträge hat

Die Prototypen in SQLite umfassen nur die folgenden beiden Einträge:

enum PlaneSemanticLabel
class OpenXRSpatialComponentPlaneSemanticLabelList

Im Chunk hexagonal_map fehlten beide Eingabemuster. Daher ist das Fehlen von label_prototypes in diesem Durchlauf kein Versäumnis, sondern das Ergebnis eines aktivierten Struktur‑Basis‑Filters.

Aktuelle Schlussfolgerung

Die Datenkonsistenz zwischen den Rückgabe‑Kandidaten und dem SQLite‑Originaltext wurde bestätigt.
Typische Projekteinstellungen, TileSet, TileMapLayer und Bewegungs‑Funktions‑Suchen wurden in die Top‑Ränge der zugehörigen Dokumente aufgenommen.
Nicht alle Chunks erreichen die Obergrenze von 80 Kandidaten, sodass eine weitere Reduktion nicht ausreicht.
Bei kurzen Klassen‑Deklarationen und einzelnen Funktionsaufrufen wird relevante Dokumentation manchmal nach hinten verdrängt.
Da Struktur‑Zuordnungen allein aufgrund passender Token in die Kandidaten gelangen können, kann Qwen im ausgeschalteten Zustand keine endgültige Entscheidung über deren Annahme treffen.

Kriterien für den nächsten Durchlauf

Sobald der Qwen‑Endpunkt wieder verfügbar ist, werden dieselben 134 Chunks mit demselben Commit erneut verarbeitet, um folgende Punkte hinzuzufügen:

Klassifizierung jedes Struktur‑Kandidaten in Godot 3, Godot 4, Keine Relevanz, Begründung fehlt
Entscheidung über die Ablehnung von Kandidaten mit Sprach‑Kontext‑Mismatches wie PackedByteArray -> byte[]
Ablehnung von Migrations‑Kandidaten in Chunks, die bereits die Ziel‑API verwenden
Ablehnung von nicht relevanten Negative‑Control‑JSONL‑Einträgen
Direkte Dokument‑Rang‑Veränderungen vor und nach Anwendung von Embedding und Reranker