Отделяне на сигнала от шума в оценките за кодиране

Точното измерване на възможностите на нашите модели е важно за обосновани решения за внедряване и безопасност, включително решения по Рамката за готовност⁠(отваря се в нов прозорец) на OpenAI. При всяка версия на модел съобщаваме резултати от различни външни и вътрешни бенчмаркове, за да проследяваме напредъка на моделите. Когато оценките имат недостатъци, които влияят на резултатите, те могат да създадат погрешна представа за възможностите, да изкривят аргументите за безопасност и да повлияят на изследователските приоритети.

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

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

Оттогава извършихме подобен одит на SWE-Bench Pro, като прегледахме набора от данни чрез конвейер за анализ на точки от данни. Конвейерът прегледа опитите на моделите по задачата, метаданните на задачата и следите от неуспехи, за да маркира вероятни недостатъци в оценяването. След това всяка маркирана задача беше оценена чрез многократни преминавания с разследващи агенти и независимо прегледана от петима опитни софтуерни инженери, като несъгласията се ескалираха за допълнително разследване.

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

• Прекалено строгите тестове¹ налагат конкретни детайли на реализацията, които не са посочени в подканата, и обезсилват много функционално правилни решения.
• Недостатъчно уточнените подкани² пропускат изисквания, които скритите тестове налагат и които не могат разумно да се изведат.
• Тестовете с ниско покритие проверяват заявената функционалност недостатъчно, така че непълни поправки могат да преминат.
• Подвеждаща подкана насочва моделите към грешно поведение или противоречи на това, което тестовете изискват.

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

Целта ни е да гарантираме, че неуспехите по задачи отразяват реални ограничения на модела, а успехите по задачи отразяват пълни и валидни решения на изискванията в подканата. За да проверим качеството на данните, използвани в оценяването, създадохме конвейер за осигуряване на качество, който оценява дали всяка точка от данни точно отразява възможностите на модела.

Първоначален автоматизиран филтър преглежда инструкциите, дадени на модела, опитите на модела да реши задачата и тестовете, използвани за оценяване на тези опити, за да маркира вероятно дефектни или проблемни примери. Този филтър маркира 286 потенциално дефектни задачи. След това извършихме по-задълбочен преглед на това подмножество по два начина: преглед от Агент под човешки надзор, който провежда обстойни проверки с разследващи агенти и финална човешка преценка; и кампания за човешко анотиране с опитни софтуерни разработчици.

Всеки маркиран проблем се одитира с базирани на Codex разследващи агенти, на които беше предоставен достъп до хранилището и средата на задачата. Това им помага да разграничават разумната неяснота в задачата, която често може да се разреши чрез изучаване на близкия код и конвенциите на хранилището, от истинската недостатъчна спецификация. Агентът може да изпълнява тестове, да преглежда файлове в хранилището и да изследва опити на модели и техните общи режими на отказ по задачата. След няколко независими повторения на тези по-задълбочени одити изследовател прегледа резюметата, направи окончателна преценка и постави етикети на вероятните проблеми.

Успоредно с това проведохме кампания за човешко анотиране върху маркираното подмножество. Работихме с опитни софтуерни инженери, които бяха обучени за целите на бенчмарка, таксономията на проблемите и граничните случаи, преди да преглеждат задачи. Всяка задача беше прегледана от петима инженери.

Рецензентите формираха независима преценка въз основа на видимото условие на задачата, тестовите случаи и еталонното референтно решение (известно като gold patch), преди да използват анализа от конвейера или транскрипта като подпомагащ контекст. След това рецензентите присвояваха етикет и оценка на тежестта въз основа на конкретни доказателства и ескалираха несъгласията или случаите с ниска увереност за допълнителен преглед.

Човешките рецензенти бяха по-склонни от разследващите агенти да отбелязват задачите като дефектни. Имаше и известни разногласия по категориите между двата пътя за преглед, но при нито една маркирана задача „не е дефектна“ не беше най-често срещаният човешки етикет. При категориите, маркирани от агентния конвейер, преценките на рецензентите се припокриваха в 74% от случаите.

В сравнение с агентния конвейер човешките рецензенти също по-често избираха няколко етикета за една задача, което показва, че са намирали задачите за дефектни по няколко начина или че те не са се вписвали чисто в една категория. Това предполага, че конвейерът с агенти и рецензенти е довел до консервативно етикетиране: той е уловил същите широки режими на отказ, които са идентифицирали хората, но е подценил броя на случаите, в които рецензентите са видели допълнителни или припокриващи се проблеми. Най-голямата разлика беше при тестовете с ниско покритие, които хората избраха като най-честия проблем за 9,4% от бенчмарка спрямо 4,1% от агентния конвейер.

Проблемите, които идентифицирахме, заедно с подобни случаи в SWE-bench Verified, подчертават колко е важно бенчмарковете да се проверяват стриктно. Проблемите и pull request-ите от хранилища с отворен код първоначално са създадени за човешко сътрудничество, често чрез дълги обсъждания между поддържащи и допринасящи участници. В резултат описанията на проблемите, слетият код и unit тестовете невинаги се подреждат в ясни, изолирани задачи за надеждно оценяване на модели. По-специално тестовете, включени в pull request-и, могат да бъдат прекалено строги, защото са написани да валидират конкретна промяна, а не да дефинират независим от реализацията стандарт за решаване на задачата.

Същевременно недостатъците в оценяването вече се откриват по-лесно, отколкото биха се откривали дори преди кратко време. С подобряването на възможностите на моделите можем да използваме тези модели, за да проверяваме подкани, тестове, корекции, следи и гранични случаи с много по-голяма дълбочина и последователност, което помага да се откриват проблеми в бенчмарковете, които преди са били скъпи или непрактични за намиране в мащаб.

Надяваме се по-широката общност за оценяване да разработи нови бенчмаркове, създадени от опитни софтуерни разработчици специално за тестване на възможностите на моделите. Този подход може да запази високия стандарт и реализма, които искаме при измерването на възможностите на моделите, и позволява по-добър човешки надзор през целия процес. Предвид проблемите, разкрити в този анализ, оттегляме предишната си препоръка за приемане на SWE-Bench Pro.

В крайна сметка една оценка трябва да дава смислен сигнал чрез бенчмаркове, които трудно се манипулират, лесно вдъхват доверие и наистина отразяват възможностите или подравняването на модела. Тъй като тези резултати информират решенията на OpenAI за внедряване и безопасност, оценките, които проследяваме, трябва да бъдат валидни и информативни.