En el pipeline de análisis de código fuente de Godot, se reorganizó el papel de docs_chunks, api_mapping y label_prototypes.
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 descartan evidencias irrelevantes 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 en su totalidad.
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 oficial en Markdown se clasifica según su naturaleza: el cuerpo de la explicación 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, los resultados de validación del LLM y los resultados aprobados por el Validador se almacenan en un flujo JSONL/score DB.
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 se fija su función solo como repositorio de resultados preliminares antes de la clasificación del sistema de archivos.
En el futuro, se utilizará el sistema de archivos clasificado 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 entregaba solo los primeros 3000 caracteres del Markdown en lugar del documento completo; se corrigió para enviar todo el Markdown según el requerimiento original.
Esta tarea confirmó nuevamente que la documentación no es solo un registro, sino un proceso de verificación del 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 continuó.
Tras reiniciar la aplicación, los archivos que estaban en proceso volvieron a pending; al reanudar, se reutilizaron los resultados de clasificación existentes y se 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 falta de respuesta del servidor RunPod.