Qwen Validation Debugger stratégie et enregistrement de l'implémentation

Date de rédaction : 30 juin 2026

Objectif

Ce document consigne les raisons de la création de tools/qwen-validation-debugger ainsi que le flux de fonctionnement réel.

Le 28 juin, nous avons créé manuellement des morceaux de code Godot et des fichiers JSONL avec Qwen, puis nous avons directement concaténé prompt + morceau de code + JSONL pour vérifier comment apparaissent les réponses « oui »/« non ». Cette méthode était utile pour se diriger, mais à mesure que le nombre d'éléments augmentait, le coût de copier manuellement, de se souvenir des critères de génération et de comparer les résultats devenait trop élevé.

Ainsi, le 30 juin, nous avons transformé ce processus en un outil web séparé. Le but de cet outil n’est pas la formation finale du modèle, mais de permettre de suivre visuellement la relation entre le code de test généré par Qwen et le JSONL, et de détecter rapidement les jugements erronés « oui »/« non ».

Écran actuel

L’outil s’exécute actuellement à l’adresse http://localhost:8520/.

L’écran est divisé en trois grandes zones.

• Gauche : liste de contrôle de 50 éléments de test Godot
• Centre/haut droit : étiquette AI de l’élément sélectionné et résultat de génération du code Godot
• Bas : slots de création/validation JSONL pour docs_chunks, api_mapping, label_prototypes

Pourquoi un outil séparé était nécessaire

À l’origine, nous avions demandé directement cela au chatbot Qwen.

Crée un fragment de code Godot,  
génère un fichier JSONL correct et un fichier JSONL incorrect conformes au format `docs_chunks/api_mapping/label_prototypes`.  
Ensuite, vérifie que, lorsqu’on concatène le `SOURCE_CODE` avec le JSONL, la réponse « oui / non » est correcte.

Cependant, lors des tests manuels, il s'est avéré qu'il y avait plus d'axes à vérifier que prévu.

S'il s'agit d'une syntaxe commune, il y a 6 slots.

Code commun  
  docs_chunks       description base / autre description de code  
  api_mapping       commun/inutile / conversion non pertinente  
  label_prototypes  commun/inutile / conversion non pertinente

Si c'est une syntaxe de séparation de version, il y a 12 slots.

Godot 3 code  
  docs_chunks       explication base / autre explication de code  
  api_mapping       conversion nécessaire / conversion non pertinente  
  label_prototypes  conversion nécessaire / conversion non pertinente  

Godot 4 code  
  docs_chunks       explication base / autre explication de code  
  api_mapping       déjà appliqué / conversion non pertinente  
  label_prototypes  déjà appliqué / conversion non pertinente

Cette tâche, si elle est réalisée manuellement, consomme plus de temps en copier/coller et en organisation des résultats que le test lui‑même. C’est pourquoi nous avons regroupé les éléments, le code, le JSONL et les résultats de validation sur une seule interface graphique.

Flux complet

flowchart TD
  A["50 éléments de test"] --> B["Sélection d'éléments"]
  B --> C["Étiquetage Qwen"]
  C --> D{"Est-ce une syntaxe commune ?"}
  D -->|"common"| E["Génération de code commun"]
  D -->|"separate"| F["Génération de code Godot 3"]
  D -->|"separate"| G["Génération de code Godot 4"]
  E --> H["6 slots JSONL"]
  F --> I["6 JSONL basés sur Godot 3"]
  G --> J["6 JSONL basés sur Godot 4"]
  I --> K["Vérification du code Godot 3"]
  I --> L["Vérification du code Godot 4"]
  J --> K
  J --> L
  H --> M["Vérification du code commun"]

Outil appelle Qwen en trois rôles différents.

Étape d’étiquetage

En cliquant sur un élément, Qwen détermine d’abord s’il s’agit d’une syntaxe commune ou d’une séparation de version.

Par exemple, _process(delta) est utilisé comme fonction de mise à jour de trame à la fois dans Godot 3 et Godot 4, il peut donc être considéré comme une syntaxe commune.

À l’inverse, Appliquer la vitesse et l’accélération du joueur peut varier selon la version du corps physique et la façon d’appeler move_and_slide(), donc on crée des codes séparés pour Godot 3 et Godot 4.

Conception des slots JSONL

Au départ, les slots étaient simplement divisés en JSONL correct et JSONL incorrect. Cette distinction était trop grossière.

docs_chunks constitue une preuve explicative. Ainsi, si l’explication correspond directement au code, on répond Oui ; si le document décrit un autre comportement du code, on répond Non.

En revanche, api_mapping et label_prototypes ne sont pas de simples explications ; ils justifient la conversion de Godot 3 vers Godot 4. Ainsi, si du code déjà écrit pour Godot 4 possède un api_mapping ou un label_prototypes marqué Oui, cela peut être interprété comme « Vous êtes déjà sous Godot 4, pourquoi demander une migration ? ».

Nous avons donc renommé les slots comme suit.

Grâce à ce critère, le Oui/Non n’est plus une simple évaluation de pertinence, mais une décision adaptée à l’usage de chaque table.

Séparation du code de génération et du code à valider

Le changement le plus important aujourd’hui se trouve à ce point.

Dans la première implémentation, un slot n’était validé que par rapport à son propre code.

JSONL créé avec le code Godot 3  
  -> Vérifié uniquement avec le code Godot 3  

JSONL créé avec le code Godot 4  
  -> Vérifié uniquement avec le code Godot 4

Mais la vérification réellement nécessaire est plus large que cela.

Le JSONL créé avec le code Godot 3 doit également renvoyer 아니오 lorsqu’il est utilisé avec le code Godot 4. Inversement, il faut également vérifier quel résultat apparaît lorsque le JSONL créé avec le code Godot 4 est utilisé avec le code Godot 3. Ainsi, on pourra identifier le problème où les chaînes source/target se mélangent et produisent à tort 예.

Donc, le bouton a été divisé en deux.

Désormais, chaque emplacement de l'élément de séparation de version peut effectuer toutes les vérifications suivantes.

JSONL généré avec le code Godot 3
  -> Vérification du code Godot 3
  -> Vérification du code Godot 4

JSONL généré avec le code Godot 4
  -> Vérification du code Godot 3
  -> Vérification du code Godot 4

Dans l’outil interne, cela est séparé comme suit.

Critères de calcul de la réponse attendue

Le résultat de la validation est toujours reçu par Qwen sous forme de « oui » ou « non ». Cependant, la réponse attendue n’est plus calculée en se basant uniquement sur un seul slot, mais en considérant « table + version de référence du JSONL + version cible de la validation + nature du slot ».

Ce critère sert davantage de critère de débogage à ce stade, afin d’observer où les correspondances de justification de Qwen commencent à vaciller, plutôt que d’être le critère d’évaluation final.

Évolution du prompt de validation

Le prompt de validation inclut désormais deux informations de version.

JSONL_GENERATED_FROM_CODE_VERSION:
godot3

VERIFY_TARGET_CODE_VERSION:
godot4

Ainsi, nous incluons cela pour empêcher Qwen de répondre « oui » simplement parce que le target_api dans le JSONL correspond au code actuel.

Dans api_mapping et label_prototypes, les critères suivants sont importants :

• source_api, source_pattern, input_pattern, before_code, required_when_seen_in_code doivent être présents directement dans le code actuel pour répondre oui.
• Si seul le target_api, after_code ou la forme de la cible recommandée correspondent au code actuel, cela signifie que la transformation a déjà été appliquée, donc non.
• Les indicateurs tels que signature_stable, no_change, common signifient qu'aucune transformation n'est nécessaire, donc non.
• Même si le JSONL de migration est attaché à du code Godot 4 ou à du code de syntaxe commune, s'il n'est pas nécessaire d'effectuer une transformation supplémentaire, la réponse est non.

Enregistrement des tests de 50 éléments

1/50 Initialisation de la fonction _ready() et réglage de la taille du viewport

Le 3 juillet, nous avons d'abord vérifié le premier des 50 éléments de test. Cet élément a été étiqueté comme code commun, et le code de référence était le suivant.

func _ready():
    var vp_size = get_viewport().get_visible_rect().size
    position = Vector2(vp_size.x / 2, vp_size.y / 2)

Au départ, le créneau d’erreur docs_chunks était appelé « JSONL de description sans rapport ». Cependant, lors des tests réels, ce nom s’est avéré inexact. Ce créneau ne sert pas à fabriquer intentionnellement des JSONL étranges ou incorrects, mais à insérer d’autres descriptions de documentation officielle que le Retriever peut récupérer comme candidats de recherche, afin de vérifier si Qwen les filtre lors de la validation finale.

Ainsi, la signification de ce créneau a été reformulée en « JSONL de description d’un autre code ».

Dans ce test, le JSONL problématique décrivait Viewport.get_visible_rect et _ready(), alors que le contenu réel portait sur le safe area, le scaling UI, $Label, $Button.rect_position et d’autres comportements de code. Le SOURCE_CODE lit la taille du viewport et déplace la position du nœud actuel vers le centre de l’écran, donc même si certaines API se recoupent, il ne s’agit pas d’une justification directe.

La réponse attendue était « non », mais Qwen a renvoyé « oui ». La cause était que l’invite de validation interprétait « correspondance exacte avec la chaîne réelle / appel d’API » de façon trop large, acceptant même des descriptions de documents contenant la même API comme justification directe.

Modifications :

• Renommage du créneau d’erreur docs_chunks de « JSONL de description sans rapport » en « JSONL de description d’un autre code ».
• Dans l’invite de génération du JSONL, ce créneau est défini comme « un JSONL de type documentation officielle qui peut partager certaines API / sujets avec les candidats de recherche, mais qui décrit en réalité le comportement d’un autre code ».
• Renforcement de l’invite de validation : le critère « oui » pour docs_chunks ne repose plus uniquement sur une correspondance de chaîne d’API, mais sur la correspondance du but principal du code, de l’objet cible et du résultat final.
• Même si la même API ou la même méthode apparaît, tant que le JSONL décrit un but différent, un objet cible différent ou un résultat différent, il ne constitue qu’un candidat de recherche et doit être indiqué comme « non ».
• Les libellés et les textes d’aperçu du slot dans l’interface frontale ont été ajustés selon les mêmes critères.
• Ajout d’un test dans core.test.js pour vérifier que ces critères restent appliqués dans les invites.

2/50 _process(delta) boucle de mise à jour par frame

Le 3 juillet, le deuxième point a été validé. Ce point a été étiqueté par Qwen comme code commun.

Résumé de l’étiquetage :

syntax_scope: common
label: _process(delta) mise à jour par image
reason: Dans Godot 3 et 4, la signature et le mode d'appel de la fonction _process(delta) sont identiques, et il n'existe aucune différence syntaxique pour écrire une logique par image.

Résultat de la validation : les 6 créneaux correspondent tous à la réponse attendue.

Cet élément est enregistré comme un cas où, dans la grammaire commune, docs_chunks donne oui comme justification, tandis que api_mapping et label_prototypes donnent non en tant que transformation commune/non nécessaire ou sans rapport, et le flux fonctionne correctement.

3/50 Traitement de l’entrée de déplacement du joueur

L’élément 3 a été étiqueté par Qwen avec le code de séparation de version.

Résumé de l’étiquetage :

syntax_scope: separate
label: Gestion de l'entrée de déplacement du joueur
reason: Bien que la vérification des entrées soit similaire, les changements de signature de Input.get_vector() introduits dans Godot 4 et de move_and_slide() de CharacterBody2D obligent à séparer la structure du code.
godot3_focus: Héritage de KinematicBody2D, calcul manuel de velocity.x/y et appel de move_and_slide(up_direction)
godot4_focus: Héritage de CharacterBody2D, simplification du déplacement diagonal avec Input.get_vector() et suppression du paramètre de move_and_slide()

Résultat de la validation :

Incohérences :

Observation du prompt :

Dans la recherche hybride, il est naturel que des candidats JSONL similaires à un fragment de code apparaissent ensemble. Ainsi, le prompt de validation doit juger si le candidat de recherche constitue une justification réelle pour appliquer la transformation au CODE_SOURCE actuel. Les trois incohérences montrent que la question n’était pas suffisamment précise, ce qui a conduit Qwen à interpréter api_mapping et label_prototypes comme une simple correspondance de pertinence plutôt que comme une nécessité de migration.

En particulier, le point 3 a révélé les problèmes suivants :

• Si un nom de fonction comme move_and_slide, qui peut apparaître à la fois dans Godot 3 et Godot 4, est trouvé seul, Qwen peut pencher vers « Oui ».
• Lorsqu’un JSONL basé sur Godot 3 est appliqué à du code Godot 4 déjà modifié, le label_prototypes · conversion nécessaire ne doit pas renvoyer « Oui ».
• De même, un JSONL de conversion non pertinent créé pour Godot 4 ne doit pas renvoyer « Oui » lorsqu’il est appliqué à du code Godot 3 qui ne nécessite pas cette transformation.
• L’essentiel n’est pas la façon dont le JSONL est généré, mais la question de validation : il faut déterminer si le code actuel est avant ou après modification, ou s’il s’agit d’une transformation totalement différente.

Ainsi, les critères du prompt ont été modifiés comme suit :

• Reformuler la question de validation de « Le JSONL est‑il lié au code ? » à « Faut‑il appliquer une migration au CODE_SOURCE actuel en se basant sur ce JSONL ? ».
• Si le CODE_SOURCE actuel est déjà sous forme cible Godot 4, même si le JSONL semble lié à une explication de migration, il faut répondre « Non » (« déjà appliqué »).
• Le label_prototypes · conversion nécessaire ne doit répondre « Oui » que lorsque le CODE_SOURCE actuel reflète réellement l’ancien mode d’utilisation, la composition des arguments et le schéma d’appel.
• Un JSONL de conversion non pertinent doit répondre « Non » même lorsqu’il cible du code Godot 3, s’il ne constitue pas une transformation applicable au CODE_SOURCE actuel.
• Chaque champ du JSONL constitue le contexte de jugement. L’étape de validation doit examiner ce contexte pour déterminer si le CODE_SOURCE est dans l’état antérieur ou déjà modifié.
• Comme source_api et target_api peuvent partager le même nom ou que match_terms peut contenir des termes source/target, la simple correspondance d’un nom de fonction ou de termes larges ne suffit pas à répondre « Oui ».
• Même si le nom de fonction correspond, il faut que le modèle d’utilisation antérieur (arguments, valeur de retour, nœud hérité, structure de code environnante) décrit par le JSONL soit présent dans le CODE_SOURCE pour répondre « Oui ».
• Si JSONL_GENERATED_FROM_CODE_VERSION et VERIFY_TARGET_CODE_VERSION diffèrent, il faut d’abord préciser si le CODE_SOURCE actuel correspond au code antérieur du JSONL ou s’il a déjà été modifié.

4/50 Application de la vitesse et de l’accélération du joueur

Le point 4 a également été étiqueté par Qwen comme du code séparé par version.

Résumé de l’étiquetage :

syntax_scope: separate  
label: Application de la vitesse de déplacement et de l'accélération du joueur  
reason: Dans Godot 4, le nœud physique est passé de KinematicBody à CharacterBody, et la signature de move_and_slide() a changé pour un passage d'arguments, ce qui modifie la structure du code.  
godot3_focus: Assignation de la vitesse à la propriété velocity puis appel de move_and_slide(), utilisation de KinematicBody2D/3D  
godot4_focus: Passage de l'argument avec move_and_slide(velocity), utilisation de CharacterBody2D/3D, utilisation de lerp() ou move_toward() pour appliquer l'accélération.

Résultat de la validation :

Incohérence :

Observation du prompt :

L’incohérence n° 4 était moins fréquente que la n° 3, mais la cause est la même. Lorsque les noms de fonctions source et cible dans api_mapping sont identiques ou similaires, Qwen peut juger qu’« ce JSONL décrit le changement de fonction » avec une large pertinence et répondre « Oui ». Cependant, cet outil nécessite une évaluation de la pertinence : il s’agit de déterminer si une migration doit réellement être appliquée au code actuel, et non seulement de juger de la pertinence.

Ainsi, en se basant sur les observations jusqu’à la n° 4, le prompt de validation a été renforcé pour ne pas se limiter à la simple correspondance de noms d’API, mais pour prendre également en compte les critères suivants :

• Le code actuel contient‑il réellement le motif avant‑transformation du JSONL ?
• Même si le nom de fonction est identique, les arguments d’appel et le traitement des valeurs de retour correspondent‑ils au code avant la transformation ?
• Si le code cible est déjà sous la forme post‑transformation, la nécessité de migration est‑elle « Non » ?
• Un JSONL de transformation non pertinent ne doit pas être accepté comme « Oui » uniquement à cause d’une pertinence superficielle.

5/50 Limite de vitesse maximale du joueur

L’élément n° 5 a été étiqueté par Qwen comme un code de séparation de version.

Résumé de l’étiquetage :

syntax_scope: separate
label: Limite de vitesse maximale du joueur
reason: En raison du changement de nom de classe entre KinematicBody2D de Godot 3 et CharacterBody2D de Godot 4, ainsi que des différences de signature de la méthode move_and_slide() et du mode de transmission de la vitesse, un code séparé est nécessaire.
godot3_focus: Héritage de KinematicBody2D, assignation de la vitesse à self.velocity puis appel de move_and_slide(), limitation de vitesse avec limit_length()
godot4_focus: Héritage de CharacterBody2D, assignation de la vitesse à la variable velocity puis transmission explicite via move_and_slide(velocity), application de limit_length()

Flux de code généré :

Résultats de la validation :

Mismatches :

Observations sur le prompt :

Le cas 5 ressemble à une situation réellement possible dans la recherche hybride. Plus tard, lorsqu’on interroge la base de données, on ne récupère pas uniquement un JSONL complètement hors sujet, mais aussi des candidats similaires appartenant à la même API ou à la même catégorie de gestion du déplacement/vitesse. Dans ce cas, le prompt de validation doit porter non pas sur « le candidat de recherche est‑il similaire ? », mais sur « ce JSONL décrit‑il directement le comportement réel du SOURCE_CODE ? ».

Dans ce cas 5, api_mapping et label_prototypes ont fonctionné comme prévu dans les validations pour Godot 3 et Godot 4. En particulier, les JSONL déjà appliqués au code Godot 4 ou de type no_change, pattern_validation ont été correctement rejetés avec « Non », ce qui atténue partiellement les problèmes de jugement de migration observés aux cas 3 et 4.

En revanche, docs_chunks nécessite encore davantage d’examen. docs_chunks ne porte pas sur l’application d’une migration mais sur la correspondance de la justification d’explication ; ainsi, si seuls le nom de l’API ou un indice de version identique entraînent un « Oui », du bruit persiste lors de la validation des candidats de recherche hybride. Par conséquent, les prochains prompts de validation devront vérifier plus rigoureusement que le but du SOURCE_CODE, l’objet cible et l’état résultant correspondent réellement à la description du JSONL.

6~10/50 ajout d’enregistrements de validation

De la 6ᵉ à la 10ᵉ, on enregistre d’abord le résultat, puis on corrige le prompt de validation. À ce stade, on se contente de noter où l’outil donne des réponses correctes ou incorrectes, sans modifier le prompt.

Résumé global :

Résumé par élément :

Les numéros 6, 9 et 10 ont tous donné les résultats attendus. Le numéro 6 montre la séparation entre le flux de Godot 3 (PackedScene.instance(), Input.is_mouse_button_pressed(1), get_viewport().get_mouse_position()) et celui de Godot 4 (instantiate(), InputEventMouseButton, get_global_mouse_position()), avec des candidats correct/incorrect bien distingués. Le numéro 9 a également vu les candidats de version séparés évalués comme attendus. Le numéro 10 a été classé comme syntaxe commune, et le traitement hors‑écran basé sur get_viewport_rect().size, global_position, hide() a été jugé « oui » selon la documentation, tandis que les candidats de migration api_mapping/label_prototypes ont été notés « non ».

Incohérences :

Observations :

Pour les numéros 6‑10, on constate globalement un signal d’amélioration. Sur 102 validations, 97 correspondent aux attentes, et les numéros 6, 9 et 10 sont tous passés. En particulier, le numéro 10 (syntaxe commune) a vu tous les api_mapping et label_prototypes évalués « non », ce qui montre que la règle « ne pas ajouter de justification de migration aux codes communs » fonctionne partiellement.

Les incohérences restantes se divisent en deux catégories. La première concerne les cas comme le numéro 7, où une justification de migration basée sur Godot 3 apparaît également comme « oui » sur du code Godot 4. Il faut alors clarifier si le code actuel est déjà dans sa forme post‑migration ou non. La seconde concerne les cas comme le numéro 8, où des candidats docs_chunks sont marqués « oui » parce qu’ils traitent d’un même sujet ou d’une API similaire. Il faut distinguer si la justification décrit réellement le comportement du code source ou si ce n’est qu’un candidat de recherche similaire.

Il est important de ne pas résoudre ce problème en bloquant des chaînes de caractères ou des candidats spécifiques. Lorsqu’on insère les JSONL dans la base de données et qu’on effectue une recherche hybride, il est normal que des candidats similaires mais différents apparaissent ensemble. Ainsi, les corrections futures doivent viser à rendre le prompt de validation plus précis dans l’évaluation de la relation entre le code source actuel et les candidats de recherche, plutôt que de filtrer artificiellement les candidats.

Renforcement du prompt de validation appliqué après l’enregistrement :

• Dans docs_chunks, lorsqu’il y a une différence de version entre la version de génération du JSONL et la version cible de validation, on vérifie d’abord si le JSONL explique le comportement du code de la version cible.
• Même si les versions diffèrent, un oui est possible lorsqu’on décrit explicitement une API ou un comportement commun, mais pour les candidats qui décrivent la structure ou les différences de nœuds/API entre versions, on vérifie séparément s’ils correspondent au comportement du code source actuel.
• Dans api_mapping et label_prototypes, on détermine d’abord si le code source actuel est du code pré‑migration, post‑migration, non pertinent ou inutile à convertir.
• Le oui n’est autorisé que lorsque le code source actuel est pré‑migration et que le JSONL propose une conversion à appliquer immédiatement.
• Ce renforcement ne consiste pas à traiter des chaînes de caractères spécifiques, mais à renforcer la procédure d’évaluation des candidats issus de la recherche hybride par rapport au code actuel.

Vérification des résultats de validation

Les résultats de validation sont affichés séparément pour chaque slot, par version.

Cette méthode permet de voir immédiatement, à l’intérieur d’un même slot, les informations suivantes.

Godot 3 validation du code avant / réponse / attente / correspondance  
Godot 4 validation du code avant / réponse / attente / correspondance

Précédemment, seules les mentions « Ce JSONL est correct/incorrect » étaient visibles. Désormais, vous pouvez voir « Correct/Incorrect lorsqu’il est appliqué à un certain code ».

Problèmes résolus par l’outil actuel

Évolution de la productivité du développement

Avant de créer l’outil, chaque test nécessitait les actions suivantes effectuées manuellement.

1. Expliquer les éléments de test à Qwen  
2. Demander du code Godot 3  
3. Demander du code Godot 4  
4. Demander le JSONL de réponses correctes/incorrectes pour `docs_chunks`  
5. Demander le JSONL de réponses correctes/incorrectes pour `api_mapping`  
6. Demander le JSONL de réponses correctes/incorrectes pour `label_prototypes`  
7. Vérifier chaque JSONL en le combinant à nouveau avec `SOURCE_CODE`  
8. Noter manuellement les résultats « oui / non »  
9. Comparer mentalement pour voir si la valeur attendue est correcte

Actuellement, le même flux est fixé à l'intérieur de l'écran.

1. Cliquez sur l’élément  
2. Créez une étiquette AI  
3. Générez du code commun ou Godot 3/4  
4. Générez des slots JSONL  
5. Vérifiez le code Godot 3 / Vérifiez le code Godot 4  
6. Vérifiez les résultats ainsi que les invites/réponses

Particulièrement, la partie où la productivité s’est améliorée se rapproche davantage de « ne pas être confus » que de « produire rapidement et en grande quantité ». Dans ce travail, il est plus important que le critère de jugement reste stable que la simple quantité générée. Avec l’apparition de l’outil, les choses suivantes sont devenues plus faciles.

• Fixer d’abord si c’est une grammaire commune ou une séparation de version
• Vérifier en continu l’usage du JSONL par tableau à l’écran
• Séparer les attentes de génération des résultats de validation réels
• Valider de façon croisée le même JSONL dans le code Godot 3/4
• Consulter immédiatement le prompt et la réponse brute des slots échoués
• Réduire l’état que l’humain doit retenir lorsqu’on répète 50 éléments

Problèmes encore ouverts

Cet outil n’est pas encore l’évaluateur final. Il s’agit actuellement d’un outil de débogage.

Les problèmes ouverts sont les suivants :

• L’explication de docs_chunks peut parfois être reconnue comme une description commune même si les versions diffèrent.
• Dans api_mapping, si les chaînes source/target sont toutes deux présentes dans le JSONL, Qwen peut répondre « oui » en ne regardant que la chaîne target.
• Pour label_prototypes, la distinction de motifs avant/après peut être plus importante que la simple correspondance de chaînes.
• Le calcul actuel de la réponse attendue sert de critère de débogage ; il faudra plus tard affiner séparément le calcul du score/F1 réel.
• Le problème de sélection des candidats de recherche et la décision du prompt de validation sont difficiles à séparer immédiatement en ne regardant que le résultat.

Conclusion actuelle

Le 28 juin, l’impression était de « faire les 50 tests à la main ». En le faisant, on a constaté qu’il y avait trop d’axes à tester, et que la combinaison de grammaire commune, de séparation de version, de critère de génération et de version cible de validation entraînait rapidement de la confusion.

En créant l’outil le 30 juin, ce problème a été largement résolu. Désormais, on ne se contente plus de juger le JSONL produit par Qwen comme correct ou incorrect, mais on peut aussi voir dans quel code il a été généré et dans quel code il a été validé.

Cet outil pourra être utilisé de la même manière lorsque les résultats réels de recherche de docs_chunks, api_mapping et label_prototypes seront ajoutés. Autrement dit, il constitue une base qui peut s’étendre non seulement aux données de démonstration manuelles, mais aussi à la validation des résultats de recherche en base de données.