Separare il segnale dal rumore nelle valutazioni di coding

Misurare con precisione le capacità dei nostri modelli è importante per prendere decisioni adeguate in materia di implementazione e sicurezza, incluse quelle previste dal Preparedness Framework⁠(si apre in una nuova finestra) di OpenAI. A ogni rilascio di un modello, riportiamo risultati su vari benchmark esterni e interni per monitorare i progressi dei modelli. Quando le valutazioni hanno difetti che influenzano i risultati, possono fornire una percezione errata delle capacità, distorcendo i casi di sicurezza e incidendo sulle priorità di ricerca.

Recentemente abbiamo analizzato come uno dei benchmark di programmazione più diffusi, SWE-bench Verified, presentasse problemi fondamentali di progettazione e di contaminazione, e abbiamo riscontrato che tale benchmark non forniva più indicazioni significative sulle capacità di sviluppo software. All’epoca, abbiamo incoraggiato la comunità in generale a passare a SWE-Bench Pro.

SWE-Bench Pro⁠(si apre in una nuova finestra) è stato progettato per migliorare SWE-bench Verified, testando i modelli su orizzonti temporali più lunghi e su compiti di codifica più realistici, al fine di valutare meglio le capacità di coding agentico. Come in SWE-bench Verified, i compiti vengono generati programmaticamente dalla cronologia delle modifiche alle funzionalità in una serie di repository pubblici e privati. I modelli devono implementare una soluzione che superi i nuovi test relativi a una determinata funzionalità, senza compromettere le funzionalità esistenti. Sulla divisione pubblica di 731 attività, i modelli avanzati sono passati da un tasso di superamento del 23,3% all'80,3% in otto mesi.

Da allora abbiamo condotto una verifica analoga su SWE-Bench Pro, esaminando il set di dati tramite una pipeline di analisi dei punti dati. La pipeline ha esaminato i tentativi del modello relativi all'attività, i metadati dell'attività e le tracce di errore per individuare possibili difetti nella valutazione. Ogni attività segnalata è stata poi valutata attraverso più cicli di revisione da parte di ricercatori e agenti e sottoposta a revisione indipendente da parte di cinque ingegneri software esperti; eventuali disaccordi sono stati sottoposti a un livello superiore per ulteriori approfondimenti.

I problemi rientravano principalmente in quattro categorie:

• Test troppo rigidi¹ impongono dettagli di implementazione specifici non indicati nel prompt, rendendo non valide molte soluzioni funzionalmente corrette.
• Prompt non sufficientemente dettagliati² omettono requisiti che vengono verificati da test nascosti e che non sono ragionevolmente deducibili.
• Test a bassa copertura verificano la funzionalità richiesta, pertanto è possibile che correzioni incomplete vengano accettate.
• Un prompt fuorviante induce i modelli ad adottare un comportamento errato o è in contraddizione con quanto richiesto dai test.

I nostri risultati evidenziano la difficoltà di definire criteri di valutazione rigorosi ma equi e la crescente utilità degli agenti per controlli scalabili della qualità dei dati. Alla luce di questi risultati, stimiamo che circa il 30% delle attività di SWE-bench Pro presenti anomalie e raccomandiamo agli sviluppatori di modelli di esaminare attentamente i risultati.

Il nostro obiettivo è garantire che i fallimenti delle attività riflettano effettivi limiti del modello e che i successi riflettano soluzioni complete e valide rispetto ai requisiti del prompt. Per verificare la qualità dei dati utilizzati nella valutazione, abbiamo creato una pipeline di controllo qualità volta a valutare se ogni singolo dato rifletta accuratamente le capacità del modello.

Un filtro automatizzato iniziale esamina le istruzioni fornite al modello, i tentativi del modello di risolvere l'attività e i test utilizzati per valutare tali tentativi, al fine di segnalare esempi potenzialmente non funzionanti o problematici. Questo filtro ha segnalato 286 attività potenzialmente non funzionanti. Abbiamo quindi condotto una revisione più approfondita di quel sottoinsieme in due modi: una revisione da parte di agenti supervisionati da esseri umani, che effettua controlli approfonditi con agenti investigatori e un giudizio finale umano; e una campagna di annotazione umana in collaborazione con sviluppatori di software esperti.

Ogni problema segnalato viene verificato da agenti investigatori basati su Codex, ai quali è stato concesso l'accesso al repository dei compiti e all'ambiente. Ciò li aiuta a distinguere tra una ragionevole ambiguità dell'attività, che spesso può essere risolta studiando il codice circostante e le convenzioni del repository, e una vera e propria mancanza di specificazione. L'agente può eseguire test, ispezionare i file nel repository e indagare sui tentativi del modello e sulle loro modalità di fallimento più comuni nell'ambito del compito. Dopo diverse ripetizioni indipendenti di queste verifiche approfondite, un ricercatore ha esaminato i riepiloghi, ha espresso un giudizio finale e ha contrassegnato i probabili problemi.

Parallelamente, abbiamo condotto una campagna di annotazione manuale sul sottoinsieme contrassegnato. Abbiamo collaborato con ingegneri informatici esperti che, prima di procedere alla revisione delle attività, sono stati formati sugli obiettivi del benchmark, sulla tassonomia dei problemi e sui casi limite. Ogni attività è stata revisionata da cinque ingegneri.

I revisori hanno formulato un giudizio indipendente sulla base della descrizione visibile del problema, dei casi di test e della soluzione di riferimento (nota come gold patch), prima di ricorrere all'analisi della pipeline o alla trascrizione come contesto di supporto. I revisori hanno quindi assegnato un'etichetta e un livello di gravità sulla base di prove concrete, segnalando i casi di disaccordo o quelli con basso livello di affidabilità per un'ulteriore revisione.

I revisori umani erano più propensi degli agenti investigativi a contrassegnare le attività come non funzionanti. Si è riscontrata inoltre una certa discrepanza sulle categorie tra i due percorsi di revisione, ma in nessuna delle attività segnalate l'etichetta umana più comune era "funzionante". Tra le categorie segnalate dalla pipeline degli agenti, i giudizi dei revisori coincidevano nel 74% dei casi.

Rispetto alla pipeline basata sugli agenti, i revisori umani erano inoltre più propensi a selezionare più etichette per un'attività, indicando che ritenevano che le attività presentassero difetti in più modi o non rientrassero chiaramente in un'unica categoria. Ciò suggerisce che la pipeline agente più revisore abbia portato a un’etichettatura conservativa: ha individuato le stesse modalità di errore generali identificate dagli esseri umani, sottostimando però i casi in cui i revisori hanno rilevato problemi aggiuntivi o sovrapposti. La differenza maggiore si è riscontrata nei test a bassa copertura, che i revisori umani hanno selezionato come il problema più comune nel 9,4% del benchmark, rispetto al 4,1% rilevato dalla pipeline basata sugli agenti.

I problemi che abbiamo individuato, insieme a casi simili riscontrati su SWE-bench Verified, evidenziano l'importanza di verificare con rigore i benchmark. I problemi e le pull request provenienti dai repository open source sono stati originariamente creati per favorire la collaborazione umana, spesso attraverso lunghi scambi tra manutentori e contributori. Di conseguenza, le descrizioni dei problemi, il codice integrato e i test unitari non sempre si allineano in modo da formare attività chiare e isolate che consentano di valutare i modelli in modo affidabile. In particolare, i test inclusi nelle pull request possono risultare eccessivamente rigorosi poiché sono scritti per convalidare una modifica specifica, piuttosto che per definire uno standard indipendente dall'implementazione per la risoluzione dell'attività.

Allo stesso tempo, oggi è più facile individuare i difetti di valutazione rispetto a quanto lo fosse anche solo poco tempo fa. Man mano che le capacità dei modelli migliorano, possiamo utilizzarli per analizzare prompt, test, patch, tracce e casi limite con maggiore approfondimento e coerenza, contribuendo a portare alla luce problemi nei benchmark che in precedenza erano costosi o difficili da individuare su larga scala.

Ci auguriamo che la comunità di valutazione nel suo complesso sviluppi nuovi benchmark realizzati da sviluppatori di software esperti appositamente per testare le capacità dei modelli. Tale approccio può garantire gli standard elevati e il realismo che desideriamo per misurare le capacità dei modelli, consentendo al contempo un migliore controllo umano durante l'intero processo. Alla luce delle criticità emerse in questa analisi, ritiriamo la nostra precedente raccomandazione di adottare SWE-Bench Pro.

In definitiva, una valutazione dovrebbe fornire indicazioni significative attraverso benchmark difficili da manipolare, affidabili e che riflettano realmente le capacità o l'allineamento del modello. Poiché questi risultati influenzano le decisioni di OpenAI in materia di implementazione e sicurezza, le valutazioni che monitoriamo devono essere valide e informative.