🤖 machine learning

mcdok at SemEval-2026 Task 13: Finetuning LLMs for Detection of Machine-Generated Code

Il paper descrive l'adattamento dell'approccio mdok per la rilevazione di codice generato da macchine al SemEval-2026 Task 13, ottenendo risultati competitivi in tutti i sottocompiti ma evidenziando margini significativi di miglioramento rispetto ai sistemi leader.

Autori originali: Adam Skurla, Dominik Macko, Jakub Simko

Pubblicato 2026-04-24

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Adam Skurla, Dominik Macko, Jakub Simko

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

Immagina di essere un detective che deve scoprire se un'opera d'arte è stata dipinta da un umano o da un robot. Ora, invece di quadri, il "campo di battaglia" è il codice informatico (quello che fa funzionare i programmi e i siti web).

Questo paper racconta la storia di un team di ricercatori (mcdok) che ha partecipato a una grande gara internazionale chiamata SemEval-2026 Task 13. L'obiettivo? Costruire un "detective digitale" capace di capire se un pezzo di codice è stato scritto da una persona o generato da un'intelligenza artificiale (LLM).

Ecco come hanno lavorato, spiegato con parole semplici e qualche metafora:

1. La Missione: Tre Sfide Diverse

La gara non era una sola, ma divisa in tre livelli di difficoltà, come in un videogioco:

Livello A (Il Semplice "Sì/No"): Il detective deve solo dire: "Questo codice è umano o è stato scritto da un'IA?". È come guardare un'immagine e dire "è un gatto o un cane?".
Livello B (L'Identikit): Qui è più difficile. Non basta dire che è un'IA, bisogna capire quale IA l'ha scritto. Ci sono 10 "famiglie" di robot diversi (come se dovessi dire se il codice è stato scritto da "Google", "OpenAI" o "Meta"). È come riconoscere la firma di un autore specifico tra 11 possibili candidati.
Livello C (Il Camaleonte): Questa è la sfida più subdola. Il codice può essere:
1. Umano puro.
2. IA pura.
3. Ibrido: Una parte fatta da un umano e completata da un'IA (come un assistente che ti aiuta a scrivere).
4. Adversariale: Un'IA che ha cercato di ingannare il detective, modificando il codice per sembrare umano.

2. L'Arsenale: Non un Detective, ma una Squadra

I ricercatori non hanno creato un nuovo detective da zero. Hanno preso un vecchio amico, un sistema chiamato mdok (che era bravo a riconoscere testi scritti da IA), e gli hanno dato una "trasformazione" per capire il codice.

Hanno creato tre versioni diverse del loro sistema, chiamandole mcdok, e hanno scelto "cervelli" (modelli base) diversi per ogni missione, proprio come un allenatore sceglie giocatori diversi per ruoli diversi:

Per il Livello A, hanno usato un modello generico ma potente (Gemma-3) che, stranamente, si è rivelato il migliore per capire la differenza tra umano e macchina.
Per il Livello B (riconoscere le famiglie), hanno usato un modello specializzato in codice (CodeGemma).
Per il Livello C (il camaleonte), hanno scelto un altro esperto di codice (Qwen2.5-Coder).

3. Il Metodo: Addestramento Intelligente

Come si addestra un detective?

Non hanno "imbrattato" il codice: A differenza di quando si analizza un testo normale (dove si toglie la punteggiatura o si mettono le lettere minuscole), qui non potevano toccare nulla. Il codice è come un'equazione matematica: se cambi un simbolo, smette di funzionare.
Hanno usato un trucco: Invece di far studiare il modello con migliaia di esempi alla volta, lo hanno fatto studiare un esempio alla volta, molto lentamente e con attenzione (una tecnica chiamata QLoRA), per non "confonderlo".
Hanno bilanciato la dieta: Hanno fatto in modo che il detective vedesse un numero uguale di esempi umani e di IA, altrimenti si sarebbe abituato a dire sempre "è umano" perché ce n'erano di più.

4. Il Risultato: Bravi, ma non Perfetti

Alla fine della gara, i loro detective hanno fatto un ottimo lavoro:

Hanno battuto i "principianti" (i modelli di base chiamati baselines).
Si sono piazzati nella top 10% per la sfida più difficile (Livello C).
Hanno dimostrato che un detective fatto per i testi può imparare a fare il detective per il codice, basta dargli gli strumenti giusti.

Ma c'è un "ma":
Non sono stati i primi in classifica. C'era un margine di miglioramento. A volte il detective si confondeva, specialmente quando il codice era "ibrido" (metà umano, metà IA) o quando il codice era stato modificato apposta per ingannarlo.

In Sintesi

Immagina che i ricercatori abbiano preso un cane da guardia esperto (il modello di testo), gli abbiano insegnato a fiutare non più l'odore di un libro, ma l'odore di un motore d'auto (il codice). Hanno costruito tre cani diversi per tre compiti diversi. Hanno vinto molte medaglie e dimostrato che la tecnologia è potente, ma il lavoro non è finito: c'è ancora spazio per rendere questi "detective" ancora più astuti e meno ingannabili.

1. Il Problema

L'avanzamento delle capacità di generazione dei Large Language Models (LLM) ha reso sempre più difficile distinguere tra codice scritto da umani e codice generato da macchine. SemEval-2026 Task 13 affronta questa sfida in un contesto complesso e multi-dominio, caratterizzato da:

Multi-linguaggio: Supporto per diversi linguaggi di programmazione (C++, Python, Java, Go, ecc.).
Multi-generatore: Identificazione di diverse famiglie di LLM generatori.
Sfide avanzate: Rilevamento di codice ibrido (co-generato da umani e macchine) e codice avversariale (modificato per mimetizzare l'origine).

La task è suddivisa in tre sottoproblemi:

Subtask A: Rilevamento binario (Codice umano vs. Codice macchina).
Subtask B: Attribuzione dell'autore (Classificazione multiclasse tra 11 categorie: 10 famiglie di LLM + classe "umano").
Subtask C: Rilevamento di codice ibrido (Classificazione tra 4 classi: umano, macchina, ibrido, avversariale).

2. Metodologia

Il sistema proposto, denominato mcdok (machine-code detector of KInIT), è un adattamento del precedente sistema mdok (specializzato nel rilevamento di testo generato da macchine) al dominio del codice.

Approccio Tecnico:

Architettura: Il sistema evita ensemble complessi, puntando su un approccio semplice basato sul fine-tuning di singoli modelli di base.
Modelli di Base: Sono stati selezionati modelli specifici per ogni sottotask, privilegiando modelli specializzati nel codice ma testando anche modelli generici:
- Subtask A: Gemma-3-27B-PT (modello generico).
- Subtask B: CodeGemma-7B (modello specializzato).
- Subtask C: Qwen2.5-Coder-14B (modello specializzato).
Fine-tuning: Utilizzo della tecnica QLoRA (Quantized Low-Rank Adaptation) con quantizzazione a 4 bit per efficienza.
- Parametri LoRA: rank ( $r$ ) = 64, $\alpha$ = 16, dropout = 0.1.
- Ottimizzatore: paged_adamw_32bit.
- Strategia di training: Batch size 1, learning rate $2 \times 10^{-5}$ con scheduler cosinusoidale.
- Funzione di perdita: Cross-entropy pesata per bilanciare le classi sbilanciate.
Preprocessing: A differenza del rilevamento di testo, non è stata applicata alcuna anonimizzazione o normalizzazione del testo (es. lowercase), poiché tali operazioni invaliderebbero la sintassi del codice.
Gestione dei Dati:
- Utilizzo esclusivo dei dati ufficiali forniti dagli organizzatori.
- Campionamento e bilanciamento dei dataset di training e validazione per mitigare i bias delle classi maggioritarie.
- Utilizzo del set test_sample (non etichettato pubblicamente ma accessibile per la validazione interna) per simulare dati Out-of-Distribution (OOD) e selezionare i checkpoint migliori.

3. Contributi Chiave

Adattamento di un framework esistente: Dimostrazione che un approccio efficace per il rilevamento di testo generato (mdok) può essere trasferito con successo al dominio del codice (mcdok) modificando strategicamente il modello di base.
Analisi comparativa dei modelli: Sperimentazione estesa su una vasta gamma di modelli (da 0.5B a 70B parametri), rivelando che per il rilevamento binario (Subtask A) un modello generico (Gemma-3-27B) ha superato i modelli specializzati nel codice.
Ottimizzazione della soglia di classificazione: Per il Subtask A, è stato osservato che fissare la soglia di decisione a una probabilità di 1.0 (100% di confidenza per la classe "macchina") ha migliorato significativamente le prestazioni rispetto alla soglia standard di 0.5.
Riproducibilità: Il codice sorgente per l'addestramento e l'inferenza è stato reso pubblico, permettendo la replica completa dei modelli.

4. Risultati

Le prestazioni sono state valutate utilizzando la metrica Macro F1.

Subtask A (Rilevamento Binario):
- Il modello migliore è stato Gemma-3-27B-PT, ottenendo un Macro F1 di 0.697 sul set di test ufficiale.
- I modelli specializzati (CodeGemma, Qwen) hanno ottenuto risultati inferiori rispetto al modello generico, sebbene superiori alla baseline.
- Analisi su un dataset filtrato (Droid test set) ha mostrato prestazioni stabili su linguaggi non visti in training (es. C, C#), ma difficoltà su linguaggi con pochi campioni (Rust, PHP).
Subtask B (Attribuzione dell'Autore):
- Il modello CodeGemma-7B ha ottenuto il miglior risultato con un Macro F1 di 0.396.
- La task è risultata molto difficile a causa delle 11 classi e dello sbilanciamento dei dati.
- Il sistema ha superato le baseline (CodeBERT e random), ma con margini ridotti. L'analisi della matrice di confusione ha mostrato buona capacità nel distinguere le classi "umano", "OpenAI" e "BigCode", ma confusione tra le altre famiglie di LLM.
Subtask C (Codice Ibrido):
- Il modello Qwen2.5-Coder-14B ha ottenuto il miglior risultato con un Macro F1 di 0.686.
- La classe più difficile da distinguere è stata quella "ibrida", spesso confusa con la classe "macchina".
- Le prestazioni sono state stabili tra i diversi linguaggi di programmazione.

Posizionamento:

Subtask A: 10° su 81 partecipanti (88° percentile).
Subtask B: 13° su 34 partecipanti (62° percentile).
Subtask C: 5° su 32 partecipanti (84° percentile).

5. Significatività e Conclusioni

Il lavoro dimostra che i rilevatori di testo generato da macchine possono essere efficacemente adattati al codice, ma richiedono una selezione attenta del modello di base: non sempre i modelli "code-specialized" sono la scelta migliore per ogni task (come evidenziato dal successo di Gemma-3 nel task binario).

Limitazioni e Lavori Futuri:

I risultati sono specifici per i modelli testati e potrebbero non generalizzarsi a tutti gli LLM.
Le prestazioni sono state limitate dalla dimensione e dalla distribuzione dei dati ufficiali.
Futuri miglioramenti potrebbero derivare da un campionamento più accurato dei dataset di training/validazione e da un'ottimizzazione più fine degli iperparametri.

In sintesi, mcdok rappresenta un contributo significativo nel campo della sicurezza del codice, offrendo strumenti pratici per identificare l'origine del codice in scenari sempre più complessi e ibridi.