Как вы оцениваете качество после fine-tuning?

Краткий тезис

Оценка качества после fine-tuning — это многоуровневый процесс, сочетающий автоматические метрики, LLM-as-a-judge и human evaluation. Нельзя полагаться только на loss на валидации: нужно проверять, не переобучилась ли модель, сравнивать с baseline (до fine-tuning) и тестировать в production. Ключевой принцип — разделить данные на train / validation / holdout, использовать perplexity для языковых моделей, task-specific метрики для целевой задачи и A/B тестирование для оценки бизнес-эффекта.

1. Термин: Fine-tuning

Fine-tuning — это дообучение предобученной модели (например, LLM) на небольшом размеченном датасете для адаптации к конкретной задаче (классификация, суммаризация, генерация ответов в заданном стиле).

Почему оценка качества после fine-tuning критична:

• Без оценки вы не знаете, стала ли модель лучше или хуже baseline.
• Fine-tuning может привести к катастрофическому забыванию (catastrophic forgetting) — модель теряет общие знания.
• Нужно отличать улучшение на тестовых данных от переобучения.

Основной pipeline оценки

1. Собрать размеченный датасет.
2. Разделить на train (70-80%), validation (10-20%), holdout (10-20%).
3. Обучить модель на train, подбирать гиперпараметры на validation.
4. Финальная оценка на holdout (test set).
5. Дополнительно: A/B тест в production, LLM-as-a-judge, human evaluation.

2. Holdout set и валидация

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

Зачем выделять holdout

• Избежать data leakage (утечки данных) — когда модель косвенно видела тестовые примеры через валидацию.
• Получить реалистичную оценку обобщающей способности.

Валидация (validation set) — набор для подбора гиперпараметров (learning rate, batch size, количество эпох) и ранней остановки (early stopping).

Правило holdout — это «священный» набор. Вы смотрите на него только один раз, после финального обучения.

3. Автоматические метрики

Автоматические метрики бывают двух типов: perplexity (для языковых моделей) и task-specific (для конкретной задачи).

3.1 Perplexity (PPL)

Perplexity — метрика, показывающая, насколько модель «удивлена» текстом. Чем ниже PPL, тем лучше модель предсказывает следующий токен.

Формула:

PPL = exp( - ([[1. Как бы вы спроектировали RAG-систему для 10 000 документов с разной структурой|1]]/N) * sum(log P(token_i | context)) )

где N — число токенов, P — предсказанная вероятность.

Интерпретация

• PPL = 1 — идеально (модель всегда угадывает следующий токен).
• PPL = 100 — модель в среднем выбирает из 100 равновероятных токенов.

Ограничение Perplexity не всегда коррелирует с качеством генерации (например, модель может давать безопасные, но скучные ответы с низкой PPL).

3.2 Task-specific метрики

Пример: расчёт F1-score для ответов на вопросы

from sklearn.metrics import f1_score

y_true = [1, 0, 1, 1, 0]
y_pred = [1, 0, 0, 1, 1]
f1 = f1_score(y_true, y_pred)  # 0.67

(Здесь бинарная классификация, для генерации текста F1 считают по совпадающим токенам.)

Когда использовать task-specific метрики дают быструю обратную связь, но не учитывают семантическую эквивалентность (например, «Столица Франции — Париж» и «Париж — столица Франции» дадут разный ROUGE).

4. LLM-as-a-judge

LLM-as-a-judge — подход, при котором сильная LLM (GPT-4, Claude, Llama 3 70B) оценивает ответы fine-tuned модели по заданным критериям.

Как работает

1. Формируется промпт с инструкцией: «Оцени ответ по шкале 1–5 по критериям: полезность, точность, безопасность».
2. Подаётся запрос пользователя, ответ модели и (опционально) эталонный ответ.
3. LLM-судья выставляет оценку.

Пример промпта

Ты — эксперт по оценке качества ответов. Оцени ответ модели по шкале 1-5:
- 5: полный, точный, без ошибок
- 1: нерелевантный, содержит фактические ошибки

Запрос: {query}
Ответ модели: {response}
Эталонный ответ: {reference}

Твоя оценка (только число):

Преимущества

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

Недостатки

• Bias (смещение) в сторону LLM-судьи (например, предпочтение длинных ответов).
• Высокая стоимость, если использовать GPT-4.
• Необходимость валидации: нужно проверить корреляцию с human evaluation.

Рекомендация используйте LLM-as-a-judge как дополнение к автоматическим метрикам, а не замену.

5. Human evaluation (оценка человеком)

Human evaluation — привлечение людей-аннотаторов для оценки качества ответов. Незаменима для:

• Критичных доменов (медицина, юриспруденция).
• Оценки субъективных качеств (полезность, креативность, тон).
• Валидации LLM-as-a-judge.

Метрики human evaluation

• Likert scale (1-5) по разным аспектам.
• Pairwise comparison (какой ответ лучше, A vs B).
• Binomial testing (доля случаев, когда ответ модели лучше эталона).

Затраты дорого и медленно. Для стартапов — разовая валидация на 100-200 примерах, для production — регулярные замеры на краудсорсинге.

6. A/B тестирование в production

Даже если метрики на holdout хороши, нужно проверить, как модель ведёт себя в реальных условиях. A/B тест (или online evaluation) — сравнение fine-tuned модели с предыдущей версией (baseline) на части трафика (5–10%).

План A/B теста

1. Разделить трафик случайно: 50% baseline, 50% новая модель.
2. Собирать бизнес-метрики: user engagement (время сессии, количество запросов), quality rate (жалобы, thumbs down), retention.
3. Использовать статистическую значимость (p-value < 0.05, t-test или bootstrap).
4. После подтверждения — раскатка на 100%.

Важно A/B тест может выявить проблемы, невидимые на статическом тесте (например, рост токсичности на длинных запросах).

7. Обнаружение переобучения (overfitting)

Overfitting — модель отлично работает на train, но плохо на validation / holdout. Как детектировать:

• Сравнить loss на train и validation после каждой эпохи. Если loss на train падает, а на validation растёт — переобучение.
• Использовать early stopping (остановка, когда validation loss не улучшается N эпох).
• Смотреть на разницу метрик (accuracy train - accuracy validation > 5% — подозрение).

График переобучения (схематично):

Loss
^
|   train (---)
|   validation (---)
|         _______
|        /       \
|   ___/         \___
|   эпоха

(Тренировочный loss продолжает падать, валидационный начинает расти — точка остановки.)

Методы борьбы

• Regularization weight decay (L2), dropout.
• Data augmentation: синонимы, back-translation.
• LoRA (Low-Rank Adaptation) — обучение небольшого числа параметров, менее склонен к переобучению.

8. Комбинированный подход: лучшая практика

Идеальная схема оценки после fine-tuning:

1. Быстрая проверка (на validation после каждой эпохи): perplexity + task-specific метрика (например, F1).
2. Финальная оценка (holdout): те же метрики + LLM-as-a-judge на 500–1000 примерах.
3. Human evaluation на критических кейсах (100–200 примеров) для валидации судьи.
4. A/B тест на 5% трафика в течение 1–2 недель.

Пример метрик для чат-бота (fine-tuning на инструкции):

Такой подход даёт полную картину: техническое улучшение, субъективное качество и бизнес-эффект.

Пет-проект для закрепления

Задача Реализовать пайплайн оценки fine-tuned модели для задачи генерации заголовков новостей.

Инструменты Python, Hugging Face Transformers, TRL (для fine-tuning), LangChain (для LLM-as-a-judge), scikit-learn (метрики).

Шаги:

1. Загрузить датасет новостей (например, CNN/DailyMail).
2. Fine-tune модель (T5-small или GPT-2) на задачу генерации заголовка по тексту.
3. Разделить данные: train 80%, validation 10%, test 10%.
4. Написать скрипт оценки:
   • Рассчитать ROUGE-1, ROUGE-2, ROUGE-L на test set.
   • Использовать LLM-as-a-judge (GPT-4-mini) с промптом, оценивающим соответствие заголовка тексту по шкале 1-5.
   • Собрать 30 ответов для human evaluation (друзья или через Mechanical Turk).
5. Провести A/B тест (симуляция): случайно выбрать 100 запросов, сгенерировать заголовки старой и новой моделью, попросить людей выбрать лучший.

Ожидаемый результат

• Сравнительная таблица метрик (ROUGE, judge score, human preference).
• Вывод: улучшилась ли модель, есть ли переобучение.
• Код пайплайна на GitHub.

Связь с другими вопросами

Навигация

• Предыдущий: 24
• Следующий: 26
• Индекс: 00. Индекс разборов