💬 NLP

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

Il documento presenta il sistema del team "Archaeology" per il Task 13 di SemEval-2026, che sfrutta modelli di codice pre-addestrati affinati e strategie specializzate come la convalida incrociata leave-one-language-out e il packing a sandwich dei token per ottenere prestazioni di livello superiore nel rilevamento del codice generato dall'intelligenza artificiale e nell'attribuzione della sua fonte.

Autori originali: Jany-Gabriel Ispas, Sergiu Nisioi

Pubblicato 2026-05-05

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Jany-Gabriel Ispas, Sergiu Nisioi

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate un'agenzia investigativa digitale chiamata Archaeology. Il loro compito non è scavare antiche ceramiche, ma setacciare mucchi di codice informatico per rispondere a due grandi domande:

Chi ha scritto questo? È stato un programmatore umano o un robot (AI)?
Quale robot l'ha scritto? Se è stato un robot, quale specifico modello di AI lo ha creato?

Questo team ha partecipato a una competizione ad alto rischio chiamata SemEval-2026 Task 13 per dimostrare le proprie abilità. Ecco come ce l'hanno fatta, spiegato in modo semplice.

La Sfida: Un Mistero in Due Parti

La competizione presentava due enigmi distinti, ognuno richiedente una strategia investigativa diversa.

Enigma A: Il Test "Umano vs Robot" (Classificazione Binaria)

L'Obiettivo: Osservare un pezzo di codice e dire "Umano" o "AI".
La Trappola: Il team è stato addestrato principalmente su codice Python (il 91% dei dati di pratica), ma il test finale includeva linguaggi che non avevano mai visto prima, come JavaScript, Go e C#. È come insegnare a uno chef a cucinare solo cibo italiano, per poi chiedergli di identificare se un piatto è fatto in casa o industriale quando in realtà è un curry thailandese.
L'Indizio: Il codice AI tende ad essere più lungo e uniforme, mentre il codice umano è più corto e caotico. Tuttavia, questa regola si inverte a seconda del linguaggio (ad esempio, in C++, gli umani scrivono effettivamente codice più lungo rispetto all'AI).

Enigma B: Il Test "Quale Robot?" (Attribuzione Multi-Classe)

L'Obiettivo: Se il codice è generato dall'AI, identificare esattamente quale dei 11 diversi modelli di AI lo ha scritto.
La Trappola: I dati erano estremamente sbilanciati. Una categoria (codice scritto da umani) costituiva l'88% dei dati, mentre alcuni modelli AI specifici avevano meno di 2.000 esempi. È come cercare un ago in un pagliaio, dove il pagliaio è per il 99% paglia e gli aghi sono di colori diversi, ma avete solo un ago rosso e un milione di aghi blu.
L'Indizio: Diversi modelli AI hanno sottili stili di "scrittura", ma questi stili sono difficili da individuare in codice lungo e complesso.

Il Corredo dell'Investigatore

Il team non ha solo indovinato; ha utilizzato quattro diversi "super-occhi" (modelli AI pre-addestrati) e ha fornito loro tecniche di addestramento speciali per ogni enigma.

Per l'Enigma A (Umano vs Robot)

L'Esercizio "Scambio di Lingua": Per prepararsi alle lingue a sorpresa nel test, hanno addestrato i modelli nascondendo una lingua alla volta. Hanno insegnato al modello a riconoscere i pattern senza affidarsi a trucchi specifici del linguaggio (come il fatto che Python usa # per i commenti).
L'Allenamento "Pulisci e Maschera": Hanno rimosso i commenti e sostituito i numeri con segnaposto durante l'addestramento. Questo ha costretto i modelli a guardare la logica del codice, non solo le decorazioni superficiali.
La Strategia "A Fette" (Chunking): Poiché il codice di test era spesso troppo lungo per essere letto tutto in una volta, lo hanno tagliato in pezzi sovrapposti (come leggere un libro lungo leggendo poche pagine alla volta). Hanno poi preso la media di queste fette, ignorando le ipotesi più estreme e "rumorose", per prendere una decisione finale.
La Calibrazione "Casi Difficili": Hanno creato un apposito "test difficile" utilizzando esempi che un semplice programma informatico aveva sbagliato. Hanno tarato la loro soglia decisionale (la linea tra "Umano" e "AI") basandosi su questi casi insidiosi per assicurarsi di non essere ingannati dai dati di test.

Per l'Enigma B (Quale Robot?)

La Tecnica "Panino": Poiché il codice era troppo lungo per entrare nella memoria del modello, non hanno semplicemente tagliato via la parte centrale. Invece, hanno mantenuto la Testa (inizio) e la Coda (fine) del codice e le hanno accostate come un panino, con un marcatore speciale nel mezzo. Questo ha preservato lo stile all'inizio e alla fine, dove spesso si nasconde la "firma del robot".
Il Peso "Equità": Poiché alcuni modelli AI erano rari nei dati, il team ha detto al modello: "Non indovinare solo quello più comune! Presta attenzione extra a quelli rari." Hanno aggiustato il sistema di punteggio in modo che il modello imparasse a individuare i robot rari, non solo quelli popolari.
Il Voto della "Saggezza della Folla": Hanno eseguito lo stesso codice attraverso il modello più volte con lievi variazioni e hanno lasciato che i modelli votassero per la risposta. Questo ha ridotto gli errori e aumentato la fiducia.

I Risultati

Il team "Archaeology" ha ottenuto risultati molto buoni:

Enigma A: Hanno ottenuto un punteggio di 0.737, piazzandosi 6° su 81 team. Il loro miglior strumento è stato CodeBERT, che sembrava comprendere la "logica" del codice meglio degli altri.
Enigma B: Hanno ottenuto un punteggio di 0.422, piazzandosi 7° su 34 team. Il loro miglior strumento qui è stato UniXcoder, che ha beneficiato dell'osservazione di pezzi di codice più lunghi e dell'uso della strategia di "voto".

La Grande Lezione

Il team ha scoperto che come un modello è stato addestrato conta più di quanto sia grande.

I modelli più piccoli (125 milioni di parametri) che sono stati addestrati specificamente per comprendere la logica del codice hanno funzionato meglio nell'individuare l'AI.
Il modello gigante (220 milioni di parametri) non ha vinto, suggerendo che per questo lavoro specifico, essere uno "specialista" è meglio che essere un "generalista".

In breve, il team ha dimostrato che con i giusti trucchi di addestramento — come tagliare il codice lungo, ignorare il rumore superficiale e votare sulle risposte — è possibile costruire un sistema sorprendentemente bravo a catturare il codice generato dall'AI, anche quando cerca di mascherarsi in nuovi linguaggi.

Riepilogo Tecnico: Archeologia a SemEval-2026 Task 13

Enunciato del Problema

Il documento affronta la sfida di rilevare il codice sorgente generato dall'intelligenza artificiale, un problema critico per l'integrità accademica, la sicurezza della catena di approvvigionamento del software e l'attribuzione della proprietà intellettuale. Gli autori hanno partecipato al Task 13 di SemEval-2026, suddiviso in tre sottocompiti; il loro sistema, "Archeologia", si è concentrato sui primi due:

Sottocompito-A: Classificazione binaria per distinguere tra codice scritto da umani e codice generato dall'IA.
Sottocompito-B: Attribuzione multiclasse per identificare la specifica famiglia di Modelli Linguistici di Grande Dimensione (LLM) che ha generato un dato frammento di codice tra 11 classi (incluso il codice scritto da umani e 10 modelli AI distinti).

Entrambi i sottocompiti utilizzano il punteggio F1 macro-averaged come metrica di valutazione primaria. I compiti presentano sfide distinte: il Sottocompito-A richiede la generalizzazione a linguaggi di programmazione fuori dominio (OOD) non visti durante l'addestramento, mentre il Sottocompito-B deve gestire distribuzioni di classi estremamente sbilanciate (un rapporto di 225:1 tra la classe più grande e la più piccola) e sequenze di codice lunghe.

Metodologia

Baseline

Il team ha stabilito una baseline utilizzando feature TF-IDF (n-grammi di caratteri da bigrammi a 5-grammi) combinate con Regressione Logistica. Il codice è stato troncato ai primi 10.000 caratteri. Per il Sottocompito-B, sono state applicate pesi di classe bilanciati per mitigare lo sbilanciamento delle etichette. Questa baseline ha ottenuto punteggi macro-F1 di 0,266 (Sottocompito-A) e 0,255 (Sottocompito-B), dimostrando che i pattern lessicali di superficie da soli sono insufficienti.

Modelli Pre-addestrati

Il sistema principale esegue il fine-tuning di quattro modelli di codice pre-addestrati:

CodeBERT: Solo encoder (RoBERTa-base, 125M parametri), pre-addestrato con Masked Language Modeling (MLM) e Rilevamento di Token Sostituiti.
GraphCodeBERT: Solo encoder (RoBERTa-base), che estende CodeBERT con strutture di grafi del flusso di dati.
UniXcoder: Solo encoder (RoBERTa-base), un modello unificato che supporta la comprensione e la generazione tramite obiettivi cross-modali.
CodeT5+: Encoder-decoder (220M parametri), pre-addestrato con denoising e modellazione linguistica causale su coppie di codice e testo-code.

Strategie per il Sottocompito-A (Classificazione Binaria)

Per affrontare la sfida dei linguaggi OOD (addestramento su Python, C++, Java; test su linguaggi aggiuntivi come JavaScript, Go, PHP), gli autori hanno impiegato:

Validazione Incrociata Leave-One-Language-Out (LOLO): I modelli sono stati addestrati su due linguaggi e validati sul terzo per simulare condizioni OOD. I dati di addestramento sono stati bilanciati campionando un numero uguale di esempi per linguaggio ed etichetta.
Augmentation del Codice: Sono state applicate augmentation stocastiche per ridurre la dipendenza da feature di superficie specifiche del linguaggio, inclusa la rimozione dei commenti, il mascheramento dei letterali e l'eliminazione degli header. La normalizzazione deterministica ha rimosso le recinzioni markdown e standardizzato gli spazi bianchi.
Inferenza a Blocchi (Chunked): Poiché il codice di test è più lungo di quello di addestramento, i frammenti che superavano la finestra di contesto del modello sono stati suddivisi in blocchi sovrapposti. Le probabilità sono state aggregate utilizzando una media troncata (rimuovendo i valori minimo/massimo) combinata con una media dei top-2 (mediando le due probabilità più alte) per bilanciare la robustezza al rumore con la sensibilità ai segnali forti.
Calibrazione della Soglia: È stata utilizzata una calibrazione in due fasi. Innanzitutto, è stata trovata una soglia ottimale sulle previsioni OOF (Out-Of-Fold). In secondo luogo, è stato costruito un "dataset difficile" di 1.000 esempi classificati erroneamente (da una validazione incrociata della Regressione Logistica) per derivare una seconda soglia. La soglia decisionale finale è stata una combinazione a peso uguale di queste due, con soglie per linguaggio aggiuntive applicate dove era possibile il rilevamento del linguaggio.

Strategie per il Sottocompito-B (Attribuzione Multiclasse)

Per gestire lo sbilanciamento estremo delle classi e le sequenze lunghe:

Imballaggio a Panino dei Token (Sandwich Token Packing): Invece di troncare il codice lungo, la sequenza di input è stata costruita utilizzando i primi $h$ token (testa), un delimitatore e gli ultimi $t$ token (coda). Durante l'addestramento, la frazione della testa è stata campionata casualmente per agire come augmentation dei dati; durante l'inferenza, è stata fissata a 0,60.
Funzione di Perdita Bilanciata per Classe: Per contrastare lo sbilanciamento 225:1, gli autori hanno utilizzato pesi di perdita bilanciati per classe basati sul numero effettivo di campioni ( $\beta = 0,9995$ ), assegnando un peso maggiore alle classi sottorappresentate senza l'eccessivo aumento di peso dei metodi inversi alla frequenza.
Ensemble e Augmentation al Momento del Test (TTA):
- UniXcoder: Addestrato con 3 semi casuali ed eseguito con 3 diverse frazioni di testa durante l'inferenza (9 passaggi in avanti totali).
- CodeBERT/GraphCodeBERT: Singolo seme con 3 frazioni di testa (3 passaggi).
- CodeT5+: Singolo seme, frazione di testa fissa, 1 epoca di addestramento a causa delle dimensioni del modello.

Risultati

Il sistema ha ottenuto i seguenti punteggi macro-F1 sul set di test:

Sottocompito-A: 0,737 (6º posto su 81 squadre) utilizzando CodeBERT.
Sottocompito-B: 0,422 (7º posto su 34 squadre) utilizzando UniXcoder.

Osservazioni Chiave:

Tutti i modelli con fine-tuning hanno superato significativamente la baseline TF-IDF.
Per il Sottocompito-A, i modelli solo encoder focalizzati sulla comprensione del codice (CodeBERT, GraphCodeBERT) hanno superato CodeT5+ (encoder-decoder) e UniXcoder orientato alla generazione.
Per il Sottocompito-B, UniXcoder ha superato gli altri modelli, attribuito alla sua finestra di contesto più ampia (1.024 token contro 512), all'ensemble a 3 semi e all'uso del token <encoder-only>.
L'analisi degli errori ha rivelato che i modelli hanno faticato di più con i linguaggi OOD nel Sottocompito-A e nel distinguere generatori AI stilisticamente simili nel Sottocompito-B (ad esempio, la Classe 1 ha avuto un F1 $\le$ 0,11 nonostante disponesse di dati di addestramento sufficienti).

Significato e Contributi

Il documento rivendica tre principali contributi tecnici:

Pipeline di Inferenza a Blocchi: Un metodo per la classificazione binaria del codice che utilizza l'aggregazione a media troncata per gestire frammenti di codice lunghi che superano i limiti del contesto del modello.
Strategia di Calibrazione della Soglia: Un approccio ibrido che combina soglie OOF con soglie derivate da un "dataset difficile" di esempi classificati erroneamente, ulteriormente raffinato dalla calibrazione per linguaggio.
Imballaggio a Panino dei Token: Una strategia per l'attribuzione multiclasse che preserva le informazioni dall'inizio e dalla fine di sequenze di codice lunghe, combinata con augmentation al momento del test e funzione di perdita bilanciata per classe.

Gli autori concludono che la scelta dell'obiettivo di pre-addestramento è più critica delle dimensioni del modello per questi compiti. I modelli pre-addestrati per la comprensione del codice (CodeBERT, GraphCodeBERT) hanno eccelluto nel rilevamento binario, mentre UniXcoder unificato, potenziato da finestre di contesto più lunghe e ensemble, ha ottenuto i migliori risultati nell'attribuzione multiclasse. Il documento nota che CodeT5+, nonostante sia il modello più grande (220 milioni di parametri), non ha raggiunto i punteggi più alti, suggerendo che la dimensione da sola non garantisce le prestazioni in questo dominio.

Limitazioni

Gli autori riconoscono diverse limitazioni:

L'uso di modelli pre-addestrati relativamente piccoli (125M–220M parametri) e finestre di contesto limitate (fino a 1.024 token).
Il compromesso nell'inferenza a blocchi tra copertura e diluizione del segnale.
La dipendenza da un "dataset difficile" per la calibrazione della soglia, che potrebbe non essere sempre disponibile nel deployment reale.
La mancanza di studi di ablazione estesi a causa di vincoli computazionali, lasciando non quantificata la contribuzione isolata di componenti specifici (ad esempio, augmentation specifiche o metodi di aggregazione).