Resumen Técnico: El Verificador es el Currículo

Declaración del Problema

Los generadores de código post-entrenamiento que utilizan jueces aprendidos (por ejemplo, modelos LLM o modelos multimodales con prompts para puntuar salidas) introducen una vulnerabilidad estructural: estos jueces suelen depender de características superficiales que pueden ser manipuladas sin mejorar el artefacto subyacente. Esto conduce al "reward hacking" (hackeo de recompensa), donde los modelos optimizan los puntos ciegos del juez en lugar de la corrección funcional. En el contexto de la generación de juegos, un juez aprendido podría recompensar la presencia de activos visuales incluso si el código del juego está roto o congelado.

El artículo aborda la pregunta de qué sucede cuando la señal de entrenamiento es, en su lugar, un filtro determinista, libre de jueces y no manipulable (ungameable). Específicamente, investiga si un control de ejecución estricto —verificar si un proyecto generado se inicia limpiamente bajo un motor sin interfaz gráfica (headless)— puede impulsar una autodestilación efectiva y una generalización entre familias de modelos.

Metodología

El estudio utiliza GameCraft-Bench, un benchmark que requiere que los modelos generen proyectos completos y ejecutables de Godot 4 a partir de breves descripciones en lenguaje natural. La tarea es intrínsecamente difícil porque la corrección es conjuntiva; un solo error de análisis, un recurso faltante o un fallo en tiempo de ejecución hace que todo el proyecto deje de ser funcional.

La Escalera de Verificación

Los autores definen una jerarquía de señales de verificación (Figura 1):

1. BUILD (Permisivo): Comprueba si el proyecto se abre y cierra sin errores de análisis inmediatos. Es "casi vacuo" ya que acepta muchos proyectos rotos (tasa de éxito del 99.9%).
2. Strict-Launch (Puerta de Entrenamiento): Un control determinista que requiere que el proyecto se ejecute limpiamente bajo un motor headless (código de salida 0, sin errores de parseo/carga/tiempo de ejecución). Es no manipulable y preciso.
3. Execution Grounding (Auditoría Dinámica): Una señal secundaria que impulsa el SceneTree y mide los cambios de estado en tiempo de ejecución para confirmar la sustancia funcional.
4. Visual Judge (Manipulable/Gameable): La métrica oficial del benchmark, que se muestra como manipulable (por ejemplo, intercambiando assets mientras se congela el código).

Autodestilación Iterativa

El método central es la autodestilación por muestreo de rechazo filtrada por la puerta de strict-launch:

1. Inicialización: Partir de un modelo supervisado ($M_0$) entrenado con 111 proyectos de oro de 10 familias de juegos.
2. Generación: Para cada breve de la familia de entrenamiento, generar $K=8$ proyectos candidatos.
3. Filtrado: Materializar los candidatos y ejecutar el chequeo de strict-launch. Solo se mantienen los candidatos que se lanzan limpiamente (y tienen $\ge$3 archivos).
4. Creación de Combustible: Los candidatos mantenidos forman el "combustible" ($F_t$) para la siguiente ronda.
5. Reentrenamiento: Se entrena un nuevo adaptador LoRA sobre el modelo base utilizando la unión del pool original de oro y el nuevo combustible ($D_{t+1} = D_t \cup F_t$).
6. Iteración: Este proceso se repite durante tres rondas ($RFT-r1, r2, r3$).

Controles

Para aislar la causa de las mejoras de rendimiento, los autores emplean tres controles emparejados:

• Gold-Duplication (CTRL): Añade duplicados exactos de los proyectos de entrenamiento de oro en lugar de combustible autogenerado.
• Count-Matched: Intercambia el generador (usando $M_1$ en lugar de $M_0$) para aislar el efecto de la calidad del combustible frente a la cantidad.
• BUILD-Gated: Reemplaza el filtro strict-launch por el filtro permisivo BUILD, manteniendo el generador y el presupuesto idénticos.

Resultados Clave

El estudio se centra en la generalización entre familias, evaluando el rendimiento en cuatro familias de juegos no vistas (terror, ritmo, puzzle, shooter) que comprenden 25 tareas reservadas.

• Ganancias Compuestas: Bajo la puerta de strict-launch, la autodestilación compone el rendimiento significativamente:

  • Tasa de lanzamiento limpio por candidato: Aumenta de 8.8% (SFT) a 13.6% (r1), 30.9% (r2) y 42.2% (r3).
  • Cobertura Best-of-K: Aumenta de 18/25 (SFT) a 25/25 (r3), alcanzando el "techo de oro" donde cada tarea reservada tiene al menos un candidato limpio.
  • Todas las mejoras son estadísticamente significativas ($p < 10^{-4}$ para las rondas posteriores).

• Atribución de Ganancias:

  • No es Duplicación de Datos: El control de Gold-Duplication (CTRL) de hecho retrocedió el rendimiento al 5.6%, demostrando que el mero volumen o repetición de datos es insuficiente y potencialmente perjudicial.
  • La Precisión del Filtro es Causal: El control BUILD-gated (usando el filtro permisivo) borró todas las ganancias, regresando al rendimiento base (8.6%). Esto aísla la precisión del verificador como el factor causal, no el optimizador ni el volumen de datos.
  • Calidad vs. Cantidad: La descomposición del salto de la ronda 1 a la 2 revela tanto un canal de calidad (+8.8 puntos porcentuales) como un canal de cantidad (+8.5 puntos porcentuales), siendo la calidad el motor dominante.

• Validez Funcional:

  • Auditoría Estática: Los proyectos limpios de las rondas posteriores son más ricos (mediana de 473 líneas de GDScript frente a 331 para SFT) y contienen más archivos.
  • Grounding Dinámico: Una señal de grounding de ejecución independiente confirma que las ganancias son funcionales. El número de tareas con candidatos "grounded" (funcionalmente activos) aumenta monótonamente (10 $\to$ 15/25), y la autodestilación produce muchos más candidatos funcionales que la duplicación de oro (16 vs. 5 con presupuesto igualado).

Significado y Reivindicaciones

La tesis central del artículo es que "El verificador es el currículo".

1. Los Filtros Deterministas Permiten la Composición: A diferencia de los jueces aprendidos, que pueden ser manipulados y llevar a una optimización superficial, un control de ejecución determinista y no manipulable define una distribución de entrenamiento que obliga al modelo a aprender la corrección funcional.
2. La Precisión Impulsa la Transferencia: La capacidad de la autodestilación para componer capacidades entre familias no vistas está directamente ligada a la precisión del filtro de aceptación. Un filtro con alta tasa de falsos positivos (como BUILD) hace que el bucle componga proyectos rotos, mientras que un filtro preciso compone proyectos funcionales.
3. Sustancia Funcional: Las mejoras no son "infladas por estuches" (proyectos que se lanzan pero no hacen nada); representan incrementos genuinos en la complejidad funcional y el comportamiento en tiempo de ejecución.

Los autores concluyen que, en los bucles de automejora, el techo de la capacidad está determinado por la integridad del verificador, no simplemente por el volumen de datos. Aunque el estudio es específico para la generación de juegos como un banco de pruebas verificable, el principio sugiere que para cualquier dominio donde exista un chequeo determinista y no manipulable, la autodestilación iterativa puede impulsar una generalización robusta entre dominios.