Как работает DPOP (Dual Policy Optimization)? Когда он лучше DPO (работа с multi-turn, длинные ответы)?

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

DPOP (Dual Policy Optimization) — это улучшение классического DPO, разработанное для сценариев, где одно предпочтение между двумя завершёнными траекториями (ответами) недостаточно информативно. DPOP вводит двойную политику (текущую и референсную) и покадровый credit assignment, чтобы корректно распределять «награду» между шагами диалога или частями длинного ответа. Он превосходит DPO в multi-turn диалогах и задачах с длинными, логически связанными ответами, но требует значительно больше вычислительных ресурсов и аккуратной реализации.

2. Учитывает credit assignment

Основная проблема DPO в multi-turn — credit assignment: если первый шаг был неудачным, а второй скорректировал ситуацию, DPO накажет весь ответ, что сбивает модель. DPOP решает это через ретроспективное взвешивание:

• Для каждого промежуточного состояния вычисляется преимущество (advantage) относительно референсной политики.
• Шаги, которые привели к смене направления (например, переход от плохого ответа к хорошему), получают повышенный вес при обновлении.
• Используется off-policy correction — траектории собираются старой политикой, но градиент считается для текущей с учётом важности (importance sampling), как в TRPO/PPO, но без explicit reward.

Это особенно критично для длинных генераций, где модель может «выправиться» только на последних токенах: DPO считает всю последовательность проигрышной, DPOP — только её неудачную начальную часть.

Пример: диалог из трёх реплик. Пользователь: «Расскажи про NLP». Помощник: «(1) NLP — это...»; «(2) Основные задачи: ...»; «(3) А ты что хочешь узнать конкретно?». Если в ответе победителе реплика (3) была грубой, а в проигравшем вежливой, DPO ошибочно усилит грубость в (3) из-за того, что весь ответ считался выигрышным. DPOP выделит (3) как проблемный шаг и скорректирует только его, оставив (1)-(2) без изменений.

3. Лучше для multi-turn диалогов

C DPOP особенно эффективно в multi-turn диалогах, где каждая реплика зависит от предыдущей и ошибка может быть скомпенсирована позже. Например, ассистент на первом шаге дал неверный факт, а на втором исправился — DPO признает такую траекторию проигрышной (если первая версия хуже), хотя реальный пользователь может оценить исправление. DPOP оценит каждую реплику отдельно и усилит поведение «исправить ошибку», а не «избегать любых ошибок».

4. Сложнее в реализации

Хотя DPOP концептуально ближе к offline DPO, его реализация сопряжена с рядом технических сложностей:

• Хранение состояний — необходимо запоминать log-prob для каждого шага обеих политик (θ и ref) на каждой траектории. Это резко увеличивает объём данных (в K раз, где K — число шагов).
• Вычисление преимуществ — нужен механизм, похожий на GAIL или advantage estimation из RL, что требует дополнительных проходов и буфера.
• Гиперпараметры — вводятся пороги для маскировки (advantage threshold), веса для importance sampling, что делает настройку более чувствительной.
• Сходимость — при неправильном расписании off-policy correction градиенты могут расходиться, так как текущая политика быстро уходит от референсной.

Для практического использования рекомендуется начать с DPO и внедрять DPOP только если наблюдается деградация на long‑form или multi‑turn задачах. Существующие фреймворки (TRL, Axolotl) пока не имеют встроенной поддержки DPOP, требуется кастомная реализация на PyTorch с использованием техник из RLHF.

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

Задача: Обучить агента для двушагового диалога «Запрос → Промежуточный ответ → Финальный ответ» с использованием DPOP.

Инструменты:

• Python, PyTorch, библиотека Transformers (Hugging Face)
• Модель: GPT-2 или TinyLlama (для скорости)
• Датасет: синтетический, сгенерированный по правилам (например, 1000 траекторий с известным успехом/неуспехом на каждом шаге)

Шаги:

1. Создать синтетический сценарий: на шаге 1 модель должна дать нейтральный ответ, на шаге 2 — либо исправить ошибку, либо усугубить. Собрать пары предпочтений с разметкой пошагового качества.
2. Реализовать DPOPTrainer:
   • Хранит две модели: policy и ref_policy.
   • Принимает список шагов (token ids) с log-probs от ref.
   • Вычисляет loss как сумму log_policy/ref по шагам, взвешенных маской преимущества (например, 1 если шаг улучшает траекторию, -1 если ухудшает, 0 если нейтрально).
3. Запустить обучение (batch_size=4, lr=1e-5, 5 эпох). Сравнить с обычным DPO на тех же данных.
4. Оценить: замерить accuracy исправления ошибок на втором шаге (доля случаев, когда модель второй репликой корректирует первую) — у DPOP ожидается прирост на 10–20%.

Ожидаемый результат:

• Модель, обученная DPOP, на тестовых диалогах исправляет ошибки в 70% случаев против 45% у DPO.
• При этом качество первого шага остаётся на уровне DPO (не падает из-за ошибочного штрафа).

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

Навигация

• Предыдущий: 997
• Следующий: 999
• Индекс: 00. Индекс разборов zation)|999]]
• Индекс: 00. Индекс разборов