💬 NLP

Fine-Tuning Pre-Trained Code Models for AI-Generated Code Detection

Le document présente le système de l'équipe « Archaeology » pour la tâche 13 de SemEval-2026, qui exploite des modèles de code préentraînés affinés et des stratégies spécialisées telles que la validation croisée en laissant une langue de côté et l'empaquetage de tokens sandwich pour atteindre des performances de premier plan dans la détection du code généré par l'IA et l'attribution de sa source.

Auteurs originaux : Jany-Gabriel Ispas, Sergiu Nisioi

Publié 2026-05-05

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Jany-Gabriel Ispas, Sergiu Nisioi

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez une agence de détectives numériques appelée Archaeology. Leur travail ne consiste pas à fouiller de la poterie antique, mais à tamiser des piles de code informatique pour répondre à deux grandes questions :

Qui a écrit ceci ? S'agit-il d'un programmeur humain ou d'un robot (IA) ?
Quel robot l'a écrit ? Si c'est un robot, quel modèle d'IA spécifique l'a créé ?

Cette équipe a participé à une compétition à haut risque appelée SemEval-2026 Task 13 pour prouver ses compétences. Voici comment ils ont procédé, expliqué simplement.

Le Défi : Un Mystère en Deux Parties

La compétition comportait deux énigmes distinctes, chacune nécessitant une stratégie d'enquête différente.

Énigme A : Le Test "Humain vs Robot" (Classification Binaire)

L'Objectif : Examiner un morceau de code et dire "Humain" ou "IA".
Le Piège : L'équipe s'est entraînée principalement sur du code Python (91 % de leurs données d'entraînement), mais le test final incluait des langues qu'ils n'avaient jamais vues, comme JavaScript, Go et C#. C'est comme enseigner à un chef de cuisiner uniquement de la nourriture italienne, puis lui demander d'identifier si un plat est fait maison ou fabriqué en usine alors qu'il s'agit en réalité d'un curry thaï.
L'Indices : Le code généré par l'IA a tendance à être plus long et plus uniforme, tandis que le code humain est plus court et plus chaotique. Cependant, cette règle s'inverse selon la langue (par exemple, en C++, les humains écrivent en réalité du code plus long que l'IA).

Énigme B : Le Test "Quel Robot ?" (Attribution Multi-Classes)

L'Objectif : Si le code est généré par une IA, identifier exactement lequel des 11 modèles d'IA différents l'a écrit.
Le Piège : Les données étaient extrêmement déséquilibrées. Une catégorie (code écrit par des humains) représentait 88 % des données, tandis que certains modèles d'IA spécifiques avaient moins de 2 000 exemples. C'est comme chercher une aiguille dans une botte de foin, où la botte est composée à 99 % de foin et les aiguilles sont de différentes couleurs, mais vous n'avez qu'une seule aiguille rouge et un million d'aiguilles bleues.
L'Indices : Différents modèles d'IA ont des styles d'"écriture" subtils, mais ces styles sont difficiles à repérer dans du code long et complexe.

La Boîte à Outils du Détective

L'équipe n'a pas seulement deviné ; elle a utilisé quatre "super-yeux" différents (modèles d'IA pré-entraînés) et leur a donné des techniques d'entraînement spéciales pour chaque énigme.

Pour l'Énigme A (Humain vs Robot)

L'Exercice "Changement de Langue" : Pour se préparer aux langues surprises du test, ils ont entraîné les modèles en cachant une langue à la fois. Ils ont appris au modèle à reconnaître des modèles sans dépendre de astuces spécifiques à une langue (comme l'utilisation de # pour les commentaires en Python).
L'Entraînement "Nettoyage et Masquage" : Ils ont retiré les commentaires et remplacé les nombres par des espaces réservés pendant l'entraînement. Cela a forcé les modèles à examiner la logique du code, et non seulement les décorations de surface.
La Stratégie "Découpage" : Puisque le code de test était souvent trop long pour être lu d'un seul coup, ils l'ont découpé en morceaux se chevauchant (comme lire un long livre en lisant quelques pages à la fois). Ils ont ensuite pris la moyenne de ces tranches, en ignorant les prédictions les plus extrêmes et "bruyantes", pour prendre une décision finale.
Le Réglage "Cas Difficiles" : Ils ont créé un "test difficile" spécial en utilisant des exemples qu'un simple programme informatique avait mal classés. Ils ont ajusté leur seuil de décision (la ligne entre "Humain" et "IA") sur la base de ces cas piégeux pour s'assurer qu'ils ne seraient pas trompés par les données du test.

Pour l'Énigme B (Quel Robot ?)

La Technique "Sandwich" : Puisque le code était trop long pour tenir dans la mémoire du modèle, ils ne l'ont pas simplement coupé au milieu. Au lieu de cela, ils ont conservé la Tête (début) et la Queue (fin) du code et les ont empilés ensemble comme un sandwich, avec un marqueur spécial au milieu. Cela a préservé le style au début et à la fin, là où la "signature robot" se cache souvent.
Le Poids "Équité" : Comme certains modèles d'IA étaient rares dans les données, l'équipe a dit au modèle : "Ne devinez pas simplement le plus courant ! Faites attention particulière aux rares." Ils ont ajusté le système de scoring afin que le modèle apprenne à repérer les robots rares, et non seulement les populaires.
Le Vote "Sagesse de la Foule" : Ils ont fait passer le même code à travers le modèle plusieurs fois avec de légères variations et ont laissé les modèles voter pour la réponse. Cela a réduit les erreurs et augmenté la confiance.

Les Résultats

L'équipe "Archaeology" s'en est très bien sortie :

Énigme A : Ils ont obtenu un score de 0,737, se classant 6e sur 81 équipes. Leur meilleur outil était CodeBERT, qui semblait mieux comprendre la "logique" du code que les autres.
Énigme B : Ils ont obtenu un score de 0,422, se classant 7e sur 34 équipes. Leur meilleur outil ici était UniXcoder, qui a bénéficié de l'examen de tranches de code plus longues et de l'utilisation de la stratégie de "vote".

La Grande Leçon

L'équipe a découvert que la façon dont un modèle est entraîné compte plus que sa taille.

Les petits modèles (125 millions de paramètres) entraînés spécifiquement pour comprendre la logique du code ont mieux performé pour repérer l'IA.
Le géant (220 millions de paramètres) n'a pas gagné, ce qui suggère que pour ce travail spécifique, être un "spécialiste" est mieux que d'être un "généraliste".

En bref, l'équipe a prouvé qu'avec les bons tours d'entraînement — comme découper le code long, ignorer le bruit de surface et voter sur les réponses — on peut construire un système étonnamment efficace pour repérer le code généré par l'IA, même lorsqu'il tente de se déguiser dans de nouvelles langues.

Résumé technique : Archéologie à SemEval-2026 Tâche 13

Énoncé du problème

L'article aborde le défi de la détection du code source généré par l'IA, un enjeu crucial pour l'intégrité académique, la sécurité de la chaîne d'approvisionnement logicielle et l'attribution de la propriété intellectuelle. Les auteurs ont participé à la Tâche 13 de SemEval-2026, divisée en trois sous-tâches ; leur système, « Archéologie », s'est concentré sur les deux premières :

Sous-tâche A : Classification binaire pour distinguer le code écrit par un humain du code généré par l'IA.
Sous-tâche B : Attribution multi-classes pour identifier la famille spécifique de Modèle de Langage (LLM) ayant généré un extrait de code donné parmi 11 classes (incluant le code écrit par un humain et 10 modèles d'IA distincts).

Les deux sous-tâches utilisent le score F1 macro-moyen comme métrique d'évaluation principale. Les tâches présentent des défis distincts : la sous-tâche A nécessite une généralisation à des langages de programmation hors domaine (OOD) non vus pendant l'entraînement, tandis que la sous-tâche B doit gérer des distributions de classes extrêmement déséquilibrées (un ratio de 225:1 entre les classes la plus grande et la plus petite) et des séquences de code longues.

Méthodologie

Ligne de base

L'équipe a établi une ligne de base utilisant des caractéristiques TF-IDF (n-grammes de caractères allant des bigrammes aux 5-grammes) combinées à une Régression Logistique. Le code a été tronqué aux 10 000 premiers caractères. Pour la sous-tâche B, des poids de classes équilibrés ont été appliqués pour atténuer le déséquilibre des étiquettes. Cette ligne de base a obtenu des scores F1 macro de 0,266 (sous-tâche A) et 0,255 (sous-tâche B), démontrant que les motifs lexicaux de surface seuls sont insuffisants.

Modèles pré-entraînés

Le système principal affine quatre modèles de code pré-entraînés :

CodeBERT : Encodeur uniquement (RoBERTa-base, 125M de paramètres), pré-entraîné avec le modèle de langage masqué (MLM) et la détection de tokens remplacés.
GraphCodeBERT : Encodeur uniquement (RoBERTa-base), étendant CodeBERT avec des structures de graphes de flux de données.
UniXcoder : Encodeur uniquement (RoBERTa-base), un modèle unifié supportant la compréhension et la génération via des objectifs cross-modaux.
CodeT5+ : Encodeur-décodeur (220M de paramètres), pré-entraîné avec du débruitage et un modèle de langage causal sur des paires code-texte.

Stratégies pour la sous-tâche A (Classification binaire)

Pour relever le défi des langages hors domaine (entraînement sur Python, C++, Java ; test sur des langages supplémentaires comme JavaScript, Go, PHP), les auteurs ont employé :

Validation croisée Leave-One-Language-Out (LOLO) : Les modèles ont été entraînés sur deux langages et validés sur le troisième pour simuler des conditions OOD. Les données d'entraînement ont été équilibrées en échantillonnant un nombre égal d'exemples par langue et par étiquette.
Augmentation du code : Des augmentations stochastiques ont été appliquées pour réduire la dépendance aux caractéristiques de surface spécifiques à la langue, incluant le retrait des commentaires, le masquage des littéraux et la suppression des en-têtes. Une normalisation déterministe a supprimé les barrières markdown et standardisé les espaces blancs.
Inférence par blocs : Puisque le code de test est plus long que le code d'entraînement, les extraits dépassant la fenêtre de contexte du modèle ont été divisés en blocs chevauchants. Les probabilités ont été agrégées en utilisant une moyenne tronquée (éliminant les valeurs min/max) mélangée à une moyenne des 2 meilleurs (moyenne des deux probabilités les plus élevées) pour équilibrer la robustesse face au bruit avec la sensibilité aux signaux forts.
Calibration des seuils : Une calibration en deux étapes a été utilisée. Premièrement, un seuil optimal a été trouvé sur les prédictions OOF. Deuxièmement, un « ensemble de données difficile » de 1 000 exemples mal classés (issus d'une validation croisée de Régression Logistique) a été construit pour dériver un deuxième seuil. Le seuil de décision final était un mélange à poids égal de ces deux seuils, avec des seuils par langue supplémentaires appliqués là où la détection de langue était possible.

Stratégies pour la sous-tâche B (Attribution multi-classes)

Pour gérer le déséquilibre extrême des classes et les longues séquences :

Empaquetage de tokens sandwich : Au lieu de tronquer le code long, la séquence d'entrée a été construite en utilisant les $h$ premiers tokens (tête), un délimiteur, et les $t$ derniers tokens (queue). Pendant l'entraînement, la fraction de tête a été échantillonnée aléatoirement pour servir d'augmentation de données ; pendant l'inférence, elle a été fixée à 0,60.
Perte équilibrée par classe : Pour contrer le déséquilibre 225:1, les auteurs ont utilisé des poids de perte équilibrés par classe basés sur le nombre effectif d'échantillons ( $\beta = 0,9995$ ), accordant un poids plus élevé aux classes sous-représentées sans le surpoids extrême des méthodes d'inverse de fréquence.
Ensemble et augmentation au moment du test (TTA) :
- UniXcoder : Entraîné avec 3 graines aléatoires et exécuté avec 3 fractions de tête différentes pendant l'inférence (9 passages avant au total).
- CodeBERT/GraphCodeBERT : Graine unique avec 3 fractions de tête (3 passages).
- CodeT5+ : Graine unique, fraction de tête fixe, 1 époque d'entraînement en raison de la taille du modèle.

Résultats

Le système a obtenu les scores F1 macro suivants sur l'ensemble de test :

Sous-tâche A : 0,737 (6e place sur 81 équipes) en utilisant CodeBERT.
Sous-tâche B : 0,422 (7e place sur 34 équipes) en utilisant UniXcoder.

Observations clés :

Tous les modèles affinés ont nettement surpassé la ligne de base TF-IDF.
Pour la sous-tâche A, les modèles encodeur uniquement axés sur la compréhension du code (CodeBERT, GraphCodeBERT) ont surpassé le CodeT5+ encodeur-décodeur et l'UniXcoder orienté vers la génération.
Pour la sous-tâche B, UniXcoder a surpassé les autres modèles, attribué à sa fenêtre de contexte plus large (1 024 tokens contre 512), à l'ensemble à 3 graines et à l'utilisation du token de mode <encoder-only>.
L'analyse des erreurs a révélé que les modèles avaient plus de difficultés avec les langages OOD dans la sous-tâche A et avec la distinction de générateurs d'IA stylistiquement similaires dans la sous-tâche B (par exemple, la classe 1 avait un F1 $\le$ 0,11 malgré des données d'entraînement suffisantes).

Importance et contributions

L'article revendique trois contributions techniques principales :

Pipeline d'inférence par blocs : Une méthode pour la classification binaire du code utilisant l'agrégation par moyenne tronquée pour gérer les extraits de code longs dépassant les limites de contexte du modèle.
Stratégie de calibration des seuils : Une approche hybride mélangeant des seuils OOF avec des seuils dérivés d'un « ensemble de données difficile » d'exemples mal classés, affinée davantage par une calibration par langue.
Empaquetage de tokens sandwich : Une stratégie pour l'attribution multi-classes qui préserve l'information du début et de la fin des longues séquences de code, combinée à une augmentation au moment du test et à une perte équilibrée par classe.

Les auteurs concluent que le choix de l'objectif de pré-entraînement est plus critique que la taille du modèle pour ces tâches. Les modèles pré-entraînés pour la compréhension du code (CodeBERT, GraphCodeBERT) ont excellé dans la détection binaire, tandis que l'UniXcoder unifié, amélioré par des fenêtres de contexte plus longues et l'ensemble, a obtenu les meilleurs résultats sur l'attribution multi-classes. L'article note que CodeT5+, bien que le plus grand modèle (220 millions de paramètres), n'a pas obtenu les meilleurs scores, suggérant que la taille seule ne garantit pas la performance dans ce domaine.

Limitations

Les auteurs reconnaissent plusieurs limitations :

L'utilisation de modèles pré-entraînés relativement petits (125M–220M de paramètres) et de fenêtres de contexte limitées (jusqu'à 1 024 tokens).
Le compromis dans l'inférence par blocs entre la couverture et la dilution du signal.
La dépendance à un « ensemble de données difficile » pour la calibration des seuils, qui peut ne pas toujours être disponible dans un déploiement réel.
Un manque d'études d'ablation extensives en raison de contraintes computationnelles, laissant la contribution isolée de composants spécifiques (par exemple, des augmentations ou des méthodes d'agrégation spécifiques) non quantifiée.