En el autobús que subía a Seúl, volví a organizar mis dudas sobre el conjunto de datos/pipeline RAG de Godot 4.
Antes pensaba en rastrear la documentación oficial de Godot, convertir proyectos de GitHub a formatos md y jsonl, y usar un chatbot RAG para determinar si se trata de Godot 3 o 4.
Sin embargo, me surgió la duda de si realmente se puede colocar todo el contexto del proyecto y los fragmentos de documentación oficial encontrados en una sola entrada al modelo.
Reflexioné sobre los límites del contexto de entrada al crear un chatbot RAG.
Un proyecto de GitHub incluye README, estructura de directorios, varios archivos .gd, archivos de escena y rutas de recursos.
Si a eso se añaden los fragmentos de documentación oficial obtenidos mediante RAG, el tamaño de la entrada crece mucho; por eso, diseñar qué archivos y fragmentos seleccionar es más importante que simplemente acumular documentos.
Planteé preguntas sobre la forma del conjunto de datos de preguntas/respuestas.
Una solicitud como “crea un mapa” no siempre se resuelve con una única pieza de código.
En la práctica, se requieren varios pasos de razonamiento: comprender la estructura del proyecto, identificar los assets a usar, analizar el estilo de código existente, revisar la sintaxis de Godot 4 y decidir qué archivos modificar.
Por lo tanto, me cuestioné si basta con incluir solo el código final en el conjunto de datos de instrucciones, o si también es necesario registrar los procesos de exploración y decisión.
Consideré la posibilidad de que el peso de Python vuelva a dominar durante el procesamiento por chunks.
Incluso si se pide “haz un mapa con Godot 4”, el modelo podría volver a favorecer pesos pre‑entrenados centrados en Python al leer el proyecto y la documentación por chunks.
Sentí la necesidad de inyectar fuertemente el contexto de Godot 4 al inicio del prompt y filtrar con mayor rigor en la fase de pre‑procesamiento para evitar que se mezclen código de Godot 3 o respuestas al estilo Python.
Resumen del día
RAG o el rastreo por sí solos no son la solución; lo crucial es diseñar cómo el modelo leerá el contexto real de la solicitud y qué juicios realizará.
Decidí dividir el contexto del proyecto por archivo/rol/dependencia y, en los datos de instrucción, incluir no solo la respuesta final sino también, cuando sea necesario, el flujo de exploración y decisión.
Es necesario diseñar prompts, etiquetas, filtros y criterios de datos preferidos más robustos para que el contexto de Godot 4 no se diluya durante el razonamiento.