Resumen Técnico: Mage – Evaluación Multieje de Escenas de Juego Ejecutables Generadas por LLM

Declaración del Problema

Los estándares de evaluación actuales para la generación de código por Modelos de Lenguaje Grande (LLM) dependen en gran medida de las tasas de aprobación en compilación y del éxito de las pruebas unitarias (por ejemplo, pass@k en funciones independientes). Los autores argumentan que, para artefactos específicos de dominio y multi-componente, específicamente escenas de juego ejecutables en Unity, esta métrica es activamente engañosa. Un script generado puede compilarse con éxito mientras falla al instanciar una escena funcional, renderizar contenido visible sin activar condiciones de victoria, o implementar lógica que nunca se ejecuta. Los benchmarks existentes no logran capturar la divergencia entre la corrección sintáctica (compilación) y la corrección funcional (fidelidad de dominio). Además, los intentos previos de condicionamiento semántico a nivel de Representación Intermedia (IR) resultaron en tasas de compilación del 0%, dejando abierta la pregunta de qué nivel de anclaje estructural es suficiente para la generación de código ejecutable.

Metodología

El artículo introduce Mage, un benchmark y protocolo de evaluación diseñados para evaluar escenas de juego Unity 2022 generadas por LLM a través de cuatro ejes distintos.

1. Construcción del Benchmark

• Conjunto de datos: 26 minijuegos 2D de Unity creados a mano derivados del corpus Goal Playable Concept (GPC), que cubren patrones de objetivo diversos (por ejemplo, recolección de recursos, sigilo, juego competitivo).
• Verdad de referencia: Cada patrón se materializa como una escena Unity completa y aplanada (prefabs expandidos a GameObjects) con una representación JSON sin pérdida del grafo de la escena.
• Extracción de IR: Una pipeline automatizada extrae Representaciones Intermedias (IRs) en dos niveles de granularidad:
  • Solo comportamiento: Lógica de script, cuerpos de métodos, valores de campos del inspector, configuraciones de física y cadenas de condiciones de victoria/derrota.
  • Escena completa: Datos de solo comportamiento más objetos físicos pasivos, configuración de cámara, límites y componentes de renderizado para todos los GameObjects.
• Modelos: Cuatro LLMs de pesos abiertos (7B–30B parámetros activos): Qwen3-Coder-30B, Gemma-4-26B, DeepSeek-Coder-V2-Lite y Qwen2.5-Coder-7B.
• Condiciones: Se probaron tres estrategias de prompting a través de 858 intentos de generación (3 semillas por patrón):
  1. Sin esquema (NL directo a C#): Solo descripción del patrón en lenguaje natural.
  2. IR solo comportamiento: JSON derivado de la verdad de referencia que contiene la lógica del script.
  3. IR escena completa: JSON derivado de la verdad de referencia que contiene la estructura completa de la escena.
• Control: Todas las condiciones compartieron reglas de mapeo de API y plantillas de prompt idénticas para aislar el efecto del condicionamiento de IR.

2. Protocolo de Evaluación (Mage)

El protocolo evalúa la calidad de la generación a lo largo de cuatro ejes:

1. Éxito de compilación: Si el archivo C# generado se carga en Unity sin errores (excluyendo advertencias de referencias obsoletas).
2. Éxito en tiempo de ejecución: Si la escena compilada ejecuta GameBuilder.Awake() y finaliza limpiamente sin bloquearse.
3. Fidelidad estructural: Una puntuación F1 multidimensional que compara los GameObjects, componentes, scripts y etiquetas de la escena generada contra la verdad de referencia.
4. Adherencia a mecanismos: Una métrica de análisis estático que mide la corrección de la ruta de victoria/derrota (pasos, efectos y condiciones) mediante puntuaciones F1 fijas.

Resultados Clave

Divergencia entre Corrección de Compilación y Funcional

El estudio revela una anticorrelación sistemática entre las tasas de aprobación en compilación y la corrección funcional:

• NL directo a C# (Sin esquema): Logró la mayor tasa media de aprobación en tiempo de ejecución (43%), con el modelo más fuerte (Qwen3) alcanzando el 80%. Sin embargo, estas escenas eran estructural y comportamentalmente vacías. La puntuación F1 de adherencia a mecanismos colapsó a ~0.12 (un suelo de línea base), y la puntuación F1 de etiquetas fue 0.00 en todos los modelos. Los modelos produjeron programas pequeños y localmente consistentes que satisfacían al analizador pero carecían de la estructura del patrón objetivo.
• Condicionamiento por IR: El condicionamiento sobre IR (solo comportamiento o escena completa) redujo significativamente las tasas de aprobación en tiempo de ejecución (Media: 14% y 21% respectivamente), pero mejoró drásticamente la corrección funcional. La adherencia a mecanismos F1 aumentó a 0.82–1.00 para los modelos más fuertes, y la fidelidad estructural mejoró en todas las dimensiones.

Saturación de Granularidad

Dentro de los ajustes condicionados por IR, no hubo diferencia estadística entre las granularidades solo comportamiento y escena completa. Las pruebas exactas de McNemar arrojaron p = 1.0 en los cuatro modelos, lo que indica que, para este benchmark, la información a nivel de comportamiento es suficiente para saturar el condicionamiento a nivel de entrada; agregar geometría de escena pasiva (escena completa) no produjo ganancias adicionales en la corrección funcional.

Análisis de Errores

Los fallos de compilación estuvieron dominados por errores semánticos (por ejemplo, miembros inaccesibles, resolución de tipos, conflictos de ámbito) en lugar de errores de sintaxis.

• Sin esquema: Los errores fueron raros; los modelos evitaron estructuras complejas.
• Condicionamiento por IR: Los errores se desplazaron a fallos semánticos específicos introducidos por la IR. Por ejemplo, CS0246 (tipo/namespace no encontrado) apareció exclusivamente bajo condiciones de IR (469 ocurrencias), indicando fallos en el mapeo de nombres de entidades de IR a APIs de Unity. CS0122 (miembro inaccesible) se disparó en la IR solo comportamiento (862 ocurrencias) debido a que los modelos aplicaron incorrectamente modificadores de acceso expuestos en la IR.

Contribuciones

1. Metodología de Evaluación: Un protocolo de cuatro ejes (Compilación, Tiempo de ejecución, Fidelidad Estructural, Adherencia a Mecanismos) que expone la divergencia sistemática entre las tasas de compilación y la corrección funcional en la generación de código específico de dominio.
2. Benchmark y Conjunto de Datos: Una liberación de 26 patrones de objetivos de Unity, dos niveles de granularidad de IR extraídos automáticamente, 858 salidas de generación y registros completos de reproducción para verificación independiente.
3. Caracterización Empírica: Un estudio controlado que demuestra que:
   • Las tasas de compilación están anticorrelacionadas con la corrección funcional en este dominio.
   • El condicionamiento estructural de IR recupera la estructura fiel al dominio a costa de las tasas de éxito en tiempo de ejecución.
   • Ocurre saturación de granularidad a nivel de entrada entre IRs solo comportamiento y escena completa.
4. Descomposición de Tres Factores: Una lente de marco (Completitud de Dominio, Adecuación del Mapeo de API, Fidelidad de Ejecución del LLM) para interpretar por qué el anclaje estructural falla en producir código correcto, atribuyendo los fallos a la resolución semántica y la traducción de API en lugar de la sintaxis.

Significado y Afirmaciones

El artículo afirma que la tasa de aprobación en compilación es una señal inadecuada y a menudo engañosa para evaluar LLMs en artefactos específicos de dominio y multi-componente. Los autores argumentan que confiar únicamente en métricas de compilación lleva a la falsa conclusión de que los modelos están funcionando bien cuando en realidad están generando código "estructuralmente vacío".

El significado del trabajo radica en establecer que la evaluación multieje es necesaria para detectar la divergencia entre la validez sintáctica y la corrección funcional. Los autores postulan que, para tareas que involucran marcos específicos de dominio pesados (como motores de juego), los benchmarks deben informar al menos tres ejes: aprobación a nivel de analizador, aprobación a nivel de tiempo de ejecución y aprobación de fidelidad de dominio. El estudio sugiere que, aunque el condicionamiento estructural de IR mejora la corrección funcional, introduce nuevos modos de fallo relacionados con el mapeo de API y la resolución de tipos, destacando la necesidad de mejores mecanismos de traducción entre IRs y APIs de dominio.

El artículo concluye con modestia, señalando limitaciones como el alcance de un solo motor (Unity), la falta de medición de jugabilidad humana (solo se verificó la ejecución en tiempo de ejecución) y la naturaleza interpretativa de la descomposición de tres factores, que requiere una investigación causal adicional.