Представляем SWE-bench Verified13.08.2024 10:00

Обновлено 24 февраля 2025 г.

В рамках нашей методологии обеспечения готовности (Preparedness Framework)⁠ OpenAI разрабатывает ряд метрик для отслеживания, оценки и прогнозирования способностей моделей действовать автономно. Способность автономно решать задачи по разработке программного обеспечения является ключевым компонентом нашего среднего (Medium) уровня риска в категории «Автономность моделей» (Model Autonomy). Оценка этих возможностей сопряжена со сложностями из-за комплексности задач софта, трудности точной оценки сгенерированного кода и сложности симуляции сценариев реальной разработки. Поэтому наш подход к обеспечению готовности также должен включать тщательный анализ самих оценок, чтобы снизить вероятность недооценки или переоценки производительности в важных категориях риска.

Один из самых популярных наборов тестов для оценки программной инженерии — это SWE-bench⁠1, бенчмарк для оценки способностей больших языковых моделей (LLM) решать реальные программные проблемы, взятые из GitHub. Бенчмарк заключается в том, что агентам предоставляются репозиторий кода и описание проблемы, а также ставится задача сгенерировать патч, устраняющий описанную проблему. Кодинг-агенты добились впечатляющих успехов на SWE-bench: лучшие агенты набирают 20% в SWE-bench и 43% в SWE-bench Lite, согласно таблице лидеров SWE-bench⁠ по состоянию на 5 августа 2024 года.

Наше тестирование выявило некоторые задачи SWE-bench, которые могут оказаться сложными или невыполнимыми, что приводит к тому, что SWE-bench систематически недооценивает автономные возможности моделей в области программной инженерии. Мы поработали совместно с авторами SWE-bench над решением этих проблем в новом релизе бенчмарка, который должен обеспечить более точную оценку.

Каждый образец в тестовом наборе SWE-bench создан на основе решенной проблемы GitHub в одном из 12 открытых репозиториев на Python на GitHub. С каждым образцом связан пулл-реквест (PR), который включает в себя как код решения, так и модульные тесты для проверки корректности кода. Эти модульные тесты завершаются с ошибкой до того, как код решения в PR будет добавлен, но успешно проходят после него, поэтому они называются FAIL_TO_PASS тестами. Каждый образец также имеет связанные PASS_TO_PASS тесты, которые проходят успешно как до, так и после слияния PR, и используются для проверки того, что существующий несвязанный функционал в кодовой базе не был нарушен PR. 

Для каждого образца в SWE-bench агентам предоставляется исходный текст из проблемы GitHub, известный как постановка проблемы (problem statement), и предоставляется доступ к кодовой базе. Получив это, агенты должны отредактировать файлы в кодовой базе для решения проблемы. Тесты агенту не показываются.

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

Учитывая потенциальную значимость SWE-bench для методологии Preparedness Framework, мы стремились найти способы повышения надежности и устойчивости бенчмарка. Мы выделили три основные области для улучшения2:  

1. Модульные тесты, используемые для оценки правильности решения, часто излишне специфичны, а в некоторых случаях даже не связаны с проблемой. Это потенциально приводит к отклонению правильных решений. 
2. Многие образцы имеют недостаточно подробное описание проблемы, что приводит к двусмысленности в отношении того, в чем заключается проблема и как ее следует решать.
3. Иногда бывает трудно надежно настроить среды разработки SWE-bench для агентов, из-за чего модульные тесты непреднамеренно завершаются с ошибкой независимо от решения. В таких случаях совершенно верные решения могут быть оценены как неверные.

Ниже приведен пример, иллюстрирующий первую из этих проблем.

Образец SWE-bench scikit-learn__scikit-learn-14520 ставит перед агентом задачу решить проблему в репозитории scikit-learn⁠. В этой постановке проблемы сообщается, что аргумент функции copy может быть задан пользователем, но игнорируется библиотекой (вместо этого поведение жестко закодировано внутри функции):

Агенту, столкнувшемуся с вышеуказанной проблемой, сначала придется разобраться с двусмысленностью в отношении того, является ли поведение функции задуманным или багом, а затем внести изменения в кодовую базу для решения проблемы. Согласно настройке SWE-bench, любое предложенное агентом решение должно пройти следующий тест, извлеченный из пулл-реквеста, который изначально разрешил проблему⁠:

Этот тест явно проверяет, что решение должно вызывать предупреждение DeprecationWarning всякий раз, когда используется параметр copy, хотя исходная постановка проблемы в тексте проблемы выше не передает это требование. Более того, даже если бы агент понял, что нужно вызывать DeprecationWarning, тест также требует, чтобы агент точно соответствовал сообщению об устаревании (deprecation message), к которому пришли только после некоторого обсуждения в PR, к которому у агента нет доступа.

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

Для решения этих проблем мы запустили кампанию по аннотированию с привлечением профессиональных разработчиков программного обеспечения для проверки каждого образца из тестового набора SWE-bench на предмет наличия подходящих по объему модульных тестов и четко сформулированных описаний проблем.

Совместно с авторами SWE-bench мы выпускаем SWE-bench Verified: подмножество исходного тестового набора SWE-bench, состоящее из 500 образцов, проверенных нашими аннотаторами как не содержащие проблем. Эта версия заменяет оригинальные наборы тестов SWE-bench и SWE-bench Lite. Кроме того, мы публикуем наши аннотации для всех тестовых образцов SWE-bench. Эти аннотации позволяют разбивать датасет по степени сложности. Подмножество «легких» задач (easy) состоит из 196 задач, решаемых менее чем за 15 минут, а подмножество «сложных» (hard) — из 45 задач, занимающих более 1 часа.

Мы также сотрудничали с авторами SWE-bench в деле разработки нового фреймворка оценки для SWE-bench⁠, который использует контейнеризованные среды Docker, чтобы сделать тестирование на SWE-bench более простым и надежным.

В бенчмарке SWE-bench Verified модель GPT‑4o решает 33,2% образцов3, в то время как лучший из существующих Open-Source фреймворков (скаффолдов), Agentless, удвоил свой предыдущий результат в 16% на SWE-bench.

Мы работали с 93 разработчиками ПО, имеющими опыт работы с Python, чтобы вручную проверить образцы SWE-bench на качество. Мы проаннотировали 1699 случайных образцов из тестового набора SWE-bench, чтобы получить SWE-bench Verified. Следующий анализ основан на этих 1699 образцах.

Мы аннотируем образцы, чтобы зафиксировать:

• Считаем ли мы описание проблемы недостаточно подробным и, следовательно, некорректным для тестирования.
• Отсеивают ли модульные тесты FAIL_TO_PASS правильные решения.

Каждый критерий аннотирования имеет метку в диапазоне [0, 1, 2, 3] по мере возрастания степени серьезности. Метки 0 и 1 являются незначительными; метки 2 и 3 являются серьезными и указывают на то, что образец в каком-то отношении неадекватетен и должен быть отброшен. Мы решили проводить аннотирование по четырем порядковым категориям, а не по одной бинарной метке (серьезно/не серьезно), чтобы зафиксировать более детальные подробности.

Кроме того, мы оцениваем сложность каждого образца, предлагая аннотаторам оценить, сколько времени потребуется разработчику на принятие решения и реализацию решения, предполагая, что образец не содержит проблем. Наконец, мы предоставляем возможность ввода произвольного текста для указания любых других серьезных проблем с образцом (например, если модульные тесты FAIL_TO_PASS можно легко обойти, это может привести к тому, что неверное решение будет отмечено как правильное).

Наша команда инженеров сначала вручную разметила 50 образцов с высокой степенью достоверности для использования в вводных тестах для аннотаторов. Чтобы принять участие в кампании по аннотированию, каждый потенциальный аннотатор должен был пройти наши вводные тесты. Мы предоставляли подробные отзывы каждому аннотатору на протяжении всего вводного обучения, чтобы лучше подготовить их к задаче. Аннотаторы не обязательно были предварительными экспертами в кодовых базах, относящихся к SWE-bench, но им было предоставлено время для ознакомления с каждой кодовой базой, с которой они работали.

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

Полный текст наших правил аннотирования можно найти здесь⁠.

Для создания SWE-bench Verified мы отфильтровываем любой образец из исходного тестового набора, у которого либо постановка проблемы, либо модульные тесты FAIL_TO_PASS имеют объединенную метку степени серьезности 2 или выше. Мы также отфильтровываем все образцы, у которых отмечены другие крупные проблемы. Учитывая наш метод ансамблирования, это эквивалентно отсеву образцов, для которых хотя бы один из трех аннотаторов отметил проблему. Такой подход приводит к более высокой доле ложноположительных результатов при удалении образцов, но помогает повысить нашу уверенность в качестве образцов для финального датасета. 

Мы включаем как можно больше образцов со сложностью 1–4 часа и более 4 часов, а затем случайным образом выбираем оставшиеся, чтобы получить 500 образцов, составляющих SWE-bench Verified.

Результаты нашего аннотирования приведены ниже:

Мы видим, что 38,3% образцов были помечены как имеющие недостаточно подробное описание проблем, а 61,1% — как содержащие модульные тесты, которые могут неправомерно помечать правильные решения как неверные. В целом, в результате процесса аннотирования 68,3% образцов SWE-bench были отфильтрованы из-за недостаточной детализации, некорректных модульных тестов или других проблем. Как обсуждалось ранее, этот процесс фильтрации, вероятно, излишне строг, но он позволяет нам быть абсолютно уверенными в применимости отфильтрованных образцов.

Ниже мы приводим несколько примеров образцов и их аннотаций, специально отобранных для иллюстрации разнообразия качества образцов:

Используя наш новый датасет SWE-bench Verified, мы протестировали производительность GPT‑4o с помощью нескольких открытых каркасов (scaffolds), показавших хорошие результаты в оригинальных таблицах лидеров SWE-bench4.

Мы обнаружили, что производительность GPT‑4o с лучшим каркасом достигает 33.2% на SWE-bench Verified, более чем в два раза превосходя результат в 16% на оригинальном SWE-bench. В целом это подтверждает наше первоначальное подозрение, что оригинальный датасет SWE-bench недооценивает возможности агентов. Обратите внимание, что скачок от SWE-bench Lite к SWE-bench Verified не столь значителен, поскольку SWE-bench Lite уже был отфильтрован таким образом, чтобы сделать его проще⁠ полного датасета, хотя этот процесс не охватывал полностью те же проблемы, что и наша процедура фильтрации.

Рост производительности при оценке на SWE-bench Verified отчасти может объясняться смещением распределения в сторону более простых задач (как было показано в предыдущих анализах). Однако наша цель — не завышение показателей бенчмарка, а обеспечение того, чтобы бенчмарк достоверно отражал возможности моделей на любом заданном уровне сложности.

Мы исследуем это, строя график производительности с разбивкой по уровню сложности. Если бы наш новый набор данных просто сместил распределение сложности в сторону большего числа простых задач, производительность внутри каждой категории не изменилась бы, как это наблюдается при переходе от оригинального SWE-bench к SWE-bench Lite. Вместо этого мы замечаем, что производительность растет внутри отдельных категорий сложности при переходе к SWE-bench Verified, что согласуется с ожидаемым эффектом удаления невыполнимых задач из всех категорий, а не удаления сложных задач. Этот эффект наиболее очевиден в двух самых простых диапазонах сложности, где у нас больше всего задач.

Мы используем SWE-bench в качестве одного из нескольких тестов для отслеживания среднего уровня риска (Medium risk level) в категории риска «Автономность моделей» (Model Autonomy) в рамках нашей структуры Preparedness Framework. Отслеживание уровней катастрофического риска с помощью оценок опирается на уверенность в том, что мы можем доверять результатам тестирования и правильно понимаем, что именно означают баллы.

Наш опыт подсказывает, что нам следует:

Инвестировать в глубокое понимание наших бенчмарков. Хотя SWE-bench был тщательно продуман, он недооценивает возможности моделей из-за проблем, упомянутых в этом блоге. По мере того как наши системы приближаются к ОИИ (AGI), нам необходимо тестировать их на все более сложных задачах. Это также повышает требования к уровню квалификации и внимания, необходимым для курирования и проверки бенчмарков, чтобы гарантировать их достаточную сложность и надежность (в этом случае может быть полезной такая работа, как CriticGPT⁠, которая исследует возможности помощи ИИ в процессах разметки).

Учитывать прогресс в экосистеме. Развитие каркасов агентов (agent scaffolding) силами сообщества подчеркивает необходимость учета потенциальных внешних улучшений модели при оценке риска. Глядя на разницу между наихудшими и наилучшими каркасами для конкретной модели в таблицах лидеров SWE-bench⁠, мы видим, например, что производительность GPT-4 на SWE-bench Lite варьируется от 2,7% при использовании раннего каркаса на основе RAG до 28.3% при использовании CodeR. Таким образом, Preparedness Framework требует проведения оценок непрерывно и так часто, как это необходимо для выявления любых существенных изменений возможностей; это включает этапы до, во время и даже после обучения, когда модели могут быть улучшены за счет интеграции с внешними системами. Более того, курирование оценок — это задача всей экосистемы, и мы надеемся продолжить сотрудничество с исследователями в создании надежных и высококачественных оценок.

Понимать ограничения. Оценки на основе статических наборов данных по своей сути ограничены, и SWE-bench не является исключением. Учитывая, что бенчмарк состоит из дампов публичных репозиториев GitHub, крупные базовые модели, предварительно обученные на текстах из интернета, вероятно, имеют проблему загрязнения данных (contamination) по этим задачам. Кроме того, SWE-bench охватывает лишь узкое распределение среднего уровня риска для автономности моделей, поэтому его необходимо дополнять другими оценками. 

Мы верим в эмпирический и научный подход к отслеживанию катастрофических рисков и защите от них. Создание и постоянное совершенствование оценок — ключевой элемент этой работы. Еще многое предстоит сделать, и мы с нетерпением ждем новых работ от сообщества по созданию ценных бенчмарков, подобных SWE-bench. 

SWE-bench Verified доступен для скачивания здесь⁠; полный набор наших аннотаций доступен здесь⁠, а наши критерии аннотирования (rubric) — здесь⁠.