2026-07-28 Rapport de recherche de source réelle du Flow Debugger

Objectif

Dans les enregistrements précédents, il était indiqué que le projet Godot réel avait été découpé en 134 chunks et que les documents associés figuraient parmi les résultats supérieurs. Cette description ne permettait pas de savoir, pour chaque chunk, ce qui avait été renvoyé, si le JSONL renvoyé existait réellement dans SQLite, ou si un document plus direct présent dans SQLite avait été relégué dans le classement.

Ce rapport sépare les trois questions suivantes :

Quel JSONL candidat le Source Flow Debugger a-t‑il renvoyé pour chaque chunk ?
Le candidat renvoyé correspond‑t‑il exactement au JSONL source vérifié dans le SQLite ?
Les preuves directes trouvées dans tout le SQLite sont‑elles apparues en haut du classement, ou le classement doit‑il être amélioré ?

Le point d’accès Qwen étant interrompu, nous n’avons exécuté que la recherche et la comparaison avec SQLite. La classification des versions Godot de Qwen et les résultats d’acceptation/rejet des candidats n’ont pas été enregistrés, et le simple fait qu’un candidat de recherche soit apparu n’est pas considéré comme une validation finale.

Entrée fixe

Dépôt : godotengine/godot-demo-projects
Licence : MIT
Commit : cae8dc567a56d3e7936f171bcb85f0ccb9634ad0
Projet : 2d/hexagonal_map
Fichiers d’entrée : project.godot, map.tscn, tileset.tres, tileset_edit.tscn, troll.gd, troll.tscn
Nombre de fichiers d’entrée : 6
Nombre de chunks générés : 134
Chunks AST : 3
Chunks directs : 131

Le SQLite utilisé pour l’exécution est outputs/godot-rag-sqlite/godot-rag.sqlite3 et, au moment de l’exécution, il contenait 2 265 enregistrements docs_chunks, 1 133 api_mapping, 2 label_prototypes et 3 399 embeddings.

État d’exécution

Étape	État	Signification de cette exécution
SQLite FTS5 + Okapi BM25	exécuté	Recherche sur les 134 chunks complète
embedding	non exécuté	Clé d’API d’embedding de requête non définie
reranker	non exécuté	Clé d’API du fournisseur non définie
Qwen validator	non exécuté	Point d’accès Qwen interrompu

Ainsi, le classement ci‑dessous n’est pas le classement final de la stratégie F globale, mais le résultat de l’étape lexical/BM25.

Résultats de la comparaison globale

Élément	Résultat
Chunks	134
Candidats BM25 renvoyés par chunk	80
Candidats renvoyés comparés à SQLite	10 720
Candidats après suppression des doublons	844
Candidats introuvables dans SQLite	0
Candidats dont le provenance n’est pas `verified`	0
Candidats dont le `raw_json` diffère de SQLite	0
Retour `docs_chunks`	10 713
Retour `api_mapping`	7
Retour `label_prototypes`	0

La cohérence des données renvoyées était correcte. Lorsque les tables et ID affichés par le Source Flow Debugger ont été re‑interrogés dans SQLite, les 10 720 enregistrements existaient tous, le provenance était verified, et les enregistrements renvoyés correspondaient aux raw_json stockés.

Cependant, cela ne signifie pas que la qualité de la recherche était parfaite. Les 134 chunks ont tous rempli le plafond de 80 candidats, de sorte que les candidats lexicaux n’ont pas été suffisamment restreints. De plus, la protection des ancres de nom de fichier a fait monter en première position des documents avec un score BM25 plus bas dans 9 chunks.

Résultats des chunks représentatifs

Cas bien recherchés

Chunk	Résumé de l’entrée	Résultat renvoyé	Comparaison SQLite
1	Description du format du fichier `project.godot`	`Manually editing project.godot` en 1ᵉʳ rang	ID et texte d’origine identiques
13	`TileMapLayer`, `tile_map_data`, `TileSet`	`TileMapLayer` propriété 1ᵉʳ rang, méthode 2ᵉʳ rang, `TileData` 3ᵉʳ rang	Tous dans `docs_chunks` vérifiés
42	`TileSetAtlasSource`, région de texture	`TileSetAtlasSource` 1ᵉʳ rang, `TileSetSource` 2ᵉʳ rang	Preuve de classe directe confirmée
125	`_physics_process`, `Input.get_axis`, `move_and_slide`	`Physics process` 1ᵉʳ rang, documents de mouvement 2D rangs 5‑7, `CharacterBody2D` 8ᵉ rang	Documents liés au déplacement et à la physique présents
130	Nœud `CharacterBody2D`	Classe `CharacterBody2D` 1ᵉʳ rang	Preuve de classe directe confirmée

Le document classé 1ᵉʳ rang du chunk 1 n’est pas arrivé en tête uniquement grâce au score BM25 ; il a été maintenu grâce à la protection de l’ancre lexicale project.godot. Dans ce cas, la description du format du fichier correspondait exactement, confirmant la validité de la protection.

Cas nécessitant une amélioration du classement

Chunk 123 : `extends CharacterBody2D`

Réel 1ᵉʳ : Collision exceptions
Documentation de la classe CharacterBody2D : 17ᵉ
Mappage KinematicBody2D -> CharacterBody2D : 6ᵉ

SQLite contenait la documentation exacte de la classe CharacterBody2D, mais elle était placée après la documentation large sur les collisions et le déplacement. Ce n’est pas un manque de données, mais un problème de classement. Dans les chunks de déclaration courte, il faut traiter le nom de classe et les champs de structure parfaitement correspondants comme plus pertinents que les tokens de contexte général.

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

Réel 1ᵉʳ : Setting up the spring arm and camera
Evaluating expressions : 2ᵉ et 3ᵉ positions

Même si la documentation de première position comporte un exemple d’utilisation de deg_to_rad, ce n’est pas totalement hors sujet, mais le tutoriel 3D a été classé avant la documentation qui explique l’appel lui‑même. Un ré‑ordonnancement distinguant la description d’API directe des simples exemples d’utilisation est nécessaire.

Structures candidates nécessitant une re‑validation Qwen

Chunk 13 : `PackedByteArray` présent dans `map.tscn`

Le mappage PackedByteArray -> byte[] est arrivé en 48ᵉ position. Le JSONL stocké décrit la migration des collections C#, mais l’entrée est une ressource de scène GDScript. Les tokens correspondent, mais la langue et le contexte d’application diffèrent, il ne faut donc pas approuver ce résultat lors de l’étape de recherche.

Chunk 130 : nœud utilisant déjà `CharacterBody2D`

Le mappage KinematicBody2D -> CharacterBody2D est arrivé en 3ᵉ position. Ce mappage est pertinent pour la détection de version, mais le chunk actuel ne contient pas l’ancienne API KinematicBody2D. Ce n’est pas un candidat d’avertissement de migration, et Qwen doit classer ce cas comme « Godot 4 » ou « non applicable » après avoir comparé le JSONL et le chunk d’origine.

Le texte original du JSONL SQLite pour les deux cas a été conservé tel quel dans le champ reviewCases du rapport de lecture machine.

Pourquoi `label_prototypes` compte 0 entrée

Les prototypes SQLite ne sont que les deux suivants :

enum PlaneSemanticLabel
class OpenXRSpatialComponentPlaneSemanticLabelList

Le chunk hexagonal_map ne contenait aucun de ces deux modèles d’entrée. Ainsi, le fait que label_prototypes soit à 0 n’est pas une omission, mais le résultat d’un filtre structurel direct.

Conclusion actuelle

La cohérence des données entre les candidats retournés et le texte original SQLite a été vérifiée.
Les paramètres de projet représentatifs, TileSet, TileMapLayer et la recherche de fonctions de déplacement ont été placés en haut des résultats.
Tous les chunks n’atteignent pas la limite supérieure de 80 candidats, donc la réduction des candidats n’est pas suffisante.
Dans les déclarations de classe courtes et les appels de fonction uniques, des documents plus directs sont parfois relégués à des positions inférieures.
Le mappage structurel peut faire entrer un candidat uniquement sur la base de tokens pertinents, de sorte que Qwen ne peut pas statuer sur l’approbation tant qu’il est inactif.

Critères pour la prochaine exécution

Lorsque le point d’accès Qwen sera de nouveau disponible, utiliser le même commit et les mêmes 134 chunks pour ajouter les valeurs suivantes :

Classification de chaque candidat structurel en Godot 3, Godot 4, Non pertinent, Preuve insuffisante
Décision de rejet pour les candidats de discordance de contexte linguistique comme PackedByteArray -> byte[]
Rejet des candidats de migration dans les chunks qui utilisent déjà l’API cible
Décision de rejet pour les JSONL de contrôle négatif non pertinents
Variation du classement des documents directs avant/après l’application d’embeddings et de reranker

Stratégie F du 01‑08‑2026 et re‑validation Qwen

Le même commit du dépôt externe et les 6 fichiers originaux de 2d/hexagonal_map ont été ré‑importés dans l’interface Source Flow Debugger GUI. Selon le dernier critère de chunking, 146 chunks ont été générés. L’audit complet de recherche, exécutant successivement BM25, embedding, union et reranker, a abouti à la complétion de tous les 146 chunks, sans enregistrement manquant dans SQLite, aucune provenance non vérifiée, ni JSONL différent du texte original.

Fichier réel	Chunk	Portée de vérification
`project.godot`	20	Recherche hybride complète, validation Qwen complète, re‑validation individuelle des chunks en échec
`map.tscn`	6	Recherche hybride complète et validation Qwen
`tileset.tres`	54	Audit complet de recherche, validation du source atlas et de la ressource finale
`tileset_edit.tscn`	54	Audit complet de recherche, validation du nœud racine et du nœud sprite
`troll.gd`	3	Recherche hybride complète et validation Qwen
`troll.tscn`	9	Recherche hybride complète et validation Qwen

Résultats de la séparation recherche / validation

La déclaration et le nœud CharacterBody2D ont renvoyé la documentation de classe ainsi que le mappage KinematicBody2D -> CharacterBody2D. Qwen a adopté uniquement le mappage correspondant à l’API cible comme preuve de version et l’a classé Godot 4.
PackedScene, Node2D, Sprite2D, TileSetAtlasSource, etc., ont correctement renvoyé leurs documents de classe, mais ceux‑ci ne prouvent pas l’exclusivité de version majeure, ils sont donc restés « Preuve insuffisante ».
Le paramètre run/main_scene a correspondu exactement à la documentation Setting the main scene et au texte SQLite. Il a d’abord été rejeté parce que la description en langage naturel ne répétait pas littéralement la notation du paramètre, mais la règle de validation a été ajustée pour accepter les clés structurées dont la valeur et le rôle sont explicitement décrits dans la documentation.
doc_version ou godot_version_tags ne sont que des métadonnées de collecte de documentation ; ils ne prouvent pas automatiquement l’exclusivité de version du code. La règle a été modifiée pour ne confirmer la version que lorsque le corps du JSONL explique directement la différence de version majeure.

Vacuité de données révélée par la comparaison totale SQLite

Les expressions suivantes ont été recherchées dans les candidats supérieurs de l’interface GUI, sans aucun enregistrement correspondant dans les docs_chunks, api_mapping ou label_prototypes de SQLite :

en‑tête de ressource de scène
déclaration de ressource de script externe
paramètre de version du format de projet
paramètre d’avertissement de déclaration non typée
paramètre d’aspect d’étirement de fenêtre
paramètre de couleur de nettoyage par défaut

Ces cas montrent que le JSONL correct existe dans SQLite, mais la recherche ne l’a pas trouvé parce qu’aucune preuve directe n’est présente dans le JSONL collecté. Ainsi, le validateur n’a pas remplacé un résultat « Non pertinent » par « Godot 3 » ou « Godot 4 » de façon arbitraire.

Les modifications des règles de validation ont été réparties dans les commits d504f50 et 2222634, et les 33 tests du Source Flow Debugger ont tous été réussis. Aucun code spécifique, nom d’API ou clé de configuration n’a été ajouté manuellement à la liste des règles.