OpenAI: аудит показал, что около 30% задач в бенчмарке SWE-Bench Pro сломаны

OpenAI отчитывается о возможностях своих моделей по набору внешних и внутренних бенчмарков, эти цифры влияют, в частности, на решения о безопасном развёртывании моделей в рамках собственной политики готовности к рискам (Preparedness Framework). Если в бенчмарке есть системные изъяны, он даёт искажённую картину возможностей модели. Ранее OpenAI уже обнаружила, что один из самых популярных бенчмарков для оценки кода, SWE-bench Verified, страдает фундаментальными проблемами дизайна и загрязнением данных (contamination) и перестал давать содержательный сигнал о реальных навыках разработки; тогда компания рекомендовала сообществу перейти на SWE-Bench Pro.
SWE-Bench Pro задумывался как более совершенная версия SWE-bench Verified: он тестирует модели на более длинных горизонтах и более реалистичных задачах, чтобы точнее отслеживать агентные навыки программирования. Как и в SWE-bench Verified, задачи берутся программно из истории реальных изменений функциональности в публичных и приватных репозиториях, модель должна реализовать решение, которое проходит новые тесты для новой функции, не ломая существующую функциональность. На публичной части датасета из 731 задачи доля успешных решений у топовых моделей выросла с 23,3% до 80,3% всего за восемь месяцев.
OpenAI провела аналогичный аудит и для SWE-Bench Pro, с помощью конвейера анализа отдельных задач (datapoint analysis pipeline), который изучал попытки моделей решить задачу, метаданные задач и трассы неудачных попыток, чтобы находить вероятные изъяны в оценке. Автоматический фильтр пометил 286 потенциально сломанных задач. Каждую помеченную задачу проверяли двумя параллельными способами: несколько независимых проходов ИИ-агентов-«следователей» на базе Codex с доступом к репозиторию и окружению задачи (это помогает отличить обычную неоднозначность формулировки, которую можно снять, изучив код рядом и конвенции репозитория, от настоящей недосказанности), после нескольких таких проходов исследователь-человек выносил финальное решение и присваивал ярлык вероятной проблемы; и отдельная кампания ручной разметки, где каждую задачу независимо оценивали пять опытных инженеров-программистов, прошедших обучение по целям бенчмарка, таксономии проблем и пограничным случаям. Люди сначала формировали собственное суждение по видимому условию задачи, тестам и эталонному решению (gold patch), и только потом сверялись с выводами конвейера как со вспомогательным контекстом; расхождения и случаи с низкой уверенностью эскалировались на дополнительную проверку.
Изъяны разбились на четыре категории: (1) слишком строгие тесты, они проверяют конкретную реализацию, не оговорённую в условии, из-за чего «заваливаются» многие функционально верные решения (раньше OpenAI называла эту категорию «узкими тестами»); (2) неполно сформулированные условия, в них отсутствуют требования, которые тем не менее проверяются скрытыми тестами и которые нельзя разумно вывести из текста задачи (раньше, «широкие тесты»); (3) тесты с низким покрытием, они недостаточно проверяют запрошенную функциональность, поэтому через них проходят неполные решения; (4) вводящая в заблуждение формулировка, условие задачи направляет модель к неверному поведению или прямо противоречит тому, что требуют тесты. Отдельно OpenAI приводит типичный пример подобного провала: формулировка задачи явно подразумевала конкретную реализацию, а скрытые тесты требовали другого поведения, модель наказывали за отступление от реализации, которая не была прямо прописана в условии.
Люди-рецензенты чаще, чем агенты-следователи, признавали задачи сломанными; по категориям изъянов мнения расходились, но ни в одной помеченной задаче большинство рецензентов-людей не сочло её исправной. Из категорий, которые отметил конвейер агентов, суждения людей совпали с ним в 74% случаев. При этом люди чаще ставили задаче сразу несколько ярлыков, то есть находили в ней проблему сразу нескольких типов или не могли уверенно отнести её к одной категории; это говорит о том, что связка «агент плюс рецензент» в целом даёт консервативную оценку, те же основные типы проблем, что видят люди, но с недоучётом случаев, где рецензенты находят дополнительные или пересекающиеся изъяны. Самый большой разрыв, по тестам с низким покрытием: люди назвали их главной проблемой у 9,4% всего бенчмарка против 4,1% по оценке конвейера агентов.
OpenAI объясняет системную причину: задачи и пул-реквесты в открытом коде изначально создавались для совместной работы людей, часто через долгую переписку между мейнтейнерами и авторами правок, поэтому описание проблемы, итоговый код и юнит-тесты не всегда складываются в чистую, изолированную задачу для надёжной оценки моделей. В частности, тесты внутри пул-реквестов часто пишутся, чтобы проверить одно конкретное изменение, а не задать независимый от реализации стандарт решения задачи, отсюда и слишком строгие тесты. При этом сами изъяны бенчмарков стало проще находить: возросшие возможности моделей позволяют куда глубже и последовательнее, чем раньше, проверять условия, тесты, патчи, трассы и пограничные случаи, то, что раньше было слишком дорого или трудозатратно делать в таком масштабе. OpenAI надеется, что сообщество разработает новые бенчмарки, которые с нуля создают опытные инженеры-программисты специально для проверки возможностей моделей, такой подход позволит сохранить высокую планку и реалистичность задач при лучшем контроле со стороны людей. С учётом вскрытых проблем компания отзывает свою более раннюю рекомендацию переходить на SWE-Bench Pro и подчёркивает: раз именно такие оценки влияют на решения OpenAI о безопасном развёртывании моделей, бенчмарки обязаны быть достоверными и информативными.
Ключевые факты
- OpenAI: около 30% задач в бенчмарке SWE-Bench Pro сломаны, из-за слишком строгих тестов, неполно сформулированных условий, тестов с низким покрытием и вводящих в заблуждение формулировок.
- Ранее OpenAI уже признала непригодным SWE-bench Verified (проблемы дизайна и загрязнение данных) и тогда рекомендовала перейти на SWE-Bench Pro, теперь эта рекомендация отозвана.
- На публичном сплите из 731 задачи доля успешных решений топовых моделей выросла с 23,3% до 80,3% за восемь месяцев, именно эти цифры теперь под вопросом.
- Методика проверки: автофильтр пометил 286 задач, каждую оценивали и Codex-агенты-«следователи», и пять независимых инженеров-людей; совпадение категорий, в 74% случаев.
- Крупнейшее расхождение агентов и людей, тесты с низким покрытием: люди сочли их главной проблемой у 9,4% бенчмарка против 4,1% по оценке агентов.
Почему это важно
OpenAI использует внешние и внутренние бенчмарки, включая SWE-Bench Pro, чтобы отслеживать реальный прогресс моделей и принимать решения о безопасном развёртывании, в том числе в рамках собственной политики готовности к рискам (Preparedness Framework). Если в бенчмарке сломана почти треть задач, громкие цифры прогресса, вроде роста доли успешных решений с 23,3% до 80,3% за восемь месяцев, перестают быть надёжным индикатором реальных возможностей моделей. Это уже вторая крупная кодовая оценка подряд (после SWE-bench Verified), которую OpenAI сама признаёт непригодной, вопрос доверия к бенчмаркам кодинга и агентных навыков встаёт для всей индустрии, а не только для OpenAI.
Кому это важно
Лабораториям, которые сравнивают модели по агентным навыкам программирования и публикуют результаты на SWE-Bench Pro как аргумент в конкурентной борьбе; исследователям и инженерам, создающим и поддерживающим бенчмарки для ИИ; командам, разрабатывающим ИИ-агентов для кодинга, чьи маркетинговые заявления опираются на такие цифры; и всем, кто читает лидерборды моделей как источник истины о том, какая модель лучше пишет код.
Как это применить
OpenAI прямо советует разработчикам моделей не доверять сырым цифрам SWE-Bench Pro без проверки и отзывает собственную более раннюю рекомендацию переходить на этот бенчмарк. Практический рецепт для команд, которые строят или используют бенчмарки: не полагаться на один автоматический прогон, а выстраивать конвейер проверки, автоматический фильтр подозрительных задач, затем независимые проходы ИИ-агентов-«следователей» с доступом к репозиторию, и отдельно оценка несколькими живыми инженерами, которые сначала формируют своё мнение по условию, тестам и эталонному решению и только потом сверяются с выводами агентов. Четыре категории изъянов из статьи (слишком строгие тесты, неполно сформулированные условия, низкое покрытие тестами, вводящая в заблуждение формулировка) можно использовать как готовый чек-лист при аудите любого бенчмарка кода, не только SWE-Bench Pro.
Можно ли доверять
Методика описана довольно подробно и с конкретными цифрами: автофильтр отметил 286 задач, каждую разбирали и агенты на базе Codex, и пять независимых опытных инженеров-людей, при этом совпадение категорий между агентами и людьми, 74%, а по отдельным категориям (например, тесты с низким покрытием, 9,4% против 4,1%) приведена точная разбивка расхождений. Это выгодно отличает материал от голословных заявлений. При этом стоит учитывать: аудит полностью самостоятельный, OpenAI одновременно оценивала чужой бенчмарк и обнародовала результат без независимой стороны, которая перепроверила бы её методологию; кроме того, именно OpenAI ранее рекомендовала SWE-Bench Pro сообществу, так что часть мотивации публикации, снять с себя ответственность за прежний совет. Сама находка при этом выглядит правдоподобной и согласуется с более ранней историей о проблемах SWE-bench Verified.
Риски и подводные камни
Если почти треть задач популярного бенчмарка агентного кодинга сломана, все прежние сравнения моделей и маркетинговые заявления, опиравшиеся на цифры SWE-Bench Pro, нужно пересматривать: модели могли переобучаться под особенности сломанных тестов, либо подстраиваясь под конкретную реализацию, которую требуют слишком строгие тесты, либо получая незаслуженный зачёт благодаря тестам с низким покрытием. Более широкий риск в том, что это уже второй крупный кодовый бенчмарк подряд с системными изъянами, значит, у индустрии, вероятно, есть и другие широко цитируемые оценки со скрытыми проблемами, которые пока никто не аудировал так же тщательно, а самостоятельные аудиты лабораторий без внешней проверки сами по себе не решают проблему доверия к бенчмаркам.
«В конечном счёте оценка должна давать содержательный сигнал за счёт бенчмарков, которые трудно обмануть, которым легко доверять и которые по-настоящему отражают возможности модели или её согласованность (alignment).»
— OpenAI, блог «Separating signal from noise in coding evaluations»