Evaluation: tuned model versus base

Самообман номер один в fine-tuning-проектах: сравнить тюненую модель с базой на голом промпте и отрапортовать «плюс 30 пунктов». В проде альтернатива вашей модели — не голая база, а база с лучшим промптом, few-shot примерами и всеми ухищрениями из первого урока. Честное сравнение: tuned с коротким промптом против base с максимально выжатым промптом, на одном held-out наборе, при одинаковых параметрах генерации (temperature, max_tokens). Отдельной строкой — сравнение с большой API-моделью: если ваша 8B проигрывает ей по качеству, но выигрывает в десять раз по цене, это осмысленный бизнес-результат, только фиксируйте оба числа.

Второе правило: метрика успеха формулируется до обучения. «Стало лучше» — не метрика; «доля валидного JSON выше 99% и win rate по глубине разбора не ниже 60%» — метрика. Когда критерий выбирается после взгляда на результаты, человек неизбежно подбирает тот, по которому модель выглядит лучше.

Третье: только held-out. Метрики на обучающих данных не значат ничего — модель могла их запомнить. И если вы многократно итерируетесь, подглядывая в held-out, он тоже протухает: держите второй, финальный набор, к которому прикасаетесь один раз перед релизом.

Абсолютные оценки («поставь от 1 до 10») шумные: судьи-LLM сжимают шкалу и непоследовательны между прогонами. Парные сравнения устойчивее: судья видит промпт и два ответа — A и B — и выбирает победителя по рубрике или объявляет ничью. Из бинарных вердиктов складывается win rate.

Два обязательных элемента протокола. Первый — контроль position bias: LLM-судьи систематически чаще выбирают первый из показанных ответов. Каждую пару прогоняйте дважды с переставленными позициями; вердикт засчитывается, только если он совпал в обоих порядках, иначе — ничья. Второй — калибровка судьи: на 30–50 парах сравните вердикты судьи с вашими собственными; согласие ниже 80% означает, что рубрика размыта и судить рано.

Теперь статистика. Win rate 55% на 40 примерах — это не победа: 95-процентный доверительный интервал при таком n — примерно ±15 процентных пунктов, внутри сидит и 50%, и поражение. Грубая формула: половина ширины интервала ≈ 1/√n. Сто примеров дают ±10 п.п., четыреста — ±5 п.п. Хотите утверждать «60% против 50%» — нужно не меньше трёхсот сравнений либо bootstrap-интервал по вашим данным. Дешевле всего набрать объём, автоматизировав судейство и оставив человеку выборочную проверку.

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

lm_eval --model hf \
  --model_args pretrained=out/merged,dtype=bfloat16 \
  --tasks mmlu,gsm8k,humaneval \
  --batch_size 8

Порог допустимой просадки задаётся заранее: например, «минус 2 пункта на MMLU приемлемо, минус 10 — блокер». Небольшая просадка на нерелевантных задачах — нормальная цена специализации; важно, чтобы она была осознанной, а не сюрпризом от пользователей.

Вторая ловушка — выбор чекпойнта по train loss. Loss падает монотонно, а качество на held-out после какой-то эпохи начинает деградировать: модель зазубривает датасет. Правильно: сохранять чекпойнт после каждой эпохи и выбирать по held-out метрике, а не по loss. Типичная картина для SFT на 1–3 тысячах примеров — пик качества на второй эпохе.

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

Соберём протокол оценки в чек-лист, который защищает от самообмана.

1. Метрика и порог приёмки зафиксированы до обучения.
2. Бейзлайн — база с лучшим промптом плюс, при необходимости, большая API-модель; параметры генерации одинаковы.
3. Оценка только на held-out; для финального вердикта — нетронутый второй набор.
4. Side-by-side с рандомизацией позиций и откалиброванным судьёй.
5. Win rate с доверительным интервалом; интервал не должен накрывать 50%.
6. Регрессии на общих бенчмарках в пределах заранее заданного порога.
7. Чекпойнт выбран по held-out метрике, а не по train loss.
8. Формат проверен на промптах вне распределения.

И последнее — читайте транскрипты. Двадцать случайных side-by-side, прочитанных глазами, регулярно вскрывают то, что метрики маскируют: модель побеждает за счёт многословия, судья награждает уверенный тон, форматная ошибка сидит в одном и том же поле. Числа решают «лучше или хуже», чтение объясняет «почему» — и подсказывает, что чинить в данных следующей итерации.