Kalo te përmbajtja kryesore
OpenAI

8 korrik 2026

KërkimePublikim

Ndarja e sinjalit nga zhurma në vlerësimet e kodimit

Përmes një auditimi të detajuar, ne zbulojmë probleme të përhapura të detyrave në SWE-Bench Pro dhe vlerësojmë se ~30% e detyrave kanë defekte.

Duke ngarkuar…

Matja me saktësi e aftësive të modeleve tona është e rëndësishme për vendime të arsyeshme për vendosjen në përdorim dhe sigurinë, duke përfshirë vendimet sipas Preparedness Framework(hapet në një dritare të re) të OpenAI. Me çdo publikim modeli, ne raportojmë rezultatet për një larmi standardesh të jashtme dhe të brendshme për të monitoruar progresin e modelit. Kur vlerësimet kanë të meta që ndikojnë te rezultatet, ato mund të japin njohuri të pasakta për aftësitë, duke shtrembëruar argumentet e sigurisë dhe duke ndikuar te prioritetet e kërkimeve.

Ne hetuam së fundi se si një nga standardet më të përdorura të kodimit, SWE-bench Verified, kishte probleme thelbësore në dizajn dhe në lidhje me kontaminimin, si dhe zbuluam se vlerësimi nuk jepte më një sinjal domethënës për aftësitë e zhvillimit të softuerit. Në këtë moment, ne e nxitëm komunitetin më të gjerë të kalonte te SWE-Bench Pro.

SWE-Bench Pro(hapet në një dritare të re) u krijua për të përmirësuar SWE-bench Verified duke testuar modelet në horizonte më të gjata dhe detyra më realiste kodimi për të monitoruar më mirë aftësitë e kodimit agjentik. Ashtu si në SWE-bench Verified, detyrat merren programatikisht nga historiku i ndryshimeve të veçorive në një grup deposh publike dhe private. Modeleve u kërkohet të zbatojnë një zgjidhje që kalon testet e reja për një veçori, pa dëmtuar funksionalitetin ekzistues. Në ndarjen publike me 731 detyra, modelet avangardë u përmirësuan nga një normë kalimi prej 23,3% në 80,3% brenda tetë muajsh.

Që nga ajo kohë, ne kemi kryer një auditim të ngjashëm për SWE-Bench Pro, duke rishikuar grupin e të dhënave me përorimin e një kanali të analizës së pikave të të dhënave. Ky kanal rishikoi përpjekjet e modelit për detyrën, metadatat e detyrës dhe gjurmët e dështimeve për të raportuar të metat e mundshme të vlerësimit. Çdo detyrë e raportuar u vlerësua më pas përmes disa kalimeve hetues-agjent dhe u rishikua në mënyrë të pavarur nga pesë inxhinierë softuerësh me përvojë, ndërsa mospërputhjet u përshkallëzuan për hetim të mëtejshëm.

Ne zbulojmë prova për probleme që prekin një pjesë të konsiderueshme të grupit të të dhënave. Kanali ynë i analizës së pikave të të dhënave raportoi 200 (27,4%) detyra me defekte, ndërsa fushata e shënimeve nga njerëzit identifikoi 249 (34,1%) të tilla.

Problemet u ndanë kryesisht në katër kategori:

  • Testet tepër të rrepta1 zbatojnë detaje specifike zbatimi që nuk janë të specifikuara në kërkesë, duke i bërë të pavlefshme shumë dorëzime të sakta në aspektin funksional.
  • Kërkesat e papërcaktuara mirë2 lënë jashtë nevojat që zbatohen nga testet e fshehura dhe që nuk mund të nxirren në mënyrë të arsyeshme.
  • Testet me mbulim të ulët nuk e kontrollojnë në mënyrë të mjaftueshme veçorinë e kërkuar, kështu që mund të kalojnë rregullime jo të plota.
  • Një kërkesë çorientuese i drejton modelet drejt sjelljes së gabuar ose bie ndesh me atë që kërkojnë testet.

Gjetjet tona tregojnë vështirësinë e përsosjes së standardeve të vështira por të drejta, si edhe dobinë në rritje të agjentëve për kontrolle të shkallëzueshme të cilësisë së të dhënave. Në kuadër të këtyre rezultateve, ne vlerësojmë se ~30% e detyrave të SWE-bench Pro kanë defekte dhe i këshillojmë zhvilluesit e modeleve t’i ekzaminojnë me kujdes rezultatet.

Metodologjia

Synimi ynë është të sigurojmë që dështimet e detyrave të pasqyrojnë kufizime të vërteta të modeleve dhe sukseset e detyrave të pasqyrojnë zgjidhje të plota dhe të vlefshme për nevojat e kërkesave. Për të kontrolluar cilësinë e të dhënave të përdorura në vlerësim, ne krijuam një kanal për sigurinë e cilësisë për të vlerësuar nëse çdo pikë të dhënash pasqyron me saktësi aftësitë e modelit.

Rrjedha e punës për sigurimin e cilësisë që kombinon filtrimin e automatizuar dhe rishikimin njerëzor për të vlerësuar cilësinë e detyrave.

Një tubacion fillestar i cilësisë së të dhënave shënon problemet për rishikim. Ne e verifikojmë me një auditim më të thelluar të detyrave të shënuara, të asistuar nga agjentë, dhe me një fushatë shënimesh nga njerëzit duke punuar me inxhinierë me përvojë.

Një filtër fillestar i automatizuar rishikon udhëzimet që i jepen modelit, përpjekjet e modelit për ta zgjidhur detyrën dhe testet e përdorura për t’i vlerësuar këto përpjekje për të raportuar shembujt që mund të jenë problematikë ose me defekte. Ky filtër raportoi 286 detyra potencialisht me defekt. Më pas ne kryem një rishikim më të thelluar të atij nëngrupi në dy mënyra: një rishikim nga agjenti nën mbikëqyrje njerëzore, që kryen kontrolle të gjera me agjentë hetues dhe një gjykim përfundimtar njerëzor; dhe një fushatë shënimesh nga njerëzit, në bashkëpunim me zhvillues me përvojë të softuerëve.

Rishikimi nga agjenti nën mbikëqyrje njerëzore

Çdo problem i raportuar auditohet me agjentë hetues bazuar në Codex, të cilëve u është dhënë qasje në depon dhe mjedisin e detyrës. Kjo i ndihmon ata të dallojnë paqartësinë në mënyrë të arsyeshme për detyrat, gjë që shpesh mund të zgjidhet duke studiuar kodin përreth dhe konvencionet e depos, nga specifikimi i vërtetë i pamjaftueshëm. Agjenti mund të ekzekutojë teste, të inspektojë skedarët në depo dhe të hetojë përpjekjet e modelit dhe modalitetet e zakonshme të dështimit në detyrë. Pas disa përsëritjeve të pavarura të këtyre auditimeve më të thella, një studiues rishikoi përmbledhjet, dha gjykimin përfundimtar dhe etiketoi problemet e mundshme.

Fushata e shënimeve nga njerëzit

Paralelisht, ne zhvilluam një fushatë shënimesh nga njerëzit për nëngrupin e raportuar. Ne punuan me inxhinierë softuerësh me përvojë, të cilët u trajnuan për objektivat e standardit, taksonominë e problemeve dhe rastet ekstreme përpara se të rishikonin detyrat. Çdo detyrë u rishikua nga pesë inxhinierë.

Rishikuesit formuan një gjykim të pavarur nga përshkrimi i dukshëm i problemit, rastet e testimit dhe zgjidhja me referencë ndaj arsyesh-së vërtetës (e njohur si korrigjimi i artë) përpara se të përdornin analizën e kanalit ose transkriptin si kontekst mbështetës. Më pas rishikuesit caktuan një etiketë dhe një vlerësim rëndësie mbi bazën e provave konkrete dhe përshkallëzuan mospërputhjet ose rastet me nivel të ulët besimi për rishikim të mëtejshëm.

Rishikuesit njerëzorë kishin më shumë gjasa se agjentët hetues t’i shënonin detyrat si me defekte. Pati po ashtu disa mospërputhje për kategoritë mes dy rrugëve të rishikimit, por në asnjë detyrë të raportuar etiketa njerëzore më e zakonshme nuk ishte "pa defekt". Nga kategoritë që raportoi kanali me agjent, gjykimet e rishikuesve kishin mbivendosje në 74% të rasteve.

Krahasuar me kanalin me agjent, rishikuesit njerëzorë kishin po ashtu më shumë gjasa të zgjidhnin disa etiketa për një detyrë, gjë që tregon se ata gjetën defekte të detyrave në disa mënyra ose që nuk ishin qartësisht të përshtatshme për një kategori të vetme. Kjo sugjeron se kanali agjent-plus-rishikues solli një etiketim konservator: ai kapi të njëjtat modalitete të gjera të dështimeve që identifikuan njerëzit, ndërsa numëroi më pak raste ku rishikuesit panë probleme shtesë ose të mbivendosura. Dallimi më i madh ishte te testet me mbulim të ulët, të cilat njerëzit i zgjodhën si problemin më të zakonshëm për 9,4% të standardit, krahasuar me 4,1% nga kanali me agjent.

Modalitet e dështimeve

Në disa raste, kërkesa e detyrës përshkruante një zbatim specifik, por rastet e fshehura të testimit prisnin sjellje tjetër.

This task involves normalizing table-of-contents entries and rendering them back to Markdown via TocEntry.to_markdown(). The task prompt specifies serialization down to character-level spacing, describing how exact spacing and pipes are enforced, and gives examples such as " | Chapter 1 | 1" and "** | Chapter 1 | 1":

Asnjë

1
"[space]| Chapter 1 | 1"
2
"**[space]| Chapter 1 | 1"
3
"[space]| Just title | "

The hidden test_to_markdown assertions instead require " | Chapter 1 | 1" and "** | Chapter 1 | 1":

Asnjë

1
"[space][space]| Chapter 1 | 1"
2
"**[space][space]| Chapter 1 | 1"
3
"[space][space]| Just title | "

There are two leading spaces in the hidden tests, but the example given to the model only contains one leading space. If a model rightly follows the given prompt, that one-character difference would fail the hidden test cases and the task would be marked incorrect.

Diskutimi

Problemet që kemi identifikuar, bashkë me raste të ngjashme në SWE-bench Verified, nxjerrin në pah rëndësinë e kontrollit rigoroz të standardeve. Problemet dhe pull request-et nga depot me burim të hapur u krijuan fillimisht për bashkëpunim njerëzor, shpesh përmes shkëmbimeve të gjata midis mirëmbajtësve dhe kontribuesve. Si rezultat, përshkrimet e problemeve, kodi i shkrirë dhe testet e njësive nuk përputhen gjithmonë për të formuar detyra të pastra dhe të izoluara për vlerësimin e besueshëm të modeleve. Në veçanti, testet e përfshira në pull request-e mund të jenë tepër të rrepta, pasi ato shkruhen për të verifikuar një ndryshim specifik, dhe jo për të përcaktuar një standard të pavarur nga zbatimi për zgjidhjen e detyrës.

Në të njëjtën kohë, të metat e vlerësimit janë më të lehta për t’u zbuluar tani sesa do të kishin qenë shumë pak kohë më parë. Ndërsa aftësitë e modeleve përmirësohen, ne mund t’i përdorim ato modele për të inspektuar kërkesat, testet, korrigjimet, gjurmët dhe rastet ekstreme me shumë më tepër thellësi dhe konsistencë, duke ndihmuar në zbulimin e problemeve të standardeve që më parë ishin të kushtueshme ose jo praktike për t’u gjetur në shkallë të gjerë.

Ne shpresojmë që komuniteti më i gjerë i vlerësimit të zhvillojë standarde të reja të ndërtuara nga zhvillues softuerësh me përvojë posaçërisht për të testuar aftësitë e modeleve. Kjo qasje mund të ruajë nivelin e lartë dhe realizmin që duam në matjen e aftësive të modeleve, si dhe lejon një mbikëqyrje më të mirë nga njerëzit gjatë gjithë procesit. Duke pasur parasysh problemet e zbuluara në këtë analizë, ne e tërheqim rekomandimin tonë të mëparshëm për të përdorur SWE-Bench Pro.

Si përfundim, një vlerësim duhet të japë një sinjal domethënës përmes standardeve që janë të vështira për t’u manipuluar, të lehta për t’u besuar dhe që pasqyrojnë vërtet aftësinë ose përputhjen e modelit. Meqenëse këto rezultate japin informacione për vendimet e marra nga OpenAI për vendosjen në përdorim dhe sigurinë, vlerësimet që monitorojmë duhet të jenë të vlefshme dhe informuese.

Autor

OpenAI

Shënimet e fundit të faqes

  1. 1

    Ne i jemi referuar më parë kësaj kategori si teste të ngushta.

  2. 2

    Ne i jemi referuar më parë kësaj kategorie si teste të gjera.