Separare il segnale dal rumore nelle valutazioni della codifica

L’accurata misurazione delle capacità del nostro modello è fondamentale per decisioni corrette riguardo alla distribuzione e alla sicurezza, comprese quelle in base al [Preparedness Framework⁠(si apre in una nuova finestra) di OpenAI](https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf). Con ogni nuovo modello rilasciato, riportiamo risultati per una varietà di benchmark esterni ed interni per tracciare l’evoluzione delle capacità del modello. Tuttavia, quando le valutazioni presentano difetti che influenzano i risultati, possono generare un’errata rappresentazione delle capacità, compromettendo le case della sicurezza e influenzando le priorità di ricerca.

Perché smettere di utilizzare SWE-Bench Verified

Recentemente [abbiamo esaminato](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/) come uno dei benchmark più utilizzati, SWE-bench Verified, avesse gravi problemi di progettazione e contaminazione, concludendo che la valutazione non fornisse più un segnale significativo sulla capacità di sviluppo software. In quel momento, abbiamo incoraggiato la comunità più ampia a passare a SWE-Bench Pro.

Come è progettato SWE-Bench Pro

[SWE-Bench Pro⁠(si apre in una nuova finestra)](https://scale.com/blog/swe-bench-pro) è stato concepito per migliorare su SWE-Bench Verified, testando i modelli su orizzonti più lunghi e su compiti di programmazione più realistici per meglio tracciare le capacità di programmazione agente (agentic).Come in SWE-Bench Verified, i compiti sono ottenuti programmaticamente dalla cronologia delle modifiche alle funzioni in un insieme di repository pubblici e privati. I modelli devono implementare una soluzione che passi i nuovi test per una funzionalità senza rompere la funzionalità esistente.

Sul set pubblico di 731 compiti, i modelli di frontiera hanno migliorato la percentuale di passaggio del test da 23,3% a 80,3% in otto mesi. Tuttavia, abbiamo recentemente condotto un'analisi simile su SWE-Bench Pro, utilizzando una pipeline di analisi dei punti dati.

Problemi riscontrati in SWE-Bench Pro

La pipeline ha esaminato gli tentativi modellati delle attività, i metadati delle attività e le tracce di errore per segnalare possibili difetti nelle valutazioni. Ogni attività segnalata è stata quindi valutata attraverso múltipli passaggi di agente-investigatore, revisionata indipendentemente da cinque sviluppatori di software esperti e le discrepanze sono state elevate per ulteriore indagine.

La nostra analisi ha evidenziato la presenza di problemi nella valutazione su una percentuale significativa del dataset. La nostra pipeline con la sua analisi ha segnalato 200 attività rotte (27,4%) mentre le valutazioni umane hanno riscontrato 249 attività rotte (34,1%).

• Test troppo rigorosi [1](https://openai.com/index/separating-signal-from-noise-coding-evaluations#citation-bottom-1) stabiliscono dettagli implementativi specifici non richiesti nel prompt, incompatibili con molte implementazioni funzionalmente corrette.
• Prompt sottospecificati [2](https://openai.com/index/separating-signal-from-noise-coding-evaluations#citation-bottom-2) omettono requisiti che i test nascosti impongono e non sono ragionevolmente inferibili.
• Test poco completi non verificano a fondo la funzionalità richiesta, permettendo a riparazioni incomplete di passare.
• Prompt fuorvianti orientano i modelli verso il comportamento sbagliato o contraddicono ciò che i test richiedono.

Metodologia

Il nostro obiettivo è assicurarci che gli insuccessi riflettano vere limitazioni dei modelli, che gli successi rappresentino soluzioni corrette e complete per le esigenze del prompt. Per verificare la qualità dei dati utilizzati nello studio, abbiamo creato una pipeline di assicurazione della qualità per valutare se ciascun punto dati riflette fedelmente le capacità del modello.

Pipeline iniziale per la qualità dei dati segna problemi per la revisione. Verifichiamo con un’ispezione più approfondita assistita da agenti e una campagna di annotazione effettuata con sviluppatori esperti.

Filtro automatizzato iniziale

La pipeline iniziale esamina le istruzioni date al modello, gli tentativi del modello di risolvere la compito, e i test utilizzati per valutare questi tentativi, segnalando esempi probabilmente rotti o problematici. Questo filtro ha segnalato 286 potenziali problemi. Successivamente, abbiamo condotto un’ispezione più approfondita su questo sottoinsieme in due modi: un’ispezione assistita dagli agenti con supervisione umana e una campagna di annotazione umana con esperti sviluppatori di software.

Revisione supervisionata degli agenti umana

Ogni problema segnalato è stato ispezionato da agenti in base a Codex che avevano accesso al repository e all’ambiente del compito. Questo permette ai modelli di distinguere tra ambiguità ragionevolmente risolvibili, che spesso si possono risolvere studiando codice vicino e convenzioni del repository, e una vera sottospecificazione. Gli agenti possono eseguire test, ispezionare file nel repository e esaminare i tentativi del modello insieme alle loro comuni mode fallimento. Dopo alcuni audit autonomi, un ricercatore ha riveduto le sintesi, emettendo una giudicazione finale e assegnando un’etichetta ai probabili problemi.

Campagna di annotazione umana

In parallelo, abbiamo realizzato una campagna di annotazione umana sul sottoinsieme segnalato. Abbiamo collaborato con ingegneri esperti formati sugli obiettivi del benchmark, la classificazione dei problemi e casi estremi prima di revisionare i compiti. Ogni compito è stato revisionato da cinque ingegneri.

Gli estimatori hanno espresso un giudizio autonomamente sulla base del problema visibile, dei casi di test e della soluzione di riferimento (conosciuta come "gold patch") senza utilizzare la pipeline di analisi o una traccia come contesto. Gli estimatori hanno assegnato un'etichetta e una valutazione di severità sulla base di evidenze concrete e hanno risolto in modo separato i casi di disaccordo o di scarsa fiducia.

I revisori umani hanno segnalato un numero più elevato di compiti rotti rispetto agli agenti investigatori. C'è anche stato disaccordo tra le due revisioni sulle categorie, ma in nessun compito segnalato “non rotto” è stato considerato l’etichetta predominante dagli umani. Delle categorie indicate dalla pipeline agente, i giudizi dei revisori sovrapposi in 74 casi.

Rispetto alla pipeline agente, i revisori umani hanno spesso scelto più etichette per una singola attività, indicando che spesso hanno rilevato diversi modi in cui il compito era rotto o non rientrava in una categoria unica. Questo suggerisce che la pipeline agente piu' revisionatore ha prodotto un'etichettatura conservativa catturando i modelli di fallimento princip