Зачем вообще рекомендательная система

В первой части мы говорили об инфраструктуре, во второй — о знаниях. Теперь переходим к тому, ради чего всё затевалось: алгоритмам, которые решают, что показать пользователю.

Рекомендательная система (RecSys) — это сердце персонализации. Когда пользователь открывает приложение, у вас есть 3–5 секунд, чтобы предложить ему что-то релевантное. Если промахнётесь — он уйдёт. Если попадёте — останется, послушает, купит, вернётся завтра.

В Звуке рекомендации генерировали 65% всего streaming time. Не поиск, не browse, не плейлисты редакции — а именно алгоритмические рекомендации. Это было нашим главным продуктом, хотя пользователи об этом даже не задумывались.

Три подхода к рекомендациям

Прежде чем строить RecSys, нужно выбрать архитектурный подход. Их три, и каждый имеет свои сильные и слабые стороны.

Collaborative Filtering (CF)

Принцип: «Пользователи, похожие на тебя, слушали вот это». CF не знает ничего о контенте — он работает только с матрицей «пользователь × элемент». Если 1000 пользователей с похожим на твой паттерном слушали трек X, а ты его ещё не слышал — CF порекомендует тебе трек X.

Плюсы:
- Не требует атрибутов контента — работает на чистом поведении
- Ловит неочевидные связи — может рекомендовать джаз любителю электроники, если паттерн совпадает
- Хорошо масштабируется при достаточном объёме данных

Минусы:
- Cold start — не работает для новых пользователей и нового контента
- Popularity bias — склонен рекомендовать популярное
- Требует большого объёма данных — при MAU < 100K может не хватить сигналов

Content-Based Filtering

Принцип: «Тебе нравился контент с такими характеристиками — вот ещё похожий». Работает с атрибутами контента: жанр, настроение, темп, исполнитель, язык.

Плюсы:
- Работает с первого взаимодействия — достаточно знать, что пользователь послушал
- Не зависит от других пользователей — работает даже при малом MAU
- Объяснимость — легко объяснить, почему рекомендация была сделана

Минусы:
- Ограничен пузырём — рекомендует только похожее на уже потреблённое
- Требует качественных атрибутов контента (см. часть 2 про Content Management)
- Не ловит сложные поведенческие паттерны

Гибридные подходы

Принцип: комбинировать CF и content-based, чтобы компенсировать слабости каждого. Варианты:

  • Weighted hybrid — линейная комбинация скоров CF и content-based
  • Switching hybrid — используем content-based для новых пользователей, CF для активных
  • Feature augmentation — контентные фичи как вход для CF-модели
  • Cascade — сначала грубая фильтрация одним методом, затем ранжирование другим

На практике все зрелые RecSys-системы — гибридные. Вопрос не «CF или content-based?», а «как именно комбинировать?».

Как мы выбирали подход в Звуке

Когда я начал строить персонализацию в Звуке, у нас было 5 миллионов MAU, каталог из 70+ миллионов треков и практически нулевая персонализация. Главная страница выглядела одинаково для всех.

Мы начали с collaborative filtering — и вот почему:

Данные были. 5M MAU генерировали достаточно поведенческих сигналов. У нас были миллиарды событий прослушивания — идеальный вход для CF.

Атрибутов не было. Каталог содержал базовые метаданные — исполнитель, альбом, жанр. Но жанровая классификация была грубой и неполной. Строить content-based на таких данных — получить плохие рекомендации.

Скорость важнее совершенства. Нам нужно было показать результат за 3 месяца. CF можно обучить на существующих данных без дополнительной разметки. Content-based требовал сначала инвестиций в разметку каталога.

Первая версия — implicit ALS (Alternating Least Squares на неявных сигналах) — заработала через 6 недель. Она была далека от совершенства, но уже давала +12% streaming time в A/B-тесте. Этого было достаточно, чтобы получить ресурсы на развитие.

Проблема cold start и наше решение

Cold start — главная боль CF. Новый пользователь не имеет истории, а значит, CF не может найти похожих пользователей. Новый контент никто не слушал — CF его не рекомендует.

Cold start для пользователей

Мы решили эту проблему в два этапа:

Этап 1: Onboarding-опрос. При первом входе пользователь выбирал 3–5 любимых исполнителей из списка. Это давало нам seed-вектор — начальное представление о вкусе. Конверсия прохождения опроса — 72%. Те, кто проходил, показывали +25% retention на первой неделе по сравнению с контрольной группой.

Этап 2: Контентные фичи для новых пользователей. Параллельно мы обучили content-based модель, которая работала для пользователей с < 20 прослушиваниями. После 20 прослушиваний включался CF. Switching hybrid в чистом виде.

Cold start для контента

Новые треки попадали в специальный exploration pool — небольшой процент рекомендаций отдавался новому контенту. Мы использовали multi-armed bandit подход: каждый новый трек получал ограниченное количество показов, и если пользователи реагировали положительно, трек получал больше exposure. Если нет — выбывал из пула.

Это решало сразу две проблемы: cold start нового контента и exploration-exploitation tradeoff — баланс между проверенными хитами и экспериментами.

Масштабирование: от 1 модели до 5 RecSys-продуктов

За 2,5 года мы выросли от одной CF-модели до 5 рекомендательных продуктов:

  1. Персональная лента — главная страница с рекомендациями. Гибрид CF + content-based + контекстные фичи (время суток, день недели, устройство). Наш основной RecSys-продукт, генерировавший ~40% streaming time.

  2. Персональные плейлисты — «Микс дня», «Открытия недели» и другие. Алгоритмы подбирали треки с учётом diversity (не слишком много одного жанра) и novelty (минимум 30% неслышанных треков).

  3. Radio — бесконечный поток музыки на основе seed-трека или исполнителя. Здесь content-based играл ключевую роль: поток должен быть когерентным по настроению и энергии, а не просто релевантным.

  4. Contextual recommendations — рекомендации по контексту: «Для бега», «Для работы», «Для вечеринки». Здесь мы использовали кластеризацию сессий — определяли типичные паттерны использования и подбирали контент под каждый.

  5. Push-рекомендации — персонализированные пуши: «Вышел новый альбом исполнителя, которого ты слушаешь» или «Ты давно не слушал — вот что нового». Здесь критичным было timing — когда отправить push, чтобы пользователь кликнул.

Каждый продукт — это отдельная модель (или ансамбль моделей) со своим пайплайном обучения, serving-инфраструктурой и метриками. ML Platform, о которой я писал в первой части, — это то, что позволяло управлять этой сложностью.

Реальные цифры

Вот что мы получили по результатам A/B-тестов на разных этапах:

  • Базовый CF (месяц 2): +12% streaming time vs неперсонализированная выдача
  • CF + content-based гибрид (месяц 6): +22% streaming time, +15% retention day 7
  • Полный стек из 5 продуктов (месяц 18): +30% конверсия в платную подписку, 2.5x рост общего streaming time
  • Cold start solution (onboarding): +25% retention day 7 для новых пользователей

Эти цифры — не теоретические модели. Это результаты статистически значимых A/B-тестов с контрольными группами и корректным расчётом significance.

Ключевой инсайт: первая модель не должна быть идеальной. Она должна быть достаточно хорошей, чтобы показать эффект и получить ресурсы на развитие. Перфекционизм на старте — причина смерти большинства RecSys-инициатив.

Чек-лист: когда начинать строить RecSys

Рекомендательная система имеет смысл, если:

  • [ ] У вас > 10 000 MAU — достаточно данных для CF
  • [ ] Каталог > 1000 единиц — есть из чего рекомендовать
  • [ ] Пользователи совершают > 5 действий за сессию — достаточно сигналов
  • [ ] Есть Data Platform (или хотя бы event tracking) — данные собираются
  • [ ] Есть A/B-платформа — можно измерить эффект
  • [ ] Бизнес готов ждать 3–6 месяцев до первых результатов

Если вы ответили «да» на 4+ пункта — вы готовы. Если меньше — начните с инфраструктуры (часть 1).

Что дальше

В следующей части мы разберём персонализированный поиск и discovery — как помочь пользователю найти то, о чём он даже не знал.

Хотите обсудить рекомендательные системы для вашего бизнеса? Запишитесь на консультацию — разберём ваш кейс и определим оптимальный подход.