2026-07-03 Rétrospective

Ce que j'ai fait aujourd'hui

Aujourd'hui, j'ai simplement laissé un flux YouTube 24 h en marche tout en lançant la collecte, j'ai testé la traduction, et j'ai poursuivi la validation en cliquant sur l'outil de validation créé le 30 juin.

Du côté du convertisseur Markdown → JSONL, le nombre d'éléments collectés à partir de la documentation officielle est passé de 737 à 850. Aujourd'hui encore, plutôt que de pousser une grande implémentation, j'ai continué la collecte tant que RunPod était allumé et, entre‑temps, j'ai vérifié petit à petit les flux de validation et de traduction.

Pour la traduction, j'expérimente un pipeline utilisant l'API de modèle gratuit de NVIDIA. Grâce aux secrets du workflow GitHub, nous avons vu un certain succès et nous avons même pu observer la génération de README en japonais et en chinois. Ce n'est pas encore le moment d'affirmer que c'est pleinement intégré, mais plus la documentation augmente, plus le besoin d'un flux de traduction automatique se fait sentir.

La satisfaction d'avoir créé l'outil de validation

Ce que j'ai le plus ressenti aujourd'hui, c'est à quel point il était judicieux d'avoir créé l'outil de validation le 30 juin. Sans cet outil, les choses auraient pu mal tourner.

Avec l'ancienne méthode, il fallait demander à Qwen de créer séparément le code et le JSONL, puis les coller dans le prompt et comparer mentalement la réponse attendue. Maintenant, on clique sur un élément, on génère le code et le JSONL, on lance la validation pour le code Godot 3 et le code Godot 4, et on peut voir le prompt brut et la réponse brute sur le même écran. Le travail manuel reste présent, mais on ne manque plus ce qui est incorrect.

Aujourd'hui, j'ai vérifié les 10 premiers éléments sur les 50 tests. Au cours de ce processus, des cas où le LLM a mal répondu ont réellement été découverts.

• Au test 1, le candidat docs_chunks a été accepté (« Oui ») parce qu'il contenait le même indice _ready() ou un indice lié au viewport, même si le texte décrivait en réalité un code différent.
• Aux tests 3, 4 et 7, le JSONL de migration basé sur Godot 3 avait été collé à du code au format Godot 4, mais le système a quand même renvoyé « Oui ».
• Au test 8, le candidat docs_chunks a été jugé « Oui » parce qu'il traitait le même sujet de suivi/déplacement ou une API similaire, bien que le comportement réel du CODE_SOURCE diffère.
• Les tests 6, 9 et 10 ont tous été validés comme prévu, ce qui montre que la direction d'amélioration n'est pas complètement erronée.

Ces problèmes ne proviennent pas d'un JSONL défectueux, mais plutôt de la façon dont Qwen utilise (ou ignore) un candidat similaire lorsqu'il apparaît dans une recherche hybride. Il ne s'agit donc pas de bloquer certains tokens, mais d'affiner le prompt de validation afin qu'il évalue plus précisément la relation entre le code actuel et le candidat JSONL.

Réflexions

Aujourd'hui n'a pas été une journée de mise en œuvre spectaculaire. J'ai lancé la collecte automatique, cliqué manuellement sur les validations, et examiné les JSONL ainsi que les résultats de validation, ce qui a fait passer le temps plus lentement que prévu. Néanmoins, je suis satisfait d'avoir accompli quelque chose.

La validation prend plus de temps qu'on ne le pense. Même si cela ressemble à la lecture d'un seul code et d'un seul JSONL, les natures de docs_chunks, api_mapping et label_prototypes diffèrent, tout comme le code basé sur Godot 3 et celui basé sur Godot 4. Faire cela pour seulement 10 cas génère déjà de nombreux scénarios.

Cependant, en identifiant à l'avance les points d'erreur comme aujourd'hui, on pourra réduire les incidents qui surviennent lors des recherches en base de données réelles et du flux de validation du récupérateur. À l'avenir, je souhaite continuer à capturer les problèmes détectables dès les tests.

Si je devais améliorer, je pourrais envisager d'utiliser également les API gratuites en plus de RunPod. Si l'API de modèle gratuit de NVIDIA ou d'autres points de terminaison gratuits pouvaient être intégrés de manière fiable aux tâches de traduction, de validation auxiliaire et de synchronisation de documentation, la dépendance à RunPod pourrait être légèrement réduite.