Поддержу коллег из Эргономики всего с их предложениями, ведь я очень люблю музыку, всегда и везде её слушаю, а Яндекс всеми силами пытается отбить у меня это желание. Интерфейс Яндекс музыки с каждым обновлением Название трека переводится, как острая пицца и это отсылка к фильму падает на дно. С остальными сервисами всё хорошо, а сервис музыка Так, план простой: найти свой ритм и не сбавлять ;) делают всё неудобнее и хуже. Страшный коктейль из постоянно мигрирующих кнопок, переливающихся всеми Лиричность - визитная карточка русского рока цветами, рекламы и максимально неуместных элементов, смысл которых лишь запутать и помешать тебе найти нужный. А ещё удобно поделиться треком, чтобы ссылка кинула не на трек, а на альбом и твой визави угадывал, какой же ты трек посоветовал. Я использую на телефоне и компе много разных стриминговых приложений и ко всем есть вопросики, это святое, но яндекс-музыка в последний год от души пришпорила свою бешеную лошадь обновлений и теперь она, закусив удила, несётся с выпученными глазами по вёдрам с яркими красками, перемешивая всё на своём пути. Яндекс, пишите нам, если вы запутались, что делать, я вам с удовольствием помогу сделать удобно и хорошо. Министерство жилья

Вышел технический репорт о 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 на полный трафик. Поздравляем ребят с грандиозными результатами!

Обновление Яндекс Музыки, которое вызвало шквал возмущения в соцсетях, критиковали внутри самого Яндекса перед релизом, но эффективным менеджерам было плевать Яндекс Музыка выкатила большое обновление в конце мая. Само обновление было давно, но мне попал в руки скриншот из внутреннего мессенджера с обсуждением этого релиза. Расскажу контекст. Яндекс предлложил юзерам новый инновационный сценарий взаимодействия с приложением — это выбор настроения треков. То есть не свои подборки или определённый жанр музыки, а именно настроение, сформулированное долбоёбскими AI-слопными формулировками: «неделя до диплома (ааа)», «свидание 10 из 10» или «секс под грустную музыку». Вдобавок дизайнеры накрутили некоторые спорные решения, например, кнопки «вперёд/назад» убрали с экрана трека, потому что по задумке перелистывание настроения важнее. Прило стало лагать на слабых девайсах, а некоторые любимые пользователями функции переместили подальше так, что их не найти. Пользователи были в ярости. Вот цитата самого популярного отзыва на Пикабу (орфография автора сохранена): Яндекс.Музыка, хотите отзыв? Идите НА ХУЙ с такими обновлениями. Вот реально, я максимально лояльный пользователь, по жизни вежливый и культурный, но ваше приложение, а точнее — ее обновление, просто вывело меня из себя и сдерживаться я не буду. Вы делаете ГАВНО! И за мои же деньги, мать вашу, вы меня им кормите! Сотрудники Яндекса, которые тестировали приложение до релиза, говорили, что получается плохо, но руководство Я.Музыки отвечало на это примерно так: вы просто не понимаете проблематику и внутреннюю кухню сервиса, а мы понимаем. Релиз обсуждали долго, сотрудники несколько раз пытались донести, что сервис совершает ошибку. Пипл схавает. Какая разница? Последствий всё равно не будет, аудитории некуда переходить. Яндекс монополист с более чем половиной российского рынка стриминга. Тем более по инфе из официального пресс-релиза новый интерфейс повысил такие важные метрики для пользователя, как переход на страницу артиста на 11% и уменьшил количество дизлайков в «Моей волне» на 4%. К посту приложил скрин из корпоративного мессенджера Яндекса с хронологией внутреннего спора о новом дизайне Я.Музыки от одного из сотрудников. И вот самое интересное там: 0. Зацените этот пассивно-агрессивный тон вкупе с корпоративно-ебланским языком. Это владение на уровне мастера. 1. Вы удивитесь, но в самом Яндексе признают агрессивную монетизацию своих сервисов, их перегруженность и неудобство, рекламу на каждом квадратном сантиметре и дарк-паттерны. 2. В Яндексе тоже считают, что в подписку Яндекс Плюс в нагрузку включены ненужные сервисы. Подписка дорожает, а качество этих сервисов ухудшается. 3. Ну и вишенка — работники Яндекса НЕИРОНИЧНО на серьёзных щщах называют себя «яндексойдами».

Где-то два с половиной года назад на конференции по рексистемам в Вышке, куда я пришел слушателем (так появилась секция кулуары, которой, кстати, давно не было), мне задали вопрос — почему у нас нет научных публикаций. Я ответил, что у ребят в Яндексе, занимающихся рексистемами, нет KPI на статьи — только KPI на внедрения. При этом я, конечно, не воспринимал вопрос лично, но сам уже долгое время горел идеей писать статьи, публиковаться на конференциях, участвовать в жизни научного сообщества. Через год я съездил на свою первую большую конференцию ACM RecSys’24. Про эту поездку есть целая серия постов; нетрудно понять, что мне очень понравилось)) Был даже маленький забавный моментик, когда я во время выступления Эда Чи что-то спросил, а он ответил “А может, вы про это статью и напишете” :) После всего этого я еще больше укрепился в решимости начать писать статьи. KPI не то чтобы после этого поменялся, но как будто подвернулся хороший момент, чтобы попробовать. Мы разработали и внедрили в Яндекс Музыку большую рекомендательную трансформерную модель (тот самый Аргус); и казалось логичным превратить это внедрение в статью. Затем, при подготовке лекции для ШАДа про LogQ коррекцию для двухбашенных моделей, я обнаружил ошибку в широко используемой по всему миру формуле. Когда я принес своим ребятам выкладки, далеко не все сразу поверили, что такое вообще возможно)) Было крайне нетривиально одновременно работать фуллтайм, преподавать новый курс в ШАДе и при этом еще и писать сразу две статьи. Но каким-то образом все получилось, и примерно год назад у нас сначала приняли на ACM RecSys’25 статью про LogQ коррекцию, а затем спустя еще полгода приняли на ACM KDD'26 статью про Аргуса. И вот я радостный стою уже 7 часов возле постера на рексисе и рассказываю всем окружающим про LogQ коррекцию)) А потом ночью в караоке пою Radiohead Creep в толпе рексисоидов И самое крутое, что мы на этом не остановились: * на тот же ACM RecSys’25 была принята работа про датасет Yambda, в которой я лично не участвовал, но поучаствовали ребята из нашей команды — Влад Тыцкий и Владимир Байкалов * на ACM SIGIR приняли статью Владимира Байкалова и его студентов из ИТМО про дообучение семантических айдишников * туда же на ACM SIGIR приняли статью от ребят из нашей (бывшей) команды — Артёма Матвеева, Влада Тыцкого, Сережи Макеева и Сережи Лямаева, про улучшение архитектуры энкодер-декодера для generative retrieval Ну и вот сейчас у нас приняли статью на воркшоп ACM KDD’26, продолжающую линию ресерча из статьи Top-K REINFORCE (я периодически шучу, что надо было её назвать "Correcting the Off-Policy Correction" в духе нашей LogQ статьи) и скрещивающую ее с generative retrieval. Про нее я написал в прошлом посте. Кроме того, на архиве появились препринты, про которые смею надеяться, что они дойдут до публикации: * мой Variable-Length Semantic IDs * Gryphon от ребят из Яндекса, в котором поучаствовали Олег Сорокин и Влад Додонов из нашей бывшей команды (читайте подробности про статью на канале Даши @redrecsys) И все это произошло только за последний год! Хочется верить, что мы только в начале нашего пути и нас всех ждет еще миллиард параметров приключений и публикаций :)