Reorganicé la dirección del modelo de codificación de Godot 4 desde el aprendizaje de Q&A simple a la perspectiva de aprendizaje de trayectoria de SWE‑agent
Determiné que con solo pequeñas instrucciones Q&A es difícil manejar solicitudes a nivel de proyecto como “Crea un mapa”.
Concluí que un agente de codificación real necesita una trayectoria que incluya exploración del repositorio, selección de archivos relevantes, modificación de código, pruebas/validación y generación de parche.
Como casos de referencia, enumeré SWE‑agent trajectories, SWE‑smith, SWE‑Gym, CoderForge‑Preview, ACC, RepoBench/CrossCodeEval/RepoCoder, aiXcoder CoLT, godot‑dodo, wallstoneai dataset.
Documenté todo el roadmap de desarrollo de Godot LLM con imágenes y texto
Organicé el flujo completo en las etapas Datos → Chatbot RAG de 1ª fase → SFT → DPO → SWE Agent.
Dividí desde la fase de preparación Stage 0 hasta la mejora continua Stage 6, registrando recolección/estructuración de datos, chatbot RAG de 1ª fase, etiquetado de datos, entrenamiento del modelo, desarrollo del SWE Agent y operación/re‑entrenamiento.
El punto clave es crear primero un chatbot RAG de 1ª fase como experto en la documentación de Godot, usarlo para etiquetar y procesar datos de GitHub, y luego expandir a entrenamiento del modelo y SWE Agent.
Añadí una nota sobre la estructura de generación de datos basada en el juez RAG de Godot
En lugar de delegar la decisión final de la etiqueta al LLM, la etiqueta y la verificación son determinadas por una tubería del sistema.
El LLM solo asume roles de asistencia generativa, como código corregido, explicaciones, preguntas/respuestas SFT, respuestas negativas DPO y borradores de parche.
Documenté el flujo que parte de la base de datos de mapeo API, la base de datos vectorial de documentación oficial y la base de datos de prototipos de etiquetas, pasando por extracción de símbolos, búsqueda, puntuación de etiquetas y ensamblaje/validación de JSONL.
Clasifiqué los conjuntos de datos objetivo en ocho categorías: clasificación de versiones, mapeo API, corrección de migración, instrucción SFT, preferencia DPO, explorador de repositorios, generación de parches y verificación de metadatos.
Registré en una nota separada el flujo MVP que parte del juez RAG de Godot hacia el modelo de codificación Qwen 3.6
Documenté el proceso desde la preparación del documento original godot_docs_full.zip, el chunking inicial con chunk_docs.py, el post‑procesamiento específico de Godot y la construcción de la infraestructura de búsqueda local.
Combino Vector DB, Keyword Index, Reranker, API Mapping DB y Label Prototype DB para que el sistema decida las etiquetas.
Después de estructurar los datos de GitHub, ejecuto el juez RAG y separo el rol del LLM a asistencia generativa (código corregido, explicaciones, muestras QA, etc.).
En el SFT inicial de Qwen 3.6, el objetivo es priorizar Godot 4, salida básica de GDScript y rechazo de la API de Godot 3; luego se continúa con DPO y expansión a SWE.
Resolví el problema de reflejo del “grass” de GitHub ajustando la configuración de autor/email de Git
Cambié la configuración global de Git a yyeongjin <appsky1888@gmail.com>.
Detecté que los correos de autor/committer en el historial main estaban mezclados entre correo local, correo de Naver y noreply de GitHub.
Uniformé autor/committer del historial main a yyeongjin <appsky1888@gmail.com> y lo empujé al remoto.
Guardé el estado previo a la reescritura en la rama de respaldo local backup/before-author-email-rewrite-2026-06-17.