2026-06-14 Reflexión

Pensamientos en el autobús que sube a Seúl

Hoy, dentro del autobús que sube a Seúl, volví a pensar en la tubería de datos/RAG de Godot 4 que diseñé la última vez. El 12 de junio pensé en rastrear la documentación oficial, recopilar proyectos de Godot de GitHub y colocar un chatbot RAG al frente para determinar si es Godot 3/4 y generar datos de instrucción.

Sin embargo, al reflexionar de nuevo hoy, me di cuenta de que hay muchas preguntas sin resolver para que esta arquitectura funcione bien. En particular, la brecha entre “se recopilaron los documentos” y “el modelo los utiliza eficazmente” es mayor de lo que imaginaba y eso me sigue molestando.

Primera pregunta: ¿Puede el chatbot RAG manejar todo el contexto?

Inicialmente pensé que, si rastreaba la documentación oficial de Godot y creaba un chatbot RAG, podría usarlo para clasificar o validar los proyectos de GitHub recopilados. Pero al imaginar el escenario de raspar proyectos de GitHub, convertirlos a formatos md o jsonl y lanzar todo ese contenido al chatbot de una sola vez, surgió la duda:

¿Puede el modelo recibir todo ese contexto de entrada?

Incluso un solo proyecto de Godot incluye README, estructura de directorios, varios archivos .gd, archivos de escena y rutas de recursos. Si a eso le añadimos fragmentos de documentación oficial obtenidos mediante RAG, la entrada puede crecer rápidamente. No basta con que exista la documentación rastreada; el modelo no puede leer de forma fiable todo el proyecto y los documentos relacionados en cada solicitud.

Al fin y al cabo, crear un chatbot RAG no significa insertar todo el documento de una vez, sino construir una estructura de búsqueda/selección que decida qué fragmento de documento traer para cada pregunta. Si esa parte es deficiente, el modelo puede pasar por alto archivos importantes o perder el contexto del proyecto al leer documentos innecesarios.

Segunda pregunta: ¿Es suficiente una sola respuesta de código por pregunta?

La segunda duda surgió respecto a la forma del conjunto de datos de instrucción. Por ejemplo, si consideramos la pregunta “Crea un mapa”, la respuesta no tiene por qué ser simplemente un bloque de código.

Para que un LLM genere una respuesta real, debe pasar por varios pasos: observar la estructura del proyecto, identificar qué escenas y scripts existen, comprobar los assets disponibles, leer el estilo de código existente, verificar que cumpla con la sintaxis de Godot 4 y, finalmente, decidir qué archivos y código modificar.

En otras palabras, la pregunta “Crea un mapa” parece una sola solicitud, pero internamente implica varias capas de razonamiento. Si en los datos de entrenamiento solo dejamos el código final, surge la duda de si el modelo podrá aprender el proceso intermedio de toma de decisiones.

Los datos de respuesta correcta podrían no contener solo el código completo, sino también información sobre qué archivos leer, en qué evidencia basarse, por qué se eligió una API concreta, etc. Especialmente si queremos que actúe como un agente de codificación, podría ser más apropiado registrar un flujo “pregunta → exploración → juicio → modificación → verificación” en lugar de solo “pregunta → respuesta”.

Tercera pregunta: ¿No volverá a aparecer el sesgo hacia Python al procesar fragmentos?

La tercera inquietud se relaciona con el sesgo de lenguaje. Incluso si damos el prompt “Crea un mapa con Godot 4”, me preocupa que, al dividir el proyecto o la documentación en fragmentos, el modelo favorezca patrones de código Python o de resolución de problemas al estilo Python.

Los modelos de codificación genéricos probablemente hayan sido entrenados mucho más con Python. Por lo tanto, solo anteponer la palabra Godot puede no ser suficiente. Si los fragmentos recuperados no contienen suficiente contexto de Godot 4, o si durante el razonamiento intermedio el modelo recurre a patrones de codificación comunes, podría derivar en respuestas al estilo Python.

Así que no basta con decir “Hazlo en Godot 4”; debemos reforzar el contexto de Godot 4 tanto en el prompt como en la fase de preprocesamiento de datos. Por ejemplo, etiquetar los datos de entrada con una marca específica de Godot 4, filtrar más agresivamente los datos que mezclan código de Godot 3 u otros lenguajes, o inyectar repetidamente la restricción “Esta tarea sigue la sintaxis de GDScript de Godot 4” antes de generar la respuesta.

Resumen de hoy

La idea central de hoy es que ni RAG ni el rastreo por sí solos son la solución. Lo más importante no es recopilar mucha documentación, sino diseñar cómo el modelo leerá el contexto y qué juicios debe hacer en una solicitud real.

La arquitectura actual parece necesitar dividirse en los siguientes pasos:

• No insertar todo el proyecto de una vez, sino crear una estructura buscable basada en archivo/rol/dependencia.
• Evaluar si los datos de instrucción deben incluir solo el código final o también el proceso de exploración y juicio.
• Diseñar prompts, etiquetas, filtros y criterios de datos preferidos que mantengan fuerte el contexto de Godot 4 durante el razonamiento.

En última instancia, para crear un “modelo de codificación de Godot 4” no basta con reunir solo código de Godot 4. Los datos deben reflejar también el orden en que el modelo lee el proyecto, cómo decide que algo es Godot 4 y cómo selecciona la mejor respuesta.

Reflexión

Hoy no fue un día de mucho código, pero sí una ocasión para volver a observar los vacíos del diseño anterior. Pensar distraído en el autobús hizo que notara problemas que había pasado por alto frente al escritorio. Decir que se crea un chatbot RAG es fácil; en la práctica, la unidad de búsqueda, el tamaño del contexto, la estructura de preguntas/respuestas y el control del sesgo de lenguaje están todos interconectados.

Aún no hay respuesta. Pero el hecho de que surjan preguntas es una señal positiva. Registrar estas dudas ahora servirá como referencia para saber qué validar cuando implementemos la tubería más adelante.

A continuación, basándome en estas preguntas, deberé concretar cómo dividir el contexto del proyecto, hasta qué punto incluir el proceso de razonamiento en los datos de instrucción y qué reglas de preprocesamiento usar para mantener fuerte el contexto de Godot 4.