Riepilogo Tecnico: Mage – Valutazione Multi-Assiale di Scene di Gioco Esecutabili Generate da LLM

Enunciato del Problema

Gli standard di valutazione attuali per la generazione di codice da parte di Modelli Linguistici di Grande Dimensione (LLM) si basano pesantemente sui tassi di successo della compilazione e sul successo dei test unitari (ad esempio, pass@k su funzioni autonome). Gli autori sostengono che, per artefatti multi-componente e specifici di un dominio, in particolare scene di gioco eseguibili in Unity, questa metrica è attivamente fuorviante. Uno script generato potrebbe compilare con successo pur non istanziando una scena funzionale, rendendo visibile il contenuto senza attivare le condizioni di vittoria, o implementando una logica che non viene mai eseguita. I benchmark esistenti non riescono a catturare la divergenza tra correttezza sintattica (compilazione) e correttezza funzionale (fedeltà al dominio). Inoltre, i precedenti tentativi di condizionamento semantico a livello di Rappresentazione Intermedia (IR) hanno portato a tassi di compilazione dello 0%, lasciando aperta la questione di quale livello di fondazione strutturale sia sufficiente per la generazione di codice eseguibile.

Metodologia

Il documento introduce Mage, un benchmark e un protocollo di valutazione progettati per valutare le scene di gioco Unity 2022 generate da LLM lungo quattro assi distinti.

1. Costruzione del Benchmark

• Dataset: 26 mini-giochi Unity 2D creati a mano, derivati dal corpus Goal Playable Concept (GPC), che coprono modelli di obiettivo diversi (ad esempio, raccolta di risorse, furtività, gioco competitivo).
• Verità di Riferimento (Ground Truth): Ogni modello è realizzato come una scena Unity completa e appiattita (prefab espansi in GameObject) con una rappresentazione JSON senza perdita della struttura della scena.
• Estrazione IR: Una pipeline automatizzata estrae Rappresentazioni Intermedie (IR) a due livelli di granularità:
  • Solo Comportamento: Logica dello script, corpi dei metodi, valori dei campi dell'ispettore, configurazioni fisiche e catene di condizioni di vittoria/sconfitta.
  • Scena Completa: Dati "Solo Comportamento" più oggetti fisici passivi, configurazione della telecamera, confini e componenti di rendering per tutti i GameObject.
• Modelli: Quattro LLM a pesi aperti (7B–30B parametri attivi): Qwen3-Coder-30B, Gemma-4-26B, DeepSeek-Coder-V2-Lite e Qwen2.5-Coder-7B.
• Condizioni: Sono state testate tre strategie di prompting su 858 tentativi di generazione (3 seed per modello):
  1. Nessuno schema (NL diretto a C#): Solo descrizione del modello in linguaggio naturale.
  2. IR Solo Comportamento: JSON derivato dalla verità di riferimento contenente la logica dello script.
  3. IR Scena Completa: JSON derivato dalla verità di riferimento contenente l'intera struttura della scena.
• Controllo: Tutte le condizioni condividevano regole di mappatura API e modelli di prompt identici per isolare l'effetto del condizionamento IR.

2. Protocollo di Valutazione (Mage)

Il protocollo valuta la qualità della generazione lungo quattro assi:

1. Successo della Compilazione: Se il file C# generato viene caricato in Unity senza errori (esclusi gli avvisi di riferimento obsoleti).
2. Successo a Runtime: Se la scena compilata esegue GameBuilder.Awake() ed esce correttamente senza crash.
3. Fedeltà Strutturale: Un punteggio F1 multidimensionale che confronta i GameObject, i componenti, gli script e i tag della scena generata con la verità di riferimento.
4. Aderenza al Meccanismo: Una metrica di analisi statica che misura la correttezza del percorso di vittoria/sconfitta (passi, effetti e condizioni) tramite punteggi F1 fissi.

Risultati Chiave

Divergenza Correttezza-Compilazione

Lo studio rivela una sistematica anti-correlazione tra i tassi di successo della compilazione e la correttezza funzionale:

• NL diretto a C# (Nessuno schema): Ha raggiunto il tasso medio di successo a runtime più alto (43%), con il modello più forte (Qwen3) che ha raggiunto l'80%. Tuttavia, queste scene erano strutturalmente e comportamentalmente vuote. Il punteggio F1 di aderenza al meccanismo è crollato a ~0,12 (un pavimento di base), e il F1 dei tag è stato 0,00 per tutti i modelli. I modelli hanno prodotto piccoli programmi localmente coerenti che soddisfacevano il parser ma mancavano della struttura del modello target.
• Condizionamento IR: Il condizionamento su IR (Solo Comportamento o Scena Completa) ha ridotto significativamente i tassi di successo a runtime (Media: 14% e 21% rispettivamente) ma ha drasticamente migliorato la correttezza funzionale. L'aderenza al meccanismo F1 è salita a 0,82–1,00 per i modelli più forti, e la fedeltà strutturale è migliorata in tutte le dimensioni.

Saturazione della Granularità

All'interno delle impostazioni condizionate all'IR, non c'è stata alcuna differenza statistica tra la granularità "Solo Comportamento" e "Scena Completa". I test esatti di McNemar hanno restituito p = 1,0 per tutti e quattro i modelli, indicando che per questo benchmark le informazioni a livello di comportamento sono sufficienti per saturare il condizionamento a livello di input; l'aggiunta della geometria passiva della scena (Scena Completa) non ha prodotto ulteriori guadagni nella correttezza funzionale.

Analisi degli Errori

I fallimenti di compilazione erano dominati da errori semantici (ad esempio, membri inaccessibili, risoluzione dei tipi, conflitti di ambito) piuttosto che da errori di sintassi.

• Nessuno schema: Gli errori erano rari; i modelli evitavano strutture complesse.
• Condizionamento IR: Gli errori si sono spostati su specifici fallimenti semantici introdotti dall'IR. Ad esempio, CS0246 (tipo/nome spazio non trovato) è apparso esclusivamente nelle condizioni IR (469 occorrenze), indicando fallimenti nella mappatura dei nomi delle entità IR alle API di Unity. CS0122 (membro inaccessibile) è aumentato drasticamente nell'IR Solo Comportamento (862 occorrenze) a causa di modelli che applicavano erroneamente i modificatori di accesso esposti nell'IR.

Contributi

1. Metodologia di Valutazione: Un protocollo a quattro assi (Compilazione, Runtime, Fedeltà Strutturale, Aderenza al Meccanismo) che espone la divergenza sistematica tra tassi di compilazione e correttezza funzionale nella generazione di codice specifico di un dominio.
2. Benchmark e Dataset: Una release di 26 modelli di obiettivo Unity, due livelli di granularità IR estratti automaticamente, 858 output di generazione e log di riproduzione completi per la verifica indipendente.
3. Caratterizzazione Empirica: Uno studio controllato che dimostra che:
   • I tassi di compilazione sono anti-correlati con la correttezza funzionale in questo dominio.
   • Il condizionamento strutturale IR recupera una struttura fedele al dominio a scapito dei tassi di successo a runtime.
   • Si verifica una saturazione della granularità a livello di input tra IR "Solo Comportamento" e "Scena Completa".
4. Decomposizione a Tre Fattori: Una lente di inquadramento (Completezza del Dominio, Adeguatezza della Mappatura API, Fedeltà di Esecuzione LLM) per interpretare perché la fondazione strutturale non produce codice corretto, attribuendo i fallimenti alla risoluzione semantica e alla traduzione delle API piuttosto che alla sintassi.

Significato e Affermazioni

Il documento afferma che il tasso di successo della compilazione è un segnale inadeguato e spesso fuorviante per valutare gli LLM su artefatti multi-componente e specifici di un dominio. Gli autori sostengono che fare affidamento esclusivamente sulle metriche di compilazione porta alla falsa conclusione che i modelli stiano performando bene quando in realtà stanno generando codice "strutturalmente vuoto".

Il significato del lavoro risiede nell'instaurare che è necessaria una valutazione multi-assiale per rilevare la divergenza tra validità sintattica e correttezza funzionale. Gli autori ipotizzano che per compiti che coinvolgono framework pesanti specifici di un dominio (come i motori di gioco), i benchmark devono riportare almeno tre assi: passaggio a livello di parser, passaggio a livello di runtime e passaggio di fedeltà al dominio. Lo studio suggerisce che, sebbene il condizionamento strutturale IR migliori la correttezza funzionale, introduce nuovi modi di fallimento relativi alla mappatura delle API e alla risoluzione dei tipi, evidenziando la necessità di meccanismi di traduzione migliori tra IR e API di dominio.

Il documento conclude con modestia, notando limitazioni come l'ambito del singolo motore (Unity), la mancanza di misurazione della giocabilità umana (è stata verificata solo l'esecuzione a runtime) e la natura interpretativa della decomposizione a tre fattori, che richiede ulteriori indagini causali.