Кризис бенчмарков и почему публичные рейтинги нейросетей больше не имеют отношения к реальности

Каждый релиз новой большой языковой модели сопровождается победными гистограммами в социальных сетях. Новинка обгоняет конкурентов на три процента в тесте MMLU, ставит исторический рекорд в кодинге по HumanEval и выбивает почти сто процентов в математическом наборе GSM8K. Маркетинговые отделы объявляют о смене лидера в индустрии.

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

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

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

Закон Гудхарта в эпоху глубокого обучения

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

Именно это произошло со всеми популярными открытыми бенчмарками.

Тесты вроде MMLU создавались как академический срез эрудиции и логики. Однако когда коммерческий успех проекта и приток инвестиций стали напрямую зависеть от места в публичной таблице Hugging Face, разработчики начали невольно оптимизировать обучение именно под эти задания.

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

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

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

Системные перекосы автоматической оценки

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

Однако на практике этот метод породил целый букет когнитивных искажений алгоритмов.

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

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

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

Почему академические задачи врут инженерам

Стандартные датасеты проверяют работу моделей в идеальном сферическом вакууме.

Там всегда дано четкое и непротиворечивое условие задачи. Вопрос сформулирован на идеальном литературном английском языке, а правильный ответ заранее известен и строго верифицирован составителями теста.

В продакшене таких тепличных условий не существует в принципе.

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

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

Как зрелые команды организуют оценку в продакшене

Понимание тупиковости открытых таблиц привело команды разработки к созданию закрытых внутренних контуров тестирования.

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

Ответы оцениваются не абстрактными баллами за стиль, а жесткими программными инвариантами.

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

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

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

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

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