💬 NLP

Dream at SemEval-2026 Task 13: SALSA for Single-Pass Machine-Generated Code Detection

L'équipe Dream propose un cadre de classification autorégressif à passage unique de type SALSA, combinant un échantillonnage équilibré et un ajustement fin conservateur pour parvenir à une détection robuste hors distribution du code généré par machine, surpassant de manière significative la référence CodeBERT sur le classement du SemEval-2026 Task 13.

Auteurs originaux : Ruslan Berdichevsky, Shai Nahum-Gefen, Elad Ben-Zaken

Publié 2026-06-25

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Ruslan Berdichevsky, Shai Nahum-Gefen, Elad Ben-Zaken

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 que vous êtes un enseignant essayant de déterminer si le devoir d'un élève a été écrit par l'élève lui-même ou s'il a été copié d'une IA super intelligente. Voici le défi que les auteurs de ce papier ont relevé pour une compétition appelée SemEval-2026 Task 13.

Voici l'histoire de la façon dont ils l'ont résolu, en utilisant des analogies simples :

Le Problème : Le Code « Caméléon »

Par le passé, détecter du code écrit par une IA revenait à essayer de repérer un caméléon dans une forêt. L'IA pouvait écrire du code dans de nombreux langages différents (comme Python, Java ou C++) et pour de nombreuses tâches différentes. Si vous entraîniez un détecteur pour repérer le code IA en Python, il échouait souvent lorsque l'IA passait au Java. Le détecteur était trop « spécialisé » et ne pouvait pas gérer de nouvelles situations inédites.

La Solution : Le Jeu de la « Réponse en un Mot »

L'équipe de Dream Security Ltd. a proposé une nouvelle façon de jouer au jeu, qu'ils appellent SALSA (Single-pass Autoregressive LLM Structured Classification).

Pensez à un chatbot IA normal comme à un perroquet bavard. Si vous lui demandez : « Est-ce que ce code est écrit par une IA ? », il pourrait répondre : « Eh bien, en regardant la syntaxe et les noms de variables, je pense que c'est probablement une IA parce que... » et écrire ensuite tout un paragraphe. C'est désordonné et difficile à noter.

SALSA change les règles :

Le Prompt : Ils donnent un extrait de code à l'IA et lui posent une question très spécifique : « Est-ce généré par une machine ? »
La Contrainte : Ils disent à l'IA : « Tu n'as le droit de répondre qu'avec un seul mot : soit '0' (Non), soit '1' (Oui). »
Le Résultat : Au lieu d'un long essai, l'IA est forcée de faire un choix rapide et décisif. C'est comme demander à un juge de laisser tomber un seul coup de marteau au lieu d'écrire un avis juridique de 10 pages.

L'Entraînement : « Moins, c'est Plus »

Habituellement, quand vous apprenez à un modèle informatique une nouvelle tâche, vous pouvez le faire réviser pendant longtemps jusqu'à ce qu'il mémorise les exemples spécifiques que vous lui avez donnés. Mais les auteurs ont réalisé que si vous faites réviser un modèle trop intensément sur des exemples spécifiques, il oublie comment gérer de nouvelles situations (c'est ce qu'on appelle le « surapprentissage » ou overfitting).

Ils ont utilisé une approche d'« Entraînement Conservateur » :

Le Taux d'Apprentissage : Imaginez que le taux d'apprentissage est le bouton de volume d'une radio. Ils ont baissé le volume très bas. Cela a permis au modèle d'apprendre la nouvelle tâche sans couvrir ses propres connaissances existantes.
La Durée : Ils n'ont laissé le modèle étudier les exemples qu'une seule fois (une époque/epoch). Ils ont constaté qu'étudier trop longtemps rendait le modèle incapable d'être un généraliste et le rendait trop spécialisé dans les données d'entraînement uniquement.
Régime Équilibré : Les données d'entraînement contenaient beaucoup plus de code Python que de Java ou C++. Pour empêcher le modèle de devenir un expert « uniquement en Python », ils l'ont forcé à consommer une quantité égale de chaque langage, même s'il fallait jeter une partie de l'excédent de données Python.

Les Résultats : Battre la Référence

La compétition avait un détecteur de « référence » (CodeBERT) qui était comme un vieux détecteur de métaux rouillé. Il n'obtenait qu'un score de 0,305 (très médiocre) lorsqu'il était testé sur de nouveaux langages inconnus.

Le système SALSA de l'équipe Dream Security était comme un scanner haute technologie et adaptatif.

Zero-Shot (Sans entraînement) : Même sans entraînement spécial, leur IA était correcte (autour de 0,5).
Avec Entraînement : Après leur entraînement minutieux d'« une seule époque », leur meilleur système a atteint un score de 0,789.

C'est un bond massif. Cela signifie que leur système est bien meilleur pour repérer le code généré par l'IA, même lorsque le code est écrit dans un langage ou un style qu'il n'a jamais vu auparavant.

Le Piège

Le papier note une curiosité amusante : avant l'entraînement, l'IA était très timide. Elle avait tellement peur de faire une erreur qu'elle devinait presque toujours « Écrit par un humain » (0), même quand c'était une IA. Cela la faisait paraître très performante en « précision » (quand elle disait que c'était une IA, elle avait raison), mais avec un très mauvais « rappel » (elle passait à côté de presque tout le code IA). L'entraînement a aidé à corriger cette timidité, apprenant au modèle à être assez courageux pour dire « Oui » lorsqu'il voit du code IA.

En bref : Ils ont construit un détecteur qui n'écrit pas d'essais, qui ne mémorise pas le manuel scolaire et qui ne se laisse pas submerger par de nouveaux langages. Il regarde simplement le code, réfléchit une fraction de seconde, et lâche un seul « Oui » ou « Non » précis.

Résumé Technique : SALSA pour la détection de code généré par machine en un seul passage

Définition du Problème
Le papier traite du défi critique de la détection de code généré par les grands modèles de langage (LLM), une tâche essentielle pour maintenir l'intégrité des évaluations et la confiance logicielle. Plus précisément, les auteurs s'attaquent à la SemEval-2026 Task 13 Subtask A, qui cadre le problème comme une tâche de classification binaire (écrit par l'humain vs généré par la machine) sur des extraits de code. La difficulté principale réside dans la généralisation hors distribution (OOD) : le système doit être robuste face à des langages de programmation et des domaines d'application inédits (par exemple, passer de données d'entraînement algorithmiques à des scénarios d'évaluation de recherche ou de production). Les approches traditionnelles reposant sur des caractéristiques faites à la main ou des règles de décision manquent souvent de la couverture de domaine et de la robustesse nécessaires.

Méthodologie : SALSA
Les auteurs proposent SALSA (Single-pass Autoregressive LLM Structured Classification), une formulation qui reformule la classification comme une tâche de génération de jetons (tokens) contrainte plutôt que comme un problème standard de séquence à séquence ou basé sur des caractéristiques.

Prompting Structuré et Cartographie de Jetons :
- Au lieu de permettre au modèle de générer des explications verbeuses ou des formats incohérents, SALSA associe chaque classe à un jeton de sortie unique et dédié (par exemple, « 0 » pour l'humain, « 1 » pour la machine).
- Le prompt est structuré avec des délimiteurs clairs et une instruction directe (par exemple, « le code est-il généré par une machine ? »), exigeant la réponse dans un format spécifique : <ANSWER>#</ANSWER>.
- Pour éviter le raisonnement de type « chaîne de pensée » (chain-of-thought) qui introduit de la latence et de la variance de format, les auteurs utilisent le flag /no_think et un bloc <thought> vide (spécifiquement pour les modèles Qwen3) afin de forcer une sortie à jeton unique.
Stratégie d'Entraînement pour la Robustesse OOD :
- Objectif : Le modèle est entraîné en utilisant un objectif de modélisation de langage causal, mais la perte (loss) est évaluée exclusivement à la position du jeton d'étiquette. Cela concentre les mises à jour de gradient sur la distribution du jeton suivant pour les classes cibles.
- Fine-Tuning Paramétrique Efficace (PEFT) : Les auteurs emploient LoRA (Low-Rank Adaptation) pour réduire les risques de surapprentissage et accélérer l'entraînement.
- Régime d'Entraînement Conservateur : Pour éviter que le modèle ne se spécialise excessivement dans le domaine d'entraînement (ce qui dégrade les performances OOD), les auteurs adoptent une approche conservatrice :
  - Époque Unique : L'entraînement est limité à une seule époque.
  - Taux d'Apprentissage Faible : Un taux de $5 \times 10^{-6}$ est utilisé.
  - Échantillonnage Équilibré : Étant donné le fort biais de l'ensemble de données d'entraînement vers Python (91,5 %), les auteurs implémentent un échantillonnage équilibré entre les groupes (langage, étiquette). Cela empêche le modèle d'apprendre des motifs spécifiques à Python au détriment de l'alignement général de la tâche.
Inférence :
- L'inférence implique un passage direct unique (single forward pass). Le système extrait uniquement les logits pour les jetons de classes cibles (« 0 » et « 1 ») et applique un softmax pour déterminer l'étiquette prédite, minimisant ainsi la surcharge de décodage.

Contributions Clés

Formulation : L'introduction de SALSA, qui convertit la classification en une tâche de prédiction à jeton unique fiable, éliminant la fragilité de la génération ouverte des LLM.
Optimisation OOD : Une démonstration que le fine-tuning conservateur (faible taux d'apprentissage, époque unique, échantillonnage équilibré) préserve les capacités générales du modèle de base, surpassant de manière significative les stratégies d'entraînement agressives dans les contextes OOD.
Performance : Le système obtient une amélioration substantielle par rapport à la ligne de base officielle, comblant l'écart dans la détection de code multi-langage et multi-domaine.

Résultats
Les auteurs ont évalué leur système sur le classement SemEval-2026 :

Comparaison avec la Ligne de Base : La ligne de base officielle CodeBERT a atteint un score F1 OOD de 0,305.
Performance de SALSA : Le meilleur système, utilisant Qwen2.5-72B-Instruct affiné avec SALSA, a atteint un score F1 OOD de 0,789.
Zero-Shot vs Fine-Tuned : La performance zero-shot variait considérablement selon la taille et l'architecture du modèle, certains modèles montrant un fort biais vers la prédiction de code « écrit par l'humain » (haute précision, rappel très faible). Le fine-tuning avec la stratégie conservatrice proposée a résolu ces biais, atteignant un score F1 de validation quasi parfait (0,996) tout en maintenant une forte généralisation OOD.
Mise à l'échelle du Modèle (Scaling) : La performance a généralement suivi la taille du modèle, le modèle de 72 milliards de paramètres surpassant les variantes de 32B et 8B.

Signification
Le papier affirme que SALSA fournit une solution robuste, efficace et évolutive pour la détection de code généré par machine. En déléguant la décision d'auteur au modèle via un prompting structuré et en gérant soigneusement le processus de fine-tuning pour éviter le surapprentissage, l'approche parvient à se généraliser aux langages et domaines non vus. Les résultats suggèrent que préserver les caractéristiques générales du modèle de base par un entraînement conservateur est plus efficace pour les tâches OOD que de maximiser la précision intra-domaine. Les auteurs notent que leur code est disponible publiquement, facilitant ainsi la recherche ultérieure dans ce domaine.

Le Problème : Le Code « Caméléon »

La Solution : Le Jeu de la « Réponse en un Mot »

L'Entraînement : « Moins, c'est Plus »

Les Résultats : Battre la Référence

Le Piège

Articles similaires