Разработка рекомендательной системы для музыкального сервиса

Почему музыкальные рекомендации ломаются на росте каталога

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

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

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

Итог — падение удержания: подборка перестаёт попадать в вкус, сессии укорачиваются, слабеет сигнал «дослушал и вернулся», а вместе с ним и данные, на которых система могла бы дообучиться. Получается замкнутый круг деградации. Разбираем, как это закрывается: плотные сигналы для разреженных профилей, контроль разнообразия выдачи и пересборка профиля интереса с учётом времени.

Что даёт перестройка рекомендаций: эффект в измеримых величинах

Метрики рекомендаций не читаются средним по сервису — сдвиг виден в срезах: новый слушатель, вернувшийся после паузы, подписчик с длинной историей. Сравнение ведём на отложенных сессиях: новая модель и текущая выдача получают одни и те же запросы, и разница считается по каждому срезу отдельно, а не по впечатлению от показательной подборки.

Доля попаданий в подборку — сколько треков из верхней части выдачи слушатель не пропускает в первые секунды. Её рост означает, что модель перестала угадывать жанр «в целом» и попала в конкретный контекст: утренний плейлист, дорога, работа в наушниках. Одновременно проявляются системные перекосы — когда всех уводит в один жанр или в одни и те же хиты.

Время отклика рекомендаций считаем на перцентилях, а не на среднем: важно, чтобы подборка успевала за действием слушателя — пропуском, отметкой «нравится», добавлением в плейлист — и учитывала его уже в следующей сессии, а не через час. Хвост распределения здесь дороже среднего: именно редкие долгие ответы выбивают человека из потока.

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

Способы построения рекомендаций: сравнение подходов

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

Что сравниваем

Как выбираем на практике

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

Этапы внедрения рекомендательной системы

Работу ведём последовательно: каждая ступень опирается на результат предыдущей. Пропустить аудит событий и сразу взяться за обучение модели — значит собрать признаки из случайно сохранившихся полей и упереться в потолок данных, а не в алгоритм.

1. Аудит событий прослушивания. Разбираем, что сервис фиксирует на деле: старт, дослушивание, пропуск, повтор, лайк, добавление в плейлист, — и где события теряют привязку к профилю слушателя.
2. Схема признаков. Согласуем состав и источники: профиль слушателя, свойства трека, контекст сессии, история взаимодействий. Схему версионируем, иначе пересчёт задним числом даёт несопоставимые результаты.
3. Разделение данных. Обучающую и проверочную части режем по времени, а не случайно: отложенная выборка — последние недели, которых модель не видела. Это убирает утечку будущего и даёт честную оценку.
4. Обучение модели. Точка отсчёта — текущая выдача. Усложняем только при измеримом выигрыше, сравнивая попадание в топ-N, долю дослушиваний, разнообразие и новизну — одна метрика почти всегда обманывает.
5. Проверка на отложенной выборке. Прогоняем кандидатов на данных, которых модель не видела, и имитируем онлайн-поведение. Отбираем вариант с выигрышем в среднем и без провала на редких жанрах.
6. Онлайн-эксперимент. Включаем на доле трафика и следим за дослушиваниями, повторами и оттоками. Решение о раскатке принимаем по набору метрик, а не по одной.
7. Передача в эксплуатацию. Настраиваем мониторинг качества, контроль смещения данных, регламент переобучения и откат на предыдущую версию. Версии модели и признаков логируем — без этого результат не воспроизводится.

Порядок сжимаем или растягиваем под ваш объём данных, но пропуск любого шага всплывает уже в эксплуатации — когда выдача расходится с ожиданиями, а причина неочевидна.

Что передаём на руки: модели, схемы данных и регламенты

Передаём не только обученную модель, но и весь комплект для её самостоятельной эксплуатации — иначе любое изменение превращается в разбор кода и логов. Комплект рассчитан на команду, которая не участвовала в разработке: инженер поднимает систему по документам, а не по переписке.

• Схема потоков данных — от событий прослушивания до хранилища признаков: источники, задержка поступления, точки агрегации. Новый источник подключается без правок в коде модели.
• Справочник признаков — смысл, тип, окно расчёта, источник и владелец по каждому признаку. Когда музыкальные рекомендации проседают, сразу видно, какой признак сместился.
• Регламент переобучения — триггеры (деградация метрик, сдвиг в прослушиваниях), периодичность, состав проверочной выборки и критерий приёмки новой версии.
• Правила отката версии — порядок возврата предыдущей модели, целевое время восстановления и метрики, подтверждающие, что откат сработал.
• Документация по системе — архитектура, ограничения, известные слабые места, точки отказа и порядок разбора инцидентов.
• Регламент мониторинга — какие метрики считаем, как часто, какие значения считаем деградацией и куда уходит оповещение.
• Инструкция по воспроизведению — состав данных, шаги обучения с нуля и проверка, что собранная модель повторяет переданную.

Кейс: музыкальные рекомендации, метрики до и после внедрения

До проекта выдачу держали ручные подборки редакторов и простые правила вида «популярное в жанре» и «свежие релизы». Обновлялись полки раз в неделю, к середине недели слушатели выгорали: в каждой подборке повторялись одни и те же треки, а сами рекомендации закрывали лишь малую долю прослушиваний. Люди уходили в поиск или возвращались к своим сохранённым спискам — удержание слушателей падало.

Мы собрали журнал событий плеера: дослушивания, пропуски в первые секунды, повторы, добавления в плейлист, переходы между треками. На этих сигналах обучили модель ранжирования, а ручные подборки не убрали, а сменили их роль — они закрывают старт для новых слушателей и редакционные полки, остальное подбирается по сочетанию звуковых признаков и поведения похожих слушателей. Сравнение качества подбора ведём по единым замерам, как это делают крупные платформы вроде Spotify.

Метрики до и после

• доля прослушиваний, пришедших из рекомендаций: 18% → 46%;
• доля пропусков трека в первые 30 секунд: 41% → 27%;
• удержание слушателей на 30-й день: 22% → 29%;
• доля ручных подборок в общем времени прослушивания: 57% → 21%.

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

Чем холодный старт пользователя отличается от холодного старта трека

Это две разные задачи, и решаются они разными сигналами. У нового слушателя нет истории прослушиваний, но есть сам трек и контекст сессии. У нового трека нет ни одного прослушивания, зато есть аудитория, чьи вкусы уже описаны. Путать контуры нельзя: правило, применённое не к тому объекту, даёт либо шум в первые минуты, либо релиз, который так и не набрал показов.

Для нового слушателя работают прямые сигналы: опрос вкуса при регистрации, выбранные жанры и исполнители, перенос своей подборки из внешнего сервиса, регион и язык интерфейса. Дальше включаются поведенческие — дослушивание до конца, досрочное переключение, повтор, добавление в свою подборку. Опрос вкуса даёт стартовую точку, но переоценивать его нельзя: люди отмечают то, что «звучит солидно», а слушают другое, поэтому первые действия перевешивают анкету.

У нового трека сигналов вкуса нет вообще — есть только его собственные характеристики и связи с уже известными объектами. Поэтому задача решается через вектор признаков (темп, тональность, плотность аранжировки, вокал или инструментал, эпоха записи) и через граф похожести: трек показывают тем, кто уже слушал близкие по описанию записи того же исполнителя или периода. Дальше решает доля дослушиваний на ограниченной аудитории — она либо открывает треку полноценные показы, либо закрывает тему.

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

Практический вывод: в системе это два независимых контура с общим хранилищем признаков. Контур слушателя быстро собирает предпочтения и уточняет их по первым действиям, контур трека проверяет новинку на малой аудитории и только потом масштабирует показы. Совмещение даёт деградацию обеих задач.

Технические вопросы, которые задают до старта

До оценки уточняем: сколько истории прослушиваний накоплено, как события попадают из плеера и что уже работает в проде. От этого зависит, опираемся ли мы на совместные сигналы или на признаки каталога, поэтому сомнения по данным, эксплуатации и проверке качества разбираем сразу.

Как подключаются источники данных?

Нужен поток событий плеера: идентификаторы пользователя и трека, тип действия, метка времени. Забираем его пакетно или потоково, приводим к единой схеме и работаем с копии, не затрагивая боевые базы.

Как проверяется качество подбора?

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

Что делать, если система уже развёрнута?

Новую логику включаем теневым режимом: она считает подборки, но не влияет на плеер, пока метрики не подтвердят улучшение. Переключение идёт по сегментам слушателей, с быстрым возвратом к прежней логике.

Как учитывается фоновое прослушивание?

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

Обсудим задачу: вернёмся с оценкой и планом работ

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

Взамен возвращаемся с постановкой задачи и планом работ: что делаем на каждом этапе, какие данные нужны с вашей стороны, где контрольные точки и как будет выглядеть приёмка.

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

Опишите задачу и ограничения — вернёмся с оценкой и планом работ.