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

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

Сначала разберите название теста

MMLU проверяет ответы на вопросы из разных учебных дисциплин. SWE-Bench оценивает попытку исправить реальные задачи в репозиториях. HumanEval смотрит на небольшие функции по описанию, а не на сопровождение большого проекта. AIME и другие математические наборы показывают работу с олимпиадными задачами. GPQA проверяет сложные вопросы естественных наук. Terminal-Bench оценивает планирование действий в командной строке. Arena собирает слепые оценки людей.

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

Четыре причины осторожно относиться к баллам

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

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

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

Статистический шум. Размер выборки, случайный порядок и округление влияют на результат. Разница 88,4% против 87,9% редко означает заметное преимущество в рабочем процессе. Проверьте доверительный интервал и число примеров.

Читайте не среднее, а профиль

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

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

Сделайте свой мини-бенчмарк

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

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

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

Сравнивайте цену результата

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

Зафиксируйте дату и канал доступа. API, веб-интерфейс и командный тариф могут использовать разные версии и параметры. Числа из пресс-релиза нельзя переносить в бюджет без повторного расчёта.

Три вопроса к любому заявлению

1. На каком тесте и какой части выборки получена победа?
2. Были ли одинаковыми модель, режим рассуждения, число попыток и подсказка?
3. Кто выполнял замер и есть ли независимое повторение?

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

Как не перепутать прогресс с удачным запуском

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

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

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

Когда лидерборд всё-таки полезен

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

Чек-лист чтения

1. Понятно, какую способность и какую выборку измеряет тест.
2. Известны модель, режим, число попыток и дата замера.
3. Проверены загрязнение, размер выборки и возможный шум.
4. Сравниваются профиль, ограничения и русский язык, а не одно среднее.
5. Есть собственные обезличенные задачи и эталонные ответы.
6. Учтены повторы, ручная проверка, задержка и стоимость.
7. Заявление подтверждено независимым прогоном или помечено как гипотеза.

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