RLHF и DPO: выравнивание моделей
В 2026 статью про RLHF и DPO полезно подавать уже не как “старый метод против нового”, а как обзор preference optimization family. RLHF остаётся исторически важным полным пайплайном, но в практической работе для многих команд DPO стал более понятным default. Параллельно рядом появились RFT, KTO и другие способы оптимизировать модель по сигналу предпочтений или grader-ов.
Главная мысль: после SFT модель уже умеет отвечать. Preference optimization нужен, когда нужно улучшать не просто формат, а какой ответ модель выбирает как лучший.
1. RLHF остаётся фундаментом, но не всегда practical default
Исторически RLHF важен, потому что именно он показал, как переводить человеческие предпочтения в улучшение модели.
Классический pipeline:
SFT;- сбор preference data;
- reward model;
- RL optimization, часто через PPO.
Этот подход остаётся концептуально сильным, но operationally дорогим:
- сложнее инфраструктура;
- больше moving parts;
- reward model itself needs quality control;
- RL stage нестабилен и чувствителен к настройке.
Поэтому для многих teams full RLHF уже не выглядит первым practical шагом.
2. DPO стал гораздо более рабочим baseline
Direct Preference Optimization сильно упростил историю.
Он полезен потому, что:
- не требует отдельной reward model;
- не требует full RL loop;
- легче дебажится;
- лучше вписывается в обычный training stack.
Именно поэтому в 2026 DPO часто воспринимается как default preference optimization path, если у вас есть chosen/rejected data и вы хотите quality lift после SFT.
3. Что preference optimization реально улучшает
Обычно это не “знания”, а:
- helpfulness;
- tone preference;
- refusal behavior;
- stylistic selection;
- relative answer quality;
- ranking among multiple plausible outputs.
То есть DPO/RLHF особенно полезны там, где one correct answer отсутствует, но human preference clearly exists.
4. Почему SFT всё ещё идёт раньше
Preference optimization почти всегда строится на уже нормальном SFT baseline.
Если базовая модель:
- плохо следует инструкциям;
- ломает формат;
- не понимает задачу,
то RLHF/DPO не спасут её магически. Они начнут оптимизировать слабый base behavior.
Поэтому practical order обычно такой:
prompt baseline
-> SFT
-> preference optimization
5. RLHF, DPO и RFT решают разные уровни задачи
RLHF
Полезен, когда:
- есть серьёзная research/infra capacity;
- нужен полный control over reward process;
- задача оправдывает сложный alignment stack.
DPO
Полезен, когда:
- есть preference pairs;
- хочется simpler pipeline;
- нужен practical quality lift after SFT.
RFT
Полезен, когда:
- есть grader/reward;
- задача reasoning-heavy;
- plain preference pairs уже не лучший signal.
Именно поэтому правильнее думать не “RLHF или DPO”, а “какой reward/preference signal у нас вообще есть”.
6. Главный bottleneck — данные предпочтений
Самая болезненная часть не в названии метода, а в качестве preference signal.
Нужны данные, где:
- chosen действительно лучше rejected;
- разница осмысленная, а не случайная;
- signal соответствует product goals;
- предпочтения consistent across annotators or graders.
Плохие preference data ломают любой метод:
- RLHF начнёт учиться на плохом reward;
- DPO начнёт тянуть модель к не тем паттернам.
7. Operational tradeoff в 2026
Здоровая practical рамка такая:
RLHF— max flexibility, max complexity;DPO— strong quality/cost/simplicity tradeoff;RFT— сильный путь для reasoning, но требует grader discipline.
Поэтому DPO и родственные методы часто выигрывают не потому, что RLHF “устарел”, а потому, что они лучше совпадают с реальными constraints небольших и средних teams.
8. Как выбирать
Выбирайте по сигналу и по задаче:
| У вас есть | Чаще выбрать |
|---|---|
| Хорошие supervised targets | SFT |
| Chosen/rejected pairs | DPO |
| Reward/grader for complex reasoning | RFT |
| Много infra и сложный alignment research path | RLHF |
Плюсы
- Preference optimization поднимает quality beyond plain SFT
- DPO даёт более простой и practical путь, чем полный RLHF
- RFT открывает более сильные reasoning optimization loops
- В 2026 это уже family of methods, а не один монолитный подход
Минусы
- Нужны хорошие preference или reward signals
- Без сильного SFT baseline методы теряют смысл
- RLHF operationally тяжёлый и сложный в поддержке
- Плохо собранные preference data быстро ведут к оптимизации не того поведения