Bridging the Gap: Unpacking the Hidden Challenges in Knowledge Distillation for Online Ranking Systems
часть 2

Далее в статье описываются нюансы реализации. Авторы рассматривают:

1. Два возможных подхода к дистилляции:

🔹 Direct distillation — дистилляционный и основной лосс применяются к одному логиту в модели-ученике.
🔹 Auxiliary distillation — в модели-ученике есть два раздельных логита: для основного и для дистилляционного лосса. Схема показана на иллюстрации.

Второй вариант хорошо себя показал для задач предсказания LTV: в офлайн-замере RMSE он на 0,4% лучше direct-подхода. Это объясняется тем, что LTV — очень шумный и плохо откалиброванный таргет: большая модель выучивает биасы в данных и остаётся плохо откалиброванной. А потом передаёт свои биасы ученикам и приводит к зашумлению таргета. Поэтому лучше использовать два отдельных логита.

1. Какие таргеты стоит использовать для дистилляции. Все таргеты можно поделить на 3 группы: Engagement (например, клики), Satisfaction (лайки или досмотры) и остальные. Авторы отмечают, что лучше использовать только Engagement и Satisfaction — это даёт прирост +1,13% Satisfaction +0,39% Engagement относительно модели без дистилляции. Добавление дополнительных таргетов влияет на общие слои и ухудшает итоговые результаты.

2. Как комбинировать ученика и учителя. Архитектуры ученика и учителя похожи, главное отличие — глубина и ширина внутренних слоёв. Авторы провели онлайн-эксперименты для комбинаций, когда учитель больше ученика в 2 и в 4 раза: в 2 раза больший учитель позволил добиться прироста +0,42% Engagement и +0,34% Satisfaction относительно модели без дистилляции, в 4 раза больший учитель — +0,85% и +0,80% соответственно. Но эффект масштабирования не будет продолжаться бесконечно, а увеличивать учителя ещё сильнее сложно: во-первых, его нужно обучать на больших объёмах данных, за несколько месяцев. Во-вторых – поддерживать онлайн.

@RecSysChannel
Разбор подготовил ❣ Петр Зайдель

Bridging the Gap: Unpacking the Hidden Challenges in Knowledge Distillation for Online Ranking Systems
часть 1

Сегодняшнюю статью подготовила для RecSys 2024 команда Google. В ней они рассказали, как используют дистилляцию для ранжирования видео на главной YouTube: не шортсов, а именно роликов на главной странице.

Говоря о дистилляции в CV или NLP, обычно подразумевают классический пайплайн:

🔹 обучение большой модели на некотором объёме данных;
🔹 подготовка датасета из предсказаний большой модели;
🔹 обучение маленьких моделей с использованием предсказаний большой нейросети.

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

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

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

@RecSysChannel
Разбор подготовил ❣ Петр Зайдель

KuaiFormer: Transformer-Based Retrieval at Kuaishou

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

Kuaishou — суперпопулярный в Китае аналог TikTok: 400 млн активных пользователей, 600+ тыс RPS. В среднем один пользователь просматривает сотни видео в день.

Это первое внедрение в Kuaishou трансформера для кандидатогенерации. По их словам, — самое успешное внедрение за последние полгода.

Новая модель получила название KuaiFormer. Опираясь на историю взаимодействия пользователя с продуктом, она помогает предсказывать следующие положительные взаимодействия (в случае Kuaishou — это, например, лайк, полный просмотр видео и т. д.).

PinnerFormer, SASRec, Bert4Rec и другие похожие работы плохо улавливают разнообразные интересы пользователей, поскольку представляют их в виде одного вектора. Подходы MIND и ComiRec решают эту проблему: они умеют выделять целые кластеры интересов — так рекомендации получаются более разнообразными. KuaiFormer объединяет в себе оба подхода — она умеет справляться с главными проблемами реальных рекомендательных систем:

1. За счёт применения logQ-коррекции эффективно работает с большим каталогом айтемов при обучении.

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

3. Работает в реалтайме, но не требует большого объёма вычислительных ресурсов, несмотря на огромные RPS. Добиться этого помогает сворачивание последовательных кусков истории пользователя в один вектор с помощью bidirectional-трансформера: самые старые айтемы, которые были актуальны достаточно давно, сворачиваются в один вектор, а самые свежие — остаются нетронутыми. Схема того, как 256 токенов превращаются в 64, показана на рисунке.

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

Recommender Systems with Generative Retrieval

Современные модели для генерации кандидатов обычно строят так: обучают энкодеры (матричные разложения, трансформеры, модели dssm-like) для получения ембеддингов запроса (пользователя) и кандидата в одном пространстве. Далее по кандидатам строится ANN-индекс, в котором по ембеддингу запроса ищутся ближайшие по выбранной метрике кандидаты. Авторы предлагают отойти от такой схемы и научиться генерировать ID айтемов напрямую моделью, которую они обучают. Для этого предлагают использовать энкодер-декодер трансформенную модель на основе фреймворка T5X.

Остается вопрос, как закодировать айтемы для использования в трансформерной модели и как научиться напрямую предсказывать ID в декодере? Для этого предлагается использовать наработки из прошлой работы — Semantic IDs. Такие ID для описания айтемов обладают следующими свойствами:

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

В статье проводят эксперимент на датасете Amazon Product Reviews, состоящий из отзывов пользователей и описания товаров. Авторы используют три категории: Beauty, Sports and Outdoors и Toys and Games. Для валидации и тестирования используют схему leave-one-out, когда последний товар в истории каждого пользователя используется для тестирования, а предпоследний — для валидации. Такой подход много критиковали за возможные лики, но авторы используют его для сравнения с уже существующими результатами бейзлайнов.

Semantic IDs строили следующим образом: каждый товар описывался строкой из названия, цены, бренда и категории. Полученное предложение кодировали предобученной моделью Sentence-T5, получая эмбеддинг размерности 768. На этих ембеддингах обучали RQ-VAE с размерностями слоев 512, 256, 128, активацией ReLU и внутренним ембеддингом 32. Использовали три кодовые книги (codebooks) размером 256 ембеддингов. Для стабильности обучения их инициализировали центроидами кластеров k-means на первом батче. В результате каждый айтем описывает три ID, каждый из словаря размера 256. Для предотвращения коллизий добавляли еще один ID с порядковым номером.

Энкодер и декодер — трансформеры из четырёх слоев каждый с шестиголовым аттеншеном размерности 64, ReLU активацией, MLP на 1024 и размерностью входа 128. В словарь токенов добавили 1024 (256 × 4) токенов для кодбуков и 2000 токенов для пользователей. В итоге получилась модель на 13 миллионов параметров. Каждый пример в датасете выглядит так: hash(user_id) % 2000, , … -> . Во время инференса метод показывает значительный прирост качества (Recall@5, NDCG) по сравнению с бейзлайнами (SASRec, S3-Rec etc). При этом нужно учитывать, что у предложенной модели намного больше параметров, чем у остальных.

Авторы проводят ablation study для семантических ID — рассматривают варианты их замены на LSH и случайные ID. В обоих случаях semantic ID дает большой прирост и является важным компонентом подхода. Также проводится анализ возможности модели обобщаться на новые айтемы. Для этого из датасета выкидываются 5% товаров, а на инференсе задают отдельным гиперпараметром долю новых кандидатов в top-k (с совпадающими первыми тремя ID) и сравнивают свою модель с KNN.

Статья получилась во многом академичной, но она обращает внимание на важное направление, которое сейчас активно развивается. Похожий подход можно использовать для кодирования айтемов для LLM, чем, судя по разговорам на конференции, уже активно занимаются. Также можно отметить, что в статье не раскрывается часть важных вопросов: как добавлять новые айтемы и как переобучать RQ-VAE (в реальных сервисах часто меняется распределение контента), а также хотелось бы увидеть сравнение на более приближенных к реальным датасетах.

@RecSysChannel
Разбор подготовил ❣ Петр Зайдель

Joint Modeling of Search and Recommendations Via an Unified Contextual Recommender (UniCoRn)

В ещё одном интересном докладе с ACM RecSys разработчики из Netflix делятся опытом объединения моделей для персонализированного поиска и рекомендаций. В статье есть несколько предпосылок. Во-первых, обслуживать одну модель в продакшене проще, чем несколько. Во-вторых, качество объединённых моделей может быть выше.

Представленная архитектура обучается на трёх задачах: персональные рекомендации, персонализированный поиск и рекомендации к текущему видео. Для этого в нейросетевой ранкер подаётся поисковой запрос, ID текущей сущности (видео), ID пользователя, страна и ID задачи, которая решается (поиск или одно из ранжирований). Также в ранкер подаётся эмбеддинг истории действий пользователя, полученный так называемой "User Foundation Model", детали которой не раскрываются ни в тезисах с конференции, ни в ответе на прямой вопрос после устного доклада.

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

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

Результаты — рост на 7% в офлайн-качестве в поиске и на 10% — в рекомендациях. Это, по всей видимости, достигается за счёт регуляризации, возникающей при обучении на несколько задач и за счёт перехода к полной персонализации в поиске.

@RecSysChannel
Разбор подготовил ❣ Владимир Цепулин