Tricky$^2$: Towards a Benchmark for Evaluating Human and LLM Error Interactions

Sintesi Tecnica: Tricky2 – Verso un benchmark per la valutazione delle interazioni tra errori umani e LLM

Problema

Mentre i Large Language Models (LLM) sono sempre più integrati nei flussi di lavoro dello sviluppo software (ad esempio, GitHub Copilot), i benchmark esistenti per il testing e il debugging del software valutano gli errori generati da umani e quelli generati dall'IA isolatamente. I dataset attuali, come TrickyBugs (difetti umani) o buggy-HumanEval (difetti LLM), non riescono a catturare la realtà dello sviluppo moderno, in cui codice scritto da umani e da LLM coesiste all'interno degli stessi file e funzioni.

Il documento identifica una lacuna critica: i benchmark esistenti non possono valutare le interazioni tra errori. Nei contesti ibridi, le correzioni umane possono mascherare i guasti degli LLM, le riparazioni degli LLM possono reintrodurre difetti umani, e le metriche di valutazione standard possono fallire quando molteplici fonti di errore si compongono o si oscurano a vicenda. Di conseguenza, la comunità dell'ingegneria del software manca della capacità di valutare rigorosamente gli strumenti di riparazione in contesti misti di origine reale o di studiare l'affidabilità del debugging nella collaborazione ibrida uomo-IA.

Metodologia

Per affrontare questo problema, gli autori introducono Tricky2, un dataset ibrido che estende l'esistente corpus TrickyBugs. La pipeline di costruzione prevede i seguenti passaggi:

1. Dataset di base: La fondazione è TrickyBugs, che contiene 3.043 programmi errati scritti da umani e 1.361 programmi corretti in C++, Python e Java, derivati da sottomissioni di programmazione competitiva.
2. Iniezione controllata di bug: Gli autori utilizzano due LLM, GPT-5 e OpenAI-oss-20b, per iniettare errori aggiuntivi nei programmi esistenti.
   • Framework di prompting: Un prompt strutturato e guidato da una tassonomia istruisce i modelli a iniettare esattamente un nuovo bug da una tassonomia predefinita (Input/Output, Variabile/Dati, Logica/Condizione, Ciclo/Iterazione, Funzione/Procedura) preservando rigorosamente tutti gli originali difetti umani e la struttura del programma.
   • Vincoli: Ai modelli viene ordinato di evitare cambiamenti di commenti o formattazione e di restituire il file modificato con il livello tassonomico e le posizioni dei caratteri del codice iniettato.
3. Suddivisioni del dataset: Il processo genera tre distinte suddivisioni:
   • Solo umano (Human-only): Gli originali programmi errati.
   • Solo LLM (LLM-only): Programmi corretti con errori iniettati da LLM (senza bug umani).
   • Umano+LLM (Human+LLM): Programmi errati contenenti sia i difetti umani originali che i nuovi errori iniettati dagli LLM.
4. Validazione: Una pipeline automatizzata valida la sintassi e la compilazione utilizzando strumenti specifici per linguaggio (g++, py_compile, javac). Il corpus finale contiene 11.851 programmi errati, con tutte le suddivisioni che condividono gli stessi casi di test e riferimenti corretti.

Contributi Chiave

• Benchmark Tricky2: Il primo benchmark controllato che modella esplicitamente la cooccorrenza di errori umani e LLM all'interno di contesti di programma condivisi.
• Iniezione guidata dalla tassonomia: Una pipeline riproducibile che utilizza una specifica tassonomia di errori per generare bug di origine meccanica che interagiscono con i difetti umani senza alterare la struttura originale del codice.
• Tre compiti di valutazione: Il documento definisce tre compiti complementari per misurare l'affidabilità in contesti ibridi:
  1. Classificazione dell'origine: Distinguere tra difetti umani, LLM e misti.
  2. Identificazione dell'errore: Localizzare gli intervalli del bug e identificare il livello tassonomico.
  3. Riparazione del programma: Valutare il successo di patch minimali rispetto ai test case forniti.
• Valutazioni baseline: Valutazioni di prova di concetto su piccola scala su un sottoinsieme stratificato di 135 problemi difficili (45 per suddivisione) in C++, Java e Python.

Risultati

Le valutazioni baseline, sebbene limitate nell'ambito, rivelano schemi distinti riguardo agli errori di origine mista:

• Difficoltà di riparazione: Sia le suddivisioni "solo umano" che "solo LLM" hanno dimostrato tassi di successo della riparazione più elevati rispetto alla suddivisione Human+LLM.
• Effetti di interazione: I risultati suggeriscono che i difetti di origine mista introducono effetti di interazione che complicano il ragionamento e la riparazione. In particolare, nella suddivisione C++ Human+LLM, il modello non è riuscito a produrre un singolo programma corretto, nonostante avesse corretto con successo sottogruppi sostanziali dei casi a origine singola.
• Classificazione e localizzazione: Il documento riporta matrici di confusione e heatmap per la classificazione dell'origine e l'identificazione della tassonomia, sebbene le percentuali specifiche di accuratezza non siano l'oggetto primario del riassunto; l'enfasi è sulla divergenza nei risultati di riparazione.

Significato e Rivendicazioni

Il documento posiziona Tricky2 come un primo, ma necessario, passo verso la valutazione della affidabilità del software in ambienti di sviluppo ibridi uomo-IA. Gli autori affermano che:

• Gli effetti di interazione sono reali: I difetti di origine mista non sono semplicemente la somma delle loro parti; creano effetti di composizione o mascheramento che i benchmark attuali a singola origine non possono rilevare.
• Gli strumenti attuali faticano: Gli LLM esistenti sembrano faticare significativamente con la complessità del debugging di codice in cui gli errori umani e dell'IA interagiscono, evidenziando una lacuna nelle attuali capacità di riparazione.
• Fondamenta per il lavoro futuro: Tricky2 funge da base per studiare la robustezza, la collaborazione consapevole degli errori e la progettazione di workflow di codifica uomo-IA più sicuri. Gli autori prevedono futuri ampliamenti che coinvolgano protocolli di debugging agentici, studi longitudinali sulla affidabilità dei modelli e l'espansione ad altri linguaggi e famiglie di modelli.

Il documento riconosce esplicitamente i limiti, inclusa la dipendenza da versioni specifiche di LLM (che possono cambiare nel tempo), il vincolo del dominio sottostante di TrickyBugs (programmazione competitiva rispetto a sistemi industriali) e la mancanza di copertura per errori semantici complessi come la concorrenza o la gestione della memoria. Tuttavia, afferma che il dataset fornisce una base controllata per investigare le interazioni tra errori che prima erano inmisurabili.