Розробка рекомендаційної системи для маркетплейсу

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

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