Алексей Гусаков на deep tech night рассказал как Яндекс Музыка перешла на end-to-end генеративные рекомендации с новой моделью SONA. Энкодер-декодер модели вернулись! Новая система называется SONA. В A/B-тесте SONA дала +4,5% Active Users поверх всех улучшений, что были сделаны с 2023 года. От внедрения модели получили эффект больше, чем от всего сделанного за последние годы вместе взятого. В 2023 мы увидели первые BERT в рекомендациях: SASRec и BERT4Rec. Там история прослушиваний подавалась в энкодер-трансформер, а из результата делался вектор пользователя. Для получения рекомендаций можно было вычислить косинусное расстояния с вектором трека. Ограничение такого подхода в медленном обучении: каждый сабсет истории прослушиваний пользователя нужно обрабатывать как отдельный префикс, отдельным форвардом всей модели. Из-за этого приходилось ограничивать историю 128 треками. В 2025 появился ARGUS с переходом к генеративной постановке с трансформеров-декодером. Модель последовательно предсказывает следующий музыкальный трек, авторегрессионно, как LLM предсказывает следующий токен. Это позволило подавать в модель 8000 треков за раз и сразу считать ошибку для всех префиксов. Однако сжатие всей истории в один токен теряет много информации. К тому же трансформер был тяжёлый, поэтому его можно было применять только как реранкер. Этап генерации кандидатов оставался отдельным. Теперь следующая итерация – SONA, настоящая end-to-end система. Ключевая инновация это новый токенизатор под названием Semantic ID. Грубо говоря one-hot представление для каждого трека заменяется тремя дискретными иерархическими токенами из кодбука. Кодбук формируется на основе мультимодальных эмбеддингов трека с помощью Qwen 2.5-Omni, refinement-трансформера и кластеризации RQ-KMeans. В итоге получается токенизация сохраняющая семантику на разных уровнях абстракции: от общих жанровых черт до специфики конкретного трека. SONA – это энкодер-декодер. Энкодер часть сжимает историю пользователя, а декодер часть генерирует рекомендации. Одновременно учится и предсказывать следующий трек, и реакцию на него. SONA сама себе генератор кандидатов и ранкер, потому что использует новую структуру токенов для ретривала прямо во время своих предсказаний. Используется beam search. Сначала предсказываем первый токен из трех, затем второй при условии первого, затем последний при условии двух предыдущих. По сути для получения рекомендации сразу делаем поиск по дереву несколькими форвардами трансформера. Никакого FAISS или HNSW!

Казалось бы, зачем рекомендательной системе что-то генерировать? Нам же надо выбрать человеку существующий трек, а не сочинить новый. Но генерировать можно идентификатор этого трека. У Алексея Гусакова на deep tech night как раз был доклад про то, как Яндекс дошел до генеративных рекомендаций без ручного фичеинжиниринга. Начиналось все довольно привычно: BERT превращает историю прослушиваний в вектор пользователя, дальше ищем близкие векторы треков. В версии 2023 года модель учитывала историю из 128 треков. Потом появился Argus: идея была в том, чтобы предсказывать следующий трек примерно так же, как LLM предсказывает следующий токен. Обучение стало вычислительно эффективнее, историю удалось увеличить до 8000 треков. Но оставалась неприятная особенность: всю историю пользователя сжимали в один вектор, а подходящие треки искались через простую функцию близости, плюс еще был каскад отбора кандидатов. В итоге это приводило к тому, что если хороший трек потерялся на раннем этапе, можно сколько угодно улучшать финальный ранжировщик, но этот трек пользователь уже не увидит. В новой модели SONA трек представляют последовательностью из трех кодов, Semantic ID. Их получают из текста и аудио, причем коды сохраняют музыкальную семантику: у похожих треков могут совпадать первые компоненты. Дальше модель учится генерировать эту последовательность и одновременно ранжировать кандидатов по ожидаемому отклику пользователя. То есть next token prediction, только на выходе рекомендация, а не ответ в чатике. По данным команды, в A/B-тесте SONA дала около +4,5% к числу активных пользователей. Причем поверх предыдущих улучшений, а не относительно какого-нибудь древнего бейзлайна. Мне как человеку, успевшему позаниматься рекомендашками, и потому к ним неравнодушному, доклад понравился тем, что показывает как успешно прикручивать NLPшные методы к привычным задачам вроде построения рекомендательных систем. И, кстати, перетаскивание методов из NLP в RecSys и обратно всегда было рабочей идеей - есть много похожего в данных.

Вышел технический репорт о Sona – модели, которая заменила весь рекомендательный стек Яндекс Музыки https://arxiv.org/abs/2608.11015 Эта модель – итог целого года работы. И это лучшее внедрение трансформеров в истории А/B-тестов в Яндекс Музыке. Но главное здесь, что Sona – это одна модель. До этого продакшн-каскад рекомендаций Яндекс Музыки включал в себя 15+ генераторов кандидатов плюс ранжирование на сотнях ручных фич. И это все заменили единой моделью, обучаемой end-to-end. Это даже звучит сложно, а на деле несет за собой еще больше проблем и нюансов, чем может показаться на первый взгляд. Вот три центральных момента: 1️⃣ Раньше, в подходах типа OneRec, ранжирование считала отдельная модель на ручных фичах. Sona же должна была стать единым рецептом обучения и инференса, то есть декодер (который генерирует кандидатов) и ранкер (который их ранжирует) должны использовать один и тот же энкодер user-эмбеддингов, которые рассчитываются один раз за запрос. А значит – надо обходиться без ручных фич. Но проблема в том, что явный сигнал (лайки, репиты) довольно редок, чтобы выучить ранжирование напрямую. Поэтому тут встроена дистилляция. Сначала обучали Teacher Ranker. Это большая, медленная, но очень умная модель, которую тренили аж на годе логов. Она не используется в проде и нужна для того, чтобы научить шустрый Ranking Module воспроизводить ее скоры. 2️⃣ Так как Sona – это encoder-decoder, обучаемый хронологически на Next Token Prediction, каждый трек нужно представить в виде токенов. Это называется Semantic ID. И тут кроется парадокс: чем больше растет словарь токенов, тем модель должна быть умнее, но на самом деле она просто не успевала эффективно использовать возросшее пространство и деградировала. Поэтому одной из самых сложных частей было сделать рецепт токенизации, который бы обеспечивал рост качества при росте словаря. Дьявол кроется в деталях. 3️⃣ Ну и, конечно же, инфраструктура. Переход на одну модель потребовал фактически нового движка рекомендаций, включая сложный online learning pipeline. Кроме того, авторегрессивная генерация с длинными историями – это дорого, и поэтому пришлось прорабатывать отдельные архитектурные трюки (History Compression, кастомные CUDA-кернелы, radix top-k), просто чтобы уложиться в приемлемую латентность. Ради чего была вся эта огромная работа? На этот вопрос хорошо отвечают метрики. Sona принесла: +4,53% Active Users, +6,30% Total Listening Time и +11,42% Likes. Причем это прирост поверх улучшений от предыдущих внедрений, которые оставались в контрольной выборке в продакшне. В планах у команды – масштабирование, добавление RL и, конечно, раскачивание Sona на полный трафик. Поздравляем ребят с грандиозными результатами!