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

Точное измерение возможностей наших моделей важно для обоснованных решений о развертывании и безопасности, включая решения в рамках Программы готовности⁠(открывается в новом окне) 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 requests в репозиториях с открытым исходным кодом изначально создавались для совместной работы, которая часто сопровождается долгими обсуждениями между кураторами проекта и авторами кода. Из-за этого описания задач, влитый код и юнит-тесты не всегда образуют четкие, изолированные задания, пригодные для надежного тестирования моделей.

В то же время недостатки оценок сейчас обнаруживать легче, чем было бы даже совсем недавно. По мере роста возможностей моделей мы можем использовать эти модели, чтобы гораздо глубже и последовательнее проверять промпты, тесты, патчи, трассировки и пограничные случаи, помогая выявлять проблемы бенчмарков, которые раньше было дорого или непрактично находить в масштабе.

Мы надеемся, что широкое сообщество специалистов по оценкам разработает новые бенчмарки, созданные опытными разработчиками ПО специально для проверки возможностей моделей. Такой подход может сохранить высокий стандарт и реализм, которые нужны нам для измерения возможностей моделей, и обеспечивает более качественный человеческий надзор на протяжении всего процесса. Учитывая проблемы, выявленные в этом анализе, мы отзываем нашу прежнюю рекомендацию использовать SWE-Bench Pro.

В конечном счете оценка должна давать значимый сигнал через бенчмарки, которые трудно обмануть, которым легко доверять и которые действительно отражают возможности модели или ее выравнивание. Поскольку эти результаты влияют на решения OpenAI о развертывании и безопасности, отслеживаемые нами оценки должны быть валидными и информативными.