Решения

RLHF и DPO для LLM: пайплайн и лучшие практики

Задача страницы. Помочь выбрать между классическим RLHF (PPO + reward‑модель) и прямой оптимизацией по предпочтениям (DPO/IPO/ORPO/KTO), собрать предпочтения, настроить обучение и проверку качества, не «сломав» базовую модель.

Картина целиком: из чего состоит пайплайн

  1. SFT (базовая настройка по демо/инструкциям).
  2. Данные предпочтений (пары chosen vs rejected на одни и те же промпты). Классика — человеческая разметка; альтернативы — AI‑feedback/конституционные правила.
  3. Два пути обучения по предпочтениям:
    • RLHF: обучаем reward‑модель по парам (обычно Bradley‑Terry), затем оптимизируем политику PPO с KL‑штрафом к референсной модели.
    • DPO‑семейство: без Reward‑модели и без PPO — оптимизируем политику напрямую по парам (DPO/IPO/ORPO/KTO). Проще/стабильнее и дешевле по вычислениям.

Когда RLHF (PPO), а когда DPO/IPO/ORPO/KTO

  • Выберите RLHF (PPO), если нужно онлайн‑исследование и тонкая KL‑контроль к референсу, есть бюджет на сэмплинг и итеративные циклы (reward‑модель → PPO).
  • Выберите DPO/IPO/ORPO/KTO, если у вас офлайн пары предпочтений и важны простота/стабильность/стоимость:
    • DPO — проверенный «стандарт де‑факто».
    • IPO — снимает зависимость от предположений Bradley‑Terry, уменьшает риск переобучения.
    • ORPOбез референс‑модели, монолитная оптимизация odds‑ratio. 
    • KTO — семейство «human‑aware» лоссов (просмотровая теория), хорошо работает даже по бинарному сигналу «годно/не годно». 

Коротко: онлайн‑исследование и тонкий KL → RLHF (PPO); быстро/дёшево по офлайн‑парам → DPO/IPO/ORPO/KTO.

Данные предпочтений:
где брать и как разметить

  • Человеческая разметка. Формат: JSONL с полями chosen/rejected. Есть открытые корпуса (например, HH‑RLHF), удобные как шаблон формата.
  • AI‑feedback (RLAIF). «Конституционные» правила + самокритика/переписывание → предпочтения без ручной модерации на каждом примере. Хорошо дополняет человеческий корпус.
  • Советы по сбору:
    • фиксируйте промпты и версию базовой модели;
    • балансируйте «зоны риска» (безопасность, фактичность, приватность);
    • добавляйте hard negatives (нежелательные стили/паттерны).

Reward‑модель (если идёте в RLHF)

  • Классический лосс — Bradley‑Terry (логистическая регрессия на разности скорингов; по сути ранжирование по парам). Контроль качества — hold‑out по парам и стабильность калибровки.
  • Практически: в TRL есть RewardTrainer и примеры pipelines.

RLHF‑этап: PPO + KL к референсу

  • Схема: политика максimizирует награду reward‑модели при ограничении KL(π‖π_ref) — чтобы не уехать от исходной модели. Это как раз конфигурация InstructGPT.
  • Инструменты: PPOTrainer в TRL; в логах следите за rlhf_reward и отношением ratio (не должен «взрываться»).

Мини‑скелет (TRL):

				
					from trl import PPOTrainer, PPOConfig
# policy, ref_policy (frozen), reward_model — подготовлены заранее
config = PPOConfig(model_params={"torch_dtype": "bfloat16"})
trainer = PPOTrainer(config, policy, ref_policy, tokenizer=tok)
# цикл генерации → оценка reward_model → шаг PPO

				
			

DPO/IPO/ORPO/KTO: «без RL», прямо по парам

  • Идея DPO. Эквивалент RLHF‑целевой функции, но решается классификационным лоссом к парным предпочтениям + KL к референсу. Стабильнее и проще, чем PPO.
  • TRL DPOTrainer упрощает запуск (пара prompt, chosen, rejected).

Мини‑скелет (TRL):

				
					from trl import DPOTrainer, DPOConfig
cfg = DPOConfig(beta=0.1)  # «температура» DPO
trainer = DPOTrainer(model, ref_model, args=cfg, tokenizer=tok,
                     train_dataset=dpo_pairs)  # (prompt, chosen, rejected)
trainer.train()

				
			
  • IPO помогает, когда BT‑предположение ломает DPO (детерминированные предпочтения → переобучение).
  • ORPO сокращает этапы: без референса, «монолитная» оптимизация с odds‑ratio штрафом.
  • KTO — human‑aware лоссы из теории перспектив: зачастую не хуже DPO при более простом сигнале.
Off‑policy vs online: как организовать циклы
  • Off‑policy (офлайн пары). Идеальны для DPO/IPO/ORPO/KTO: тренируем «разом», быстро валидируем, не тратим бюджет на онлайн‑сэмплинг.
  • Online (итерации сэмплинг→разметка→обучение). Здесь выигрывает RLHF (PPO) — можно адаптировать данные предпочтений и держать поведение в KL‑окне к референсу.

Ресурсы и бюджет

  • GPU: для DPO/ORPO — один‑несколько GPU с 24–80 GB VRAM (контекст и батч решают). Для RLHF — добавьте GPU под reward‑модель и запас VRAM на генерацию/оценку.
  • Диск/I‑O: храните пары в tar‑шардах (WebDataset) с предвыборкой; логируйте источники и версии.
  • Режим аренды: офлайн «партии» удобно гонять на interruptible при агрессивном чекпоинтинге; онлайн‑RLHF и длительные циклы — On‑Demand. См. /solutions/cost-planner/

Проверка качества и безопасность

  • Оценка: метрики/плей‑оффы (MT‑Bench/Arena‑стили), перплексия на отложенном корпусе, регрессии по фактам/стилю. См. /solutions/llm-training/eval/
  • Безопасность: используйте конституционные правила и AI‑feedback, чтобы не сдвигать помощь в сторону «уклончивости»; добавляйте guardrails на инференсе.

/solutions/llm-inference/guardrails/, /solutions/security/

Частые ошибки и быстрые фиксы

  • «Уехали» от базы (развал стиля/фактов). Повышайте KL‑штраф (PPO/DPO), используйте близкий ref_model, добавляйте смешанный SFT‑микс.
  • Переобучение на парах (DPO). Перейдите на IPO либо усильте регуляризацию/температуру; проверьте разнообразие промптов.
  • Reward‑хаккинг (PPO). Валидируйте reward‑модель, добавляйте adversarial‑примеры, мониторьте разрыв «reward vs human‑eval».
  • Дорогой онлайн‑цикл. Перенесите большую часть в офлайн‑этап (DPO/ORPO/KTO), оставьте RLHF только для «доводки».

Полезные сниппеты

Формат пары (JSONL):

				
					{"prompt": "...", "chosen": "...", "rejected": "..."}
				
			

(Совместимо с DPO/ORPO/KTO и Reward‑тренингом TRL.)

Мини‑проверка качества пары:
— невалидные токены/галлюцинации в chosen → валидация фэйлит;
— оба ответа плохие → помечайте rejected корректно и выводите в «to‑fix» лист.