2026-06-12 rétrospective

J'ai décidé d'écrire à nouveau une rétrospective

Je laisse une rétrospective après longtemps. La raison pour laquelle je n'ai pas enregistré pendant ce temps n'est pas seulement que j'étais occupé, mais plutôt que j'avais un fort désir de ne laisser que des écrits parfaits. Je voulais n'enregistrer que lorsque les résultats étaient clairement organisés, et je trouvais ambigu de laisser des échecs ou des processus où la direction a changé en cours de route.

Cependant, avec le recul, c'est ce processus qui a été le plus significatif. Au cours des dix derniers jours, il n'y a pas eu beaucoup de résultats finis, mais j'ai beaucoup accumulé sur ce que j'ai recherché pour créer un modèle de codage spécialisé pour Godot, où je me suis bloqué, et quels jugements j'ai modifiés. Ainsi, aujourd'hui, j'ai décidé de résumer le flux de travail jusqu'à présent.

Expérimentation de modèle local

Au début, je voulais économiser les frais d'utilisation de RunPod en essayant de charger un modèle de la série Qwen sur mon PC local. J'utilise un RTX 3060, donc je pensais pouvoir faire tourner un modèle d'environ 9 B d'une manière ou d'une autre sous WSL.

Mais en pratique, cela ne s'est pas déroulé comme prévu. La vitesse de connexion réseau et les problèmes de latence de réponse étaient graves, et il fallait plus de 5 minutes seulement pour atteindre l'étape de raisonnement avant même de recevoir une réponse. Dans cet état, la vitesse d'expérimentation était trop lente et il était difficile d'intégrer cela comme outil de développement, donc j'ai immédiatement abandonné l'exécution du modèle local.

Ce que j'ai tiré de cette expérience était clair : dans mon environnement, il est plus important, pour l'instant, de concevoir d'abord la structure du jeu de données et le pipeline d'entraînement plutôt que d'essayer de faire tourner un gros modèle localement.

Recherche de jeu de données Godot

Pour entraîner le modèle, il fallait d'abord des données. J'ai donc cherché un jeu de données utilisable pour l'apprentissage du code Godot 4 et j'ai trouvé le jeu de données wallstoneai/godot-gdscript-dataset sur Hugging Face.

• https://huggingface.co/datasets/wallstoneai/godot-gdscript-dataset

Au départ, je pensais qu'il s'agissait simplement d'un jeu de données contenant de nombreux fichiers .gd, mais après l'avoir analysé avec Gemini, la structure s'est avérée plus importante. L'essentiel n'était pas d'extraire les fichiers un par un depuis le dépôt GitHub, mais de déployer l'intégralité du dépôt afin de préserver le contexte du projet.

Ce jeu de données semble fusionner le README.md du dépôt, les fichiers .gd, la structure des répertoires en un seul texte, et inclure le nom du projet, la version de Godot, l'arborescence des fichiers et le contenu de chaque fichier sous forme de markdown. Ainsi, le modèle ne voit pas seulement un fragment de code isolé, mais peut également percevoir la structure du projet et les relations entre les fichiers.

Un aspect particulièrement important était la méthode de distinction des versions Godot 3/4. Godot n'a pas une structure typique de projet web avec un package.json ou un requirements.txt. Au lieu de cela, il faut lire des valeurs comme config_version ou config/features dans le fichier project.godot, ou bien exploiter les différences de syntaxe GDScript.

Par exemple, Godot 3 utilise des expressions comme onready var ou KinematicBody, tandis que Godot 4 utilise @onready ou CharacterBody3D. En capturant ces différences syntaxiques avec des expressions régulières ou un parseur, on peut obtenir une certaine capacité de filtrage de version même pour des langages peu courants qui n'ont pas de fichier de version basé sur JSON.

Le jeu de données seul était insuffisant

Ensuite, j'ai regardé une vidéo sur YouTube concernant le fine‑tuning d'un langage de programmation ancien appelé OPL.

• https://www.youtube.com/watch?v=5wGD92ktQL4

Mais même après avoir vu la vidéo, je n'avais pas une vision claire. Le processus de collecte du jeu de données et le processus de fine‑tuning doivent être liés, et la question « Si j'ai seulement le jeu de données, que vais‑je apprendre et comment ? » restait.

J'ai donc demandé à mon coach SSAFY comment collecter les données d'un langage peu courant d'une version spécifique de la manière la plus efficace. J'ai reçu une réponse importante.

La première était que le jeu de données que je consultais était plus proche d'un jeu de données de code brut que d'un jeu de données d'entraînement d'assistant. Si je veux un résultat sous forme de chatbot, simplement injecter le code brut ne suffit pas.

La deuxième était qu'il faut créer des paires question/réponse à partir du jeu de données brut pour le LLM. Après avoir entendu cela, mon objectif est devenu plus clair. Il ne suffit pas de rassembler uniquement du code Godot 4, il faut générer des données de question et des réponses pour créer un jeu de données d'instructions.

Sans ce processus, lorsqu'on demande « Conçois une carte », le modèle pourrait répondre en Python plutôt qu'en Godot. Les modèles existants ont probablement beaucoup plus appris sur les données Python. Si les données de réponse ne sont pas claires, il y a un risque que du code Godot d'anciennes versions ou même d'autres langages se mélangent.

Réflexion sur le jeu de données d'instructions et le prompting

J'ai également examiné le jeu de données d'instructions Magicoder-Evol-Instruct-110K.

• https://huggingface.co/datasets/ise-uiuc/Magicoder-Evol-Instruct-110K

Mais la plupart des exemples étaient centrés sur Python. L'utiliser tel quel ne semblait pas adapté pour créer un modèle dédié à Godot 4.

C'est alors que je me suis demandé « Doit‑on vraiment mentionner explicitement Godot ? ». Si on injecte beaucoup de données Godot, peut‑être que le modèle répondra en code Godot même sans que l'utilisateur le précise.

Cette question a été clarifiée en consultant un senior de mon école. Aujourd'hui, il peut être plus judicieux de concevoir soigneusement le prompting ou une recherche basée sur des documents plutôt que de compter uniquement sur le RAG, et de créer des documents markdown indexés vectoriellement afin que le modèle puisse naviguer vers les données nécessaires.

En fin de compte, à ce stade, il est plus probable d'obtenir une réponse précise en donnant un contexte clair comme « Crée une carte avec Godot » plutôt que simplement « Crée une carte ». Étant donné le poids des poids Python des modèles existants, il est nécessaire de renforcer la condition « Godot » dès le début du prompt.

Redesign de l'architecture

Au départ, j'avais envisagé une architecture simple.

Collecte de jeux de données → création de jeux de données questions/réponses → entraînement du modèle

Cependant, j'ai rapidement senti que cette structure était trop dangereuse. Si je collecte des données sans connaître suffisamment les changements entre Godot 3 et 4, du code incorrect pourrait être intégré comme donnée de référence. Même en créant un jeu de données de questions/réponses, du code Python ou du code Godot 3 pourrait se mêler.

J'ai donc imaginé une structure qui prend d'abord la documentation officielle comme point de référence. En parcourant les documents de migration de Godot 3 vers 4 et la documentation officielle de Godot 4, on crée un chatbot RAG, que l’on place en façade pour déterminer si le code collecté provient de Godot 3 ou 4, s’il utilise une API ancienne, et s’il convient à du code Godot 4.

Le diagramme ci‑joint est le brouillon du pipeline que j’ai organisé à ce moment‑là.

Le flux principal est le suivant :

• Parcourir la documentation officielle de Godot et les documents de migration pour créer une base de connaissances RAG.
• Collecter les projets Godot sur GitHub au niveau des dépôts.
• Fusionner le README, la structure des fichiers et le code GDScript en un seul contexte.
• Effectuer un premier filtrage à l’aide du fichier de configuration project.godot et des différences de syntaxe GDScript.
• Utiliser le chatbot RAG pour déterminer si le code est destiné à Godot 3/4 et s’il utilise une API ancienne.
• Ne retenir que les données nettoyées pour Godot 4 afin de constituer le jeu de données instruction/réponse.
• Entraîner le modèle de codage Godot 4 avec des données SFT et DPO/Preference.

Orientation SFT et DPO

Par la suite, en posant des questions supplémentaires à ChatGPT, j’ai découvert des directions inattendues. Je pensais uniquement à un « modèle qui génère du code Godot 4 », mais il était possible de subdiviser la tâche d’apprentissage de façon plus précise.

Avec le SFT, on peut créer les tâches suivantes :

• Classification du code Godot 3/4
• Conversion du code Godot 3 en code Godot 4
• Génération de code Godot 4
• Correction d’erreurs dans le code Godot 4
• Rejet ou correction des API Godot 3

Avec le DPO/Preference, on peut clairement distinguer les mauvaises réponses des bonnes réponses. Par exemple, on considère comme mauvaise réponse une réponse contenant de la syntaxe Godot 3, et comme bonne réponse une réponse rédigée uniquement en code Godot 4.

Cette perspective m’a fait réaliser qu’il ne s’agit pas simplement de « collecter le plus de données possible », mais de définir d’abord « ce qui constitue une bonne réponse ».

Documentation officielle de Godot

Pour essayer réellement cette approche, nous avons trouvé un outil de crawling et avons utilisé crawl4ai.

• https://github.com/unclecode/crawl4ai
• https://docs.godotengine.org/en/stable/tutorials/migrating/upgrading_to_godot_4.html

Nous avons crawlé et documenté près de 1 500 pages, incluant la documentation officielle de Godot 4, le guide de migration de Godot 3 → 4, la référence des classes de Godot 4 et les tutoriels de Godot 4.

Au départ, je me suis demandé si nous n’avions pas trop crawlé, mais comparé à la taille totale du contexte du modèle, cela ne représente qu’environ 3 % du volume. Ce n’est pas destiné à être chargé entièrement dans le modèle immédiatement ; utilisé dans un système RAG ou de recherche documentaire, cela constitue une quantité tout à fait gérable.

Pipeline de données et préoccupations I/O

En redessinant l'architecture, je me suis également penché sur les I/O disque et le timing de l'entraînement. En effet, lorsque la collecte, le pré‑traitement, le post‑traitement, le stockage, la réindexation et l'entraînement s'enchaînent, un goulot d'étranglement est inévitable.

J'ai également demandé conseil à un senior de l'école. La réponse obtenue était qu'il vaut mieux, plutôt que de lancer un fine‑tuning en temps réel, assurer rapidement la collecte et le traitement des données, puis exécuter l'entraînement de façon batch.

Par exemple, on ne lance l'apprentissage par renforcement ou le fine‑tuning que lorsque le jeu de données a atteint un certain seuil. Comme pour un slot de réplication, traiter les données une fois le seuil dépassé permet de réduire le goulot d'I/O, et les parties où la réactivité est cruciale concernent davantage la collecte et le traitement des données que l'entraînement lui‑même.

Le coût de la réindexation est structurellement difficile à éliminer complètement. Ainsi, plutôt que d'essayer de supprimer ce coût, il est plus réaliste de définir des critères pour savoir quand réindexer et quand entraîner.

Résumé du jour

En résumant le flux des dix derniers jours, cela a commencé de façon vague avec « Je dois créer un modèle de codage Godot ». Mais maintenant, une structure un peu plus concrète a émergé.

Un jeu de données de code brut n’est pas suffisant. Il faut des données de code nettoyées basées sur Godot 4, une structure de filtrage basée sur la documentation officielle, des données d’instruction/réponse, des tâches SFT, ainsi que des critères DPO/Preference.

De plus, avec mon niveau technique actuel, il est réaliste difficile de créer un modèle de codage à partir de zéro sans un grand modèle comme Qwen. En comparant les compétences de codage d’un modèle local initial et de ChatGPT, j’ai aussi ressenti qu’on ne peut pas ignorer la différence de taille du modèle et de quantité d’entraînement préalable.

Cependant, la direction est beaucoup plus claire qu’auparavant. En se basant sur la documentation officielle de Godot 4 pour créer une base de connaissances, filtrer les données collectées, et établir des critères de bonnes et mauvaises réponses afin de les transformer en données d’entraînement, on peut essayer ce flux.

Rétrospective

En écrivant cette rétrospective, ce que j’ai le plus ressenti, c’est qu’il faut abaisser le critère d’enregistrement. Si l’on ne veut consigner que des résultats parfaits, le processus réellement important disparaît. Les expériences qui ont échoué, les jugements ambigus, l’architecture modifiée en cours de route sont les matériaux qui façonnent les décisions futures ; si on ne les laisse pas, on ne pourra plus comprendre plus tard pourquoi ces choix ont été faits.

À l’avenir, plutôt que d’essayer de ne publier que les résultats achevés, je veux consigner le processus lui‑même plus souvent. Au lieu de remettre la rétrospective à plus tard parce que l’on pense avoir échoué, je crois qu’il est préférable d’enregistrer les échecs et les réflexions.

Je veux profiter de ce jour pour recommencer à consigner régulièrement des rétrospectives. Ce n’est pas grave si ce n’est pas un texte parfait, ni même un processus complet. L’important est de laisser une trace de ce que j’ai tenté, de ce que j’ai appris et des critères qui guideront mes actions à l’avenir.