Трансформерная персонализация: какие события действительно нужны
История содержит клики, покупки, запросы и пропуски. Они отличаются по частоте, надёжности и зависимости от прежних рекомендаций. Доклад разбирает выбор событий, кодирование истории и постепенное подключение трансформера к существующему ранжированию.
Видео · на русском
Тайны трансформерной персонализации — Кирилл Хрыльченко, ЯндексКирилл Хрыльченко · Опубликовано: 13 августа 2024 г.
Исходный доклад · Открыть оригинал
История пользователя — не однородный текст
Запрос человек формулирует явно, клик может быть случайным, а показ во многом определяется самой рекомендательной системой. В музыке пропуск трека важен; аналогичное отсутствие действия в магазине может означать совсем другое. Поэтому состав истории выбирают под продукт.
В Маркете оказались полезны поисковые запросы из другого сервиса. В Музыке собственных сигналов было достаточно. Перенос событий между продуктами помогает не во всех задачах одинаково.
02:00 — фрагмент докладаДлина и свежесть зависят от поверхности
Для похожих товаров особенно важны недавние действия. Для главной страницы и поиска нового полезнее долговременные интересы. Увеличение длины истории даёт убывающую прибавку, поэтому размер нужно сопоставлять со стоимостью.
В описанных экспериментах простой выбор последних событий часто работал лучше ручных квот на лайки и просмотры. Для очень длинной истории могут потребоваться другие способы отбора.
Эксперимент с длиной истории пользователя.
Источник: Кадр из докладаКонтент не отменяет идентификаторы
Событие включает описание объекта, его ID и тип реакции. Обучаемые векторы ID сохраняют поведенческую информацию, которую текст не выражает. В примере доклада объединение контента и идентификаторов даёт больше, чем каждый источник по отдельности.
Позиции удобно отсчитывать от конца истории: тогда ближайшее действие имеет одинаковый смысл при разной длине последовательности. Время и тип взаимодействия также должны отличать события друг от друга.
Кодирование текстового содержания.
Источник: Кадр из докладаНачать можно с признака для текущего ранжировщика
Вместо немедленной замены всего стека можно заранее считать представления пользователя и объекта, а их близость передавать существующему бустингу. Это упрощает запуск, но задерживает поступление свежих действий.
Один скаляр становится ограничением: сложная история сжимается до одного числа. В докладе этот вопрос отделён от выбора самого трансформера — важно не только научиться представлению, но и передать его полезную информацию дальше.
15:00 — фрагмент доклада