Benchmark

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

Коротко

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

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

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

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

Если различаются запросы, инструменты или число попыток, проценты уже не описывают одинаковый эксперимент. Например, pass@1 оценивает одну попытку, а pass@k — успех среди k попыток.

Benchmark и eval

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

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

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

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

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

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

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

Код

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

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

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

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

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

Метрики

Accuracy — доля правильных ответов. F1 объединяет точность и полноту: например, сколько найденных объектов действительно относятся к нужному классу и сколько таких объектов удалось найти. При дисбалансе классов важно указать, для какого класса и с каким усреднением рассчитана метрика.

Pass@k оценивает вероятность получить хотя бы одно верное решение среди k попыток. Она не показывает, сможет ли система самостоятельно выбрать этот ответ. Метод описан, например, в работе, представившей HumanEval.

В поиске используют полноту среди первых k результатов — recall@k — и метрики порядка выдачи, такие как MRR и nDCG. Одной метрики часто недостаточно: HELM рассматривает качество моделей по нескольким измерениям.

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

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

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

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

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

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

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

Попадание тестов в обучение

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

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

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

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

Насыщение теста

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

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

Когда ответы оценивает другая модель

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

Для проверки модели-оценщика:

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

Как читать таблицу результатов

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

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

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

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

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

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

• Сравнивать числа из разных источников. Условия могли отличаться.
• Игнорировать число попыток. Pass@1 и pass@many отвечают на разные вопросы.
• Выбирать по одному benchmark. Способности многомерны.
• Публиковать балл без версии модели. Сервис может обновить модель за одним и тем же коротким именем.
• Подбирать запрос по итоговым тестовым задачам. Они перестают быть независимой проверкой.
• Считать модель-оценщика объективной. Её ответы тоже нужно проверять.

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

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

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

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

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

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

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

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

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

Главное

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