Коли OpenAI випустила перші версії своїх мовних моделей, академічні тести з природної мови, шкільні іспити й класичні NLP‑бенчмарки ще могли щось сказати про прогрес. Сьогодні для команди frontier evals, яку очолює дослідниця Tejal Patwardhan, це вже радше історичні артефакти, ніж інструменти вимірювання. Моделі стали настільки сильними, що старі шкали просто «зламались» — і довелося переосмислити, як взагалі вимірювати інтелект систем, здатних писати код, керувати комп’ютером і взаємодіяти з наукою та реальним світом.
Patwardhan прямо говорить: якщо подивитися на дослідницьку дорожню мапу зараз, «я не бачу жодних ознак зупинки… це буде дуже божевільний рік». І саме це відчуття стрімкого фронтиру зробило кризу бенчмарків однією з ключових тем для OpenAI.
Як моделі «переросли» академічні тести
Ще кілька років тому ситуація виглядала просто: були шкільні та університетські іспити, тести з вибором відповіді, класичні NLP‑бенчмарки. Моделі їх не проходили, і завдання дослідників було очевидним: підняти точність.
Поступове покращення призвело до того, що моделі стали впевнено закривати більшість цих завдань. У якийсь момент те, що колись вважалося «людським рівнем», перетворилося на нижню межу можливостей моделей. Старі тести перестали бути корисними як індикатор прогресу.
Patwardhan описує це як поступовий зсув у бік дедалі більш реалістичних і складних задач: від класичних завдань — до довгих ланцюжків дій у реальних середовищах, включно з роботою в браузері, на комп’ютері та зрештою — із взаємодією з фізичним світом.
У якийсь момент команда зіткнулася з ситуацією, коли «стало незрозуміло, як взагалі вимірювати те, що люди реально хочуть робити з моделями». І старі бенчмарки, навіть якщо вони були колись корисними, перестали відповідати на це запитання.
SWE‑bench Verified і межа «насичення»
Одним із символів цього перелому став SWE‑bench. Це був популярний в індустрії тест для оцінки здатності моделей розв’язувати реальні задачі розробників. Здавалося б, серйозна планка: робота з живими Python‑кодобазами, інтегровані тести, реальний девелоперський воркфлоу.
У OpenAI пішли далі і зробили складнішу версію — SWE‑bench Verified. Цей бенчмарк «тестував, наскільки добре модель може взаємодіяти з реальними кодовими базами в Python, як Django, завершувати PR‑и й проходити юніт‑тести». На той момент це був відчутний крок уперед: замість штучних задач — конкретні баг‑репорти, патчі, прогін тестів.
Але навіть він досить швидко втратив гостроту. Patwardhan описує «кризу evals», коли команда тренувала «послідовно кращі моделі, а на SWE‑bench вони виглядали приблизно однаково, бо вже робили це дуже добре». Іншими словами, крива можливостей продовжувала рости, а бенчмарк уже не міг розрізнити рівні.
Тут у гру входить поняття «насичення». У термінах Patwardhan, «насиченість — це коли модель близька до того, щоб пройти всі питання правильно, майже до 100% на тесті». Як тільки бенчмарк наближається до цього стану, він перестає бути корисним як інструмент вимірювання прогресу. Різниця між моделями зникає в статистичному шумі.
Влучна аналогія: «Це як порівнювати двох геніїв на шкільному іспиті з математики… вони обидва просто складуть його, але це не дуже корисно». Коли системи опановують завдання, створені для людей середнього рівня, це радше привід змінити тест, ніж привід святкувати.
Benchmaxxing: спокуса «косметичного прогресу»
Коли з’являються бенчмарки, неминуче виникає й спокуса їх «грати». У спільноті це явище отримало свою назву — benchmaxxing.
Patwardhan формулює це так: «BenchMaxxing — це ідея, що якщо хтось… просто намагається виглядати добре на якійсь оцінці чи бенчмарку, а не робити модель загалом корисною». Замість інвестувати обчислювальний бюджет у те, що реально покращує модель, частина ресурсів може піти на тонке підлаштування під конкретний публічний тест.
Наслідок очевидний: «користувач отримує модель, яка добре виглядає в маркетинговій презентації, але в реальному використанні “це не зовсім те, на що я розраховував”». Саме тому Patwardhan не вагається: «загалом погано. BenchMaxxing — погано».
Вона описує внутрішній підхід OpenAI як протилежний: дослідницька програма має бути «дуже дисциплінованою» щодо того, щоб «інвестувати в загальні покращення моделі в областях, які справді важливі». Eval‑и запускаються «в кінці для порівняння», але «мета не в тому, щоби виглядати добре на eval. Ми хочемо зробити модель, яка корисна, щоб просувати фронтир науки чи роботи».
Ця установка позначається й на публікаціях: OpenAI вже публікувала результати, де їхні моделі були не найкращими. Позиція проста: краще «малювати дуже точну картину того, що наші моделі можуть робити», ніж гнатися за красивими числами.
Від шкільних задач до реальної роботи
Коли старі бенчмарки наситилися, довелося переосмислити саме поняття «гарної оцінки». Patwardhan формулює критерій просто: «найкращі бенчмарки, я думаю, дуже реалістичні й вимірюють те, що людям насправді важливо».
Тому фокус змістився в бік завдань, які виглядають як реальна робота:
- не абстрактний код, а pull request у великій кодобазі з юніт‑тестами;
- не окреме речення, а довга послідовність дій на комп’ютері;
- не штучне завдання, а реальні робочі сценарії з описів бюро статистики праці.
У певний момент команда оцінила, що взагалі «не має уявлення, як вимірювати те, що люди хочуть робити з моделями в реальному житті». Так з’явилися більш амбітні проєкти, на кшталт великої економічної оцінки реальних професій (окрема тема для іншого матеріалу) та рух у бік задач, де модель мусить діяти в складних середовищах, а не просто генерувати текст.
Patwardhan описує еволюцію як послідовну гонку «випередити темп прогресу»: щоразу, як моделі стабільно долають новий рівень, доводиться вигадувати наступний. І дедалі частіше цей «наступний рівень» — це вже не тести на папері, а довгі багатокрокові сценарії в живих системах.
Коли бенчмарки ламаються: помилки, меморизація і «хакнуті» eval‑и
Ще одна причина, чому старі тести перестали бути корисними, — їхня крихкість. Patwardhan наводить приклад: оригінальний SWE‑bench виявився наполовину зламаним — «половина задач була або поламана, або недостатньо специфікована». Попри це, на ньому публікувалися результати як на серйозному yardstick для індустрії.
Така ситуація типова для багатьох академічних бенчмарків: їх створює невелика група дослідників «у лабораторії» для статті, але ніхто не змушений запускати їх у масштабі продакшн‑рейнів та релізних eval‑свіпів. Коли ж те саме робить продуктова організація, проблеми якості спливають моментально.
Є й інша пастка — меморизація. Якщо тестові дані випадково опиняються в тренувальному корпусі, модель може просто «згадати» правильну відповідь, не продемонструвавши жодної реальної навички. У такому разі оцінка фактично вимірює не здатність до міркування, а ступінь витоку бенчмарку в тренінг.
Щоб цього уникати, OpenAI намагається «дуже чисто й дисципліновано» будувати пайплайни даних, виключаючи з тренування будь-які набори, які потім використовуються для оцінки. Але навіть за цієї умови залишаються ще й «хакнуті» eval‑и — там, де модель знаходить неочевидний шлях до правильної відповіді, який не передбачався дизайнерами тесту.
Patwardhan говорить про це як про окрему задачу «чистоти дизайну»: потрібно «тестувати eval‑и в масштабі, дивитися, чи є хакі, і переконатися, що середовища тестування не дозволяють моделі обходити завдання». Інакше замість вимірювати здібності, оцінка міряє кмітливість у пошуку лазівок.
Виміряти те, чого ще немає
На тлі всіх цих труднощів завдання frontier evals виглядає парадоксально: потрібно не просто описати поточний рівень, а й «побачити майбутнє до того, як воно станеться». Patwardhan прямо говорить, що навіть всередині команди прогнози часто виявляються недостатньо сміливими: люди «переоцінюють, скільки часу потрібно, аби наситити бенчмарк».
Коли моделі наближаються до режиму, в якому можуть «працювати днями й тижнями» над однією задачею, статичні короткі тести стають взагалі слабким наближенням реальності. Eval може просто не встигнути за реальними сценаріями використання. Потрібно будувати оцінки довгої дії й паралельно — «закони масштабування», які дозволяють прогнозувати результат через тиждень роботи моделі, бачачи те, що вона показує за перший день.
Саме в цьому контексті фраза Patwardhan про те, що в дорожній мапі «немає жодних ознак зупинки» і що «це буде дуже божевільний рік», звучить не як маркетинговий оптимізм, а як попередження: інфраструктура вимірювання має встигнути за темпом систем, які вона оцінює.
Старі бенчмарки свою роль уже відіграли. Тепер їхнє місце займають складні, болісні для розробки eval‑и на реальному коді, реальних комп’ютерах і, дедалі частіше, з реальними наслідками в лабораторіях і виробничих процесах. І саме ця «біль», як каже команда frontier evals, стає новим moat — тим, що відділяє поверхневе покращення цифр у таблиці від реального розуміння того, наскільки далеко ми вже зайшли.
Джерело
OpenAI Podcast — Why Tejal Patwardhan stopped underestimating the models — Episode 21