Sintesi Tecnica: Oltre il Tasso di Successo: Una Valutazione Multilingue e Basata sull'Esecuzione dei Modelli LLM per il Codice Open Source

Definizione del Problema

Le attuali valutazioni dei modelli linguistici di grandi dimensioni (LLM) per la generazione di codice si affidano frequentemente a benchmark compatti e a lingua singola e a tassi di successo aggregati (ad esempio, pass@1). Gli autori sostengono che tali riassunti oscurino dimensioni critiche delle prestazioni del modello, inclusa la variabilità tra i linguaggi di programmazione, le famiglie di problemi, i livelli di difficoltà e le modalità specifiche di fallimento. Inoltre, i benchmark standard spesso non riescono a distinguere tra correttezza funzionale e manutenibilità del codice (qualità statica), e non catturano adeguatamente la natura dei fallimenti (ad esempio, errori sintattici rispetto a semantici). Questo studio affronta il divario proponendo una valutazione su larga scala basata sull'esecuzione che preserva l'intero processo dalla generazione all'esecuzione per rivelare i compromessi nascosti dai classici leaderboards a metrica singola.

Metodologia

Costruzione del Corpus

Gli autori hanno costruito un benchmark utilizzando 2.707 problemi LeetCode gratuiti (non premium) per garantire la riproducibilità. Il corpus copre 12 linguaggi di programmazione: C, C++, C#, Go, Java, JavaScript, PHP, Python, Ruby, Scala, Swift e TypeScript.

• Scala: Lo studio ha generato 325.343 job problema–modello–linguaggio.
• Modelli: Sono stati valutati nove modelli LLM istruiti per il codice, ad accesso aperto o a pesi aperti, tra cui Yi-Coder-9B-Chat, Qwen2.5-Coder-14B-Instruct, Gemma-2-27B-IT, DeepSeek-Coder-V2-Lite-Instruct, Codestral-22B-v0.1, Phi-4, Meta-Llama-3.1-8B-Instruct, Granite-3.1-8B-Instruct e Stable-Code-Instruct-3B.
• Preservazione dei Dati: Ogni job conserva il prompt, la risposta grezza del modello, il codice estratto, l'esito dell'esecuzione ufficiale di LeetCode e i segnali di analisi statica.

Pipeline di Esecuzione

1. Prompting: Per ogni coppia problema–linguaggio sono stati generati prompt specifici per il linguaggio.
2. Inferenza: Una coda di job supportata da un server distribuito ha gestito l'inferenza tra i modelli locali (ospitati su LM Studio) per gestire la scala di oltre 300.000 job. Gli errori operativi (rete, timeout) sono stati distinti dai fallimenti del modello e gestiti tramite tentativi di riproposizione (retry).
3. Estrazione del Codice: Il post-processing ha estratto i blocchi di codice dalle risposte del modello (specificamente le sezioni tra tripli apici) per servirli come sottomissioni candidate.
4. Valutazione: Uno script di automazione in Python utilizzando Selenium ha sottoposto il codice estratto al giudice ufficiale di LeetCode. I risultati sono stati recuperati tramite GraphQL, catturando stati quali Accepted (Accettato), Wrong Answer (Risposta Errata), Compile Error (Errore di Compilazione), Runtime Error (Errore di Runtime), Time Limit Exceeded (Limite di Tempo Superato) e Memory Limit Exceeded (Limite di Memoria Superato).
5. Selezione della Metrica: Per ogni job, la "migliore" sottomissione è stata selezionata in base al più alto rapporto di correttezza, poi allo stato di accettazione, quindi al timestamp.
6. Analisi Statica: Lo studio ha eseguito l'analisi statica (linting) sugli artefatti di codice accettati utilizzando ast-grep e strumenti in stile Pylint per misurare la qualità del codice, la complessità e l'aderenza alle convenzioni.

Contributi Chiave

1. Archivio su Larga Scala: La costruzione di un archivio di esecuzione riproducibile che copre 2.707 problemi, 12 linguaggi e 9 modelli, contenente oltre 325.000 job di esecuzione.
2. Valutazione Multidimensionale: Un framework di valutazione che va oltre i punteggi aggregati per analizzare le prestazioni attraverso la media di correttezza, la copertura dei problemi accettati, le fette di difficoltà, le fette di linguaggio, le categorie di argomenti, gli esiti testa a testa a coppie e la composizione dei fallimenti.
3. Analisi Congiunta Funzionale e Statica: Un'analisi simultanea della correttezza funzionale e della qualità statica, dimostrando che il successo dell'esecuzione e i segnali orientati alla manutenibilità possono divergere significativamente.

Risultati Sperimentali

Prestazioni dei Modelli e Classifiche

• Correttezza Media: Yi-Coder-9B-Chat ha raggiunto la correttezza media più alta (23,64%), seguito da Qwen2.5-Coder-14B-Instruct e Gemma-2-27B-IT. Tuttavia, tutti i modelli rimangono molto al di sotto della baseline umana di accettazione del 57,2%.
• Copertura dei Problemi: Qwen2.5-Coder-14B-Instruct ha dimostrato la più ampia copertura di problemi accettati (77,1%), indicando che può risolvere una varietà più ampia di problemi distinti anche se la sua correttezza media per job è leggermente inferiore a quella di Yi-Coder.
• Fette di Difficoltà: Le classifiche dipendono dalla fetta considerata. Yi-Coder guida nei problemi facili e medi, mentre Qwen2.5-Coder-14B-Instruct ottiene le migliori prestazioni sui problemi difficili.
• Fette di Linguaggio: La qualità del modello non è invariante rispetto al linguaggio. Yi-Coder è più forte nei target convenzionali compilati/scripting (C++, Java, Python), Qwen è competitivo in C#, JavaScript, Ruby, Swift e TypeScript, e Gemma è più forte in Go e Scala.
• Fette di Argomento: Le classifiche variano per argomento. Ad esempio, Yi-Coder è costantemente forte in argomenti ad alta frequenza come array e stringhe, mentre Qwen guida in specifiche categorie algoritmiche.

Analisi dei Fallimenti

• Modalità di Fallimento Dominante: Gli errori di compilazione rappresentano il 63,25% delle migliori sottomissioni non accettate. Ciò indica che la maggior parte dei fallimenti avviene prima che la correttezza semantica possa essere testata.
• Spostamento del Fallimento: I modelli più forti tendono a ridurre la quota di errori di compilazione, esponendo relativamente più casi di runtime o di risposta errata.
• Correttezza Parziale: L'archivio mostra che i casi di risposta errata sono concentrati nel contenitore di zero percento di test superati, con prove limitate di successo "quasi raggiunto" intermedio.

Qualità Statica vs. Correttezza Funzionale

• Divergenza: La correttezza funzionale e la pulizia statica misurano proprietà diverse. Stable-Code-Instruct-3B ha ottenuto il punteggio di qualità strutturale più forte nonostante avesse la prestazione funzionale più debole.
• Tassi di Passaggio Lint: Gemma-2-27B-IT ha raggiunto il più alto tasso di passaggio lint per tutti i linguaggi. Al contrario, Qwen, nonostante le forti prestazioni di esecuzione, ha superato le regole di lint meno frequentemente.
• Tipi di Problemi: Il carico dell'analisi statica è dominato da avvisi (141.376 riscontri) e convenzioni (45.537 riscontri) piuttosto che da errori critici. I problemi di convenzione comuni includono using-namespace-std (48% dei riscontri di convenzione) e importazioni wildcard. I riscontri di refactoring sono stati rari (402 totali).

Significato e Rivendicazioni

Il documento sostiene che la sua importanza risiede nel dimostrare che una valutazione multilingue e che preserva gli artefatti rivela i compromessi nascosti dai leaderboard a lingua singola o a metrica singola.

• Nessun Modello Unicamente Migliore: Il "miglior" modello dipende interamente dall'obiettivo a valle. Se l'obiettivo è la correttezza media, è preferibile Yi-Coder-9B-Chat; se l'obiettivo è la copertura di problemi distinti o il successo su compiti difficili, Qwen2.5-Coder-14B-Instruct è superiore; se l'obiettivo è minimizzare l'onere di revisione tramite codice pulito, Gemma-2-27B-IT o Stable-Code-Instruct-3B potrebbero essere preferibili.
• Gap di Affidabilità: Lo studio evidenzia che gli attuali modelli open sono lontani dalla affidabilità del livello umano, con gli errori di compilazione che rappresentano la barriera primaria all'esecuzione.
• Rigore della Valutazione: Gli autori sostengono che la valutazione dei modelli di codice deve preservare l'esecuzione, la copertura linguistica e le modalità di fallimento e i segnali di qualità. Affidarsi a un singolo punteggio collassa le dimensioni delle prestazioni che sono critiche per l'implementazione pratica, come se un modello produca codice manutenibile o fallisca a causa della sintassi piuttosto che della logica.

Il documento conclude che valutare i modelli LLM che generano codice richiede un passaggio dall'identificare un singolo "vincitore" alla comprensione di come e perché i modelli abbiano successo o falliscano attraverso diversi contesti di programmazione.