Свой бенчмарк для выбора LLM: почему рейтинги моделей устаревают

бенчмарк для выбора LLM
как выбрать LLM для бизнеса
бенчмарки LLM
оценка языковых моделей
eval для LLM
насыщение бенчмарков
сравнение нейросетей
Свой бенчмарк для выбора LLM: почему рейтинги моделей устаревают

Свой бенчмарк для выбора LLM — это небольшой набор задач из реальной работы компании с заранее известными правильными ответами и правилами оценки, на котором сравнивают модели перед внедрением. Он нужен потому, что публичные рейтинги быстро перестают различать лучшие модели: по разбору 224 бенчмарков, опубликованному 13 октября 2026 года, половина тестов, вышедших с 2023 года, «умирает» примерно за 19 месяцев против 38 у более старых. Высокий балл в чужом тесте говорит о модели в целом, но не о том, справится ли она с вашими документами, процессами и ограничениями по цене.

Материал подготовлен AIrassvet 14 октября 2026 года по статье на Хабре «Период полураспада бенчмарка ИИ сократился вдвое» (13 октября 2026 года), исследованиям насыщения бенчмарков на arXiv и в Nature Communications, а также по опыту отбора моделей из открытого кейса внедрения ИИ-агента. Он адресован руководителям, ИТ-директорам и продуктовым командам, которые выбирают языковую модель для чат-бота, ИИ-агента, RAG-системы или обработки документов. Статья не составляет рейтинг моделей и не рекомендует конкретного поставщика. Собственного исследования бенчмарков AIrassvet не проводил; все цифры принадлежат авторам указанных работ. AIrassvet не аффилирован с ними; раздел в конце статьи описывает услуги издателя.

Содержание

Кратко

  1. Бенчмарки стареют быстрее: период полураспада публичных тестов, вышедших в 2023 году и позже, — около 19 месяцев (95 % доверительный интервал 15–23), у вышедших до 2023 года — 38 месяцев.
  2. Дело не в том, что тесты стали проще: на старте у новых бенчмарков такой же запас до потолка, но модели проходят его примерно вдвое быстрее.
  3. Каждый седьмой новый бенчмарк ломается сам: из-за ошибок в задачах или проверке. У агентных сред это причина почти половины «смертей».
  4. Автоматические рейтинги можно обмануть: «нулевая модель», которая всегда отвечает одной и той же строкой, набрала 86,5 % на AlpacaEval 2.0.
  5. Вывод для бизнеса: публичный рейтинг годится, чтобы сузить список кандидатов. Окончательный выбор стоит делать на своём наборе из 30–100 задач с известными ответами, ценой и задержкой — это рабочий ориентир редакции, а не норма из исследований.

Что такое бенчмарк и почему он «умирает»

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

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

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

Что показал разбор 224 бенчмарков

Автор винного бенчмарка OenoBench собрал 224 бенчмарка, о которых в 2018–2026 годах отчитывались девять лабораторий: OpenAI, Anthropic, Google, Meta, xAI, DeepSeek, Alibaba, Moonshot и Mistral. В выборку попадал тест, о котором в официальных материалах релиза отчитались хотя бы две лаборатории из девяти или одна — хотя бы в трёх релизах. Всего 230 релизов и 6652 строки «релиз × бенчмарк × результат», срез — 30 сентября 2026 года. Правила, что считать смертью теста, записали в кодбук до начала разметки, а датасет и код опубликованы (Хабр, 13.10.2026).

Год выхода бенчмарков Бенчмарков Умерло к срезу Период полураспада, мес (95 % ДИ)
2016–2019 28 19 49 (24–98)
2020–2022 21 14 38 (25 и выше)
2023 23 16 19 (13–27)
2024 50 30 21 (17–26)
2025 63 27 19 (12 и выше)
2026 39 10 история слишком короткая для оценки

Главные выводы автора:

  • По всей выборке период полураспада — 23 месяца (95 % ДИ 19–27). Четверть бенчмарков умирает в первый же год.
  • Разрыв между эпохами — вдвое: 38 месяцев у вышедших до 2023 года (за первый год умирало 4 %) и 19 месяцев у вышедших позже (за первый год — около трети).
  • С каждым следующим годом выхода риск «смерти» растёт примерно на 22 %. Для типичного публичного статического теста это значит: вышедший в 2018 году прожил бы около 53 месяцев, в 2022-м — 31, в 2026-м — 18.
  • Разрыв держится при строгих правилах: если засчитывать только независимо проверенные результаты одиночных моделей, периоды вырастают до 68 и 26 месяцев, а разница даже увеличивается.

Новые бенчмарки не проще старых. Медианный запас до порога на старте у старых тестов — 35 процентных пунктов, у новых — 38. Зато по траекториям Epoch AI для 21 бенчмарка из выборки лучший результат рос на старых тестах на 0,75 логита в год, а на новых — на 1,56, то есть вдвое быстрее. Путь до потолка прежний, модели проходят его быстрее.

Независимые работы показывают ту же картину. Исследование коалиции EvalEval, опубликованное на ICML 2026, проанализировало 60 бенчмарков языковых моделей: почти половина из них насыщена, доля растёт с возрастом теста, а устойчивость к насыщению зависит от экспертной курации, а не от закрытости тестовых данных (arXiv:2602.16763). Ранее Ott и соавторы разобрали траектории тысяч бенчмарков из Papers with Code в журнале Nature Communications (Ott et al., 2022).

От чего умирают бенчмарки

Из 116 «смертей» в выборке 84 — это порог, взятый моделями. Ещё 12 раз создатели сами объявили тест насыщенным раньше, чем модели дошли до порога. Остальные 20 — дефекты: ошибки в задачах или проверке, независимый аудит или тривиальный метод.

Причина Пример из исследования Что это значит для выбора модели
Модели взяли порог GPQA Diamond вышел в ноябре 2023 года и «умер» через 24 месяца, когда модель набрала 91,9 % Разница между лидерами на таком тесте уже ничего не говорит
Создатели объявили насыщение Первую версию Finance Agent объявили насыщенной при лучшем результате 60,7 % Порог «смерти» у разных тестов разный — смотрите на правила
Дефекты задач При аудите Humanity's Last Exam из 2500 вопросов без правок оставили только 668, 1143 исправили, по 689 не смогли вынести вердикт Часть «ошибок» модели может быть ошибками теста
Дефекты агентной среды Аудит домена airline из τ-bench признал недоопределёнными 31 задачу из 50 Агентные тесты особенно хрупкие
Смена версии Terminal-Bench 3.0 прожил месяц: в версии 4.0 убрали 8 задач из 74 Результаты разных версий нельзя сравнивать напрямую

Агентные среды ломаются чаще всего. Среди бенчмарков 2023 года и позже за первые два года 45 % умирают от моделей, 14 % — от дефектов и смены версий. Две трети смертей от дефектов приходятся на агентные среды: из 29 умерших агентных сред 13 сломались сами, а среди 81 умершего статического теста — шесть. По данным автора, при создании SWE-bench Verified отсеяли 68 % задач исходного набора как недоопределённые или с нечестными тестами.

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

Почему высокий балл ещё не значит, что модель подойдёт вам

Есть четыре причины не принимать решение по чужому рейтингу.

1. Автоматические оценки можно обмануть. В работе Zheng и соавторов «нулевая модель», которая на любой запрос выдаёт одну и ту же заранее подобранную строку, получила 86,5 % length-controlled win rate на AlpacaEval 2.0, 83,0 балла на Arena-Hard-Auto и 9,55 на MT-Bench (arXiv:2410.07137). Это доказательство концепции, а не обвинение конкретных моделей, но оно показывает, что балл, выставленный другой моделью-судьёй, — не гарантия качества.

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

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

4. Рейтинг не учитывает ваши ограничения. Цена за тысячу запросов, задержка ответа, работа в российском контуре, требования к персональным данным, надёжность вызова инструментов — всё это вы измеряете сами. Даже токенизация русского текста у разных моделей отличается, а значит, и реальная стоимость; подробнее — в статье о токенизации русского текста и стоимости LLM.

Публичный рейтинг или свой набор: когда что

Задача Публичного рейтинга достаточно? Что делать
Сузить список из 20 моделей до 3–5 кандидатов Да Смотрите живые, не насыщенные тесты близкого класса задач
Выбрать модель для чат-бота поддержки или RAG по своим документам Нет Свой набор вопросов с эталонными ответами и ссылками на источники
Выбрать модель для ИИ-агента с вызовом инструментов Нет Свои задачи с известным ответом и подсчётом падений и зацикливаний
Решить, заменить ли текущую модель новой версией Нет Прогон старой и новой модели на одном и том же наборе
Понять общий уровень модели для внутренней презентации Да, с оговорками Указывайте дату теста и проверяйте, не насыщен ли он
Сравнить облачную модель и модель на своих серверах Нет Одинаковый набор, плюс замер цены, задержки и нагрузки

Как собрать свой бенчмарк для выбора модели: 7 шагов

Это методика редакции AIrassvet, собранная из рекомендаций автора исследования и практики оценки ИИ-систем. Она не требует специальных инструментов на старте — достаточно таблицы и скрипта.

  1. Опишите одну задачу и критерий успеха. Не «умный ассистент», а «ответ клиенту по регламенту возврата с правильной ссылкой на пункт». Запишите, что считается правильным ответом, частично правильным и ошибкой.
  2. Соберите задачи из реальной работы. Возьмите 30–100 настоящих обращений, документов или инцидентов с уже известным правильным результатом. Обезличьте персональные данные до того, как задачи увидит внешняя модель.
  3. Оставьте запас до потолка. Автор исследования показал, что запас на старте — главный рычаг долголетия теста: каждый логит запаса удлиняет жизнь примерно в полтора раза. Если текущая модель решает почти всё, добавьте трудные случаи: длинные документы, редкие исключения, вопросы без ответа в базе.
  4. Зафиксируйте правила оценки до прогона. Как и в исследовании, где кодбук записали до разметки, решите заранее, что считается верным ответом. Иначе критерии незаметно подстроятся под понравившуюся модель.
  5. Делайте несколько прогонов на каждую модель. В кейсе внедрения ИИ-агента разница в цене между моделями, которая на первом прогоне выглядела как порядок, на полусотне прогонов сжалась до нескольких раз. Одного прогона мало.
  6. Измеряйте не только качество. Для каждого прогона запишите: верно ли, сколько стоило по биллингу, сколько длилось, были ли падения, сломанный формат, отказ, зацикливание.
  7. Разделите выбор и приёмку. Набор для выбора модели и набор для приёмки готовой системы лучше держать отдельно, чтобы не подгонять систему под известные задачи.

О том, как отдельно оценивать поиск, ответы и галлюцинации в RAG-системах, — в статье о точности RAG и галлюцинациях.

Шаблон карточки задачи и протокола прогона

Скопируйте эту структуру в таблицу или YAML — так набор можно будет перезапускать при каждой новой модели.

Карточка задачи

Поле Что записать Пример
ID и версия Уникальный номер и версия набора refund-017, набор v1.2
Сценарий К какому процессу относится задача Ответ клиенту о возврате
Вход Вопрос, документ или контекст, который получает модель Текст обращения и выдержка из регламента
Эталон Правильный ответ или признаки правильного ответа Срок возврата и ссылка на пункт 4.2
Правило оценки Как ставится «верно / частично / неверно» Неверно, если срок указан неправильно
Трудность Обычная, трудная, без ответа в базе Без ответа — модель должна сказать, что не знает
Чувствительность Есть ли персональные или коммерческие данные Обезличено

Протокол прогона

Поле Что записать
Дата и версия модели Точное название и версия, провайдер, регион
Параметры Температура, системный промпт, версия промпта
Результат по задаче Верно / частично / неверно, комментарий проверяющего
Стоимость По биллингу ключа, а не по прайсу
Задержка Медиана и самый долгий ответ
Сбои Падения, ошибки формата, отказы, зацикливания
Итог Доля верных, доля трудных верных, стоимость на одну задачу

Пример: отбор модели для ИИ-агента в эксплуатации

Хороший пример маленького собственного бенчмарка — кейс команды, которая подключила открытый агент HolmesGPT к разбору алертов в Kubernetes (Хабр, 13.10.2026). Вместо рейтинга они провели отбор: восемь моделей, 52 прогона в три волны, включая задачу с заранее известным ответом.

Что показал этот отбор:

  • Половина кандидатов провалила задачу с известным ответом одинаково: уверенно сообщила, что нужного компонента в кластере нет, хотя он был — просто его не видно среди обычных объектов.
  • Победила не самая дешёвая модель: DeepSeek V4 Flash прошла 16 прогонов без единого падения и верно решила задачу во всех четырёх попытках; обе модели дешевле неё задачу не решили.
  • Продакшен добавил новые критерии: в одном контуре примерно каждый пятый разбор не укладывался в 15 минут, в другом модель зацикливалась. Команда перешла на более дорогую по прайсу модель, зато разборы стали заканчиваться.

Отсюда практическое правило: в свой набор нужно включать не только «правильно / неправильно», но и надёжность — таймауты, падения, повторные вызовы. Если модель будет внедрять подрядчик, попросите его показать такой протокол на ваших задачах; о выборе подрядчика — в статье как выбрать LLM-интегратора.

Как не дать своему бенчмарку устареть

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

  • Закладывайте полтора-два года жизни, а не пять. Если нужен инструмент на годы, нужен механизм обновления задач.
  • Определите насыщение заранее. Например: если все кандидаты решают больше 95 % задач, набор пора усложнять.
  • Ведите версии. Закреплённая версия набора, журнал изменений, отдельные результаты для каждой версии. Если заменено больше заметной доли задач, сравнивать старые и новые результаты напрямую нельзя.
  • Проверяйте сами задачи. Аудит задач до запуска дешевле, чем «исправленная» версия через полгода: часть «ошибок модели» может оказаться ошибками эталона.
  • Закрытость не продлевает жизнь. И в исследовании на Хабре, и в работе EvalEval закрытый тестовый набор не защищал от насыщения. Он защищает от утечки, но не от прогресса моделей. Держать корпоративный набор вне интернета всё равно стоит — ради конфиденциальности.

Частые вопросы

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

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

Почему публичные рейтинги моделей быстро устаревают?

Модели проходят путь до потолка теста примерно вдвое быстрее, чем раньше, а часть бенчмарков ломается из-за ошибок в задачах. По разбору 224 бенчмарков половина тестов, вышедших с 2023 года, перестаёт различать лучшие модели примерно за 19 месяцев.

Сколько задач нужно в собственном бенчмарке?

Единого стандарта нет. Рабочий ориентир редакции AIrassvet — 30–100 реальных задач с известным ответом на один сценарий, включая трудные случаи и вопросы без ответа. Важнее, чтобы задачи были похожи на настоящую работу и проверялись по заранее записанным правилам.

Можно ли доверять оценке, которую ставит другая модель?

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

Как часто перепроверять выбранную модель?

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

Что важнее при выборе модели: качество или цена?

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

Первоисточники и метод проверки

Метод: мы прочитали исходное исследование целиком 14 октября 2026 года, выписали показатели вместе с оговорками автора и сверили описание независимых работ по их аннотациям на arXiv и странице журнала. Шаги, шаблон и ориентир 30–100 задач — методика редакции AIrassvet, а не выводы исследований.

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

Как AIrassvet помогает выбрать и проверить модель

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

  • Аудит процесса и подготовка данных: отбор реальных задач, обезличивание, эталонные ответы.
  • Внедрение и дообучение языковых моделей, включая развёртывание на серверах заказчика, — когда нужно сравнить облачную и собственную модель на одном наборе.
  • RAG-системы и корпоративные базы знаний — если модель должна отвечать по вашим документам.
  • Разработка MVP, интеграция и тестирование выбранной модели до масштабирования.

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

Обсудить задачу.

Итог: рейтинг сужает выбор, решение даёт свой набор

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

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

← Все статьи

Комментарии (0)

Пока нет комментариев. Будьте первым!

Оставить комментарий
Регистрация не требуется