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

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

Сверено с сайтами авторов бенчмарков и карточкой модели Google 15 октября 2026 года. Ниже мы объясняем, как устроены тесты, а в разборе результатов используем опубликованные данные Google. Интерпретация и рекомендации по оценке — наши.

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

Что измеряют бенчмарки LLM

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

Датасет содержит вопросы или задачи. Протокол оценки задаёт, что получает модель, какая помощь ей доступна и как проверяется результат. Тестовая обвязка, или harness, также называемая scaffold, — это программное окружение модели: промпты, инструменты и цикл выполнения действий.

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

В таблице лидеров SWE-bench это различие видно по отдельным условиям оценки, в том числе по общей среде mini-SWE-agent. В вашем продукте для программирования могут быть другие инструменты, инструкции и ограничения. Прежде чем переносить результат на свой рабочий процесс, выясните, какое окружение использовалось при тестировании модели.

Какие бенчмарки встречаются в анонсах моделей

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

Указывайте версию вместе с названием. HLE-Diamond содержит 1,000 доработанных вопросов, а финальная версия исходного HLE — 2,500. В Terminal-Bench 4.0 изменились ресурсы и задачи. Актуальный репозиторий tau описывает и новые модальности, и исправления в оценивании. Разница между свежим и старым результатом может означать, что изменился экзамен, а не стала лучше модель.

Какие результаты важны для вашей работы?

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

Бенчмарки агентов для программирования

Разработчику, который поддерживает существующий продукт, стоит начать с исправлений в репозитории и работы в терминале. SWE-bench даёт полезные сведения о решении задач в кодовой базе, Terminal-Bench — о выполнении работы в командной оболочке. LiveCodeBench и HumanEval отвечают на более узкие вопросы о программировании. Ни один из этих тестов сам по себе не показывает, насколько удобно будет сопровождать предложенные изменения в вашем проекте.

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

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

Бенчмарки рассуждений LLM

GPQA, HLE, MMLU-Pro, AIME и ARC-AGI проверяют разные виды рассуждений. Они помогают понять, что стоит изучить подробнее, особенно если задача требует решения сложных научных или математических проблем. Но они мало говорят о том, соблюдает ли система ваши рабочие правила.

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

В случае Humanity's Last Exam не путайте амбициозное название с тем, что действительно измеряется. Авторы прямо отделяют результаты на академических задачах с проверяемым ответом от самостоятельных исследований. Умение ответить на сложный вопрос с известным решением не доказывает, что система способна выбрать достойную исследования проблему, собрать надёжные свидетельства и распознать собственную ошибку.

Для длинного контекста и речи нужны отдельные проверки

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

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

При оценке голоса разделяйте распознавание речи, рассуждения, произнесение ответа и управление разговором. FLEURS полезен для оценки транскрибации, Big Bench Audio — для рассуждений по устным вопросам, VoiceBench охватывает задачи с устными инструкциями. Актуальное семейство tau также оценивает голосовые взаимодействия. Это разные измерения.

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

Оценка LLM для внедрения

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

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

Как за пять минут разобраться в таблице из анонса

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

1. 1

   Минута 1: определите свою задачу

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

2. 2

   Минута 2: уточните, какой именно тест проводился

   Зафиксируйте версию бенчмарка, поднабор, язык и период выхода задач. Обратите внимание на уточнения вроде Diamond, Verified, офлайн, только текст или с инструментами. Если подпись неполная, загляните на сайт самого бенчмарка.

3. 3

   Минута 3: изучите условия

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

4. 4

   Минута 4: разберитесь в метрике

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

5. 5

   Минута 5: выясните, кто получил результат

   Установите, кто запускал тест: разработчик модели, организатор бенчмарка или другой оценщик. Прочитайте сноску к конкретной строке — не предполагайте, что вся таблица получена по одной процедуре. Сохраните источник и настройки, затем выберите кандидата для собственных тестов.

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

Разбираем пример: таблица Google для Gemini 4 Argon

Gemini 4 Argon, универсальная ИИ-модель Google, удобна для разбора: в её таблице соседствуют разные семейства задач и способы подсчёта баллов. Строки ниже воспроизводят результаты Google из октябрьской карточки модели, проверенные 15 октября 2026 года. Это данные указанного источника, а не измерения, проведённые для этой статьи.

Читайте название строки и примечания вместе с каждым значением. У этих процентов нет ни общего знаменателя, ни единого смысла.

BFS — это поиск в ширину: обход связей графа по уровням глубины. Токены — единицы измерения контекста модели; они не равны словам.

Прочитайте сноски, прежде чем делать выводы

Согласно методике оценки Google, для Argon обычно используются максимальный уровень рассуждений и pass@1, но есть исключения. Результат DeepSWE получен с обвязкой mini-swe. Результат Terminal-Bench Google рассчитала сама, а значения для сравнения взяла из официальной таблицы лидеров. Результаты GraphWalks для всех моделей также рассчитаны самой Google. Для OSWorld берётся максимум из трёх прогонов и указывается офлайн-оценка с учётом частичного выполнения.

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

Наш расчёт: 99.7 минус 84.2 — это разница в 15.5 процентного пункта между опубликованными результатами GraphWalks по F1. В строках используются разные поднаборы по длине, поэтому такое вычитание не позволяет выделить причинное влияние длины на одних и тех же вопросах. Но оно показывает, почему цитировать только строку с более коротким контекстом — значит упускать важные данные для работы с длинными документами.

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

Если нужен контекст для внедрения конкретной модели, прочитайте разбор Gemini 4 Argon и отдельное сравнение Gemini 4 Argon с Opus 5.5.

Почему высокий балл может ввести в заблуждение

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

Попадание тестовых данных в обучение и подгонка под тест

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

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

Для собственной оценки держите отложенный набор, который не используется при настройке промптов. Когда неудачный пример становится материалом для доработки системы, пополняйте отложенный набор новыми случаями. Иначе система может отлично решать знакомые примеры и оставаться хрупкой во всём остальном.

Как обвязка влияет на сравнение нейросетей

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

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

Результат разработчика полезен, но это ещё не независимое воспроизведение

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

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

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

Даже хороший оценщик может проверять не тот результат

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

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

Когда нужно проводить собственное тестирование языковых моделей

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

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

Для команды поддержки в компании среднего размера практический пилот можно начать с 50 случаев: 20 типовых обращений, 10 исключений из правил, 10 случаев с недостающими или противоречивыми входными данными и 10 ситуаций, связанных с правами доступа или эскалацией. Это пример состава проверки, а не утверждение, что такой выборки статистически достаточно для внедрения. Итоговый размер подбирайте с учётом частоты ошибок и различий, которые нужно обнаружить.

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

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

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

Для фактов, которые можно проверить напрямую, например выбранного аккаунта или запрещённого действия, используйте детерминированные проверки. Для качеств, требующих суждения, — например полноты и обоснованности объяснения, — задайте критерии и откалибруйте оценку по человеческой разметке. В руководстве по LLM-as-a-judge разобраны этот уровень оценивания и его типичные сбои.

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

Вопросы о таблицах результатов бенчмарков

Какие бенчмарки LLM встречаются чаще всего?

Сначала научитесь различать семейства: SWE-bench и Terminal-Bench — для агентов программирования, GPQA и Humanity's Last Exam — для академических вопросов, семейство tau — для использования инструментов в диалоге, отдельные тесты — для длинного контекста и речи. Указывайте версию и настройки вместе с каждым результатом.

Какой бенчмарк LLM лучше подходит для программирования?

Берите тест, наиболее близкий к вашей задаче. SWE-bench проверяет решение задач в репозитории, Terminal-Bench — работу в терминале, HumanEval — генерацию функций, LiveCodeBench включает олимпиадные задачи с датами публикации. Применимы ли эти результаты к вашей работе, покажут изменения в собственном репозитории.

Что такое датасет для бенчмарка LLM?

Датасет содержит вопросы или задачи. Чтобы результаты бенчмарка можно было сопоставлять, нужен и протокол: промпты, инструменты, ограничения, попытки и способ подсчёта баллов. Одного совпадения названия датасета недостаточно, чтобы считать два результата сравнимыми.

Чтобы получать практические рекомендации по оценке и внедрению ИИ, подпишитесь на рассылку.