Помилка random split — одна з найчастіших причин провалу рекомендаційної системи в продакшні. Ми займаємося навчанням рекомендаційних моделей, які працюють в реальних умовах, а не на перетренованих метриках. Типовий випадок: клієнт з e-commerce використовував випадковий поділ, отримав NDCG@10 = 0.65, але після впровадження модель показувала 0.4. Після переходу на temporal split метрики впали, зате A/B тест дав +5% до виручки. Клієнт зазначив: «Випадковий поділ давав завищені метрики — часовий split виявився єдино чесним». Наш стек: PyTorch, Hugging Face Transformers, Faiss для ANN пошуку, ONNX Runtime для інференсу. Досвід команди — понад 5 років у ML і 50+ впроваджених рекомендаційних систем в e-commerce, медіа та fintech. Використовуємо Weights & Biases для трекінгу експериментів і MLflow для управління моделями. Замовте попередній аналіз даних — ми оцінимо вашу задачу і запропонуємо оптимальне рішення.
Проблеми, які вирішуємо
Неправильна генерація негативних прикладів
Якщо брати uniform sampling з усіх товарів, модель не навчиться відрізняти популярне від релевантного. Ми використовуємо popularity-based та hard negative mining (наприклад, товари, які модель вже помилково ранжує високо). Hard negative sampling покращує Recall@20 в 1.3 рази порівняно з uniform.
Холодний старт для нових користувачів і товарів
Без контентних ознак модель видає нульові передбачення. Ми додаємо side information (категорію, текст опису, зображення) через ембендінги.
Temporal bias
Реальні сценарії — це послідовність дій. Якщо перемішати дані випадково, модель «побачить» майбутнє під час навчання. Temporal split з відкладеними за часом val/test — обов'язкова умова.
Як ми це робимо: розгорнутий кейс
Серед наших проектів — інтернет-магазин з 5M взаємодій і 200K товарів. Ми побудували Two-Tower модель з об'єднанням через HNSW індекс. Пайплайн включав:
- передобробку логів: дедуплікація, фільтрація ботів, зважування взаємодій (покупка > перегляд);
- negative sampling 4:1 з урахуванням популярності; часовий split: 28 днів на train, 7 на val, 7 на test;
- Two-Tower: user tower — шар ембендінгів + Dense(256), item tower — те ж + L2 нормалізація. Loss — Weighted BCE з логарифмом позитивних ваг;
- навчання 20 епох з early stopping за NDCG@10, використовуючи AdamW (LR=1e-3). На GPU A100 — 45 хвилин;
- деплой через Triton Inference Server з ONNX моделлю. Latency p99 — 12 мс.
Результат: lift за NDCG@10 на 22% відносно ALS-бейзлайну, онлайн A/B тест показав +8% до додавань у кошик.
Чому важливий правильний negative sampling?
Негативні приклади задають межу прийняття рішень. Якщо всі негативні — це випадкові десяткові товари, модель легко їх відрізнить. Але на практиці потрібно розрізняти майже релевантні — наприклад, темний диван vs чорний диван. Hard negative sampling (з top-100 невзаємодіяних) дає більш robust навчання. У нас це реалізовано через кеш з ембендінгами та онлайн-вибірку.
Що дає часовий поділ?
Оцінка моделі на часовому спліті — єдиний спосіб отримати чесні метрики. Випадковий поділ може «зазирнути» в майбутнє, завищуючи результати. NDCG@10 на temporal split корелює з онлайн-результатами A/B тестів: розбіжність <15%.
Порівняння архітектур моделей
| Модель | Якість (NDCG@10) | Час навчання (5M) | Інференс latency | Особливості |
|---|---|---|---|---|
| ALS (матрична факторизація) | 0.42 | 30 хв (CPU) | <1 мс | Простий baseline, не використовує side info |
| Two-Tower (Dense 256) | 0.53 | 45 хв (A100) | 3–12 мс | Гнучка, cold start через ознаки |
| BERT4Rec (трансформер) | 0.58 | 4 год (A100) | 50 мс | Тільки послідовності, немає холодного старту |
Порівняно з ALS, Two-Tower дає приріст в 1.2 рази за NDCG@10 при співставному часі інференсу.
Порівняння стратегій negative sampling
| Стратегія | Якість (Recall@20) | Швидкість навчання | Складність реалізації |
|---|---|---|---|
| Uniform | 0.48 | Висока | Низька |
| Popularity-based | 0.55 | Середня | Середня |
| Hard negative (online) | 0.61 | Низька (через перерахунок ембендінгів) | Висока |
На практиці комбінуємо popularity-based та hard negatives: 80% популярних, 20% хард-негативів. Це дає баланс якості та швидкості.
Процес роботи
- Аналітика: вивчаємо логи взаємодій, виявляємо вузькі місця (sparsity, cold start, imbalance).
- Проектування: вибираємо архітектуру, функцію втрат, стратегію negative sampling.
- Реалізація: пишемо pipeline на PyTorch + Hugging Face, інтегруємо з вашою системою логування.
- Тестування: offline метрики (NDCG, recall@k) + онлайн A/B тест на 2-4 тижні.
- Деплой: контейнеризація, моніторинг (дрейф даних, latency), документація.
Терміни та вартість
Терміни: від 2 тижнів (baseline + доопрацювання) до 2 місяців (full pipeline з кастомною архітектурою). Вартість обговорюється індивідуально після аналізу даних. Наші клієнти відзначають економію на інфраструктурі до 40% і зниження витрат на підтримку до 30% завдяки оптимізації пайплайну.
Що входить в роботу
- Підготовлений датасет для повторного навчання
- Baseline (ALS або Two-Tower) зі звітом за метриками
- Навчена фінальна модель (PyTorch/ONNX)
- Документація по відтворенню pipeline
- Код пайплайнів (препроцесинг, навчання, інференс)
- Методичка по донавчанню на нових даних
- Консультація по інструментам NDCG та Temporal Split
Отримайте консультацію спеціаліста — ми обговоримо ваш проект і запропонуємо оптимальне рішення.