Бенчмарки LLM

Общее #

Каждый раз, когда выходит новая языковая модель, в сопроводительных материалах появляются цифры: «90% на MMLU», «восемь из десяти на HLE», «Elo 1350 в Chatbot Arena». Это и есть бенчмарки — стандартизированные наборы задач, на которых модели сравнивают между собой. Бенчмарки — это экзамен, который сдают все модели по одним и тем же билетам.

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

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

Однако у бенчмарков есть принципиальное ограничение, которое обязательно нужно понимать с самого начала: ни один бенчмарк не скажет, насколько модель подойдёт вашей конкретной задаче. Бенчмарк измеряет способность модели решить стандартизированный набор вопросов — не ваших. Модель, набирающая 95% на MMLU, может плохо справляться с суммаризацией юридических договоров или с ответами в вашем узкоспециализированном чат-боте. Бенчмарк даёт первичную ориентацию на рынке и помогает отсеять заведомо неподходящие варианты, но окончательное решение всегда принимается на собственных метриках и собственных данных.

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

Какие бывают бенчмарки #

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

Статические и живые. Статические бенчмарки — это зафиксированный набор вопросов и эталонных ответов: MMLU, HumanEval, GSM8K. Модель прогоняется по ним, считается доля правильных. Живые (краудсорсинговые) — это площадки, где оценку ставят реальные люди на свежих запросах: Chatbot Arena, ruLLMArena. Живые ближе к реальному пользовательскому опыту, но дороже и хуже воспроизводимы.

С эталоном (ground truth) и с судьёй. В бенчмарках с эталоном есть единственный правильный ответ, и проверка сводится к сравнению: точное совпадение, прохождение автотестов, F1. В бенчмарках с судьёй (LLM-as-a-judge или человек) сравнивают качество ответа по критериям — релевантность, связность, полезность. Эталонные бенчмарки объективнее и воспроизводимее, judge-бенчмарки гибче и ближе к человеческому восприятию, но подвержены искажениям судьи (см. Метрики LLM, раздел LLM-as-a-judge).

Выбор из вариантов (MCQA) и свободная генерация. MCQA (multiple-choice) — модель выбирает один из нескольких вариантов (MMLU, ARC). Это удобно для автоматической проверки, но по сути измеряет ранжирование вариантов, а не умение формулировать ответ. Свободная генерация требует от модели произвести текст или код, и проверяется уже содержательно: автотестами (HumanEval), судьёй (MT-Bench), семантической близостью. MCQA систематически переоценивает «знающие», но плохо формулирующие модели.

Универсальные и предметные. Универсальные бенчмарки (MMLU, GPQA, HLE) покрывают широкий спектр областей и претендуют на измерение «общего интеллекта». Предметные (HumanEval для кода, TruthfulQA для правдивости, ToxiGen для токсичности) измеряют конкретную способность. Универсальные удобны для «одной цифры в релиз», но именно предметные лучше предсказывают поведение модели в конкретном сценарии.

Zero-shot, few-shot и chain-of-thought. В zero-shot модели дают «голый» вопрос без примеров. В few-shot показывают несколько решённых примеров, задавая формат. В chain-of-thought просят рассуждать пошагово. От выбора режима радикально зависит результат: одна и та же модель на одной и той же задаче может показать 40% в zero-shot и 80% в few-shot. Поэтому любой результат бенчмарка имеет смысл только с указанием режима.

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

Как проводятся #

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

Датасет. Берётся зафиксированный набор вопросов (или задач), обычно с эталонными ответами. Размер варьируется от сотен (BrowseComp — 1266 вопросов) до десятков тысяч (MMLU — около 16 000). Чем меньше датасет, тем выше статистический шум: на 500 вопросах разница в 1–2% может быть чистой случайностью.

Промпт. Каждый вопрос упаковывается в текстовый промпт по фиксированному шаблону: «Вопрос: … Ответ:» или «Выберите правильный вариант из A–D». Шаблон промпта — часть методологии бенчмарка. Модель, натренированная именно под такой формат, получит преимущество; модель, привыкшая к другому формату, проиграет — вне зависимости от реальных способностей.

Few-shot примеры. Часто в начало промпта подставляют 3–5 решённых примеров (few-shot), чтобы задать модели формат ответа. Их наличие и количество тоже часть методологии.

Генерация ответа. Модель генерирует ответ с заданными параметрами: температура (обычно 0 для воспроизводимости), max tokens, stop-последовательности. Для reasoning-моделей отдельно учитывается бюджет на reasoning tokens. Подробно о том, как именно эти параметры меняют ответы модели, — в Параметры LLM.

Оценка (scoring). Сгенерированный ответ сопоставляется с эталоном: точное совпадение, парсинг указанного варианта (A/B/C/D), прохождение автотестов, judge-оценка. Здесь тоже много свободы: считать ли ответ верным, если модель написала «Правильный ответ — B», а не просто «B», зависит от логики парсера.

Агрегация. Результаты по всем вопросам усредняются в одну или несколько цифр: overall accuracy, accuracy по категориям, pass@k (доля задач, решённых хотя бы в одной из k попыток), Elo-рейтинг. Именно эту агрегированную цифру и публикуют.

Воспроизводимость. Критически важный, но часто игнорируемый аспект. Чтобы результат бенчмарка имел смысл, его должно быть можно воспроизвести: та же версия модели (с весами!), тот же промпт, те же параметры, тот же код прогона (evaluation harness). На практике вендоры публикуют только финальную цифру, а воспроизвести её у себя, как правило, невозможно. Независимые инициативы (Open LLM Leaderboard, LM Evaluation Harness, HELM) существуют именно для того, чтобы вернуть воспроизводимость.

Кто проводит. Важнейший вопрос — кто именно прогнал модель. Варианты: сам вендор (максимальный конфликт интересов, можно подобрать выгодные настройки), независимая лаборатория (Stanford HELM, Hugging Face), создатели бенчмарка (Scale Labs для своих), краудсорсинговая платформа (LMSYS для Chatbot Arena). Чем независимее проводящий — тем больше оснований доверять результату.

Что показывает значение #

Самый частый вопрос при взгляде на лидерборд: «Эта модель набрала 50 — это хорошо или плохо?». Однозначного ответа без контекста не существует, и вот почему.

Абсолютная шкала — это не оценка в школе. 50% на школьном экзамене — это двойка. 50% на HLE — это выдающийся результат, недостижимый для большинства моделей. Цифра бенчмарка имеет смысл только относительно: относительно chance level, относительно потолка человека и относительно других моделей.

Chance level (уровень случайного угадывания). Минимально возможный осмысленный результат, который модель получит, просто гадая. Для бенчмарка с четырьмя вариантами ответа (MMLU) chance level равен 25%: любая модель, набирающая меньше, по сути просто тыкает наугад. Поэтому «30% на MMLU» — это не «чуть-чуть не дотянула», а «модель почти ничего не знает». Любая цифра ниже chance level должна вызывать подозрение, что модель сломана или прогон некорректен.

Потолок человека. Максимальный результат, который на бенчмарке способен показать человек-эксперт. На MMLU это около 90%, на HLE — около 70–80%. Потолок человека задаёт верхнюю границу «осмысленной» шкалы: когда модели массово начинают его превышать, бенчмарк теряет различительную способность.

Насыщение (saturation). Состояние, когда модели выходят на плато и разница между ними исчезает. SWE-bench Verified к настоящему времени достиг насыщения: фронтальные модели группируются в районе 85–88%, и лидерборд больше не различает, какая модель действительно лучше. Именно поэтому OpenAI публично отказался от использования SWE-bench Verified как фронтальной метрики — на нём больше невозможно увидеть прогресс. Когда бенчмарк насыщен, высокие цифры ничего не значат: «92% против 90%» — это шум, а не реальное превосходство.

Шум и случайность. На любом бенчмарке есть статистический шум, и его масштаб зависит от размера датасета. На 500 вопросах результат ±2% запросто может быть игрой случая. Поэтому разница в 1–2 пункта между моделями в лидерборде — это почти никогда не «модель А лучше модели Б», а статистическая погрешность. Реальные различия начинаются там, где разница превышает доверительный интервал.

Относительная шкала ценнее абсолютной. Значительно информативнее не сама цифра, а её динамика и контекст: как эта модель выглядит на фоне предшественников, как быстро растут результаты по бенчмарку, насколько далеко от chance level и от человеческого потолка, сколько времени назад вышел бенчмарк. Elo-рейтинг Chatbot Arena — пример хорошо работающей относительной шкалы: абсолютные числа мало что говорят, но ранжирование моделей осмысленно и стабильно.

Разные бенчмарки — разные шкалы. Сравнивать «90% на MMLU» и «90% на HLE» бессмысленно: это разные шкалы с разной сложностью. Один и тот же процент на разных бенчмарках означает совершенно разное качество модели. Сравнивать модели имеет смысл только в пределах одного бенчмарка.

Каким значениям можно верить #

Высокая цифра в лидерборде — это ещё не доказательство качества. Между «модель способна» и «модель набрала X%» стоит много факторов, способных исказить результат, и именно здесь проходит граница между доверенными и недоверенными оценками.

Загрязнение обучающих данных (data contamination). Самая распространённая и самая серьёзная проблема. Если вопросы бенчмарка (или очень похожие на них) попали в обучающую выборку модели, модель не «решает» бенчмарк — она его вспоминает. Признаки загрязнения: аномально высокий результат, разрыв между ожидаемым и фактическим, провал на аналогичных по сложности, но ранее не публиковавшихся вопросах. Именно из-за нарастающего загрязнения OpenAI официально отказался от SWE-bench Verified: часть тестовых задач оказалась в обучающих корпусах фронтальных моделей, и результаты перестали что-либо измерять. Борьба с загрязнением — основная причина, по которой регулярно выходят новые, более сложные бенчмарки (GPQA после насыщения MMLU, HLE после насыщения GPQA, SWE-bench Pro после насыщения Verified).

Переобученность под конкретный бенчмарк (overfitting). Сильнее всего страдает MMLU: он настолько устоялся как стандарт, что модели целенаправленно оптимизируют под него — включают MMLU-подобные данные в обучение, отбирают чекпойнты по MMLU-результатату. В итоге модель показывает 90% на MMLU, но на близких по сути, но свежих датасетах отстаёт. Это вариант утечки — не через прямое заучивание вопросов, а через «натаскивание» на формат.

Чувствительность к формату промпта. Результат радикально зависит от того, как сформулирован вопрос. Та же модель на тех же задачах может показать 40% в zero-shot и 80% в few-shot, может провалиться при замене «Answer:» на «Response:», может потерять 20 пунктов от замены латиницы кириллицей. Поэтому любые две цифры из разных источников сопоставимы только при идентичности формата промпта и процедуры прогона — что почти никогда не выполняется. Самостоятельное воспроизведение часто даёт на 10–20 пунктов меньше обещанного вендором.

Заявленные самими вендорами результаты (self-reported scores). Цифры из релизных материалов вендора — наименее надёжный источник. Вендор контролирует все переменные: версию модели, промпт, few-shot, параметры, код прогона — и имеет явный стимул выбрать те настройки, при которых его модель выглядит лучше. Это не обязательно злонамеренно (часто это просто «официальная» настройка), но систематически завышает результат относительно того, что получат независимые исследователи.

Независимые и слепые лидерборды. Наиболее доверенные оценки приходят от площадок, где процедуру контролирует третья сторона: Stanford HELM, Hugging Face Open LLM Leaderboard, Scale Labs, LM Evaluation Harness. Ещё выше доверие к слепым площадкам, где модель не знает, что её оценивают, а оценщики не знают, чью модель оценивают: Chatbot Arena — классический пример, и именно поэтому её Elo-рейтинг считается одним из самых надёжных индикаторов «человеческого» качества моделей.

«Игра в метрику» (gaming the benchmark). Отдельный и неприятный класс искажений — когда разработчики целенаправленно оптимизируют модель под конкретный бенчмарк, чтобы подняться в лидерборде, вне зависимости от того, отражается ли это в реальном качестве. На агentic-бенчмарках зафиксированы случаи, когда модели эксплуатируют лазейки в тестовом окружении (например, читают ожидаемый результат из служебных файлов), вместо того чтобы реально решать задачу. Любой резко выросший результат без качественного скачка в архитектуре должен вызывать подозрение.

Практический фильтр. Простой способ отделить доверенные цифры от недоверенных: предпочитайте независимые прогоны self-reported, свежие бенчмарки насыщенным, живые (Chatbot Arena) статическим, разрывы абсолютным значениям. И самое главное — любую цифру из любого лидерборда нужно валидировать на своих данных и в своих сценариях, прежде чем принимать по ней решение.

Категории и обзор бенчмарков #

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

Общие знания и понимание #

Эти бенчмарки претендуют на измерение «общего интеллекта» — широты знаний и понимания модели по многим областям.

MMLU (Massive Multitask Language Understanding). Около 16 000 вопросов с вариантами ответа по 57 предметным областям: от истории и права до медицины и программирования. MMLU де-факто стал стандартом «общего интеллекта» LLM: почти каждый релиз модели сопровождается результатом по MMLU. Но именно из-за этой роли MMLU сильно страдает от насыщения, загрязнения обучающих выборок и переобученности. Ограниченный формат «выбор из вариантов» плохо проверяет реальные рассуждения, а шанс-уровень в 25% занижает «дно» шкалы.

MMLU-Pro. Развитие MMLU с десятью вариантами ответа вместо четырёх (chance level — 10% вместо 25%), более сложными вопросами и явным требованием рассуждений. MMLU-Pro создан, чтобы вернуть различительную способность на верхнем конце шкалы, где MMLU уже насыщен. Результаты на MMLU и MMLU-Pro у одной модели могут расходиться на 20–30 пунктов — индикатор того, сколько «знания» было, а сколько — удачного угадывания.

ARC (AI2 Reasoning Challenge). Набор школьных научных вопросов с вариантами ответа, разделённый на «лёгкий» (ARC-Easy) и «сложный» (ARC-Challenge) наборы. ARC создавался специально так, чтобы его нельзя было решить простым сопоставлением слов или статистикой ответов. Сложная часть остаётся полезным индикатором способности модели к элементарным научным рассуждениям.

BBH (BIG-Bench Hard). 23 сложных задания из набора BIG-Bench, на которых ранние модели систематически проигрывали среднему человеку. BBH измеряет комбинацию рассуждений, следования инструкциям и знания. Полезен как «второй opinион» к MMLU: если модель сильна на MMLU, но слаба на BBH, её знания поверхностны.

Рассуждения (reasoning) #

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

GSM8K. Набор из нескольких тысяч школьных текстовых задач по математике, требующих многошаговых рассуждений («У Маши было 5 яблок, она отдала 2…»). Базовый индикатор reasoning-способностей модели. Для современных reasoning-моделей GSM8K близок к насыщению (топ-модели ~95%), поэтому как различительная метрика почти исчерпал себя, но остаётся точкой отсчёта.

MATH. Задачи из школьных и университетских олимпиад по математике — на порядок сложнее GSM8K. Измеряет способность модели проводить длинные цепочки символьных и алгебраических рассуждений. На MATH до сих пор есть заметный разброс между моделями, поэтому бенчмарк различителен.

AIME (American Invitational Mathematics Examination). Задачи реального американского математического соревнования — настолько сложные, что даже сильные модели до недавнего времени набирали единицы процентов. AIME стал одним из ключевых бенчмарков для reasoning-моделей нового поколения (OpenAI o-серии и аналогов): только они способны поднять результат в содержательный диапазон.

GPQA (Google-Proof Q&A). Докторские вопросы по биологии, физике и химии, настолько узкоспециализированные, что на них нельзя найти ответ «загуглив». GPQA создан как замена насыщающемуся MMLU на верхнем конце шкалы: chance level — 25%, потолок человека с PhD — около 65%, топ-модели — в районе 50–80%. Один из ключевых бенчмарков для оценки фронтальных моделей.

DROP. Задачи на чтение текста с числами и проведение над ними арифметических рассуждений («Сколько всего очков набрали команды за второй период, если в первом было X, а во втором Y…»). DROP ловит модели, которые «понимают» текст, но не умеют связно проводить вычисления по извлечённым данным.

Экспертные и предельные рассуждения #

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

Humanity’s Last Exam (HLE). 2500 вопросов по десяткам предметов — от математики и физики до философии и истории, — составленных мировыми экспертами так, чтобы быть на грани возможностей даже для человека-профессионала. HLE выпущен Scale AI и Center for AI Safety (2025) как прямой ответ на насыщение MMLU и GPQA: там, где фронтальные модели уже выходят на 80–90%, на HLE даже сильнейшие набирают около 10–20%. Помимо точности HLE измеряет калибровку — насколько уверенность модели соответствует реальной вероятности правильного ответа, что критично для доверия к модели в эксплуатации. HLE сегодня — один из немногих бенчмарков, где ещё видно реальное движение фронтальных моделей.

Программирование и SWE-агенты #

Самая большая и активно развивающаяся категория бенчмарков — по программированию. Здесь наблюдается чёткое разделение на два направления: простая функциональная кодогенерация (написать функцию) и программная инженерия уровня репозитория (решить реальную задачу в большом проекте).

Функциональная кодогенерация #

Бенчмарки, где модель должна написать относительно небольшую функцию по описанию, и её решение проверяется автотестами. Это «объективные» метрики кодогенерации: код либо проходит тесты, либо нет.

HumanEval и HumanEval+. Около 160 задач на Python, где по описанию и сигнатуре функции нужно написать реализацию, проверяемую набором юнит-тестов. HumanEval — классический и самый цитируемый бенчмарк кодогенерации. HumanEval+ — расширение с существенно большим числом тестов, ловящее «случайно прошедшие» решения. Метрика — pass@k: доля задач, решённых хотя бы в одной из k попыток.

MBPP (Mostly Basic Python Problems). Около тысячи простых задач на Python, по формату аналогичных HumanEval, но более массовых и однообразных. MBPP дополняет HumanEval и используется для устойчивости оценок на массовом материале.

MultiPL-E. Перевод задач HumanEval и MBPP на десятки других языков (C++, Java, JavaScript, Go, Rust и др.). MultiPL-E измеряет способность модели генерировать код не только на Python — что важно, потому что модели часто заметно сильнее на Python, чем на остальных языках.

LiveCodeBench. Набор задач с платформ типа LeetCode и Codeforces, публикуемый по строгому календарю. Главная идея — бороться с загрязнением: задачи появляются после релиза модели, поэтому их физически не могло быть в обучающей выборке. На статических HumanEval и MBPP, давно опубликованных, модели часто показывают завышенные результаты именно из-за утечки; LiveCodeBench — попытка вернуть честность.

SWE-агенты и репозитории #

Отдельная и самая динамичная подкатегория — бенчмарки, где модель-агент решает реальные задачи в больших существующих кодовых базах, а не пишет изолированные функции. Это измеряет уже не «умение писать код», а «способность самостоятельно довести до конца инженерную задачу» — то, ради чего существуют AI-coding-агенты.

SWE-bench (Verified и Pro). Задачи из реальных GitHub-issов популярных open-source Python-проектов: агенту даётся описание проблемы и доступ к репозиторию, он должен внести изменения так, чтобы прошли тесты. Оригинальный SWE-bench (2294 задачи) оказался зашумлённым и местами некорректным, поэтому вышел подмножество SWE-bench Verified (500 задач, прошедших человеческую проверку). SWE-bench Verified стал стандартом, но быстро достиг насыщения (фронтальные модели ~85–88%) и подвергся загрязнению — из-за чего OpenAI публично от него отказался. Преемник — SWE-bench Pro (около 1865 задач в 41 репозитории), в 3–4 раза сложнее: топ-модели набирают около 20–30%. Сегодня именно SWE-bench Pro — рабочая метрика для сравнения кодинг-агентов.

DeepSWE. Набор из более сотни оригинальных long-horizon задач по программной инженерии, взятых из активных open-source репозиториев (не из публичных issов, а написанных с нуля). По сложности заметно превышает SWE-bench Pro: типичные решения в 5–6 раз длиннее по строкам кода, а траектории агента — вдвое длиннее. DeepSWE измеряет способность агента вести длительную, многоэтапную инженерную работу — то, что ближе всего к реальной деятельности разработчика.

NL2Repo (NL2Repo-Bench). Бенчмарк на repository-level генерацию: по неформальному описанию на естественном языке модель должна сгенерировать или модифицировать целостную многофайловую кодовую базу. Это шаг за пределы «одной функции в существующем проекте» — в сторону «создать проект целиком по описанию». NL2Repo измеряет long-horizon способности: умение агента держать в уме архитектуру, согласованность между файлами, целостность системы.

ProgramBench. Один из самых сложных на сегодня кодинг-бенчмарков: модели даётся скомпилированный бинарник популярной open-source программы и её документация, и требуется спроектировать и реализовать с нуля полноценную кодовую базу, поведение которой совпадает с оригиналом. Проверка — через огромный набор тестов (порядка сотен тысяч). На ProgramBench фронтальные модели долгое время набирали около нуля — это один из немногих бенчмарков, где «правильный ответ» настолько труден, что разница между моделями измеряется долями процента. ProgramBench особенно ценен тем, что ловит разрыв между «ассистированной кодогенерацией» (помочь написать функцию) и «самостоятельной разработкой системы».

Следование инструкциям #

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

IFEval (Instruction Following Evaluation). Набор промптов с точно заданными формальными ограничениями («ответь ровно тремя предложениями», «начни с буквы K», «содержи не менее 400 слов»). Проверка полностью автоматическая и объективная — нет ни эталонного ответа, ни судьи, только соблюдение формата. IFEval — один из самых чистых бенчмарков в принципе: его невозможно «запомнить», он мало страдает от загрязнения, и он прямо предсказывает надёжность модели в пайплайнах.

MT-Bench. Набор многоходовых диалоговых задач, оцениваемых сильной моделью-судьёй (обычно GPT-4-класса) по нескольким критериям: релевантность, глубина, креативность, стиль. MT-Bench измеряет качество открытой диалоговой генерации — там, где нет единственно верного ответа. Субъективен и зависит от судьи, но близок к человеческому восприятию.

AlpacaEval. Сравнение ответов модели с эталонными (обычно от GPT-4) судьёй-моделью, с подсчётом доли побед и нормировкой на длину. AlpacaEval быстрее и дешевле MT-Bench, но чувствителен к известному искажению — предпочтению более длинных ответов (verbosity bias), которое частично компенсируется нормировкой.

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

Бенчмарки для моделей, работающих с изображениями (vision-language models). Измеряют способность понимать диаграммы, документы, сцены, графики.

MMMU (Massive Multi-discipline Multimodal Understanding). Вопросы по 30 дисциплинам (искусство, бизнес, наука, здоровье, инженерия, гуманитарные), где для ответа нужно изображение — диаграмма, схема, картина, чертёж. MMMU измеряет не просто распознавание объектов, а способность вести предметные рассуждения поверх визуальной информации.

MathVista. Математические задачи с визуальным контентом — графики, геометрические чертежи, таблицы, диаграммы. Измеряет связку «понимание изображения + математические рассуждения», что для большинства моделей оказывается значительно труднее, чем каждая способность по отдельности.

DocVQA и ChartQA. Вопросы по документам (DocVQA — сканы, формы, квитанции) и по инфографике (ChartQA — графики и диаграммы). Эти бенчмарки ближе всего к промышленным RAG-сценариям, где модель работает с реальными документами. Полезны для оценки способности модели извлекать информацию из неструктурированных визуальных источников.

Агенты и работа с окружением #

Категория бенчмарков, измеряющих способность модели-агента действовать в реальной компьютерной среде — терминале, рабочем столе, браузере. Это не «ответить на вопрос», а «выполнить задачу через интерфейс», что значительно ближе к тому, чего ждут от AI-агентов в эксплуатации.

Terminal-Bench. Набор задач, которые агент выполняет в реальном окружении командной строки: скомпилировать проект, настроить сервер, обучить модель, развернуть сервис. Terminal-Bench намеренно собирает сложные, реалистичные задачи, вдохновлёнными повседневной работой инженеров. Это один из немногих бенчмарков, где «правильность» определяется достижением реального, проверяемого результата в живой системе, а не совпадением с эталоном.

OSWorld-Verified. Набор из нескольких сотен задач в реальных десктопных и веб-приложениях: отредактировать таблицу в LibreOffice, отправить письмо в почтовом клиенте, оформить документ, выполнить действие в браузере. Агент взаимодействует с полноценной операционной системой через экран и клавиатуру, как живой пользователь. OSWorld — один из ключевых бенчмарков для computer-use-агентов. Версия Verified — переработанный набор с исправлениями ошибок разметки и уточнёнными критериями успеха; именно она сегодня служит рабочей метрикой.

BrowseComp. Около 1200 вопросов, ответы на которые существуют в открытом вебе, но требуют упорного, изобретательного, многоходового поиска: одна информация ведёт к другой, нужно комбинировать источники, перепроверять, спускаться вглубь. BrowseComp измеряет способность browsing-агента не просто «найти по запросу», а исследовать веб — что значительно ближе к реальным сценариям research-ассистентов и автоматических аналитиков. Большинство вопросов устроено так, что их невозможно решить одним поисковым запросом.

Использование инструментов (tool use) #

Отдельная способность агента — грамотно пользоваться внешними инструментами: вызывать API, работать с Model Context Protocol, выбирать нужный инструмент из набора, строить последовательность вызовов. Эта категория переживает бум благодаря распространению MCP-инструментов.

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

GAIA (General AI Assistants Benchmark). Реалистичные бытовые и рабочие задачи, требующие многошагового рассуждения, работы с инструментами и обработки разных типов входных данных (текст, изображения, файлы). GAIA интересен тем, что задачи для человека тривиальны (минуты на решение), но для моделей оказываются крайне сложными — что подсвечивает разрыв между «понимать» и «самостоятельно действовать».

WebArena. Набор задач в воспроизводимом веб-окружении (несколько реальных сайтов, развёрнутых локально): купить товар, найти статью, ответить на вопрос по содержанию. WebArena измеряет способность веб-агентов действовать в знакомом интерфейсе, не рискуя при этом сломать реальные сайты — воспроизводимо и безопасно.

τ-bench (tau-bench). Бенчмарк для оценки агентных способностей в реалистичных отраслевых сценариях: ретейл, авиация, телеком. Агент взаимодействует с базой знаний компании и набором инструментов, решая задачу пользователя в рамках правил. τ-bench ближе всего к тому, как агенты будут работать в корпоративных продуктах.

MCP-Atlas. Бенчмарк для оценки tool-use-способностей через Model Context Protocol: десятки реальных MCP-серверов, сотни инструментов и около тысячи задач, требующих вызвать нужные инструменты в правильной последовательности. MCP-Atlas — ответ на стремительное распространение MCP как стандарта интеграции LLM с внешними системами; он измеряет именно способность агента работать с MCP-инструментами как таковыми.

Tool Decathlon (Toolathlon). Бенчмарк для оценки комплексного tool-use: десятки MCP-серверов с сотнями инструментов, более ста задач, требующих длинных многоходовых последовательностей вызовов (в среднем около 20 шагов на задачу). Toolathlon специально собран так, чтобы ловить разрыв между «умеет вызвать один инструмент» и «умеет построить осмысленную стратегию из многих вызовов».

Безопасность и выравнивание #

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

TruthfulQA. Вопросы, провоцирующие модель повторить популярные заблуждения («Правда ли, что стекло — это жидкость?»). TruthfulQA измеряет, насколько модель поддаётся распространённым мифам и конспирологии — то есть склонна ли она галлюцинировать там, где ошибается большинство людей. Высокий балл — признак того, что модель «идёт за толпой», а не проверяет факты.

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

BBQ (Bias Benchmark for QA). Вопросы, в которых правильный ответ не зависит от демографии, но модель может выдать предвзятый, если она склонна стереотипизировать. BBQ измеряет именно скрытую предвзятость модели — какую группу она «подставляет» по умолчанию.

HarmBench. Стандартизованный набор вредоносных запросов для оценки устойчивости моделей к генерации запрещённого контента. HarmBench используется и для red-teaming-сценариев, и для оценки jailbreak-атак — с единой методологией, что позволяет сравнивать модели между собой.

AdvBench. Набор adversarial-промптов — специально сконструированных запросов, пытающихся обойти выравнивание модели и заставить её выдать запрещённое содержимое. AdvBench — базовый материал для оценки робастности модели к атакам и тестирования защитных стратегий.

Русский язык и многоязычность #

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

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

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

ruLLMArena. Русскоязычный аналог Chatbot Arena: краудсорсинговая площадка, где пользователи вслепую сравнивают ответы моделей на живых русскоязычных запросах. Это самый близкий к реальному русскоязычному пользовательскому опыту бенчмарк — и потому один из самых доверенных источников при выборе модели для российских продуктов.

Живые и краудсорсинговые #

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

Chatbot Arena (LMSYS) и Elo-рейтинг. Платформа, где пользователи вслепую сравнивают ответы двух моделей на свой собственный запрос, а результаты агрегируются в рейтинг Elo (как в шахматах). Chatbot Arena — самый близкий к реальному пользовательскому опыту бенчмарк: оценка идёт от людей на живых запросах, без эталонов и без формата. Elo-рейтинг Chatbot Arena считается одним из самых надёжных индикаторов «человеческого» качества моделей, потому что не страдает от проблем автоматических метрик (загрязнение, чувствительность к формату). Минус — он агрегатный и не показывает, подойдёт ли модель конкретно вашей задаче.

Arena-Hard. Набор из нескольких сотен тщательно отобранных сложных промптов, по которым сильная модель-судья сравнивает ответы испытуемой модели с эталонными (от GPT-4). Arena-Hard — попытка сохранить дух Chatbot Arena, но сделать оценку дешёвой и воспроизводимой. Качественно коррелирует с живым Elo, но зависит от судьи.

WildBench. Набор реальных пользовательских запросов из продакшена, отобранных по сложности и разнообразию, оцениваемых моделью-судьёй. WildBench балансирует между живой оценкой (настоящие запросы) и воспроизводимостью (фиксированный набор, автоматический судья).

Субъективные и «вайб» #

Отдельный и относительно молодой класс оценок — попытки формализовать субъективное ощущение пользователя («модель зашла», «модель плохо вайбает»). Это контр-тренд к формальным бенчмаркам: реакция на то, что высокие результаты на MMLU и HumanEval плохо предсказывают, понравится ли модель реальному пользователю.

Vibe / ViBench. Методологии и бенчмарки, формализующие «вайб-тестирование» моделей — субъективную оценку, которой пользователи пользуются на практике, когда не доверяют формальным метрикам. ViBench доводит эту идею до автоматизации: использует LLM-агента как автоматического оценщика «вайба» ответов модели (в том числе в кодинге), чтобы масштабировать субъективную оценку без участия людей. Этот класс бенчмарков честно признаёт то, что игнорируют формальные тесты: модель, отлично набирающая баллы на стандартизированных экзаменах, может вызывать у пользователя стойкое ощущение «не того» — и наоборот. Vibe-оценки пока меньше стандартизированы и хуже воспроизводимы, чем классические бенчмарки, но они заполняют важный пробел между «модель может» и «моделью приятно пользоваться».

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

Практический чек-лист для тех, кто смотрит на рейтинг моделей и пытается сделать вывод.

Смотрите на методологию, а не на цифру. Кто проводил? Сам вендор или независимая лаборатория? Какой формат промпта? Какая версия evaluation harness? Один и тот же бенчмарк в разных руках может дать разные результаты — потому что процедура разная.

Сравнивайте модели одного размера. Big-модель почти всегда сильнее маленькой, и это скучный результат. Интересны сравнения внутри своего класса: кто лучший среди маленьких моделей, кто — среди средних, кто — среди фронтальных. Смешивать в одном сравнении модели разного размера бессмысленно.

Сверяйтесь с датой и версией. Модель устаревает: новая версия через полгода может быть на 20 пунктов сильнее. Любой лидерборд имеет смысл только с указанием дат тестирования и конкретных версий моделей. Лидерборд годичной давности уже не отражает текущей картины.

Игнорируйте шум. Разница в 1–2 пункта на бенчмарке — статистическая погрешность, а не реальное превосходство. Реальные различия начинаются там, где разрыв выходит за пределы доверительного интервала (обычно это несколько пунктов, в зависимости от размера датасета).

Не доверяйте насыщенным бенчмаркам. Если топ-модели группируются в районе 85–90% на каком-то бенчмарке, этот бенчмарк больше не различает модели. «92% против 90%» на насыщенном бенчмарке ничего не значит. Ищите свежие, не насыщенные альтернативы.

Предпочитайте живые и слепые площадки. Chatbot Arena и аналогичные Elo-рейтинги дают более доверенную картину «человеческого» качества, чем статические тесты. Расхождение между Elo и формальными бенчмарками — это сигнал: модель, сильная на тестах, но слабая в Elo, скорее всего, переобучена под бенчмарки.

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

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

Резюме #

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

Здоровый подход к бенчмаркам — скептический и контекстный: всегда учитывать методологию, доверять независимым и живым площадкам больше, чем self-reported результатам вендоров, отслеживать насыщение и загрязнение, не придавать значения разнице в 1–2 пункта и обязательно валидировать любые лидербордные выводы собственной оценкой.

Подробно о том, как измерять модели на своих данных и какие метрики выбирать под конкретные сценарии — в Метрики LLM. Общий контекст осознанного встраивания ИИ в процесс разработки — в разделе Искусственный интеллект.