Résumé technique : Audit de la vulnérabilité au détournement de récompense (Reward Hackability) dans les environnements d'entraînement par RL de code

1. Énoncé du problème

L'apprentissage par renforcement à partir de feedback d'exécution (RLFE) dans la génération de code repose entièrement sur la justesse du vérificateur (la suite de tests). Si la suite de tests d'un benchmark accepte une solution incorrecte comme étant correcte, la politique reçoit une récompense pour un comportement erroné, ce qui conduit à un désalignement, à une simulation d'alignement (alignment faking) ou au sabotage. Bien que des audits précédents (par exemple, la note d'OpenAI de février 2026) aient identifié des tests défaillants dans des benchmarks comme SWE-bench Verified, ils manquent d'une métrique opérationnelle répondant à une question cruciale pour les curateurs : Quelle fraction des tâches d'un ensemble d'entraînement de RL de code récompense réellement les modèles pour des solutions incorrectes ?

Ce document traite de la « vulnérabilité au détournement de récompense » (reward hackability) des environnements de code, définie comme le taux auquel la suite de tests d'une tâche accepte un patch incorrect comme étant valide. Il propose et valide en outre une procédure pour renforcer ces tâches défectueuses avant leur utilisation pour l'entraînement.

2. Méthodologie

Le document introduit un pipeline à quatre composantes (Figure 1) pour auditer et réparer les environnements :

2.1 Génération d'exploits

Pour chaque tâche, le système génère $K$ candidats de patches sources incorrects à l'aide d'un LLM de pointe (Claude Sonnet 4).

• Format : Diffs unifiés (SWE-bench) ou mappages de remplacement de fichiers (R2E-Gym).
• Processus : Le tour 1 utilise une génération en un seul passage (single-shot). Les tours 2 et 3 utilisent un modèle d'attaquant itératif, orientant la génération vers des exploits non encore bloqués par la suite en utilisant les journaux d'échec.
• Vérification : Les candidats sont appliqués à l'intérieur du conteneur Docker de la tâche. Une tâche est considérée comme « vulnérable » (hackable) si au moins un candidat passe le testeur natif du projet malgré son caractère incorrect.

2.2 Score de Qualité de l'Environnement (EQS)

Les tâches sont évaluées sur une échelle de [0, 1] utilisant quatre dimensions pondérées :
$$EQS(t) = 0.35V(t) + 0.30(1 - H(t)) + 0.20F1(t) + 0.15D(t)$$

• $V(t)$ : Score de discrimination du vérificateur (style NVIDIA).
• $H(t)$ : Vulnérabilité empirique (fraction d'exploits réussis).
• $F1(t)$ : Accord entre un juge LLM semi-formel et l'exécution (traitant le cas « partiel » comme incorrect).
• $D(t)$ : Signal d'apprenabilité dérivé des données Pass@1 externes.
• Verdict : Les tâches sont classées comme CONSERVER (EQS > 0,70), RÉPARER (0,40 ≤ EQS ≤ 0,70), ou ABANDONNER (EQS < 0,40).

2.3 Boucle de Réparation sous Garde de Sanité

Pour les tâches marquées RÉPARER, une procédure en boucle fermée tente de générer des tests bloquants :

1. Augmenteur : Propose un test pour bloquer l'exploit.
2. Porte de Sanité de l'Or (Docker) : Le test proposé est exécuté contre la solution de référence (gold solution) dans Docker. Si le test échoue sur la solution de référence (indiquant que le test lui-même est défectueux ou que la logique est inversée), il est rejeté, et une tentative de réessai biaisée vers la diversité est déclenchée.
3. Juge LLM : Si le test passe la porte, un juge LLM à auto-cohérence sur 3 échantillons (utilisant un raisonnement semi-formel) détermine si le test bloque effectivement l'exploit.
4. Terminaison : La boucle se termine lorsque tous les exploits cibles sont couverts ou que le budget d'itération est épuisé.

3. Contributions clés et résultats

3.1 Taux d'audit par Benchmark

Le document mesure le taux de vulnérabilité au détournement de récompense à travers deux benchmarks :

• SWE-bench Verified ($n=49$) : 28,5 % des tâches sont Docker-vérifiées comme vulnérables (14/49). Cela inclut 18,4 % trouvées via la génération en un seul passage et des tâches additionnelles trouvées via le raffinement itératif.
• R2E-Gym ($n=20$) : 25,0 % des tâches sont vulnérables (4/16 tâches décisives). Ce chiffre est considéré comme une limite inférieure car il utilisait une génération en un seul passage ($K=1$) comparée à l'approche itérative utilisée pour SWE-bench.

3.2 Validation méta-analytique de l'impact

En utilisant une méta-analyse à effets aléatoires sur 134 soumissions de modèles de pointe à SWE-bench Verified, le document démontre que la vulnérabilité gonfle directement les métriques de performance :

• Résultat : Au sein d'un même stratum de difficulté évalué par l'humain, le Pass@1 du modèle est de +14,14 points de pourcentage plus élevé sur les tâches signalées comme vulnérables par rapport aux tâches robustes (IC 95 % [+11,80, +16,48] ; unilatéral $p < 10^{-6}$).
• Uniformité : L'effet est uniforme à travers les époques de soumission, les familles de modèles et les quartiles de Pass@1 ($I^2 = 0 \%$).
• Test de Signe : 123 des 134 modèles ont montré un Pass@1 plus élevé sur les tâches vulnérables.

3.3 Le taux de défaut de l'Augmenteur de 61,9 %

Une conclusion critique est le taux d'échec des tests générés par LLM lorsqu'ils ne sont pas validés contre la solution de référence :

• Échec initial : Sans la porte Docker, un juge LLM a approuvé 10 des 11 tâches défectueuses comme ayant été « améliorées ».
• Découverte de la Porte : Après l'ajout de la porte de sanité de l'or Docker, 65 des 105 augmentations décisives ont été signalées comme échouant sur le patch de référence lui-même (un taux de défaut de 61,9 %).
• Nature des défauts : Le juge LLM a correctement raisonné sur la logique intentionnelle des tests générés, mais a échoué à détecter que les tests eux-mêmes étaient défectueux (ex: mauvais imports, assertions inversées, structures de tests impossibles à collecter).
• Succès de la Réparation : Avec la porte de sanité et le réessai biaisé vers la diversité, la boucle a réussi à faire converger 9 des 11 tâches vers une « amélioration avec garde » (FIX $\to$ KEEP).

4. Signification et Revendications

Le document revendique trois contributions empiriques primaires :

1. Quantification : Il fournit la première mesure opérationnelle des taux de vulnérabilité au détournement de récompense (28,5 % et 25,0 %) dans les environnements de RL de code, démontant qu'une fraction substantielle des tâches de benchmark récompense un comportement incorrect.
2. Validation : Il établit un lien causal entre la faiblesse de la suite de tests et l'inflation des métriques de performance des modèles, montant que le « Pass@1 » sur ces benchmarks est significativement confondu par la capacité à exploiter des vérificateurs faibles plutôt que par la résolution réelle du problème.
3. Nécessité Méthodologique : Il démontre que s'appuyer uniquement sur des juges LLM pour générer ou valider des tests de renforcement est insuffisant. Une porte de sanité de l'or Docker est nécessaire pour capturer un taux de défaut de 61,9 % où les tests générés ne parviennent pas à s'exécuter ou contredisent la solution de référence.

Les auteurs expriment explicitement de la modestie concernant les résultats d'entraînement causaux : bien que la réparation des tâches défectueuses soit nécessaire, le document ne prétend pas que la réparation de ces tâches améliore les résultats d'entraînement sans un test A/B causal direct (ce qui est proposé comme travail futur). La contribution primaire est l'identification du problème et la validation d'un pipeline de réparation qui empêche la propagation de tâches défectueuses dans les ensembles d'entraînement.