Как вы проверяете, что fine-tuned модель не сломала базовые способности?

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

Проверка сохранности базовых способностей после fine-tuning — это критически важный этап оценки. Мы создаём единый бенчмарк, включающий три категории: кастомные задачи (которые улучшали), базовые знания (MMLU, HellaSwag) и safety/alignment. Запускаем его на исходной модели и на fine-tuned, сравниваем метрики. Порог допустимого ухудшения базовых способностей — не более 5%, иначе применяем методы смягчения вроде уменьшения learning rate или replay buffer.

1. Термин: Fine-tuning и базовые способности

Fine-tuning — это процесс дообучения предобученной языковой модели (LLM) на небольшом специализированном датасете для улучшения её производительности на конкретной задаче. Однако при этом модель может потерять часть общих знаний — это явление называется катастрофическим забыванием (catastrophic forgetting).

Базовые способности — это широкий круг навыков, которыми обладает исходная модель: понимание языка, фактические знания, логика, генерация безопасного контента. Они обычно оцениваются на стандартных бенчмарках (MMLU, HellaSwag, TruthfulQA и т.д.) и через тесты на вредоносный контент (safety). Сохранение этих способностей критически важно, потому что fine-tuning не должен превращать модель в «специалиста», который не умеет отвечать на простые вопросы вне своей области.

2. Почему fine-tuning может ломать способности

Основные причины ухудшения:

• Дисбаланс датасета если данные для fine-tuning слишком узкие, модель переобучается на них и «забывает» остальное.
• Высокая скорость обучения (learning rate): большие шаги градиента могут резко изменять веса, нарушая обобщающие представления.
• Малая диверсификация ответов если датасет содержит только шаблонные ответы, модель теряет вариативность.
• Смещение распределения (distribution shift): входные данные fine-tuning могут отличаться от предобучающего корпуса по стилю или формату.

3. Системный подход: единый бенчмарк до и после

Ключевая идея — оценка должна быть сравнительной: запускаем один и тот же набор тестов на исходной модели (baseline) и на fine-tuned версии. Только так можно увидеть динамику. Бенчмарк состоит из трёх независимых категорий, покрывающих разные аспекты качества.

4. Категория 1: Кастомные задачи (те, что улучшали)

Здесь мы используем специализированный тестовый набор — например, 20 вопросов из домена fine-tuning, которые не входили в тренировочные данные. Ожидается, что после fine-tuning метрики на этих задачах вырастут (иначе сама процедура бессмысленна). Примеры:

• Для summarization: ROUGE-L между сгенерированной и эталонной сводкой.
• Для classification: accuracy/ F1.
• Для chat: win-rate по сравнению с baseline после оценки людей или LLM-judge.

Важно: этот набор должен быть независимым от тренировочного (validation split). Если метрики не растут — fine-tuning не удался.

5. Категория 2: Базовые знания (MMLU, HellaSwag)

Используем стандартные открытые бенчмарки:

• MMLU (Massive Multitask Language Understanding): 57 предметов от математики до права. Accuracy по каждому предмету и общий скор.
• HellaSwag: здравый смысл и логика (выбор наилучшего продолжения предложения).
• TruthfulQA: правдивость ответов.
• GSM8K: математические рассуждения.

Для каждой модели запускаем одинаковый seed и подсчитываем метрику. Ухудшение более чем на 5% считается сигналом о катастрофическом забывании.

6. Категория 3: Safety/Alignment

Проверка, что модель не стала генерировать опасный, токсичный или неэтичный контент. Используем красные команды (red teaming) — набор вредоносных запросов (например, «Как взломать банк?»). Хорошая модель должна отказываться отвечать или давать безопасный ответ. Метрики:

• Refusal rate – доля запросов, на которые модель отказалась отвечать.
• Toxicity score – измеряется с помощью перплексии или классификатора токсичности (например, ToxiGen).
• Bias тесты – модель не должна проявлять расовые, гендерные или другие предубеждения.

Важно, чтобы после fine-tuning эти метрики не ухудшились — safety не должна снижаться.

7. Процесс запуска и сбора метрик

1. Подготовка окружения фиксируем версии библиотек (transformers, evaluate, datasets), seed’ы для воспроизводимости.
2. Запуск на исходной модели — получаем baseline значения по каждому бенчмарку.
3. Fine-tuning — обучаем модель на целевом датасете.
4. Запуск на fine-tuned модели — те же тесты, те же hyperparameters инференса.
5. Сравнение для каждой метрики вычисляем дельту Δ = метрика_после - метрика_до. Если Δ для базовых знаний < 0 и |Δ| > 0.05 (5%) — обнаружена проблема.

Пример кода на Python для сравнения по MMLU:

import evaluate
from transformers import pipeline

def evaluate_mmlu(model_name):
    # Загружаем тестовый сплит MMLU (например, 1000 вопросов)
    mmlu = load_dataset("mmlu", "all", split="test")
    pipe = pipeline("text-generation", model=model_name)
    correct = 0
    for item in mmlu:
        prompt = item["question"] + "\nOptions: " + ", ".join(item["choices"])
        answer = pipe(prompt, max_new_tokens=1)[0]["generated_text"][len(prompt):].strip()
        if answer == item["answer"]:
            correct += 1
    return correct / len(mmlu)

baseline_acc = evaluate_mmlu("gpt2")
finetuned_acc = evaluate_mmlu("my-finetuned-model")
delta = finetuned_acc - baseline_acc
if delta < -0.05:
    print("Внимание: базовые способности ухудшены на {:.2%}".format(abs(delta)))

8. Пороги и принятие решений

Рекомендуемый порог: ухудшение базовых способностей не более 5% (абсолютных или относительных — оговаривается заранее). В таблице ниже — типовые решения:

9. Если упало: методы смягчения

Если тесты показали ухудшение, применяем следующие техники:

• Уменьшение learning rate (например, 2e-5 → 1e-5) — делает шаги градиента менее агрессивными.
• Replay buffer (experience replay) — добавляем в датасет fine-tuning примеры из предобучающей выборки (или генерация с помощью исходной модели), чтобы модель «вспоминала» общие знания.
• Regularization – L2 penalty или elastic weight consolidation (EWC), который штрафует за изменение важных для базовых знаний весов.
• Parameter-efficient fine-tuning (PEFT) – LoRA/Adapter, которые обучают лишь малую часть параметров, сохраняя основную архитектуру нетронутой.
• Multi-task learning – добавляем в датасет также несколько задач из общего домена (например, небольшой набор MMLU вопросов).

10. Дополнительные аспекты

• Долговременное тестирование иногда забывание проявляется не сразу, а после нескольких итераций дообучения. Рекомендуется протестировать на каждом шаге чекпоинта.
• Автоматизация с помощью CI/CD можно интегрировать запуск полного бенчмарка в pipeline при каждом коммите модели.
• Интерпретация дельты если метрики на кастомных задачах выросли на 20%, а на базовых упали на 4% — это может быть приемлемым компромиссом, но нужно согласование с бизнесом.

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

Задача разработать скрипт benchmark_after_ft.py, который принимает имя исходной и fine-tuned модели (из HuggingFace), скачивает тестовые наборы из трёх категорий, запускает инференс и выводит отчёт.

Инструменты Python, transformers, datasets, evaluate.

Шаги:

1. Загрузить 20 кастомных QA-пар из CSV (например, по финансам).
2. Загрузить MMLU (100 вопросов) и HellaSwag (50 примеров).
3. Загрузить тестовый набор для safety (refusal проверка — 20 красных запросов).
4. Для каждой модели запустить последовательно все тесты и сохранить метрики.
5. Сравнить метрики, вывести таблицу с дельтой и заключением (PASS/FAIL).

Ожидаемый результат автоматизированный отчёт о влиянии fine-tuning на базовые способности, понятный даже неспециалисту.

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

Навигация

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