ClassEval-Pro: A Cross-Domain Benchmark for Class-Level Code Generation

1. Enunciato del Problema

Sebbene i Modelli Linguistici su Larga Scala (LLM) abbiano ottenuto grandi successi nella sintesi di codice a livello di funzione (ad esempio HumanEval, MBPP) e nella modifica di codice a livello di repository (ad esempio SWE-bench), persiste un divario critico nella creazione di codice compositivo. Ciò si riferisce alla capacità di costruire una classe completa e strutturalmente interna a partire da una specifica, il che richiede il coordinamento di più metodi, la gestione di uno stato condiviso e l'integrazione della logica tra diversi domini.

I benchmark esistenti non riescono a risolvere efficacemente questo problema perché:

• I benchmark a livello di funzione testano la sintesi di logica isolata.
• I benchmark a livello di repository si concentrano sulla modifica di codebase esistenti.
• I precedenti benchmark a livello di classe (ad esempio ClassEval) si basano su una curatela manuale, rendendoli difficili da scalare, costosi e sempre più suscettibili alla contaminazione dei dati (addestramento su dati di test) a causa della loro anzianità (vintage 2023).

2. Metodologia: Costruzione di ClassEval-Pro

Gli autori introducono ClassEval-Pro, un benchmark composto da 300 task a livello di classe distribuiti su 11 domini. La costruzione si basa su una pipeline completamente automatizzata e resistente alla contaminazione in tre fasi:

A. Raccolta e Strutturazione dei Dati (Fase 1)

• Fonte: Repository Python da GitHub aggiornati dopo gennaio 2025 per garantire che i dati siano successivi alle attuali soglie di taglio per l'addestramento degli LLM.
• Domini: Copre 11 domini (ad esempio Finanza, Rete, Sicurezza, Sviluppo di Giochi).
• Strategia di Composizione:
  • Intra-Dominio: Fusione di classi all'interno dello stesso dominio (ad esempio SinglyLinkedList + Stack).
  • Cross-Dominio: Fusione di classi da domini diversi (ad esempio SQLQueryBuilder + PlayerInventory) per forzare una gestione complessa dello stato e vincoli di interfaccia.
• Filtraggio: Un parsing AST rigoroso garantisce che il codice sia autonomo (solo libreria standard), abbia 5 o più metodi e 40–800 righe di codice.

B. Generazione e Filtraggio dei Test (Fase 2)

• Generazione dello Scheletro: Un LLM genera uno scheletro di classe basato sul codice fuso.
• Generazione della Suite di Test: Un LLM genera casi di test corrispondenti allo scheletro.
• Validazione: Un Ensemble di Giudici LLM (tre giudici indipendenti) valuta la compatibilità tra lo scheletro e la suite di test. Solo le coppie che ricevono il punteggio massimo da almeno due giudici procedono.

C. Generazione della Soluzione e Verifica (Fase 3)

• Soluzione di Riferimento: Un LLM separato genera il codice completo della soluzione.
• Verifica di Esecuzione: Le soluzioni vengono eseguite in un ambiente isolato. Per essere incluse nel benchmark, un task deve:
  1. Superare tutti i test.
  2. Raggiungere una copertura delle righe >90%.
  3. Completarsi entro un timeout di 60 secondi.
• Output Finale: Un dataset di scheletri di classe, suite di test e soluzioni di riferimento verificate.

3. Design Sperimentale

• Modelli Valutati: Cinque LLM all'avanguardia (GPT-5.1, Gemini-2.5-Pro, Qwen3-480B, Qwen3-30B, Kimi-K2).
• Strategie di Generazione: Sono state testate cinque approcci distinti:
  1. Olistico: Generazione in un'unica passata dell'intera classe.
  2. Incrementale: Generazione iterativa dei metodi nell'ordine di dichiarazione.
  3. Compositivo: Generazione indipendente di import, definizioni di classe e corpi dei metodi, seguita dall'assemblaggio.
  4. Top-Down: Generazione prima dei metodi di alto livello, poi delle dipendenze.
  5. Bottom-Up: Generazione prima delle dipendenze di basso livello, poi dei metodi di alto livello.
• Metriche: La metrica principale è Pass@k (Successo Completo a Livello di Classe), con un'analisi secondaria sul successo a livello di metodo e sul successo parziale.

4. Risultati Chiave

A. Difficoltà del Benchmark e Potere Discriminativo

• Difficoltà: I task di ClassEval-Pro sono significativamente più difficili dei precedenti benchmark, con gerarchie di dipendenze più profonde (che raggiungono un picco di 3 livelli rispetto a 1-2 in ClassEval) e una maggiore diversità semantica.
• Divario di Prestazioni: Il miglior modello (Qwen3-480B) ha raggiunto solo un 45,6% di Pass@1 (Successo Completo a Livello di Classe). Il divario tra il modello più forte e quello più debole è stato di 17,7 punti percentuali, confermando la capacità del benchmark di discriminare tra i modelli all'avanguardia.

B. Interazione Strategia-Modello

• Approcci Strutturati Aiutano i Modelli Più Deboli: Per GPT-5.1, la strategia Bottom-Up ha migliorato il Pass@1 di 9,4 punti (dal 27,9% al 37,3%) rispetto all'approccio Olistico.
• Fallimento della Generazione Compositiva: La strategia "Compositiva" (generazione di parti in isolamento) ha causato il crollo delle prestazioni, scendendo fino a 1,3% per Gemini-2.5-Pro. Ciò evidenzia la difficoltà di riassemblare frammenti isolati in una classe coerente.
• Top-Down per Modelli Forti: Modelli più forti come Gemini-2.5-Pro hanno beneficiato leggermente della pianificazione Top-Down, suggerendo che una pianificazione esplicita di alto livello aiuta la coerenza globale.

C. Analisi degli Errori (Basata su 500 Fallimenti Annotati Manualmente)

• Errori Dominanti:
  • Errori Logici (56,2%): Implementazioni semanticamente errate (ad esempio, casi limite mancanti, tipi di eccezione errati).
  • Errori di Dipendenza (38,0%): Fallimenti nella gestione dello stato condiviso, firme dei metodi o import (ad esempio, import os mancante).
  • Errori Sintattici: Trascurabili (0,6%).
• Collo di Bottiglia Principale: La modalità di fallimento primaria non è la formazione del codice, ma il coordinamento cross-metodo. I modelli spesso generano metodi individualmente corretti che non funzionano insieme a causa di una gestione dello stato incoerente o interfacce rotte.

5. Contributi Chiave

1. Benchmark ClassEval-Pro: Un benchmark scalabile e cross-domain di 300 task progettato specificamente per valutare la creazione di codice compositivo, andando oltre la sintesi di funzioni isolate.
2. Pipeline di Costruzione Automatizzata: Una pipeline innovativa e resistente alla contaminazione che combina fusione di codice basata su AST, Ensemble di Giudici LLM e verifica rigorosa dell'esecuzione per generare task di alta qualità e reali senza curatela manuale.
3. Insight Diagnostici: Identificazione del coordinamento cross-metodo come il principale collo di bottiglia nella generazione a livello di classe. Lo studio rivela che, sebbene i modelli possano scrivere metodi locali, faticano con la coerenza globale della classe, la gestione dello stato condiviso e il coordinamento delle dipendenze.

6. Significato

• Realismo: Utilizzando codice GitHub post-2025 e composizione cross-domain, ClassEval-Pro offre una valutazione più realistica delle capacità degli LLM per compiti di ingegneria del software rispetto ai benchmark sintetici a livello di funzione.
• Direzioni Future: I risultati suggeriscono che i futuri miglioramenti degli LLM per la generazione di codice devono concentrarsi meno sulla sintassi e più sul ragionamento architettonico, la gestione dello stato e il coordinamento delle dipendenze.
• Guida alle Strategie: I risultati indicano che le strategie di generazione dovrebbero essere adattate alle capacità del modello; la decomposizione strutturata aiuta i modelli più deboli, mentre approcci olistici o top-down potrebbero adattarsi meglio ai modelli più forti.

Gli autori hanno reso open-source il benchmark, la pipeline e gli script di valutazione per facilitare ulteriori ricerche in questa area sottoutilizzata della generazione di codice.