Оценка LLM: бенчмарки и LLM-as-judge

У задачи «напиши письмо клиенту» нет единственного правильного ответа — поэтому оценивать LLM сложнее, чем классификатор. Разбираем бенчмарки и их болезни, арены с Elo, LLM-судей с их предвзятостями и то, как строить eval под собственный продукт.

Интуиция: почему это сложно

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

Автоматические бенчмарки и их болезни

Первый этаж — бенчмарки (benchmarks) с проверяемыми ответами: MMLU (тесты с выбором варианта по 57 предметам), GSM8K (школьные математические задачи с числовым ответом), HumanEval (генерация кода, проверяемая юнит-тестами). Дёшево, воспроизводимо, удобно сравнивать. Но у бенчмарков две хронические болезни:

• Контаминация (contamination) — задачи просочились в обучающие данные (они ведь лежат в открытом интернете), и модель «помнит» ответы, а не решает. Красивая цифра ничего не говорит о способностях.
• Насыщение (saturation) — топовые модели выбивают 90%+, и бенчмарк перестаёт различать их между собой.

Второй этаж — лидерборды на людских предпочтениях: LMArena показывает пользователю два анонимных ответа, тот голосует за лучший, а из миллионов парных сравнений считается рейтинг Elo (как в шахматах). Это устойчивее к контаминации, но меряет «что нравится людям в чате», а не качество на вашей задаче.

LLM-as-judge и его предвзятости

Люди — дорого и медленно, поэтому ответы всё чаще оценивает сильная LLM: судья (LLM-as-judge) получает вопрос, пару ответов и рубрику, а выдаёт вердикт. Дёшево и масштабируемо, но судья систематически предвзят:

• Position bias — склонность выбирать ответ, стоящий первым (или последним), независимо от содержания.
• Length bias — любовь к длинным, развёрнутым ответам, даже если они водянистые.
• Self-preference — судья завышает оценки ответам, похожим на его собственный стиль (особенно ответам своей же модели).

Поэтому судью обязательно калибруют: сравнивают его вердикты с человеческими на размеченном сете, прогоняют каждую пару дважды с переставленными A и B (если вердикт перевернулся — это position bias), проверяют корреляцию вердикта с длиной ответа.

Как строить eval под свой продукт

Публичные бенчмарки не ответят, хорошо ли ваш бот отвечает вашим пользователям. Рабочий рецепт:

• Золотой сет (golden set) — 100–500 реальных запросов из продукта с эталонными ответами или человеческими оценками. Это ваш главный актив.
• Рубрики — явные критерии для судьи («фактически верно», «уложился в формат», «не выдумал ссылок») вместо расплывчатого «оцени от 1 до 10».
• Парные сравнения — «какой из двух ответов лучше» люди и судьи дают надёжнее, чем абсолютные баллы.
• Регрессионные прогоны — каждый релиз промпта или смена модели прогоняется по золотому сету, метрики сравниваются с прошлыми. Eval — это CI для качества.

Человеческая оценка остаётся золотым стандартом — ею калибруют судью и принимают спорные решения, но целиком на ней жить дорого. И везде нужна статистическая честность: на 20 примерах разница «71% против 68%» — шум; считайте доверительные интервалы или хотя бы держите сеты в сотни примеров.