Прескокни до главната содржина
OpenAI

Одвојување сигнал од шум во евалуации на кодирање

Преку детална ревизија, наоѓаме широко распространети проблеми со задачите во SWE-Bench Pro и проценуваме дека ~30% од задачите се неисправни.

Се вчитува...

Точното мерење на способностите на нашите модели е важно за здрави одлуки за распоредување и безбедност, вклучувајќи ги и одлуките според Рамка за подготвеност(се отвора во нов прозорец) на OpenAI. Со секое издание на модел, известуваме за резултати од разни надворешни и внатрешни реперни евалуации за да го следиме напредокот на моделот. Кога евалуациите имаат недостатоци што влијаат врз резултатите, тие можат да дадат погрешна слика за способностите, погрешно да ги претстават безбедносните аргументи и да влијаат врз истражувачките приоритети.

Ние неодамна истраживме како една од најшироко користените реперни евалуации за кодирање, SWE-bench Verified, имаше суштински проблеми со дизајнот и контаминацијата, и утврдивме дека евалуацијата веќе не дава значаен сигнал за способностите за развој на софтвер. Тогаш ја охрабривме пошироката заедница да премине на SWE-Bench Pro.

SWE-Bench Pro(се отвора во нов прозорец) беше дизајниран да го подобри SWE-bench Verified преку тестирање модели на подолги хоризонти и пореалистични задачи за кодирање, за подобро следење на способностите за кодирање со агент. Како и во SWE-bench Verified, задачите програмски се извлекуваат од историјата на промени на функции во сет јавни и приватни репозиториуми. Од моделите се бара да имплементираат решение што ги поминува новите тестови за одредена функција, без да ја наруши постојната функционалност. На јавната поделба со 731 задача, граничните модели ја подобрија стапката на поминување од 23,3% на 80,3% за осум месеци.

Оттогаш спроведовме слична ревизија на SWE-Bench Pro, прегледувајќи ја збирката податоци со цевковод за анализа на податочни точки. Цевководот ги прегледа обидите на моделот на задачата, метаподатоците за задачата и трагите од неуспех за да означи веројатни недостатоци во евалуацијата. Секоја означена задача потоа беше проценета преку повеќе премини со истражувачки агенти и независно прегледана од пет искусни софтверски инженери, а несогласувањата беа ескалирани за понатамошна истрага.

Наоѓаме докази за сериозни проблеми во значителен дел од збирката податоци. Нашиот цевковод за анализа на податочни точки означи 200 (27,4%) неисправни задачи, а кампањата за човечка анотација идентификува 249 (34,1%).

Проблемите главно спаѓаа во четири категории:

  • Претерано строги тестови1 наметнуваат конкретни детали од имплементацијата што не се наведени во промптот, со што поништуваат многу функционално точни поднесоци.
  • Недоволно специфицирани промптови2 изоставуваат барања што ги спроведуваат скриените тестови и што не можат разумно да се заклучат.
  • Тестови со мала покриеност недоволно ја проверуваат бараната функција, па нецелосни поправки можат да поминат.
  • Заведувачки промпт ги насочува моделите кон погрешно однесување или е во спротивност со она што го бараат тестовите.

Нашите наоди укажуваат на тешкотијата да се подготват тешки, но фер реперни евалуации, како и на растечката корисност на агентите за скалабилни проверки на квалитетот на податоците. Со оглед на овие резултати, проценуваме дека ~30% од задачите во SWE-bench Pro се неисправни и советуваме развивачите на модели внимателно да ги разгледуваат резултатите.

Методологија

Нашата цел е да обезбедиме неуспесите на задачите да одразуваат вистински ограничувања на моделот, а успешните задачи да одразуваат целосни и валидни решенија на барањата од промптот. За да го провериме квалитетот на податоците што се користат во евалуацијата, создадовме цевковод за обезбедување квалитет за да процениме дали секоја податочна точка точно ги одразува способностите на моделот.

Работен тек за обезбедување квалитет што комбинира автоматизирана проверка и човечки преглед за процена на квалитетот на задачите.

Почетен цевковод за квалитет на податоци означува проблеми за преглед. Потврдуваме со подлабока ревизија со помош на агент на означените задачи и со кампања за човечка анотација со искусни инженери.

Почетен автоматизиран филтер ги прегледува упатствата дадени на моделот, обидите на моделот да ја реши задачата и тестовите што се користат за оценување на тие обиди, за да означи веројатно неисправни или проблематични примери. Овој филтер означи 286 потенцијално неисправни задачи. Потоа спроведовме подлабок преглед на тој подскуп на два начина: преглед на агент под човечки надзор, кој врши обемни проверки со истражувачки агенти и финална човечка процена; и кампања за човечка анотација со искусни софтверски развивачи.

Преглед на агент под човечки надзор

Секој означен проблем се ревидира со истражувачки агенти базирани на Codex, на кои им беше даден пристап до репозиториумот и околината на задачата. Ова им помага да ја разликуваат разумната двосмисленост на задачата, која често може да се разреши со проучување на околниот код и конвенциите на репозиториумот, од вистинска недоволна специфицираност. Агентот може да извршува тестови, да прегледува датотеки во репото и да ги истражува обидите на моделот и нивните вообичаени начини на неуспех на задачата. По неколку независни повторувања на овие подлабоки ревизии, истражувач ги прегледа резимеата, донесе конечна процена и ги означи веројатните проблеми.

Кампања за човечка анотација

Паралелно, спроведовме кампања за човечка анотација врз означениот подскуп. Работевме со искусни софтверски инженери кои, пред да ги прегледуваат задачите, беа обучени за целите на реперната евалуација, таксономијата на проблеми и граничните случаи. Секоја задача ја прегледаа пет инженери.

Рецензентите формираа независна процена врз основа на видливиот опис на проблемот, тест-случаите и референтното решение како основна вистина (познато како gold patch), пред да ја користат анализата од цевководот или транскриптот како дополнителен контекст. Потоа рецензентите доделија ознака и оцена на сериозност врз основа на конкретни докази и ги ескалираа несогласувањата или случаите со мала сигурност за понатамошен преглед.

Човечките рецензенти поверојатно од истражувачките агенти ги означуваа задачите како неисправни. Имаше и одредено несогласување за категориите меѓу двете патеки на преглед, но кај ниедна означена задача „не е неисправна“ не беше најчестата човечка ознака. Кај категориите што ги означи цевководот со агент, процените на рецензентите се поклопуваа во 74% од случаите.

Во споредба со цевководот со агент, човечките рецензенти исто така почесто избираа повеќе ознаки за една задача, што укажува дека утврдиле дека задачите се неисправни на повеќе начини или не се вклопуваат јасно во една категорија. Ова сугерира дека цевководот агент-плус-рецензент доведе до конзервативно означување: ги опфати истите широки начини на неуспех што ги идентификуваа луѓето, но ги потцени случаите каде што рецензентите видоа дополнителни или преклопувачки проблеми. Најголемата разлика беше кај тестовите со мала покриеност, кои луѓето ги избраа како најчест проблем за 9,4% од реперната евалуација, во споредба со 4,1% од цевководот со агент.

Начини на неуспех

Во неколку случаи промптот за задачата пропишуваше конкретна имплементација, но скриените тест-случаи очекуваа поинакво однесување.

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":

Нема

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":

Нема

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.

Дискусија

Проблемите што ги идентификувавме, заедно со слични случаи во SWE-bench Verified, ја нагласуваат важноста од ригорозна проверка на реперните евалуации. Проблемите и pull request-ите од репозиториуми со отворен код првично биле создадени за човечка соработка, често преку долги разменувања меѓу одржувачи и придонесувачи. Како резултат, описите на проблемите, споениот код и unit тестовите не секогаш се усогласуваат во чисти, изолирани задачи за веродостојно оценување на моделите. Особено, тестовите вклучени во pull request-и можат да бидат претерано строги, бидејќи се напишани за да потврдат конкретна промена, а не да дефинираат стандард независен од имплементацијата за решавање на задачата.

Во исто време, недостатоците во евалуациите сега полесно се откриваат отколку што би било можно дури и пред кратко време. Како што се подобруваат способностите на моделите, можеме да ги користиме тие модели за многу подлабоко и поконзистентно да прегледуваме промптови, тестови, закрпи, траги и гранични случаи, што помага да се откријат проблеми во реперните евалуации што претходно беа скапи или непрактични за наоѓање во голем обем.

Се надеваме дека пошироката заедница за евалуации ќе развие нови реперни евалуации изградени од искусни софтверски развивачи, специјално за тестирање на способностите на моделите. Таквиот пристап може да ги зачува високите критериуми и реализмот што сакаме да ги мериме кај способностите на моделите и овозможува подобар човечки надзор низ целиот процес. Со оглед на проблемите откриени во оваа анализа, ја повлекуваме нашата претходна препорака за усвојување на SWE-Bench Pro.

На крајот, евалуацијата треба да дава значаен сигнал преку реперни евалуации што тешко се изигруваат, лесно им се верува и вистински ја одразуваат способноста или усогласеноста на моделот. Бидејќи овие резултати ги информираат одлуките на OpenAI за распоредување и безбедност, евалуациите што ги следиме треба да бидат валидни и информативни.

Автор

OpenAI

Фусноти

  1. 1

    Ние претходно ја нарекувавме оваа категорија тесни тестови.

  2. 2

    Претходно ја нарекувавме оваа категорија широки тестови.