Сравнение DPO и RLHF: обучение по предпочтениям

Сравнение DPO и RLHF: обучение по предпочтениям сводится к одной развилке. Классический RLHF строит отдельную модель награды, которая оценивает ответы, и уже её сигнал двигает политику через обучение с подкреплением. DPO обходится без этого шага: пара «предпочтительный / отвергнутый ответ» попадает прямо в цель обучения, и политика сама несёт в себе функцию награды. Дальше разберём механику, учебный пример и границы применимости.

Основной механизм и его пределы простыми словами

Классический RLHF в изложении блога Hugging Face начинается с уже предобученной языковой модели. Дальше идёт генерация данных для модели награды — именно через неё человеческие предпочтения попадают в систему. Цель модели награды — принимать последовательность текста и возвращать скалярную оценку, которая численно выражает предпочтение человека. Скалярность здесь принципиальна: существующие алгоритмы обучения с подкреплением подключаются к такому сигналу без переделки.

Разметку блог Hugging Face описывает так: люди ранжируют сгенерированные моделью ответы. Прямая скалярная оценка каждого текста на практике плохо работает — у разных людей разные шкалы, оценки получаются несогласованными и шумными. Ранжирование сравнивает выходы нескольких моделей и даёт лучше регуляризованный набор данных. Один из успешных способов — попарное сравнение ответов двух моделей на одном и том же запросе, а система Elo превращает эти пары в относительный рейтинг. Разные способы ранжирования нормализуются в скалярный сигнал награды.

Статья о DPO на arXiv описывает ту же классическую схему как три фазы: сначала supervised fine-tuning, затем сэмплирование предпочтений и обучение награды, затем оптимизация через обучение с подкреплением. Модель награды там параметризуется как отдельная сеть, которую часто инициализируют из SFT-модели и дополняют линейным слоем поверх последнего слоя трансформера — этот слой выдаёт одно скалярное предсказание. Чтобы снизить дисперсию, награды нормализуют.

DPO меняет точку приложения усилия. Документация TRL на Hugging Face формулирует так: модель обучается на парах завершений к одному и тому же запросу, где одно завершение предпочтительнее другого. Цель напрямую расширяет разрыв между логарифмическими правдоподобиями предпочтительного и отвергнутого завершений относительно опорной модели, и явная модель награды для этого не нужна. Документация отдельно отмечает, что на практике при таком обучении часто снижается правдоподобие отвергнутых завершений.

Предел у обеих схем общий и лежит в природе сигнала. Предпочтение — сравнительная величина. Оно говорит, какой из двух ответов лучше по размеченному критерию, и ничего не говорит о том, верен ли лучший ответ фактически. Модель награды в классическом RLHF наследует это ограничение: она обучена воспроизводить ранжирование, а ранжирование опирается на суждение разметчика. DPO наследует его напрямую, потому что работает с теми же парами.

Второй предел — узость измеренного. Авторы DPO в статье на arXiv сообщают, что их эксперименты показывают как минимум сопоставимую эффективность с существующими методами, включая RLHF на основе PPO, для задач модуляции тональности, суммаризации и диалога на моделях до 6B параметров. Это утверждение про конкретный набор задач и конкретный масштаб. Переносить его на любую задачу и любой размер модели нельзя.

Третий предел — незакрытое пространство решений. Блог Hugging Face прямо пишет, что общего ответа на вопрос, какая модель лучше подходит как стартовая точка для RLHF, нет, и что пространство вариантов обучения RLHF исследовано не полностью. Тот же источник отмечает, что для моделей награды ни одна базовая модель не считается однозначно лучшим выбором.

Четвёртый предел касается терминологии. RLHF — широкий термин, охватывающий разные алгоритмы и разные конфигурации. DPO тоже относят к обучению по предпочтениям. Сравнение «DPO против RLHF» на практике означает сравнение DPO с классической схемой вида предпочтения → модель награды → обновление политики через RL, чаще всего с PPO в роли алгоритма подкрепления. Сводить это к противостоянию человека и алгоритма некорректно: человек участвует в обеих схемах, различается маршрут, по которому его суждение доходит до весов модели.

Пятый предел — цена ошибки в разметке. Если оба ответа в паре неверны, разметка всё равно назначит одного предпочтительным. Схема обучения воспримет это как сигнал и сдвинет политику в сторону выбранного варианта. Ни классический RLHF, ни DPO не защищены от такого входа на уровне алгоритма.

Учебный вход, артефакт и эталон проверки

Ниже — учебный пример разметки. Это иллюстрация формата. Для обучения трёх пар недостаточно; запуск здесь не проводился. Значения условные и приведены как вход для разбора.

Пара 1
prompt:  Когда откроется филиал?
chosen:  Время ещё не объявлено
rejected: Завтра в 09:00

Пара 2
prompt:  17+26?
chosen:  43
rejected: 44

Пара 3
prompt:  Куда вернуть R-2?
chosen:  В источнике нет адреса возврата
rejected: Лесная 10

Что здесь проверяется. В первой паре предпочтительный ответ сообщает об отсутствии сведений, отвергнутый называет конкретное время, которого в источнике нет. Во второй паре предпочтительный ответ арифметически верен, отвергнутый отличается на единицу. В третьей паре предпочтительный ответ признаёт отсутствие адреса, отвергнутый подставляет конкретный адрес.

Эталон проверки — отложенный пример, который в разметку не попадал. Возьмём запрос «18+26?» и правильный ответ 44. Ответ 44 на этом отложенном запросе удовлетворяет конкретной проверке. Одного совпадения недостаточно, чтобы установить перенос арифметического правила на другие числа. Ответ 43 на запрос 18+26 означает ошибку на этом отложенном примере. По одному ответу нельзя определить её причину или характер усвоенного правила. Добавьте другие числа и повторите проверку на заранее заданном наборе.

Тот же эталон работает для третьей пары. Отложенный запрос про возврат другого товара при отсутствии адреса должен получить ответ об отсутствии сведений. Ответ с конкретным адресом без подтверждения в источнике ошибочен на этом примере. Для проверки поведения добавьте другие запросы с отсутствующими адресами и отдельные случаи, где адрес явно указан в источнике.

Дальше — два потока на одном и том же наборе пар.

Классический RLHF. Модель награды учится оценивать новые ответы, которых в разметке не было. Она получает запрос и ответ и выдаёт скаляр. Затем алгоритм обучения с подкреплением использует этот скаляр как сигнал и меняет политику. Разметчик здесь влияет на веса опосредованно: через обученную модель награды. Промежуточное звено можно проверить отдельно — посмотреть, какие оценки она ставит на отложенных примерах.

DPO. Предпочтительный и отвергнутый ответы используются прямо в цели обучения. Отдельная классическая модель награды в этом потоке не обучается. Документация TRL описывает практическую сторону так: каждый пример содержит запрос, предпочтительное завершение и отвергнутое завершение, а тренер токенизирует вход штатным токенизатором модели. В формуле участвуют политика, опорная модель, сигмоида и параметр, управляющий силой сигнала предпочтения.

Различается маршрут передачи сигнала предпочтения. В обоих потоках суждение разметчика задаёт направление сдвига. В классическом RLHF между суждением и весами стоит обученная модель награды. В DPO этого звена нет, и суждение доходит до политики короче.

Что даёт учебный артефакт читателю. Он показывает, что формат входа у двух схем общий: запрос плюс два ответа. Он показывает, где искать эталон проверки: на отложенных примерах того же типа. И он показывает главный риск: разметка может быть структурно корректной и фактически неверной одновременно.

Структурная корректность и фактическая правильность

Разведём два свойства, которые легко перепутать.

Структурная корректность — это соответствие формы. Пример содержит запрос, предпочтительное завершение и отвергнутое завершение. Документация TRL указывает, что DPO требует набора предпочтений и что тренер совместим со стандартным и разговорным форматами; при разговорном формате шаблон чата применяется автоматически. Если набор в другом виде, его предобрабатывают к ожидаемому формату. Соответствие формату делает набор допустимым входом для тренера. Успешность запуска также зависит от конфигурации и ресурсов; качество результата проверяется отдельно.

Фактическая правильность — это соответствие действительности. Предпочтительный ответ может быть выбран разметчиком по критерию тона, длины, вежливости или соответствия регламенту. Этот выбор описывает предпочтение по размеченному критерию. Утверждение о факте из него не следует.

Разберём на парах. В паре 2 предпочтительный ответ 43 фактически верен для запроса 17+26. Здесь структурная корректность и фактическая правильность совпали. В паре 1 предпочтительный ответ сообщает об отсутствии сведений. Это фактически верное поведение при отсутствии данных, и оно одновременно предпочтительно по критерию честности. В паре 3 то же самое: признание пробела верно и предпочтительно.

Теперь подставим контрпример. Пусть оба ответа на запрос фактически неверны: один называет время 09:00, другой — на следующее утро, а филиал не открывается вовсе. Если разметчик вынужденно назначит один preferred, неверный ответ станет положительным сигналом. Такую пару следует вернуть на исправление или исключить по правилам разметки. Совпадение формата не делает её эталоном.

Второй контрпример — стиль. Пусть предпочтительный ответ написан аккуратнее и подробнее, а оба ответа содержат одну и ту же фактическую ошибку. Разметка выберет более аккуратный. Схема обучения воспримет это как сигнал о форме и сдвинет политику в сторону формы. Этот пример не подтверждает улучшения фактической правильности; её нужно проверить отдельными вопросами с известными ответами.

Отсюда практическое правило проверки. Метрики обучения, которые показывает тренер, относятся к структурной стороне. Документация TRL перечисляет, например, среднюю неявную награду для предпочтительного завершения и долю немаскированных токенов, где предсказание модели с максимальной вероятностью совпало с токеном предпочтительного завершения. Обе величины измеряют согласие с разметкой. Фактическую правильность они не измеряют.

Фактическую сторону проверяют отдельным набором с известными правильными ответами, который в обучении не участвовал. Для арифметики это примеры с проверяемым результатом. Для ответов об отсутствии данных это запросы, где правильное поведение — сообщить о пробеле. Такой набор строится до обучения и не меняется после.

Ещё одна деталь, которую стоит держать в голове. Документация TRL отдельно описывает случай, когда модель является смесью экспертов: тогда логируется вспомогательная потеря балансировки, и только при ненулевом коэффициенте. Это техническая метрика конкретной архитектуры, и к оценке качества ответов она отношения не имеет.

Первоисточники и границы переноса

Внешние утверждения в этом разборе опираются на конкретные документы. Перечислим их и то, что именно каждый подтверждает.

Документация TRL на Hugging Face описывает тренер DPO и формат данных. Она подтверждает: DPO обучает модель на парах завершений к одному запросу, расширяет разрыв между правдоподобиями относительно опорной модели, обходится без явной модели награды, а на практике подавляет правдоподобие отвергнутых завершений. Там же приведён пример обучения модели Qwen 3 0.6B на наборе UltraFeedback. Эти сведения относятся к библиотеке TRL и её тренеру.

Блог Hugging Face про RLHF описывает классический конвейер: стартовая предобученная модель, генерация данных для модели награды, ранжирование ответов людьми, нормализация ранжирований в скалярный сигнал. Там же приведены примеры масштабов из чужих работ: OpenAI использовала уменьшенную версию GPT-3 для InstructGPT, Anthropic — трансформеры от 10 миллионов до 52 миллиардов параметров, DeepMind документировала использование модели Gopher на 280 миллиардов параметров. Это исторические сведения о конкретных проектах, и переносить их на другие модели нельзя.

Статья о DPO на arXiv формулирует трёхфазную схему классического RLHF и описывает переход к прямой оптимизации по предпочтениям. Авторы сообщают о сопоставимой эффективности с методами, включая RLHF на основе PPO, на задачах модуляции тональности, суммаризации и диалога при моделях до 6B параметров. Это результат конкретных экспериментов.

Материал IBM про обучение с подкреплением для языковых моделей объясняет, зачем этап вообще нужен. Предобучение даёт широкий запас знаний, обучение с учителем помогает следовать инструкциям, и ни один из этих этапов полностью не решает задачу качества в открытой генерации. Два ответа могут быть грамматически верны, и один при этом полезнее, короче или лучше соответствует задаче пользователя. Обучение с подкреплением даёт способ оптимизировать такие трудно формализуемые свойства напрямую через сигналы предпочтения.

Материал AWS про RLHF описывает четыре стадии и приводит пример с переводом: машинный перевод может быть технически корректным и звучать неестественно, а дополнительное обучение улучшает естественность. Там же приведён пример с погодой: два ответа сообщают одно и то же, и второй звучит естественнее и даёт больше контекста.

Блог AWS про настройку Amazon Nova через DPO описывает практический конвейер: выбор рецепта настройки, отправка запроса в контрольную плоскость SageMaker AI, выделение инфраструктуры, оркестрация распределённого обучения, автоматический вывод кластера из эксплуатации по завершении. Там же сказано, что настройка выполняется в двух вариантах — параметро-эффективном и полном, в зависимости от объёма данных и соображений стоимости, а развёртывание готовой модели идёт на Amazon Bedrock. В этом материале приведён пример с настройкой Nova Micro под вызовы инструментов на наборе nvidia/When2Call и указаны приросты: 81% по F1 и до 42% по метрикам ROUGE. Эти числа относятся к конкретной задаче, конкретному набору и конкретной модели. Переносить их на другие задачи нельзя.

Отдельно про инфраструктуру. Тот же материал называет требование к квоте для своего сценария: минимум две инстанса p5.48xlarge с восемью GPU NVIDIA H100 каждый, с возможностью масштабирования. Это условие конкретного рецепта у конкретного провайдера. Оно не описывает требования DPO как метода и не переносится на другие платформы.

Правило переноса простое. Число, версия, порт или ограничение принадлежат тому продукту, о котором сказано. Прирост F1 из материала AWS описывает настройку Nova Micro под вызовы инструментов. Требование к инстансам описывает рецепт SageMaker. Результат по трём задачам из статьи на arXiv описывает эксперименты авторов на моделях до 6B. Смешивать эти числа в одно утверждение о методе нельзя.

Случай, где подход не решает задачу

Возьмём задачу, в которой нужен факт, отсутствующий в обучающих данных. Пусть внутренняя база знаний компании не содержит сведений о дате открытия нового филиала, и модель должна отвечать на вопросы сотрудников.

Разметим пары так, как в учебном примере: предпочтительный ответ сообщает, что время не объявлено, отвергнутый называет конкретную дату. Обучим политику любым из двух способов. Что произойдёт.

В классическом RLHF модель награды обучают предпочитать обоснованный ответ об отсутствии сведений. Её оценки затем используют в RL-обновлении политики. Даст ли итоговая модель нужный ответ о другом филиале, можно узнать только из отложенной проверки.

В DPO те же пары входят прямо в цель оптимизации. Сопоставимый результат на новом вопросе служит целью проверки; эти три пары его не гарантируют.

Теперь изменим условие. Пусть база знаний обновилась, и дата открытия появилась. Ни одна из двух схем не узнает об этом из своих обучающих пар: в разметке не было примеров с корректной датой. Обновление внешней базы само по себе не меняет веса обученной политики. Чтобы новая дата участвовала в ответе, системе нужен доступ к актуальному источнику либо отдельное обновление модели и проверка его результата.

Второй случай — арифметика. В учебных парах предпочтительным ответом на 17+26 было 43. На отложенном запросе 18+26 правильный ответ 44. Если разметка содержала только примеры с результатом 43, схема может закрепить связь между формой записи и конкретным числом. Ответ 43 вместо 44 выявит ошибку на этом отложенном примере. Чтобы оценить перенос арифметического правила, проверьте несколько заранее подготовленных заданий и отдельно разберите причины ошибок.

Третий случай — оба ответа неверны. Принудительный выбор меньшего зла создаёт ошибочный положительный сигнал в обеих схемах. До обучения такую пару возвращают на исправление: предпочтительный ответ должен удовлетворять заявленному критерию.

Четвёртый случай — конфликт критериев. Пусть в одной части пар предпочтение отдавалось краткости, в другой — подробности с оговорками. Модель награды в классической схеме усреднит эти сигналы в одну скалярную функцию и может дать противоречивые оценки на новых примерах. DPO сдвинет политику в сторону обоих типов ответов с разной силой. В обоих случаях требуется отложенная проверка каждого критерия: по одному виду обучающих пар итоговое поведение не выводится.

Общий вывод по этим случаям: обучение по предпочтениям решает задачу выбора между вариантами, когда верный вариант присутствует в разметке или выводится из неё. Задачи, где нужен факт вне разметки, обновление знания или проверяемое вычисление, требуют отдельных механизмов.

Как принять решение для своей задачи

Ниже — таблица вопросов к проекту. Она описывает устройство двух потоков, а результат будущего обучения остаётся неизвестным.

Для учебного набора сначала зафиксируйте основание каждого выбора. У первой пары во входе нет времени открытия, у третьей нет адреса; конкретные время и адрес в rejected поэтому не подтверждены. У второй пары основание арифметическое: сложение даёт43. Смешивать эти критерии в одно неопределённое предпочтение полезности не нужно: при разборе ошибки должно быть понятно, какое правило нарушено.

Затем подготовьте проверку до выбора метода. Запрос18+26 с эталоном44 не должен попадать в учебные пары. Для вопросов без адреса добавьте ситуацию, где адрес присутствует в источнике: иначе постоянный отказ может выглядеть успешным на одних только пустых источниках. Эти дополнительные задания являются предложением для будущей проверки, результатов по ним здесь нет.

Наконец, запишите, что повлияло на решение команды: нужен ли отдельный оценщик, какие данные доступны, какой результат будет считаться приемлемым. Название алгоритма само по себе не заменяет этих условий. Три полные пары позволяют понять маршрут сигнала и проверить разметку вручную; оценка рабочего решения потребует более представительного набора.

Частые вопросы

DPO vs RLHF — в чём главное отличие?

Классический RLHF строит отдельную модель награды, которая оценивает ответы, и уже её скалярный сигнал двигает политику через обучение с подкреплением. DPO использует пару «предпочтительный / отвергнутый ответ» прямо в цели обучения и обходится без отдельной классической модели награды. Маршрут от суждения разметчика до весов модели в DPO короче. Обе схемы относятся к обучению по предпочтениям.

DPO vs PPO RLHF — что сравнивают на практике?

Сравнивают DPO с классической схемой, в которой обучение с подкреплением выполняется алгоритмом PPO. Авторы DPO в статье на arXiv сообщают о сопоставимой эффективности с методами, включая RLHF на основе PPO, на задачах модуляции тональности, суммаризации и диалога при моделях до 6B параметров. Это результат конкретных экспериментов, и он не означает превосходства на любой задаче. RLHF остаётся широким термином, охватывающим разные алгоритмы.

SFT vs DPO vs RLHF — как эти этапы соотносятся?

Статья о DPO на arXiv описывает классический конвейер как три фазы: обучение с учителем, затем сэмплирование предпочтений и обучение награды, затем оптимизация через обучение с подкреплением. Обучение с учителем даёт модели базовую способность следовать инструкциям на качественных примерах. Оба варианта обучения по предпочтениям идут после него и уточняют поведение на парах ответов. DPO заменяет вторую и третью фазы одной целью обучения.

Нужна ли отдельная модель награды для DPO?

Документация TRL указывает, что цель DPO напрямую расширяет разрыв между правдоподобиями предпочтительного и отвергнутого завершений относительно опорной модели, и явная модель награды для этого не требуется. Опорная модель при этом присутствует в формуле. В классическом RLHF модель награды обучается отдельно и служит источником сигнала для алгоритма подкрепления.

Можно ли обучить DPO на своём наборе пар?

Документация TRL указывает, что DPO требует набора предпочтений и что тренер совместим со стандартным и разговорным форматами. Набор в другом виде предобрабатывают к ожидаемому формату. Каждый пример содержит запрос, предпочтительное завершение и отвергнутое завершение. Качество результата определяется тем, насколько разметка отражает нужный критерий и насколько отложенная проверка подтверждает перенос на новые запросы.