Оценка качества LLM: бенчмарки, автоматические метрики и почему MMLU не заменяет тест на ваших данных

Бенчмарк показывает, как модель справляется с задачами, которые кто-то другой счёл репрезентативными. Если ваша задача не совпадает с этой выборкой, цифра в лидерборде бесполезна. Оценка качества LLM — это не выбор одного числа из таблицы, а построение системы измерений, которая отвечает на конкретный вопрос: «Насколько хорошо модель решает мою задачу?»

Что измеряют бенчмарки и почему они расходятся с реальностью​

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

• Доменную специфику. Модель, набравшая 85% на MMLU, может ошибаться в юридических формулировках, если в обучающих данных не было достаточно примеров из этой области.
  
• Формат взаимодействия. Бенчмарк обычно тестирует single-turn QA. В продакшене модель работает в многошаговом диалоге, с контекстом, инструкциями и ограничениями.
  
• Распределение ошибок. Средний балл скрывает, что модель может стабильно ошибаться на определённом подмножестве запросов — например, на задачах с отрицанием или на многоязычных примерах.
  
• Утечку данных. Часть вопросов из публичных бенчмарков попадает в обучающие датасеты. Высокий балл может отражать запоминание, а не обобщение.
  

Основные публичные бенчмарки​

MMLU (Massive Multitask Language Understanding)​

57 предметов — от физики до юриспруденции. Формат: вопрос с четырьмя вариантами ответа. Измеряет широту знаний и способность к рассуждению в формате множественного выбора.

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

HumanEval и MBPP​

Измеряют способность генерировать код. HumanEval содержит 164 задачи на Python с юнит-тестами. MBPP — около 974 задач начального уровня.

Ограничения: задачи короткие и изолированные. Реальная разработка включает работу с существующей кодовой базой, рефакторинг, понимание контекста проекта — всё это бенчмарки не покрывают.

GSM8K​

8500 математических задач начальной школы с пошаговым решением. Проверяет цепочку рассуждений (chain-of-thought).

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

HellaSwag, ARC, WinoGrande​

Измеряют здравый смысл и понимание контекста. Формат — выбор наиболее вероятного продолжения или ответа.

MT-Bench и Chatbot Arena​

MT-Bench — многошаговые диалоги, которые оценивает другая LLM (LLM-as-judge). Chatbot Arena — парные сравнения, где люди голосуют за лучший ответ. Оба подхода ближе к реальному использованию, но имеют собственные смещения: LLM-судья склонен предпочитать более длинные ответы, а голосование в Arena зависит от субъективных предпочтений.

Автоматические метрики для генерации текста​

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

BLEU​

Сравнивает n-граммы сгенерированного текста с эталонным переводом. Изначально создан для машинного перевода.

Проблемы: не учитывает семантику. Два текста с одинаковым смыслом, но разными словами получают низкий BLEU. Для задач суммаризации и генерации ответов метрика часто не коррелирует с человеческой оценкой.

ROUGE​

Измеряет перекрытие n-грамм между сгенерированной и эталонной суммаризацией. Варианты: ROUGE-1 (униграммы), ROUGE-2 (биграммы), ROUGE-L (наибольшая общая подпоследовательность).

Проблемы: те же, что у BLEU — лексическое перекрытие не равно смысловая близость.

BERTScore​

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

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

LLM-as-Judge​

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

Почему ни один бенчмарк не заменяет тест на ваших данных​

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

Типичные сценарии расхождения:

Ситуация	Почему бенчмарк не помогает
Узкий домен (медицина, финансы, юриспруденция)	В обучающих данных мало примеров из этой области
Специфический формат вывода (JSON, SQL, разметка)	Бенчмарки тестируют свободный текст или выбор варианта
Многоязычность	Большинство бенчмарков англоязычные
Длинные контексты	Бенчмарки редко проверяют работу с контекстом > 8K токенов
Устойчивость к adversarial-запросам	Публичные наборы не содержат целенаправленно сложных примеров

Как построить собственный оценочный набор​

Шаг 1: Определите критерии качества​

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

• Фактическая точность (нет выдуманных фактов).
  
• Следование формату (валидный JSON, корректный SQL).
  
• Полнота (ответ покрывает все части запроса).
  
• Отсутствие галлюцинаций в цитатах и ссылках.
  

Шаг 2: Соберите репрезентативную выборку запросов​

Источники:

• Логи реальных запросов пользователей (анонимизированные).
  
• Пограничные случаи, которые вы знаете из поддержки или тестирования.
  
• Запросы с намеренно сложной формулировкой: отрицания, двусмысленности, многосоставные инструкции.
  

Размер выборки зависит от задачи. Для грубой оценки достаточно 50–100 примеров. Для статистически значимого сравнения двух моделей — 300+ примеров на каждую категорию.

Шаг 3: Разметьте эталонные ответы или критерии оценки​

Два подхода:

• Эталонный ответ. Подходит для задач с однозначным правильным результатом (классификация, извлечение данных, генерация SQL).
  
• Рубрика. Подходит для открытых задач. Опишите, что считается приемлемым, что — частичным, что — провалом.
  

Шаг 4: Автоматизируйте запуск и подсчёт​

Простейший пайплайн:

import json

def evaluate(model_fn, test_cases):
    results = []
    for case in test_cases:
        output = model_fn(case["prompt"])
        score = case["scorer"](output, case.get("reference"))
        results.append({"id": case["id"], "score": score})
    return results

Для LLM-as-judge scorer — это промпт с критериями и шкалой. Для детерминированных задач — функция сравнения (регулярное выражение, парсинг JSON, выполнение SQL).

Шаг 5: Отслеживайте регрессии​

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

Типичные ошибки при оценке​

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

Тестирование на данных из обучения. Если вы дообучали модель на части тестового набора, результаты завышены. Разделяйте данные до начала обучения.

Игнорирование вариативности. При temperature > 0 модель даёт разные ответы на один и тот же запрос. Один запуск — не оценка. Минимум 3–5 запусков на пример, если задача не детерминирована.

Оценка только «хороших» ответов. Полезно отдельно отслеживать долю галлюцинаций, отказов и форматных ошибок. Модель, которая даёт блестящий ответ на 70% запросов и выдумывает факты на 30%, хуже модели со стабильным средним качеством.

Практический чек-лист перед выбором модели для продакшена​

1. Определите 3–5 критериев качества, специфичных для вашей задачи.
   
2. Соберите минимум 100 запросов из реального распределения.
   
3. Разметьте эталоны или рубрики.
   
4. Прогоните кандидатов (2–4 модели) на одном наборе.
   
5. Посмотрите не только средний балл, но и худшие 10% ответов.
   
6. Проверьте устойчивость: повторите запуск, если используете сэмплирование.
   
7. Зафиксируйте результаты как базовую линию для будущих сравнений.
   

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