Разделение сигнала и шума при оценке навыков программирования | OpenAI

В ходе детального аудита мы обнаружили широко распространенные проблемы с задачами в SWE-Bench Pro и подсчитали, что около 30% задач не работают должным образом.

• Методология
• Проверка агента под контролем человека
• Кампания по аннотированию человеком
• Обсуждение

• Методология
• Проверка агента под контролем человека
• Кампания по аннотированию человеком
• Обсуждение

Точное измерение возможностей наших моделей важно для принятия обоснованных решений по развертыванию и обеспечению безопасности, в том числе в рамках системы OpenAI Preparedness Framework (открывается в новом окне) . С каждым выпуском модели мы публикуем результаты по различным внешним и внутренним критериям для отслеживания прогресса модели. Если в оценках обнаруживаются недостатки, влияющие на результаты, это может привести к ложному пониманию возможностей, искажению обоснований безопасности и изменению приоритетов исследований.

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

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

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

Основные проблемы можно разделить на четыре категории:

• Чрезмерно строгие тесты 1 навязывают конкретные детали реализации, не указанные в запросе, что делает недействительными многие функционально корректные отправленные результаты.
• Неполные подсказки 2 опускают требования, которые обеспечиваются скрытыми тестами и которые нельзя разумно вывести.
• Тесты с низким уровнем покрытия проверяют запрошенную функцию, поэтому неполные исправления могут пройти проверку.
• Вводящая в заблуждение подсказка направляет модели к неправильному поведению или противоречит требованиям тестов.

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

Методология

Наша цель — обеспечить, чтобы неудачи в выполнении задач отражали реальные ограничения модели, а успехи в выполнении задач — полные и корректные решения заданных требований. Для проверки качества данных, используемых в оценке, мы создали конвейер обеспечения качества, позволяющий оценить, насколько каждая точка данных точно отражает возможности модели.

Первоначальный автоматизированный фильтр анализирует инструкции, данные модели, попытки модели решить задачу, и тесты, используемые для оценки этих попыток, чтобы выявить потенциально неработающие или проблемные примеры. Этот фильтр выявил 286 потенциально неработающих задач. Затем мы провели более глубокий анализ этого подмножества двумя способами: проверка с помощью агентов под наблюдением человека, которая включает в себя обширные проверки с агентами-исследователями и окончательное заключение человека; и кампания по аннотированию с участием опытных разработчиков программного обеспечения.

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

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

Кампания по аннотированию человеком

Параллельно мы провели кампанию по проверке отмеченного подмножества кода опытными специалистами. Мы работали с опытными инженерами-программистами, которые прошли обучение по целям бенчмарка, таксономии проблем и граничным случаям, прежде чем приступить к проверке задач. Каждую задачу проверяли пять инженеров.

Рецензенты самостоятельно выносили суждение, основываясь на явной формулировке проблемы, тестовых примерах и эталонном решении (известном как «золотой образец»), прежде чем использовать анализ конвейера или стенограмму в качестве подтверждающего контекста. Затем рецензенты присваивали метку и рейтинг серьезности на основе конкретных доказательств и передавали несогласия или случаи с низкой степенью достоверности на дальнейшее рассмотрение.

Люди-эксперты чаще, чем агенты-исследователи, отмечали задачи как неисправные. Также наблюдались некоторые разногласия в категориях между двумя путями проверки, но ни в одной отмеченной задаче «не неисправно» не было наиболее распространенной отметкой, используемой людьми. Из категорий, отмеченных конвейером агентов, суждения экспертов совпадали в 74% случаев.

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

Виды отказов

В нескольких случаях в подсказке к заданию указывалась конкретная реализация, но скрытые тестовые примеры предполагали другое поведение.

Эта задача включает в себя нормализацию записей оглавления и их преобразование обратно в Markdown с помощью TocEntry.to_markdown() . В подсказке к заданию указана сериализация вплоть до межсимвольного интервала, описано, как обеспечивается точное соблюдение интервалов и вертикальной черты, и приведены примеры, такие как » | Глава 1 | 1″ и «** | Глава 1 | 1» :

Никто

1 «[пробел]| Глава 1 | 1» 2 «**[пробел]| Глава 1 | 1» 3 «[пробел]| Просто заголовок | «

Вместо этого скрытые утверждения test_to_markdown требуют » | Глава 1 | 1″ и «** | Глава 1 | 1» :

Никто

1 «[пробел][пробел]| Глава 1 | 1» 2 «**[пробел][пробел]| Глава 1 | 1» 3 «[пробел][пробел]| Просто заголовок | «

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

Обсуждение

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

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

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

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

Источник: openai.com