Чому музичні рекомендації ламаються на зростанні каталогу
Поки каталог — десятки тисяч треків, а історія слухача накопичена роками, матриця «користувач × трек» залишається достатньо щільною, і спільна фільтрація впевнено знаходить схожих.
Як тільки каталог сягає десятків мільйонів записів, а медіанний профіль — це кілька десятків подій, щільність падає на порядки: близькість між слухачами рахується вже за випадковими збігами.
Spotify уперся в це раніше за інших і пішов від чистих колаборативних сигналів до гібридних — аудіоознаки, тексти, поведінка в межах сесії.
Друга точка відмови — зміщення до популярного. Модель вчиться передбачати клік, а найнадійніший спосіб його отримати — показати те, що й так слухають усі. Довгий хвіст не потрапляє у видачу, не отримує показів, не отримує сигналів — і залишається невидимим. Різноманітність падає, добірки для різних людей стають майже однаковими.
Третя — застарівання профілю смаку. Якщо вектор інтересу усереднений за всією історією без часового згасання, давні прослуховування тягнуть підбірку на себе так само сильно, як учорашня сесія.
Зміна жанру у слухача не відстежується, а новий трек без історії отримує холодний старт і майже нульовий шанс показу.
Підсумок — падіння утримання: підбірка перестає потрапляти у смак, сесії коротшають, слабшає сигнал «дослухав і повернувся», а разом із ним і дані, на яких система могла б донавчитися. Виходить замкнене коло деградації.
Розбираємо, як це закривається: щільні сигнали для розріджених профілів, контроль різноманітності видачі та перезбирання профілю інтересу з урахуванням часу.
Що дає перебудова рекомендацій: ефект у вимірюваних величинах
Метрики рекомендацій не читаються середнім по сервісу — зсув видно у зрізах: новий слухач, що повернувся після паузи, передплатник із довгою історією.
Порівняння ведемо на відкладених сесіях: нова модель і поточна видача отримують одні й ті самі запити, і різниця рахується за кожним зрізом окремо, а не за враженням від показової підбірки.
Частка потраплянь у підбірку — скільки треків із верхньої частини видачі слухач не пропускає в перші секунди. Її зростання означає, що модель перестала вгадувати жанр «загалом» і потрапила в конкретний контекст: ранковий плейлист, дорога, робота в навушниках. Одночасно проявляються системні перекоси — коли всіх веде в один жанр або в ті самі хіти.
Час відгуку рекомендацій вважаємо на перцентилях, а не на середньому: важливо, щоб підбірка встигала за дією слухача — пропуском, позначкою «подобається», додаванням у плейлист — і враховувала його вже в наступній сесії, а не через годину. Хвіст розподілу тут дорожчий за середнє: саме рідкісні довгі відповіді вибивають людину з потоку.
Глибина прослуховування зростає, коли підбірка перестає бути набором знайомих треків: рахуємо частку композицій, дограних до кінця, і кількість нових виконавців, що закріпилися в особистій бібліотеці.
Повернення слухачів перевіряємо наступного дня і наступного тижня — якщо підбірка змінюється разом із настроєм, а не за розкладом оновлень, людина приходить частіше й слухає довше.
Способи побудови рекомендацій: порівняння підходів
Вибір підходу диктує не мода, а обсяг даних і щільність прослуховувань. Поки користувачів тисячі, а в кожного десяток треків, статистика спільних прослуховувань майже нічого не дає: матриця розріджена, профіль нового слухача порожній.
Тому в продукті зазвичай сусідять кілька механік — питання не «що вибрати», а «що працює на якій ділянці життєвого циклу».
Що порівнюємо
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручні добірки редактора | Запуск сервісу, сезонні та тематичні полиці | Не масштабуються: покривають малу частку каталогу, не персоналізуються |
| Колаборативна фільтрація | Щільна історія прослуховувань, багато взаємодій | Холодний старт для нових треків і слухачів, зміщення до популярного |
| Контентна модель за ознаками треку | Новинки каталогу, рідкісні жанри, мало статистики | Слабша там, де є поведінкові дані; залежить від якості розмітки |
| Гібридна схема підбору | Зрілий сервіс із різнорідним каталогом | Складніша в експлуатації: ваги об’єднання, контроль якості, переналаштування |
Як вибираємо на практиці
На старті гібрид спирається на ознаки треку й редакційні полиці, далі частка колаборативного сигналу зростає в міру накопичення взаємодій.
Холодний старт закривається окремо: новому треку вектор рахують за контентними ознаками, новому слухачеві — за коротким опитуванням і першими прослуховуваннями.
Ваги об’єднання добираємо офлайн за метриками дослуховування, і це частина робіт із супроводу, а не разове налаштування.
Етапи впровадження рекомендаційної системи
Роботу ведемо послідовно: кожен щабель спирається на результат попереднього. Пропустити аудит подій і відразу взятися за навчання моделі — означає зібрати ознаки з випадково збережених полів і впертися в стелю даних, а не в алгоритм.
- Аудит подій прослуховування. Розбираємо, що сервіс фіксує насправді: старт, дослуховування, пропуск, повтор, лайк, додавання в плейлист, — і де події втрачають прив’язку до профілю слухача.
- Схема ознак. Узгоджуємо склад і джерела: профіль слухача, властивості треку, контекст сесії, історія взаємодій. Схему версіонуємо, інакше перерахунок заднім числом дає непорівнювані результати.
- Розділення даних. Навчальну та перевірну частини ріжемо за часом, а не випадково: відкладена вибірка — останні тижні, яких модель не бачила. Це прибирає витік майбутнього й дає чесну оцінку.
- Навчання моделі. Точка відліку — поточна видача. Ускладнюємо лише за вимірюваного виграшу, порівнюючи потрапляння в топ-N, частку дослуховувань, різноманітність і новизну — одна метрика майже завжди обманює.
- Перевірка на відкладеній вибірці. Прогоняємо кандидатів на даних, яких модель не бачила, і імітуємо онлайн-поведінку. Відбираємо варіант із виграшем у середньому та без провалу на рідкісних жанрах.
- Онлайн-експеримент. Вмикаємо на частці трафіку й стежимо за дослуховуваннями, повторами та відтоками. Рішення про розкочування ухвалюємо за набором метрик, а не за однією.
- Передавання в експлуатацію. Налаштовуємо моніторинг якості, контроль зміщення даних, регламент перенавчання й відкат на попередню версію. Версії моделі та ознак логуємо — без цього результат не відтворюється.
Порядок стискаємо або розтягуємо під ваш обсяг даних, але пропуск будь-якого кроку спливає вже в експлуатації — коли видача розходиться з очікуваннями, а причина неочевидна.
Що передаємо на руки: моделі, схеми даних і регламенти
Передаємо не лише навчену модель, а й весь комплект для її самостійної експлуатації — інакше будь-яка зміна перетворюється на розбір коду й логів. Комплект розрахований на команду, яка не брала участі в розробці: інженер піднімає систему за документами, а не за листуванням.
- Схема потоків даних — від подій прослуховування до сховища ознак: джерела, затримка надходження, точки агрегації. Нове джерело підключається без правок у коді моделі.
- Довідник ознак — зміст, тип, вікно розрахунку, джерело й власник для кожної ознаки. Коли музичні рекомендації просідають, відразу видно, яка ознака змістилася.
- Регламент перенавчання — тригери (деградація метрик, зсув у прослуховуваннях), періодичність, склад перевірної вибірки та критерій приймання нової версії.
- Правила відкату версії — порядок повернення попередньої моделі, цільовий час відновлення й метрики, які підтверджують, що відкат спрацював.
- Документація щодо системи — архітектура, обмеження, відомі слабкі місця, точки відмови та порядок розбору інцидентів.
- Регламент моніторингу — які метрики рахуємо, як часто, які значення вважаємо деградацією і куди надходить оповіщення.
- Інструкція з відтворення — склад даних, кроки навчання з нуля та перевірка, що зібрана модель повторює передану.
Кейс: музичні рекомендації, метрики до і після впровадження
До проєкту видачу тримали ручні добірки редакторів і прості правила типу «популярне в жанрі» та «свіжі релізи».
Оновлювалися полиці раз на тиждень, до середини тижня слухачі вигорали: у кожній підбірці повторювалися ті самі треки, а самі рекомендації закривали лише малу частку прослуховувань. Люди йшли в пошук або поверталися до своїх збережених списків — утримання слухачів падало.
Ми зібрали журнал подій плеєра: дослуховування, пропуски в перші секунди, повтори, додавання в плейлист, переходи між треками.
На цих сигналах навчили модель ранжування, а ручні добірки не прибрали, а змінили їхню роль — вони закривають старт для нових слухачів і редакційні полиці, решту підбирають за поєднанням звукових ознак і поведінки схожих слухачів.
Порівняння якості підбору ведемо за єдиними вимірюваннями, як це роблять великі платформи на кшталт Spotify.
Метрики до і після
- частка прослуховувань, що надійшли з рекомендацій: 18% → 46%;
- частка пропусків треку в перші 30 секунд: 41% → 27%;
- утримання слухачів на 30-й день: 22% → 29%;
- частка ручних добірок у загальному часі прослуховування: 57% → 21%.
Окремо стежили за застоєм: повтори тих самих треків усередині підбірки скоротилися більш ніж удвічі, а нові для слухача виконавці стали з’являтися приблизно втричі частіше.
Старт для новачків при цьому не просів — редакційні полиці тримають їх, поки не накопичиться історія прослуховувань, і модель підключається поступово.
Чим холодний старт користувача відрізняється від холодного старту треку
Це дві різні задачі, і розв’язуються вони різними сигналами. У нового слухача немає історії прослуховувань, але є сам трек і контекст сесії. У нового треку немає жодного прослуховування, зате є аудиторія, чиї смаки вже описані.
Плутати контури не можна: правило, застосоване не до того об’єкта, дає або шум у перші хвилини, або реліз, який так і не набрав показів.
Для нового слухача працюють прямі сигнали: опитування смаку під час реєстрації, вибрані жанри й виконавці, перенесення своєї підбірки із зовнішнього сервісу, регіон і мова інтерфейсу.
Далі вмикаються поведінкові — дослуховування до кінця, дострокове перемикання, повтор, додавання у свою підбірку. Опитування смаку дає стартову точку, але переоцінювати його не можна: люди відзначають те, що «звучить солідно», а слухають інше, тому перші дії переважують анкету.
У нового треку сигналів смаку немає взагалі — є лише його власні характеристики та зв’язки з уже відомими об’єктами.
Тому задача розв’язується через вектор ознак (темп, тональність, щільність аранжування, вокал чи інструментал, епоха запису) і через граф схожості: трек показують тим, хто вже слухав близькі за описом записи того самого виконавця або періоду.
Далі вирішує частка дослуховувань на обмеженій аудиторії — вона або відкриває треку повноцінні покази, або закриває тему.
Різниця в метриках теж принципова. У слухача ми вимірюємо, як швидко падає частка дострокових перемикань і зростає утримання на другому тижні. У треку — скільки показів потрібно, щоб передбачення перестало відрізнятися від поведінки на широкій аудиторії.
Один поріг на обидва випадки не працює: для людини він занадто повільний, для треку — занадто швидкий.
Практичний висновок: у системі це два незалежні контури зі спільним сховищем ознак. Контур слухача швидко збирає переваги та уточнює їх за першими діями, контур треку перевіряє новинку на малій аудиторії й лише потім масштабує покази. Суміщення дає деградацію обох задач.
Технічні питання, які задають до старту
До оцінки уточнюємо: скільки історії прослуховувань накопичено, як події потрапляють із плеєра і що вже працює в проді. Від цього залежить, спираємося ми на спільні сигнали чи на ознаки каталогу, тому сумніви щодо даних, експлуатації та перевірки якості розбираємо відразу.
Скільки історії прослуховувань потрібно для старту?
Активному профілю вистачає кількох десятків взаємодій, щоб запрацювали спільні сигнали. Рідкісним профілям допомагають ознаки треку — жанр, темп, енергія; персональні ваги підмішуються в міру накопичення історії.
Як підключаються джерела даних?
Потрібен потік подій плеєра: ідентифікатори користувача й треку, тип дії, мітка часу. Забираємо його пакетно або потоково, приводимо до єдиної схеми і працюємо з копії, не зачіпаючи бойові бази.
Як перевіряється якість підбору?
Офлайн — на відкладеній частині історії: частка дослуховувань, час до першого пропуску, різноманітність видачі. Онлайн — порівняння двох груп слухачів на одному трафіку, щоб відокремити ефект моделі від сезонних коливань.
Що робити, якщо систему вже розгорнуто?
Нову логіку вмикаємо тіньовим режимом: вона рахує підбірки, але не впливає на плеєр, поки метрики не підтвердять покращення. Перемикання йде за сегментами слухачів, із швидким поверненням до попередньої логіки.
Як враховується фонове прослуховування?
Події зважуємо за тривалістю: трек, залишений на перших секундах, і явний пропуск — різні сигнали. Довга сесія без взаємодії не вважається інтересом і не тягне підбірку в той чи інший бік.
Обговоримо задачу: повернемося з оцінкою та планом робіт
Щоб музичні рекомендації заробили у вашому сервісі, а не залишилися демонстрацією на тестовому наборі, нам потрібна поточна картина загалом. Як влаштована видача зараз, звідки надходять події прослуховувань, що вже пробували і на якому обмеженні зупинилися. Опишіть ситуацію своїми словами — цього достатньо, щоб почати розбір.
Натомість повертаємося з постановкою задачі та планом робіт: що робимо на кожному етапі, які дані потрібні з вашого боку, де контрольні точки і як виглядатиме приймання.
- постановка задачі: формулюємо мету у вимірюваних термінах — що саме покращуємо у видачі і як це перевіримо;
- розбір поточної системи: дивимося, які сигнали вже збираються, чого бракує, де втрачається якість;
- склад робіт: перелічуємо етапи від підготовки даних до виведення видачі на реальних користувачів;
- план впровадження: розписуємо послідовність, залежності між етапами й точки, де потрібне ваше рішення;
- порядок старту: називаємо, що робимо в першу чергу, а що можна відкласти без втрати результату;
- критерії приймання: домовляємося заздалегідь, за якими показниками вважаємо задачу розв’язаною.
Опишіть задачу й обмеження — повернемося з оцінкою та планом робіт.
