2026-06-12 Reflexión

Decidí volver a escribir una reflexión

Dejo una reflexión después de mucho tiempo. La razón por la que no había registrado nada no fue solo por estar ocupado, sino porque quería dejar solo un texto perfecto. Quería registrar solo después de que los resultados estuvieran claramente organizados, y sentía que era innecesario dejar registros de procesos fallidos o de cambios de dirección a mitad del camino.

Sin embargo, al mirar atrás, ese proceso fue lo más significativo. En los últimos 10 días no hubo muchos resultados terminados, pero investigué mucho sobre cómo crear un modelo de codificación especializado en Godot, descubrí dónde me quedé atascado y qué decisiones cambié, lo cual se acumuló bastante. Así que hoy decidí organizar el flujo de lo que he hecho hasta ahora.

Experimento con modelo local

Al principio quería evitar el costo de RunPod y probar a cargar un modelo de la familia Qwen en mi PC local. Como estoy usando una RTX 3060, pensé que tal vez podría ejecutar un modelo de alrededor de 9 B en WSL.

Pero en la práctica no resultó como esperaba. Hubo problemas graves de velocidad de conexión de red y latencia, y antes de recibir una sola respuesta ya pasaban más de 5  minutos en la fase de razonamiento. En esas condiciones, la velocidad del experimento era demasiado lenta y resultaba difícil usarlo como herramienta de desarrollo, así que descarté inmediatamente la ejecución del modelo local.

Lo que quedó claro de este experimento es que, en mi entorno, es más importante diseñar primero la estructura del conjunto de datos y la canalización de entrenamiento que intentar ejecutar un modelo grande localmente.

Investigación del conjunto de datos de Godot

Para entrenar un modelo necesitaba datos. Entonces busqué un conjunto de datos que pudiera usar para aprender código de Godot 4 y encontré wallstoneai/godot-gdscript-dataset en Hugging Face.

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

Al principio pensé que era simplemente un conjunto de muchos archivos .gd, pero al analizarlo con Gemini descubrí que la estructura era lo crucial. La clave no era extraer archivos individualmente del repositorio de GitHub, sino desplegar todo el repositorio para conservar el contexto del proyecto.

Este conjunto de datos parece combinar el README.md, los archivos .gd y la estructura de directorios del repositorio en un solo texto, incluyendo el nombre del proyecto, la versión de Godot, el árbol de archivos y el contenido de cada archivo en formato markdown. De esa forma el modelo no solo ve fragmentos de código aislados, sino también la arquitectura del proyecto y las relaciones entre archivos.

Una parte especialmente importante fue la forma de distinguir entre versiones Godot 3 y Godot 4. Godot no tiene una estructura como package.json o requirements.txt típica de proyectos web. En su lugar hay que leer valores dentro del archivo project.godot, como config_version o config/features, o usar diferencias en la sintaxis de GDScript.

Por ejemplo, en Godot 3 se usan expresiones como onready var o KinematicBody, mientras que en Godot 4 aparecen @onready y CharacterBody3D. Detectar esas diferencias con expresiones regulares o un parser permite filtrar versiones incluso sin un archivo de versión basado en JSON, lo que brinda una visión útil para lenguajes menos comunes.

El conjunto de datos no era suficiente

Luego vi un video en YouTube sobre afinación de un lenguaje de programación clásico llamado OPL.

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

Pero el video no me dio una comprensión completa. El proceso de recopilar el conjunto de datos y el de afinación deben estar conectados, y la pregunta “Si solo tengo el conjunto de datos, ¿qué y cómo entrenaré?” seguía ahí.

Así que le pregunté a mi coach de SSAFY cómo recolectar datos de un lenguaje menos común en una versión específica de la manera más eficaz. Obtuvé una respuesta clave.

Primero, el conjunto de datos que estaba consultando es más un conjunto de datos de código bruto que un conjunto de datos para entrenamiento de asistentes. Si quiero un chatbot, simplemente alimentar código crudo no es suficiente.

Segundo, a partir del conjunto de datos bruto debo generar pares de pregunta/respuesta para el LLM. Esa respuesta aclaró lo que debo hacer: no basta con reunir solo código de Godot 4, sino que debo crear datos de preguntas y respuestas para formar un conjunto de datos de instrucciones.

Sin este paso, una solicitud como “Diseña un mapa” podría ser respondida por el modelo en Python en lugar de Godot, ya que los modelos existentes han entrenado mucho más con datos de Python. Si los datos de respuesta no son claros, también hay riesgo de que se mezclen códigos de versiones antiguas de Godot o de otros lenguajes.

Reflexiones sobre el conjunto de datos de instrucciones y el prompting

Como candidato para el conjunto de datos de instrucciones revisé Magicoder-Evol-Instruct-110K.

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

Pero la mayor parte estaba escrita centrada en Python. Usarlo tal cual no parece adecuado para crear un modelo exclusivo de Godot 4.

En ese momento surgió la duda: “¿Es necesario mencionar explícitamente Godot?” Si se alimenta mucho datos de Godot, tal vez el modelo responda con código de Godot sin que el usuario lo indique.

Esta cuestión se aclaró al consultar a un senior de la universidad. Hoy en día, a veces es mejor diseñar bien la estructura de prompting o de búsqueda basada en documentos que depender únicamente de RAG, y crear documentos markdown indexados vectorialmente para que el modelo pueda localizar la información necesaria.

En conclusión, en la etapa actual es más probable obtener respuestas precisas si se da un contexto claro, como “Crea un mapa con Godot”, en lugar de simplemente “Crea un mapa”. Dado que los pesos del modelo están fuertemente inclinados hacia Python, es necesario reforzar la condición “Godot” al inicio del prompt.

Rediseño de la arquitectura

Al principio pensé en una arquitectura simple.

Recopilación de datos → Creación del conjunto de datos de preguntas/respuestas → Entrenamiento del modelo

¡Pero pronto sentí que esta estructura era demasiado peligrosa! Si recopilo datos sin conocer suficientemente qué cambió de Godot 3 a 4, podría introducir código incorrecto como datos de respuesta. Incluso al crear un conjunto de datos de preguntas/respuestas, podrían mezclarse código Python y código de Godot 3.

Así que pensé en una estructura que tome la documentación oficial como punto de referencia. La idea es rastrear la documentación de migración de Godot 3 a 4 y la documentación oficial de Godot 4 para crear un chatbot RAG, colocar ese chatbot en el frente y hacer que determine si el código recopilado es de Godot 3 o 4, si usa una API antigua y si es adecuado para código de Godot 4.

El diagrama adjunto es el borrador del pipeline que organicé en ese momento.

El flujo general es el siguiente.

• Crawler la documentación oficial de Godot y la documentación de migración para crear una base de conocimiento RAG.
• Recopila los proyectos de Godot en GitHub por unidad de repositorio.
• Fusiona el README, la estructura de archivos y el código GDScript en un solo contexto.
• project.godot archivo de configuración y diferencias de sintaxis de GDScript para realizar un filtrado de primera versión.
• Utiliza un chatbot RAG para determinar adicionalmente si es Godot 3/4 y si se usa una API de versión anterior.
• Crea un conjunto de datos de instrucción/respuesta solo con los datos refinados para Godot 4.
• Entrena el modelo de codificación de Godot 4 con datos SFT y DPO/Preference.

Dirección SFT y DPO

Posteriormente, al preguntar más a través de ChatGPT, obtuve direcciones inesperadas. Solo pensé en “un modelo que genera código de Godot 4”, pero pude dividir la tarea de entrenamiento de manera más específica.

En SFT se pueden crear las siguientes tareas:

• Clasificación de código Godot 3/4
• Conversión de código Godot 3 a código Godot 4
• Generación de código Godot 4
• Corrección de errores de Godot 4
• Rechazo o corrección de la API de Godot 3

En DPO/Preferencia se pueden definir claramente respuestas malas y buenas. Por ejemplo, se considera una respuesta mala cuando contiene sintaxis de Godot 3 mezclada, y una respuesta buena cuando está escrita con código puro de Godot 4.

Con esta perspectiva, surgió la idea de que no se trata solo de “reunir muchos datos”, sino de decidir primero “qué consideraremos una buena respuesta”.

Crawl de la documentación oficial de Godot

Para probar esta dirección en la práctica busqué una herramienta de rastreo y utilicé crawl4ai.

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

Se rastreó y documentó cerca de 1 500 páginas, incluyendo la documentación oficial de Godot 4, la guía de migración de Godot 3 → 4, la referencia de clases de Godot 4 y los tutoriales de Godot 4.

Al principio pensé que quizás había rastreado demasiado, pero comparado con el tamaño total del contexto del modelo, representa aproximadamente un 3 % del total. No es necesario cargar todo en el modelo de una vez; si se usa en una arquitectura RAG o de búsqueda documental, la cantidad es manejable.

Canal de datos y preocupaciones de I/O

Al rediseñar la arquitectura, también surgieron dudas sobre el I/O del disco y el momento del entrenamiento. Si la recopilación de datos, el preprocesamiento, el postprocesamiento, el almacenamiento, la reindexación y el entrenamiento están todos conectados, inevitablemente se producirá un cuello de botella.

En esta parte también consulté a un senior de la escuela. La respuesta que obtuve fue que, en lugar de ejecutar afinación fina en tiempo real, es mejor procesar rápidamente la adquisición y el procesamiento de datos y realizar el entrenamiento de forma batch.

Por ejemplo, se trata de ejecutar aprendizaje por refuerzo o afinación fina solo cuando el conjunto de datos supera cierto umbral. Al procesar cuando se supera el umbral, como en una ranura de replicación, se puede reducir el cuello de botella de I/O, y la parte donde la inmediatez es crucial se enfocó más en la adquisición y el procesamiento de datos que en el entrenamiento.

El costo de la reindexación es estructuralmente difícil de eliminar por completo. Por lo tanto, en lugar de intentar eliminar este costo, concluí que es más realista establecer criterios sobre cuándo reindexar y cuándo entrenar.

Resumen del día

Al repasar el flujo de los últimos 10 días, al principio comenzó vagamente con “Necesito crear un modelo de codificación para Godot”. Pero ahora ya tengo una estructura un poco más concreta.

Los datos del conjunto de código bruto no son suficientes. Se necesita código refinado basado en Godot 4, una estructura de verificación basada en la documentación oficial, datos de instrucción/respuesta, tareas SFT y criterios DPO/Preferencia.

Además, con mi nivel técnico actual, crear un modelo de codificación desde cero sin un modelo grande como Qwen es prácticamente imposible. Al comparar las habilidades de codificación de un modelo local inicial con las de ChatGPT, también sentí que no se puede ignorar la diferencia en el tamaño del modelo y la cantidad de pre‑entrenamiento.

Sin embargo, la dirección ahora es mucho más clara. Podemos intentar crear una base de conocimientos basada en la documentación oficial de Godot 4, filtrar los datos recopilados y establecer criterios para respuestas buenas y malas, convirtiéndolos en datos de entrenamiento.

Reflexión

Al escribir esta reflexión, lo que más me llamó la atención es que debemos bajar el umbral para registrar. Si solo intentamos registrar resultados perfectos, los procesos realmente importantes desaparecen. Los experimentos fallidos, los juicios ambiguos y las arquitecturas cambiadas a mitad de camino son los materiales que generan decisiones futuras; si no los dejamos, más adelante no sabremos por qué hicimos esas elecciones.

En adelante, en lugar de intentar subir solo resultados terminados, intentaré registrar el proceso con más frecuencia. Creo que es mejor registrar tanto los fracasos como las dudas, en lugar de posponer la reflexión porque el pensamiento de haber fallado se adelanta.

Quiero aprovechar este día como una oportunidad para volver a registrar reflexiones de manera constante. No tiene que ser un texto perfecto, ni siquiera tiene que ser un proceso completo. Lo importante es dejar constancia de lo que intenté, lo que aprendí y bajo qué criterios actuaré la próxima vez.