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
- 1ᵉ rang réel :
Collision exceptions - Documentation de la classe
CharacterBody2D: 17ᵉ rang - Mappage
KinematicBody2D -> CharacterBody2D: 6ᵉ rang
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 courts, il faut traiter le nom de classe et les champs de structure parfaitement correspondants comme plus importants que les tokens de contexte général.
Chunk 124 : tan(deg_to_rad(30))
- 1ᵉ rang réel :
Setting up the spring arm and camera Evaluating expressions: 2ᵉ et 3ᵉ rang
Même si la documentation de rang 1 contient un exemple d’utilisation de deg_to_rad, ce n’est pas totalement hors sujet, mais le tutoriel 3D a été placé avant la documentation qui explique l’appel lui‑même. Un ré‑ordonnancement distinguant les explications d’API 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é au 48ᵉ rang. Le JSONL de stockage décrit la migration de 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 à l’étape de recherche.
Chunk 130 : nœud utilisant déjà CharacterBody2D
Le mappage KinematicBody2D -> CharacterBody2D est arrivé au 3ᵉ rang. 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 cela comme « Godot 4 » ou « non applicable » après avoir examiné 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 est à 0 ?
Les prototypes SQLite ne comprennent que les deux entrées suivantes :
enum PlaneSemanticLabelclass OpenXRSpatialComponentPlaneSemanticLabelList
Le chunk hexagonal_map ne contenait aucun de ces deux modèles d’entrée. Ainsi, le fait que label_prototypes soit à 0 lors de cette exécution n’est pas une omission, mais le résultat d’un filtre de structure directe qui a fonctionné.
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é inclus en haut du classement.
- 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 rangs inférieurs.
- Le mappage de structure peut entrer comme candidat uniquement sur la base de tokens associés, de sorte que Qwen, lorsqu’il est désactivé, ne peut pas statuer sur l’approbation.
Critères pour la prochaine exécution
Lorsque le point d’accès Qwen sera de nouveau disponible, le même commit et les mêmes 134 chunks seront utilisés pour ajouter les informations suivantes :
- Classification de chaque candidat de structure 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 rang des documents directs avant et après l’application de l’embedding et du reranker