Содержание статьи

В статье Measuring AI Ability to Complete Long Software Tasks (Kwa & West и др., 2025) команда METR ввела понятие 50% time horizon модели: это длительность задачи (в пересчете на время выполнения профессиональным подготовленным человеком), которую модель может автономно завершить с вероятностью 50%. Мы оценили time horizon у флагманских моделей, выпущенных с 2019 года, на бенчмарке, объединяющем три набора задач в области программирования и исследований, с длительностью от 1 секунды до 16 часов для человека (HCAST, RE-Bench и SWAA; далее — METR-HRS). METR обнаружила, что time horizon удваивается каждые 7 месяцев, с возможным ускорением до 4 месяцев в 2024 году.

Существенным ограничением того анализа был домен задач: все они относились к программной инженерии или исследовательской деятельности, в то время как известно, что способности AI значительно варьируются между типами задач^[1]. В этом исследовании мы рассматриваем, сохраняются ли аналогичные тренды к другим типам задач, включая автономное вождение и агентное использование компьютера, применяя методологию, позволяющую оценивать time horizon на менее детализированных данных. Данные для многих из этих бенчмарков менее надежны по сравнению с оригинальной работой, и результаты по каждому отдельному бенчмарку следует трактовать как шумные. Однако в совокупности они демонстрируют схожую динамику.

Домен программного обеспечения и reasoning-задач — таких как научные QA (GPQA), математические соревнования (MATH, Mock AIME), полуреалистичные задачи по программированию (METR-HRS) и соревновательное программирование (LiveCodeBench) — показывает time horizon в диапазоне 50–200+ минут, который в настоящее время удваивается каждые 2–6 месяцев. Таким образом, ~100-минутные time horizons и ~4-месячное время удвоения, наблюдавшиеся на METR-HRS в исходной работе, скорее всего, не являются исключением.

Для задач визуального взаимодействия с компьютером (OSWorld, WebArena) time horizon в 40–100 раз короче, чем у кластеров reasoning и software, но темп роста — аналогичный. В области автопилота (Tesla FSD) улучшения идут медленнее: примерно 0.6 удвоения в год. С точки зрения видео (VideoMME, CGBench) модели уже способны отвечать на вопросы по видео длительностью около часа с точностью >50%, однако сам time horizon может быть неадекватной метрикой для этого домена. Ни в одной из рассмотренных областей прогресс не демонстрирует явно субэкспоненциального характера.

С учётом того, что реальный мир более разнообразен, чем любой бенчмарк, можно ожидать, что time horizons для всех экономически значимых задач будут различаться на несколько порядков. Кроме того, многие из приведённых time horizon — это экстраполяции за пределами фактического диапазона длительности задач в бенчмарках; ниже мы обсуждаем ограничения данных и сопутствующие оговорки. Тем не менее, полученные результаты указывают, что даже в тех доменах, где сегодня ИИ способен заменять человека лишь на секунды или минуты, в ближайшие 5 лет мы можем увидеть экспоненциальный рост вплоть до time horizons, измеряемых днями и неделями.

^{[1] Даже небольшие изменения в домене задачи могут приводить к существенным различиям в сравнительной производительности ИИ и человека. Взглянем на шахматы,Go и покер — три из самых популярных соревновательных игр. Сверхчеловеческий шахматный движок был создан в 1997 году, однако из-за огромного пространства состояний Gо удалось покорить лишь в 2016 году, а покер — в период с 2017 по 2019 год. Тамай Берсилоглу отметил, что шахматные движки, вероятно, обладают time horizon, измеряемым годами.}

Методология

Вместо того чтобы проводить новые эксперименты, мы отобрали 9 существующих бенчмарков, которые (a) позволяют хотя бы приблизительно оценить распределение времени выполнения задач человеком и (b) имеют публично доступные результаты для многих фронтирных AI-агентов. Мы используем логистическую модель, аналогичную той, что применялась в оригинальной статье, где h_agent — это 50% time horizon, t_task — временная сложность задачи, а β_agent — подгоняемый параметр наклона, но дополнительно вводим параметр случайной точности c_task для бенчмарков с выбором из нескольких вариантов:

В оригинальной статье для каждой пары (агент, задача) вычислялся индивидуальный скор, после чего применялась логистическая регрессия. Однако большинство доступных в открытом доступе бенчмарков предоставляют только агрегированные показатели, процент правильных ответов на всём бенчмарке, поэтому требуется альтернативный метод для аппроксимации логистической кривой.

Когда доступны метрики по отдельным задачам или подмножествам задач внутри бенчмарка (например, деление на easy/medium/hard в LiveCodeBench), мы применяем метод максимального правдоподобия (MLE), чтобы оценить значения h_agent и β_agent, наиболее согласующиеся с наблюдаемыми результатами^[2]. Если более чем у половины моделей значение β оказывается ниже 0.25 (что эквивалентно коэффициенту увеличения шансов на неуспех менее чем в 1.28 раза при удвоении длительности задачи), мы считаем зависимость между временем выполнения человеком и успешностью слишком слабой для осмысленной оценки time horizon и исключаем такой случай из основного анализа.

Когда доступен только один агрегированный скор, невозможно независимо оценить как  h_agent, так и β_agent. В таких случаях мы предполагаем, что β_agent равен среднему значению по набору METR-HRS, использованному в оригинальной статье, — примерно 0.6. Затем мы подбираем значение h_agent так, чтобы предсказанное среднее значение скоров совпадало с фактическим скором агента s_agent, учитывая оценочные значения длительности задач t_task^[3]

Поскольку этот метод может давать большие ошибки при оценке time horizon далеко от медианного времени задач в бенчмарке, он подходит только в тех случаях, когда доступно недостаточно разбивок, чтобы применить метод MLE. Мы рекомендуем исследователям, когда возможно, использовать данные по отдельным задачам и на их основе рассчитывать time horizon.

Чтобы построить трендлайн, мы сохраняем только фронтирные модели (с horizon выше любого предыдущего значения) и аппроксимируем линейным сплайном^[4].

На METR-HRS значения time horizon, полученные с использованием только агрегированных показателей успешности, отличаются от результатов, полученных исходной методикой, менее чем в 2 раза (в пределах погрешности) и обычно лежат в пределах ± 25%. Основное расхождение, по-видимому, связано с разным весом задач в зависимости от их разнообразия^[5].

Помимо этого, мы внесли два методологических улучшения по сравнению с оригинальной статьей о time horizon.

Во-первых, в оригинальной работе длина задачи определялась как геометрическое среднее времени выполнения человеком при условии успеха (conditional on success). Здесь же мы учитываем тот факт, что низкая успешность делает задачу труднее, и оцениваем ее длительность как если доступны данные о частоте успеха у людей^[6].

Во-вторых, мы вводим поправку на случайную точность (chance accuracy) в задачах с множественным выбором, используя переменную c_task ^[7].

Для данных Tesla FSD используется совершенно иная методология (см. раздел "Подробности по отдельным бенчмаркам").

В целом, предложенные здесь изменения позволяют оценивать time horizon без необходимости повторного проведения экспериментов. Однако если отсутствуют хотя бы данные подмножеств по производительности и невозможно оценить β, ошибки в оценке time horizon могут быть значительными^[8].

Наш код вы можете посмотреть тут.

^{[2] Это проще, чем полный байесовский подход, и поскольку у нас слабые априорные представления относительно horizon и slope, мы не используем MAP.}

^{[3] В частности, поскольку рассматриваемая величина монотонно возрастает по отношению к h_agent, мы можем использовать бинарный поиск.}

^{[4] Это дата релиза основной модели; в таблице лидеров OSWorld иногда указываются вспомогательные модели размером около 7B, используемые для GUI-grounding.}

^{[5] В оригинальной статье мы группировали задачи в «семейства задач» с похожей реализацией (например, варианты одного и того же типа вопроса).}

^{[6] Скорректированное время равно ожидаемому времени, которое тратит человек (случайно выбранный из популяции) до первого успешного выполнения. Коррекция по человеческой точности проводится для OSWorld, MATH и AIME. Мы не делаем эту корректировку для METR-HRS, поскольку многие ошибки в baseline были связаны с причинами, не применимыми к моделям (например, отсутствие релевантной экспертизы или мотивации); подробнее см. в оригинальной статье. Это может смещать оценки horizon в сторону уменьшения по сравнению с другими доменами.}

^{[7] C_task принимается равным нулю для задач со свободным ответом, 1/n — для задач с выбором из n вариантов ответа, и 1/1000 — для AIME, где ответы — целые числа от 0 до 999 включительно.}

^{[8] Если β очень мало, time horizon может вообще оказаться непригодной метрикой; см. приложение.}

Бенчмарки

Результаты

Тренды в других доменах

Ключевой вывод

Интеллектуальные домены, такие как научные QA (GPQA), математические олимпиады (MATH, AIME) и программирование (METR-HRS, LiveCodeBench), демонстрируют time horizon в диапазоне 50–200 минут, который в настоящее время удваивается каждые 2–6 месяцев. Таким образом, наблюдаемые в METR-HRS горизонты порядка 100 минут и время удвоения около 4 месяцев (с 2024 года) не являются исключением.

Дополнительные наблюдения

• По состоянию на март 2025 года фронтирный time horizon в задачах агентного взаимодействия с компьютером, будь то с DOM-вводом (WebArena) или с визуальным интерфейсом (OSWorld), примерно в 50 раз короче, чем в интеллектуальных доменах. Одна из гипотез — плохой инструментарий: авторы OSWorld отметили, что 75% неудачных кейсов были связаны с неточными кликами мыши^[10], хотя это вряд ли объясняет слабую производительность на WebArena. Несмотря на гораздо меньший time horizon, время удвоения в этих доменах сопоставимо с другими и отстает от "интеллектуального" кластера примерно на 2 года.

• Скорость прогресса заметно варьируется: Mock AIME демонстрирует удвоение за ~3 месяца,в то время как Tesla FSD — за ~20 месяцев. Тем не менее, все домены показывают экспоненциальный или слабо суперэкспоненциальный рост. Ни один из них не демонстрирует субэкспоненциального роста или стагнации.

• На видеобенчмарках, таких как Video-MME (не показан на графике), корреляция между длиной видео и сложностью задачи слишком слаба, чтобы надежно определять time horizon. Тем не менее, модели уже уверенно превышают порог в 50% успешности на видео длительностью около часа.

  • Так, Gemini 1.5 Pro показывает: 81.7% точности на видео <2 минут, и 67.4% на видео длительностью 30–60 минут, что позволяет экстраполировать: его точность опустится ниже 50% только на видео длиной более 1000 минут.

  • Прогон GPT-4o-mini на CG-Bench, где аннотированы именно те отрезки видео, которые действительно релевантны вопросу, показывает, что с точки зрения видео нет устойчивой связи между длиной видео и его сложностью, даже если ограничиваться релевантными фрагментами.

  • В следующем разделе мы подробно обсуждаем, для каких бенчмарков метрика time horizon применима, а для каких — нет.

• Также мы исключили несколько индивидуальных точек с низкой корреляцией между сложностью и временем выполнения человеком (β<0.25\beta < 0.25β<0.25). Например, на GPQA Diamond индивидуальная точность моделей перестаёт коррелировать со временем выполнения человеком, когда бенчмарк приближается к насыщению.

Ниже мы показываем те же данные, разбитые по подграфикам и с включением не-фронтирных моделей.

Времена удвоения на этом графике определяются как календарное время между тем, как сглаженный сплайн достигает 2-го и 98-го процентилей длительности задач в бенчмарке (или подмножества, если диапазон короче).

^{[10] Из статьи OSWorld: «Среди 550 неудачных примеров из разных конфигураций в нашей выборке более чем в 75% случаев присутствуют неточности кликов мышью, что является наиболее распространённой ошибкой. Агент не смог кликнуть по корректным координатам, несмотря на то, что в комментариях к коду были спланированы детализированные и точные шаги, что указывает на сильные навыки планирования, но слабые способности к исполнению».}

Обоснованность метрики time horizon

Существует несколько аргументов в пользу того, что успешность на задачах может описываться логистической кривой, в терминах параметра способности агента η и параметра сложности задачи α:

Теоретически такая логистическая модель стандартна в теории item response (IRT), применяемой при проектировании как бенчмарков, так и экзаменов для людей. Эмпирически, Epoch AI и другие нашли сигмоидальные зависимости между результатами на бенчмарках и такими параметрами, как вычислительные ресурсы, количество параметров модели и время. METR использовала более специализированную форму этого закона, в которой сложность задачи моделируется как логарифмическая функция длительности задачи для человека:

Для того чтобы логистическая модель time horizon была валидной, время выполнения задачи человеком должно быть сильным предиктором ее сложности для ИИ. В оригинальной статье это подтвердилось для METR-HRS, но неясно, сохраняется ли такая зависимость и в других доменах или же её можно достоверно измерить только на бенчмарках с достаточно широким диапазоном длительностей задач.

Мы можем построить график зависимости между длительностью задачи и ее сложностью для нескольких бенчмарков, и по углу наклона кривой оценить: чем он круче, тем в большей степени успешность модели зависит от длительности задачи для человека.

На некоторых бенчмарках, например LiveCodeBench (оранжевый), длительность задачи сильно коррелирует со сложностью для моделей. В других, таких как Video-MME (синий), эта корреляция гораздо слабее. Мы предполагаем, что это связано с тем, что сложные задачи в LiveCodeBench отличаются от простых не только длительностью.

На GPQA Diamond (фиолетовый) наблюдается сильный шум из-за малого объёма данных и узкого диапазона длительности задач. При этом зависимость кажется выраженной у слабых моделей (например, GPT-4 Turbo), но менее очевидной у более сильных (например, Gemini 2.5 Pro). В целом данные грубо соответствуют логистической модели, но шум достаточен, чтобы допускать и другие возможные зависимости.

Построив значения наклона β_agent для подогнанных логистических кривых, мы можем понять, насколько сильно коррелируют производительность агента и длительность задачи для каждой модели на конкретном бенчмарке.

Наконец, мы рассмотрели, как эта зависимость меняется в зависимости от производительности модели. В бенчмарках METR-HRS, LiveCodeBench и Mock AIME (не показан) логистический наклон остаётся стабильным при разных уровнях способностей. Однако в GPQA Diamond и VideoMME наблюдается ослабление этой зависимости по мере насыщения бенчмарка: лучшие модели практически не показывают худшие результаты на более длинных задачах по сравнению с короткими, поэтому их time horizon невозможно надежно оценить.

Когда длительность выполнения задачи человеком является сильным предиктором её сложности, можно предположить, что успех в задаче описывается мультипликативной функцией — т.е. успех зависит от выполнения возрастающего числа подзадач, пропорционального длине. На это также указывает Тоби Орд, отмечая, что такая зависимость предполагает экспоненциальную, а не логистическую модель.

Хотя (реальная или оцененная) длительность выполнения задачи человеком часто хорошо коррелирует с фактической успешностью моделей, мы обнаружили, что связанные величины — такие как длина видео или стоимость фриланс-задачи — могут плохо коррелировать с успешностью модели. Мы предостерегаем от использования таких показателей для оценки способностей моделей. В подобных случаях «эффективный горизонт сложности» может быть менее информативен, чем просто указание процентного score; ниже мы приводим два примера.

Длина видео — плохой предиктор сложности

Большинство бенчмарков на понимание видео включают распределение длин видеороликов. Интуитивно может показаться, что длина видео — хороший индикатор сложности, но на практике зависимость может быть слабой как для людей, так и для моделей. Во-первых, человек, имеющий доступ к интерактивному видеоплееру, скорее всего, может ответить на вопросы быстрее, чем длится само видео. То есть длина видео — это даже не надёжный прокси для времени выполнения человеком, по крайней мере, в экономически значимом контексте.

Кроме того, длина видео слабо коррелирует с результатами моделей на ряде видеобенчмарков помимо VideoMME. Например, на LVBench длина почти не влияет на успешность. На LongVideoBench (видео от 8 секунд до 1 часа) GPT-4o показывает падение успешности всего на 10% между самой короткой и самой длинной группой. Более того, агенты обычно набирают меньше на видео 8–15 секунд, чем на видео 15–60 секунд.

Мы предполагаем, что слабая корреляция связана с тем, что количество фундаментальных шагов не масштабируется с длинной видео. Задачи видео-QA часто требуют обращения к нескольким точкам в ролике^[12], но поскольку вопросы почти всегда одной длины, видеобенчмарки не имеют мультипликативной структуры.

Чтобы проверить, объясняется ли отсутствие корреляции наличием длинных нерелевантных фрагментов видео, мы проанализировали другой видеобенчмарк — CG-Bench, который, как и VideoMME, содержит аннотации по длине подсказки (clue length) — совокупной длительности тех отрезков, которые действительно нужны для решения задачи. Так как CG-Bench не публикует разбивки по длине, мы прогнали GPT-4o-mini-2024-07-18 на 3000 задачах бенчмарка с использованием официального репозитория. Полученный score составил 48.7% (против 48.4% на leaderboard). Результаты GPT-4o-mini на видео с разной длиной подсказки показали либо отсутствие зависимости, либо очень слабую отрицательную зависимость между длиной релевантных сегментов и успешностью (точечная оценка: –0.0087 успешности на каждое удвоение длины подсказки; 95% доверительный интервал по наклону: (–0.020642, 0.003241)). Таким образом, можно заключить, что длина видео почти не увеличивает сложность задачи для моделей — по крайней мере, в рамках текущих условий бенчмарков. Возможно, время выполнения задач человеком имеет более сильную связь со сложностью, но нам не удалось найти доступный источник данных по human baseline.

Стоимость задачи в SWE-Lancer — плохой предиктор сложности

На фриланс-бенчмарке по программированию SWE-Lancer (Miserendino и др., 2025), который моделирует задачи в сфере фриланс-разработки ПО, производительность модели o1 не демонстрирует значимой корреляции со стоимостью задачи. Это оказалось неожиданным, поскольку навыки, проверяемые в SWE-Lancer, кажутся близкими к тем, что используются в других реалистичных бенчмарках, таких как HCAST и SWE-Bench Verified. Какова бы ни была причина, расчёт «горизонта по стоимости задачи» (task value horizon) для AI-системы на SWE-Lancer, вероятно, не имеет особого смысла. Вместо этого можно отслеживать такие метрики, как «скорость заработка» (earn rate), о которой сообщают Miserendino и соавторы, или использовать невзвешенное среднее.

^{[11] В LiveCodeBench оценка длительности задач основана на эмпирическом правиле: лёгкие задачи с LeetCode должны занимать около 8 минут, средние — 20 минут, а сложные — 40 минут. Мы не испытываем особой уверенности в этой оценке, однако наблюдаемый наклон (slope) на LiveCodeBench значительно круче, чем на METR-HRS. Если бы истинный наклон METR-HRS и LiveCodeBench совпадал, сложные задачи LiveCodeBench должны были бы быть примерно в 40 раз длиннее лёгких, что представляется маловероятным.}

^{[12] См. раздел «Benchmark» на сайте Video-MME или ознакомьтесь с соответствующей статьёй для примеров заданий.}

Проверка надёжности

Мы можем проверить надёжность наших методов, сравнивая бенчмарки, где доступны данные по индивидуальным задачам, с бенчмарками, где имеются только агрегированные результаты. Для AIME и GPQA мы сравниваем данные Epoch AI (с долей успеха для каждой пары (модель, задача)) с данными по аналогичным бенчмаркам, собранными из открытых источников (только общий score модели); для METR-HRS и LiveCodeBench мы рассчитываем приближенный time horizon с помощью метода бинарного поиска, несмотря на то, что у нас есть достаточно данных для применения оригинального метода METR-HRS или MLE-метода LiveCodeBench. В каждом приближенном методе мы предполагаем, что β = 0.6, даже если нам известно, что истинные значения β другие.

Приближенные данные для AIME (светло-голубой цвет) показывают более быстрый рост time horizon, чем Mock AIME от Epoch AI, вероятно, из-за отсутствующих данных по моделям начала 2024 года. Приближенный метод для GPQA также даёт более крутой наклон, чем GPQA Diamond, поскольку β ниже у высокоэффективных агентов на GPQA Diamond, а метод бинарного поиска это не учитывает. В случае с LiveCodeBench наблюдается противоположное: LiveCodeBench (приближенный) показывает более крутой наклон, чем оригинальный LiveCodeBench, потому что реальное значение β для LiveCodeBench значительно выше 0.6. Метод бинарного поиска интерпретирует высокие агрегированные скоры модели o4 mini на LiveCodeBench как гораздо более высокие time horizon, в то время как на самом деле они лишь немного выше.

Ограничения и направления будущей работы

Другие домены: Экономически значимые задачи значительно более разнообразны, чем охваченные в этом исследовании. Например, две самые распространённые высокооплачиваемые профессии в США — управление и сестринское дело, ключевые навыки которых практически не представлены в этих бенчмарках.

В частности, у нас крайне мало доменов с короткими time horizon (фактически только OSWorld), поэтому мы не знаем, будут ли такие домены демонстрировать «догоняющий рост» или останутся в стагнации. При попытках предсказать автоматизацию R&D в AI или автоматизацию экономики в целом, конкретная дата и скорость автоматизации будут, скорее всего, зависеть от скорости прогресса в тех навыках, которые будут автоматизированы последними. Поэтому идентификация самых трудных для AI навыков и оценка темпов их улучшения особенно важны.

Все бенчмарки в определенной степени искусственны: Мы предполагаем, что любые бенчмарки проще, чем реальные задачи в соответствующем домене: задачи в бенчмарках почти всегда дешевы в запуске и оценке, а значит, легче улучшаются с помощью RL. Даже если конкретный бенчмарк не искажен, он всё равно представляет собой более легкое распределение задач по сравнению с реальностью. Поскольку мы рассматриваем только бенчмарки (за исключением автопилота), мы не знаем, насколько велик разрыв между бенчмарками и реальными задачами — и выражается ли он в постоянном коэффициенте или в разной скорости прогресса. Также вероятно, что бенчмарки выбираются из тех доменов, где ожидается прогресс в ближайшие месяцы после публикации — что может вносить смещение в сторону более быстроразвивающихся областей.

Недостаточные данные: Многие бенчмарки не имеют human baseline, поэтому нам приходится оценивать длительность задач разными методами; при этом тренд time horizon довольно чувствителен к распределению длительностей задач. Также сильно возрастает неопределенность для бенчмарков без разбивок (splits), в отличие от тех, где доступно несколько подмножеств задач, позволяющих определить параметр β. Это особенно актуально для OSWorld, так как он единственный в своем домене. Что касается производительности агентов, некоторые лидерборды не включают лучшие модели. Например, в LiveCodeBench самая ранняя точка — Claude 3 Haiku; но Claude 3 Opus, вероятно, показал бы значительно более высокие результаты.

Elicitation и масштабирование вывода: В задачах METR-HRS модели получали достаточно ресурсов на inference, чтобы их производительность достигала плато. Методология Epoch AI для GPQA Diamond, MATH L5, AIME и SWE-bench Verified была стандартизирована. Однако многие лидерборды содержат разнообразные scaffolds, что может означать, что сравнение моделей между собой некорректно.

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

Заключение

В этом посте мы рассмотрели, как time horizon и времена удвоения 4–7 месяцев, обнаруженные Kwa и West и др. (2025) на задачах по программированию, соотносятся с другими доменами. Мы оценили time horizon в других бенчмарках, используя ту же логистическую модель, подгоняя её с помощью метода максимального правдоподобия (MLE) там, где доступны (1) оценки времени выполнения задач человеком и (2) публичные данные о производительности агентов по нескольким уровням сложности. Даже при наличии только агрегированных результатов можно зафиксировать значение β и получить более шумную, но всё же полезную оценку time horizon.

Мы наблюдаем экспоненциальные или сверхэкспоненциальные тренды роста во всех исследованных случаях, хотя разброс как в значениях time horizon, так и в скоростях роста значителен. Бенчмарки по программированию, олимпиадной математике и QA демонстрируют горизонты 30–200+ минут, удваивающиеся каждые ~2–6 месяцев, при этом METR-HRS находится в среднем диапазоне. Агентные задачи с GUI (OSWorld) по-прежнему примерно в 100 раз короче, чем программирование или математика; автопилот Tesla показывает значительно более медленный прогресс, чем другие домены.

Ограниченность текущих источников данных делает наши оценки шумными. Но что еще важнее — все приведенные нами данные основаны на бенчмарках в ограниченном наборе доменов, преимущественно там, где ИИ уже показывает хорошие результаты. Будущие исследования в других доменах, особенно с короткими time horizon, могут дать прямые свидетельства о технологических узких местах, мешающих автоматизации опасных способностей и R&D в области AI.

Приложение

Потенциальные будущие эксперименты

Ниже приведён список экспериментов в примерном порядке приоритетности, которые могли бы расширить текущие результаты:

1. Данные об успешности на уровне задач для OSWorld, WebArena, MATH и RLBench, чтобы проверить силу корреляции между длительностью задачи и ее сложностью, так как это может влиять на скорость роста time horizon.

2. Анализ с использованием item response theory (IRT) для GPQA Diamond, чтобы определить, связано ли высокое значение time horizon и низкое значение β у o3-mini с шумом в аннотациях или с чем-то другим.

3. Бейзлайны для некоторых бенчмарков, в которых отсутствуют данные о времени выполнения задач человеком:

   1. Визуальные головоломки, такие как ZeroBench, VisualPuzzles и ARC-AGI. Однако некоторые из них были сконструированы как adversarial-примеры, сложные именно для AI, и могут не быть репрезентативными с точки зрения экономически полезной работы.

   2. Классические бенчмарки по распознаванию изображений: MNIST, ImageNet. Это позволило бы построить тренд на более длительном промежутке времени.

   3. Бенчмарки опасных способностей, такие как CVE-Bench и ProtocolQA.

   4. FrontierMath, который имеет гораздо более высокий «потолок» по сравнению с другими QA-бенчмарками.
      

Подробности по отдельным бенчмаркам

• METR-HRS (HCAST/RE-Bench/SWAA)

  • Данные по людям получены через бейзлайны для большинства задач; примерно для 24 из 170 задач было оценены приблизительно, так как получить успешный бейзлайн не удалось. Данные о success rate людей не используются, поскольку многие неудачи бейзлайнов были вызваны причинами, не релевантными для моделей (подробнее см. оригинальную статью).

  • Данные по агентам включают 8 прогонов каждой модели с scaffold от METR.

• SWE-bench Verified

  • Данные по людям — это аннотации времени, собранные OpenAI, чтобы оценить, сколько времени потребуется инженеру, знакомому с кодовой базой, на решение задачи.

  • Данные по агентам — от Epoch AI. Обратите внимание, что модели OpenAI o1 и o3 исключены.

• OSWorld

  • Длительность задач для человека — это длина демо из рисунка 4 и таблицы 6 статьи OSWorld. Мы применяем поправку 1 / 0.7236 для учёта человеческой успешности на основе 72.36% успешности, приведённой в статье.

  • Данные по агентам — из публичного лидерборда.

• WebArena

  • Длительность задач для человека и данные об успешности агентов извлечены из официального лидерборда и репозитория; значения длительности получены из доступных trace-данных.

• Mock AIME

  • Длительность задач для человека оценивалась на основе распределения времени, которое участники должны тратить на вопросы в 15-вопросном экзамене продолжительностью 180 минут. В частности, мы предположили, что распределение времени по вопросам логарифмически равномерное, а самая длинная задача занимает в 5 раз больше времени, чем самая короткая.

  • Временные оценки скорректированы с учётом success rate, полученным на основе априорного распределения сложности задач IRT для человека с баллом около 10 (примерно топ-250 в США), с диапазоном от 0.98 для первого вопроса до 0.10 для пятнадцатого. При сравнении с топ-участниками AIME длительности задач будут меньше, но мы выбрали данный уровень способностей для согласованности с бейзлайнами METR-HRS, MATH и других бенчмарков.

  • Данные по агентам — от Epoch AI.

  • Также используются данные по другим бенчмаркам AIME из сторонних источников для проверки надёжности.

• MATH

  • Для получения оценок времени выполнения задач человеком я (Thomas Kwa) создал простое приложение и самостоятельно решил задачи из train-набора, пока не набрал по 4 примера в каждом из 5 уровней сложности, дав 24 правильных ответа из 28. Я не использовал калькулятор или внешние инструменты (в соответствии с правилами олимпиад по математике). Мы моделируем времена выполнения в каждом bucket как логнормальные и корректируем длительности в зависимости от моей успешности в этом bucket.

  • Данные по агентам — с лидерборда HuggingFace. Были отфильтрованы агенты, использовавшие код или другие инструменты.

• LiveCodeBench

  • Так как LiveCodeBench состоит в основном из задач LeetCode и AtCoder, я использовал свои приблизительные медианные времена прохождения задач на LeetCode во время подготовки к собеседованиям: m = (8, 20, 40) минут для (easy, medium, hard) соответственно. Мы моделируем длительности в каждом bucket как логарифмически равномерные от m/2 до 2m.

    • Это может быть неточно, если в последней версии LiveCodeBench увеличена доля задач с Codeforces, которые значительно сложнее.

• GPQA Diamond

  • Оценки времени выполнения человеком — это среднее значение из двух экспертных аннотаций, включённых в бенчмарк GPQA.

  • Данные по агентам — от Epoch AI.

• Video-MME

  • Оценка длительности задач для человека — длина видео. Это может быть неточной метрикой, так как человек с интерактивным видеоплеером, скорее всего, может ответить на вопросы быстрее, чем длительность видео

  • Данные по агентам — с лидерборда Video-MME, включающего результаты без использования субтитров (no-captions) по разбивке на easy / medium / hard. Обратите внимание, что данные не обновлялись с момента выхода Gemini 1.5.

• Tesla FSD

  • Оценки времени выполнения задач человеком рассчитываются из расстояния, предполагая скорость 30 миль/ч в городе и 60 миль/ч на шоссе. Мы предполагаем, что поездка без вмешательств в течение часа равна успешному выполнению задачи длиной в час.

  • Данные по агентам — это среднее расстояние между вмешательствами по данным Tesla FSD Tracker — сайта, объединяющего опросы и два сторонних трекера. Мы исключаем версии с малым числом миль по городу или шоссе, нормализуем к равному количеству городских и шоссейных миль и умножаем на ln(2), так как агент с постоянной вероятностью отказа и MTBF = k минут будет иметь 50% вероятность сбоя на отрезке k * ln(2). Возможно, в этих данных есть смещение из-за того, что люди используют FSD только в условиях, где он хорошо работает, но более серьёзная проблема в том, что Waymo, вероятно, опережает Tesla в автономном вождении^[13].

• RLBench

  • Оценки времени выполнения человеком предполагаются равными длине демонстраций, включенных в 18 задач RLBench, использованных для оценки.

  • Данные по агентам — из публичного лидерборда.

Эффективная средняя длительность задач

См. этот документ по теме: [ext] Getting task duration from baseliner time distribution.

^{[13] К сожалению, Waymo не публикует необходимые нам данные. Компания заявляла о тысячах миль пробега между вмешательствами (interventions) ещё с 2017 года — задолго до того, как автономное вождение стало приносить значимую выручку. Однако их заявления не поддаются однозначной интерпретации.}

Другие графики

Необработанные данные

Без метрики time horizon трудно интерпретировать эти значения в терминах, откалиброванных на человека, но необработанные процентные scores позволяют лучше отслеживать прогресс на таких бенчмарках, как Video-MME и GPQA Diamond, где time horizon либо неприменим, либо нестабилен.