Приглашаем на RecSys Meetup!

Когда? 28 августа, старт в 18:00
Где? Москва + онлайн-трансляция

Обсудим актуальное из мира рекомендаций: от передовых архитектур для построения Semantic IDs и их внедрения в продуктивные системы, до тонкостей балансировки интересов пользователей и продавцов маркетплейса с помощью онлайн-доранжирования и байесовской оптимизации

В программе:

🚩 «Semantic IDs: архитектура и наш опыт внедрения» | Александр Тришин, Data Scientist в команде персональных рекомендаций

🚩 «Счастье пользователя vs счастье продавца. Онлайн доранжирование и байесовская оптимизация в товарных рекомендациях» | Андрей Ветров, Data Scientist в команде товарных рекомендаций

🚩 «Как мы обучаем CLIP-ы для текстовых тегов» | Михаил Киндулов, CV Engineer в команде Поиска по фото

🚩 «Трансформеры в Wildberries & Russ: от гипотез до AB-тестирования» | Иван Ващенко, DS Stream Lead в команде персональных рекомендаций

Регистрация уже открыта! PS: для участия в офлайне регистрация обязательна.

#wbtech #wbmeetups #wbspeakers #wbml #wbrecsys

🟣 Сегодня закончилась моя испыталка в WB

Теперь я точно могу объявить, что тружусь над перс реками в Wildberries!

кстати у нас недавно была конфа

На самом деле вокруг много очень талантливых людей, что невольно считаешь себя на птичьих правах. Но это определенно дает вектор куда тебе двигаться и мотивирует моего синдрома самозванца.

Пока что я немного ушел от академии, как-то не складывается у меня с ней в этом году. Получил три реджекта, провалился с аспирантурой, да и устал от учебы.

В планах вернуть свой прайм и раскачать свой бренд 😎

✅ TorchRec — библиотека для реально больших рекомендательных систем

Когда слышишь про Meta (Facebook) и их модели с триллионами параметров, сразу возникает вопрос: а как вообще это всё тренировать и запускать? Ответ — TorchRec.

Это часть PyTorch, заточенная именно под RecSys: огромные embedding таблицы, шардинг на десятки GPU и inference в продакшене на C++.

Почему это must-have?
✍️ Разреженные данные без боли: embedding bags и jagged tensors закрывают все мучения с категориальными фичами.
✍️ Шардинг под ваши задачи: row-wise, column-wise, table-wise — оптимальная стратегия сама найдётся для кластера.
✍️ Гибридный параллелизм: данные + модель → обучение монстров с триллионами параметров.
✍️ FBGEMM под капотом: квантование и оптимизированные ядра, которые реально ускоряют обучение.
✍️ Датасеты и модели из коробки: Criteo, Movielens — сразу можно тестировать идеи.
✍️ Продакшен-ready: seamless переход от PyTorch к C++ inference.

➡️ Torchrec

Такое нам надо, такое мы импортируем себе

#RECSYS

‼️ Кстати, важная новость!

Для всех кому я интересен, и похожий контент, но не про рисерч!

Я активно веду канал @danyatyping и приглашаю ВАС поддержать моё творчество.

Искренне был бы рад вашей активности в комментариях, в чате хочу делиться с вами своим каким-то опытом, фишками про карьеру, про лайфстайл, хобби и мимолетные радости жизни.

А в рисерчошной оставить контент более строгий и тематический.

➡️ @danyatyping

4️⃣5️⃣6️⃣

Почему двухбашенные модели тайно бустят только популярные товары

Мои коллеги из Wildberries выпустили классную статью про то, что мы обычно не замечаем при обучении two-tower моделей.

Оказывается, даже если мы используем cosine loss (кажется же, что он не должен учитывать популярность), эмбеддинги популярных товаров растут быстрее. В итоге модель начинает ещё сильнее “подсвечивать” и без того востребованные айтемы.

По сути это значит, что «богатые становятся богаче» — популярные товары лезут в топ рекомендаций просто из-за нормы векторов, а не качества совпадения. Вот такой вот капитализм…

Жаль, что написали на хабр, вообще выходит на научную министатейку. Но несмотря на это там много объясняющей математики (другой вопрос нужно ли она на хабре?) почему такие процессы получаются.

➡️ Читать на Хабре

❗Желаю коллегам из лабы удачи и ждем от них больше хорошего рисерча в паблик и науку

MADE IN @researchoshnaya

✅ Нашёл имбовый датасет для ресёрча — T-ECD


Команда T-Bank выложила на Hugging Face огромный синтетический датасет в кросс-домейн рекомендациях.

В нём намешаны сразу разные сферы: маркетплейс, ритейл, покупки, промоакции, отзывы. Получается такой мини-«мир e-commerce», где видно, как пользователь ведёт себя в разных уголках экосистемы. При этом данные синтетические, так что приватность жива и здорова.

Есть full (~135B интеракций, 44M юзеров, 30M товаров, 1300+ дней) и компактная small (~1B, без платежей).

На самом деле не так уж и много хороших и больших кросс-домейн датасетов. Что сильно ограничивает рисерч в этой теме.

В T-ECD фичи завязаны на пять доменов (marketplace, retail, payments, offers, reviews).

Основное:
✍️user_id и brand_id согласованы во всех доменах.

События:
✍️ action_type: view, click, add-to-cart, order, transaction
✍️ subdomain: catalog, search, recommendations, checkout, campaign (для marketplace/retail)
✍️ item_id: в доменах marketplace, retail, offers
✍️ brand_id: присутствует во всех доменах
✍️ price, count
✍️ os: только для marketplace и retail

Каталоги:
✍️ items.pq → item_id, brand_id, категории, pretrained embeddings
✍️ users.pq → регион, социо-демографический кластер
✍️ brands.pq → brand_id, метаданные и embeddings

Специальные структуры
✍️ payments/receipts → детализация чеков: товары, количество, цены; связаны с marketplace/retail
✍️ reviews → рейтинги брендов + pretrained text embeddings (без сырого текста)


Очень круто, что компании начали выкладывать в опенсорс датасеты, хоть и синтетические.

➡️ Hugging Face T-ECD

#RECSYS

MADE IN @researchoshnaya

🏋️Вот что я узнал на Practical ML Conf

На выходных был на конференции от Яндекса. Возможно, кто-то из вас даже видел меня там.

Честно говоря, рексиса оказалось многовато, а по-настоящему сильных выступлений — меньше, чем хотелось бы. Ведущие (не спикеры) выглядели так, будто впервые вышли на сцену: сбивались, терялись, аудитория их почти не слушала.

Зато было то, ради чего я всегда жду такие мероприятия. Например, доклад Коли про Argus (HSTU). Он как спикер очень силён: харизматичный, чёткий, а главное — рассказал массу нового про обучение, кросс-домейн, трики и реальные проблемы, с которыми они столкнулись. Его презентацию точно стоит посмотреть.

В кулуарах тоже вышло насыщенно: обсудили семантики, hashing tricks, Tiger, OneRec и свежую статью Яндекса про logQ-коррекцию.

И да, не могу не отметить бытовое: сырный попкорн, классный кейтеринг и афтерпати с барменами и кальянами. Атмосфера — на уровне.

➡️ Канал Коли с презентацией

❗️А вы сами ходите на конференции ради докладов или ради вкусной еды?

MADE IN @researchoshnaya

✅ Как искать иголку в стоге миллиардов — и находить за миллисекунды

Вы когда-нибудь задумывались, как векторные базы данных быстро находят похожие объекты в гигантских коллекциях?

Есть такой алгоритм — Hierarchical Navigable Small World, который сегодня используют большинство векторных хранилищ. Он уже работает эффективно и останется релевантным по мере роста объёмов данных.

HNSW строит многоуровневую сеть. На верхних уровнях остаются только дальние связи — это как авиамаршруты между крупными городами.

Внизу находятся все векторы; они связаны плотно, как улицы и кварталы. Каждый слой вниз содержит больше объектов и короче связи. Такая иерархия позволяет сначала быстро приблизиться к нужной области, а затем выполнить детальный локальный поиск — без перебора всего набора.

Как это выглядит на практике: сначала «подлетаем» по верхнему уровню, затем уточняем район на среднем, и в конце спускаемся в нижний слой для точного поиска.

Сначала алгоритм отбрасывает явно нерелевантное, а потом проверяет ближайших соседей — поэтому он остаётся быстрым даже при миллиардах векторов.

При настройке обратите внимание на три параметра.
➡️maxConnections управляет плотностью связей: больше связей повышает точность, но увеличивает затраты на память и индексацию.
➡️ ef и efConstruction задают размер кандидатного списка при поиске и при построении индекса: их увеличение обычно повышает точность, но замедляет работу.
➡️ Наконец, выбор метрики (косинус, евклид и т. п.) определяет, какие объекты считать похожими в вашей задаче.

❗️Меня кстати пару раз спрашивали на собесах как работает HNSW, поэтому решил чуть освежить память, да и часто в работе применяется. Надеюсь получилось классно вам объяснить, накидайте реакций если хотите побольше таких постов

#RECSYS

MADE IN @researchoshnaya

✅ ACM начали выкладывать видео с RecSys 2025

Помните тот вайб, когда открываешь YouTube и случайно залипаешь на гайд какого-то индуса ML?

Так вот, тут не случайно: ACM выкатили 67 записей RecSys 2025. Да, почти вся конференция теперь в открытом доступе.

— YouTube: ACM RecSys — чтобы сразу включить «фоном».
— SlidesLive — чтобы видеть графики, архитектуры и все те мелкие детали, за которые мы любим доклады

#RECSYS

MADE IN @researchoshnaya

💎 А какие каналы читаете вы по рексису?

Давайте соберем в комментариях как можно больше классных каналы по рексису, которые вы читаете!

Я начну
➡️ @wildrecsys — канал нашей команды в WB
➡️ @recsys_for_all — канал Олега из Т-банка
➡️ @Recsys_IR_Travel — канал Саши из Spotify
➡️ @WazowskiRecommends — канал Мишы из Meta
➡️ @knowledge_accumulator — канал Саши из X

Остальных напишу в комментариях 🤨

4️⃣5️⃣6️⃣

Как WB сделал «Поиск по фото»

Продолжаю рассказывать про прикольные проекты коллег. В этот раз прикольную фичу — поиск по фото, которой я сам частенько пользуюсь. Особенно если нашел какую-то прикольную вещь в рилсах, или буквально недавно нашел чайник-термос в одном заведении.

С точки зрения юзера схема супер простая: Заскринил — загрузил — выделил нужный объект — выбрал нужный товар. Кстати прикольно, что у нас есть OCR по объектам, я такого в других местах не встречал. Можно по одному фото сразу несколько вещей найти.

Под капотом там не просто CLIP, сначала YOLO вырезает объект, OCR снимает артикулы/текст, потом SigLIP-эмбеддинги улетают в векторный поиск Qdrant (HNSW). Товары лежат уже в эмбеддингах заранее.

Самое интересное — мультимодальная логика: поиск живёт не только в изображении. Фото обогащают тегами, которые заранее сгенерированы LLM офлайн по описаниям и визуальным признакам.

Пост у ребят получился достаточно понятным, почти все технические детали разобрали, мне было легко читать.

➡️ Почитать можно тут


❗Ставьте 🔥 огонек если пользуетесь поиском по фото

MADE IN @researchoshnaya

4️⃣5️⃣6️⃣

Недавно прочитал в блоге Netflix очень занятную статью — про Advantage-Weighted Supervised Finetuning.

Если коротко, это их новая техника пост-тренинга для генеративных рекомендательных моделей — такая, знаешь, “упрощённая альтернатива RLHF”, но сделанная очень по-инженерному и приземлённо.

Значит они берут уже натренированную генеративную модель, которая умеет “писать” рекомендации
и дообучают её не просто на пользовательских примерах, а с учётом преимущества (advantage) — насколько текущее предсказание лучше среднего по reward-модели.

По сути это reward-learning без RLHF

Это прикольно, потому что RLHF в рекомендациях — это боль. Нужно как-то разруливать шум, дефицит логов, инфраструктуру и дорогостоящие онлайн-итерации.

Да и честно говоря RL в рексисе не особо приживается пока что.

Кроме того от Netflix наконец-то говорят про генеративные Recsys…

➡️ Netflix Tech Blog — Post-Training Generative Recommenders with A-SFT


❗Ставьте ❤️‍🔥 сердечки если верите в генеративную персонализацию

MADE IN @researchoshnaya

✅ Китайцы выкинули 80% GPU — а оптимизация выросла.

Alibaba Cloud на конференции SOSP’25 показали систему Aegaeon — призванную оптимизировать inference‑набор генеративных моделей на маркетплейсе.

Каким-то магическим способом они сократили использование GPU на 82% для обслуживания генеративных моделей. Было 1192 GPU — стало 213.

Идея в том, что они делают динамический GPU-пуллинг на уровне токена.

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

Aegaeon объединяет модели с разной нагрузкой, перераспределяет GPU между ними, следит за токен-latency и tail-задержками.
и делает это без потери качества генерации.

17.7% GPU раньше обслуживали всего 1.35% запросов. после Aegaeon — ресурсы утилизируются почти полностью.

➡️ SOSP’25 — Aegaeon: Effective GPU Pooling for Concurrent LLM Serving


❗Кстати мой коллега уже показал нашим MLOPSам

MADE IN @researchoshnaya

4️⃣5️⃣6️⃣

Недавно на архиве я прочитал работу с громким названием про «Massive Memorization…» и новую схему VISTA от Meta для генеративных рексистем.

Если по-честному, меня зацепило простое обещание: учиться на пожизненной истории пользователя хоть до миллиона событий, но держать инференс по цене “фикс”. Типа, не страдать от длины хвоста и при этом не сжигать кластеры.

Классические подходы делятся на “берём всё” как в HSTU и “берём релевантный срез” как SIM/TWIN, но оба упираются либо в дорогую полную прогонку, либо в линейный рост стоимости по числу кандидатов. Ну да, боль индустрии знакомая.

Концептуальная идея VISTA — разнести обучение и инференс на два шага и закэшировать «суть» пользователя заранее. Сначала длиннющая UIH сжимается в пару сотен эмбеддингов с помощью виртуальных “seed”-токенов, потом на инференсе кандидаты смотрят только на этот компактный буфер. Короче Summary-как-сервис.

Фишка в том, что эти summary-эмбеддинги выгружаются в отдельную систему доставки эмбеддингов и живут в KV-хранилище от терабайтов до петабайтов, а модель на проде просто их подтягивает и считает target-attention. Ну да, хранение дешевле GPU — звучит прагматично.

Чтобы вся эта история не умерла на софтмаксе, они прикручивают quasi-linear attention: линейная по длине последовательности формулировка, без “перетекания” внимания между кандидатами, чтобы не ловить leakage. Что-то в духе Lightning/Mamba-лайна, но под рексисы.

Плюс сверху кладут генеративный reconstruction-лосс, который заставляет summary реально «выписывать» исходную последовательность, а не делать вид. Такая, ну, дисциплина для памяти модели.

В статье есть внятная схема двухступенчатой архитектуры и раздел про “Embedding Delivery System” — как говорится спасибо META за систем дизайн. Они пишут, что так держат стоимость инференса постоянной и уезжают в пожизненные истории до 1M событий.

Есть офлайн-абляции: QLA даёт ускорение и позволяет ходить к 16k длине на блок больше при сопоставимых метриках. Да, детали по NE/AUC там свои, но тренд понятный.

И главное — они гоняли онлайн A/B на 5% трафика 15 дней и заявляют значимый рост ключевых метрик потребления и онбординга против HSTU. Для меня это сильнее любого офлайна, сорри.

➡️ Ссылка на статью


❗Накидайте огоньков 🔥, говорят так посты выходят чаще

MADE IN @researchoshnaya

4️⃣5️⃣6️⃣

На EMNLP 2025 в Китае представили новый способ быстрого обучения больших языковых моделей логике без особых финансовых затрат. Метод разработали наши исследователи из T-Bank AI Research и Центрального университета.

Его главная фишка в том, что вместо полного “переписывания мозга” в нем используются векторы-настройки (steering vectors), которые точно усиливают логические цепочки в рассуждениях. В будущем метод может помочь сделать языковые модели более интерпретируемыми.

На шести математических бенчмарках метод показал и доказал, что реально эффективен: он сократил память с гигабайтов до сотен килобайт и ускорил один из этапов обучения в сотни раз. При этом у 14-миллиардной модели изменения коснулись только нескольких сотен тысяч параметров.

Для меня главный инсайт в том, что сложные reasoning-навыки можно улучшать точечно, без переобучения всей модели. Получается, что даже при весьма ограниченных ресурсах можно будет создавать специализированных ассистентов.

➡️ Steering LLM Reasoning Through Bias-Only Adaptation

❗Как считаете, какие еще скиллы нужно развивать у ИИ?

MADE IN @researchoshnaya

🦖 Вот в последнее время я много время уделяю генеративным рекомендациям, но что бы их обучить надо крайне много данных. А вы вообще представляете как решают проблемы с таким объемом данных ведь просто нереально держать такие матрицы эмбеддингов в памяти?

Можете попробовать угадать в комментах

4️⃣5️⃣6️⃣

Главный bottleneck в рекомендациях — embedding-таблицы

Давно хотел рассказать про такую интересную штуку как unified embeddings, и кажется, что этот подход реально БАЗОЙ в генеративных рекомендациях.

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

В отличие от LLM где вокабуляр составляет 40-50 тысяч токенов, мы оперируем миллионами товаров и пользователей. Поэтому мы ограничены как в расчете full CE, так и в том что-бы хранить все пространство.

И вы знаете, мы неплохо научись бороться с этим бутылочным горлышком. Если нам тяжело и дорого считать всё напрямую — давайте считать приближенно.

Один из таких подходов предложили исследователи Google под названием Feature Multiplexing: вместо независимых таблиц для каждого признака модель использует единое пространство эмбеддингов.

Причем размеры этой таблицы мы можем задавать сами — а лукапы реализовать через агрегацию по хешам. Таким образом, один унифицированный эмбеддинг товара несёт семантику сразу из разных источников.

По сути вы заставляете модель, в каком-то линейном слое, научить правильно декодировать эмбеддинг.

Безусловно за все хорошее надо платить — теперь у вас открывается пассивный навык в виде 1-5% коллизий.

Кроме Google unified матрицы используют Pinterest, Netflix, Yandex, WB, определенно стоит присмотреться!

➡️ Unified Embedding

❗В предыдущем посте кстати угадали альтернативную версию — semantic id. Одну из проблем мы решили, но вот вам следующий кейс: FullCE вы считать не можете у вас слишком много классов, а что тогда?

MADE IN @researchoshnaya

✅ Любишь logQ применять — люби и частоты считать.

Но мало кто знает, как решить одну из вечных болей — расчёт частот по миллиардам item_id.

Вы все знаете этот кошмар, когда надо делать logQ-коррекцию или семплить негативы по популярности. Ты берёшь огромный словарь на Python и начинаешь его заполнять частотами.

Особенно если вы сильно ограничены ресурсами, тогда у меня для вас плохая новость. Таблица частот для 10^9 ~ 4ГБ, и вроде бы не страшно, НО на каждый порядок она будет увеличиваться кратно.

Так вот знакомьтесь — CMS (Count-Min Sketch).

CMS — это маленькая таблица фиксированного размера, которая не растёт, даже если у тебя миллиард новых ID каждую неделю.

Ты просто пропускаешь item’ы через несколько хэшей и обновляешь счётчики в таблице.

Когда нужно узнать частоту — берёшь минимум из нескольких значений.

       cols →
     0   1   2   3   4   5   ...
h₁ [ 0 | 5 | 0 | 2 | 0 | 1 | ... ]
h₂ [ 3 | 0 | 4 | 0 | 2 | 0 | ... ]
h₃ [ 0 | 1 | 0 | 3 | 0 | 2 | ... ]

Один и тот же ID каждый раз попадает в одни и те же клетки, аккуратно увеличивая их значения.

В итоге у тебя всегда есть приблизительная частота, причём погрешность минимальна и даже полезна — слегка занижает популярность самых жирных item’ов, давая тебе бесплатную регуляризацию в logQ и sampled negatives.

Конечно, если вы не считаете миллиарды айтемов будет проще посчитать линейным методом. Но если вы условный Pinterest — вам скорее всего придется искать приближенные методы.

❗Мне особенно понравилась эта статья, она похожа на Unified Embedding. Эти два поста напомнили мне подход ученых к астрономии, если вы не можете что-то посчитать точно, вам достаточно найти приближение.

MADE IN @researchoshnaya

🎉 ИТОГИ 2025 ГОДА

Подписчики, я поздравляю всех с наступающим 2026 годом! А мы подводим итоги года.

За год я написал 73 публикации, которые набрали аж 146 тысяч просмотров. Немногонемало прибавилось аж 603 новых подписчика.

Для меня этот год был и остается одним из действительно сложных, особенно в принятии решений, в прикладывании титанических усилий не всегда дающих ожидаемые результаты. Но несмотря на это, самым продуктивным за все время!

За год произошло новое, но вот что меня радует:
1. Приняли статью про дистилляцию знаний из LLM в RecSys трансформеры
2. Разбирали с вами много статей про генеративный рексис
3. Продвигали рисерч в массы

Очень рад повстречать новых крутых людей в своей жизни, невероятных талантов и прекрасных личностей. Очень рад был познакомиться с ребятами и помогать тем кто начал так-же развивать свои ТГК.

В следующем году хотелось бы достичь отметки свыше 10 тысяч подписчиков, написать еще как минимум одну статью.

MADE IN @researchoshnaya