Рекомендательные системы

Context-Aware Recommendations

YouTube в 2016 году оптимизировал рекомендации на watch time. Пользователи стали проводить больше времени на платформе, но в опросах говорили: «чувствую, что теряю время». В 2019 команда опубликовала работу о переходе на multi-task learning - совместную оптимизацию watch time, satisfaction и engagement. Контекстуальность и multi-objective стали стандартом индустрии.

**Netflix Content Scheduling** - разный контент рекомендуется в будни vs выходные; сезонные коллекции (летние блокбастеры, новогодние фильмы)
**Foursquare/Swarm** - time+location aware рекомендации мест; модель «утро у офиса = кофе»
**SASRec в Amazon** - self-attentive session рекомендации; стандартная baseline в e-commerce sequential rec

Предварительные знания

Коллаборативная фильтрация и матрица оценок «пользователь-товар»
Взаимодействия признаков и эмбеддинги из нейросетевых рекомендательных моделей
Дилемма explore-exploit, лежащая в основе бандитов

Factorization Machines и приход контекста

В 2010 году Steffen Rendle представил Factorization Machines - модель, которая обучает попарные взаимодействия между всеми признаками через общие латентные векторы. Прорыв был практическим: контекст вроде времени суток, локации, устройства или погоды можно добавить как обычные признаки рядом с id пользователя и товара, и модель всё равно оценит надёжные веса взаимодействий, даже если большинство комбинаций признаков ни разу не встречались. Это сделало контекст полноценным сигналом, а не дополнением, и превратило задачу предсказания оценки в общее предсказание на основе признаков. Factorization Machines лежат в основе значительной части context-aware рекомендаций и напрямую связаны с contextual bandits, где система также балансирует использование известных предпочтений и исследование нового контекста.

Временной контекст: сезонность и затухание интереса

Netflix анализировал паттерны просмотра и обнаружил: в будние вечера пользователи смотрят короткие эпизоды (20-30 мин), в выходные - полнометражные фильмы и многосерийные драмы. Один и тот же пользователь хочет разный контент в зависимости от времени. Контекстно-независимая рекомендательная система это слепая зона.

**Seasonality vs Short-term patterns:** сезонность (лето → пляжные фильмы, декабрь → праздничный контент) - долгосрочный тренд. Circadian patterns (утро → подкасты, вечер → сериалы) - краткосрочный. Модель должна захватывать оба уровня через разные features или multi-scale архитектуру.

Зачем кодировать час дня через sin/cos, а не как число 0-23?

Location-Aware: гео-контекст и локальная релевантность

Foursquare в 2012 году обнаружил: пользователь в 8:00 утром рядом со своим офисом с большой вероятностью ищет кофе. Тот же пользователь в 19:00 в том же районе - скорее всего ищет бар или ресторан. Локация и время вместе создают контекст, который ни одна из переменных в одиночку не описывает.

**Home vs Office vs Traveling:** один пользователь имеет несколько «локальных контекстов». Кластеризация посещённых мест (k-means по геокоординатам) позволяет определить: дом, офис, спортзал, «путешествие». Контент для каждого кластера отличается.

Почему location-aware рекомендации требуют учёта ВРЕМЕНИ, а не только координат?

Session-Based Recommendations: моделирование краткосрочного намерения

Классический collaborative filtering использует всю историю пользователя. Но намерение пользователя **внутри сессии** меняется: зашёл за кроссовками - через 5 кликов смотрит носки и шорты. Session-based рекомендации моделируют текущий intent через последовательность действий в сессии, игнорируя долгосрочную историю.

Модель	Архитектура	Преимущество	Недостаток
GRU4Rec (2016)	GRU	Эффективна для коротких сессий	Плохо захватывает дальние зависимости
SASRec (2018)	Transformer (causal)	Дальние зависимости, параллельное обучение	Больше параметров, медленнее
BERT4Rec (2019)	BERT (bidirectional)	Контекст в обе стороны	Нельзя использовать напрямую в online inference
FMLP-Rec (2022)	MLP + FFT	Быстрее Transformer, конкурентное качество	Менее изучена

Чем session-based рекомендации отличаются от классического collaborative filtering?

Multi-Task Learning: совместная оптимизация нескольких целей

YouTube в 2019 году обнаружил: оптимизация только на клики (CTR) продвигала кликбейт. Оптимизация только на время просмотра - длинные скучные видео. **Multi-task learning** решает это: совместная оптимизация CTR + watch time + like probability + «не жалею о просмотре» одновременно дала контент, который пользователи реально хотели видеть.

**Задачи при MTL:** CTR (кликабельность), CVR (конверсия), watch time, skip rate, like/share/save. Каждая задача имеет свои labels и loss. Итоговый скоринг - взвешенная комбинация всех задач: `score = w1*CTR + w2*watch_time - w3*skip_rate`. Веса подбираются A/B тестами.

Multi-task learning усложняет систему без реального выигрыша - лучше сделать несколько специализированных моделей.

MTL улучшает качество каждой задачи через shared representations: сигнал от одной задачи помогает другой. MMOE позволяет задачам иметь разные веса экспертов - задачи-конфликты получают разные специализированные пути. Один inference vs N независимых моделей = меньше latency.

Shared lower layers в MTL работают как regularization - редкие сигналы (likes) получают больше обучающего сигнала через shared features с частыми событиями (clicks). N отдельных моделей не имеют этого эффекта.

YouTube перешёл на multi-task learning (CTR + watch time + satisfaction). Почему оптимизация только CTR недостаточна?