Рекомендательные системы: от collaborative filtering до real-time serving
E-commerce с каталогом 300k SKU. CTR на рекомендациях — 1.8%. После замены правила «популярное за последние 7 дней» на коллаборативную фильтрацию — 3.1%. После добавления контентных признаков и re-ranking — 4.4%. Это реальные числа из реального проекта. Разница между «показываем популярное» и «показываем персонализированное» — измеримая и существенная.
Collaborative Filtering: матричная факторизация и нейронные подходы
Matrix Factorization. ALS (Alternating Least Squares) — классический алгоритм для implicit feedback (клики, просмотры, покупки без явного рейтинга). Implicit библиотека реализует ALS с GPU-ускорением, обрабатывает матрицы user×item в сотни миллионов ненулевых значений за минуты. Latent factors 64-256, регуляризация λ=0.01-0.1 — стартовые параметры.
Проблема cold start: для нового пользователя нет истории взаимодействий. Для новых items: нет взаимодействий. Классический CF здесь беспомощен — нужны контентные признаки или гибридный подход.
Neural Collaborative Filtering. NCF заменяет линейное скалярное произведение в MF на нейросеть. На практике выигрыш над хорошо настроенным ALS умеренный, но NCF проще расширять дополнительными признаками (возраст пользователя, категория товара, время суток).
Sequence-aware модели. Если порядок взаимодействий важен (пользователь смотрел A → B → C, что показать следующим) — SASRec (Self-Attentive Sequential Recommendation) или BERT4Rec. Трансформерная архитектура поверх последовательности item_id — state-of-the-art для сессионных рекомендаций. Обучается на последовательностях, предсказывает следующий item.
Content-Based Filtering: когда история взаимодействий мала
Content-based рекомендует на основе характеристик товаров/контента, а не поведения других пользователей. Решает cold start для items: новый товар с описанием и категорией можно рекомендовать сразу.
Текстовые эмбеддинги. Описания товаров → эмбеддинги через sentence-transformers (multilingual-e5-base или BGE-M3 для мультиязычного каталога) → поиск похожих через cosine similarity. Для каталога 100k товаров — FAISS IndexFlatIP, запрос за <5ms.
Структурированные признаки. Категория, бренд, цена, характеристики — через embedding layers в нейросети или как категориальные признаки в gradient boosting. CatBoost хорошо работает с категориальными фичами без ручного encoding.
Item2Vec. Обучаем Word2Vec на последовательностях просмотров: item_id вместо слов, сессия вместо предложения. Быстро, интерпретируемо, хорошо работает для «похожие товары».
Гибридные подходы: two-stage retrieval + ranking
Production рекомендательные системы почти всегда двухуровневые.
Stage 1: Retrieval (candidate generation). Из 300k товаров быстро отбираем 100-500 кандидатов. Инструменты: ALS или Two-Tower модель (отдельные энкодеры для user и item, dot product для скоринга). Векторный поиск через FAISS или Qdrant. Требование — скорость: < 20ms.
Stage 2: Ranking. Из 100-500 кандидатов ранжируем финальный список (топ-10-20). Тяжёлая модель с богатыми признаками: градиентный бустинг (LightGBM, CatBoost) или нейросеть с cross-features. Здесь учитываем контекст: устройство, время, предыдущие действия в сессии. Требование: < 50-100ms.
LightFM — библиотека, реализующая гибридные модели факторизации с поддержкой item и user features. Хорошая отправная точка для среднего масштаба без тяжёлой инфраструктуры.
Real-Time Serving: архитектура под нагрузку
Рекомендательная система на главной странице сервиса — это latency SLA 50-100ms при тысячах запросов в секунду. Архитектура serving имеет значение.
Precomputation vs. real-time. Для большинства пользователей рекомендации можно посчитать заранее и закэшировать. Batch job раз в час/ночью → записать топ-100 рекомендаций в Redis по user_id → при запросе читаем из кеша. Latency < 5ms. Недостаток: не учитывает события последних часов.
Real-time обновление контекста. Hybrid подход: base рекомендации из кеша + real-time re-ranking с учётом последних действий в сессии. Kafka для потока событий (клики, добавление в корзину) → feature computation → обновление контекстных признаков → быстрый re-ranking.
Feature serving. Redis для пользовательских признаков с TTL (количество просмотров за последние 24 часа, последний кликнутый item). Latency чтения < 1ms. При нагрузке 10k req/s — Redis Cluster с репликацией.
A/B тестирование. Рекомендательные системы нельзя оценивать только по офлайн-метрикам (NDCG, MAP). Офлайн-метрики коррелируют с онлайн-CTR, но не всегда. A/B тест с 5-10% трафика на новую модель, мониторинг CTR, конверсии, revenue per session — единственный достоверный способ оценить улучшение.
Метрики: офлайн и онлайн
Офлайн метрики:
- NDCG@k (Normalized Discounted Cumulative Gain) — учитывает позицию в списке
- MAP@k (Mean Average Precision) — для задач с binary relevance
- Recall@k — покрытие: какую долю релевантных items мы попали в топ-k
- Coverage — какую долю каталога система реально рекомендует (борьба с popularity bias)
Онлайн метрики:
- CTR (Click-Through Rate) — базовая метрика engagement
- Conversion Rate — из рекомендации в покупку/целевое действие
- Revenue per user
- Diversity — разнообразие рекомендаций (не показывать 10 одинаковых товаров)
Popularity bias — хроническая проблема CF. Популярные items получают много взаимодействий → модель их чаще рекомендует → они получают ещё больше взаимодействий. Long tail item (80% каталога) плохо рекомендуются. Решение: diversity-aware re-ranking, debiasing в loss function, popularity normalization в implicit feedback.
Этапы проекта
Аудит данных. Смотрим историю взаимодействий: плотность матрицы user×item (обычно <0.1%), распределение активности пользователей (20% users дают 80% взаимодействий), наличие temporal паттернов, cold start статистику.
Baseline. Popular items в качестве рекомендаций — простой baseline, который часто трудно сильно обогнать. Фиксируем offline-метрики baseline.
Итеративное улучшение. ALS → добавление контентных признаков → two-stage система → sequence-aware модели. Каждый шаг измеряем офлайн и проверяем A/B тестом.
Инфраструктура serving. Batch precomputation, Redis кеширование, real-time re-ranking, мониторинг.
Прототип на существующих данных с офлайн-валидацией: 2-3 недели. Production-система с two-stage ranking, A/B тестированием и мониторингом: 2-3 месяца.







