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

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

Маркетплейс с 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 — товар показывается случайной выборке пользователей.

Пример exploration-стратегии

Мы используем 8% трафика для случайного показа новых товаров. Это позволяет собрать достаточно данных за 2-3 недели для перехода к гибридной модели.

Через 2-3 недели накапливается достаточно данных для перехода на гибридную модель.

 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 

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

Подход	Цель	Преимущества	Недостатки
Pure relevance	Релевантность	Высокий CTR	Игнорирует монетизацию, доминирование продавцов
Weighted multi-objective	Баланс всех целей	Гибкость, настройка под бизнес	Сложность подбора весов
Constrained optimization (CCO)	Максимизация GMV при ограничениях	Прямая оптимизация бизнес-метрики	Риск снижения качества при жёстких ограничениях

Многоцелевая архитектура увеличивает 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 среди продавцов.

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

Метрика	До внедрения	После внедрения многоцелевой системы
GMV per session	база	+12-20%
CTR главной страницы	база	+30-50%
Conversion rate	база	+5-10%

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

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+ внедрений для маркетплейсов с высоким оборотом. Гарантируем прозрачный процесс и поддержку после запуска.