idea_world_labDEV JOURNAL
mercredi 17 juin 2026

17 juin 2026

  • Réorganisation de la direction du modèle de codage Godot 4, non plus comme un apprentissage Q&A simple mais sous l’angle de l’apprentissage de trajectoires d’agent SWE

    • On estime qu’une simple instruction Q&A ne suffit pas à gérer des requêtes de type « crée une carte » au niveau d’un projet complet
    • Un véritable agent de codage doit suivre une trajectoire incluant l’exploration du dépôt, la sélection des fichiers pertinents, la modification du code, les tests/validation et la génération de patchs
    • Les mots‑clés associés sont Long-context repository-level software engineering agent training, SWE-agent trajectory training
    • Cas de référence : SWE‑agent trajectories, SWE‑smith, SWE‑Gym, CoderForge‑Preview, ACC, RepoBench/CrossCodeEval/RepoCoder, aiXcoder CoLT, godot‑dodo, wallstoneai dataset

  • Documentation complète de la feuille de route du développement du LLM Godot sous forme d’images et de texte

    • Le flux global est structuré en étapes : données → chatbot RAG de première passe → SFT → DPO → agent SWE
    • De la phase de préparation (Stage 0) à l’amélioration continue (Stage 6), on décrit la collecte/structuration des données, le chatbot RAG initial, l’étiquetage, l’entraînement du modèle, le développement de l’agent SWE et les cycles d’opération/re‑entraînement
    • L’idée maîtresse est de créer d’abord un chatbot RAG spécialisé dans la documentation Godot, puis d’utiliser ce chatbot pour étiqueter et transformer les données GitHub avant de former le modèle et d’étendre vers l’agent SWE

  • Ajout d’une note sur la structure de génération de données basée sur le juge RAG Godot

    • Au lieu de confier la décision finale d’étiquette au LLM, le pipeline système détermine les étiquettes et la validation
    • Le LLM ne joue qu’un rôle d’assistance à la génération : code modifié, explications, questions/réponses SFT, réponses négatives DPO, brouillon de patch, etc.
    • Le flux repose sur une base de données de mappage API, une base vectorielle de la documentation officielle et une base de prototypes d’étiquettes, permettant extraction de symboles, recherche, scoring d’étiquettes, assemblage/validation JSONL
    • Les jeux de données cibles sont classés en huit catégories : classification de version, mappage API, correction de migration, instruction SFT, préférence DPO, exploration de dépôt, génération de patch, vérification de métadonnées

  • Note séparée sur le développement MVP reliant le juge RAG Godot au modèle de codage Qwen 3.6

    • Du pré‑traitement du document source godot_docs_full.zip à la première segmentation via chunk_docs.py, en passant par le post‑traitement spécifique à Godot et la mise en place d’une infrastructure de recherche locale, le flux est détaillé
    • En combinant Vector DB, Keyword Index, Reranker, API Mapping DB et Label Prototype DB, le système décide des étiquettes
    • Après structuration des données GitHub, le juge RAG est exécuté et le LLM ne se charge que de la génération d’assistance (code/modif, explications, exemples QA)
    • Le premier SFT avec Qwen 3.6 vise à privilégier Godot 4, produire du GDScript de base et refuser les API Godot 3, avant de passer à DPO et à l’extension SWE

  • Résolution du problème de mise à jour du « grass » GitHub : réglage du author/email Git

    • Modification de la configuration globale : yyeongjin <appsky1888@gmail.com>
    • Identification d’un mélange d’adresses (localhost, Naver, noreply GitHub) dans les commits de la branche main
    • Uniformisation des auteurs/committeurs de main à yyeongjin <appsky1888@gmail.com> et propagation vers le remote
    • L’état avant réécriture est sauvegardé dans la branche locale backup/before-author-email-rewrite-2026-06-17

  • Documents de référence