2026-07-03 Reflexión

Lo que hice hoy

Hoy simplemente puse una transmisión de YouTube de 24 horas y ejecuté la recolección, probé la traducción y, presionando la herramienta de verificación creada el 30 de junio, realicé la validación.

En la parte de Markdown → Conversor JSONL, la cantidad de recolecciones de documentos oficiales JSONL pasó de 737 a 850. Hoy, en lugar de lanzar una gran implementación nueva, continué la recolección mientras RunPod estaba activo y, entre tanto, revisé poco a poco el flujo de verificación y traducción.

En cuanto a la traducción, estoy experimentando con una canalización que usa la API de modelo gratuito de NVIDIA. A través de los secretos del workflow de GitHub, vi que funcionaba en cierta medida y también observé la generación de README en japonés y chino. Aún no es momento de decir que está totalmente implementado, pero cuanto más documentación haya, más necesario se vuelve un flujo de traducción automática.

Satisfacción por haber creado la herramienta de verificación

Lo que más me impactó hoy fue darme cuenta de lo acertado que fue crear la herramienta de verificación el 30 de junio. Sin esa herramienta, casi hubiera sido un desastre.

Con el método anterior, tenías que hacer que Qwen generara código y JSONL por separado, luego pegarlos en el prompt y comparar mentalmente la respuesta esperada. Ahora, al pulsar un ítem, se generan el código y el JSONL, se verifica tanto el código de Godot 3 como el de Godot 4, y se pueden ver el prompt crudo y la respuesta cruda en una sola pantalla. Sigue habiendo trabajo manual, pero al menos ahora podemos observar sin perder de vista qué está mal.

Hoy revisé hasta el ítem 10 de los 50 ítems de prueba. En ese proceso encontré casos en los que el LLM respondió incorrectamente.

• En el ítem 1, se marcó como “sí” porque el candidato docs_chunks compartía la misma pista de _ready() o de la familia viewport, aunque en realidad describía un código diferente.
• En los ítems 3, 4 y 7, aunque el JSONL de migración de Godot 3 ya estaba insertado en código de formato Godot 4, el resultado fue “sí”.
• En el ítem 8, se consideró “sí” porque docs_chunks trataba un tema de seguimiento/movimiento o una API similar, aunque el comportamiento real del SOURCE_CODE era distinto.
• En los ítems 6, 9 y 10, todo pasó según lo esperado, lo que indica que la dirección de mejora no está completamente equivocada.

Estos problemas no se deben a que un JSONL sea defectuoso, sino a que, cuando una búsqueda híbrida devuelva candidatos similares, Qwen debe decidir si los usa como base o los descarta como simples resultados de búsqueda. Por lo tanto, no se trata de bloquear ciertos tokens, sino de refinar el prompt de verificación para que evalúe con mayor precisión la relación entre el código actual y los candidatos JSONL.

Comentarios

Hoy no fue un día de implementaciones llamativas. Ejecuté la recolección automática, presioné la verificación manualmente y revisé los resultados de JSONL y la validación, lo que hizo que el tiempo pasara más despacio de lo esperado. Aún así, me siento satisfecho por haber avanzado.

La verificación lleva más tiempo de lo que parece. Aunque parezca solo revisar un código y un JSONL, los tipos de docs_chunks, api_mapping y label_prototypes varían, y también difieren los códigos basados en Godot 3 y Godot 4. Con solo 10 ítems ya aparecen bastantes casos.

Sin embargo, si se detectan los puntos problemáticos con anticipación, como hoy, se pueden reducir los incidentes inesperados en la búsqueda real de bases de datos y en el flujo de verificación del recuperador. Quiero seguir identificando y registrando los problemas que se puedan anticipar en futuras pruebas.

Si fuera a mejorar, además de depender de RunPod, podría ser útil combinarlo con APIs gratuitas. Si la API de modelo gratuito de NVIDIA u otros puntos finales gratuitos pueden integrarse de forma estable en tareas como traducción, verificación auxiliar y sincronización de documentación, tal vez se pueda reducir la dependencia de RunPod.