EBR в рекомендательных системах: перспективы мультизадачности
Статья о любопытном подходе к EBR (Embedding-based retrieval) для учёта нескольких интересов пользователя. Авторы не просто растят diversity и fairness, но и утверждают, что увеличивают общее качество. В статье это показано на примере SASRec, но в теории подход сработает для любых трансформеров над историей пользователя.

Суть — в кластеризации исходного множества айтемов на подмножества, в которые на этапе retrieval ходят отдельными kNN. При этом в каждом кластере обучают отдельный таск и рассматривают задачу в целом как multi-tasking learning (MTL).

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

В экспериментах авторы проводили кластеризацию через K-means на Word2Vec, но также можно использовать уже имеющееся in-house разбиение документов на категории.

Три подхода к MTL
В статье описано три варианта реализации multi-tasking learning. Первый подход — наивный, где на вход добавляется ещё один обучаемый вектор. Работает это не очень хорошо — у модели не получается выучить взаимодействия между фичами.

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

Третий подход — MoE (Mixture of Experts), где используется несколько специализированных сетей — экспертов — для решения одной задачи. Он работает лучше, чем наивный multi-tasking, но хуже, чем покомпонентное умножение, и получается дороже по времени обучения.

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

@RecSysChannel

Разбор подготовил ❣ Артём Мышкин

Трансформеры в рекомендательных системах
Высокая гетерогенность фичей мешает использовать трансформеры в рекомендательных системах. Ресёрчеры из Google поделились статьёй, где предложили решение: модифицированный attention-слой позволил уловить связи, важные для предсказания итогового таргета. В тестах подход показал рост ключевых метрик (клики, покупки) — например, +0,4% по сравнению с DCN.

Подготовка фичей
На вход модели подаются cat- и dense-фичи. Cat-фичи обрабатываются стандартно (для них строятся обучаемые эмбеддинги), а с dense-фичами поступают чуть сложнее: их нормализуют, конкатенируют, применяют линейное преобразование, а потом сплитуют по D — внутренней размерности трансформера. Так фичей становится меньше.

Heterogeneous Attention Layer
Здесь матрицы query, key и value (QKV) считают отдельно для каждой фичи. Чтобы вычислить итоговый вектор для токена, вектора со всех голов, отвечающих фичам, конкатенируются и умножаются на матрицы.

Затем данные идут на Feed Forward-слой (FFN) с активацией GELU. Полученный вектор и будет выходом attention-слоя. Количество операций по сравнению с обычным трансформером не растёт, увеличивается лишь число параметров.

Hiformer
Чтобы уловить сложные взаимодействия, систему снова модифицируют — создают одну большую матрицу фичей. Затем конкатенируют все фичи каждой головы, умножают их на матрицу и получают модифицированные вектора. Благодаря этому получается выявить новые закономерности и связи, в т. ч. между composite-фичами и task-эмбеддингами.

Оптимизация
С большой матрицей трансформер становится тяжёлым с точки зрения latency — его нужно оптимизировать. Авторы используют низкоранговое разложение и прунинг последнего слоя. В первом случаем мы уменьшаем сложность за счёт разложения большой матрицы на две матрицы меньшего ранга.

Прунинг выполняется на последнем слое, где можно обучать таргет по task-эмбеддингам. Обычно итоговых задач намного меньше, чем фичей, что снижает сложность матричных умножений.

@RecSysChannel
Разбор подготовила ❣ Маргарита Мишустина

Улучшаем Sequential Recommendation с помощью Guided Diffusion, часть 1
Поговорим о моделях, генерирующих следующий айтем на основе предыдущих взаимодействий пользователя — это может быть трек в плейлисте, видео, товар и т. д. По словам авторов статьи, SR обычно работает в парадигме learning-to-classify — получает позитивы, выполняет сэмплинг негативов, дополняет ими выборку и обучается. При этом неизвестно, видел ли юзер полученные айтемы и считает ли их нерелевантными. Альтернатива — использовать диффузию и перейти к learning-to-generate.

Пользователь примерно понимает, что хочет найти. Этот гипотетический айтем авторы называют oracle. Не факт, что он существует — тогда человек выберет что-то близкое из предложенных вариантов. Но именно «оракула» должна сгенерировать Guided Diffusion-модель.

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

Авторы описывают три подхода к диффузии:
— DDPM — оптимизация нижней вариационной оценки логарифмов правдоподобия наблюдаемых таргетов, которая сводится к оптимизации дивергенции Кульбака — Лейблера. Основной метод, использующийся в статье.
— Непосредственное рассмотрение двух марковских цепочек — если расписать score-функцию, этот подход эквивалентен певрому.
— Проведение аналогии между СДУ и диффузионной моделью актуально для генеративных моделей, т. к. позволяет получить логарифм нулевого распределения на таргетах и замерять им качество на этапе инфиренса.

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

@RecSysChannel
Разбор подготовил ❣ Сергей Макеев

Улучшаем раннюю стадию ранжирования рекламы
Сегодня — статья о ранжировании рекламы. Как и в других рекомендательных системах, в нём 3 стадии:

• Retrieval — отбор объявлений из баз, необязательно с помощью ML (~миллионы объявлений).
• Ранняя стадия ранжирования (~тысячи объявлений).
• Финальное ранжирование (~сотни объявлений).

Value считают на обоих этапах ранжирования, а итоговую оценку получают в финале. Учитывают:
• ставку рекламодателя;
• кликовые/конверсионные прогнозы;
• качество рекламы, оно же фидбек. Например, клик по крестику говорит, что объявление нерелевантно.

Проблемы ранней стадии ранжирования

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

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

Решение

Фреймворк с мультитаргет-архитектурой. В нём есть shared-часть — она выдаёт эмбеддинги, которые идут в 3 головы:
• Первая предсказывает CTR.
• Во второй происходит дистилляция — главная фишка статьи. Модель с нижних стадий обучают на разметке моделей с финальной стадии ранжирования
• Третья — Consolidated Quality Score — учится на целевые действия кроме кликов: результаты опросов, долгие конверсии и др. Для каждого баннера считается их вероятность, а таргет берётся из финальной стадии.

Финальная модель обучается на сумму loss’ов — важно аккуратно подбирать веса, чтобы ничего не просело.

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

Оценивают симулятором — он считает вероятный топ в оффлайне. Так получают golden-сет, с которым сравнивают результаты прода.

@RecSysChannel
Разбор подготовила ❣ Маргарита Мишустина

⏰ Добавляем таймстэмпы в модели Sequential Recommendation
Статья от Amazon о том, как передать время события в трансформер — в основном на примере BERT4Rec. Для этого есть сложившиеся подходы, и авторы предлагают 2 метода: близкий к «классике» и оригинальный.

Основная идея — мультиразмерный таймстэмп: время события делят на 5 представлений: год, месяц, неделя, день недели и час дня, прибавляя их комбинацию к эмбеддингам событий на входе трансформера. Получаются категории, отвечающие за периодичность. Значения нормализуют до ≤ 1. Кроме исторических событий берут таймстэмп текущего запроса (query time) — в BERT4Rec его просто добавляют к маске.

Projection-based подход
В таймстэмпе два вида полезной информации: время и его отличие от других событий в истории. Модель должна «видеть» временные паттерны, учитывая разницу между таймстэмпами. Чтобы достичь этого, вычисляют векторы, используя ядро — функцию от разности таймстэмпов. Оно хорошо подходит для трансформера, т. к. в attention эмбеддинги сравниваются через скалярное произведение, смоделированное ядром.

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

Embedding-based подход
Компоненты мультиразмерного таймстэмпа рассматривают как категориальные фичи, ограниченные по количеству значений. Для каждой фичи ведут таблицу эмбеддингов — 24 эмбеддинга для часа дня, 7 для дней недели и т. д. Их конкатенируют и получают финальный эмбеддинг таймстэмпа.

По словам авторов, embedding-based метод работает лучше, когда данных много, т. к. модель может выучить нужную структуру эмбеддингов сама, без ограничения конкретным методом вроде ядра. Но в экспериментах много спорного: в 2 датасетах из 4 нет информации о часовых поясах; для больших и маленьких датасетов используют разные размерности эмбеддингов, а также странным образом делят данные на трейн, валидацию и тест — без полного таймсплита, отчего результаты могут быть некорректными.

Однако сама идея разбиения таймстэмпа интересная — хочется провести свой эксперимент 🤓

@RecSysChannel
Разбор подготовил ❣ Денис Бурштеин

LiRank: как LinkedIn строит модели ранжирования, часть 1
Авторы рассказывают, как строили систему ранжирования: комбинировали известные архитектуры и оптимизировали их, чтобы сократить время обучения и улучшить метрики. Результат: +0,5% сессий пользователей в ленте, +1,76% квалифицированных заявок на работу, +4,3% CTR объявлений.

Предлагают:
— 2 версии MTL для предсказания engagement и CTR;
— Residual DCN с attention-схемой;
— изотонический калибровочный слой, который учится вместе с моделью;
…и другое. В двух словах расскажем здесь, а подробности ищите в статье.

Ранжирование
Point-wise подход используют для оценки вероятности лайков, комментариев и репостов в паре пост — юзер. С помощью TF-модели с MTL-архитектурой вероятности комбинируют, группируя задачи в тасках.

Предсказание CTR
В модели с 3 башнями по-разному группируют взаимодействия, ориентируясь на цели рекламодателей: кто-то считает прибыльными лайки и комментарии, а кто-то — только клики. В каждой из голов используются свои interaction-блоки (MLP, DCNv2), loss тоже отбирают в зависимости от задачи.

Residual DCN — расширение DCNv2
Матрицу весов заменяют 2 тонкими матрицами — это похоже на low-rank аппроксимацию — и уменьшают размерность входных фич. Число параметров сокращается почти без потери качества, а модель запускается на CPU. В неё добавляют attention-схему, где исходное low-rank отображение дублируется в виде 3 матриц: Query, Key и Value. Их перемножают и добавляют residual connection от Value, умноженной на исходный вектор. Параллельно используется стандартный low-rank DCN. Когда тюнят температуру, получается ещё лучше.

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

И это не всё… Расскажем о других оптимизациях в продолжении 😃

@RecSysChannel
Разбор подготовил ❣ Влад Додонов

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

Dense Gating и LMLP
Авторы статьи сделали MLP шире, и она стала работать лучше, а ещё — внедрили в архитектуру контроль над информацией с помощью Gate Net, который эффективнее всего оказалось применять к скрытым слоям. Сначала вход прогоняют через линейный слой с SiLU (swish) активацией. Затем выход умножают на выход, трансформированный линейным слоем с сигмоидой.

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

Чтобы ещё лучше обезопаситься от катастрофического забывания, в дополнение к весам из предыдущей модели авторы берут веса самой первой cold start-модели, комбинируя их, и здесь тоже используют гессиан.

Member History Modeling
Для моделирования истории пользователя используется транзакт, представленный командой Pinterest. В трансформере над историей эмбеддинги айтемов конкатенируются с эмбеддингами экшнов и эмбеддингом айтема, скорящегося в данный момент времени (early fusion). Из трансформера забирают макс-пуллинговый токен, а также 5 последних токенов — так же, как в транзакте.

Explore and Exploit
Чтобы разрешить дилемму explore/exploit, в последний слой добавляют байесовскую линейную регрессию. Оттуда получают веса и используют их в томпсоновском сэмплировании, чтобы предлагать кандидатов с учётом explore/exploit tradeoff. Подробнее схему не раскрывают, но указывают, что она помогла получить +0,6% активных юзеров на в тестах.

Это всё на сегодня! А в финальной части обзора обсудим ещё 4 интересные оптимизации.

@RecSysChannel
Разбор подготовил ❣ Влад Додонов

LiRank: как LinkedIn строит модели ранжирования, часть 3
Финал обзора статьи от LinkedIn об оптимизациях в рекомендательных системах. Поехали!

Wide Popularity Features
Random effect модель нужна, чтобы к обычной модели с миллиардами параметров добавить связи, указывающие на происходящее в данный момент. Модель дообучается раз в 8 часов и выдаёт самую актуальную информацию: айтемы с высокой волатильностью, коротким сроком жизни и т. д. Итоговый предикт — это сигмоида от суммы логитов двух моделей — основной и random effect.

Dwell Time Modeling
Просто брать время на просмотр поста (dwell time) и использовать его при расчёте вероятностей оказалось неэффективно: данные шумные, а статические пороги не адаптируются под предпочтения пользователя и смещают оценку.

Решение — бинарный классификатор, который предсказывает, будет ли юзер сидеть на посте больше, чем, к примеру, 90% пользователей. Оценка даётся на основе позиции в ленте, типа контента, платформы и т. д. Айтемы кластеризуют и проводят отбор внутри. Авторы утверждают, что при ежедневном обновлении получается +0,2% сессий и +1% dwell time.

Model Dictionary Compression
Экономить память помогает QR-хешинг — большие матрицы с категориальными sparse-фичами высокого разрешения декомпозируют в маленькие. 4 миллиарда строк сжимают в 1000 раз, ещё около 1000 получают из «остатков». Remainder-матрица позволяет сохранить уникальность эмбеддингов в разрезе ID и повысить их репрезентативность.

Embedding Table Quantization
Post-training квантизацию делают не по min—max, а по middle—max. Есть две причины:
— эмбеддинги имеют нормальное распределение, поэтому больше всего значений в центре;
— диапазон значений эмбеддингов — от -128 до 127, что решает проблему дополнительного кода.

Это была эпическая серия! Если вам мало оптимизаций от LinkedIn, в оригинальной статье есть ещё часть про масштабирование обучения и эксперименты — читайте и делитесь впечатлениями :) А нам пора двигаться дальше.

@RecSysChannel
Разбор подготовил ❣ Влад Додонов

🤖 HyperFormer от DeepMind: выучить выразительные представления для sparse-фичей
Авторы статьи рассказывают, как улавливать высокоуровневые взаимосвязи между категориальными фичами (они же — sparse-фичи) и благодаря этому выучивать информативные эмбеддинги в том числе и для редких значений.

Например, в выборке много москвичей, но всего несколько жителей Нью-Йорка. Таких редких значений категориальных признаков в датасетах может быть много — возникает т. н. тяжёлый хвост признаков. Современные нейросети справляются с ним плохо — для решения этой проблемы и придуман HyperFormer.

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

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

Гиперформер
Модель, которая выучивает информативные эмбеддинги sparse-фичей. Dense-фичи гиперформер не обрабатывает — этим, как и финальными предсказаниями, занимаются upstream-модели.

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

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

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

@RecSysChannel
Разбор подготовил ❣ Сергей Лямаев

Кластерная якорная регуляризация в рекомендательных системах
Обучение на логах юзеров может приводить к popularity bias. Мы рекомендуем айтемы, человек их смотрит, это попадает в логи и оттуда — в дальнейшее обучение. В итоге «богатый становится богаче». Известные способы борьбы с этим ухудшают перфоманс популярных айтемов, что тоже плохо. Ресёрчеры из DeepMind предлагают свой метод, Cluster Anchor Regularization, и применяют его для YouTube Shorts.

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

Кластеры генерируют энкодером с учётом метаданных и контента. 2-миллиардный индекс мапится в 256-размерные эмбеддинги. Они фиксированы, считаются один раз и нужны лишь для построения графа, который и будет кластеризоваться. Об архитектуре энкодера авторы не пишут.

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

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

На втором этапе то же самое происходит с target-айтемами, но обновляется уже не представление кластера, а векторы target’ов. Результаты обоих этапов добавляем в основной loss. Благодаря этому получается «эффект якоря»: популярные айтемы «тянут» за собой непопулярные.

@RecSysChannel
Разбор подготовил ❣ Сергей Макеев

Законы масштабирования в больших моделях последовательных рекомендаций

Авторы из WeChat и Tencent разбирались, работают ли законы масштабирования нейросетей для рекомендательных систем. Главный вопрос — есть ли улучшение качества рекомендаций при увеличении количества обучаемых параметров? Короткий ответ — да.

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

В работе об SR авторы масштабировали декодер трансформера и вносили изменения в стратегии обучения, чтобы получить закон масштабирования для рекомендательных систем:
— Для слоёв в начале последовательности декодер-блоков применяли больший dropout-rate, а для слоёв на вершине — меньший, что позволило избежать оверфита.
— Сначала обучались с Adam до полной сходимости, а потом брали чекпоинты, с которых продолжали обучение при помощи SGD, потому что несмотря на лучшую сходимость, итоговый минимум у Adam получался хуже.

Историю взаимодействий форматировали как хронологическую последовательность ID айтемов. То есть задача решалась так же, как в случае с языковыми моделями. Исследователи не брали другую информацию (например, текст айтема), так как хотели изучить работу закона с т. з. поведения пользователя. Модели увеличивали до 0,8B параметров, сравнивая эффекты в разных диапазонах размеров.

Оказалось, закон масштабирования работает для SR-моделей даже в сценариях с ограниченным количеством данных. Авторы показали преимущество больших моделей и на сложных задачах рекомендаций: cold start, long tail, определяли траектории пользователей и смотрели, что происходит при мультидоменном трансфере — во всех случаях масштабирование улучшало результаты.

@RecSysChannel
Разбор подготовил ❣ Артем Матвеев

LiNR: Model Based Neural Retrieval on GPUs at LinkedIn

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

В LiNR построение индекса рассматривается как процесс обучения, из-за чего и представления объектов, и веса, с помощью которых происходит формирование выдачи, интегрируются в одну модель. Отличительным аспектом статьи является использование честного KNN для формирования выдачи вместо широко распространенного ANN (Approximate Nearest Neighbor). В работе также описывается способ интегрирования фильтраций, основанных на логических правилах, в стадию скоринга объектов индекса, что позволяет повысить качество финальной выдачи.

В статье авторы предлагают три версии алгоритма для генерации кандидатов:
— Скоринг всех объектов с последующей фильтрацией. Первое предложенное решение, которое может работать неоптимально, особенно в случаях с большим процентом отфильтрованных объектов (low-pass-rate сценарии).
— Предварительная фильтрация объектов с последующим скорингом. Улучшенная версия первого подхода, которая решает его проблемы и увеличивает метрики качества выдачи.
— Дополнительное улучшение второго подхода с использованием квантизации. Предлагается использовать две стадии выбора кандидатов после фильтрации: первичный выбор подмножества объектов на основе квантизованных представлений и более гранулярная фильтрация оставшихся объектов для получения финальной выдачи.

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

— С оффлайн инференсом и обновлением модели вы теряете свежих кандидатов, а следовательно, и качество. Real-time обновление LiNR увеличило качество всего пайплайна на 6%.
— Предварительная фильтрация, в отличие от пост-фильтрации, которая может тратить слоты кандидатов на нерелевантные объекты, помогает повысить качество модели.
— По умолчанию TF или PyTorch не приспособлены для реализации retrieval-моделей, из-за чего такие решения будут довольно медленными без дополнительных оптимизаций.
— Имплементация собственного CUDA-ядра для второй и третьей версий модели позволила получить значительное преимущество в скорости (к сожалению, авторы не поделились кодом самого ядра).

@RecSysChannel
Разбор подготовил ❣ Владимир Байкалов

Multi-objective Learning to Rank by Model Distillation

Свежая статья от Airbnb о том, как совместить дистилляцию и мультитаск-обучение. Задача ранжирования заключается не только в предсказании конверсии, но и её исхода. Например, человек может вернуть заказ или оставить отзыв. Также он может обратиться в сервис, если возникнут проблемы. Это важно в контексте долгосрочного роста платформы.

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

Решение — end-to-end multi-objective, совмещенный с дистилляцией. Важно, чтобы при этом инференс и обучение не занимали слишком много времени. Модели объединяют через дистилляцию, после чего добавляют механизм самодистилляции — он даёт лучшую воспроизводимость и помогает побороть cold start при переобучении. Так у авторов получилось решать ad-hoc бизнес-задачи, связанные с недифференцированными функционалами.

Лоссы с разных подзадач объединяют с помощью скаляризации. Отдельные лейблы, возникающие из-за того, что задач несколько, агрегируются в один, т. н. софт-лейбл. При такой постановке происходит шеринг нижних слоев (возможно, не только их). Это оказывает положительное влияние на задачи с разреженными данными, но может работать плохо, если между задачами слабая корреляция — так часто бывает в маркетплейсах. Даже несмотря на это, по словам авторов, выгода от шеринга есть.

Подбирать веса, с которыми суммируются лоссы, при таком подходе дорого, плюс есть риск переобучения. Если подбирать веса каждый раз, когда обновляется какая-то модель — затраты вырастут. Избавиться от онлайн-тюнинга весов и сбалансировать обучение на цели с разным количеством данных помогает дистилляция, а дальнейшая самодистилляция закрепляет и усиливает эффект. Исследователи получили рост метрики nDCG на 1,1% в офлайн-экспериментах и +0,37% бронирований (CVR) в A/B-тестах.

@RecSysChannel
Разбор подготовил ❣ Сергей Макеев

Diffusion Model for Slate Recommendation

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

Ранжирование объектов — важная подзадача в рамках рекомендации слейтов, и для её решения авторы статьи используют отдельные модели, но в данной работе концентрируются на retrieval-части, рассказывая, чем хороши диффузионки. В качестве примеров похожих работ они ссылаются на 2 статьи от Google, за 2015 и 2019 год, где для решения аналогичной задачи используется RL. Проблема в том, что айтемы в слейте являются в RL-подходе независимыми событиями. Это упрощает обучение, но такой подход не совсем корректен, так как зависимость между соседними айтемами в слейте все же есть, что приводит к проблемам с качеством генерации.

Исследователи из Spotify утверждают, что генеративный подход (а именно — диффузионные модели) могут работать лучше, чем RL-like подходы. Диффузионки могут сделать слейт разнообразнее благодаря неявному пониманию, что айтемы не должны быть слишком похожими. Также авторы замечают, что диффузионные модели помогают бороться с popularity bias’ом и включать в подборки менее очевидные треки даже без явного обучения под эту задачу. Также авторы делают conditioning на весь контекст — профиль и запрос пользователя. Опционально в контекст добавляют отдельные айтемы из слейта, которые уже были предсказаны.

По словам исследователей, такой метод даёт значимо лучшие результаты, чем RL и другие привычные решения в сфере рекомендаций слейтов.

@RecSysChannel
Разбор подготовил ❣ Владимир Байкалов

Efficient Retrieval with Learned Similarities

Сегодня обсуждаем статью от Microsoft и Meta* об эффективном retrieval с обучаемыми функциями близости. Исторически нишу функций близости в retrieval занимали косинусные близости — скалярные произведения над нормализованными векторами. Но в последнее время популярность стали набирать обучаемые функции близости. Например, они допускают сопоставление одному запросу нескольких эмбеддингов, чтобы лучше улавливать редкие и противоречивые интересы пользователей. Также можно использовать нейросети над векторами запроса и векторами айтема и делать многие другие интересные вещи. Однако с эффективностью этих решений есть проблемы.

Чтобы повысить эффективность обучаемых функций близости, в статье используют Mixture-of-Logits как универсальный аппроксиматор и предлагают методы его ускорения для получения достаточно точной аппроксимации топ-k соседей. В экспериментах подход авторов обгоняет бейслайны почти в 100 раз по времени работы и при этом достигает 99% полноты/рекола.

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

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

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

@RecSysChannel
Разбор подготовил ❣ Сергей Макеев

—
Meta признана экстремистской организацией, а Facebook и Instagram запрещены на территории РФ