Перейти к содержимому

Бенчмарки: как измеряют модели

Каждый анонс новой модели сопровождается таблицей: «74% на SWE-bench Verified», «на 12 пунктов лучше конкурента». Эти цифры взяты из бенчмарков, стандартизированных наборов задач для сравнения моделей. Уметь их читать полезно: это самый быстрый способ прикинуть уровень модели. Но верить им слепо нельзя, и на этой странице разберём почему.

Бенчмарк (benchmark) — это фиксированный набор задач с известным способом проверки ответа. Модели дают задачи, считают долю решённых, и получается число, по которому модели можно сравнивать между собой.

Зачем это нужно, понятно из альтернативы: без бенчмарков сравнение моделей сводится к впечатлениям («мне кажется, эта умнее»). Бенчмарк даёт воспроизводимое измерение: одни и те же задачи, одинаковые условия, объективная проверка. Для индустрии это общая линейка прогресса, для вас это фильтр первого уровня при выборе модели.

Ключевые бенчмарки, о которых стоит знать

Заголовок раздела «Ключевые бенчмарки, о которых стоит знать»

Бенчмарков сотни; для работы с агентами достаточно ориентироваться в нескольких классах.

SWE-bench — самый цитируемый бенчмарк для программирования. Собран из реальных issue открытых проектов на GitHub: модель получает репозиторий и описание бага, должна изменить код так, чтобы прошли тесты, написанные людьми для настоящего фикса. Это близко к реальной работе разработчика: не «напиши функцию с нуля», а «разберись в чужом коде и почини». Чаще всего цитируют вариант SWE-bench Verified — подмножество задач, вручную проверенных на корректность условий.

Terminal-Bench проверяет работу агента в терминале: настроить окружение, собрать проект, разобраться с системными задачами через команды. Хороший индикатор того, насколько модель пригодна именно для агентной работы, где большая часть действий — команды и их вывод.

Тесты знаний класса MMLU — сотни вопросов с вариантами ответов по десяткам дисциплин, от истории до физики. Измеряют эрудицию и понимание, а не умение действовать. Топовые модели давно решают классические тесты знаний почти полностью, поэтому появляются усложнённые наследники (GPQA и другие) с задачами уровня экспертов.

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

Цифра «модель решает 70% SWE-bench» сама по себе значит меньше, чем кажется. На результат влияют условия запуска, и без них сравнение может быть некорректным.

  • Процент решённых считается от какого набора? У бенчмарков бывают варианты (полный набор, Verified, Lite), и проценты по ним несравнимы между собой.
  • Какой харнес? Агентные бенчмарки модель проходит не в вакууме, а внутри обвязки (с инструментами, циклом, промптами). Одна и та же модель в разных харнесах показывает заметно разные цифры. Когда провайдеры хвастаются результатом, они используют собственный, хорошо настроенный харнес.
  • Сколько попыток? «pass@1» — задача решена с первой попытки; встречаются схемы с несколькими попытками или с выбором лучшего из нескольких прогонов, и цифры при этом выше. Сравнивать pass@1 одной модели с «лучшим из десяти» другой бессмысленно.
  • Какой бюджет? Ограничение на время, число шагов и токены тоже влияет: модель с неограниченным бюджетом рассуждений решит больше.

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

Ограничения: почему бенчмаркам нельзя верить слепо

Заголовок раздела «Ограничения: почему бенчмаркам нельзя верить слепо»

Загрязнение данных (contamination). Модели обучаются на текстах из интернета, а задачи популярных бенчмарков в интернете опубликованы, вместе с решениями и обсуждениями. Модель может «решить» задачу, потому что видела её на обучении, а не потому что умеет решать такие задачи. Полностью исключить это трудно; свежие и закрытые наборы задач страдают меньше, чем старые публичные.

Подгонка под бенчмарк. Закон Гудхарта: когда метрика становится целью, она перестаёт быть хорошей метрикой. Бенчмарки — главный маркетинговый аргумент, поэтому у провайдеров есть стимул оптимизировать модели именно под известные наборы задач. Модель, натренированная блистать на SWE-bench, не обязана так же блистать на вашем легаси-монолите.

Отличие от ваших задач. Самое важное ограничение. Бенчмарк измеряет производительность на своих задачах: SWE-bench — это Python-проекты с открытым кодом и хорошими тестами. Ваш стек может быть другим: иной язык, внутренние библиотеки, которых модель не видела, специфичные соглашения, отсутствие тестов. Разрыв между «70% на бенчмарке» и результатом на вашем коде бывает в любую сторону.

К бенчмаркам стоит относиться как к скринингу резюме. Они хорошо отвечают на грубые вопросы: какое поколение моделей сильнее, есть ли между кандидатами разрыв класса «в разы», стоит ли вообще смотреть на модель для агентных задач. Они плохо отвечают на вопрос «какая модель лучше для моей работы».

Финальный тест — ваши задачи. Соберите маленький собственный набор: пять-десять типичных задач вашей команды с понятным критерием успеха (починить конкретный баг, написать тест к модулю, разобрать документ). Прогоните кандидатов через него, в вашем харнесе и на вашем коде, и сравните результаты. Это дёшево, занимает вечер и говорит о пригодности модели больше, чем любой лидерборд. Как оценивать результаты работы модели системно — тема страницы «Проверка результатов».

Автор учебника — Шахматов Алексей