Fue temporada de la Copa del Mundo, y al ver los partidos no dormí bien, por lo que no pude trabajar mucho
La conversión Markdown → JSONL en localhost:8501 está actualmente alrededor de 655 documentos
Hoy me concentré en crear y pulir una herramienta sencilla de depuración de pruebas de validación, en lugar de una gran recolección/entrenamiento
Definí la estrategia de la herramienta de depuración de pruebas de validación y desarrollé la herramienta web Qwen Validation Debugger
Ruta de ejecución: tools/qwen-validation-debugger
Comando local: npm run validation-debug:debug
Dirección base: http://127.0.0.1:8520/
El 28 de junio probé crear manualmente fragmentos de código Godot y JSONL con el chatbot Qwen y realicé validaciones de “sí”/“no”
Este método demostró ser viable, pero a medida que aumentan los ítems, la copia/pegado y la comparación de resultados se vuelve excesiva
En particular, hay que probar las tres tablas docs_chunks, api_mapping y label_prototypes; si es sintaxis común se requieren 6 ranuras, y si se separa por versiones, 12 ranuras, lo que complica mucho la gestión manual
La herramienta carga como muestra 50 ítems de prueba de Godot y, para cada ítem, hace que Qwen etiquete primero si es sintaxis común o separación Godot 3/4
Si es sintaxis común, genera un solo código común
Si hay diferencia de versión, genera código para Godot 3 y para Godot 4 por separado
Luego crea automáticamente las ranuras JSONL por tabla
Confirmé nuevamente que no se pueden agrupar docs_chunks, api_mapping y label_prototypes bajo un único “sí/no”
docs_chunks sirve como evidencia de explicación del código, por lo que si coincide directamente con el código, la respuesta es “sí”
api_mapping y label_prototypes son evidencia de origen de migración; a menudo la respuesta correcta es “no” cuando el código ya está aplicado en Godot 4 o es sintaxis común
Por eso dividí los nombres de ranura en: evidencia de explicación, explicación irrelevante, requiere conversión, ya aplicado, común/innecesario, conversión irrelevante
El cambio más importante al crear la herramienta fue separar el código base de generación JSONL del código objetivo de validación
Inicialmente, los JSONL creados con código Godot 3 se validaban solo contra código Godot 3, y los creados con Godot 4 solo contra Godot 4
Pero en la práctica también hay que comprobar si un JSONL basado en Godot 3 produce “no” cuando se aplica al código Godot 4
Así que añadí botones separados de Validación de código Godot 3 y Validación de código Godot 4 para cada ranura, y guardo los resultados por separado
Después de crear la herramienta, la productividad de desarrollo mejoró notablemente
Antes, tenía que pedir a Qwen el código y el JSONL cada vez, volver a insertarlos en el prompt, validar y comparar mentalmente la respuesta esperada
Ahora la selección de ítems, etiquetado, generación de código, generación de JSONL, validación cruzada Godot 3/4 y revisión de prompt/respuesta cruda ocurren en una sola pantalla
En lugar de simplemente producir mucho rápido, lo más valioso es que ahora sé con qué criterio se generó y contra qué código se validó, sin confusiones
Al repetir los 50 ítems de prueba, el estado que la persona debe recordar disminuye, lo que permite detectar patrones de falla más rápido
Con esta herramienta puedo ver directamente en pantalla:
Qué prompt se envía, cómo se llama la generación/validación masiva de JSONL y en qué orden
Cómo se estructuran el prompt de validación y el prompt de solicitud
La respuesta esperada está fijada según el etiquetado y la naturaleza de la ranura, evitando confusiones entre “sí” y “no”
Los resultados aparecen inmediatamente por ranura, facilitando la identificación rápida de combinaciones de código y JSONL que fallan
Incluso si una falla se debe al prompt, el prompt usado queda visible, lo que simplifica su corrección posterior
Ahora que la herramienta está bastante avanzada, planeo reducir el ritmo, enfocarme en refinar lentamente los criterios de validación en lugar de forzar un aumento de volumen