Что такое прямая оптимизация предпочтений (DPO)? Более простая альтернатива RLHF

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

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

Прямая оптимизация предпочтений: определение, границы и назначение

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

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

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

Пять этапов работы прямой оптимизации предпочтений

Диаграмма представляет собой краткую причинно-следственную схему прямой оптимизации предпочтений, а не утверждение о том, что в каждой реализации используются пять программных компонентов. В одних системах этапы объединены, в других — повторяются циклически. Схема остается полезной, поскольку требует, чтобы за каждым изменением информации или полномочий были закреплены ответственный, входные данные, результат и способ проверки.

1. Сбор запросов с ранжированными парами ответов: входные данные и предпосылки прямой оптимизации предпочтений

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

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

2. Оценка относительного предпочтения политики: представление или решение в прямой оптимизации предпочтений

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

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

3. Сопоставление с эталонной политикой: отличительное преобразование при прямой оптимизации предпочтений

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

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

4. Прямое обновление модели на основе целевой функции предпочтений: ограничения и проверка при прямой оптимизации предпочтений

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

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

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

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

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

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

Разбор примера прямой оптимизации предпочтений

Если есть два ответа, DPO повышает относительную вероятность предпочтительного ответа, не запуская онлайн-цикл оптимизации вознаграждения.

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

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

Прямая оптимизация предпочтений и наиболее распространённое упрощение

Прямую оптимизацию предпочтений часто сводят к конвейерам RLHF, в которых сначала обучают модель вознаграждения, а затем оптимизируют политику с помощью обучения с подкреплением. Такое упрощение стирает именно ту границу, которая определяет это понятие. Из-за этого покупатели могут сравнивать несопоставимые продукты, исследователи — преувеличивать то, что показывает эксперимент, а специалисты по эксплуатации — отслеживать не тот показатель после развертывания.

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

Почему прямая оптимизация предпочтений важна для современных систем ИИ

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

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

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

Какие преимущества может дать прямая оптимизация предпочтений

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

Преимущества следует описывать через решения и измеримые показатели. «Более интеллектуальный» — не критерий приемки для прямой оптимизации предпочтений. Полезная целевая метрика может, например, задавать частоту ошибок на сложных случаях, способность восстановить корректный ответ при противоречивых данных, стоимость на заданном процентиле запросов, время проверки человеком, калибровку или долю действий, не выходящих за установленный предел полномочий.

Сбой, определяющий прямую оптимизацию предпочтений

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

Контрольная мера для прямой оптимизации предпочтений полезна только в том случае, если срабатывает до того, как возникнут значительные или необратимые последствия. Определите самый ранний наблюдаемый признак сбоя, установите пороговое значение или правило, назначьте ответственного и проверьте возможность восстановления. В зависимости от сценария восстановления может потребоваться воздержаться от ответа, перейти на более простую систему, запросить дополнительные данные, передать вопрос человеку, откатить модель или полностью остановить действие.

План оценки прямой оптимизации предпочтений

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

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

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

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

Что следует выяснить перед внедрением прямой оптимизации предпочтений

• Цель: Какое измеримое узкое место призвана устранить прямая оптимизация предпочтений?
• Механизм: На каком из пяти этапов происходит характерное преобразование?
• Базовый уровень: Каковы результаты сравнения с конвейерами RLHF, в которых сначала обучают модель вознаграждения, а затем оптимизируют политику с помощью обучения с подкреплением, или с другой более простой альтернативой?
• Доказательства: Какие типичные, сложные, состязательные случаи и случаи для отдельных подгрупп проверялись?
• Эксплуатация: Какие затраты на задержку, память, вычисления, энергию, обслуживание и проверку возникают при масштабировании?
• Риск: Как команда будет выявлять ситуации, когда данные о предпочтениях вознаграждают стиль, многословие или предвзятость аннотаторов, а не фактическую правильность?
• Восстановление: Может ли система воздержаться от ответа, перейти на резервный вариант, выполнить откат или передать вопрос специалисту до того, как будет причинен вред?

Основные источники для изучения прямой оптимизации предпочтений

В качестве авторитетных отправных точек для изучения части стека ИИ, связанной с прямой оптимизацией предпочтений, можно использовать Attention Is All You Need, исследовательскую статью о LoRA и работу о прямой оптимизации предпочтений. Читайте их вместе с документацией по конкретной используемой модели, набору данных, оборудованию и юрисдикции. Общий источник может описать механизм, но пригодность конкретной реализации можно установить только на основе данных, относящихся к условиям ее развертывания.

Что важно помнить о прямой оптимизации предпочтений

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

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