Separarea semnalului de zgomot în evaluările de programare

Măsurarea precisă a capabilităților modelelor noastre este importantă pentru decizii solide de lansare și siguranță, inclusiv decizii luate conform Cadrului de pregătire⁠(se deschide într-o fereastră nouă) al OpenAI. La fiecare lansare de model, raportăm rezultate pentru o varietate de benchmarkuri externe și interne, pentru a urmări progresul modelului. Când evaluările au defecte care afectează rezultatele, ele pot crea o înțelegere falsă a capabilităților, denaturând cazurile de siguranță și influențând prioritățile de cercetare.

Am investigat recent cum unul dintre cele mai folosite benchmarkuri de programare, SWE-bench Verified, avea probleme fundamentale de proiectare și contaminare și am constatat că evaluarea nu mai oferea un semnal semnificativ despre capabilitățile de dezvoltare software. La momentul respectiv, am încurajat comunitatea mai largă să treacă la SWE-Bench Pro.

SWE-Bench Pro⁠(se deschide într-o fereastră nouă) a fost conceput pentru a îmbunătăți SWE-bench Verified, testând modelele pe orizonturi mai lungi și pe sarcini de programare mai realiste, pentru a urmări mai bine capabilitățile de codare agentivă. La fel ca și în cazul SWE-bench Verified, sarcinile sunt extrase programatic din istoricul modificărilor de funcționalități dintr-un set de depozite publice și private. Modelele trebuie să implementeze o soluție care să treacă noile teste pentru o funcționalitate, fără a defecta funcționalitatea existentă. În ceea ce privește setul public de date cu 731 de sarcini, modelele de frontieră au înregistrat o îmbunătățire a ratei de promovare de la 23,3% la 80,3% în opt luni.

De atunci, am efectuat un audit similar asupra SWE-Bench Pro, revizuind setul de date cu ajutorul unui proces de analiză a punctelor de date. Procesul a analizat încercările modelului la sarcină, metadatele sarcinii și urmele de eșec pentru a semnala defecte probabile ale evaluării. Fiecare sarcină semnalată a fost apoi evaluată prin mai multe treceri ale agenților investigatori și revizuită independent de cinci ingineri software experimentați, iar dezacordurile au fost escaladate pentru investigații suplimentare.

Problemele s-au încadrat în principal în patru categorii:

• Testele prea stricte¹ impun detalii specifice de implementare care nu sunt specificate în solicitare, invalidând multe trimiteri corecte funcțional.
• Solicitările insuficient specificate² omit cerințe pe care testele ascunse le impun și care nu pot fi deduse în mod rezonabil.
• Testele cu acoperire redusă verifică insuficient funcționalitatea cerută, astfel încât unele remedieri incomplete pot fi acceptate.
• O solicitare înșelătoare îndreaptă modelele către un comportament greșit sau contrazice ceea ce cer testele.

Constatările noastre indică dificultatea de a crea benchmarkuri dificile, dar echitabile, și utilitatea tot mai mare a agenților pentru verificări scalabile ale calității datelor. Având în vedere aceste rezultate, estimăm că ~30% dintre sarcinile SWE-bench Pro sunt defecte și le recomandăm dezvoltatorilor de modele să examineze cu atenție rezultatele.

Scopul nostru este să ne asigurăm că eșecurile în îndeplinirea sarcinilor reflectă limitări reale ale modelului, iar reușitele reflectă soluții complete și valide la cerințele solicitării. Pentru a verifica calitatea datelor utilizate în evaluare, am creat un proces de asigurare a calității menit să evalueze dacă fiecare punct de date reflectă cu acuratețe capabilitățile modelului.

Un filtru automat inițial revizuiește instrucțiunile date modelului, încercările modelului de a rezolva sarcina și testele folosite pentru a nota aceste încercări, pentru a semnala exemple probabil defecte sau problematice. Acest filtru a semnalat 286 de sarcini potențial defecte. Apoi am efectuat o revizuire mai aprofundată a acelui subset în două moduri: o revizuire de către agenți sub supraveghere umană care realizează verificări extinse cu agenți investigatori și o judecată umană finală, și o campanie de adnotare umană realizată cu dezvoltatori software experimentați.

Fiecare problemă semnalată este auditată cu agenți investigatori bazați pe Codex, care au primit acces la depozitul și mediul sarcinii. Acest lucru îi ajută să distingă ambiguitatea rezonabilă a sarcinii, care poate fi adesea rezolvată prin studierea codului apropiat și a convențiilor depozitului, de insuficienta specificare reală. Agentul poate rula teste, inspecta fișiere din depozit și investiga încercările modelului și modurile lor comune de eșec la sarcină. După mai multe repetări independente ale acestor audituri mai aprofundate, un cercetător a revizuit rezumatele, a luat o decizie finală și a etichetat problemele probabile.

În paralel, am derulat o campanie de adnotare umană asupra subsetului semnalat. Am lucrat cu ingineri software experimentați, instruiți cu privire la obiectivele benchmarkului, taxonomia problemelor și cazurile-limită înainte de a revizui sarcinile. Fiecare sarcină a fost revizuită de cinci ingineri.

Revizorii și-au format o judecată independentă pe baza descrierii vizibile a problemei, a cazurilor de test și a soluției de referință corecte (cunoscută drept gold patch), înainte de a folosi analiza procesului sau transcrierea drept context de sprijin. Apoi, revizorii au atribuit o etichetă și un scor de severitate pe baza unor dovezi concrete și au escaladat dezacordurile sau cazurile cu încredere scăzută pentru revizuire suplimentară.

Revizorii umani au fost mai predispuși decât agenții investigatori să marcheze sarcinile ca fiind defecte. Au existat, de asemenea, unele discrepanțe privind categoriile între cele două procese de revizuire, dar în nicio sarcină semnalată nu a fost eticheta „nedefectă” cea mai frecventă etichetă atribuită de revizor. Dintre categoriile semnalate de procesul cu agenți, judecățile revizorilor s-au suprapus în 74% dintre cazuri.

Comparativ cu procesul cu agenți, revizorii umani au fost, de asemenea, mai predispuși să selecteze mai multe etichete pentru o sarcină, indicând că au considerat sarcinile defecte în mai multe feluri sau că acestea nu se încadrau clar într-o singură categorie. Acest lucru sugerează că procesul cu agenți plus revizori a produs o etichetare conservatoare: a surprins aceleași moduri generale de eșec identificate de oameni, subestimând totodată cazurile în care revizorii au observat probleme suplimentare sau suprapuse. Cea mai mare diferență s-a înregistrat în cazul testelor cu acoperire redusă, pe care oamenii le-au identificat ca fiind cea mai frecventă problemă în 9,4% din benchmarkuri, comparativ cu 4,1% din procesul cu agenți.

Problemele pe care le-am identificat, împreună cu cazuri similare din SWE-bench Verified, evidențiază importanța verificării riguroase a benchmarkurilor. Problemele și pull requesturile din depozitele open-source au fost create inițial pentru colaborare umană, adesea prin schimburi îndelungate între responsabilii cu mentenanța și contribuitori. Drept urmare, descrierile problemelor, codul integrat și testele unitare nu se aliniază întotdeauna astfel încât să formeze sarcini curate și izolate, potrivite pentru evaluarea fiabilă a modelelor. În mod deosebit, testele incluse în pull requesturi pot fi prea stricte, deoarece sunt scrise pentru a valida o modificare anume, nu pentru a defini un standard independent de implementare pentru rezolvarea sarcinii.

În același timp, deficiențele de evaluare sunt mai ușor de detectat acum decât ar fi fost până nu demult. Pe măsură ce capabilitățile modelelor se îmbunătățesc, putem folosi acele modele pentru a inspecta solicitări, teste, patchuri, urme și cazuri-limită cu mult mai multă profunzime și consecvență, ajutând la scoaterea la iveală a problemelor de benchmark care înainte erau costisitoare sau imposibil de găsit la scară largă.

Sperăm că întreaga comunitate de evaluare va dezvolta noi benchmarkuri construite de dezvoltatori software experimentați special pentru a testa capabilitățile modelelor. Această abordare poate menține standardele înalte și realismul pe care le dorim pentru evaluarea capabilităților modelelor și permite o supraveghere umană mai eficientă pe tot parcursul procesului. Având în vedere problemele identificate în cadrul acestei analize, ne retragem recomandarea anterioară de a adopta SWE-Bench Pro.

În cele din urmă, o evaluare ar trebui să ofere un semnal relevant prin benchmarkuri dificil de manipulat, în care se poate avea încredere și care reflectă cu adevărat capacitatea sau conformitatea modelului. Deoarece aceste rezultate determină deciziile OpenAI privind implementarea și siguranța, evaluările pe care le monitorizăm trebuie să fie valide și informative.