Red RecSys

В день рождения - о том что важно. На "фото" (оригинал не покажу, там бардак) - лучший момент моего года. Вернулась в выходной вечером после доклада на дата фесте. Мои мальчишки по праву считают, что мама в выходной работать не должна, у неё на это и так целые пять дней. Свалили меня с ног, привалили к стенке и закидали вопросами-впечатлениями-обнимашками. А я уставшая, у нас всю неделю были экспы, АБ, раздебаги, межкомандные интеграции - мы сводили проект, и тут доклад. И всё это просто исчезло за детским теплом. Растворилось. Остались мы, и у нас всё хорошо. Банально до невозможности, но очень правдиво - ради таких моментов стоит жить. И даже в профессиональной жизни всё самое важное происходит между людьми. Наши архитектуры в статьях и цифры в АБ и код в опен-сорсе ничего не стоят без множества моментов между людьми, которые к ним вели. Общее творчество и общий вызов, брейнштормы, идеи, разборы экспов и статей, поддержка. Позже - возможность поделиться результатами вовне, обменяться идеями и опытом с коммьюнити. Самое тёплое спасибо всем, с кем мы разделили вместе какие-то классные моменты в этот год)

И отдельно хочется подсветить вот этот кусочек текста в тех репорте. Он самый-самый важный. Потрясающие люди. Мы справились)

Sona Technical Report Описываем лучшее внедрение трансформеров в истории АБ-тестов в Яндекс Музыке. Если Gryphon - это именно архитектура, в которой ранжирующий модуль можно учить на разные training objective, то Sona - это сама end-2-end модель, какой мы создали её в службе (читайте пост Коли). Если интересно, что именно в модели поменялось между двумя АБ-тестами - который мы показывали в  Gryphon-v2 и который репортим в Sona - стоит смотреть на табличку с масштабированием слоёв ранжирующего модуля и контекста (и компрессией истории). Коля будет рассказывать о нашем пути на Practical ML Conf, так что не пропустите.

С первым Грифоном поедем на CIKM в Рим! Статью приняли) Кто планирует туда же - пишите в лс, встретимся. Между версиями нет отличий в архитектуре, поменялся только supervision для обучения ранжирующего модуля. На картинке - v2, c дистилляцией на роллаутах. Первый заменял все кандгены + преранк. Второй заменил весь стек: кандгены + преранк + ранкер.

Gryphon-v2 в препринте на arxiv https://arxiv.org/abs/2608.06213 ✅ Описываем наш первый успешный результат замены полного рекомендательного стека одной моделью в Яндекс Музыке. По-честному. Никаких спрятанных между строк оговорок, никаких пост-переранжирований и ревард-селекшнов. ✅ Unified архитектура первого Грифона: encoder + decoder + ranking module. Одна модель генерирует кандидатов через Semantic IDs и сразу ранжирует их, используя cross-attention на выходы зашаренного энкодера. ✅ Алайним генерацию и ранжирование с помощью дистилляции. Подробности ниже. В литературе сейчас есть 2 активных направления ресёрча по объединению кандидато-генерации и ранжирования для замены каскада: OneRec-inspired подходы с RL-ем с одной стороны, и создание unified-архитектур с другой. Мы долгое время целились в первый подход. Он предполагает, что обучить нужно 2 модели: генеративку на Semantic IDs и ранкер. Ранкер используется для оценки reward на выходах генеративки - чтобы с помощью RL заалайнить модель на более "профитные" выдачи, которые должны больше понравиться пользователям. Для полной замены каскада генеративка должна стать настолько хорошей, чтобы переранжирование уже не требовалось. По факту переранжирование полноценным ранкером при внедрении остаётся практически всегда, хотя это не всегда считывается с текстов статей. Unified-ресёрч у нас родился незапланированно. Мы стартовали с Process Reward Model (об это рассказывала на дата-фесте). Проверяли, насколько модель подвержена накопленной ошибке beam search, завели и доработали PROMISE для оценки траекторий генерации. По сути в PROMISE уже есть ранжирующий модуль, только скорит он семантики, а не финальные айтемы. Законный вопрос. Если мы можем скорить семантики - почему не сделать это для айтемов? Так и родился Gryphon. У Грифона была всего одна проблема. Он не RL-ился в чистом виде. Можно за-RL-ить генеративную часть, но в наших экспах на кандидато-генерации мы видели, что даже одно-слойный ранжирующий модуль Грифона значительно меняет итоговую выдачу, при этом с большим приростом на метриках. Как кандген он себя доказал, но end-2-end моделью в первоначальном виде стать не мог. Обучение ранжирующего модуля на фидбеки (как UniPinRec) могло стать логичным следующим шагом, но качественно проучить ранкер без авторегрессии было бы слишком дорого, а авторегрессия в Грифон не ложилась. Казалось, что для алайна ранжирующий модуль придётся убирать. Мне конечно хотелось, чтобы он остался частью финального рецепта. Мы много вложились в него. Мне нравилась экспрессия архитектуры - потому что мы смогли выбить качество кандидато-генерации выше, чем давал полный softmax по каталогу. Нравилась концепция "сгенерируй варианты, и потом подумай, какие из них лучшие" - аналог рассуждений в ллмках. Мы подумали - и не стали его убирать. Финальным решением стала роллаут дистилляция ранкера в ранжирующий модуль Грифона. Во время обучения текущий декодер генерирует кандидатов через beam search, а ранжирующий модуль учится воспроизводить скоры учителя для данного роллаута. Так грифон качественнее скорит кандидатов, похожих на те, с которыми встретится на инференсе. По сути это тоже алайн генеративки с ранжирующей моделью, но архитектура самой генеративки более экспрессивная, а вместо RL используется дистилляция (при этом всё ещё на выдаче декодера). Роллаут дистилляция как финальный рецепт обучения соло-модели по сути вобрала в себя огромный объём ресёрча всей службы. Тут слились вместе идеи и результаты экспов с дистилляцией в рекламном ранжировании, экспы с обучением ранкеров для ревардной оценки в Музыке, экспы с самим Грифоном и генеративкой, идеи из последней литературы, да и сама концепция двух задач в претрейне Аргуса. Всё это стало кирпичиками для итоговых экспов с Gryphon-v2. Для меня участие в этом проекте было совершенно невероятным опытом.

Хардовые будни как обычно надо компенсировать фоточками в канале, так что ловите) Они тут прилетели с мероприятий в июне, и есть кадры сразу с несколькими очень крутыми людьми. Саша Плошкин - лид команды архитектур с ранним связыванием, с которым мы оба заводим новые технологии для рекламного домена. И Аня Липкина - лид команды разработки рекомендательных сервисов, с ней мы вместе (как и большая часть службы) работаем над проектом end-2-end модели для Музыки. А ещё, пользуясь случаем, советую подписаться на Сашин канал. У Саши классный опыт в ранжировании и он очень содержательно пишет про рекламу.

Препринт Gryphon) https://arxiv.org/abs/2606.08604 Ключевое: объединили архитектурно генеративный ретривал на Semantic IDs с ранжированием и задеплоили с успешным А/Б. Если судить по препринтам, именно в таком сочетании - первые в мире) Тут конечно нужна очень важная оговорка: "To the best of our knowledge, ...". Я вполне могла за последний месяц что-то пропустить в экспах-докладах-статьях. Делитесь в комментах, если это так. Например, пропустила статью от Pinterest, которая вышла за пару дней до моего доклада "UniPinRec: Unifying Generative Retrieval and Ranking at Pinterest Scale". В чём ключевые отличия: 1. В архитектуре Pinterest нет генеративного ретривала, как его опредeлил в своё время Google в "Recommender Systems with Generative Retrieval". Авторы используют двухбашенную архитектуру в части кандгена 2. Pinterest использует BCE головы на разные бинарные таргеты в стандартной индустриальной постановке задачи для ранкера: feedback prediction. Мы в статье показываем результаты обучения ранжирования на InfoNCE для задачи next-item prediction. В чём ключевые сходства: 1. Зашаренный энкодер для кандидато-генерации и ранжирования с KV-cache, объединённое обучение двух задач, request-level организация обучающих сэмплов, cross-attention ранжирование. Подходы один-в-один 2. Подобные архитектуры нацелены на то, чтобы предложить альтернативный (или дополняющий) подход к end-2-end генеративным рекомендациям на базе RL. При первых успехах этими архитектурами хочется делиться с коммьюнити. Однако завести их в end-2-end задаче всё ещё непросто и требует большого количества экспериментов. Поэтому и мы, и Pinterest показываем результаты АБ не в end-2-end сценарии, а в более простом и тем не менее очень важном: мы заменяем весь стек вплоть до финального ранкера. Ждём больше работ с подобными подходами) Мы статью подали на CIKM в short paper track. PS. Ребятам, с которыми мы вместе работаем - вы лучшие ❤️!

Вопросы по Грифону. Часть I. "Chain-of-Recommendation" Было много вопросов к докладу, которые мне задали лично или в tg. Понемногу их раскрою, потому что в 25 минут рассказа не успела вместить всё, что на самом деле хотела бы рассказать. 💬 Скорит ли ранжирующий модуль только айтемы внутри коллизии? (Короткий ответ: Нет, это полноценный скоринг всей выдачи GR) Beam search выдаёт нам пул Semantic IDs (например 1000). Мы делаем маппинг семантиков в айтемы и получаем пул Item ID (например 1200 с учётом того, что какие-то семантики мапятся в несколько айтемов). Мы считаем данный пул айтемов кандидатами для ранжирования. Ранжирующий модуль (ORM) "забывает" скоры beam search, скорит всех кандидатов по собственной логике и выдаёт финальный отранжированный список айтемов. При обучении ORM на Next-Item-Prediction (InfoNCE лосс как в докладе) задачей Грифона остаётся кандидато-генерация. При этом его выдача будет отличаться от ванильного GR за счёт нескольких пунктов: 1. ORM оценивает релевантность на уровне конкретного айтема, а не на уровне Semantic ID 2. ORM нивелирует накопленную ошибку beam search, в результате которой скоры beam search могут некорректно ранжировать сгенерированные семантики 3. ORM обладает более экспрессивной архитектурой по сравнению с генеративной частью. По сути мы повторили в ORM архитектуру Аргусных ранжирующих моделей на основе Cross-Attention - каждый кандидат "ходит" с помощью Cross Attention в hidden states энкодера над историй пользователя, и итоговый вектор используется для оценки релеватности айтема. Именно экспрессивность архитектуры позволяет нам показывать качество выше полного софтмакса. 4. Для того чтобы в ORM попадал полный пул кандидатов, стоит расширять последний бим (что дёшево), а также либо расширять предыдущие бимы (вариативный бим сайз), либо использовать PRM. Такие расширения бима (у нас не больше чем в 2 раза) в наших экспериментах имели большое влияние на качество выдачи Грифона, и при этом не влияли на качество выдачи ванильного GR (его подводит накопленная ошибка beam search). 💬 Честный ли замер при сравнении с GR в плане компьюта? (Короткий ответ: Да) Все замеры на моих слайдах показаны при сопоставимом количестве параметров моделей и сопоставимом времени инференса. Для сравнения Грифона с GR мы убираем один слой из декодера GR и отдаём его в ранжирующий модуль. И тут ещё уточню, что все реколлы, которые я показывала - это recall@1000. Презентация корректная та что скинула в канал) 💬 Есть ли похожие подходы в литературе? (Короткий ответ: Думаю, что скоро будут) Пока я готовила презентацию для датафеста, как раз вышла первая статья, в которой прямо заявляется именно объединение GR с ранжированием в одной модели. Мне очень понравилось обозначение концепции, авторы назвали такой подход "Chain-of-Recommendation". Он здорово отражает суть происходящего. В этой работе нет речи о внедрении, замеры только на одном публичном датасете, и это скорее клейм на саму концепцию. Но идейно это именно то, к чему мы стремимся с Грифоном. Отличие в том, что мы начали с задачи Next-Item-Prediction, и теперь уже после неё экспериментируем с правильным supervision и рецептом обучения для ранжирующего модуля. В целом крупные мировые компании активно исследует End-2-end рекомендации, и архитектуры по типу Грифона и Chain-of-Recommendation выглядит в таких направлениях очень органично. Ждём больше интересных работ)

Делюсь презентацией доклада про Грифон

Еду сейчас домой с датафеста. Спасибо, что пришли, крутой день) Было очень много вопросов в чате и в кулуарах, я попозже доберусь ответить в канале на ключевые

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

Дата фест в этом году не стал делать отдельную RecSys секцию, так что доклады по теме можно поискать в разные дни и в разных местах. Я свой буду рассказывать в секции "Practical ML". Программа тут Моя тема: "Гибридная генеративно-ранжирующая модель на базе Semantic IDs в рекомендациях Яндекс Музыки". В этой же секции будут доклады о том, как в Яндексе трансформируют Argus - от Саши Плошкина и от Жоры Смирнова. Я немного знаю обе истории и уверена, что будет очень интересно. Выглядит так, что со многими увидимся 31 мая в Яндексе)

Накопился целый список мини-историй, которым хочу поделиться. Канал Ильдара Сафило. Ильдар сейчас работает Engineering Manager в FAANG в Лондоне, а познакомились мы, когда он собеседовал меня в МТС в 2022. В работе с Ильдаром (и Эмилем) как менторами я поняла, что теперь всегда буду искать в руководителе 3 супер-важных качества - экспертизу, увлечение своим делом и неподдельную человеческую открытость. Беспроигрышное сочетание, которое накидывает +100 к мотивации всей команды. В канале Ильдар пишет о RecSys, ML и AI в рекламе, собеседованиях и работе в FAANG. Я вообще очень ценю, когда люди выкладывают подробные истории про множество зафейленных собесов с финальным выходом в хорошую компанию на отличную должность. Такие истории помогают собрать в голове картинку того, как в целом работает система, без необходимости тратить огромное количество времени на то, чтобы набивать собственные шишки. Кроме Ильдара я читала, например, Юру Кашницкого и Андрея Лукьяненко. Свои собесы потом прошла без проблем и с нулевым количеством отказов, хотя сейчас думаю, что на вопрос "расскажи о себе" нужно всё-таки иметь сочный отрепетированный рассказ минут на 5-7, а не скромное "делала вот это и вот то". Канал Радослава Нейчева. Увидела случайно и удивилась, что только сейчас. Когда я на своём пути самоучки понимала, что мне не хватает NLP, по базовым темам смотрела чаще всего его лекции для МФТИ и DLS. Ну и gentle introduction to transformers Игоря Котенкова. Сейчас из любопытства ещё раз покликала пару лекций Радослава - и наткнулась на идеальное объяснение, почему так много в области DL англицизмов. Мне иногда прилетают вопросы на английские термины в моих материалах. Почему ничего не поменяется - советую послушать тут Мой разбор QARM-v2 в Рекомендательной. Расскажу инсайт, что многие посты в Рекомендательной начинаются с докладов на внутреннем IR семинаре Яндекса. Я там делаю доклады редко (в общем-то впервые), потому что мы с командой сфокусированы на узких разборах по темам Semantic IDs и Generative Retrieval. И объём свежей литературы для нас всё ещё зашкаливает, разбираем 2-4 статьи в неделю. Но QARM-v2 мне настолько зашёл, что в этот раз вытащила на общий семинар. Kuaishou дают много идей и интуиции о том, как качественно делать эмбеддинги и квантизацию для семантического индекса - и почему именно так. Ещё сейчас собирают заявки на доклады на PML и DataFest. Я подалась на второй. Вообще всегда тяготела к выступлениям на камерных RecSys митапах, так что у меня есть тут не-закрытый пунктик про доклад на большую аудиторию. И сейчас как раз появилась хорошая тема. Посмотрим, как выйдет (и что успеем дофиналить к докладу, если пройду 😎).

Сегодня в Калининграде на одном из эвентов Яндекса. На похожем мероприятии я была почти год назад - в этом же городе, в этом же отеле, ровно у этого озера. Где-то здесь и прижилась мысль, что может всё же стоит пойти поработать с этими ребятами) С тех пор это был очень насыщенный путь. Сейчас я работаю над проектами, которые требуют абсолютной вовлеченности (а иначе неинтересно!). Узнаю тонну нового. И проживаю успехи и челленджи в компании совершенно невероятных, очень близких мне по духу людей. Такой вот пост, навеянный утренним Калининградом) Не всё же лекции читать

Читала сегодня в ИТМО лекцию по Semantic IDs и Generative Retrieval в рамках курса по продвинутым рекомендательным системам. Первый опыт, когда материал для лекции я собирала с нуля - на основе большого количества статей по теме. А сами статьи перед этим много и подробно разбирали внутри команды. Было здорово разложить наконец всё по полочкам) Материалом делюсь

Шикарная штука из Твиттера, оказывается Опус может генерировать простенькие видосы с текстом напрямую через moviepy и ffmpeg. Всё воспроизвелось, вот мой видос. Оригинальный промпт: "can you use whatever resources you like, and python, to generate a short 'youtube poop' video and render it using ffmpeg ? can you put more of a personal spin on it? it should express what it's like to be a LLM"

Я просто не могу это не репостнуть. Мама как-то спрашивала меня, как шутят люди моей профессии

Вышла вторая часть подкаста с Витей Кантором. Озвучиваю много неоднозначных вещей, которые лично мне зашли (и с которыми многие активно поспорят): - если не «прыгать» между компаниями, а строить качественные проекты на одном месте, это здорово помогает расти - нужно один раз хорошо проработать тему и не иметь потом с ней проблем (никогда не ходила на «тренировочные» собесы, чтобы «щупать рынок» - и реальные собесы я при этом не заваливала) - problem-solving и умение «докопаться» до сути это мета-навыки для карьерного роста - опыт вне data science может давать большие преимущества И в целом рассказываю про свою подготовку к собесам, лайфхаки в изучении нового материала и всякое разное. Подкаст мы записывали в конце декабря, на youtube ему дали заголовок «LLM не думает за тебя». Но после активной работы в курсоре с Opus 4.5/4.6 в январе-феврале я уже не могу с этим согласиться. И думает, и кодит, и статьи имплементирует, и баги фиксит, и домашки студентам создаёт, и их же решает. Но всё ещё не сделает тебя специалистом за тебя.