При Generative Retrieval (часть 1)
Предыстория
Весной 2024 года мне посчастливилось представлять свою научную работу на конференции https://www2024.thewebconf.org/ в Сингапуре. Это была моя первая конференция, эмоции от посещения были невероятные. Помню, как возвращаясь вечером в отель после одного из дней, звонил другу и убеждал его начать заниматься исследованиями в RecSys (увы, убедить не удалось).
Из множества событий конференции сейчас хотел бы выделить https://thewebconf2024-generative-ir.github.io/ от Martin de Rijke и его студентов, посвященный последним достижениям в области Generative Retrieval (GR). Тогда этот туториал был не особо популярным, в аудитории набиралось 5-6 человек. Я сам тогда скептически отнесся к идее генерировать ID объектов из каталога как текст, но за прошедшее время подход заметно эволюционировал, и, если посмотреть на последние работы на arXiv, RecSys-сообщество сейчас активно работает с GR.
Этот обзор я решил разделить на две части. В этой части я хочу разобрать, зачем нужен GR и в чём он выигрывает у двухбашенного подхода.
Во второй части я расскажу про проблемы, с которыми сталкивается GR (а то в этой части получается, что я его только хвалю), и сделаю выжимку статей, которые считаю ключевыми для этого направления, с кратким описанием их основных идей.
Немного про двухбашенные модели (дискриминативный подход)
Если вам нужно решать задачу отбора кандидатов для рекомендательных систем (англ. retrieval), и ваш сервис уже достаточно зрелый, чтобы использовать не только эвристики, то одним из следующих шагов для вас является применение нейросетевых двухбашенных моделей.
Базово такая модель устроена следующим образом: есть две независимые башни (пользовательская и айтемная). На вход первой башне идут различные признаки пользователя (часто берут N его последних взаимодействий). Айтемная башня получает на вход только признаки определенного объекта из каталога. Обе башни выдают на выход векторные представления в едином пространстве.
В проде этот подход работает по схеме "encode + retrieve". С помощью башен вы кодируете всю доступную информацию о пользователях и айтемах в вектора (шаг encode), а затем по вектору пользователя с помощью ANN находите те вектора айтемов, которые находятся к нему ближе всего (шаг retrieve). Эти объекты становятся кандидатами и проходят на следующую стадию рекомендательного пайплайна. В этом смысле двухбашенный подход является дискриминативным, так как модель не генерирует выдачу, а считает для каждого из айтемов его релевантность для данного пользователя.
Как работает генеративный подход?
В качестве альтернативы дискриминативной идее "encode + retrieve" появилась генеративная парадигма "encode + decode".
Основная идея GR в том, чтобы отказаться от подсчета релевантностей для всего каталога и обучать модель напрямую генерировать топ-k релевантных айтемов. Пользовательская башня (в этой схеме уже энкодер) остаётся без изменений, а айтемную башню заменяют на декодер, который принимает выход энкодера и генерирует последовательности кодов, соответствующие топ-k айтемам.
Осталось рассказать, как айтем переводится в последовательность для генерации. В статьях выделяют разные подходы (о них я напишу во второй части), а пока можно думать, что каждому айтему ставится в соответствие последовательность кодов (c1, c2, c3, c4), где каждый код принимает значение из фиксированного небольшого набора.
В такой схеме генерация топ-k кандидатов происходит с помощью beam search: декодер шаг за шагом предсказывает следующий код, сохраняя наиболее вероятные траектории.
(Из-за ограничение места телеграм порезал пост на две части)
