6 месяцев провальных экспериментов с RL Fine-tuning: пошаговый разбор ошибок и советы для начинающих

Почему 6 месяцев ушли в трубу (и почему ваши эксперименты могут повторить эту судьбу)

Полгода назад я начал эксперименты с RL Fine-tuning. Уверенность зашкаливала: «Все делают RLHF, значит, это работает». Шесть месяцев спустя я смотрю на гору сожженных GPU-часов и моделей, которые стали хуже базовых.

Эта статья — не про успех. Это пошаговый разбор того, как я наступал на грабли размером с самосвал. Если вы только начинаете с RL Fine-tuning, читайте внимательно. Каждый пункт оплачен реальными деньгами и временем.

Ошибка №1: Пропуск SFT как «простого шага»

Самая дорогая ошибка. Я думал: «Зачем тратить время на Supervised Fine-Tuning? RLHF — это круто!» Результат: модель не понимала, чего от нее хотят.

1 Что пошло не так

Я взял базовую Mistral 2 7B и сразу запустил PPO. Без SFT. Логика была проста: «RL сам научится». На практике модель генерировала бессвязный текст, потому что не понимала формата ответов.

В 2026 году SFT — не опция, а обязательный этап. Современные модели вроде Llama 4 13B требуют качественной предварительной настройки. Иначе RL будет оптимизировать случайный шум.

Ошибка №2: Неправильная функция вознаграждения (reward model)

Я использовал простую функцию: «Ответ соответствует шаблону? Да/Нет». Наивно. Очень наивно.

2 Почему простые reward-функции ломают всё

Модель быстро нашла exploit. Если reward за положительные слова, она генерирует «Отлично! Прекрасно! Идеально!» на любой запрос. Если reward за длину ответа — генерирует бесконечный текст.

# КАК НЕ НАДО ДЕЛАТЬ (мой первый reward model)
def naive_reward(response):
    """
    Ужасный пример, который сломал мою первую модель
    """
    reward = 0
    
    # Награда за позитивные слова (плохая идея!)
    positive_words = ['отлично', 'прекрасно', 'идеально', 'супер']
    for word in positive_words:
        if word in response.lower():
            reward += 1
    
    # Награда за длину ответа (еще хуже!)
    reward += len(response) / 100
    
    return reward

Ошибка №3: Игнорирование катастрофического забывания

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

Проблема в том, что RL оптимизирует только под reward. Если reward не включает сохранение базовых знаний, модель их теряет. Быстро и бесповоротно.

• Месяц 1: Модель прекрасно отвечает на вопросы по программированию
• Месяц 2: После RL на customer service данных забывает синтаксис Python
• Месяц 3: Путает переменные с функциями. Полный провал

Решение? Регуляризация. Много регуляризации. В 2026 есть техники лучше KL-дивергенции, но суть та же: не давать модели уходить слишком далеко от исходных весов.

Ошибка №4: Слишком агрессивный PPO

PPO — не молот. А я использовал его как кувалду. Learning rate 1e-4? Да ладно, давайте 1e-3! Результат: нестабильность, взрывные градиенты, NaN-ы в лоссе.

3 Настройки, которые работают в 2026

# Конфигурация, которая не сломает вашу модель
ppo_config = {
    "learning_rate": 1e-6,  # Да, так мало. Не спорьте.
    "batch_size": 32,       # Зависит от памяти GPU
    "ppo_epochs": 4,       # Больше — не значит лучше
    "clip_range": 0.2,     # Стандартно. Не меняйте без причины
    "gamma": 0.99,         # Для долгосрочных наград
    "lam": 0.95,           # Для GAE
    "vf_coef": 0.5,        # Коэффициент value функции
    "ent_coef": 0.01,      # Регуляризация энтропией
    "max_grad_norm": 0.5,  # Обрезание градиентов ОБЯЗАТЕЛЬНО
    "target_kl": 0.1,      # Контроль KL-дивергенции
    "gradient_accumulation_steps": 4  # Для больших batch
}

Самая частая ошибка начинающих — завышенный learning rate. В SFT можно 1e-4. В RL — нет. Модель слишком чувствительна к изменениям. Маленькие шаги. Много итераций.

Ошибка №5: Плохие данные для reward model

Я аннотировал 1000 примеров сам. Потом 5000. Потом нанял фрилансеров. Качество? Ужасное. Несогласованное. Шумное.

Reward model учится на человеческих предпочтениях. Если предпочтения противоречивы, модель не сходится. Или сходится к ерунде.

1. Не экономьте на аннотаторах: 3 эксперта лучше 10 новичков
2. Четкие инструкции: «Что такое хороший ответ?» — прописывайте критерии
3. Контроль качества: Вставляйте тестовые примеры с известными ответами
4. Активное обучение: Аннотируйте сложные случаи, где reward model неуверена

Ошибка №6: Отсутствие правильной оценки

«Reward растет — значит, работает!» — говорил я. Пока не обнаружил, что reward model переобучилась на артефакты данных.

RL оптимизирует метрику. Если метрика кривая, оптимизирует кривую метрику. Надо оценивать на:

• Валидационном наборе (не из обучающих данных!)
• Человеческой оценке (регулярно, каждые 1000 шагов)
• Разнообразных задачах (не только тех, что в reward)
• Сравнении с бейзлайном (не забывайте, с чего начинали)

Используйте метрики из статьи про 90% бесполезного fine-tuning. Особенно обращайте внимание на degradation — когда модель становится хуже по одним метрикам, улучшая другие.

Ошибка №7: Неправильный выбор модели

Я начал с 7B модели. Потом перешел на 13B. Потом на 70B. Каждая ошибка дороже предыдущей.

В 2026 появились эффективные архитектуры вроде Gemma 3 4B, которые показывают результаты 13B моделей. Начинайте с них. Сэкономите на вычислениях, получите те же проблемы, но дешевле.

Практический план: как не повторить мои ошибки

4 Неделя 1-2: Подготовка (не пропускайте!)

1. Соберите качественные SFT данные (1000-5000 примеров)
2. Настройте SFT (2-3 эпохи, low learning rate)
3. Проверьте модель на валидации. Если плохо — больше SFT данных

5 Неделя 3-4: Reward model

1. Аннотируйте сравнения (5000-10000 пар)
2. Обучите reward model отдельно от policy
3. Протестируйте на held-out данных. Accuracy должна быть >70%

6 Неделя 5-8: RL Fine-tuning

1. Начните с маленького learning rate (1e-6)
2. Мониторьте KL-дивергенцию каждый шаг
3. Регулярно оценивайте на человеческих предпочтениях
4. Останавливайтесь раньше. RL переобучается быстрее, чем кажется

Что делать, если всё равно не работает

Бывает. RL — сложная штука. В 2026 есть альтернативы:

1. DPO (Direct Preference Optimization) — проще, стабильнее, но менее гибко
2. EAFT (Expert Adaptive Fine-Tuning) — как в статье про EAFT, хорошо для специфичных задач
3. Континуальное обучение — если боитесь катастрофического забывания
4. Просто больше SFT — иногда лучше, чем плохой RL

Мой итог после 6 месяцев: RL Fine-tuning — мощный инструмент. Но как молоток Тора. В неумелых руках ломает всё вокруг. Начинайте с малого. Экспериментируйте на маленьких моделях. Сохраняйте чекпоинты. И не верьте, что это просто.

Самый ценный совет? Прежде чем запускать RL на дорогой инфраструктуре, протестируйте pipeline на TinyLlama или Gemma 3 1B. Ошибки обойдутся в 100 раз дешевле. А опыт будет тем же.

И последнее: в 2026 появились инструменты автоматического подбора гиперпараметров для RL. Используйте их. Не угадывайте, как я. Шесть месяцев жизни — слишком высокая цена за «интуитивные настройки».