J’ai décidé de rédiger à nouveau un rétrospective de développement après une longue pause
Pendant ce temps, le désir de ne laisser que des enregistrements parfaits m’a en fait fait remettre à plus tard la prise de notes
Afin de consigner de manière significative les essais et les réflexions menés au cours des dix derniers jours, j’ai récapitulé le processus de recherche et de conception d’une architecture pour créer un modèle de codage spécialisé pour Godot
Expérience de déploiement d’un modèle de la série Qwen sur le PC local pour réduire les frais d’utilisation de RunPod
J’ai tenté d’exécuter un modèle 9 B sous WSL sur une machine équipée d’un RTX 3060
Mais les problèmes de vitesse de connexion réseau et de latence de réponse étaient importants, et le temps d’attente avant même la génération de la réponse dépassait 5 minutes, ce qui a conduit à l’abandon de l’expérimentation locale
Recherche sur la méthode de collecte de jeux de données pour l’entraînement d’un modèle spécialisé Godot
Analyse, via Gemini, de la façon dont ce jeu de données a été créé
L’idée principale consistait à fusionner, au niveau du dépôt GitHub, le README.md, les fichiers .gd et la structure du projet en un seul texte, puis à classer les versions Godot 3/4 en s’appuyant sur le fichier de configuration project.godot et les différences de syntaxe GDScript
En particulier, en exploitant des indices versionnels tels que config_version, config/features, onready var, @onready, KinematicBody, CharacterBody3D, on a constaté qu’il était possible de filtrer des langages peu courants dépourvus de fichiers de dépendance JSON
Vision d’une vidéo de fine‑tuning portant sur le langage de programmation ancien OPL pour mieux comprendre le flux de fine‑tuning
Cependant, la collecte du jeu de données et la transformation en un format réellement entraînable sont deux problèmes distincts
Question posée à mon coach SSAFY sur la façon de collecter efficacement des données de langages peu courants pour une version précise
La réponse a indiqué que le jeu de données Godot actuellement consulté ressemble davantage à un jeu de données de code brut qu’à un jeu de données Q&A destiné à l’entraînement d’assistants
Pour créer un produit de type chatbot, il vaut mieux générer des paires question/réponse à l’aide d’un LLM et les transformer en jeu de données d’instructions, plutôt que d’utiliser les données brutes telles quelles
Sans cette étape, une requête du type « conçois une carte » risquerait d’obtenir une réponse centrée sur Python, largement apprise par le modèle de base
La majorité du contenu étant orientée Python, il ne convient pas tel quel comme jeu de données d’entraînement exclusif à Godot 4
Bien que je me sois demandé s’il était possible d’obtenir des réponses Godot sans le mentionner explicitement, il a été conclu que, du fait du poids important des poids Python du modèle, il faut préciser le contexte « Godot » dans la question pour augmenter les chances d’obtenir la bonne réponse
Consultation d’un senior de l’université sur les approches RAG et prompting
Au lieu d’injecter toutes les données dans le modèle, il serait plus réaliste de créer une structure de recherche vectorielle basée sur des documents Markdown et de guider le modèle vers les informations nécessaires
Le coût et le temps de ré‑indexation de gros volumes de documents étant élevés, il a été jugé que, à ce stade, une architecture basée sur la recherche et le prompting serait plus adaptée que l’entraînement direct
Conception d’une architecture initiale pour le modèle de codage spécialisé Godot
Au départ, j’imaginais une chaîne simple : collecte du jeu de données → génération du jeu de données Q&A → entraînement du modèle
Mais il est nécessaire de bien connaître les différences entre Godot 3 et Godot 4 pour filtrer correctement et générer des réponses précises, ce qui pose un problème
Un mauvais filtrage pourrait mêler du code Godot 3, du code Python et des API anciennes dans les réponses, d’où la nécessité de repenser l’architecture
Conception d’une structure plaçant un chatbot RAG basé sur la documentation officielle en amont pour la classification et la conversion des versions Godot 3/4
L’idée est de crawler la documentation officielle de migration et la documentation Godot 4, de créer un chatbot RAG, puis d’utiliser ce chatbot pour déterminer si les données collectées proviennent de Godot 3 ou de Godot 4
Ensuite, seules les données identifiées comme Godot 4 seraient transformées en jeu de données d’instructions
Obtention d’insights supplémentaires via ChatGPT sur les orientations d’entraînement SFT/DPO
En SFT, on peut créer des tâches telles que la classification Godot 3/4, la conversion Godot 3 → 4, la génération de code Godot 4, la correction d’erreurs Godot 4, le rejet/correction d’API Godot 3, etc.
En DPO/Preference, on peut constituer des données de préférence où « mauvaise réponse = réponse contenant du code Godot 3 », « bonne réponse = code pur Godot 4 »
Utilisation de unclecode/crawl4ai pour crawler la documentation officielle de Godot
Environ 1 500 pages ont été crawlées et documentées, incluant la documentation officielle Godot 4, les guides de migration Godot 3 → 4, la référence des classes Godot 4 et les tutoriels
Bien que le volume semble important, cela ne représente qu’environ 3 % du contexte total du modèle
Consultation supplémentaire d’un senior sur le goulot d’étranglement I/O du disque dans le pipeline de stockage et d’entraînement
Il est préférable de ne pas lancer le fine‑tuning en temps réel, mais de traiter la collecte, le pré‑ et post‑traitement des données de façon quasi‑temps réel, puis d’effectuer l’entraînement en mode batch
Nous envisagerons un traitement batch déclenché par des métriques, par exemple lorsqu’un certain volume de jeu de données est atteint, on lance le renforcement ou le fine‑tuning
Comme le coût de ré‑indexation ne peut être éliminé complètement, la stabilité du pipeline de collecte et de transformation des données est jugée plus critique que la latence d’entraînement
Direction globale actuelle
Crawler la documentation officielle pour construire une base de connaissances RAG centrée sur Godot 4
Collecter les projets Godot sur GitHub et fusionner, par dépôt, le README, la structure du projet et les fichiers GDScript
Effectuer un premier filtrage à l’aide du fichier project.godot et des différences de syntaxe Godot 3/4
Utiliser le chatbot RAG pour déterminer la version Godot (3/4), la présence d’API anciennes et la pertinence pour Godot 4
Générer des paires instruction/réponse à partir des données filtrées pour Godot 4
Entraîner le modèle de codage Godot 4 avec les données SFT et DPO/Preference
Rétrospective
Au cours des dix derniers jours, le désir de ne laisser que des résultats aboutis m’a empêché de consigner le processus
J’ai réalisé que les expériences ratées, les blocages et les changements de décision intermédiaires constituent les informations les plus précieuses pour orienter les prochaines étapes
Dorénavant, je privilégierai la consignation continue des essais et des décisions plutôt que la recherche d’un résultat parfait