30 juin 2026

Saison de la Coupe du monde, je n’ai pas pu bien dormir à cause du visionnage et je n’ai pas pu faire beaucoup de travail

La conversion Markdown → JSONL de localhost:8501 est actuellement confirmée jusqu’à environ 655 éléments

Aujourd’hui, je me suis concentré sur la création et le raffinement d’un outil de débogage de tests de validation plutôt que sur une grande collecte/formation

J’ai élaboré une stratégie pour l’outil de débogage de tests de validation et implémenté l’outil web séparé Qwen Validation Debugger

• Le chemin d’exécution est tools/qwen-validation-debugger
• La commande d’exécution locale est npm run validation-debug:debug
• L’adresse de base est http://127.0.0.1:8520/

Le 28 juin, j’ai créé manuellement des morceaux de code Godot et des JSONL avec le chatbot Qwen, puis effectué une validation « Oui / Non » à la main

• Cette méthode a permis de vérifier la faisabilité, mais à mesure que le nombre d’éléments augmente, les copier‑coller et les comparaisons de résultats deviennent excessifs
• En particulier, il faut tester les trois tables docs_chunks, api_mapping, label_prototypes ; si c’est une syntaxe commune, 6 slots sont nécessaires, et si les versions sont séparées, 12 slots sont requis, rendant la gestion manuelle très complexe

L’outil charge 50 éléments de test Godot en échantillon et demande à Qwen d’étiqueter d’abord chaque élément comme syntaxe commune ou séparée entre Godot 3/4

• Si c’est une syntaxe commune, un code commun est généré
• S’il y a une différence de version, le code Godot 3 et le code Godot 4 sont générés séparément
• Ensuite, les slots JSONL sont automatiquement constitués pour chaque table

J’ai confirmé à nouveau qu’on ne peut pas simplement regrouper docs_chunks, api_mapping, label_prototypes sous le même « Oui/Non »

• docs_chunks constitue la justification de la description du code, donc si le code correspond directement, c’est « Oui »
• api_mapping et label_prototypes sont des justifications de source de migration ; souvent, le code déjà appliqué à Godot 4 ou la syntaxe commune correspond à « Non »
• Ainsi, les noms de slots sont divisés en Justification de description, Description non pertinente, Conversion nécessaire, Déjà appliqué, Commun/Inutile, Conversion non pertinente

En développant l’outil, la plus grande modification a été la séparation du code de génération JSONL et du code cible de validation.

Au départ, les JSONL créés avec le code Godot 3 étaient validés uniquement avec le code Godot 3, et ceux créés avec le code Godot 4 étaient validés uniquement avec le code Godot 4.

• Cependant, il faut vérifier que le JSONL basé sur Godot 3 donne bien « non » lorsqu’il est utilisé avec le code Godot 4.
• Ainsi, chaque slot possède désormais des boutons séparés « Validation du code Godot 3 » et « Validation du code Godot 4 », et les résultats sont enregistrés séparément.

Après avoir créé l’outil, la productivité du développement a considérablement changé

• Auparavant, il fallait demander à Qwen le code et le JSONL à chaque fois, les coller dans le prompt pour les valider, puis comparer mentalement la réponse attendue.
• Maintenant, la sélection d’éléments, l’étiquetage, la génération de code, la génération de JSONL, la validation croisée Godot 3/4 et la visualisation du prompt/réponse brute se font sur un même écran.
• Au lieu de simplement produire rapidement en grande quantité, le plus important est de ne plus se perdre sur les critères de génération et les validations effectuées.
• En répétant 50 cas de test, l’état à retenir pour l’utilisateur diminue, ce qui permet de repérer les schémas d’échec plus rapidement.

Grâce à cet outil, on peut voir directement à l’écran quel prompt est envoyé, dans quel ordre les créations/validations de JSONL sont appelées, et comment le prompt de validation ainsi que le prompt de requête sont construits.

• La réponse attendue est fixée selon l’étiquetage et la nature du slot, afin que le critère « oui / non » ne prête pas à confusion.
• Les résultats s’affichent immédiatement par slot, ce qui permet d’identifier très rapidement la combinaison code/JSONL qui a échoué.
• Même si un échec provient du prompt, le prompt utilisé reste visible à l’écran, facilitant ainsi les corrections ultérieures.

L’outil étant désormais fonctionnel, nous prévoyons de ralentir le rythme, de privilégier l’affinement progressif des critères de validation plutôt que d’augmenter la quantité de façon précipitée.

Document de suivi : Qwen Validation Debugger stratégie et registre d'implémentation

Rétrospective : docs/retrospectives/2026-06-30.md