Como era temporada de la Copa del Mundo, pasé mucho tiempo viendo los partidos y no dormí bien, por lo que no pude trabajar mucho
La conversión Markdown → JSONL en localhost:8501 está actualmente en aproximadamente 655 elementos
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 pruebas de validación y desarrollé la herramienta web Qwen Validation Debugger
La ruta de ejecución es tools/qwen-validation-debugger
El comando local es npm run validation-debug:debug
La dirección base es http://127.0.0.1:8520/
El 28 de junio creé manualmente fragmentos de código Godot y JSONL con el chatbot Qwen y realicé validaciones de “sí”/“no”
Este método demostró ser posible, pero a medida que aumentaban los ítems, la copia/pegado y la comparación de resultados se volvieron excesivas
En particular, había que probar las tres tablas docs_chunks, api_mapping y label_prototypes; si era sintaxis común se necesitaban 6 ranuras, y si había separación por versiones, 12 ranuras, lo que complicó mucho la gestión manual
La herramienta carga como muestra 50 ítems de prueba de Godot y, para cada ítem, Qwen etiqueta 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 configura automáticamente las ranuras JSONL por tabla
Se 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 es “sí”
api_mapping y label_prototypes son evidencia de origen de migración; a menudo el caso correcto es “no” cuando el código ya está aplicado en Godot 4 o es sintaxis común
Por ello, los nombres de las ranuras se dividieron 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 verificar si un JSONL basado en Godot 3 produce “no” cuando se prueba contra código Godot 4
Así que se añadieron botones separados de Validar código Godot 3 y Validar código Godot 4 para cada ranura, y los resultados se guardan individualmente
Después de crear la herramienta, la productividad del desarrollo mejoró notablemente
Antes se pedía a Qwen el código y el JSONL cada vez, se copiaba al prompt, se validaba y se comparaba la respuesta esperada mentalmente
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, ahora es claro bajo qué criterio se generó y qué código se validó, evitando confusiones
Al repetir los 50 ítems de prueba, la carga cognitiva disminuye, lo que permite identificar patrones de falla más rápido
Con esta herramienta se puede ver directamente en pantalla qué prompt se envía, el orden de llamadas para generación/validación masiva de JSONL, y cómo se estructuran los prompts de validación y solicitud
Las respuestas esperadas se fijan según el etiquetado y la naturaleza de la ranura, evitando confusión 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 en pantalla, lo que simplifica su corrección posterior
Ahora que la herramienta está bastante avanzada, planeo reducir el ritmo, enfocándome en refinar lentamente los criterios de validación en lugar de forzar un aumento de volumen