newsmode
search
Меню
arrow_back Назад

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

auto_awesomeКраткое саммари

OpenAI официально прекращает использовать SWE-Bench Verified как ключевой бенчмарк для оценки кодинг-агентов. Mia Glaese (VP of Research) и Olivia Watkins из команды Frontier Evals объясняют решение: бенчмарк насыщен (большинство фронтир-моделей около 80%), а более глубокий анализ 138 нерешённых задач показал, что более 60% из них в принципе нерешаемы — 49 тестов слишком узко определены (отвергают функционально корректные решения), а 26 ищут фичи, которые не упомянуты в постановке. Вторая проблема — контаминация: OpenAI обнаружила, что ВСЕ фронтир-модели (включая Claude Opus 4.5, Gemini Flash и собственные модели OpenAI) способны воспроизводить эталонные патчи и постановки задач буквально по Task ID. OpenAI одобряет SWE-Bench Pro от Scale (где Gemini 3 опережает GPT 5.x) как более сложную и менее заражённую альтернативу. В будущих эвалах команда хочет видеть длинные задачи (часы и дни), открытые архитектурные решения, качество кода, реальное продуктостроение и человеческую оценку с привлечением экспертов — по аналогии с GDPVal. Работа вписывается в Preparedness Framework OpenAI, отслеживающий три категории рисков: биориски, кибербезопасность и автоматизацию исследований.

⚡️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

First speakers for AIE Europe and AIEi Miami have been announced. See you there!

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


We’ve been somewhat making tongue in cheek references to the very very minor bumps on SWE-Bench Verified scores every time a new frontier model is released (Opus 4.5 → 4.6 was literally a 0.1% down step), but it is a whole other matter for the original authors of SWE-Bench Verified to make the call to discontinue reporting it.

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

We were excited to have Mia Glaese, original coauthor of SWE-Bench Verified and VP of Research on the Frontier Evals, Human Data and Alignment teams, and Olivia Watkins, Researcher on Frontier Evals, drop by to talk about their decision to publicly abandon SWE-Bench Verified today and endorse SWE-Bench Pro:

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

The discussion around the saturation of SWE-Bench has been swirling in the community for over a year now — most frontier model numbers consistently report around 80%, and the authors of the original SWE-Bench still assert that the “ceiling” for a saturation call should be closer to 87-95%, aka there are still quite a few more percentage points to go, even on the filtered subset of 500 tasks in Verified.

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

But OpenAI have done a deeper analysis of 138 problematic problems (getting at least SIX more engineers to review all the issues) and found two further issues that have triggered the decision today:

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

  • >60% of remaining problems are unsolvable: in the pod, Mia explains that 49 tests were too narrowly defined (so that they also reject functionally correct submissions) and 26 tests were “too wide” - looking for extra features that were never mentioned in the problem description.

  • Training on test: this is simple contamination — that often happens even without intentional cheating. SWE-bench problems are sourced from open-source repositories many model providers use for training purposes, and the sheer popularity of SWE-bench means examples leak into other corpuses over time.

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

    These findings happened together. Taking a closer look at how GPT-5.2 somehow solved “unsolvable” problems then led the team to read the chain of thought and find test requirements that were never specified, and yet known by the model.

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

    Contamination

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

    The latter point on contamination is the most damning and also the easiest to illustrate. OpenAI found examples of ALL frontier models, starting with OpenAI’s , being able to reproduce the original gold patch or problem statements from the eval verbatim with minimal prompting, just from SWE-Bench Verified Task ID alone:

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

    Impossible Tests

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

    Closer human scrutiny easily revealed some SWE-Bench Verified problems that should be impossible to pass… unless you knew the answer beforehand.

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

    What’s Next

    Что дальше

    This move shouldn’t surprise anyone who watches closely — the Artificial Analysis team stopped indexing on SWE-Bench long ago, and OpenAI itself has been reporting SWE-Bench Pro for the last few months — but making it official is a great service to academia and industry at large who have long considered SWE-Bench Verified to be the commonly accepted standard, and it is an authoritative move that only OpenAI could have made.

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

    An additional charitable move is that OpenAI is endorsing a benchmark which it is not even close to SOTA at - even Gemini 3 does better than GPT 5.x:

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

    But clearly the team is looking into deeper evals that are more open ended and rubric based similar to their own work on GDPVal. Some properties that Mia says they are looking for:

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

  • Longer-term tasks

  • Open-ended Design Decisions

  • Code Quality and Maintainability

  • Real world product building

  • Tracking real-world usage and impact

  • Human-intensive evaluation (human review requiring domain knowledge and subjective quality assessment)

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

    Looks like there will be a whole new set of frontier evals to look forward to in 2026 — and we also discussed how this work all ties into OpenAI’s Preparedness Framework, which is not well understood outside of OpenAI.

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

    Timestamps

    Таймкоды

  • 00:00 Meet the Frontier Evals Team

  • 00:56 Why SWE Bench Stalled

  • 01:47 How Verified Was Built

  • 04:32 Contamination In The Wild

  • 06:16 Unfair Tests And Narrow Specs

  • 08:40 When Benchmarks Saturate

  • 10:28 Switching To SWE Bench Pro

  • 12:31 What Great Coding Evals Measure

  • 18:17 Beyond Tests Dollars And Autonomy

  • 21:49 Preparedness And Future Directions

  • 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 и будущие направления

    Transcript

    Транскрипт

    [00:00:00] Meet the Frontier Evals Team

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

    [00:00:00] swyx: Okay. Hi. We’re here in the PI studio with Mia and Olivia from the Frontier Evals team. Or however you want to introduce yourself. Maybe m want to introduce name, what you do at Open AI and we can get it started.

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

    [00:00:16] Olivia: Sure. Hi, I’m Olivia, I’m on the Frontier Evals team.

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

    [00:00:19] swyx: Great. Pete.

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

    [00:00:20] Mia: Hi, I’m Mia. I am a VP of research at OpenAI and my teams are the Codex team, the human data team, and the alignment team. And we work a lot with Olivia’s team on Frontier.

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

    [00:00:33] swyx: Yeah. Very exciting. And as by my understanding, you were part of the original team that worked on SWE-Bench verified as well.

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

    [00:00:38] Mia: Yeah. Olivia’s team, the Frontier team and the human data team collaborated on creating SWE bench verified.

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

    [00:00:45] swyx: So you’ve, you’ve seen the evolution of coding benchmarks over time, and I I think it was round about to the mid to late 2024 when you first covered three verified. These have evolved a lot since then.

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

    [00:00:56] Why SWE Bench Stalled

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

    [00:00:56] swyx: What’s the blog post that you have worked on that you, that we’re releasing today? Like what, what is the sort of con, what’s the main thesis that you’re pushing out?

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

    [00:01:04] Olivia: So the main thesis is that SWE-Bench verified has been one of the North Star coding benchmarks that the field has looked at to measure coding progress. But recently we’ve seen that. Progress has kind of stalled. And basically we realized that this is because the eval is effectively saturated and also highly contaminated.

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

    [00:01:20] So at this point we think that it’s not really measuring coding performance improvements well anymore. And we think that the field should move away from this towards other benchmarks

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

    [00:01:28] swyx: like SWE-Bench Pro.

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

    [00:01:29] Olivia: Like SWE-Bench Pro. Yeah.

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

    [00:01:30] swyx: Amazing. Yeah, I, one of the jokes I always have is like there’s a group chat with all the labs.

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

    [00:01:34] And everyone just takes turns, the increment, like 0.1 on trucks and then it’s like, okay, well you have the best coding model, I guess. ‘cause you’re 0.1% higher, but it’s not super convincing at this point. No. Yeah. So cool.

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

    [00:01:47] How Verified Was Built

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

    [00:01:48] swyx: I think the let’s, let’s sort of reset on like, what was the original work that you guys did for Verified, which I think was pretty substantial.

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

    [00:01:54] Like, it was like a very significant investment from OpenAI, which like people still don’t appreciate. And [00:02:00] then. What were the satisfactions that we, that we found over time? Right? So like what, what was Sweet Bench Verify, or should, should that people should know about?

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

    [00:02:08] Olivia: Suite bench verified was kind of a cleanup of original bench academic benchmark from a lab at Princeton called Suite Bench.

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

    [00:02:14] And the agent is basically given a code base and a task that was sourced from a real world repository and GitHub issue, and was asked to solve a task and is graded on whether some tests pass. And at the time this was quickly became a popular benchmark because at the time the field didn’t really have good real world coding benchmarks.

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

    [00:02:32] Then when open, I took a look at the benchmark as part of one of the evals we wanted to track in our preparedness framework. Folks started realizing that some of the cases where agents were failing were due to bad problem setups rather than just to models being dumb. So folks at OpenAI did a pretty extensive human data campaign hiring like almost a hundred real world software engineers to go through the problems and figure out like, are the tasks [00:03:00] well specified?

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

    [00:03:00] Are the tests actually fair? And kind of created a curated set of like 500 tasks that we thought were much better.

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

    [00:03:06] Mia: It’s just, it’s maybe, it’s hard to, to overstate like the amount of effort that it took to like create that benchmark. It was literally like many export software engineers. Reviewing the problems like differentially multiple times and to, you know, basically like three.

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

    [00:03:26] Different experts independently decided it.

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

    [00:03:29] swyx: Yeah, you didn’t have to do that. You just tripled your costs for just,

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

    [00:03:32] Mia: I mean, we had to do it, we had to do it actually, because it’s quite a hard task to like look at something like a, a problem and, and the patch and then like, it’s not just the problem and the patch, right?

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

    [00:03:42] You have to like understand it in the context of the code base that the human or, or the murders and to solve the task. So it’s a very complex problem and it was definitely needed to have. Three reviews and I think like maybe we should have done more, but it was definitely a lot of effort [00:04:00] to get there.

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

    [00:04:01] swyx: And there’s, there’s more, but people can read the, the blog post for that. I will note that you guys had a trend in verifying benchmarks. ‘cause I just recently saw, I think Quinn had a HLE verified for humanities. M verified.

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

    [00:04:13] Mia: Yeah.

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

    [00:04:13] swyx: Which like, so now everyone’s verifying everything, which is. Nice and good and like extra quality there.

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

    [00:04:17] Okay. So, but the, I think that the meat of it is that, that this, this was a lot of like, well, here’s the issue or problem statements, and then here’s the, here’s the diffs, here’s the golden tests, and here’s some regression tests. Right? That’s, that’s like the rough setup of these 500 problems.

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

    [00:04:32] Contamination In The Wild

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

    [00:04:32] swyx: And there’s some contamination always happens because all the C measure I was.

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

    [00:04:35] Fully open. I think you, you did have canaries, but like, you know, stuff, stuff, leaks,

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

    [00:04:40] Mia: there’s like multiple avenues that like the problems are sourced from open source repos. Yes. So it’s not just like when we usually publish evaluations. We publish evaluations and then we, we add can strengths to ensure that, you know, they are easily fit out, out at training time.

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

    [00:04:58] Obviously if [00:05:00] you use sort of like. Data from like open market, just

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

    [00:05:04] swyx: GitHub.

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

    [00:05:06] Mia: Yeah. You don’t have actually like a CAGR cannery string in that. Yeah.

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

    [00:05:09] swyx: And you,

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

    [00:05:09] Olivia: and these are also like, some of these are very popular repos, like the Jengo repository. So you’re gonna see like many instances being used kind of throughout go.

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

    [00:05:17] swyx: Yeah. Yeah. And you just before recording, you’re telling me that you found this in your own chain of thought with that 5.2 also seeing that like. They had extra knowledge or something?

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

    [00:05:26] Olivia: Yes. So this was an example where the task asked the agent to influence something, but it wasn’t told that there was this specific argument that the test was going to be looking for it using.

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

    [00:05:36] But in the GP 5.2 chain of thought, we actually saw instances of the model reusing, like, Hey, I think that at some length version of this repository, they implemented this particular argument. Maybe I should add it in. Yeah. So this is an example of a test that like would be pretty impossible to pass without this contamination knowledge.

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

    [00:05:51] swyx: Yeah.

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

    [00:05:52] Mia: And I think you found that. Sort of forced, right? And had triggered like a whole investigation, both like in our own modes oh, and also in [00:06:00] other frontier modes, like in the market, and like understanding how contaminated the benchmark is, like across the industry.

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

    [00:06:07] swyx: What else did you find? I mean, that’s, I have to double click on this.

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

    [00:06:11] Olivia: So we, and when I say we, this is mostly from other folks at our tape, not don’t, not

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

    [00:06:15] swyx: familiar.

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

    [00:06:15] Olivia: Yes.

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

    [00:06:16] Unfair Tests And Narrow Specs

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

    [00:06:16] Olivia: But so we did some analysis on, first of all, are the tests actually fair? I. So this happened by first taking all the problems that O three E couldn’t solve lively, and then again getting a lot of humans to do basically another pass of kind of digging into, you know, what’s wrong.

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

    [00:06:34] swyx: Is it the same exact analysis or were they reading o three’s output and going o. Here’s where all three went wrong.

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

    [00:06:40] Olivia: I think it was, I mean, it was definitely like a scope to the set of problems that models failed. And I believe they were able to look at like what the model solutions look like versus what the, so

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

    [00:06:49] swyx: this isn’t the same work as the original.

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

    [00:06:51] Mia: It’s not exactly the same work. It was like a, a deeper dive. It’s like, okay. Which are the problems that we don’t see any murder solving is like, is there’s something [00:07:00] fundamentally wrong with those problems or is there something you know wrong with the other model? Just not smart enough to solve the problems.

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

    [00:07:07] So that’s kind of like what we, what we dug into.

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

    [00:07:09] swyx: Yeah. And you found some.

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

    [00:07:11] Olivia: Oh, yes. Like in over half of the problems that were investigated in that deep dive, there was one problem or the other. I think the most common problem are like overly narrow tests where there’s some particular implementation detail that the tests we’re looking for, but wasn’t specified in the problem description.

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

    [00:07:28] So it wasn’t fair to expect that model to make that particular design choice like one. Pretty blatant example are cases where the task asks you to implement some feature and the tests are looking for you naming that argument or that function with a particular name. But if you may chose another reasonable name, the test would fail.

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

    [00:07:44] Mia: Yeah.

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

    [00:07:45] Olivia: And another set of types of bad tests or tests that are just looking for additional features that were never mentioned. The problem description.

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

    [00:07:51] Mia: Where, where that’s a significant, it like that means that if you pass a test, actually, like you probably did like a really good job, but just because you didn’t pass a VE test [00:08:00] doesn’t mean that your implementation wasn’t like a good one.

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

    [00:08:03] Right. So it was just like, we only accept like very narrow versions of solutions and like not the whole space

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

    [00:08:10] swyx: Yeah.

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

    [00:08:10] Mia: Of, of like viable and sort of like good solutions to the problem.

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

    [00:08:16] swyx: Yeah. I think it’s important that you’re doing this because it, in some way it is you in 2020. Five, six, going back in time and correcting your own work, right?

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

    [00:08:24] Because you could have caught all this in in the original verified work. I

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

    [00:08:27] Olivia: think so it’s definitely much harder to find a problem in the abstract than when you’re looking at a very smart agent’s best effort solution and trying to compare it. It

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

    [00:08:36] swyx: is harder or harder,

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

    [00:08:38] Olivia: sorry. It’s much easier when you have those solution much easier.

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

    [00:08:39] Exactly. Sorry,

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

    [00:08:40] When Benchmarks Saturate

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

    [00:08:40] Mia: I think, I think also like at the time and three Be Verified was published, I think it was like a very strong benchmark. It’s not like we are, we’re like, oh, this is not, this wasn’t like a strong benchmark at the time. I think this is something that a lot of. Benchmarks go through like as an evolution, right?

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

    [00:08:56] Like when they start to become like popular and like [00:09:00] viable, it’s because they measure something like important and modes maybe do like 20% correct on them, sometimes even less. And sort of like people have something to hold on and, and improve modes on, on these benchmarks. And by the time that you hit like very high performance on the benchmarks, like additional like 0.1% improvements, it’s become sort of like meaningless and sort of like at the time I think, you know.

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

    [00:09:23] That benchmark was like super valuable and it, it taught like us and like the industry a lot. It’s just like now at the point that we are at now where markets are as strong as they’re now, we are kind of starting to measure, not necessarily like what we want to measure, which is like coding capability of our agents, but like the agent’s ability to like correctly guess how to name a specific function.

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

    [00:09:46] swyx: Yeah.

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

    [00:09:46] Mia: And, and that isn’t really what we are like want to measure at this point. Yeah.

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

    [00:09:52] swyx: I think that’s fair. Is there, I mean if I, if I asked you to ballpark it, like most models are, most frontier models are now like 80 something. [00:10:00] Is there, like, what’s the actual like number on superb bench verify that you did you guess as like the ceiling or?

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

    [00:10:07] Olivia: I guess that’s really hard to say. Like I when GDI 5.2 came out folks took a look and found that it was solving like 31 problems that were in the set of, should be very hard to solve without contamination problems. So I think it’s quite possible that that number is already something that we’ve hit.

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

    [00:10:23] If you didn’t have contamination at all. Fair enough. Hard to say though.

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

    [00:10:27] swyx: Yeah. Cool.

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

    [00:10:28] Switching To SWE Bench Pro

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

    [00:10:30] swyx: We’re gonna stop reporting CBE verified. Right? And then SWE-Bench Pro Will will be sort of the next one, which is an effort from scale. What’s your sort of comparison analysis? What’s, what attracts you to SWE-Bench Pro?

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

    [00:10:37] Olivia: The first one I think is just that it’s harder for SWE-Bench verified.

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

    [00:10:41] I think, I mean like 90% of the problems are things that were estimated to take like an expert software engineer like less than an hour. They’re like very well specified, very self-contained, and the SWE-Bench Pro problems are just bigger and harder. There’s much more head rewind that eval because it’s not saturated.

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

    [00:10:56] swyx: Yeah. Like categories of like one to four hours and four plus.

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

    [00:10:59] Olivia: [00:11:00] Yeah. And it’s more diverse. Lots of repositories, multiple languages, qualitatively more different types of problems. So all that’s great. On the contamination side, we also think it’s better there. So the way we were measuring for contamination for SWE-Bench verified was with this little like contamination auditor agent, which is given the description of the task and the patch and the task ID and told to go take this target model.

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

    [00:11:23] And kind of as an open-ended, like set of questions, try to find questions that will manage to kind of reveal what contamination might be lurking in that model. And in SWE-Bench verified, we found. Many instances of contamination across like across open eye models, across like quad Opus 4.5, Gemini Flash.

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

    [00:11:42] And, and all of these we saw things like regurgitating the ground proof solutions, things like in some cases giving like the task IDs and other things that are pretty clear evidence of at minimum familiarity was the stories.

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

    [00:11:55] swyx: Yeah.

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

    [00:11:56] Olivia: So we

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

    [00:11:57] Mia: that,

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

    [00:11:59] Olivia: yeah. It [00:12:00] was SWE-Bench Pro. On the other hand we don’t see this.

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

    [00:12:01] I think they’re the auto agent found some, like very light evidence that maybe a couple models might be very lightly familiar with like one or two of the source repositories, but it’s very different than SWE-Bench verified. So less contamination is good.

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

    [00:12:15] Mia: I think there also like we should expect that at some point like that, that’s not going to be like the right benchmark anymore and like it’s a field we kind of have to continue to like move on and like find harder and more representative.

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

    [00:12:28] Yeah, problems that we can match our capabilities on.

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

    [00:12:31] swyx: Awesome.

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

    [00:12:31] What Great Coding Evals Measure

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

    [00:12:32] swyx: So let’s go into that. I think that there are a lot of I think we also practiced in the, in the pre-chat was, well, people feel a qualitative difference when they’re using 5.1 to 5.2 to 5.3, and it’s not super expressed in the these benchmarks because they, they are on a number of these things.

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

    [00:12:47] What capabilities do you really want to benchmark in a, in a ideal coding benchmark? You know, I guess like agent coding, benchmark, whatever you call it.

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

    [00:12:56] Olivia: I mean, one thing is kind of open-ended design [00:13:00] decisions, places where the problem maybe is a little bit underspecified and seeing if the model can make reasonable design decisions.

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

    [00:13:05] swyx: What’s a reasonable prompt for that? Like this vibe Code me. B2B SaaS to make no mistakes or, you know, that’s, that’s the meme, but like, okay. What’s like, what’s like an actual usable open-ended problem like that? Like,

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

    [00:13:17] Olivia: Sure. I mean, maybe an example could be finding a way to speed up a particular.

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

    [00:13:22] Part of a code base, but there might be multiple different ways to

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

    [00:13:25] swyx: Yeah, there are dedicated performance benchmarks. I think you guys have one. So, efficiency or is that, is that, oh, no, I think that’s, that’s off your group. But yeah. Yeah, I mean that, that, that is a good one.

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

    [00:13:33] Mia: I think there’s just many, many things that people like value about working with, with software engineering agents.

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

    [00:13:43] They think Swyx, Swyx bank’s verified, obviously measured like some. Still measures like some important capability, which is like given like a description of a GitHub issue, can you produce like a patch that solves that issue, you know, [00:14:00] satisfactorily. And like, obviously there’s like some issues with the, with the benchmark that needs that.

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

    [00:14:05] Now that we are like 80%, we don’t really trust like further improvements on it, but like it does match on something that is like a via, via like capability of motors. But I think. As a field, we are like moving beyond sort of, you know, can my coding agent like solve a small like GitHub issue for me?

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

    [00:14:23] Right? And so we are starting to look at like much more long, longer term tasks, right? Like. That don’t take like 15 minutes, but maybe like hour, sometimes days. And then beyond sort of like what kind of tasks can my agent solve? Like there might be things that are kind of a bit harder to grasp, right? Like Olivia talked about sort of like, does it have like design taste, right?

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

    [00:14:48] Like does it solve the problem the way that you know. My team likes to solve problems. Okay. Is the code nice? Right? Like is it, is it well written? Like, [00:15:00] is it sort of like clean code, right? Like people care about these, is it maintainable in the future? People care about a lot of these, maybe less tangible less tangible and like harder to measure, frankly.

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

    [00:15:14] Things that, that are still like super meaningful for people that are working with coding agents?

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

    [00:15:19] swyx: Yeah, so I mean these are all qualities that are obviously the, no longer the low hanging fruit. Like we have no idea how to eat all this. I think the, the, the simple question maybe that the, that there’s sort of two function road.

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

    [00:15:30] One is the sort of very human intensive, money intensive path, which is hire a bunch of contractors and try to annotate this. The other is. Use an LLM to to proxy it and try to align the LLM so that it can give you a reasonable proxy. Which of those would you want? I want You wanna do both?

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

    [00:15:47] Mia: I think like maybe you should talk about GDP law as like an example.

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

    [00:15:51] Olivia: Sure. So GDP be is an eval that was again produced by a collaboration between human data team and the front of [00:16:00] evals team. And it’s trying to measure whether agents can do kind of a variety of like, real world white collar work. That was an eval where grading is very hard requires kind of a lot of kind of like knowing knowledge on exactly what are you looking for in each different context?

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

    [00:16:16] swyx: Yeah. Across like. 15, 16 white collar jobs. Professions like I, that take of a significant part of gdp, DP, which is great.

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

    [00:16:23] Olivia: No, it’s high level professions and then a lot of like different granular sub professions.

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

    [00:16:26] swyx: I have said like I’m a big fan. It’s so, it, it is, this is the eval for agi. I basically,

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

    [00:16:32] Olivia: but, but part it because it was so hard to.

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

    [00:16:36] It required so much kind of like domain knowledge that the human data team hired like a lot of people from these professions to be very involved in creating tasks and creating the gold solutions and trying to help create rubrics and so forth so they can create it lively.

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

    [00:16:50] swyx: So basically take the GDP valve, which is a generalist, take that same approach to apply it to code and you roughly have like a, a rough road.

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

    [00:16:58] Mia: I think it’s an interesting yeah. [00:17:00] Solution. I think what you’re pointing out as an important problem, which is sort of this. This, like how realistic is it? And like, do you know what, what we want to do is like. Coding agents should write code that, you know, we think is good. And so it’s like asking human, it’s actually like a, a good way to ensure that is also kind of a slower, like, complex way to do that.

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

    [00:17:23] And so part of why I think, you know, three Venture verified ended up being super popular and where we are seeing like all benchmarks, like this being super popular. I was like, it’s very easy. It could even be easier. Validating that a solution passes all the tests. It’s like fairly trivial once you can like run the tests in, in like your, on your computer or wherever you’re running them and you can kind of like, okay, is it correct or is it not correct?

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

    [00:17:49] And you can kind of aggregate that and that it’s super simple, but it doesn’t tell you. It’s like, you know, did the method like solve the problem? Like wow, like, you know, I agree with like what if actually like. An open source [00:18:00] maintainer of that project have like merged that pr like that, it doesn’t tell you, but there is a lot of value in having benchmarks that are both like easy to compare across the industry and also that can be sort of run really fast without human involvement.

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

    [00:18:16] swyx: Yeah. Amazing.

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

    [00:18:17] Beyond Tests Dollars And Autonomy

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

    [00:18:17] swyx: Your teams also put out other kinds of evals that are related, like the, I think there’s an RL. Paper, bench paper. And then they sort of like the more sort of recursive self-improvement type evals. How much should that figure into mainstream coding evals? You know, like is there, is there some way in which those things join together?

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

    [00:18:38] Olivia: So we were asking like, should we build, should also be voting evals for the self-improvement evals? Are you saying do coding evals currently cover that? Mine?

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

    [00:18:46] swyx: I think I, I, I just think like those are some of the most advanced EVs that we have. We’re not using them in a normal path. And it’s just, it’s an interesting split between, well here’s evals for coding normal [00:19:00] things, and then here’s the one for machine learning that is like completely different.

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

    [00:19:03] Right? Yeah. I think you would be get what I mean. That’s mostly a safety argument, I guess. But also like it’s actually really useful for people to understand if the model is really good at. Like AI code basically.

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

    [00:19:15] Olivia: Yeah. Oh yeah. Like, my guess is that part of the reason that a lot of benchmarks so far haven’t focused as much on the AI coding is just a question of like, what data sets are easy to gather.

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

    [00:19:24] Yeah. Because a lot of the, like, you know, state of the art AI code bases are proprietary. So if we make evals for that, like we’re probably not gonna release them. And it’s harder for people in the field to make evals that kind of measure. Like, is this a realistic. Research, coding, workflow. I do think that it’s good for the field to try to measure these skills in a public way and think it’s just harder to make it realistic.

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

    [00:19:45] swyx: And then one more thing that a lot of people are trying to do, which is like sort of, well, in, instead of like a percentage of zero to 100, maybe we red denominate in dollars. Right? So you have freelancer and all that. Other people are doing like vending, bench, whatever. Any, any alpha in those [00:20:00] or are they, are they you, you still want like a traditional academic benchmark.

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

    [00:20:04] Mia: I think in a way, like there’s like different ways to measure the same thing, right? If we’re like, oh, this is like how much money it produces. Yeah. It’s a fairly similar thing to saying like, oh, this problem would take like a human, you know, two hours to solve or something like that. Usually they, they’re like fairly like correlated, right?

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

    [00:20:20] Like, however you know much, it would take like a human to solve. That problem kind of determines. The value that we ascribe like a solution. And so I, I do think that is like an important thing is like how complex and how sort of long running are the tasks that we’re like able to entrust our agents with.

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

    [00:20:44] Olivia: Yeah.

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

    [00:20:45] Mia: And so I think that that’s like an important piece, but I, I think here sort of. Monetary value, time, complexity. They all kind of like try to capture like a similar thing.

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

    [00:20:56] swyx: Yeah. Okay. So there, there are proxies for some amount of increasing [00:21:00] capacity that we wanna measure. I think that’s a good thing. I think the only other sort of major player in this field is meter, which has done the sort of long grass and congrats.

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

    [00:21:07] You guys have completely destroyed the curve for that. Any takes on that? Obviously you’ve come up really well, so like it looks good, but I don’t know if like that approach is something that you wanna incorporate in your own work, making it else. This is the long autonomy pass eval. You’re,

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

    [00:21:21] Mia: yeah, yeah.

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

    [00:21:21] No, from we are, and, and, and we, we, we work with, with meter on these evaluations. So like we, we do appreciate them. I think then they’re using time, right? They’re not using money. So I think like that was a, your question. I think like complexity, however we can sort of like quantify it, is really important to understand like where our motive are, are are getting to.

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

    [00:21:42] swyx: Okay. Com complexity is the abstract thing and it projects down the time, projects down to. Story points, whatever dollars. Great.

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

    [00:21:49] Preparedness And Future Directions

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

    [00:21:49] swyx: One last question on just like, just the overall preparedness framework is you know, I was actually kind of looking at, people mentioned the preparedness framework a lot.

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

    [00:21:54] I don’t think it’s well explained to a lot of people. And you actually have a nice website where it’s like I think it’s like test and [00:22:00] like inform and teach something. And I, I feel like you, you actually do a lot of work there and, and I don’t know if you wanna talk about how the preparedness framework applies.

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

    [00:22:08] Olivia: So the preparedness framework is open eyes, kinda like public framework for how we track frontier risks. So these are kind of capabilities that are typically dual use, like you can use ‘em for good things or bad things, but we wanna at least keep an eye out for the bad things to make sure that we ha both we as a company and like the broader society are kind of prepared to handle the potential downsides.

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

    [00:22:28] And so at the moment we kind of track three different categories. One is kind of bio risk, another is cybersecurity, and a third is kind of research automation and model autonomy. And that’s kind of what ties the most into the SWE-Bench, where Got it. Where coding is not all of automating research, but it is one very important key component.

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

    [00:22:47] And so we initially created Swyx Venture verified as part of like building out evals for that mono autonomy work stream. And now. I think for like we have to move beyond that, towards, I’m looking more at like, can models [00:23:00] actually start to actually automate research workflow.

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

    [00:23:02] swyx: Yeah. Amazing.

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

    [00:23:03] Okay. Abi, anything else to add on just the general, what people should know about preparedness and how evals and human data and alignment all work together at that?

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

    [00:23:12] Mia: I think maybe the thing that I would say is that we really appreciate, we, we work really hard to build these events and, and so we, that’s where we published.

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

    [00:23:23] SWE-Bench ver verified and that’s where we’re like sharing GDP via these sorts of things. We also deeply appreciate like other people and the entire field to kind of build EVAs and, and share them. And we use them like SWE-Bench program, like, yes, but that’s a better eva now we should use them. So would really encourage people to find more ways to.

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

    [00:23:43] Create and share ev events that we can, we and the entire field can use to measure like progress.

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

    [00:23:50] swyx: Yeah.

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

    [00:23:50] Mia: On, on, on like a variety of capabilities, including, including coding, because it’s important to understand, so where we are,

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

    [00:23:57] swyx: me, I had to leave. But we’re, we are just kind of [00:24:00] talking a little bit about like the, the future directions that we want evals to go.

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

    [00:24:02] Mia: Mm-hmm.

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

    [00:24:03] swyx: And I, I think here, here we can dive in on like, give us. Good work on these, these, these things. We’ll talk to you, you know here’s your platform to make a call. Look for what you’re looking for.

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

    [00:24:15] Olivia: I think a few things that would be useful. I’d say first of all, really, really hard task. Like the kinds of things that would take top-notch engineers months or teams weeks would be quite good.

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

    [00:24:26] Especially if. Breeding is reliable and breeding is like, you know, you have for example, like rubrics that have been sourced and validated by many people in the field. I think that’d be quite valuable. I think also benchmarks on kind of creating products end to end. I think as people are like putting more, that would be quite useful.

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

    [00:24:42] I think. A third thing that I’d say that is maybe not quite an eval, but I think it’s still relevant to the kind of overall mission of like. We as a field and as a world should be tracking, like where are these capabilities going? I’d like to see more metrics the tracking, like real world usage.

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

    [00:24:57] Like how much is AI [00:25:00] actually being used in the field and how much is it, you know, replacing people’s jobs? How much is it? You know, augmenting people is speeding people up, just like real world metrics. Yeah,

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

    [00:25:08] swyx: yeah. The, the, the replacement thing is always like a sensitive one on the, on the sort of PR side of things.

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

    [00:25:12] But you know, we create new jobs that, that manage the old jobs and that’s how it’s yourself like you know, I think in terms of the frontier evals that, that open I is really going to excited to push like you, you put out really good work every single time. What should people expect from, from OPI itself?

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

    [00:25:28] Olivia: I’m not sure I can say what we’re gonna

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

    [00:25:30] swyx: general directions,

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

    [00:25:31] Olivia: I mean, general directions. I think looking at real world impact, like real world real to,

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

    [00:25:38] swyx: yeah, whatever.

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

    [00:25:38] Olivia: That kind of stuff. Yeah. Yeah.

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

    [00:25:39] swyx: Yeah. Amazing. Okay. Well, I’m excited for more real world impact. I, I think you guys have, you know, really made a lot of progress and I think taking a lot of industry leadership for C Bench verified and, and now moving on to C Orange Pro.

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

    [00:25:50] So thank you for doing this. Thank you for being so transparent. And I think people will respond in kind. Yeah,

    [00:25:57] Olivia: for your time.

    [00:25:58] swyx: Thank [00:26:00] you.

    Discussion about this episode

    Обсуждение этого эпизода

    Latent.Space