⚡️The End of SWE-Bench Verified — Mia Glaese & Olivia Watkins, OpenAI Frontier Evals & Human Data

⚡️Конец SWE-Bench Verified — Mia Glaese и Olivia Watkins, OpenAI Frontier Evals & Human Data

Объявлены первые спикеры AIE Europe и AIEi Miami. Увидимся там!

Мы уже не раз с лёгкой иронией отмечали микроскопические приросты по SWE-Bench Verified при выходе каждой новой фронтир-модели (переход с Opus 4.5 на 4.6 буквально дал минус 0.1%), но совсем другое дело — когда оригинальные авторы SWE-Bench Verified сами принимают решение прекратить его публиковать.

Мы были рады, что Mia Glaese — оригинальный соавтор SWE-Bench Verified и VP of Research, отвечающая за команды Frontier Evals, Human Data и Alignment, — и Olivia Watkins, ресёрчер из Frontier Evals, заглянули обсудить решение публично отказаться от SWE-Bench Verified и поддержать SWE-Bench Pro:

Дискуссия о насыщении SWE-Bench идёт в сообществе уже больше года — большинство фронтир-моделей стабильно показывают около 80%, при этом авторы оригинального SWE-Bench по-прежнему утверждают, что «потолок» для разговоров о насыщении лежит ближе к 87–95%, то есть запас ещё есть — даже на отфильтрованном наборе из 500 задач в Verified.

Но OpenAI провела более глубокий разбор 138 проблемных задач (привлекая ШЕСТЕРЫХ дополнительных инженеров для просмотра всех кейсов) и обнаружила две дополнительные проблемы, которые и привели к сегодняшнему решению:

>60% оставшихся задач нерешаемы: в подкасте Mia объясняет, что 49 тестов слишком узко определены (и потому отвергают функционально корректные решения), а 26 тестов «слишком широкие» — они ищут дополнительные фичи, которые вообще не упоминались в постановке задачи.Обучение на тестах: это банальная контаминация — она часто случается даже без намеренного списывания. Задачи SWE-bench берутся из open-source репозиториев, которые многие провайдеры моделей используют для обучения, а сама популярность SWE-bench означает, что примеры со временем просачиваются в другие корпусы.

Эти находки появились одновременно. Внимательный разбор того, как GPT-5.2 умудрился решить «нерешаемые» задачи, заставил команду заглянуть в цепочку рассуждений и найти там требования к тестам, которые нигде не были специфицированы, но при этом известны модели.

Контаминация

Последний пункт о контаминации — самый убийственный, и его проще всего проиллюстрировать. OpenAI обнаружила примеры того, как ВСЕ фронтир-модели, начиная с моделей самой OpenAI, способны дословно воспроизвести исходный эталонный патч или постановку задачи из эвала с минимальным промптом — просто по Task ID из SWE-Bench Verified:

Невозможные тесты

Более внимательная проверка людьми легко выявила задачи SWE-Bench Verified, которые в принципе невозможно пройти… если только не знать ответ заранее.

Что дальше

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

Дополнительный благородный жест — то, что OpenAI поддерживает бенчмарк, на котором сама даже не близка к SOTA: даже Gemini 3 показывает лучшие результаты, чем GPT 5.x:

Но очевидно, что команда смотрит в сторону более глубоких эвалов — более открытых и основанных на рубриках, похожих на их собственную работу над GDPVal. Среди свойств, которые, по словам Mia, они ищут:

Более долгосрочные задачиОткрытые архитектурные решенияКачество и поддерживаемость кодаСоздание реальных продуктовОтслеживание реального использования и влиянияОценка с участием человека (требующая доменных знаний и субъективной оценки качества)

Похоже, в 2026 году нас ждёт целый новый набор фронтир-эвалов — а ещё мы обсудили, как всё это связано с Preparedness Framework OpenAI, который снаружи компании плохо понят.

Таймкоды

00:00 Знакомство с командой Frontier Evals00:56 Почему SWE-Bench застрял01:47 Как создавался Verified04:32 Контаминация в дикой природе06:16 Несправедливые тесты и узкие спецификации08:40 Когда бенчмарки насыщаются10:28 Переход на SWE-Bench Pro12:31 Что измеряют хорошие кодинг-эвалы18:17 За пределами тестов: доллары и автономия21:49 Preparedness и будущие направления

Транскрипт

[00:00:00] Знакомство с командой Frontier Evals

[00:00:00] swyx: Окей. Привет. Мы в студии PI с Mia и Olivia из команды Frontier Evals. Или как вы сами хотите представиться. Может, представитесь — имя, чем занимаетесь в OpenAI, и начнём.

[00:00:16] Olivia: Конечно. Привет, я Olivia, работаю в команде Frontier Evals.

[00:00:19] swyx: Отлично. Pete.

[00:00:20] Mia: Привет, я Mia. Я VP of Research в OpenAI, и мои команды — это команда Codex, команда Human Data и команда Alignment. И мы много работаем с командой Olivia по Frontier.

[00:00:33] swyx: Да. Очень здорово. И насколько я понимаю, вы были частью той самой команды, которая работала и над SWE-Bench Verified.

[00:00:38] Mia: Да. Команда Olivia — Frontier-команда — и команда Human Data вместе работали над созданием SWE-Bench Verified.

[00:00:45] swyx: То есть вы наблюдали эволюцию кодинг-бенчмарков со временем. Кажется, это было где-то в середине-конце 2024-го, когда вы впервые опубликовали Verified. С тех пор многое изменилось.

[00:00:56] Почему SWE-Bench застрял

[00:00:56] swyx: А что за пост в блоге, над которым вы работали и который мы выпускаем сегодня? В чём главный тезис, который вы доносите?

[00:01:04] Olivia: Главный тезис в том, что SWE-Bench Verified был одним из путеводных кодинг-бенчмарков, по которым индустрия отслеживала прогресс в кодинге. Но в последнее время мы видим, что прогресс как бы застрял. И мы поняли, что это потому, что эвал по сути насыщен и при этом сильно контаминирован.

[00:01:20] Так что сейчас мы считаем, что он уже плохо измеряет улучшения в кодинге. И мы думаем, что индустрии стоит уходить от него к другим бенчмаркам

[00:01:28] swyx: например, к SWE-Bench Pro.

[00:01:29] Olivia: Например, к SWE-Bench Pro. Да.

[00:01:30] swyx: Класс. Да, один из моих стандартных шуток — что есть некий общий групповой чат всех лабораторий.

[00:01:34] И все по очереди прибавляют по 0.1, и каждый раз: «ну окей, у тебя теперь лучшая кодинг-модель, потому что ты на 0.1% выше», но в какой-то момент это уже не очень убедительно. Нет. Да. Так что круто.

[00:01:47] Как создавался Verified

[00:01:48] swyx: Давайте перезагрузимся: что за оригинальную работу вы проделали в Verified — она ведь была довольно масштабной.

[00:01:54] Это было очень серьёзное вложение со стороны OpenAI, которое люди до сих пор не до конца ценят. А потом — какие подводные камни вы со временем нашли? Что такое SWE-Bench Verified и что про него важно знать?

[00:02:08] Olivia: SWE-Bench Verified — это, по сути, чистка оригинального академического бенчмарка SWE-Bench, который сделала лаборатория в Princeton.

[00:02:14] Агенту даётся кодовая база и задача, взятая из реального репозитория и GitHub issue, его просят решить задачу, и оценивается, проходят ли определённые тесты. На тот момент это быстро стало популярным бенчмарком, потому что в индустрии тогда не было хороших реалистичных кодинг-бенчмарков.

[00:02:32] Когда OpenAI начала смотреть на этот бенчмарк в рамках одного из эвалов для Preparedness Framework, выяснилось, что часть провалов агентов происходит не потому что модели тупые, а потому что задачи плохо поставлены. Поэтому в OpenAI запустили довольно масштабную кампанию с привлечением людей — наняли около сотни реальных software-инженеров, чтобы они прошлись по задачам и разобрались: насколько задачи хорошо специфицированы?

[00:03:00] Насколько тесты справедливы? И в итоге собрали курированный набор из 500 задач, которые мы считали гораздо более качественными.

[00:03:06] Mia: Сложно переоценить, сколько усилий ушло на создание этого бенчмарка. Это буквально были многие экспертные software-инженеры. Они просматривали задачи дифференциально по нескольку раз, то есть, по сути, три.

[00:03:26] Три разных эксперта независимо принимали решение.

[00:03:29] swyx: Да, можно было этого не делать. Вы просто утроили свои расходы.

[00:03:32] Mia: Нам и правда пришлось это сделать, потому что задача довольно сложная — посмотреть на проблему и патч, и это даже не просто проблема и патч.

[00:03:42] Это надо понимать в контексте кодовой базы, в которой человек или модель решает задачу. Так что это очень сложная задача, и тройная проверка точно была нужна. Может быть, нам стоило сделать ещё больше, но даже до этого добраться было огромным трудом.

[00:04:01] swyx: Там есть ещё детали, и про них можно почитать в посте. Замечу, что у вас сложилась традиция «верифицированных» бенчмарков. Недавно, кажется, Quinn выпустил HLE Verified для гуманитарных дисциплин.

[00:04:13] Mia: Да.

[00:04:13] swyx: Теперь все верифицируют всё подряд — и это хорошо, дополнительный уровень качества.

[00:04:17] Окей, но мне кажется, суть в том, что у вас были постановки задач и issue-описания, плюс diff-ы, плюс эталонные тесты и регрессионные тесты. Грубо такая структура у этих 500 задач.

[00:04:32] Контаминация в дикой природе

[00:04:32] swyx: И какая-то контаминация всегда случается, потому что весь набор был.

[00:04:35] Полностью открыт. Кажется, у вас были canary-строки, но вы знаете — всё равно всё утекает.

[00:04:40] Mia: Тут несколько каналов: задачи берутся из open-source репозиториев. Это не как с нашими обычными эвалуациями. Когда мы публикуем эвалуации, мы добавляем canary-строки, чтобы их легко было отфильтровать на этапе обучения.

[00:04:58] Но если ты используешь данные просто из открытого рынка,

[00:05:04] swyx: с GitHub.

[00:05:06] Mia: Да. У тебя там нет canary-строки. Да.

[00:05:09] swyx: И вы…

[00:05:09] Olivia: И часть этих репозиториев — очень популярные, как Django. Так что ты увидишь много инстансов, которые используются по всему обучающему корпусу.

[00:05:17] swyx: Да. И вы прямо перед записью говорили мне, что нашли это в своей же цепочке рассуждений в 5.2 — видно, что у модели было «лишнее» знание?

[00:05:26] Olivia: Да. Это пример задачи, где агенту поручили реализовать что-то, но не сообщили, что тест будет искать конкретный аргумент.

[00:05:36] И в цепочке рассуждений GPT-5.2 мы реально видели, как модель размышляет: «эй, кажется, в какой-то версии этого репозитория они реализовали именно такой аргумент, может, стоит его добавить». Это пример теста, который было бы практически невозможно пройти без знания, полученного из контаминации.

[00:05:51] swyx: Да.

[00:05:52] Mia: И ты это нашёл, можно сказать, форсированно — и это запустило целое расследование как в наших моделях, так и в других фронтир-моделях на рынке, чтобы понять, насколько бенчмарк контаминирован по всей индустрии.

[00:06:07] swyx: Что ещё нашли? Это надо разобрать подробнее.

[00:06:11] Olivia: Мы — а под «мы» я в основном имею в виду других людей из нашей команды, не

[00:06:15] swyx: понял.

[00:06:15] Olivia: Да.

[00:06:16] Несправедливые тесты и узкие спецификации

[00:06:16] Olivia: Мы провели анализ: во-первых, справедливы ли вообще тесты. Для этого взяли все задачи, которые o3 не смог решить, и снова посадили много людей, чтобы они ещё раз прошлись и копнули, что не так.

[00:06:34] swyx: Это был тот же самый анализ или они читали выводы o3 и смотрели, где именно o3 ошибся?

[00:06:40] Olivia: Это было сфокусировано на наборе задач, которые модели проваливали. И, по-моему, они смотрели как на решения модели, так и на эталон.

[00:06:49] swyx: То есть это не та же работа, что и оригинальная.

[00:06:51] Mia: Не совсем та же. Это был более глубокий разбор. Типа: какие задачи мы вообще не видим, чтобы хоть одна модель их решала, — есть ли с этими задачами что-то фундаментально не так, или с моделями что-то не так и они просто недостаточно умные?

[00:07:07] Вот в этом мы и копались.

[00:07:09] swyx: И что-то нашли.

[00:07:11] Olivia: О да. Больше чем в половине задач, которые мы разобрали, была та или иная проблема. Самая частая — слишком узкие тесты: тест ищет конкретную деталь реализации, которая не была указана в постановке задачи.

[00:07:28] То есть нечестно ожидать от модели именно такого дизайн-решения. Вопиющий пример — задачи, где тебя просят реализовать фичу, а тесты проверяют, что ты назвал аргумент или функцию определённым именем. Если ты выберешь другое разумное имя, тест провалится.

[00:07:44] Mia: Да.

[00:07:45] Olivia: Другой тип плохих тестов — тесты, которые ищут дополнительные фичи, вообще не упомянутые в постановке задачи.

[00:07:51] Mia: Это важно: если тест проходит — ты, скорее всего, реально сделал хорошую работу. Но если тест не проходит — это не значит, что твоя реализация была плохой.

[00:08:03] То есть мы принимали только очень узкий срез решений, а не всё пространство

[00:08:10] swyx: Да.

[00:08:10] Mia: жизнеспособных и хороших решений задачи.

[00:08:16] swyx: Важно, что вы это делаете, потому что в каком-то смысле вы из 2025–2026 года возвращаетесь и исправляете свою же работу.

[00:08:24] Ведь всё это можно было поймать ещё в оригинальной работе над Verified.

[00:08:27] Olivia: Мне кажется, найти проблему в абстракции гораздо труднее, чем когда у тебя на руках лучшая попытка очень умного агента и ты можешь её сравнить.

[00:08:36] swyx: Труднее или легче?

[00:08:38] Olivia: Извини, гораздо проще, когда у тебя есть это решение.

[00:08:39] Именно. Извини.

[00:08:40] Когда бенчмарки насыщаются

[00:08:40] Mia: Я бы ещё сказала, что на момент публикации SWE-Bench Verified это был очень сильный бенчмарк. Мы не говорим, что бенчмарк был плохой. Через это проходят многие бенчмарки в своей эволюции.

[00:08:56] Когда они становятся популярными и жизнеспособными — это потому, что они измеряют что-то важное, и модели набирают на них процентов 20, иногда меньше. И у людей появляется за что зацепиться, чтобы улучшать модели на этих бенчмарках. А когда ты достигаешь очень высокой производительности, дальнейшие улучшения на 0.1% становятся бессмысленными. И в тот момент

[00:09:23] этот бенчмарк был супер ценным, он многому научил и нас, и индустрию. Просто сейчас мы дошли до точки, где модели стали настолько сильными, что мы начинаем измерять не то, что хотим измерять — кодинг-возможности агентов, — а способность агента правильно угадать, как назвать конкретную функцию.

[00:09:46] swyx: Да.

[00:09:46] Mia: А мы хотим измерять не это.

[00:09:52] swyx: Это справедливо. Если попросить тебя прикинуть — большинство фронтир-моделей сейчас на уровне ~80%. Есть ли реальное число, которое вы считаете «потолком» на SWE-Bench Verified?

[00:10:07] Olivia: Сложно сказать. Когда вышел GPT-5.2, наша команда посмотрела и нашла, что он решает 31 задачу из набора «задачи, которые без контаминации должны быть очень сложно решаемы». Так что вполне возможно, мы уже на том числе, которое и было бы потолком

[00:10:23] если бы вообще не было контаминации. Но сказать точно сложно.

[00:10:27] swyx: Да. Круто.

[00:10:28] Переход на SWE-Bench Pro

[00:10:30] swyx: Мы прекращаем публиковать SWE-Bench Verified. И SWE-Bench Pro станет следующим — это работа Scale. Какое у вас сравнение? Что вас привлекает в SWE-Bench Pro?

[00:10:37] Olivia: Во-первых, он просто сложнее, чем SWE-Bench Verified.

[00:10:41] В Verified около 90% задач — это вещи, которые, по оценкам, у эксперта-инженера заняли бы меньше часа. Они очень хорошо специфицированы, очень самодостаточны. А задачи SWE-Bench Pro — крупнее и сложнее. У этого эвала есть большой запас, потому что он не насыщен.

[00:10:56] swyx: Да, там есть категории от одного до четырёх часов и более.

[00:10:59] Olivia: Да. И он более разнообразен — много репозиториев, несколько языков, качественно разные типы задач. Это всё здорово. По части контаминации мы тоже считаем, что там лучше. Мы измеряли контаминацию для SWE-Bench Verified с помощью небольшого агента-аудитора контаминации, которому давали описание задачи, патч и Task ID, и просили его взять целевую модель.

[00:11:23] И как открытый набор вопросов попытаться найти такие, которые помогут вскрыть, какая контаминация может скрываться в этой модели. На SWE-Bench Verified мы нашли множество примеров контаминации — в моделях OpenAI, в Claude Opus 4.5, в Gemini Flash.

[00:11:42] И во всех мы видели такие вещи, как воспроизведение эталонных решений, в каких-то случаях — указание Task ID и других вещей, которые однозначно говорят как минимум о знакомстве с задачами.

[00:11:55] swyx: Да.

[00:11:56] Olivia: Так что

[00:11:57] Mia: вот.

[00:11:59] Olivia: На SWE-Bench Pro, наоборот, такого мы не видим.

[00:12:01] Агент-аудитор нашёл лишь очень слабые признаки того, что пара моделей, возможно, чуть-чуть знакома с одним-двумя исходными репозиториями. Но это совсем другая картина по сравнению со SWE-Bench Verified. Меньше контаминации — это хорошо.

[00:12:15] Mia: Я думаю, мы должны ожидать, что в какой-то момент и этот бенчмарк перестанет быть правильным, и как индустрия мы должны продолжать двигаться и находить более сложные и более репрезентативные

[00:12:28] задачи, на которых можно мерить наши способности.

[00:12:31] swyx: Класс.

[00:12:31] Что измеряют хорошие кодинг-эвалы

[00:12:32] swyx: Давай тогда туда углубимся. Мы и в пре-чате это обсуждали: люди ощущают качественную разницу при использовании 5.1, 5.2, 5.3, но в бенчмарках это не очень-то отражается, потому что они уже упёрлись в потолок.

[00:12:47] Какие способности ты бы хотела измерить в идеальном кодинг-бенчмарке? Имею в виду — агентном кодинг-бенчмарке, как ни называй.

[00:12:56] Olivia: Одно — это открытые архитектурные решения, ситуации, где задача немного недоопределена, и мы смотрим, может ли модель принимать разумные дизайн-решения.

[00:13:05] swyx: Какой здесь разумный промпт? «Свайбкоди мне B2B SaaS без ошибок» — это мем, но какой реально полезный пример открытой задачи?

[00:13:17] Olivia: Конечно. Например, найти способ ускорить определённую

[00:13:22] часть кодовой базы — но способов сделать это может быть много

[00:13:25] swyx: Да, есть отдельные performance-бенчмарки. Кажется, у вас такой есть. По эффективности — или это не ваша группа? Но это хороший пример.

[00:13:33] Mia: Есть много-много вещей, которые люди ценят в работе с software-инженерными агентами.

[00:13:43] SWE-Bench Verified, конечно, мерил какую-то важную способность: по описанию GitHub issue можешь ли ты выдать патч, который удовлетворительно решает эту issue. И, конечно, есть проблемы с бенчмарком.

[00:14:05] Сейчас, когда мы на 80%, мы уже не доверяем дальнейшим улучшениям на нём, но он действительно измеряет некую жизнеспособную способность моделей. Но как индустрия мы выходим за пределы вопроса «может ли мой кодинг-агент решить мне маленькую GitHub issue?»

[00:14:23] И мы начинаем смотреть на гораздо более долгие задачи — которые занимают не 15 минут, а час, иногда дни. А за пределами «какие задачи мой агент может решить?» есть вещи, которые сложнее ухватить. Olivia говорила про дизайн-вкус.

[00:14:48] Решает ли модель задачу так, как любит решать задачи моя команда? Хороший ли код? Хорошо ли он написан? Чистый ли код? Поддерживаемый ли в будущем? Люди об этом заботятся — это менее ощутимые и более сложные для измерения,

[00:15:14] но всё равно супер значимые вещи для тех, кто работает с кодинг-агентами.

[00:15:19] swyx: Да, это всё качества, для которых уже нет низко висящих фруктов. Мы понятия не имеем, как это всё мерить. Простой вопрос: есть как бы две функциональные дороги.

[00:15:30] Одна — человекоёмкая и деньгоёмкая: нанимаем кучу контракторов и пытаемся это аннотировать. Вторая — использовать LLM как прокси и попытаться выровнять её так, чтобы получить разумный заменитель. Что бы вы выбрали? Хотите оба?

[00:15:47] Mia: Может, тебе стоит рассказать про GDPVal как пример.

[00:15:51] Olivia: Конечно. GDPVal — это эвал, который опять же сделали в коллаборации команды Human Data и команды Frontier Evals. Он пытается измерить, могут ли агенты выполнять разнообразную реальную «беловоротничковую» работу. Оценка там очень сложная, требует серьёзного знания: что именно ты ищешь в каждом контексте.

[00:16:16] swyx: Да. По 15–16 беловоротничковым профессиям, занимающим значительную часть ВВП — что круто.

[00:16:23] Olivia: Это укрупнённые профессии плюс много мелких подпрофессий.

[00:16:26] swyx: Я говорил, что я большой фанат. Это, по сути, эвал для AGI.

[00:16:32] Olivia: Да, и поскольку это было сложно

[00:16:36] и требовало большого доменного знания, команда Human Data наняла много людей из этих профессий, чтобы они активно участвовали в создании задач, эталонных решений и помогали создавать рубрики.

[00:16:50] swyx: Грубо говоря, бери GDPVal — это generalist-подход — применяй его к коду, и у тебя примерно есть план.

[00:16:58] Mia: Это интересный подход. Ты обозначаешь важную проблему: насколько это реалистично. Мы хотим, чтобы кодинг-агенты писали код, который мы считаем хорошим. И спрашивать у людей — хороший способ это обеспечить, но он медленный и сложный.

[00:17:23] И поэтому SWE-Bench Verified стал суперпопулярным, как и все подобные бенчмарки: их просто очень легко прогонять. Гораздо проще валидировать, что решение проходит все тесты. Достаточно один раз настроить запуск тестов — и ты можешь сказать «корректно или нет», агрегировать и получить число.

[00:17:49] Но это не отвечает на вопрос: действительно ли метод решил задачу так, что мейнтейнер этого open-source проекта замёрджил бы такой PR. На это не отвечает. Но есть огромная ценность в бенчмарках, которые легко сравнивать между игроками индустрии и которые можно прогонять быстро и без участия человека.

[00:18:16] swyx: Да. Здорово.

[00:18:17] За пределами тестов: доллары и автономия

[00:18:17] swyx: Ваши команды выпустили и другие эвалы — например, RL paper bench, эвалы на рекурсивное самосовершенствование. Насколько это должно быть частью мейнстримных кодинг-эвалов? Есть ли способ их объединить?

[00:18:38] Olivia: То есть стоит ли строить эвалы кодинга также как эвалы самосовершенствования? Или ты спрашиваешь, покрывают ли это нынешние кодинг-эвалы?

[00:18:46] swyx: Я думаю, это одни из самых продвинутых эвалов, которые у нас есть. Мы их не используем в обычном потоке. И это странный разрыв: вот эвалы для обычного кодинга, а вот — для машинного обучения, и они совсем другие.

[00:19:03] В основном это про safety, но это и реально полезно — понимать, насколько модель хороша в AI-коде.

[00:19:15] Olivia: Да. Полагаю, часть причины, по которой многие бенчмарки пока не фокусировались на AI-кодинге, — это вопрос «какие датасеты легко собрать».

[00:19:24] Потому что многие state-of-the-art AI-кодовые базы — проприетарные. И если мы сделаем эвалы по ним, мы их, скорее всего, не выложим. А людям в индустрии сложно делать эвалы, которые реалистично измеряют исследовательский кодинг-воркфлоу. Я считаю, индустрии было бы полезно публично измерять эти навыки, но это сложнее сделать реалистично.

[00:19:45] swyx: Ещё одна вещь, которую многие пытаются делать: вместо процента 0–100 деноминировать в долларах. Есть Freelancer и подобные. У других — vending bench. Есть ли в этом альфа, или вы всё-таки хотите классический академический бенчмарк?

[00:20:04] Mia: В каком-то смысле это разные способы мерить одно и то же. «Сколько денег это приносит» — довольно близко к «сколько часов человек тратит на эту задачу». Обычно они хорошо коррелируют.

[00:20:20] Сколько времени уходит у человека на решение задачи — определяет ценность, которую мы приписываем решению. И я согласна, что важная штука здесь — насколько сложные и долгие задачи мы готовы доверить агентам.

[00:20:44] Olivia: Да.

[00:20:45] Mia: Это важная часть. Но денежная стоимость, время, сложность — все они в общем-то пытаются захватить нечто похожее.

[00:20:56] swyx: Да. Это прокси для возрастающих возможностей, которые мы хотим измерять. Думаю, единственный другой крупный игрок в этом поле — METR, у которого был большой long-horizon-эвал. И — поздравляю, вы полностью сломали его кривую. Какие мысли? Это подход, который хотелось бы перенять?

[00:21:21] Mia: Да-да.

[00:21:21] Мы работаем с METR над этими эвалами и ценим их. Они используют время, а не деньги. Так что отвечая на твой вопрос: сложность — как бы мы её ни квантифицировали — действительно важна для понимания, где находятся наши модели.

[00:21:42] swyx: Окей. Сложность — это абстрактная штука, и она проецируется во время, в стори-поинты, в доллары. Класс.

[00:21:49] Preparedness и будущие направления

[00:21:49] swyx: Последний вопрос — про Preparedness Framework. Я смотрел: на него многие ссылаются, но мало кто хорошо его объясняет. У вас есть отличный сайт, где, кажется, «test, inform, teach» — что-то такое. И мне кажется, вы там много работаете. Не хочешь рассказать, как Preparedness Framework применяется?

[00:22:08] Olivia: Preparedness Framework — это публичный фреймворк OpenAI о том, как мы отслеживаем фронтир-риски. Это обычно dual-use способности — их можно использовать и во благо, и во вред. Мы хотим хотя бы следить за плохой стороной, чтобы и мы как компания, и общество в целом могли подготовиться к возможным негативным последствиям.

[00:22:28] Сейчас мы отслеживаем три категории: биорсики, кибербезопасность и автоматизация исследований и автономия моделей. Именно последняя ближе всего связана со SWE-Bench, потому что кодинг — это не вся автоматизация исследований, но один из ключевых её компонентов.

[00:22:47] И SWE-Bench Verified изначально и был создан как часть построения эвалов для рабочего потока model autonomy. Сейчас, как я думаю, мы должны двигаться дальше — смотреть, могут ли модели реально автоматизировать исследовательский воркфлоу.

[00:23:02] swyx: Да. Класс.

[00:23:03] Mia, ещё что-то добавишь в общем — что людям важно понимать про Preparedness и как эвалы, Human Data и Alignment работают вместе?

[00:23:12] Mia: Я бы сказала, что мы очень ценим, что мы много работаем над этими эвалами и публикуем их.

[00:23:23] Так мы выпустили SWE-Bench Verified, так мы делимся GDPVal и подобными вещами. Мы также глубоко ценим, когда другие люди и индустрия в целом делают эвалы и делятся ими. Мы их используем — как, например, SWE-Bench Pro: да, это лучший эвал сейчас, и мы должны его использовать. И мы бы очень призывали людей искать больше способов

[00:23:43] создавать и делиться эвалами, которые мы и вся индустрия можем использовать для измерения прогресса

[00:23:50] swyx: Да.

[00:23:50] Mia: по разнообразию способностей, в том числе по кодингу, потому что важно понимать, где мы находимся.

[00:23:57] swyx: Mia, тебе нужно уходить. А мы как раз обсуждали будущие направления, в которые мы хотим, чтобы двигались эвалы.

[00:24:02] Mia: Угу.

[00:24:03] swyx: И здесь можно углубиться. Это твоя платформа: расскажи, что ты ищешь.

[00:24:15] Olivia: Несколько вещей было бы полезно. Во-первых, действительно сложные задачи. Те, на которые у топовых инженеров уходят месяцы, а у команд — недели. Особенно если оценка надёжна — например, у вас есть рубрики, которые были собраны и валидированы многими людьми в индустрии. Это было бы очень ценно. Также бенчмарки на создание продуктов end-to-end.

[00:24:42] Третье, и это, может, не совсем эвал, но это важно для общей миссии: как индустрия и как мир мы должны отслеживать, куда движутся эти способности. Я бы хотела видеть больше метрик, отслеживающих реальное использование.

[00:24:57] Сколько на самом деле AI используется в индустрии, насколько он заменяет рабочие места, насколько он усиливает людей и ускоряет их — реальные «полевые» метрики.

[00:25:08] swyx: Да. Тема замещения всегда чувствительная с точки зрения PR.

[00:25:12] Но мы создаём новые рабочие места, которые управляют старыми, и так далее. По части фронтир-эвалов, которыми OpenAI собирается заниматься, — вы каждый раз выпускаете отличную работу. Что людям ждать от самой OpenAI?

[00:25:28] Olivia: Не уверена, что могу сказать, что именно мы будем

[00:25:30] swyx: Общие направления.

[00:25:31] Olivia: Общие направления — смотреть на реальное влияние, реальное

[00:25:38] swyx: Да, неважно.

[00:25:38] Olivia: Что-то такое. Да.

[00:25:39] swyx: Окей. Жду больше реального влияния. Вы реально многого достигли, и взяли на себя индустриальное лидерство по SWE-Bench Verified, а теперь переходите на SWE-Bench Pro.

[00:25:50] Спасибо, что сделали это. Спасибо, что были такими прозрачными. Думаю, люди ответят тем же.

[00:25:57] Olivia: Спасибо за время.

[00:25:58] swyx: Спасибо.