Résumé Technique : Le Vérificateur est le Curriculum

Énoncé du Problème

Les générateurs de code post-entraînement utilisant des juges appris (par exemple, des LLM ou des modèles multimodaux sollicités pour noter des sorties) introduisent une vulnérabilité structurelle : ces juges reposent souvent sur des caractéristiques de surface qui peuvent être manipulées sans améliorer l'artefact sous-jacent. Cela conduit au « détournement de récompense » (reward hacking), où les modèles optimisent les angles morts du juge plutôt que la justesse fonctionnelle. Dans le contexte de la génération de jeux, un juge appris pourrait récompenser la présence d'actifs visuels même si le code du jeu est défectueux ou figé.

Le papier répond à la question de savoir ce qui se passe lorsque le signal d'entraînement est au contraire un filtre déterministe, sans juge et impossible à tromper. Plus précisément, il examine si un contrôle d'exécution strict — vérifier si un projet généré se lance proprement sous un moteur en mode headless — peut piloter une auto-distillation efficace et une généralisation inter-familles.

Méthodologie

L'étude utilise GameCraft-Bench, un benchmark exigeant des modèles qu'ils génèrent des projets complets et exécutables sous Godot 4 à partir de briefs en langage naturel. La tâche est intrinsèquement difficile car la justesse est conjonctive ; une seule erreur d'analyse, un ressource manquante ou un plantage au runtime rend l'ensemble du projet non fonctionnel.

L'Échelle de Vérification

Les auteurs définissent une hiérarchie de signaux de vérification (Figure 1) :

1. BUILD (Laxiste) : Vérifie si le projet s'ouvre et se ferme sans erreur d'analyse immédiate. C'est « quasi-vacueux » car cela accepte de nombreux projets défectueux (taux de réussite de 99,9 %).
2. Strict-Launch (Porte d'Entrée de l'Entraînement) : Un contrôle déterministe exigeant que le projet se lance proprement sous un moteur headless (code de sortie 0, aucune erreur de parse/chargement/runtime). Il est impossible à tromper et précis.
3. Ancrage d'Exécution (Audit Dynamique) : Un signal secondaire qui pilote le SceneTree et mesure les changements d'état au runtime pour confirmer la substance fonctionnelle.
4. Juge Visuel (Manipulable) : La métrique officielle du benchmark, montrée comme étant manipulable (par exemple, en remplaçant les actifs tout en figeant le code).

Auto-distillation Itérative

La méthode centrale est l'auto-distillation par échantillonnage de rejet filtrée par la porte strict-launch :

1. Initialisation : Partir d'un modèle supervisé ($M_0$) entraîné sur 111 projets d'or issus de 10 familles de jeux.
2. Génération : Pour chaque brief de famille d'entraînement, générer $K=8$ projets candidats.
3. Filtrage : Matérialiser les candidats et exécuter le contrôle strict-launch. Seuls les candidats qui se lancent proprement (et possèdent $\ge$ 3 fichiers) sont conservés.
4. Création de Carburant : Les candidats conservés forment le « carburant » ($F_t$) pour le tour suivant.
5. Ré-entraînement : Un nouvel adaptateur LoRA est entraîné sur le modèle de base en utilisant l'union du pool d'or original et du nouveau carburant ($D_{t+1} = D_t \cup F_t$).
6. Itération : Ce processus se répète pour trois tours ($RFT-r1, r2, r3$).

Contrôles

Pour isoler la cause des gains de performance, les auteurs utilisent trois contrôles appariés :

• Duplication de l'Or (CTRL) : Ajoute des doublons exacts des projets d'entraînement d'or au lieu de carburant auto-généré.
• Appariement de Compte (Count-Matched) : Remplace le générateur (en utilisant $M_1$ au lieu de $M_0$) pour isoler l'effet de la qualité du carburant par rapport à sa quantité.
• Gaté par BUILD (BUILD-Gated) : Remplace le filtre strict-launch par le filtre laxiste BUILD tout en gardant le générateur et le budget identiques.

Résultats Clés

L'étude se concentre sur la généralisation inter-familles, évaluant la performance sur quatre familles de jeux inédites (horreur, rythme, puzzle, tir) comprenant 25 tâches non vues.

• Gains Composés : Sous la porte strict-launch, l'auto-distillation compose les performances de manière significative :

  • Taux de lancement propre par candidat : Passe de 8,8 % (SFT) à 13,6 % (r1), 30,9 % (r2) et 42,2 % (r3).
  • Couverture Best-of-K : Passe de 18/25 (SFT) à 25/25 (r3), atteignant le « plafond d'or » où chaque tâche non vue possède au moins un candidat propre.
  • Toutes les améliorations sont statistiquement significatives ($p < 10^{-4}$ pour les tours ultérieurs).

• Attribution des Gains :

  • Pas de Duplication de Données : Le contrôle de Duplication de l'Or (CTRL) a en réalité provoqué une régression de la performance à 5,6 %, prouvant que le simple volume ou la répétition des données est insuffisant et potentiellement nuisible.
  • La Précision du Filtre est Causale : Le contrôle gaté par BUILD (utilisant le filtre laxiste) a effacé tous les gains, revenant à la ligne de base (8,6 %). Cela isole la précision du vérificateur comme le facteur causal, et non l'optimiseur ou le volume de données.
  • Qualité vs Quantité : La décomposition du saut entre le tour 1 et le tour 2 révèle à la fois un canal de qualité (+8,8 points de pourcentage) et un canal de quantité (+8,5 points de pourcentage), la qualité étant le moteur dominant.

• Validité Fonctionnelle :

  • Audit Statique : Les projets propres des tours ultérieurs sont plus riches (médiane de 473 lignes de GDScript contre 331 pour SFT) et contiennent plus de fichiers.
  • Ancrage Dynamique : Un signal d'ancrage d'exécution indépendant confirme que les gains sont fonctionnels. Le nombre de tâches avec des candidats « ancrés » (fonctionnellement actifs) augmente de manière monotone (10 $\to$ 15/25), et l'auto-distillation produit beaucoup plus de candidats ancrés que la duplication de l'or à budget égal (16 contre 5).

Signification et Revendications

La thèse centrale du papier est que « Le vérificateur est le curriculum ».

1. Les Filtres Déterministes Permettent la Composition : Contra contrairement aux juges appris, qui peuvent être trompés et mener à une optimisation superficielle, un contrôle d'exécution déterministe et impossible à tromper définit une distribution d'entraînement qui force le modèle à apprendre la justesse fonctionnelle.
2. La Précision Pilote le Transfert : La capacité de l'auto-distillation à composer les capacités à travers des familles inédites est directement liée à la précision du filtre d'acceptation. Un filtre à haut taux de faux positifs (comme BUILD) fait composer des projets défectueux, tandis qu'un filtre précis compose des projets fonctionnels.
3. Substance Fonctionnelle : Les améliorations ne sont pas des « inflations de stub » (projets qui se lancent mais ne font rien) ; elles représentent de réelles augmentations de la complexité fonctionnelle et du comportement au runtime.

Les auteurs concluent que dans les boucles d'auto-amélioration, le plafond de capacité est fixé par l'intégrité du vérificateur, et non simplement par le volume de données. Bien que l'étude soit spécifique à la génération de jeux comme banc d'essai vérifiable, le principe suggère que pour tout domaine où un contrôle déterministe et impossible à tromper existe, l'auto-distillation itérative peut piloter une généralisation robuste et trans-domaine.