Benchmark

Benchmark — общий набор задач, правил запуска и метрик для сравнения моделей. Результат имеет смысл только вместе с версией датасета, prompt, числом попыток и способом оценки. Публичный leaderboard дополняют закрытыми и собственными задачами.

Коротко

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

Из чего состоит benchmark

Полный benchmark — не только файл с вопросами. В него входят:

• набор входных данных;
• эталонные ответы или критерии;
• prompt и формат сообщений;
• доступные инструменты;
• параметры генерации;
• число попыток;
• способ подсчёта метрики;
• правила обработки отказов и ошибок;
• версия модели и дата запуска.

Если две таблицы используют разный prompt или pass@k, их проценты нельзя сравнивать напрямую.

Benchmark и eval

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

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

Какие бывают наборы

Знания и вопросы с вариантами

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

Математика и рассуждение

Используют задачи с проверяемым ответом. Важно отделять итог от свободного chain of thought и учитывать инструменты вроде калькулятора.

Код

Модель пишет функцию или исправляет репозиторий, а оценка запускает тесты. Качество тестов и безопасность sandbox становятся частью benchmark.

Диалог и предпочтения

Ответы оценивают люди или модель-judge. Такие рейтинги чувствительны к стилю, порядку кандидатов и предпочтению длинных уверенных ответов.

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

Проверяют документы, схемы, изображения, аудио и видео. Нужны точные условия preprocessing: resize, OCR, число кадров и доступное разрешение.

Метрики

Accuracy — доля точных ответов. F1 полезна при дисбалансе классов. Pass@k показывает, найдено ли решение среди нескольких попыток. Для retrieval используют recall@k, MRR или nDCG. Для генерации часто нужны несколько метрик и ручная проверка.

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

Наглядный пример

Команда выбирает модель для исправления багов.

Публичный coding benchmark помогает отобрать кандидатов. Затем каждая модель получает одинаковый набор внутренних задач с чистым checkout и фиксированными инструментами.

Для каждой задачи записываются:

• прошли ли тесты;
• сколько итераций понадобилось;
• размер и качество diff;
• не изменился ли публичный API;
• задержка и полная стоимость;
• потребовалось ли вмешательство человека.

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

Contamination

Benchmark contamination возникает, когда вопросы или очень похожие решения попали в обучение. Модель воспроизводит знакомый шаблон, и результат перестаёт измерять обобщение.

Риск снижают:

• новыми закрытыми задачами;
• временным разделением данных;
• переформулировками и вариантами;
• поиском дословных совпадений;
• canary-строками;
• отчётом о возможном доступе модели к набору.

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

Saturation

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

Полезные новые версии добавляют трудные примеры, проверяют процесс, используют живые репозитории или меняющиеся данные. Но вместе с реализмом растёт стоимость и сложность воспроизводимости.

LLM-as-a-judge

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

Для проверки judge:

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

Почему leaderboard быстро стареет

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

Долговечная статья не называет победителя. Она объясняет, как воспроизвести сравнение и построить собственный holdout.

Как собрать свой eval

1. Выписать реальные решения, которые принимает система.
2. Собрать обычные, крайние и опасные случаи.
3. Зафиксировать ожидаемый результат или рубрику.
4. Отделить development-набор от закрытого holdout.
5. Запускать кандидатов с одинаковыми правами и бюджетом.
6. Сохранять model ID, prompt, usage и сырые ответы.
7. Смотреть не только среднее, но и группы ошибок.
8. Повторять eval после изменения модели, контекста или tool.

Небольшой качественный набор реальных задач часто полезнее огромного общего рейтинга.

Частые ошибки

• Сравнивать числа из разных источников. Условия могли отличаться.
• Игнорировать число попыток. Pass@1 и pass@many отвечают на разные вопросы.
• Выбирать по одному benchmark. Способности многомерны.
• Публиковать score без model ID. Алиас способен измениться.
• Использовать test set для настройки prompt. Он перестаёт быть независимым.
• Принимать judge за объективную истину. Его тоже нужно валидировать.

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

Какой benchmark самый важный?

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

Можно ли доверять leaderboard?

Как ориентиру для списка кандидатов. Перед выводом проверяются условия, дата, ID моделей, инструменты и возможная contamination.

Сколько задач нужно?

Зависит от разброса и цены ошибки. Важнее покрыть все классы риска и не использовать один и тот же набор для настройки и финального отчёта.

Нужно ли оценивать стоимость?

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

Главное

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