Résumé Technique : SrDetection

Énoncé du Problème

L'évaluation des modèles de langage pour le code (Code LLMs) est de plus en plus compromise par la fuite de données (data leakage), où des échantillons de benchmarks sont involontairement inclus dans le corpus de pré-entraînement d'un modèle. Lorsque les modèles mémorisent ces échantillons, leurs mesures de performance sont artificiellement gonflées, reflétant une mémorisation plutôt qu'une véritable généralisation. Cela compromet l'équité des comparaisons de modèles et complique l'évaluation de l'innovation réelle.

Les méthodes de détection existantes souffrent de trois limitations principales :

1. Dépendance aux données propriétaires : Les méthodes basées sur le chevauchement (ex: correspondance n-gramme) nécessitent l'accès aux corpus d'entraînement du modèle, qui sont généralement propriétaires et non divulgués.
2. Heuristiques fragiles : Le filtrage basé sur l'horodatage suppose que le code publié après la date de coupure de l'entraînement du modèle ne peut pas être dans le corpus. Cela échoue en pratique en raison de la réutilisation, de l'héritage et du forking de code.
3. Instabilité des seuils : Les approches basées sur la confiance (ex: Perplexité) dépendent de ensembles de référence externes pour calibrer les seuils de décision. Ces seuils sont souvent ajustés sur des données de langage naturel et ne se généralisent pas bien aux régularités structurelles du code, ou reposent sur les mêmes heuristiques temporelles erronées.

Méthodologie : SrDetection

Les auteurs proposent SrDetection, un cadre unifié et autoréférentiel pour la détection de la fuite de données dans des contextes à boîte grise (accès aux logits du modèle) et à boîte noire (accès uniquement aux sorties du modèle). L'hypothèse centrale est que si un modèle a mémorisé un échantillon de code spécifique, il exhibera un comportement nettement plus prévisible (perplexité plus faible ou plus grande similitude de génération) sur la forme de surface originale par rapport à des variantes sémantiquement équivalentes.

Le cadre opère en deux étapes principales :

1. Module de Transformation de Code

Ce module génère un ensemble de $n$ variantes sémantiquement équivalentes ($V = \{x_1, ..., x_n\}$) à partir d'un échantillon de benchmark original ($x_0$) en utilisant un LLM auxiliaire. Les transformations sont minimales et localisées pour préserver le comportement d'exécution tout en modifiant les formes lexicales et syntaxiques :

• Renommage de noms de fonctions ($\tau_f$) : Remplace les noms de fonctions et les sites d'appel par des alternatives sémantiquement équivalentes (ex: solve $\to$ compute).
• Renommage de variables ($\tau_v$) : Remplace systématiquement les identifiants et paramètres de variables (ex: nums $\to$ arr).
• Transformation de cas de test ($\tau_t$) : Génère de nouveaux tests d'entrée sémantiquement similaires aux originaux, les valide via l'exécution, et remplace les cas de test originaux.

2. Module de Décision de Fuite

Le cadre compare le comportement du modèle sur l'échantillon original ($x_0$) par rapport à ses variantes ($V$) sans dépendre de seuils externes.

• Contexte de Boîte Grise (basé sur la Perplexité) :
  Le score de détection $S_M(x)$ est la Perplexité (PPL) de l'échantillon. Si le modèle a mémorisé $x_0$, sa PPL sera plus faible que celle de toute variante.
  $$\text{Leakage}_{gray}(x_0) = \mathbb{I}[S_M(x_0) < \min_{x_i \in V} S_M(x_i)]$$
  Où $\mathbb{I}$ est la fonction indicatrice.

• Contexte de Boîte Noire (basé sur la Similitude de Génération) :
  Le score de détection $S_M(x)$ est le chevauchement N-gramme (NGO) entre le suffixe généré par le modèle et le suffixe de vérité terrain lorsqu'il est sollicité par un préfixe. Si mémorisé, le modèle génère un suffixe plus proche de la vérité terrain pour la forme originale que pour les variantes.
  $$\text{Leakage}_{black}(x_0) = \mathbb{I}[S_M(x_0) > \max_{x_i \in V} S_M(x_i)]$$

Construction d'un Banc d'Essai Contrôlé

Pour évaluer rigoureusement ces méthodes, les auteurs ont construit un banc d'essai de fuite contrôlée :

1. Préparation du Jeu de Données : Un benchmark de code public a été filtré pour éliminer les échantillons présentant déjà des signes de fuite (où l'original était déjà le plus facile parmi les variantes).
2. Fuite Simulée : Les modèles ont été soumis à un pré-entraînement continu sur un sous-ensemble de données (le split "entraînement") mélangé à un corpus web général, tandis que le reste des données servait de test "réservé". Cela crée une vérité terrain où la fuite est explicitement contrôlée et connue.

Contributions Clés

1. Cadre Autoréférentiel : SrDetection élimine le besoin de données de référence externes ou de seuils définis manuellement en utilisant le contraste intra-échantillon entre un extrait de code et ses variantes préservant la sémantique.
2. Augmentation Automatique : Une méthode sur mesure pour générer des variantes de code qui exposent la mémorisation sous des éditions courantes (renommage, refactorisation) tout en préservant la fonctionnalité sémantique.
3. Évaluation Contrôlée : L'introduction d'un banc d'essai basé sur l'entraînement qui permet une mesure précise de la performance de détection de la fuite à travers différents modèles et étapes d'entraînement, évitant l'imprévisibilité des heuristiques temporelles.

Résultats Expérimentaux

Les auteurs ont évalué SrDetection par rapport à des bases de référence solides (ex: PPL, Min-K% Prob, Zlib, VeilProbe, DPDLLM) sur des modèles Qwen2.5 et LLaMA3.1 ayant subi un pré-entraînement continu.

• Gains de Performance : SrDetection a significativement surpassé les bases de référence.
  • Boîte Grise : Amélioration moyenne du F1 de 21,52 points par rapport aux bases de référence solides.
  • Boîte Noire : Amélioration moyenne du F1 de 14,46 points.
• Robustesse : Contrairement aux bases de référence qui montraient une performance instable ou dépendaient d'époques spécifiques, SrDetection est resté cohérent à travers différents modèles et étapes d'entraînement.
• Sensibilité : La performance s'est améliorée avec un nombre plus élevé de variantes ($n$), et la méthode est restée stable à travers différents ratios de mélange code-texte dans le corpus de pré-entraînement.
• Application au Monde Réel : Une étude de 15 Code LLMs largement utilisés sur quatre benchmarks (APPS, HumanEval, MBPP, BigCodeBench) a révélé des motifs de fuite spécifiques aux benchmarks. Notamment, BigCodeBench a montré des taux de fuite élevés dans le contexte de boîte grise, suggérant que la détection basée sur le comportement peut identifier la contamination manquée par une analyse de chevauchement stricte.

Signification et Revendications

L'article affirme que SrDetection comble une lacune critique dans l'évaluation des Code LLMs en fournissant un mécanisme de détection indépendant des seuils et indépendant du corpus. En reformulant la détection de la fuite comme un problème autoréférentiel, la méthode évite la fragilité des hypothèses temporelles et l'inaccessibilité des données d'entraînement.

Les auteurs soutiennent que leurs conclusions démontrent que la fuite n'est pas simplement un artefact marginal mais un facteur de confusion systématique dans les pratiques d'évaluation actuelles. La capacité de détecter la fuite sans références externes suggère que les motifs de contamination spécifiques aux benchmarks sont plus prévalents et complexes que ce qui était compris auparavant via les analyses de chevauchement seules. Ce travail souligne la nécessité d'une conception et d'un reporting de benchmarks conscients de la fuite pour garantir la fiabilité des évaluations des Code LLMs.