Riepilogo Tecnico: EmbeddedKittens: Una valutazione degli embedding di codice per Scratch

Definizione del Problema

La proliferazione di embedding di codice e di Large Language Models (LLM) ha trasformato l'ingegneria del software e l'analisi educativa, in particolare per i linguaggi testuali come Python e Java. Tuttavia, la loro applicazione ad ambienti di programmazione visuali basati su blocchi come Scratch rimane una questione aperta. Scratch presenta sfide uniche:

1. Differenze Strutturali: Il codice Scratch consiste in blocchi visuali posizionabili liberamente piuttosto che in sequenze lineari di token, e si basa fortemente sull'esecuzione concorrente e sulla messaggistica guidata da eventi tra gli "sprite", aspetti che gli standard embedding testuali potrebbero non catturare.
2. Diversità Linguistica: La comunità di Scratch è altamente internazionale, con utenti che utilizzano diversi linguaggi naturali per identificatori, commenti ed elementi dell'interfaccia utente. I modelli standard spesso assumono identificatori centrati sull'inglese.
3. Scarsità di Dati per l'Educazione: I comuni benchmark per gli embedding di codice (ad es. denominazione di metodi, generazione di documentazione) sono impraticabili per Scratch a causa della mancanza di commenti e documentazione nei progetti degli studenti. Inoltre, i dataset scolastici sono tipicamente troppo piccoli per addestrare modelli specifici per il compito partendo da zero.

Il problema centrale è determinare quale approccio di embedding di codice sia più adatto all'analisi dell'apprendimento in Scratch, specificamente se i modelli possano catturare informazioni strutturali e semantiche senza un fine-tuning esteso in contesti educativi caratterizzati da scarsità di dati.

Metodologia

Gli autori, Benedikt Fein e Gordon Fraser, hanno condotto una valutazione empirica coinvolgendo quattro domande di ricerca (RQ) per valutare la fattibilità e le prestazioni di vari approcci di embedding.

1. Pre-elaborazione dei Dati e Rappresentazione

Gli autori hanno utilizzato LitterBox per analizzare i progetti Scratch (formato JSON) in Alberi della Sintassi Astratta (AST). Hanno implementato EmbeddedKittens, uno strumento di pre-elaborazione, per convertire il codice Scratch in formati adatti a diverse architetture di modelli:

• Sequenze di Token Piatti: Utilizzate per NeuralCodeSum (Transformer) e LLM (GPT-5-mini, DeepSeek Coder v2, Mistral Small 3.1, Gemma 3). L'AST è stato attraversato con una ricerca depth-first per creare una rappresentazione testuale (ad es. motion_movesteps(10)). Per gli LLM, è stato utilizzato il formato ScratchBlocks, poiché si allinea meglio ai loro dati di pre-addestramento.
• Percorsi AST: Utilizzati per code2vec e code2seq, rappresentando il codice come insiemi di percorsi tra i nodi foglia dell'AST.
• Sottotree di Istruzioni: Utilizzati per ASTNN, suddividendo l'AST in sottotree per ogni istruzione, codificate da una GRU bidirezionale.
• Grafi di Flusso di Controllo/Dati: Utilizzati per GGNN (Gated Graph Neural Network). Questo approccio ha esteso l'AST con archi semantici che rappresentano il flusso di dati (LastRead, LastWrite, ComputedFrom), il flusso di controllo (GuardedBy) e la gestione degli eventi specifica di Scratch (trasmissione di messaggi tra sprite).

2. Task Sperimentali

• RQ1 (Denominazione Sprite): Un task di baseline in cui i modelli prevedono il nome di uno sprite basandosi sul suo codice. Questo funge da proxy per la sintesi del codice, dato che i progetti Scratch mancano di nomi di metodi o documentazione.
• RQ2 (Internazionalità): Valutazione delle prestazioni del modello attraverso 10 lingue naturali diverse (inclusi script non latini come cinese, giapponese e russo) per valutare l'impatto della diversità linguistica.
• RQ3 (Classificazione del Programma): Fine-tuning di embedding di sprite pre-addestrati per classificare interi programmi per categoria (ad es. gioco, animazione) o in base al loro progetto originale (classificazione dei remix).
• RQ4 (Stima della Correttezza): Utilizzo degli embedding come modello surrogato per stimare la correttezza funzionale dei programmi degli studenti, misurando la distanza da una "soluzione modello" nello spazio degli embedding, rispetto ai risultati effettivi delle suite di test.
• RQ5 (Monitoraggio dei Progressi): Applicazione della tecnica "progress-variance-projection" per visualizzare i progressi degli studenti nel tempo utilizzando gli embedding, mappando la distanza da un progetto iniziale verso una soluzione.

3. Modelli Valutati

• Modelli di Embedding Dedicati: NeuralCodeSum, code2vec, code2seq, ASTNN, GGNN.
• LLM Pre-addestrati: GPT-5-mini, DeepSeek Coder v2, Mistral Small 3.1, Gemma 3, e Qwen 3 Embedding.

Contributi Chiave

1. Valutazione Sistematica: La prima comparazione strutturata di cinque diversi approcci di embedding di codice e quattro LLM specificamente per il dominio Scratch.
2. Task di Denominazione Sprite: L'introduzione di un nuovo task di "denominazione sprite" per servire come baseline per la sintesi del codice in Scratch, superando la mancanza di benchmark tradizionali.
3. Analisi Multilingue: La creazione e la valutazione di dataset attraverso 10 lingue distinte, evidenziando le disparità di prestazione negli ambienti con script non latini.
4. Applicabilità Educativa: Dimostrazione che gli embedding pre-addestrati possono essere trasferiti a compiti educativi (stima della correttezza, monitoraggio dei progressi) senza fine-tuning specifico per il task, affrontando il problema della scarsità di dati nelle classi.
5. Strumentazione Open Source: Il rilascio di EmbeddedKittens, uno strumento di pre-elaborazione per convertire il codice Scratch in vari formati pronti per l'embedding.

Risultati

RQ1: Sintesi del Codice (Denominazione Sprite)

• L'Informazione Strutturale è Critica: I modelli che incorporano informazioni strutturali e di flusso di controllo hanno superato significativamente quelli che utilizzano sequenze di token piatti. GGNN ha ottenuto le migliori prestazioni (F1 = 0.550), seguito da ASTNN (F1 = 0.342).
• Limitazioni degli LLM: Gli LLM pre-addestrati hanno performato scarsamente (F1 ≤ 0.081) sul compito specifico di generare nomi di sprite, probabilmente perché Scratch manca delle procedure personalizzate e dei nomi di variabili su cui gli LLM solitamente si affidano per l'inferenza nei linguaggi testuali.
• Discrepanza delle Metriche: Sebbene GGNN abbia ottenuto punteggi BLEU elevati, i suoi punteggi ROUGE-2 erano inferiori, suggerendo che spesso generava subtoken corretti ma in ordini errati o con ripetizioni.

RQ2: Internazionalità

• Bias Linguistico: I modelli hanno performato meglio su inglese e altre lingue basate su alfabeto latino. Le prestazioni sono diminuite significativamente per gli script non latini (es. coreano, russo, cinese).
• Problemi di Tokenizzazione: Gli autori attribuiscono la scarsa prestazione sugli script non latini alla strategia di subtokenizzazione (divisione su spazi bianchi/camel case), inefficace per gli script privi di tali delimitatori.
• Scarsità di Dati: La bassa prestazione nelle lingue con meno utenti Scratch (es. coreano) è stata collegata alla scarsità di dati di addestramento in quelle specifiche lingue.

RQ3: Classificazione del Programma

• Trasferibilità: Gli embedding di sprite pre-addestrati (specificamente GGNN e Qwen 3 Embedding) potevano essere efficacemente sottoposti a fine-tuning per la classificazione dei programmi.
• Prestazioni degli LLM: Sorprendentemente, Qwen 3 Embedding (un approccio basato su LLM) ha superato il modello dedicato GGNN nella classificazione delle categorie di programmi (F1 = 0.562 vs 0.475), suggerendo che per la categorizzazione di alto livello, la somiglianza semantica catturata dagli LLM è sufficiente, anche se i dettagli strutturali sono meno critici.
• Robustezza: Sia gli embedding GGNN che quelli basati su LLM hanno formato cluster robusti, identificando correttamente i remix dei progetti base con un'alta precisione (>97%).

RQ4 & RQ5: Correttezza e Progressi

• Validità del Surrogato: È stata trovata una correlazione lineare statisticamente significativa tra la fitness basata su embedding (distanza dalla soluzione) e la fitness effettiva della suite di test. Ciò conferma che gli embedding pre-addestrati catturano informazioni semantiche e strutturali rilevanti per la correttezza.
• Visualizzazione dei Progressi: Gli embedding hanno mappato con successo i progressi degli studenti in uno spazio 2D. GGNN e Qwen-whole (LLM che elabora l'intero programma) hanno mostrato forti correlazioni con il progresso effettivo ($R^2 \approx 0.7$), mentre l'aggregazione per sprite con gli LLM è stata meno efficace.
• Nessun Fine-Tuning Richiesto: Fondamentalmente, questi risultati sono stati ottenuti utilizzando modelli pre-addestrati solo sul task di denominazione sprite, senza ulteriore fine-tuning per correttezza o progressi, validando la loro utilità in contesti classroom con pochi dati.

Significato e Rivendicazioni

Il documento sostiene che gli embedding di codice sono fattibili ed efficaci per Scratch, a condizione che i modelli tengano conto della complessità strutturale del linguaggio.

• Ruoli Complementari: Gli autori propongono un modello di utilizzo complementare:
  • Modelli Strutturali Dedicati (es. GGNN): Più adatti a compiti che richiedono approfondimenti strutturali profondi, come il rilevamento di bug o la generazione di suggerimenti per il passo successivo, e possono essere implementati localmente con un basso carico di risorse.
  • LLM Pre-addestrati: Più adatti a compiti di alto livello che coinvolgono la somiglianza semantica, come la raccomandazione di progetti o la stima dei progressi, sfruttando il loro ampio pre-addestramento ma richiedendo maggiori risorse computazionali.
• Impatto Educativo: Lo studio dimostra che gli embedding pre-addestrati possono fungere da "modelli surrogati" per l'analisi dell'apprendimento in ambienti dove la raccolta di grandi dataset etichettati per l'addestramento di task specifici è impossibile. Ciò abilita strumenti come la valutazione automatizzata, il monitoraggio dei progressi e la stima della difficoltà degli esercizi nelle tipiche situazioni scolastiche.
• Direzioni Future: Gli autori suggeriscono modestamente che il lavoro futuro dovrebbe esplorare una migliore tokenizzazione per gli script non latini, l'integrazione delle informazioni visuali (posizioni dei blocchi) e l'adattamento di questi concetti ad altri sistemi guidati da eventi.

Il documento conclude che, sebbene il trasferimento degli embedding di codice a Scratch sia un successo, la scelta del modello dipende fortemente dall'applicazione educativa specifica e dalle risorse computazionali disponibili.