Se reorganizó el papel de docs_chunks, api_mapping y label_prototypes en la canalización de análisis de código fuente de Godot
docs_chunks se utiliza en el flujo de generación de descripciones de código. Se buscan fragmentos de la documentación oficial basándose en fragmentos de AST/código y prompts, se descarta la evidencia no relevante y se crea un JSONL de descripciones.
api_mapping es el objetivo donde se almacena cómo cambiaron los nombres de funciones, clases y símbolos de Godot 3 a Godot 4.
label_prototypes es el objetivo donde se guardan patrones de transformación para casos en los que no solo cambió el nombre, sino que también cambiaron la forma de usar la función, la composición de argumentos y los patrones de llamada.
Se estructuró el proceso de analizar proyectos de GitHub o el sistema de archivos local por fragmentos de AST/código, llamar al Retriever necesario y luego invocar Qwen 3.6 bajo demanda
La documentación Markdown oficial se clasifica según su naturaleza: el cuerpo explicativo va a docs_chunks, los cambios de nombre/símbolo a api_mapping y los cambios de uso/patrón de llamada a label_prototypes. Cada uno se guarda como JSONL.
Los resultados de búsqueda del Retriever por fragmento, la verificación del LLM y el paso del validador se almacenan en un flujo JSONL/base de datos de puntuaciones.
Las columnas, el método de agregación y las etiquetas de clasificación de la base de datos de puntuaciones aún no se han definido; por ahora su función está fija como repositorio de resultados preliminares antes de la clasificación del sistema de archivos.
En el futuro, el sistema de archivos clasificado servirá como fuente para diseñar SFT y DPO.
Al documentar el método de clasificación del LLM, se detectó que, contrariamente a lo solicitado, el LLM enviaba solo los primeros 3000 caracteres del Markdown en lugar del documento completo; se corrigió para transmitir todo el Markdown según el requerimiento original.
Esta tarea reafirmó que la documentación no es solo un registro, sino un proceso de validar el comportamiento real del código.
Durante la conversión de Markdown a JSONL, el servidor RunPod se detuvo inesperadamente; al volver a lanzar la aplicación Streamlit, se observó que el estado previo no se reinicializó y la conversión continuó.
Tras reiniciar la app, los archivos en proceso volvieron a pending; al reanudar, la aplicación reutilizó los resultados de clasificación existentes y continuó desde el mismo archivo.
Para trabajos de conversión prolongados, se concluyó que es necesario configurar alertas que avisen temprano sobre la finalización o la imposibilidad de respuesta del servidor RunPod.