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 » à l’échelle d’un projet
    • 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
    • Mots‑clés associés : 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

    • Flux global : données → chatbot RAG de première phase → SFT → DPO → agent SWE
    • Découpage de la phase 0 (préparation) à la phase 6 (amélioration continue) : collecte/structuration des données, chatbot RAG de première phase, étiquetage des données, entraînement du modèle, développement de l’agent SWE, exploitation/re‑entraînement
    • L’idée maîtresse : créer d’abord un chatbot RAG spécialisé dans la documentation Godot, l’utiliser pour étiqueter et transformer les données GitHub, puis étendre vers l’entraînement du modèle et 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
    • Flux : base de données de mappage API, vecteur DB de la documentation officielle, DB de prototypes d’étiquettes → extraction de symboles, recherche, scoring d’étiquettes, assemblage/validation JSONL
    • Les jeux de données cibles sont classés en 8 catégories : classification de version, mappage API, correction de migration, instruction SFT, préférence DPO, explorateur de dépôt, génération de patch, vérification de métadonnées

  • Note séparée sur le flux MVP menant du juge RAG Godot au modèle de codage Qwen 3.6

    • Du document source godot_docs_full.zip à la première segmentation avec chunk_docs.py, en passant par le post‑traitement dédié à Godot et la mise en place d’une infrastructure de recherche locale
    • Combinaison de Vector DB, Keyword Index, Reranker, API Mapping DB et Label Prototype DB pour que le système décide des étiquettes
    • Après structuration des données GitHub, le juge RAG est exécuté ; le LLM ne fournit que du support de génération (code de correction, explications, exemples QA)
    • Le premier SFT Qwen 3.6 se concentre sur le raisonnement Godot 4, la sortie de base GDScript et le refus des API Godot 3, puis évolue vers DPO et extension SWE

  • Résolution du problème de mise à jour du « grass » GitHub en ajustant les paramètres d’auteur/email Git

    • Modification de la configuration globale : yyeongjin <appsky1888@gmail.com>
    • Identification d’un mélange d’emails (localhost, Naver, noreply GitHub) dans les historiques main ; unification sous yyeongjin <appsky1888@gmail.com> et poussée 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