2026-06-27 Rétrospective | idea_world

Aujourd'hui, il semble que j'avais pour objectif d'améliorer la cohérence du flux d'entrée source-to-AST que j'avais rédigé le 26.

Jusqu'à hier, l'ensemble des couches était séparé dans ma tête, mais dans les documents et le code, cela restait à un niveau trop abstrait. Les termes comme AST, Retriever, validation LLM, preuve JSONL pouvaient être distingués, mais lorsqu'un projet réel arrivait, il n'était pas précisé quels fichiers s'étendaient dans quel ordre, quel texte était envoyé au parseur AST, quel chunk était transmis tel quel au Retriever, etc.

Je pensais comprendre cela mentalement, mais j'avais une forte appréhension que, si je commençais à coder dans cet état, l'implémentation ne suivrait pas la direction souhaitée. J'ai donc d'abord restructuré l'ensemble, puis j'ai cherché à concevoir une interface graphique permettant à une personne de vérifier visuellement le tout.

Pourquoi la concrétisation était nécessaire

Les rôles de l'AST et du Retriever étaient en fait distincts.

Les fichiers .gd sont passés au parseur AST et doivent être découpés en fonctions ou déclarations. Le Retriever reçoit les fragments de code résultants et doit rechercher les preuves JSONL correspondantes dans la base de données. La validation LLM doit, à partir du prompt, du chunk actuel et du JSONL recherché, déterminer si cette preuve est réellement pertinente.

Cependant, lorsqu’on ne fait que les décrire verbalement, cela reste flou. Dans le flux d’un projet réel, le fichier est d’abord déployé sous la forme # <chemin relatif>, le texte en dessous est découpé par fichier, une fonction ou déclaration spécifique d’un fichier .gd devient un chunk, et seul le chunkText de ce chunk doit être transmis au Retriever.

Je voulais voir ce flux clairement. Je voulais savoir quel texte d’un fichier était devenu quel chunk, si l’entrée reçue par le Retriever était exactement ce chunk, et si le chemin du fichier, le numéro de ligne ou le prompt ne se mêlaient pas aux critères de recherche, le tout directement dans l’interface web.

J’ai donc conclu qu’il ne suffisait pas d’écrire un document, mais qu’il fallait un outil GUI permettant à l’utilisateur de vérifier cela facilement.

Débogueur de flux source

En créant le Source Flow Debugger, j’ai pu visualiser le flux entre l’AST et le Retriever sur un même écran.

Au départ, je voulais simplement organiser comment transmettre le code source à l’AST, mais j’ai fini par intégrer les chunks AST, les chunks directs, l’entrée du Retriever, le bouton de recherche DB et l’aperçu de validation Qwen sur un seul écran. Ainsi, l’AST, le Retriever et la validation LLM se sont retrouvés dans une structure unifiée, plus pratique que prévu.

Ce qui m’a vraiment aidé, c’est de ne pas essayer de construire un système complet dès le départ, mais de le concevoir comme un outil d’observation. À ce stade, ce dont j’avais besoin n’était pas un “outil qui donne automatiquement la bonne réponse”, mais un outil permettant de vérifier que les données circulent selon le flux que j’ai imaginé.

Ce que j’ai vérifié aujourd’hui :

Le projet Godot est déployé sous la forme # <chemin relatif>.
Les fichiers .gd sont découpés en chunks de type AST.
Les ressources texte comme .godot, .tscn sont découpées en chunks directs.
Les fichiers de documentation comme README.md sont exclus du mode source‑analysis, avec la raison de l’exclusion affichée.
L’entrée du Retriever ne contient que le chunkText, sans le chemin du fichier, le numéro de ligne ou le prompt.
Sous chaque chunk, on peut rechercher dans les tables docs_chunks, api_mapping, label_prototypes.
La validation Qwen se fait ensuite avec la structure prompt + chunkText + JSONL récupéré.

J’ai également confirmé qu’un petit projet Godot se décompose en 5 fichiers, 14 chunks, AST 9, Direct 5. Cela montre que le découpage par chunk fonctionne assez bien.

Test de démonstration GPT

Initialement, je voulais, à partir d’un jeu de JSONL collecté, trouver le dépôt GitHub correspondant, le cloner et le tester.

Puis j’ai réalisé que je n’avais pas besoin de chercher le vrai dépôt GitHub dès le départ. Ce que je voulais vérifier était : « Le LLM juge‑t‑il correctement que le JSONL récupéré est réellement lié au chunk de code Godot actuel ? » Il était donc plus rapide de demander à GPT de générer des chunks Godot de démonstration ainsi que des JSONL pertinents et non pertinents, puis de les tester.

J’ai donc volontairement créé un chunk de code Godot 3, puis généré le JSONL de conversion Godot 3 → Godot 4 correspondant, ainsi qu’un JSONL totalement sans rapport, pour les tester ensemble.

Au début, j’ai simplement demandé ainsi.

Oui

Il en résultait que le JSONL pertinent était également Oui, et le JSONL non pertinent était aussi Oui.

Au début cela peut sembler décevant, mais j'ai plutôt pensé que c'était une bonne chose. Si ce problème n'était pas apparu à ce stade, plus tard, lorsqu'on ajouterait une recherche réelle dans la base de données, le LLM aurait pu concaténer de façon plausible des JSONL incorrects avec ses propres connaissances.

J'ai donc renforcé le prompt.

Vous êtes un évaluateur de correspondance JSONL.

Déterminez si le JSONL ci‑dessous contient une preuve directe de transformation pour le **SOURCE_CODE** suivant.

**Critères d’évaluation**  
- Il faut que l’un des champs du JSONL — `source_api`, `source_pattern`, `match_terms`, `required_when_seen_in_code` ou `before_code` — corresponde exactement à une chaîne de caractères réelle ou à un appel d’API présent dans le **SOURCE_CODE**. Ce n’est alors qu’à ce moment que la réponse est « Oui ».  
- Le simple fait que des mots généraux comme *Godot*, *Godot3*, *Godot4*, *migration*, *2D*, *physics* apparaissent ne constitue pas une preuve de pertinence.  
- Les mentions négatives du type « does not describe », « not related », « unrelated », « does not apply », etc., ne sont pas considérées comme une preuve valable.  
- Si le JSONL fait référence à une API, un nœud ou un système différent, la réponse doit être « Non ».  
- N’utilisez **pas** vos connaissances personnelles sur Godot ; basez‑vous uniquement sur les chaînes de caractères présentes dans le JSONL.  
- La réponse doit être **uniquement** « Oui » ou « Non ».

Ainsi, les JSONL pertinents sont séparés en 예 et les JSONL non pertinents en 아니오.

Le critère obtenu dans cette expérience d’aujourd’hui est important. Lorsque le récupérateur récupère des candidats JSONL et les soumet à la LLM pour validation, il ne faut pas se baser sur une similarité large. Il faut d’abord vérifier que les champs du JSONL tels que source_api, source_pattern, match_terms, required_when_seen_in_code, before_code correspondent réellement à la chaîne/API du chunk actuel.

Tâches à faire demain

Demain, il semble nécessaire de créer davantage d’ensembles de démonstration.

Il faut créer plusieurs JSONL pertinents et non pertinents pour les chunks Godot, et tester à plusieurs reprises comment Qwen génère ses réponses. Un ou deux succès ne suffisent pas encore à établir un critère définitif.

Il faut notamment vérifier les cas suivants :

Lorsque plusieurs JSONL pertinents sont mélangés, Qwen choisit‑il correctement les preuves réelles ?
Lorsque les JSONL non pertinents ne contiennent que des mots‑clés similaires, les rejette‑t‑il correctement avec 아니오 ?
Qwen distingue‑t‑il bien, sur la base des preuves textuelles, la différence entre api_mapping et label_prototypes ?
Les JSONL de type documentation, comme docs_chunks, peuvent‑ils être validés de la même manière ?
Si un code ressemble à du Godot 3 mais qu’il n’y a aucune preuve JSONL, Qwen n’effectue‑t‑il pas de migration arbitraire ?

Aujourd’hui a été une journée où j’ai traduit la structure abstraite en écran réel et flux d’entrée. Même les choses que je pensais déjà connaître mentalement sont devenues beaucoup plus claires en les affichant, les découpant et les recherchant sur le web.

L’étape suivante consiste à répéter plusieurs fois la recherche dans la base de données et la validation par Qwen, afin de vérifier que ce flux reste stable.