Привет, Хабр! Меня зовут Игорь Миленький, я руководитель отдела ML-аналитики в музыкальном сервисе Звук. В аналитике с 2015 года, с 2023 года работаю в Звуке: занимаюсь ML-аналитикой для команд рекомендаций, поиска, контента, клиентского опыта и антифрода.
Расскажу об еще одной профессии в Data Science, ML-аналитике, и покажу на практике, как устроена работа команды в Звуке. В статье хотел бы дать общее представление о профессии ML-аналитика и примерах задач, а конкретные образцы кода и подробные исследования будут описаны в следующих статьях :-)
Статья будет полезна:
тем, кто рассматривает для себя профессию ML-аналитика,
действующим командам ML-аналитики, чтобы поделиться лучшими практиками,
командам, которые хотят узнать, какие бизнес-задачи решает ML-аналитика и планируют создать такую команду.
В Звуке команда ML-аналитики работает в управлении Data Science, помогает в работе командам Data Science, Рекомендаций, Поиска, Технологий Client Journey и Контента. В составе команды ML-специалисты с опытом работы в Data Science, так как задачи команды сильно смещены в сторону ML и отличаются от скоупа задач дата-аналитиков. В зоне ответственности команды:
подготовка ML-моделей прогнозов и сегментации,
подсчет онлайн- и офлайн-бизнес-метрик ML-моделей, вывод метрик на дешборды,
проведение A/B-тестов ML-моделей перед выводом в продакшн,
исследование данных для разработки ML-моделей.
Разработка ML-моделей
Команда помогает с запросами заказчиков по достаточно быстрому созданию ML-моделей без привлечения ресурса инженеров. В зоне ответственности команды модели по прогнозам и кластеризации.
Например, делаем модель прогноза популярности контента. Модель важна, чтобы быстро обрабатывать и добавлять ML-фичи к самым популярным трекам, а также к новым трекам популярных исполнителей. Эта модель популярности позволяет быстрее проращивать треки с высоким прогнозом популярности в рекомендации и поиск.
В рамках работы модели мы выделяем треки, у которых были прослушивания за последний период и больше определенного числа уникальных пользователей. Затем у треков с минимальными значениями оставляем значение предыдущей недели. У треков со сроком жизни в Звуке ме��ьше 21 дня мы прогнозируем динамику прослушиваний именно на этот период. А затем объединяем с треками, у которых есть прослушивания за 21 день, и методом линейной аппроксимации строим прогноз на следующий период.
После построения прогноза разбиваем треки на “тиры” — группы по количеству прослушиваний по прогнозу. Затем добавляем “суперновинки” популярных артистов, треки у которых еще нет прослушиваний в Звуке, в самый важный тир, чтобы как можно быстрее “прорастить” новинки в рекомендации и поиск.
A/B-тесты и метрики
Если воспользоваться аллегорией с Формулой 1, ML-инженеры придумывают и собирают новые модели, а ML-аналитики занимаются испытаниями этих моделей в аэродинамической трубе. Так же как в Формуле 1, в заездах участвуют только лучшие модели, показавшие идеальные результаты на тестах — в Звуке выходят в прод только ML-модели, показавшие высокие результаты при замере офлайн-метрик, а затем по результатам A/B-тестов. Таким образом, при разработке новой ML-модели совместно с командой ML-инженеров мы сначала считаем офлайн-метрики модели, затем тестируем выдачу на ограниченном списке пользователей и только после этого запускаем A/B-тесты на большей выборке пользователей в приложении, чтобы сэкономить ресурсы и запускать только новые модели с высокими значениями метрик качества.
На первом этапе мы подсчитываем следующие офлайн-метрики: Hit Rate, Precision, Recall, F1-меру. В случае моделей, ранжирующих элементы, считаем Average Precision, NDCG, MRR. Также считаем метрики схожести рекомендаций модели со вкусами пользователей в предыдущем периоде, например, по языкам, жанрам и артистам.
В A/B-тестах ML-моделей мы стандартно считаем дизайн эксперимента. Во время проведения A/B-теста следим, чтобы не было сильного падения метрик, и если видим большое падение — получаем алерт и останавливаем тест, чтобы провести ресерч работы модели.
При подсчете результатов экспериментов, помимо стандартных метрик, мы отслеживаем достаточно большой набор метрик рекомендаций:
Freshness - скользящая доля новых треков (N) среди воспроизведенных треков в рекомендациях (T)
Coverage - скользящее количество уникальных воспроизведенных треков в рекомендациях (C), нормированное на количество воспроизведенных треков в рекомендациях (Т)
New Tracks Growth - доля новых треков топ-артистов воспроизведенных в рекомендациях (Ar) от всех новых треков топ-артистов (A)
Novelty - среднее по пользователям усредненное значение собственной информации (с учетом штрафа, который зависит от частоты встречаемости объекта и времени последней встречи) по списку его рекомендаций. Метрика, показывающая насколько новым для пользователя является предложенный моделью объект
где R - длина списка рекомендаций пользователя
F - коэффициент штрафа
ui - количество пользователей, которым был показан i-й трек
U - общее количество пользователей
Diversity - средняя по пользователям усредненная попарная схожесть (косинусное расстояние) между векторами звучания воспроизведенных треков. Метрика, показывающая способность модели рекомендовать разные по содержанию объекты
где R - длина списка рекомендаций пользователя
sim(i,j) - косинусное расстояние между векторами звучания треков i,j
Serendipity - среднее по пользователям усредненная попарная схожесть (косинусное расстояние) между векторами звучания прослушанных треков и средним вектором прослушанного трека (по истории прослушивания пользователя), домноженная на суммарное время прослушивания трека в течение следующей недели. Метрика, характеризующая способность модели рекомендовать такие объекты, которые не только релевантны для пользователя, но ещё и существенно отличаются от того, с какими объектами пользователь взаимодействовал в прошлом.
где R - длина списка рекомендаций пользователя
sim(i,mu) - косинусное расстояние между векторами звучания трека i и средним вектором прослушанного трека (по истории прослушивания пользователя) mu
TS(i) - суммарное время прослушивания трека в течение следующей недели
APLT(Average Percentage of Long Tail) - доля редких (не популярных) треков в рекомендациях. Подсчитываем популярность треков по истории прослушиваний, считаем метрику, как среднюю по пользователям.
где R - длина списка рекомендаций пользователя
W = 1/u - вес уникальности трека, обратная величина от количества уникальных пользователей, прослушавших трек (u)
U - общее количество пользователей
Из-за большого количества A/B-тестов расчет результатов вручную потребовал бы больших трудозатрат, поэтому мы используем автоматизированные дешборды в FineBI для расчета метрик в A/B-тестах.
Эти же метрики мы не только отслеживаем во время A/B-тестов, но и продолжаем отслеживать на дешбордах уже после запуска модели, чтобы убедиться в высоком качестве рекомендаций.
Однако для моделей поиска отслеживаем на дешбордах метрики Precision, DCG, NDCG, а также отслеживаем скорость доставки — насколько быстро новые треки, альбомы и аудиокниги “прорастают” в поиске с помощью нашей модели.
Исследования команды ML-аналитики
Кроме подготовки моделей и подсчета метрик, команда ML-аналитики занимается исследованиями данных для формирования корректных вводных для ML-моделей. Также исследования помогают определить дальнейший курс развития моделей. Например, мы провели исследование контента и обнаружили, что достаточно большое число треков очень похожи по звучанию — в базе Звука есть и радиоверсии треков, и студийные версии, а также ремиксы и каверы. Качество моделей рекомендаций можно улучшить, если исключить повторяющиеся треки из рекомендаций. Для этого мы подготовили модель дедупликации на основе графов, которая позволила выделить треки в большие группы, а затем выделить “эталонный трек” для моделей рекомендаций в каждой из групп.
Также мы проводим исследования AI-инструментов, которые помогут нам быстрее получать выводы по данным, используемым в моделях, не тратить ресурсы команды на написание SQL-скриптов. Мы используем open-source инструменты — модель Qwen-3, развернутую у нас локально с помощью команд ML Research и MLOps, а также агента Vanna AI для подключения к Qwen-3 и связи с Trino SQL, который используется в нашей базе данных. Таким образом, мы получаем выгрузку данных и визуализацию набора данных без написания SQL-кода, только с помощью ввода запроса.
Благодаря этому, команда ML снимает боли заказчиков по быстрой подготовке ML-моделей, также команда мониторит качество ML-моделей, в том числе и с помощью A/B-тестов, а еще проводит различные исследования данных для ML-моделей. В следующих статьях подробнее опишем конкретные кейсы наших проектов.
