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

Feature Engineering для рекомендаций

Цели урока

Разделить user features на сессионные и исторические и понять их динамику
Строить item features с дебиасингом position bias
Создавать cross features для линейных и нелинейных моделей
Использовать learned embeddings как dense признаки для ranking

Netflix в 2009 году выдал приз $1M за улучшение рекомендаций на 10%. Победившая команда Bell использовала не лучший алгоритм, а лучший feature engineering: временные паттерны, признаки взаимодействий, контекст просмотра. Сегодня Netflix оценивает, что хорошие признаки дают +40% к качеству по сравнению с базовыми.

**Netflix** - temporal features (время суток, день недели) улучшают предсказание лучше смены алгоритма
**Google Play** - Deep & Cross Network для автоматического feature crossing миллионов признаков
**Alibaba** - DIN (Deep Interest Network) использует attention over user history embedding

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

One-hot encoding и разреженные векторы
Embeddings и dot product
Линейные и логистические модели

Factorization Machines и эпоха feature engineering

До глубокого обучения точность рекомендаций добывалась в основном из признаков, построенных вручную: feature crosses, перемножающие атрибуты пользователя и товара, бакетизированные счётчики и выученные embeddings для id высокой кардинальности. Беда в том, что число явных crosses взрывается, и большинство из них вообще не встречаются в данных, поэтому их веса невозможно обучить. В 2010 году Steffen Rendle представил Factorization Machines, которые дают каждому признаку латентный вектор и моделируют каждое попарное взаимодействие как скалярное произведение этих векторов. Это позволило модели оценивать силу взаимодействия даже для пар признаков, которые ни разу не встречаются вместе в обучении, решая проблему разреженности, калечившую самодельные crosses. Factorization Machines выиграли несколько соревнований Kaggle и KDD Cup и напрямую вдохновили более поздние гибриды вроде DeepFM, где FM-компонент и глубокая сеть делят одни и те же embeddings.

User Features: сессионные и исторические

Ranking модель видит пользователя как вектор признаков. Качество рекомендаций напрямую определяется тем, насколько хорошо этот вектор описывает текущие намерения пользователя. User features делятся на два типа с разной динамикой: **сессионные** (что пользователь делает прямо сейчас) и **исторические** (что он делал за последние дни и месяцы).

Сессионные признаки критичны для intent detection: пользователь, слушающий джаз утром, может слушать рок вечером. Модель без session features будет рекомендовать усредненное и потеряет текущий контекст.

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

Item Features: контентные и статистические

Айтем - трек, видео, статья - описывается двумя группами признаков. **Контентные** извлекаются из самого контента: жанр, темп, тональность, теги, длительность. **Статистические** - это агрегаты поведения пользователей: CTR за последние 7 дней, средний completion rate, количество добавлений в плейлист. Оба типа необходимы: контентные помогают при холодном старте, статистические - точнее ранжируют популярные айтемы.

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

Зачем рекомендательной системе контентные признаки (жанр, темп аудио), если статистические (CTR, completion rate) дают точный сигнал качества?

Cross Features и Feature Crossing

Модель знает: пользователь слушает рок, и трек в жанре рок. Но отдельно эти признаки не передают взаимодействие. **Feature crossing** создаёт новый признак из комбинации двух: `user_genre=rock * item_genre=rock = 1.0`, что прямо кодирует «матч жанра». Это позволяет линейным моделям ловить нелинейные паттерны.

Зачем создавать cross feature `mobile_x_short_track` вместо того, чтобы передавать `device` и `duration` раздельно?

Embeddings как признаки

User ID и Item ID - это категориальные признаки с миллионами уникальных значений. One-hot кодирование создаст вектор в 100 миллионов измерений - это невозможно. **Embedding** сжимает каждый ID в плотный вектор малой размерности (32-512), где похожие сущности близко в пространстве. Этот вектор и является главным признаком для ranking модели.

Почему для User ID в рекомендательной системе используют learned embedding, а не one-hot кодирование?