Интересное что-то

OneRec разбор (часть 3): алайнмент

Прямо как по заказу к моменту, когда руки дошли написать пост про алайнмент в OneRec, вышла ещё одна статья от тех же авторов: OneLoc. В ней описывается в целом всё тот же OneRec (хотя в деталях различий немало), но применённый к поверхности Local Life Service. В OneRec Technical Report упоминалась выкатка на эту поверхность с точно такими же результатами AB-теста, так что это на самом деле один и тот же релиз. Разберём сегодня на примере всех 3 работ (OneLoc, OneRec и OneRec Technical Report) моё видение алайнмента генеративных рекомендательных моделей.

Я выделю следующие возможные подходы:
- Next token / item prediction (то есть отсутствие алайнмента)
- Supervised Fine-Tuning (SFT)
- Conditioning (например Prompt-based или P-tuning)
- Псевдо RL (например DPO)
- RL (например PPO и GRPO)

NTP
LLM обучается предсказывать следующий токен в последовательностях текстов (NTP), в результате чего выучивают "модель мира" (а точнее модель того, как люди пишут тексты). Мы в рекомендациях адаптируем эту идею, реализуя next item prediction. При этом практически все рекомендательные модели либо получают на вход только позитивные взаимодейтсвия (как SASRec или TIGER), либо на вход получают всё, а предсказывают только позитивы (как PinnerFormer или Actions...). Такие модели не выучивают логгирующую политику, их модель мира упрощённая. В Technical Report модель предобучают на exposed items, их базовая модель предобучена именно на NTP.

SFT
Часть цепочек можно назвать "хорошими" и научить модель такие цепочки генерировать. В LLM такие цепочки можно составлять с помощью разметчиков. В рекомендациях обычно используют логи прошлой системы и фидбэк пользователей. Pretrain первой версии OneRec это именно SFT - NTP loss там повесили только на high-quality sessions. Также в обеих версиях статьи используют SFT как дополнительный лосс на этапе алайнмента.

Conditioning
Похож на SFT, но здесь мы не доучиваем модель только на "хорошие" цепочки, вместо этого мы на них "обуславливаемся". В теории это очень мощный инструмент, который даёт возможность генерировать хоршие выдачи разного вида. Например можно поставить счётчик числа лайков перед сессией и уже в райнтайме генерировать "сессию, в которой будет 3 лайка". Такой подход используется в недавно вышедшем PinRec. Нам идея кажется перспективной и мы пробуем разные вариации.

Псевдо RL и RL
Эта группа методов позволяет напрямую оптимизировать выдачи, которые понравятся пользователям, а не иммитировать подмножество хороших выдач прошлой системы. Большая проблема рекомендаций - вы не можете показать 2 разные выдачи одному и тому же пользователю в один момент времени и узнать его реакцию на обе. Это приводит к необходимости обучения reward model. По аналогии с LLM такая модель оценивает, насколько хорошо ответ подойдёт на запрос. Имея reward model, можно сэмплировать различные выдачи для пользователя и либо составлять из них пары для DPO, либо оценивать value для RL алгоритмов.

Логичный вопрос: раз уж у нас есть reward model, зачем нам DPO? Я вижу 2 главных причины: он стабильнее и менее требовательный к "онлайновости" обучения. Основные RL алгоритмы, применяющиеся в генеративных моделях, учатся on-policy (то есть на своём собственном фидбэке). При обучении на логах другой системы приходтся вносить корректировки, которые всё равно работают плохо. В идеале модель должна обновлять веса сразу после получения фидбэка. На практике это недостижимо, поэтому чем "онлайновее" обучение, тем лучше.

Похоже, что 3 внедрения появлялись именно в таком порядке по мере усложнения инфраструктуры:
- OneLoc использует обычный DPO, обучаясь offline.
- OneRec использует Iterative DPO - модель чаще обновляет веса во время дообучения.
- OneRec Technical Report использует свою модификацию GRPO, обучаясь с минутными задержками.

63 views16:39