Рекомендаційні Системи: Від Collaborative Filtering до Real-Time Serving
E-commerce з каталогом 300k SKU. CTR на рекомендаціях — 1.8%. Після заміни правила "популярне за останні 7 днів" на collaborative filtering — 3.1%. Після додавання контентних features та re-ranking — 4.4%. Це реальні числа з реального проекту. Різниця між "показуємо популярне" та "показуємо персоналізоване" — вимірюваний та істотний.
Collaborative Filtering: Matrix Factorization та Нейронні Підходи
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 беспомощен — потрібні контентні features або гібридний підхід.
Neural Collaborative Filtering. NCF замінює лінійне dot product у MF на нейросіть. На практиці виграш над добре налаштованим ALS помірний, але NCF легше розширювати додатковими features (вік користувача, категорія товара, час доби).
Sequence-aware моделі. Якщо порядок взаємодій важливий (користувач дивився A → B → C, що показати далі) — SASRec або BERT4Rec. Transformer архітектура поверх послідовності item_id — state-of-the-art для сессійних рекомендацій. Учиться на послідовностях, передбачає наступний item.
Content-Based Filtering: Коли Історія Взаємодій Мала
Content-based рекомендує на основі характеристик товарів/контенту, а не поведінки інших користувачів. Розв'язує cold start для items: новий товар з описом та категорією можна рекомендувати одразу.
Текстові embedding'и. Описи товарів → embedding'и через sentence-transformers (multilingual-e5-base або BGE-M3 для multilingual каталогу) → пошук схожих через cosine similarity. Для каталогу 100k товарів — FAISS IndexFlatIP, запит за <5ms.
Структуровані features. Категорія, бренд, ціна, характеристики — через embedding layers у нейросіті або як категоріальні features у 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). Важка модель з багатими features: gradient boosting (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 обновлення контексту. Гібридний підхід: base рекомендації з кеша + real-time re-ranking з урахуванням останніх дій у сеансі. Kafka для потоку events (клики, додавання в кошик) → обчислення features → обновлення контекстних features → швидкий re-ranking.
Feature serving. Redis для користувацьких features з 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, який часто важко сильно перебити. Фіксуємо офлайн-метрики baseline.
Ітеративне вдосконалення. ALS → додавання контентних features → two-stage система → sequence-aware моделі. Кожен крок вимірюємо офлайн та перевіряємо A/B тестом.
Інфраструктура serving. Batch precomputation, Redis кешування, real-time re-ranking, моніторинг.
Прототип на існуючих даних з офлайн-валідацією: 2-3 тижні. Production-система з two-stage ranking, A/B тестуванням та моніторингом: 2-3 місяці.