Обучение рекомендательных моделей: Two-Tower, ALS, negative sampling

Ошибка 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%.

Сравнение архитектур моделей

По сравнению с ALS, Two-Tower даёт прирост в 1.2 раза по NDCG@10 при сопоставимом времени инференса.

Сравнение стратегий negative sampling

На практике комбинируем popularity-based и hard negatives: 80% популярных, 20% хард-негативов. Это даёт баланс качества и скорости.

Процесс работы

1. Аналитика: изучаем логи взаимодействий, выявляем бутылочные горлышки (sparsity, cold start, imbalance).
2. Проектирование: выбираем архитектуру, функцию потерь, стратегию negative sampling.
3. Реализация: пишем pipeline на PyTorch + Hugging Face, интегрируем с вашей системой логирования.
4. Тестирование: offline метрики (NDCG, recall@k) + онлайн A/B тест на 2-4 недели.
5. Деплой: контейнеризация, мониторинг (дрейф данных, latency), документация.

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

Сроки: от 2 недель (baseline + доработка) до 2 месяцев (full pipeline с кастомной архитектурой). Стоимость обсуждается индивидуально после анализа данных. Наши клиенты отмечают экономию на инфраструктуре до 40% и снижение затрат на поддержку до 30% благодаря оптимизации пайплайна.

Что входит в работу

• Подготовленный датасет для повторного обучения
• Baseline (ALS или Two-Tower) с отчётом по метрикам
• Обученная финальная модель (PyTorch/ONNX)
• Документация по воспроизведению pipeline
• Код пайплайнов (препроцессинг, обучение, инференс)
• Методичка по дообучению на новых данных
• Консультация по инструментам NDCG и Temporal Split

Получите консультацию специалиста — мы обсудим ваш проект и предложим оптимальное решение.

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