Разработка рекомендательной системы для видео/стримингового сервиса

Реализация рекомендательной системы для видеостримингового сервиса

Представьте: пользователь открывает стриминговый сервис, видит ленту с контентом, который ему не интересен, и уходит к конкуренту. Коллаборативные фильтры не работают — они не учитывают, что вечером пользователь хочет смотреть комедию, а утром — документалку. Чтобы удержать зрителя, нужна рекомендательная система, которая понимает контекст: время суток, устройство, настроение, историю просмотров. Наш подход базируется на мультиконтекстной модели, которая показала прирост watch time на 30-50% в продакшене. Экономия бюджета на привлечение новых пользователей за счёт удержания существующих достигает 40%.

Какие метрики используются для оценки?

Основная метрика — watch time на сессию. Дополнительно отслеживают continuation rate — доля пользователей, которые начали следующий эпизод сериала, и diversity потребляемого контента. CTR второстепенен, так как цель — удержание, а не клики. Наши A/B-тесты показывают, что прирост watch time в 3-5 раз выше, чем при использовании коллаборативной фильтрации.

Как учесть контекст просмотра пользователя?

Ключевая идея — предсказывать не просто 'понравится/не понравится', а вероятность досмотра с учётом текущего состояния. Для этого строим user tower и item tower с общим embedding-пространством и добавляем контекстные признаки: час дня, тип устройства, длительность предыдущей сессии, жанровый профиль.

Мультиконтекстная модель

import numpy as np
import pandas as pd
import torch
import torch.nn as nn

class VideoStreamingRecommender(nn.Module):
    """Учитывает контекст просмотра: время, устройство, соратники"""

    def __init__(self, n_users, n_items, n_genres, embed_dim=128):
        super().__init__()
        # User tower
        self.user_emb = nn.Embedding(n_users + 1, embed_dim)
        self.genre_emb = nn.Embedding(n_genres + 1, 32)

        # Context features
        self.context_mlp = nn.Sequential(
            nn.Linear(10, 32),  # hour, day, device_type, etc.
            nn.ReLU()
        )

        # Item tower
        self.item_emb = nn.Embedding(n_items + 1, embed_dim)
        self.genre_item_emb = nn.Embedding(n_genres + 1, 32)

        # Scoring head
        self.scoring = nn.Sequential(
            nn.Linear(embed_dim + 32 + 32 + embed_dim + 32, 128),
            nn.ReLU(),
            nn.Dropout(0.3),
            nn.Linear(128, 1),
            nn.Sigmoid()
        )

    def forward(self, user_id, context_features, item_id,
                 item_genre, user_top_genres):
        u = self.user_emb(user_id)
        g = self.genre_emb(user_top_genres).mean(dim=1)
        c = self.context_mlp(context_features)

        i = self.item_emb(item_id)
        ig = self.genre_item_emb(item_genre)

        combined = torch.cat([u, g, i, ig], dim=1)
        return self.scoring(combined).squeeze(1)


class WatchHistoryFeatureExtractor:
    """Признаки из истории просмотров"""

    def extract_user_features(self, watch_history: pd.DataFrame) -> dict:
        """
        watch_history: user_id, item_id, watched_seconds, total_seconds,
                       genre, timestamp, device
        """
        completion_rates = watch_history['watched_seconds'] / watch_history['total_seconds'].clip(1)

        features = {
            'completion_rate_avg': completion_rates.mean(),
            'completion_rate_std': completion_rates.std(),
            'binge_sessions': self._count_binge_sessions(watch_history),
            'preferred_genres': watch_history.groupby('genre')['watched_seconds'].sum().nlargest(3).index.tolist(),
            'preferred_device': watch_history['device'].value_counts().index[0],
            'avg_session_items': self._avg_items_per_session(watch_history),
            'evening_watcher': self._is_evening_watcher(watch_history),
            'weekend_preference': self._weekend_ratio(watch_history),
        }
        return features

    def _count_binge_sessions(self, history: pd.DataFrame) -> int:
        """Сессии с 3+ эпизодами подряд"""
        history = history.sort_values('timestamp')
        history['session_gap'] = history['timestamp'].diff().dt.total_seconds() > 1800
        history['session_id'] = history['session_gap'].cumsum()
        session_counts = history.groupby('session_id').size()
        return int((session_counts >= 3).sum())

    def _is_evening_watcher(self, history: pd.DataFrame) -> bool:
        evening_views = history[
            pd.to_datetime(history['timestamp']).dt.hour.between(18, 23)
        ]
        return len(evening_views) / max(len(history), 1) > 0.5

    def _weekend_ratio(self, history: pd.DataFrame) -> float:
        weekend = pd.to_datetime(history['timestamp']).dt.dayofweek >= 5
        return weekend.mean()

    def _avg_items_per_session(self, history: pd.DataFrame) -> float:
        if 'session_id' not in history.columns:
            return 1.5
        return history.groupby('session_id').size().mean()

Почему важна серийность контента?

В стриминге сериалы — основной драйвер удержания. Пользователь, который смотрит сериал, проводит на платформе в 3 раза больше времени. Стандартные модели не дают приоритет следующему эпизоду, и пользователь может потеряться среди рекомендованного. Мы реализовали модуль, который повышает вероятность следующего эпизода в 2.5 раза.

Ранжирование с учётом продолжаемости серий

class SeriesContinuationBooster:
    """Буст для следующих эпизодов серий, которые пользователь смотрит"""

    def boost_continuation(self, candidates: list[tuple],
                            user_watch_history: pd.DataFrame,
                            content_metadata: dict) -> list[tuple]:
        """Повышение приоритета продолжений"""
        # Серии в прогрессе
        series_progress = (
            user_watch_history
            .groupby('series_id')['episode_number']
            .max()
            .to_dict()
        )

        boosted = []
        for item_id, score in candidates:
            meta = content_metadata.get(item_id, {})
            series_id = meta.get('series_id')
            episode = meta.get('episode_number', 1)

            boost = 1.0
            if series_id and series_id in series_progress:
                watched_episode = series_progress[series_id]
                if episode == watched_episode + 1:
                    boost = 2.5  # Следующий эпизод
                elif episode <= watched_episode:
                    boost = 0.1  # Уже смотрел

            boosted.append((item_id, score * boost))

        return sorted(boosted, key=lambda x: x[1], reverse=True)

Сравнение подходов к рекомендациям

Гибридная модель обеспечивает прирост watch time в 3-5 раз выше, чем коллаборативная фильтрация. Это подтверждено A/B-тестами на проектах с аудиторией от 500 тыс. до 5 млн пользователей.

Процесс внедрения рекомендательной системы

Типичные ошибки при разработке

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

Что входит в разработку под ключ

• Модель с детальной документацией (model card, описание фич, метрики).
• REST API для выдачи рекомендаций (latency p99 < 50 мс, throughput 10k RPS).
• A/B-инфраструктура для онлайн-оценки.
• Интеграция с вашей платформой (веб, мобильные приложения, Smart TV).
• Обучение команды и сопровождение после запуска.

Как мы обеспечиваем качество

Мы разработали более 20 рекомендательных систем для streaming-платформ. Наш опыт подтверждает прирост watch time на 30-50% в первые 3 месяца после внедрения. Используем Netflix как бенчмарк, но адаптируем архитектуру под конкретный контент и аудиторию. Гарантируем прозрачность: вы получаете не чёрный ящик, а интерпретируемую модель с объяснением рекомендаций.

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

Разработка рекомендательных систем: от collaborative filtering до real-time serving

На одном проекте для e-commerce с каталогом 300k SKU мы подняли CTR с 1,8% до 4,4% — в 2,4 раза. Первый рывок дала коллаборативная фильтрация вместо «популярное за последние 7 дней», второй — добавление контентных признаков и re-ranking. Разница между «показываем популярное» и «показываем персонализированное» — измеримая и существенная. Ниже — инженерный опыт, который помог это сделать, и архитектуры, которые реально работают в продакшене.

Collaborative Filtering: матричная факторизация и нейронные подходы

Matrix Factorization — классика для implicit feedback (клики, просмотры, покупки без явного рейтинга). ALS (Alternating Least Squares) в библиотеке Implicit обрабатывает матрицы user×item с сотнями миллионов ненулевых значений за минуты на GPU. Latent factors 64–256, регуляризация λ=0.01–0.1 — стартовые параметры. Проблема cold start: для нового пользователя или товара нет истории — классический CF беспомощен, нужны контентные признаки или гибрид.

Neural Collaborative Filtering (NCF) заменяет скалярное произведение на нейросеть. На практике выигрыш над хорошо настроенным ALS умеренный, но NCF проще расширять дополнительными признаками (возраст, категория, время суток). Sequence-aware модели (SASRec, BERT4Rec) учитывают порядок взаимодействий — state-of-the-art для сессионных рекомендаций.

Как выбрать архитектуру рекомендательной системы?

Ответ зависит от данных, нагрузки и требований к холодному старту. Ниже — три основных подхода с критериями выбора.

Гибридная архитектура на 20–40% эффективнее чистого CF по покрытию long-tail — проверено на каталогах от 100k SKU.

Content-Based Filtering: когда истории взаимодействий мало

Content-based рекомендует на основе характеристик товаров, а не поведения других пользователей — решает cold start для новых items. Текстовые эмбеддинги через sentence-transformers (multilingual-e5-base, BGE-M3) → поиск похожих через FAISS IndexFlatIP — запрос за <5 ms на 100k товаров. Item2Vec (Word2Vec на последовательностях просмотров) даёт интерпретируемые «похожие товары» за пару часов обучения.

Структурированные признаки (категория, бренд, цена) подаются через embedding layers или в gradient boosting — CatBoost работает с категориями без ручного кодирования.

Почему гибридные модели работают лучше?

Production-системы почти всегда двухуровневые. Stage 1 (Retrieval) — быстрый отбор 100–500 кандидатов из 300k товаров через ALS или Two-Tower модель с векторным поиском (FAISS, Qdrant). Stage 2 (Ranking) — тяжёлый ранжировщик на LightGBM или нейросети с cross-features, временем, устройством и контекстом сессии. LightFM — хорошая отправная точка для среднего масштаба без тяжёлой инфраструктуры. Наша практика показывает: переход от single-stage к two-stage даёт прирост точности на 15–25% при росте latency всего на 20–30 мс.

Real-Time Serving: архитектура под нагрузку

Latency SLA — 50–100 ms при тысячах запросов в секунду. Base-рекомендации precompute (batch job раз в час) → Redis по user_id → <5 ms. Real-time re-ranking через Kafka для событий (клики, добавления в корзину) → обновление контекстных признаков. Feature serving — Redis с TTL (число просмотров за 24 часа, последний кликнутый item). При нагрузке 10k req/s ставим Redis Cluster с репликацией.

A/B тестирование — единственный достоверный способ оценить улучшения. Офлайн-метрики коррелируют с онлайн не всегда. Kohavi et al., «Online Controlled Experiments at Large Scale» (KDD 2013) — обязательное чтение для команды. Тест с 5–10% трафика, мониторинг CTR, конверсии, revenue per session. Одна из наших клиентских систем после гибридизации увеличила выручку на 18% за месяц A/B.

Сроки разработки рекомендательной системы

Этапы и типичные временные затраты — в таблице ниже. Стоимость рассчитывается индивидуально под масштаб каталога и требования к latency.

Что входит в разработку под ключ

1. Аудит данных — плотность матрицы user×item (обычно <0,1%), распределение активности, temporal паттерны, cold start статистика.
2. Baseline — «популярное» как простой порог, который часто трудно обогнать.
3. Итеративное улучшение — ALS → контентные признаки → two-stage → sequence-aware. Каждый шаг с A/B.
4. Инфраструктура serving — batch precomputation, Redis, real-time re-ranking, мониторинг в Grafana.
5. Документация — model card с метриками, инструкция по деплою, описание признаков.
6. Обучение команды — сессия по интерпретации результатов и дообучению модели.
7. Поддержка — 1 месяц после запуска (фикс инцидентов, донастройка pipeline).

Мы — команда с 7+ годами опыта в рекомендательных системах, реализовали более 30 проектов для e-commerce и медиа. Гарантируем прозрачное A/B‑тестирование и фиксацию улучшения метрик.

Хотите оценить потенциал роста вашего каталога? Свяжитесь с нами для бесплатного аудита данных. Закажите разработку рекомендательной системы — первый прототип в течение двух недель.

from implicit.als import AlternatingLeastSquares

model = AlternatingLeastSquares(
    factors=64,
    regularization=0.05,
    iterations=15,
    use_gpu=True
)
model.fit(user_item_matrix)

Больше о математике рекомендательных систем — в Wikipedia.