Learned or Memorized ? Quantifying Memorization Advantage in Code LLMs

1. Problématique et Contexte

L'essor des Modèles de Langage (LLM) spécialisés dans le code a transformé le génie logiciel, mais leur adoption soulève des inquiétudes majeures concernant la transparence des données d'entraînement.

• Manque de transparence : Les ensembles de données utilisés pour l'entraînement sont souvent propriétaires ou mal documentés, rendant difficile la détection des fuites de données (data leakage).
• Risque de surévaluation : Si un modèle a vu les données d'évaluation lors de l'entraînement, ses performances peuvent être artificiellement gonflées, masquant son incapacité réelle à généraliser.
• Défi de détection : Les méthodes existantes pour détecter la mémorisation nécessitent souvent un accès aux détails internes du modèle ou à une partie des données d'entraînement, ce qui n'est pas toujours possible.

L'article vise à quantifier l'« avantage de mémorisation » (memorization advantage) : la différence de performance entre un modèle face à des données qu'il a probablement vues (ou mémorisées) et des données nouvelles, en utilisant une approche basée sur la perturbation.

2. Méthodologie

Les auteurs proposent un cadre empirique fondé sur l'Hypothèse de Sensibilité à la Perturbation (PSH).

Concept Central

L'hypothèse postule que :

• Un modèle qui a mémorisé un exemple spécifique réagira de manière brutale (chute de performance) face à de légères perturbations de l'entrée, car il ne peut pas interpoler.
• Un modèle qui a généralisé (compris les principes sous-jacents) maintiendra une performance plus stable face aux perturbations, car il applique des règles apprises.

Métrique : L'Avantage de Mémorisation

L'avantage de mémorisation ($ma$) est défini comme la différence de performance entre la réponse à une entrée originale $x$ et une entrée perturbée $x'$ :
$$ma(M, x, y) = |p_\theta(y|x) - p_\theta(y|x'(x))|$$
Une sensibilité élevée indique une forte probabilité de mémorisation, tandis qu'une faible sensibilité suggère une généralisation robuste.

Protocole Expérimental

1. Modèles Évalués : 8 LLM de code open-source de pointe (DeepSeek-Coder-V2, Qwen2.5-Coder, StarCoder, CodeLlama, Codestral, OpenCoder, WizardCoder, Magicoder).
2. Benchmarks : 19 ensembles de données couvrant 5 tâches :
   • Génération de code (HumanEval, APPS, MBPP, etc.).
   • Génération de tests (BigCodeBench, TestEval).
   • Réparation de bugs (Defects4J, ConDefects, QuixBugs).
   • Détection de vulnérabilités (CVEFixes, DiverseVul, etc.).
   • Résumé de code (CodeSearchNet).
3. Techniques de Perturbation :
   • Pour les tâches NL2Code (Prompt) : Reformulation du texte naturel via le modèle BART pour créer des variantes syntaxiques tout en conservant le sens.
   • Pour les tâches Code2Code/Code2NL : Renommage aléatoire des identifiants de variables (alpha-renaming) pour modifier la syntaxe sans changer la sémantique.
4. Analyse Statistique : Utilisation du test de Mann-Whitney U (avec correction de Bonferroni) pour déterminer si les distributions de sensibilité sont statistiquement significatives.

3. Contributions Principales

1. Cadre d'évaluation empirique : Application de l'analyse de sensibilité aux perturbations pour distinguer la mémorisation de la généralisation dans les LLM de code.
2. Évaluation à grande échelle : Analyse comparative de 8 modèles sur 19 benchmarks, couvrant un spectre complet de tâches logicielles.
3. Remise en question des benchmarks : Résultats statistiques défiant les hypothèses courantes sur la contamination des benchmarks populaires (notamment CVEFixes et Defects4J), révélant une faible mémorisation.
4. Impact de l'architecture : Démonstration que des modèles de taille comparable (ex: StarCoder vs CodeLlama) présentent des profils de sensibilité radicalement différents, prouvant que le choix architectural et la méthodologie d'entraînement impactent la généralisation plus que la simple taille du modèle.
5. Insights spécifiques aux tâches : Identification de la génération de tests et de la réparation contextuelle comme les tâches les plus difficiles à généraliser, contrairement au résumé de code.

4. Résultats Clés

A. Variations selon les Tâches

• Résumé de code (Code Summarization) : Montre la plus faible sensibilité (< 0,3) pour tous les modèles. Cela indique une généralisation très robuste, probablement due à l'abondance de paires code-documentation dans les données d'entraînement.
• Génération de tests (Test Generation) : Présente une sensibilité élevée (0,4 - 0,7), significativement plus élevée que la génération de code de base. Cela suggère que comprendre la logique pour créer des tests est une tâche de généralisation plus complexe.
• Génération de code : La plupart des modèles montrent une bonne généralisation, sauf sur le benchmark APPS où StarCoder affiche une sensibilité très élevée (~0,8), suggérant une contamination potentielle ou une mémorisation spécifique.

B. Découvertes sur les Benchmarks Controversés

• CVEFixes et Defects4J : Contrairement aux craintes de la communauté, ces benchmarks affichent une sensibilité extrêmement faible (CVEFixes < 0,1 ; Defects4J 0,2-0,4).
  • Interprétation : Les modèles ne mémorisent pas simplement ces exemples ; ils ont appris à généraliser les motifs de vulnérabilités et de bugs présents dans ces ensembles de données.
• ConDefects : Ce benchmark de réparation de bugs contextuels montre une sensibilité élevée, indiquant que les modèles peinent à généraliser lorsque le contexte s'étend sur plusieurs fonctions.

C. Différences entre Modèles

• StarCoder se distingue souvent par une sensibilité plus élevée (mémorisation potentielle), notamment sur APPS et les tâches de détection de bugs.
• QwenCoder et CodeLlama montrent systématiquement des profils de sensibilité plus bas, suggérant des capacités de généralisation supérieures.

5. Signification et Implications

• Fiabilité des Évaluations : La performance élevée sur un benchmark standard ne garantit pas la généralisation. L'ajout d'une analyse de sensibilité aux perturbations est crucial pour valider les résultats.
• Validité des Benchmarks de Sécurité : Les résultats sur CVEFixes et Defects4J rassurent sur la validité de ces benchmarks pour évaluer la capacité réelle des modèles à détecter des vulnérabilités, contrairement à ce que la littérature suggérait souvent.
• Conception de Modèles : La taille des paramètres n'est pas le seul facteur déterminant. Les choix architecturaux (mécanismes d'attention, méthodes d'entraînement comme l'instruction tuning) jouent un rôle prépondérant dans la capacité à généraliser.
• Recommandations Futures :
  • Adoption de benchmarks dynamiques (mis à jour régulièrement) pour éviter la contamination.
  • Intégration systématique de l'analyse de sensibilité aux perturbations dans les protocoles d'évaluation.
  • Développement de modèles spécialisés pour les tâches à forte sensibilité (génération de tests, réparation contextuelle).

Conclusion

Cette étude fournit une méthodologie rigoureuse pour quantifier la frontière entre mémorisation et apprentissage réel dans les LLM de code. Elle démontre que, bien que des problèmes de mémorisation existent (notamment sur certains benchmarks spécifiques), de nombreux modèles démontrent une capacité de généralisation réelle, en particulier sur des tâches comme le résumé de code et la détection de vulnérabilités sur des benchmarks éprouvés. L'accent doit désormais être mis sur des cadres d'évaluation plus robustes et dynamiques.