Как читать бенчмарки LLM и что из них пригодится в вашем проекте

В анонсе новой модели — проценты, графики и таблица с бенчмарками LLM. В рабочем чате уже спрашивают: «Ну что, переезжаем?» Вопрос резонный. Ответа в анонсе нет: цифры говорят о том, как модель справилась с чужими задачами, собранными под чужие цели. Про вашу задачу они молчат.

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

Статья будет полезна всем, кто хоть раз смотрел на таблицу с процентами и решал, стоит ли менять модель. Разработчикам, продактам, аналитикам — и тем, кто просто хочет понимать, что стоит за строчкой в лидерборде.

Что такое бенчмарк LLM

Бенчмарк LLM — это фиксированный набор задач с известными правильными ответами, одинаковый для всех моделей.

Работает это так. Есть список задач и эталонный ответ к каждой. Модель получает задачу, выдаёт свой вариант, его сверяют с эталоном. Задач тысячи, все модели проходят через один и тот же список. На выходе — доля правильных ответов.

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

Практическое следствие простое. Бенчмарк сужает список кандидатов до двух-трёх моделей, с которыми стоит работать. Но он не отвечает на вопрос, какая из них лучше справится с вашими задачами. 

Из чего состоит замер

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

Датасет задач. Это список входных данных, на которых проверяют модель. В HumanEval 164 задачи на Python, каждая — описание функции, которую нужно написать. В MMLU-Pro — 12 тысяч вопросов с вариантами ответов. Размер датасета определяет, насколько статистически значим результат: на двадцати задачах разница в один ответ даёт пять процентных пунктов.

Промпт и формат подачи. Одна и та же задача, поданная по-разному, может дать разный ответ. Промпт задаёт инструкцию: «напиши функцию», «выбери правильный вариант», «объясни решение». Если в промпте есть few-shot примеры, модель видит образец того, что от неё ждут. 

Способ проверки ответа. Здесь решается, как именно ответ модели превращается в оценку. Для кода в HumanEval запускают сгенерированную функцию на скрытых тестах и считают долю задач, которые прошли все проверки — метрика pass@1. Для вопросов с выбором варианта ответ сравнивают с эталонной буквой. Для текстовых задач считают точное совпадение, F1, BLEU или ROUGE. Способ проверки может быть детерминированным (код) или модельным (LLM-as-a-judge).

Итоговая метрика. Это число, которое попадает в лидерборд. Pass@1 означает долю задач, решённых с первой попытки. Pass@10 — долю задач, где хотя бы один из десяти ответов оказался правильным. Exact match — долю ответов, полностью совпавших с эталоном. Точность метрики определяет, насколько вы можете доверять итоговой цифре.

Возьмём задачу из HumanEval. Модель получает описание функции на Python и должна написать код. 

Гипотетический пример:

def has_close_elements(numbers: List[float], threshold: float) -> bool:
    """ Проверяет, есть ли в списке два числа, разница между которыми меньше порога. """

Модель выдаёт код. Дальше начинается самое интересное — как этот код проверить. Если парсер вывода ожидает чистый код без markdown-обёртки, а модель вернула код в тройных бэктиках, задача засчитывается как проваленная. Хотя функционально решение правильное. Если тот же ответ прогнать через harness, который умеет вытаскивать код из markdown, балл будет другим.

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

Какие бенчмарки читают в 2026 году

Бенчмарки делятся по доменам. Внутри каждого есть насыщенные — те, где все фронтирные модели уже упёрлись в потолок и разница между ними лежит в пределах погрешности. Есть рабочие — те, которые ещё различают модели. По состоянию на 2026 год картина следующая.

Бенчмарк	Домен	Что измеряет	Состояние
MMLU-Pro	Знания и рассуждения	12 000 вопросов, 10 вариантов ответа	Приближается к насыщению
GPQA Diamond	Знания и рассуждения	198 вопросов уровня PhD по физике, химии, биологии	Насыщенный
ARC-AGI-2	Абстрактное рассуждение	Визуальные головоломки на обобщение	Рабочий
HumanEval	Код	164 задачи на Python	Насыщенный
SWE-bench Pro	Код и агентные задачи	1 865 реальных задач из 41 репозитория	Рабочий
Terminal-Bench 2.0	Агентные задачи	89 задач в терминале	Рабочий
τ²-bench	Агентные задачи	Многошаговые диалоги с инструментами	Рабочий
MMMU-Pro	Мультимодальность	Вопросы по изображениям и графикам	Рабочий
MERA	Русский язык	21 задача на reasoning, код и знания на русском	Рабочий

Знания и рассуждения

MMLU-Pro — это переработанная версия оригинального MMLU. В оригинале было четыре варианта ответа, в Pro — десять. Вопросы стали сложнее, меньше стало задач, где можно угадать. По состоянию на сентябрь 2026 года лидеры набирают около 90%. Это уже близко к потолку: когда все сильные модели в одной весовой категории показывают примерно одинаковый результат, бенчмарк перестаёт различать их между собой.

GPQA Diamond — 198 вопросов, которые писались так, чтобы на них не мог ответить Google. Уровень — выпускник профильного вуза или аспирант-физик. К середине 2026 года несколько фронтирных моделей укладываются в полосу шириной 1,4 процентных пункта в районе 90–95%. Это насыщенный бенчмарк. Смотреть на него, чтобы выбрать между двумя топовыми моделями, смысла нет.

ARC-AGI-2 — другое дело. Это визуальные головоломки, которые проверяют способность к абстрактному обобщению. Здесь разрыв между моделями огромный: лидеры набирают 75–85%, а медиана по всем протестированным моделям — 5,8. Если ваша задача требует нестандартного мышления, этот бенчмарк информативнее, чем MMLU.

Код и агентные задачи

HumanEval — 164 задачи на Python, которые писались в 2021 году. Сейчас топовые модели набирают 96–99% pass@1. Бенчмарк насыщен. Как инструмент для отсева слабых моделей он ещё работает — если модель не набирает 90%, это сигнал. Но разницу между двумя лидерами он не покажет.

SWE-bench Verified — это набор реальных issue из популярных Python-репозиториев. Модель должна не только написать функцию, но и разобраться в чужом коде, найти баг и предложить патч. В феврале 2026 года OpenAI опубликовала разбор, в котором назвала SWE-bench Verified загрязнённым и рекомендовала переходить на SWE-bench Pro. SWE-bench Pro — это 1 865 задач из 41 репозитория, собранных так, чтобы минимизировать утечку данных из обучающих выборок.

Terminal-Bench 2.0 измеряет, умеет ли модель работать в терминале: запускать команды, читать вывод, исправлять ошибки. По состоянию на сентябрь 2026 года лидер набирает 91,9%. τ²-bench проверяет, как агент ведёт многошаговый диалог с пользователем и вызывает инструменты в правильном порядке.

Почему агентные бенчмарки информативнее классических? Потому что реальная задача редко сводится к «напиши функцию». Обычно нужно разобраться в контексте, выбрать инструмент, проверить результат и повторить, если не сработало. HumanEval такое не проверяет. Terminal-Bench и τ²-bench — проверяют.

Мультимодальность

MMMU-Pro — это вопросы по изображениям, диаграммам и графикам. Лидеры набирают 83–84%. CharXiv проверяет понимание научных графиков из статей arXiv. Здесь есть известная проблема: часть вопросов можно решить без картинки, просто по тексту. Это не обесценивает бенчмарк целиком, но снижает его точность.

Русский язык

MERA — открытый бенчмарк для оценки русскоязычных моделей. 21 задача на reasoning, генерацию кода и знание языка. Смысл в том, что англоязычные бенчмарки не проверяют, как модель работает с русским текстом. 

MMLU написан на английском. Если ваш продукт обрабатывает русскоязычные обращения, MMLU вам ничего не скажет о качестве работы с ними. MERA закрывает этот сценарий.

Что искажает результаты

Высокий балл на бенчмарке можно получить несколькими способами. Только один из них — реальное умение. Остальные — системные искажения, которые нужно уметь распознавать.

Тест попал в обучающую выборку

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

В HumanEval 164 задачи на Python. Код из этих задач разбросан по GitHub, а GitHub — основной источник данных для обучения. Исследование 2025 года подтвердило, что задачи HumanEval массово присутствуют в обучающих корпусах моделей.

Со SWE-bench Verified ситуация ещё серьёзнее. Задачи собраны из публичных репозиториев, и соответствующие патчи попали в обучающие данные. Симптом виден со стороны: модель лидирует на публичном наборе, но показывает заметно худший результат на закрытом аналоге. 

Бенчмарк насыщен

Когда все фронтирные модели кластеризуются в узкой полосе, бенчмарк перестаёт различать их. GPQA Diamond — пример. Полоса шириной 1,4 процентных пункта на уровне 90–95% означает, что разница между первым и пятым местом лежит в пределах погрешности.

Ориентир по сроку жизни бенчмарка: медианная различающая способность держится меньше двух лет. MMLU перестал различать топовые модели примерно через год после выхода. HumanEval — тоже. GPQA Diamond доживает последние месяцы. ARC-AGI-2 пока держится, потому что задачи принципиально другие.

Под лидерборд готовятся отдельно

В апреле 2025 года вышла работа The Leaderboard Illusion. Авторы — исследователи из Cohere Labs, Стэнфорда, Принстона и Университета Уотерлу — разобрали, как вендоры адаптируют модели под публичные лидерборды.

Раскрыта схема: перед публикацией модель тестируют на приватных вариантах, выбирают лучший прогон, а иногда делают вендорский бенчмарк собственного производства, где модель гарантированно лидирует. Chatbot Arena (сейчас LMArena) тоже критикуют за то, что сотни согласованных голосов могут сдвинуть рейтинг.

Задачи сломаны

Часть задач в популярных наборах сформулирована так, что решить их корректно нельзя. Компания OpenAI провела аудит SWE-bench Verified в феврале 2026 года и обнаружила, что 59,4% задач имеют дефекты в тестах. Аудит SWE-bench Pro, проведённый позже, показал, что около 30% задач сломаны.

Самая частая проблема — тесты проверяют поведение, которого нет в условии. Модель делает то, что просили, но тест ожидает чего-то другого. Формально задача провалена. Фактически — модель права, а бенчмарк сломан.

Как читать лидерборд

Лидерборд — не истина в последней инстанции. Это один из инструментов. Разберем четыре пункта, которые стоит учесть прежде чем делать выводы.

Кто составляет рейтинг

Академический бенчмарк (ARC-AGI, SWE-bench) отвечает на вопрос «насколько модель хороша в задачах определённого типа». Краудсорсинговое сравнение вроде LMArena отвечает на вопрос «какая модель нравится людям в слепом тесте». Вендорский рейтинг отвечает на вопрос «какую модель продвигает вендор». 

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

Насколько велик разброс

Разница в полтора процентных пункта между первым и третьим местом обычно лежит в пределах погрешности. Обращайте внимание на доверительный интервал и число прогонов. Если модель прогнали один раз, а конкурента — десять, цифры несопоставимы.

В каких условиях получен результат

Настройки прогона сдвигают цифру не меньше, чем сама модель.

Pass@1 и pass@10 — разные метрики. Первая считает задачи, решённые с первой попытки, вторая — хотя бы с одной из десяти. Если у одной модели указан pass@10, а у другой pass@1, сравнивать их нельзя.

Температура тоже влияет на результат. При нуле модель отвечает одинаково, при 0.7 начинает варьировать. Доступ к инструментам меняет расклад сильнее: в SWE-bench прогон с песочницей и интерпретатором даёт разницу в десятки процентных пунктов.

Версия модели — ещё один фактор. «GPT-4o» в марте и «GPT-4o» в сентябре — разные веса. Без даты или идентификатора снапшота цифра относится к чему-то неопределённому.

Вывод: открывайте детали прогона. Если нет параметров — цифра остаётся ориентиром, а не фактом.

Как перепроверить

Ответ — триангуляция: сходятся ли результаты трёх разнотипных источников. Если модель лидирует только в вендорском рейтинге, а в академическом бенчмарке и LMArena — в середине, вывод очевиден. Если результаты сходятся везде, это сигнал.

Гипотетический мини-разбор строки лидерборда:

Model X — 87.3% на MMLU-Pro, 92.1% на GPQA Diamond, 78.4% на SWE-bench Pro

MMLU-Pro 87,3% — выше среднего, но не лидер. GPQA Diamond 92,1% — в топ-5, но полоса насыщения широкая. SWE-bench Pro 78,4% — сильно выше среднего, бенчмарк рабочий. Вывод: модель сильна в коде и неплоха в рассуждениях. Для задачи генерации кода — кандидат. Для задачи поддержки на русском — нужен отдельный замер.

Как выбрать модель под задачу проекта

Бенчмарки говорят о модели в вакууме. Ваш проект — конкретные данные. Выбирать модели под себя — задача сложная. Таблица показывает, какой бенчмарк брать под свой тип задачи.

Тип задачи	Какие бенчмарки смотреть	На что ещё обратить внимание
Поддержка на своей базе знаний	MMLU-Pro, MERA (если русский)	Цена за токен, задержка ответа
Генерация кода	SWE-bench Pro, Terminal-Bench 2.0	Поддержка языка, размер контекста
Разбор документов	MMMU-Pro, CharXiv	Качество OCR, работа с таблицами
Агент с инструментами	τ²-bench, Terminal-Bench 2.0	Набор инструментов, лимиты шагов

Параметры, которых в бенчмарках нет вообще: цена за токен на реальных задачах, задержка ответа, лимиты контекста, возможность локального развёртывания, политика хранения данных. Модель с 90% на GPQA Diamond может оказаться бесполезной, если она стоит в десять раз дороже конкурента с 88%. 

Если вам нужно развернуть модель локально, — вопрос о бенчмарках вообще уходит на второй план.

Как собрать собственный eval-набор

Бенчмарк говорит, насколько модель хороша в среднем по задачам, которые придумали не вы. Ваш eval-набор скажет, насколько она хороша именно для вас. Разница в том, что вы проверяете модель на своих данных и своих сценариях. Без этого шага выбор модели превращается в ставку на удачу.

Откуда брать примеры

Реальные логи и обращения пользователей — лучший источник. Типовые документы, с которыми работает система. Сценарии, на которых предыдущая модель ошибалась. Синтетика допустима только для добалансировки редких классов и с пометкой о происхождении. 

Если пример сгенерирован, это должно быть видно. Синтетические кейсы слишком чистые: в них нет опечаток, обрывов мысли и странных формулировок, которые встречаются в живой переписке. В одном из руководств по golden dataset прямо сказано: копируйте из реальных логов, а не пишите примеры с нуля.

Сколько примеров нужно

Сотни, не десятки. На 20 примерах изменение качества неразличимо: разница в один правильный ответ даёт 5 процентных пунктов. Статистически значимый результат требует сотен точек.

Есть и практический ориентир по размеру набора. 20–30 случаев ловят только крупные регрессии — падение на 15 и более процентных пунктов. 50–100 случаев уверенно показывают падение на 7–8 пунктов. Для тонких изменений в пределах 5 пунктов нужно 200 и больше примеров.

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

Как разложить набор

Три отдельных набора решают разные задачи:

Пропорции внутри набора должны отражать реальное распределение трафика. Если 30% обращений — про биллинг, то и в наборе должно быть 30% таких случаев. Граничные случаи, которые сидят между двумя категориями, регрессируют чаще всего. Их стоит добавлять отдельно.

Как оценивать ответы

Рубрика с примерами хороших и плохих ответов из вашего домена работает лучше шкалы «от одного до пяти». В рубрике вы описываете, что именно делает ответ хорошим: полнота, точность, тон, отсутствие выдумок. Для каждого пункта — пример, который засчитывается, и пример, который нет. 

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

Чего опасаться с LLM-судьёй

Self-bias: модель склонна оценивать свои ответы выше, чем ответы конкурентов. Дрейф после обновления API: та же модель с тем же промптом может начать оценивать иначе. Отсутствие калибровки: без человеческой разметки вы не знаете, насколько оценки судьи соответствуют реальности.

Исследование команды разработчиков на 14 моделях показало масштаб проблемы. Судьи правильно определяли корректные ответы в более чем 96% случаев, но пропускали некорректные и выдуманные ответы в 75%. Доля верных опознаний среди плохих ответов — ниже 25%.

Иными словами, судья почти всегда соглашается, что ответ выглядит нормально, даже когда он ошибочен. В реальных данных доля плохих ответов невелика, поэтому высокая общая точность маскирует эту слепоту. 

Один из способов исправить положение — калибровка на человеческой разметке. Регрессионная поправка на смещение судьи, обученная всего на пяти размеченных датасетах, снижает максимальную абсолютную ошибку до 1,2%. Без такой калибровки оценки судьи остаются ориентиром, а не фактом.

Что фиксировать, чтобы результат повторился

Прогнали модель, получили 87% на своём eval-наборе. Через неделю запускаете тот же набор — цифра другая. Модель та же, задачи те же, а результат уплыл. Знакомая ситуация, и причина почти всегда одна: часть параметров прогона не зафиксировали.

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

Параметр	Почему без него результат уплывёт
Версия модели	Обновление API меняет веса и поведение. «GPT-4o» в марте и «GPT-4o» в сентябре — разные модели
Промпты и few-shot примеры	Другая формулировка инструкции или другой набор примеров — другие ответы
Версия датасета	Датасет может обновиться: задачи добавят, удалят или исправят
Версия harness	Разный парсер вывода даёт разные баллы на одном и том же ответе
Температура и top-p	Влияют на вариативность: при нуле ответ детерминирован, при высоких значениях меняется от прогона к прогону
Random seed	Без фиксации зерна генератор случайных чисел выдаёт новую последовательность
Инфраструктура инференса	Разное железо и разные библиотеки иногда дают разное поведение на границе точности
Сырые логи	Без них не разберётесь, что пошло не так, если цифра разошлась

Если модель работает как агент — вызывает инструменты, выполняет цепочку шагов, — список параметров расширяется. Записывайте конфигурацию окружения, в котором работает агент: набор доступных инструментов, их версии и лимит шагов. Инструмент, обновивший формат вывода, ломает поведение агента там, где раньше всё работало. Агент с лимитом в 10 шагов и агент с лимитом в 20 показывают разные результаты на одной задаче.

Отдельно храните трассировки — полный лог того, что агент делал на каждом шаге. Финальный ответ показывает только результат. Причина ошибки обычно спрятана в середине цепочки: неверный вызов инструмента, пропущенный шаг, лишний повтор. Без трассировок вы видите, что агент провалился, но не понимаете, где именно.

Совет. Заведите протокол замера — таблицу или файл, куда перед каждым прогоном записываете все параметры из списка. Прогоняете модель — сохраняете протокол рядом с результатами. Через месяц, когда цифра разойдётся, у вас будет с чем сравнить. Без протокола вы будете гадать, что изменилось: модель, промпт, датасет или что-то ещё.

Вопросы, которые задают чаще всего

Какой бенчмарк LLM самый точный? 

Ни один. Каждый отвечает за свой аспект. GPQA Diamond — знания, SWE-bench Pro — код, ARC-AGI-2 — абстрактное мышление. Точность зависит от того, что вы измеряете и для какой задачи.

Можно ли верить LMArena? 

Как индикатору человеческих предпочтений — да, но с оговорками. Как единственному источнику — нет. Краудсорсинговые рейтинги уязвимы к скоординированному голосованию и отражают то, что нравится людям, а не то, что нужно вашему продукту.

Что значит «модель насытила бенчмарк»? 

Она набрала столько, что дальнейший рост невозможен или бессмыслен. Бенчмарк перестаёт различать её от конкурентов. GPQA Diamond насыщен: разница между топ-моделями — 1,4 процентных пункта.

Зачем нужен MERA, если есть MMLU? 

MMLU написан на английском. MERA проверяет, как модель работает с русским текстом: reasoning, генерацию кода, знание языка. Если продукт обрабатывает русскоязычные запросы, MMLU не покажет проблем.

Проверка модели на своих данных занимает несколько часов. Разметить полсотни примеров, прогнать двух-трёх кандидатов, сравнить ответы — столько же времени уходит на одно совещание по выбору, после которого команда возвращается к тому же вопросу.

Лидерборд подскажет, с каких моделей начать. Дальше всё решают ваши логи и ваши задачи. Начните с них — и вопрос «переезжать или нет» закроется в тот же день.

Советуем дальше почитать

ИИ-навыки разработчика: 10 требований для 2026 — какие навыки работы с моделями и агентами спрашивают у разработчиков и что из этого проверяется на практике.

Профессии в сфере нейросетей: должности и зарплаты 2026 — кто в команде размечает данные и проверяет ответы моделей: AI-тренер, ML-инженер, Data Scientist.

Как стать ML-инженером в 2026: роадмап от Python до оффера — семь этапов, метрики классификации и ветка про трансформеры, дообучение и RAG; обновлён в июле 2026.

Открытые веса: какие модели запустить бесплатно — что означает «открытые веса», какие модели можно запустить у себя и чем это отличается от API.

ИИкономика: токены, GPU и бигтех — кто реально контролирует ИИ — откуда берётся цена модели и почему цифры из бенчмарка не равны стоимости в продакшене.