💻 computer science

EmbeddedKittens: An Evaluation of Code Embeddings for Scratch

Cet article évalue empiriquement quatre grands modèles de langage et cinq approches de plongement lexical pour les programmes Scratch, démontrant que les modèles entraînés sur de vastes ensembles de données ouverts peuvent capturer efficacement les informations structurelles et sémantiques pour soutenir des tâches d'analyse de l'apprentissage, telles que la prédiction de la correction fonctionnelle dans de petits contextes de classe, sans nécessiter de réglage fin supplémentaire.

Auteurs originaux : Benedikt Fein, Gordon Fraser

Publié 2026-07-22

📖 8 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Benedikt Fein, Gordon Fraser

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 essayez d'apprendre à un robot super intelligent à comprendre le langage humain. Vous lui donnez des millions de livres, de films et de sites web, et finit par il apprend à prédire le mot suivant dans une phrase avec une précision incroyable. C'est la magie des Grands Modèles de Langage (LLM). Maintenant, imaginez que vous vouliez que ce même robot comprenne le code source — les instructions que les programmeurs écrivent pour dire aux ordinateurs quoi faire. Puisque le code ressemble un peu à un langage étrange et structuré, les chercheurs ont découvert que ces robots peuvent aussi apprendre à le comprendre, aidant ainsi les développeurs à écrire des logiciels plus rapidement ou même à corriger des bugs automatiquement.

Mais voici le rebondissement : tous les codes ne ressemblent pas à du texte. À l'école, beaucoup d'enfants apprennent à programmer en utilisant Scratch, un système coloré de blocs basé sur des pièces que l'on emboîte sur un écran au lieu de taper des lignes de texte. C'est comme construire avec des briques Lego plutôt que d'écrire une histoire. La grande question pour les scientifiques est la suivante : ces mêmes « cerveaux de robots » qui lisent du code textuel peuvent-ils aussi comprendre ces puzzles visuels de blocs ? Et si oui, quelle méthode fonctionne le mieux ? Cela importe car si nous pouvons apprendre aux robots à comprendre Scratch, nous pourrions construire des outils pour aider les enseignants à noter les devoirs, à repérer les élèves en difficulté ou à donner des indices instantanés, rendant l'apprentissage du code beaucoup plus fluide pour la prochaine génération.

Le Grand Défi du Traducteur de Code

Dans cette étude, les chercheurs Benedikt Fein et Gordon Fraser ont entrepris de répondre à une question délicate : Pouvons-nous apprendre aux ordinateurs à « comprendre » les programmes Scratch suffisamment bien pour les aider dans une salle de classe ? Ils ne se sont pas contentés de deviner ; ils ont construit un terrain de jeu numérique pour tester différents types de « traducteurs de code ».

Considérez un traducteur de code comme un moyen de transformer un programme Scratch complexe en un seul nombre secret (ou un « vecteur ») qui capture l'essence du programme. Si deux programmes sont similaires, leurs nombres secrets devraient être proches l'un de l'autre. S'ils sont différents, les nombres devraient être éloignés. Les chercheurs voulaient voir quel traducteur était le meilleur à ce jeu.

Les Contendants

Ils ont aligné cinq types différents de traducteurs pour la compétition :

Les Lecteurs « Plats » : Ces modèles traitent le code comme une simple liste de mots, ignorant la structure. C'est comme lire une recette en ignorant le fait que certaines étapes se déroulent dans un « bol de mélange » et d'autres sur une « cuisinière ».
Les Lecteurs en « Arbre » : Ces modèles regardent la structure du code, comme un arbre généalogique d'instructions. Ils comprennent que certains blocs sont imbriqués dans d'autres.
Les Lecteurs de « Flux » : Ce sont les plus avancés. Ils ne voient pas seulement la structure ; ils suivent la façon dont l'information circule à travers le programme, comme si l'on observait l'eau couler dans des tuyaux. Ils savent si une variable change dans un bloc et est utilisée dans un autre.
Les « Gros Cerveaux » (LLM) : Ce sont les modèles d'IA géants et pré-entraînés (comme ceux qui alimentent les chatbots) qui ont déjà lu des millions de documents textuels. Les chercheurs leur ont demandé de regarder du code Scratch et de deviner ce qu'il faisait.

Le Test : Nommer les Personnages

Pour tester ces traducteurs, les chercheurs ont créé un jeu appelé « Nommage de Sprite ». Dans Scratch, chaque personnage (ou « sprite ») a un nom. La tâche était simple : montrer au modèle le code à l'intérieur d'un sprite, et lui demander de deviner le nom du sprite. C'est comme montrer le journal intime d'un personnage à quelqu'un et lui demander : « Quel est le nom de ce personnage ? »

Les résultats ont montré une hiérarchie claire. Les vainqueurs étaient les lecteurs de « Flux » (plus précisément un modèle appelé GGNN). En prêtant attention à la façon dont les blocs se connectent et dont les données circulent entre eux, ces modèles étaient bien meilleurs pour comprendre l'« histoire » du code. Ils devinaient le nom du sprite avec une précision nettement supérieure aux autres.

Les géants « Gros Cerveaux » (LLM) et les lecteurs « Plats » ont mal performé sur cette tâche de nommage spécifique. Ils ont eu du mal à deviner les noms corrects car les programmes Scratch utilisent rarement les noms de variables sophistiqués ou les fonctions personnalisées que ces grands modèles ont l'habitude de voir dans le code textuel. Au lieu de cela, Scratch repose lourdement sur la structure des blocs et sur la façon dont ils se connectent. Cependant, il est important de noter que même le modèle de « Flux » gagnant n'était pas parfait ; il faisait encore des erreurs, ce qui signifie qu'aucun modèle n'était un oracle sans faille. Les LLM n'étaient pas les seuls à ne pas atteindre des scores parfaits, mais ils étaient systématiquement dépassés par les modèles qui comprenaient la structure et le flux du programme.

La Barrière de la Langue

Les chercheurs ont également testé si la langue utilisée par les étudiants importait. Scratch est utilisé partout dans le monde, au Brésil, en Chine, en Pologne et dans de nombreux autres endroits. Ils ont constaté que les modèles fonctionnaient mieux lorsque le code était écrit en anglais ou dans d'autres langues utilisant l'alphabet latin (comme A, B, C). Lorsque le code utilisait d'autres systèmes d'écriture (comme les caractères chinois ou le cyrillique russe), les modèles étaient confus. Cela suggère que pour que ces outils fonctionnent mondialement, ils doivent devenir meilleurs pour comprendre les différentes langues et symboles, pas seulement l'anglais.

Du Nommage à la Notation : Pouvons-nous utiliser cela en classe ?

La véritable magie est intervenue ensuite. Les chercheurs ont demandé : « Si ces modèles sont bons pour nommer des sprites, peuvent-ils aussi aider les enseignants ? »

Ils ont testé deux grandes idées :

Vérification de la Correction : Un modèle peut-il regarder le programme désordonné d'un étudiant et dire s'il fonctionne, même sans l'exécuter ? Ils ont trouvé un lien fort entre la « compréhension » du code par le modèle et le fait que le code passe effectivement les tests. Si le modèle pensait que le code était « proche » de la solution, le code fonctionnait généralement. Cela signifie que ces modèles pourraient agir comme un « substitut » pour vérifier les devoirs instantanément.
Suivi de la Progression : Un modèle peut-il montrer à quel point un étudiant s'est amélioré ? Ils ont utilisé une carte spéciale pour tracer la progression des étudiants. À mesure que les étudiants ajoutaient des fonctionnalités à leurs jeux, leur « carte de code » se rapprochait de la solution finale. Les modèles ont réussi à suivre ce voyage, montrant aux enseignants exactement où un étudiant était bloqué ou jusqu'où il était arrivé.

Étonnamment, pour ces tâches plus larges (comme classer le type de projet ou suivre la progression), les LLM ont en fait très bien performé, égalant parfois ou dépassant les modèles structurels spécialisés. Cela suggère que si les LLM peuvent manquer les petits détails structurels nécessaires pour nommer un personnage spécifique, ils sont très bons pour comprendre la « vue d'ensemble » d'un projet.

Le Verdict

L'étude conclut que oui, il est possible d'utiliser des plongements de code (embeddings) pour Scratch, mais il faut choisir le bon outil pour la tâche. Pour les tâches nécessitant une compréhension structurelle profonde (comme nommer un sprite), les modèles spécialisés qui comprennent le flux et la structure des blocs sont les champions. Les géants chatbots (LLM) ne sont pas le meilleur choix pour ces puzzles spécifiques car ils passent à côté des détails structurels sur lesquels Scratch repose.

Cependant, pour les tâches éducatives plus larges comme la notation ou le suivi de la progression, les LLM sont étonnamment efficaces et peuvent être tout aussi bons que les modèles spécialisés. Mieux encore, ces modèles spécialisés, une fois entraînés, peuvent être utilisés pour d'autres tâches — comme la notation ou le suivi de la progression — sans avoir besoin d'être réentraînés pour chaque nouvel devoir. C'est une victoire majeure pour les enseignants, car cela signifie qu'ils pourraient disposer d'outils automatisés puissants pour aider les étudiants, même dans de petites classes où les données ne sont pas suffisantes pour entraîner un nouvel IA à partir de zéro.

En bref, les chercheurs ont trouvé un moyen de donner aux ordinateurs un « sens » du code Scratch qui va au-delà de la simple lecture de mots. En comprenant la forme et le flux des blocs, ces modèles peuvent nous aider à construire un avenir plus intelligent et plus stimulant pour l'enseignement de la programmation.

Résumé technique : EmbeddedKittens : Une évaluation des plongements de code pour Scratch

Énoncé du problème

La prolifération des plongements de code (code embeddings) et des grands modèles de langage (LLM) a transformé le génie logiciel et l'analyse éducative, particulièrement pour les langages textuels comme Python et Java. Cependant, leur application aux environnements de programmation visuelle par blocs comme Scratch reste une question ouverte. Scratch présente des défis uniques :

Différences structurelles : Le code Scratch se compose de blocs visuels librement positionnables plutôt que de séquences de jetons linéaires, et repose fortement sur l'exécution concurrente et la messagerie événementielle entre les « sprites », ce que les plongements textuels standards peuvent échouer à capturer.
Diversité linguistique : La communauté Scratch est hautement internationale, avec des utilisateurs employant diverses langues naturelles pour les identifiants, les commentaires et les éléments de l'interface utilisateur. Les modèles standards supposent souvent des identifiants centrés sur l'anglais.
Rareté des données pour l'éducation : Les benchmarks courants de plongement de code (ex: nommage de méthodes, génération de documentation) sont irréalisables pour Scratch en raison de l'absence de commentaires et de documentation dans les projets des étudiants. De plus, les ensembles de données de classe sont typiquement trop petits pour entraîner des modèles spécifiques à partir de zéro.

Le problème central est de déterminer quelle approche de plongement de code est la plus appropriée pour l'analyse de l'apprentissage dans Scratch, spécifiquement si les modèles peuvent capturer l'information structurelle et sémantique sans un réglage fin (fine-tuning) intensif dans des contextes éducatifs où les données sont rares.

Méthodologie

Les auteurs, Benedikt Fein et Gordon Fraser, ont mené une évaluation empirique impliquant quatre questions de recherche (RQ) pour évaluer la faisabilité et la performance de diverses approches de plongement.

1. Prétraitement des données et représentation

Les auteurs ont utilisé LitterBox pour analyser les projets Scratch (format JSON) en arbres de syntaxe abstraite (AST). Ils ont implémenté EmbeddedKittens, un outil de prétraitement, pour convertir le code Scratch en formats adaptés à différentes architectures de modèles :

Séquences de jetons plates (Flat Token Sequences) : Utilisées pour NeuralCodeSum (Transformer) et les LLM (GPT-5-mini, DeepSeek Coder v2, Mistral Small 3.1, Gemma 3). L'AST a été parcouru en profondeur (depth-first) pour créer une représentation textuelle (ex: motion_movesteps(10)). Pour les LLM, le format ScratchBlocks a été utilisé, car il s'aligne mieux avec leurs données de pré-entraînement.
Chemins d'AST (AST Paths) : Utilisés pour code2vec et code2seq, représentant le code comme des ensembles de chemins entre les nœuds feuilles de l'AST.
Sous-arbres d'instructions (Statement Subtrees) : Utilisés pour ASTNN, découpant l'AST en sous-arbres par instruction, encodés par un GRU bidirectionnel.
Graphes de flux de contrôle/données (Control/Data Flow Graphs) : Utilisés pour GGNN (Gated Graph Neural Network). Cette approche étend l'AST avec des arêtes sémantiques représentant le flux de données (LastRead, LastWrite, ComputedFrom), le flux de contrôle (GuardedBy), et la gestion des événements spécifique à Scratch (diffusion de messages entre les sprites).

2. Tâches expérimentales

RQ1 (Nommage de Sprite) : Une tâche de référence où les modèles prédisent le nom d'un sprite à partir de son code. Cela sert de proxy pour la résumé de code, car les projets Scratch manquent de noms de méthodes ou de documentation.
RQ2 (Internationalité) : Évaluation de la performance des modèles à travers 10 langues naturelles différentes (incluant des scripts non latins comme le chinois, le japonais et le russe) pour évaluer l'impact de la diversité linguistique.
RQ3 (Classification de programme) : Ajustement fin (fine-tuning) des plongements de sprites pré-entraînés pour classifier des programmes entiers par catégorie (ex: jeu, animation) ou par leur projet de base (classification de remix).
RQ4 (Estimation de la correction) : Utilisation des plongements comme modèle de substitution pour estimer la correction fonctionnelle des programmes d'étudiants en mesurant la distance vers une « solution modèle » dans l'espace d'embedding, comparée aux résultats réels des suites de tests.
RQ5 (Suivi de progression) : Application de la technique de « projection de variance de progression » pour visualiser la progression des étudiants au fil du temps en utilisant les plongements, en cartographiant la distance par rapport à un projet de départ vers une solution.

3. Modèles évalués

Modèles de plongement dédiés : NeuralCodeSum, code2vec, code2seq, ASTNN, GGNN.
LLM pré-entraînés : GPT-5-mini, DeepSeek Coder v2, Mistral Small 3.1, Gemma 3, et Qwen 3 Embedding.

Contributions clés

Évaluation systématique : La première comparaison structurée de cinq approches de plongement de code et de quatre LLM spécifiquement pour le domaine de Scratch.
Tâche de nommage de sprite : L'introduction d'une nouvelle tâche de « nommage de sprite » pour servir de base au résumé de code dans Scratch, surmontant l'absence de benchmarks traditionnels.
Analyse multilingue : La création et l'évaluation d'ensembles de données à travers 10 langues distinctes, soulignant les disparités de performance dans les environnements de scripts non latins.
Applicabilité éducative : Démonstration que les plongements pré-entraînés peuvent être transférés à des tâches éducatives (estimation de la correction, suivi de la progression) sans fine-tuning spécifique à la tâche, répondant ainsi au problème de la rareté des données en classe.
Outils Open Source : La publication de EmbeddedKittens, un outil de prétraitement pour convertir le code Scratch en divers formats prêts pour l'embedding.

Résultats

RQ1 : Résumé de code (Nommage de Sprite)

L'information structurelle est critique : Les modèles incorporant des informations structurelles et de flux de contrôle ont nettement surpassé ceux utilisant des séquences de jetons plates. GGNN a obtenu la meilleure performance (F1 = 0,550), suivi de ASTNN (F1 = 0,342).
Limites des LLM : Les LLM pré-entraînés ont mal performé (F1 ≤ 0,081) sur la tâche spécifique de génération de noms de sprites, probablement parce que Scratch manque des procédures personnalisées et des noms de variables sur lesquels les LLM comptent typiquement pour l'inférence dans les langages textuels.
Discrépance de métrique : Bien que GGNN ait obtenu des scores BLEU élevés, ses scores ROUGE-2 étaient plus bas, suggérant qu'il génère souvent des sous-tokens corrects mais dans un ordre incorrect ou avec des répétitions.

RQ2 : Internationalité

Biais linguistique : Les modèles ont mieux performé sur l'anglais et les autres langues basées sur l'alphabet latin. La performance a chuté significativement pour les scripts non latins (ex: coréen, russe, chinois).
Problèmes de tokenisation : Les auteurs attribuent la faible performance sur les scripts non latins à la stratégie de sous-tokenisation (découpage sur les espaces ou le camel case), qui est inefficace pour les scripts sans ces délimiteurs.
Rareté des données : La faible performance dans les langues ayant moins d'utilisateurs de Scratch (ex: coréen) est liée à la rareté des données d'entraînement dans ces langues spécifiques.

RQ3 : Classification de programme

Transférabilité : Les plongements de sprites pré-entraînés (spécifiquement GGNN et Qwen 3 Embedding) peuvent être efficacement ajustés pour la classification de programmes.
Performance des LLM : Étonnamment, Qwen 3 Embedding (une approche basée sur les LLM) a surpassé le modèle dédié GGNN pour la classification de catégories de programmes (F1 = 0,562 contre 0,475), suggérant que pour la catégorisation de haut niveau, la similitude sémantique capturée par les LLM est suffisante, même si les détails structurels sont moins critiques.
Robustesse : Les plongements GGNN et basés sur les LLM forment des clusters robustes, identifiant correctement les remix de projets de base avec une grande précision (>97 %).

RQ4 & RQ5 : Correction et Progression

Validité du substitut : Une corrélation linéaire statistiquement significative a été trouvée entre la fitness basée sur l'embedding (distance à la solution) et la fitness réelle de la suite de tests. Cela confirme que les plongements pré-entraînés capturent l'information sémantique et structurelle pertinente pour la correction.
Visualisation de la progression : Les plongements ont réussi à cartographier la progression des étudiants dans un espace 2D. GGNN et Qwen-whole (LLM traitant le programme entier) ont montré de fortes corrélations avec la progression réelle ( $R^2 \approx 0,7$ ), tandis que l'agrégation par sprite avec les LLM était moins efficace.
Aucun fine-tuning requis : Crucialement, ces résultats ont été obtenus en utilisant des modèles pré-entraînés uniquement sur la tâche de nommage de sprite, sans fine-tuning supplémentaire pour la correction ou la progression, validant leur utilité dans les contextes de classe à faibles données.

Signification et affirmations

L'article affirme que les plongements de code sont réalisables et efficaces pour Scratch, à condition que les modèles prennent en compte la complexité structurelle du langage.

Rôles complémentaires : Les auteurs proposent un modèle d'utilisation complémentaire :
- Modèles structurels dédiés (ex: GGNN) : Mieux adaptés aux tâches nécessitant des insights structurels profonds, comme la détection de bugs ou la génération d'indices pour l'étape suivante, et peuvent être déployés localement avec une faible surcharge de ressources.
- LLM pré-entraînés : Mieux adaptés aux tâches de haut niveau impliquant la similitude sémantique, comme la recommandation de projets ou l'estimation de la progression, en tirant parti de leur pré-entraînement large mais nécessitant plus de ressources de calcul.
Impact éducatif : L'étude démontre que les plongements pré-entraînés peuvent servir de « modèles de substitution » pour l'analyse de l'apprentissage dans des environnements où la collecte de grands ensembles de données étiquetées pour un entraînement spécifique à la tâche est impossible. Cela permet des outils tels que la notation automatisée, le suivi de la progression et l'estimation de la difficulté des exercices dans des contextes de classe typiques.
Directions futures : Les auteurs suggèrent modestement que les travaux futurs devraient explorer une meilleure tokenisation pour les scripts non latins, l'intégration de l'information visuelle (positions des blocs), et l'adaptation de ces concepts à d'autres systèmes événementiels.

L'article conclut que bien que le transfert des plongements de code vers Scratch soit un succès, le choix d'un modèle dépend fortement de l'application éducative spécifique et des ressources de calcul disponibles.