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

Многоцелевая рекомендательная система для маркетплейса

Маркетплейс с 10 млн SKU и 50 тыс. продавцов — рекомендательная система здесь не просто подбирает товары, она балансирует релевантность, монетизацию и удовлетворённость продавцов. Типичная ошибка: жертвуют качеством ради конверсии или наоборот. Рекомендательные системы для маркетплейсов — сложный инженерный продукт, где плохая настройка приводит к падению GMV или уходу продавцов. Наш опыт показывает, что оптимальное решение — многоцелевая архитектура с весами, которые настраиваются под бизнес-цели.

Как многоцелевая архитектура решает конфликт интересов?

Ключевая сложность — интересы покупателя (найти нужный товар), продавца (продвинуть свой товар) и платформы (заработать) часто противоречат друг другу. Мы реализуем scoring с несколькими целевыми функциями, каждая со своим весом. Например, релевантность — 50%, качество товара — 20%, разнообразие продавцов — 15%, продвинутые товары — 10%, конверсия — 5%. Веса подбираются эмпирически через A/B тесты.

import numpy as np
import pandas as pd
from dataclasses import dataclass

@dataclass
class MarketplaceItem:
    item_id: str
    seller_id: str
    price: float
    rating: float
    review_count: int
    is_promoted: bool
    conversion_rate: float
    inventory: int

class MarketplaceRecommender:
    """Рекомендации с балансировкой нескольких целей"""

    def __init__(self, user_model, item_index, seller_index):
        self.user_model = user_model
        self.item_index = item_index
        self.seller_index = seller_index

        # Веса целевых функций
        self.weights = {
            'relevance': 0.50,      # Релевантность для пользователя
            'quality': 0.20,        # Рейтинг и отзывы
            'seller_diversity': 0.15,  # Разнообразие продавцов
            'promoted': 0.10,       # Продвинутые товары
            'conversion': 0.05      # Исторический CR
        }

    def recommend(self, user_id: str, context: dict,
                   n: int = 20) -> list[dict]:
        """Многоцелевые рекомендации"""
        # Retrieval: топ-кандидаты по релевантности
        user_emb = self.user_model.get_user_embedding(user_id)
        candidates = self.item_index.search(user_emb, k=200)

        # Scoring: многоцелевая функция
        scored = []
        seller_count = {}

        for item_id, relevance_score in candidates:
            item = self._get_item(item_id)
            if item is None or item.inventory == 0:
                continue

            # Качество товара
            quality_score = (
                item.rating / 5.0 * 0.6 +
                np.log1p(item.review_count) / 10 * 0.4
            )

            # Штраф за концентрацию продавцов
            seller_count[item.seller_id] = seller_count.get(item.seller_id, 0) + 1
            seller_diversity = 1 / seller_count[item.seller_id]

            # Promoted boost (с ограничением)
            promo_boost = 1.2 if item.is_promoted else 1.0

            # Финальный скор
            final_score = (
                self.weights['relevance'] * relevance_score +
                self.weights['quality'] * quality_score +
                self.weights['seller_diversity'] * seller_diversity +
                self.weights['promoted'] * (promo_boost - 1) +
                self.weights['conversion'] * item.conversion_rate
            )

            scored.append({
                'item_id': item_id,
                'seller_id': item.seller_id,
                'score': final_score,
                'relevance': relevance_score,
                'quality': quality_score
            })

        # Сортировка и возврат
        scored.sort(key=lambda x: x['score'], reverse=True)
        return scored[:n]

    def _get_item(self, item_id: str) -> MarketplaceItem:
        return self.seller_index.get(item_id)

    def similar_items_cross_seller(self, item_id: str,
                                    n: int = 6) -> list[dict]:
        """Похожие товары от других продавцов (comparison shopping)"""
        item = self._get_item(item_id)
        if not item:
            return []

        similar = self.item_index.search_similar(item_id, k=20)

        # Фильтрация: другой продавец, но похожий товар
        cross_seller = [
            s for s in similar
            if self._get_item(s[0]) and self._get_item(s[0]).seller_id != item.seller_id
        ]

        return cross_seller[:n]

Как решить проблему холодного старта?

Новые товары не имеют истории взаимодействий — стандартные collaborative filtering не работают. Согласно Wikipedia о холодном старте, проблема возникает, когда у нового элемента нет взаимодействий. Наш подход: используем content-based буст на основе мета-данных. Товары с высоким рейтингом (≥4.5) и конкурентной ценой получают начальный рейтинг 0.5. Плюс 8% трафика выделяется на exploration — товар показывается случайной выборке пользователей.

    def handle_new_item_cold_start(self, item: MarketplaceItem,
                                    item_features: dict) -> float:
        """Начальный буст для новых товаров"""
        base_score = 0.3  # Базовая позиция

        # Буст на основе метаданных
        if item.rating >= 4.5 and item.review_count >= 10:
            base_score += 0.2
        if item.price < self._get_category_avg_price(item_features.get('category')):
            base_score += 0.1  # Конкурентная цена

        # Explore-exploit баланс для новых товаров
        # Показываем 5-10% трафика для сбора данных
        import random
        if random.random() < 0.08:  # 8% exploration
            return 0.7 + random.random() * 0.3

        return base_score

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

Многоцелевая архитектура увеличивает GMV в 1.12-1.2 раза по сравнению с Pure relevance и повышает CTR в 1.3-1.5 раза. Это делает её более эффективной для долгосрочной монетизации.

Что даёт A/B тестирование рекомендаций?

Стандартные метрики precision@k, recall@k, NDCG — недостаточны для маркетплейса. Мы используем бизнес-метрики: GMV per session, CTR главной страницы, conversion rate. A/B тест проводится минимум 2 недели с разделением трафика 50/50. Дополнительно мониторим seller satisfaction через ежемесячный NPS среди продавцов.

Метрики эффективности рекомендаций

Процесс разработки: от аудита до деплоя

1. Аудит данных: анализ логов взаимодействий, товарных карточек, профилей продавцов. Выявляем проблемы с качеством данных и искажения (selection bias, popularity bias).
2. Проектирование архитектуры: выбор моделей (embeddings, трансформеры), определение pipeline: batch vs online, выбор векторной БД (ChromaDB, Qdrant).
3. Реализация: пишем production-ready код на PyTorch/Hugging Face, оборачиваем в REST API с latency p99 < 100ms.
4. Интеграция: подключаем к витрине магазина, настраиваем мониторинг дрейфа данных через Weights & Biases.
5. A/B тестирование: запускаем эксперимент, анализируем результаты, корректируем веса.
6. Документация и обучение: передаём код, описание модели, инструкцию для эксплуатации.

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

• Полная документация: описание архитектуры, инструкция по развертыванию, руководство по эксплуатации.
• Исходный код модели и pipeline с комментариями.
• REST API для интеграции с витриной.
• Настройка мониторинга дрейфа данных и A/B тестирования.
• Обучение команды заказчика работе с системой.
• Техническая поддержка на этапе запуска.

Сроки и стоимость

Сроки: от 4 недель (MVP) до 3 месяцев (полноценная система). Стоимость рассчитывается индивидуально — зависит от объёма данных, сложности интеграций и требований к real-time. Получите консультацию: мы проанализируем ваши данные и предложим архитектуру, подходящую под ваши бизнес-цели. Свяжитесь с нами для оценки вашего проекта — наш опыт включает 20+ внедрений для маркетплейсов с высоким оборотом. Гарантируем прозрачный процесс и поддержку после запуска.

Разработка рекомендательных систем: от 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.