«Spotify: История продукта». Как мы разработали алгоритмы музыкальных рекомендаций

Из онлайн-библиотеки — в сервис персонализированных рекомендаций.

Это третья статья из серии «Spotify: история продукта», мы уже рассказали о создании десктопной версии сервиса и разработке мобильного приложения.

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

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

В год запуска Spotify магистрант Королевского технологического института в Стокгольме Эрик Бернхардссон пришел в компанию, чтобы дописать свою диссертацию. Будучи студентом, он увидел потенциал в предоставлении пользователям индивидуальных рекомендаций, которые получались путем массового умножения матриц.

В то время в ходу был механизм «Совместной фильтрации», созданный пользователями Spotify. Он работает так: большое число пользователей помещает одни и те же треки рядом друг с другом в похожие плейлисты снова и снова. Мы понимаем: это говорит, во-первых, о том, что эти треки хорошо сочетаются, а во-вторых, подсказывает, что в них, вероятно, есть что-то общее. Затем подключаются алгоритмы: они вычисляют, насколько похожи две дорожки математически.

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

Хотя задача рекомендации новой музыки слушателям казалась второстепенной, мы не отказывались от нее полностью. Мы передали часть работы по анализу данных стартапу The Echo Nest из Массачусетса, сопроводив задачи нашими рекомендациями. Это стало базой для первого урока нашей продуктовой стратегии.

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

Но чтобы продолжать расти, нам нужно было найти способы привлечь на платформу больше «обычных» слушателей.

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

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

У этой базы данных были свои проблемы: данные были недостаточно «чистыми», чтобы предотвратить неожиданно всплывающие песни и создать действительно качественное взаимодействие с пользователем, которое казалось бы ему разумным и адекватным.

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

Стартап The Echo Nest использовал алгоритмы машинного обучения, чтобы попытаться понять музыку так, как ее понимают люди. Один алгоритм пытался понять, как люди описывают музыку, которую слушают — какие слова для этого используют. Для этого Echo Nest сканировали блоги, обзоры, и любые другие материалы, а после обрабатывали. Например, одного исполнителя постоянно описывают с помощью слов «jangle pop», а других нет, тогда система учится ассоциировать этот термин с этим конкретным исполнителем.

Так мы могли видеть связи между музыкантами с точки зрения того, как их описывают, а также замечать артистов, которых часто описывают похожими словами или музыкальными терминами. Вторая часть исследования The Echo Nest была посвящена тому, что нельзя пометить словами, темпу и ритму, а также другим сложно описываемым аспектам музыки.

У The Echo Nest было то, чего нам не хватало — алгоритмы, которые говорили все о самой музыке. У Spotify в свою очередь было то, чего не хватало The Echo Nest: данные о том, как люди взаимодействуют с музыкой. Много-много данных о прослушивании. Таким образом, мы подошли к третьему уроку продуктовой стратегии.

В 2014 году мы сделали решительный шаг и купили стартап Echo Nest. Так, наконец, получили все необходимое для запуска нашего первого machine learning продукта.

Примерно через год мы запустили Discover Weekly, наш первый плейлист, полностью сгенерированный с помощью алгоритмов: он подстраивался под каждого пользователя индивидуально. По понедельникам слушатели открывали приложение и находили там новый плейлист, составленный из треков, которые они могли пропустить в огромном каталоге Spotify.

Нам удалось решить проблему индивидуальных рекомендаций. Но только для части наших пользователей — искушенных поклонников музыки, убежденных, что ни один алгоритм никогда не сможет подстроиться под их уникальный вкус. Именно их поразила точность Discover Weekly. Но не широкую публику.

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

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

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

В 2013 году Spotify приобрела Tunigo — приложение, редакторы которого собирали саундтреки к тому, чем вы можете заняться под музыку — другими словами то, что при разработке продукта мы называем «сценариями использования». Это были плейлисты с названиями «Энергичный бег», «Музыка, чтобы сфокусироваться», «Ужин с друзьями», «Ваша любимая кофейня» — по сути, условия, позволяющие любому пользователю перемещаться по музыкальному каталогу и изучать его.

Редакторы замечали особенности повседневной жизни людей, которые не смогли уловить даже самые сложные алгоритмы, анализирующие схожесть песен или характеристики звука. И поскольку Tunigo был создан с использованием API Spotify, мы знали, насколько популярны их плейлисты у массового пользователя — того самого, которого мы пытались охватить. Это слушатели, которые любят музыку, но не разбираются в жанрах и терминах и не хотели бы тратить время на составление плейлистов, а хотели бы просто больше слушать подходящую музыку.

К 2015 году мы выработали два совершенно разных инструмента для рекомендаций: персонализированные, алгоритмически сгенерированные плейлисты, например, Discover Weekly для заядлых любителей музыки, и плейлисты с «саундтреками» для различных ситуаций и настроений, курируемые редакторами.

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

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

Так родился подход, который можно назвать и алгоритмическим, и редакционным. У нас мы его называем "algotorial".