Аудит OpenAI выявил серьёзные недостатки в SWE-Bench Pro

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

SWE-Bench Pro был представлен как более сильный преемник SWE-bench Verified, который OpenAI ранее критиковала за проблемы дизайна и загрязнения данных. Новый бенчмарк был разработан для проверки более длинных и реалистичных задач программирования, особенно такой многошаговой работы, которая ожидается от coding agents. Его задачи построены на изменениях функциональности в публичных и приватных репозиториях ПО. Модель должна написать код, который проходит новые тесты для функции, сохраняя при этом существующее поведение. На публичном наборе из 731 задачи frontier models, как сообщается, улучшили pass rate с 23,3% до 80,3% за восемь месяцев, что сделало бенчмарк важным сигналом прогресса в agentic coding.

Новый аудит OpenAI показывает, что этот сигнал гораздо более шумный, чем ожидалось. Компания использовала pipeline анализа data points, который изучал попытки моделей, метаданные задач и трассы ошибок, чтобы выявлять вероятные недостатки оценки. Затем отмеченные задачи проверялись через несколько проходов investigator agents и независимо рецензировались пятью опытными software engineers, а разногласия отправлялись на дополнительное расследование. Автоматизированный pipeline выявил 200 сломанных задач, или 27,4% публичного набора, а кампания человеческой разметки выявила 249 задач, или 34,1%. Поэтому OpenAI оценивает, что примерно треть задач SWE-Bench Pro может быть недействительной или вводящей в заблуждение как измерение способности к программированию.

Аудит сгруппировал основные проблемы в четыре категории. В некоторых задачах были чрезмерно строгие тесты, требовавшие конкретной детали реализации даже тогда, когда prompt её не задавал, поэтому функционально правильный ответ мог считаться неверным. В других задачах prompts были недостаточно специфицированы: скрытые тесты навязывали требования, которые модель не могла разумно вывести из видимых инструкций. В третьей группе были тесты с низким покрытием, то есть бенчмарк недостаточно хорошо проверял запрошенную функцию, и неполные исправления могли пройти. Наконец, некоторые prompts вводили в заблуждение, потому что направляли модели к поведению, противоречащему тому, что на самом деле требовали тесты.

OpenAI описывает цель аудита как проверку того, что неудачи и успехи означают именно то, чем кажутся. Проваленная задача должна указывать на реальную слабость модели, а не на плохой prompt или несправедливый скрытый тест. Пройденная задача должна означать, что модель создала полное и корректное решение, а не то, что тесты были слишком слабыми. Чтобы это проверить, OpenAI построила процесс quality assurance, который сначала использовал автоматический фильтр для анализа инструкций, решений моделей и проверочных тестов. Этот фильтр отметил 286 потенциально сломанных задач, которые затем были глубже проверены как с помощью agent-assisted analysis, так и через инженерную human review.

Agent-assisted review использовал investigator agents на базе Codex с доступом к репозиторию и окружению задачи. Эти агенты могли изучать файлы, запускать тесты, анализировать conventions репозитория и сравнивать распространённые паттерны ошибок моделей. Это должно было отличить допустимую неоднозначность от настоящей underspecification. В реальных software projects не каждое требование записано явно, и engineers часто выводят поведение из соседнего кода. Аудит пытался отделить такую нормальную контекстно-зависимую работу от задач, где бенчмарк действительно требовал чего-то, что prompt не поддерживал. После нескольких независимых запусков investigator agents исследователь просматривал summaries и ставил финальные issue labels.

Параллельно OpenAI провела кампанию human annotation с участием опытных software engineers, обученных целям бенчмарка, taxonomy проблем и edge cases. Каждую отмеченную задачу проверяли пять engineers. Рецензенты рассматривали видимое problem statement, test cases и reference solution, также называемое gold patch, а затем использовали pipeline analysis или transcripts как вспомогательный контекст. Эта комбинация automated triage, agent investigation и human review была задумана, чтобы сделать аудит более масштабируемым, но при этом сохранить привязку финальных суждений к профессиональной software engineering expertise.

Более широкий урок в том, что сложные бенчмарки программирования трудно курировать, потому что реалистичность и справедливость могут тянуть в разные стороны. Реальные software tasks часто требуют контекста, conventions и judgment, но бенчмарк всё равно должен определять успех достаточно чётко, чтобы корректные решения не отклонялись, а неполные решения не вознаграждались. По мере того как модели становятся сильнее, а benchmark scores быстро растут, небольшие недостатки в дизайне задач могут сильно влиять на интерпретацию прогресса. OpenAI советует model developers внимательно изучать результаты SWE-Bench Pro, а не воспринимать headline pass rates как чистое измерение способности к разработке ПО.

Аудит также указывает на растущую роль AI agents в проверке evaluation data. OpenAI использовала agents не как финальную инстанцию, а как масштабируемых investigators, которые могли изучать репозитории, запускать тесты и суммировать вероятные недостатки для human review. Это предлагает практический путь улучшения бенчмарков: использовать agents для поиска подозрительных data points в масштабе, а затем привлекать expert reviewers для финальных решений. Для AI safety и решений о развёртывании ключевой вопрос не только в том, насколько хорошо модели показывают себя, но и в том, заслуживают ли доверия тесты, используемые для их измерения.