Ускорение раннего связывания для моделей ранжирования
База
В двухэтапных рекомендательных системах используются кандидатогенерация (кандген) и ранжирование.
На этапе кандгена простые модели (например, DSSM, двухбашенные архитектуры) отбирают наиболее релевантные айтемы для пользователя. Из-за большого количества айтемов применяется позднее связывание (late interaction) — например, через скалярное произведение векторов пользователя и кандидатов.
На этапе ранжирования более сложные модели (например, CatBoost или нейросети) переупорядочивают кандидатов, учитывая дополнительные фичи, такие как счетчики взаимодействий или контекст пользователя.
Контекст
В последние годы крупные компании (Google, Meta, TikTok, Pinterest ❤️ , LinkedIn, Alibaba ) активно внедряют нейросетевые модели ранжирования, которые учитывают глобальный контекст пользователя.
В статье Amortized Inference предложен метод, улучшающий SOTA-результаты для этой задачи.
Авторы берут за основу две модели с ранним связыванием (early interaction):
BST (Behavior Sequence Transformer) — кандидат добавляется в конец истории пользователя.
TransAct — кандидат конкатенируется к каждому айтему в истории.
Обе модели используют трансформеры, что позволяет оценивать кандидата с учетом всей истории. Однако у них есть ключевая проблема — высокая вычислительная сложность.
Проблема
Для каждого кандидата модель заново обрабатывает историю пользователя.
Сложность:
O(n^2⋅m⋅d+n⋅m⋅d^2)
где:
n — длина истории,
m — число кандидатов,
d — размерность эмбеддингов.
При больших
n и m (например, 1000+ кандидатов) это приводит к высоким задержкам и делает модель непрактичной для прода.
Решение
Авторы предлагают конкатенировать всех кандидатов к истории и прогонять через трансформер один раз, а затем учить модель предсказывать таргет для каждого кандидата отдельно.
Новая сложность:
O((n+m)⋅d^2+(n+m)^2⋅d)
Это дает значительное ускорение, если
m>2 (что почти всегда верно в рекомендательных системах).
Результаты
+0.18% к качеству (A/B-тесты).
+5% к latency (vs. +56% у BST и +52% у TransAct).
Вывод
Метод упрощает инференс, сохраняя качество. Его можно масштабировать с помощью Flash Attention или приближенных вычислений (например, для 3000 кандидатов, как в Авито).
Статья мне понравилась простотой и практичностью — такой подход легче внедрять в продакшене.
База
В двухэтапных рекомендательных системах используются кандидатогенерация (кандген) и ранжирование.
На этапе кандгена простые модели (например, DSSM, двухбашенные архитектуры) отбирают наиболее релевантные айтемы для пользователя. Из-за большого количества айтемов применяется позднее связывание (late interaction) — например, через скалярное произведение векторов пользователя и кандидатов.
На этапе ранжирования более сложные модели (например, CatBoost или нейросети) переупорядочивают кандидатов, учитывая дополнительные фичи, такие как счетчики взаимодействий или контекст пользователя.
Контекст
В последние годы крупные компании (Google, Meta, TikTok, Pinterest ❤️ , LinkedIn, Alibaba ) активно внедряют нейросетевые модели ранжирования, которые учитывают глобальный контекст пользователя.
В статье Amortized Inference предложен метод, улучшающий SOTA-результаты для этой задачи.
Авторы берут за основу две модели с ранним связыванием (early interaction):
BST (Behavior Sequence Transformer) — кандидат добавляется в конец истории пользователя.
TransAct — кандидат конкатенируется к каждому айтему в истории.
Обе модели используют трансформеры, что позволяет оценивать кандидата с учетом всей истории. Однако у них есть ключевая проблема — высокая вычислительная сложность.
Проблема
Для каждого кандидата модель заново обрабатывает историю пользователя.
Сложность:
O(n^2⋅m⋅d+n⋅m⋅d^2)
где:
n — длина истории,
m — число кандидатов,
d — размерность эмбеддингов.
При больших
n и m (например, 1000+ кандидатов) это приводит к высоким задержкам и делает модель непрактичной для прода.
Решение
Авторы предлагают конкатенировать всех кандидатов к истории и прогонять через трансформер один раз, а затем учить модель предсказывать таргет для каждого кандидата отдельно.
Новая сложность:
O((n+m)⋅d^2+(n+m)^2⋅d)
Это дает значительное ускорение, если
m>2 (что почти всегда верно в рекомендательных системах).
Результаты
+0.18% к качеству (A/B-тесты).
+5% к latency (vs. +56% у BST и +52% у TransAct).
Вывод
Метод упрощает инференс, сохраняя качество. Его можно масштабировать с помощью Flash Attention или приближенных вычислений (например, для 3000 кандидатов, как в Авито).
Статья мне понравилась простотой и практичностью — такой подход легче внедрять в продакшене.
❤10
Коллеги, вы как боретесь с item cold start?
Сегодня расскажу про статью от Google: «Item-centric Exploration for Cold Start Problem»
На недавнем RecSys 2025 было много неплохих работ, которые зацепили сходу.
Сегодня хочу рассказать про простую идею, которую можно переиспользовать везде, где важна вероятность.
Например, для кандидатогенерации. В моем докладе про кросскат мы предсказываем не айтемы, а категории товаров. Для каждой категории находим вероятность и пропорционально ей семплируем уже айтемы из этой категории.
Проблемы рекомендательных систем:
Допустим, мы научились предсказывать вероятность клика/контакта от показа — но насколько такой вероятности можно доверять?
Если айтем новенький и по нему мало коллаборативных фичей-счетчиков, то модели ранжирования поставят его сильно ниже. Похожая ситуация и в кандидатогенерации.
Что предлагают авторы:
Давайте не показывать айтемы слепо. Посчитаем честную конверсию для айтема из показа в клик/контакт. Также у нас уже есть обученная модель ранжирования, которая предсказывает персональную вероятность клика S на айтем для конкретного пользователя.
Если персональная вероятность меньше, чем глобальная вероятность клика - 2 * std, то этот айтем можно не показывать пользователю — с большой вероятностью он ему не интересен.
Но получается, что мы уменьшаем пул айтемов, не предлагая ничего взамен?
Тут на арену выходят параметры alpha и beta. Когда мы считаем честную вероятность N+/N (N+ — положительное событие "клик/контакт", N — показы), мы можем добавить в числитель alpha, а в знаменатель — alpha + beta.
Таким образом, если у айтема было много N+, то alpha и beta не внесут большого вклада — мы уверены в истинной конверсии айтема.
Но если айтем холодный, то alpha и beta значительно скорректируют (повысят) его расчетную конверсию.
На картинке представлена полная картина: условия фильтрации (1), перерасчитанная конверсия (2) и поправка для оценки std (3).
Результат:
Метод позволяет без дополнительного обучения модели поднять выдачу для холодных айтемов.
Мои мысли:
Такую поправку очень легко использовать в современных индустриальных рекомендательных системах — расчет количества контактов/кликов и показов это уже решенная задача.
Для ранжирования можно дешево "прогревать" новые категории объявлений, не переобучая модель ранжирования, что обходится кратно дороже.
Для кандидатогенерации — чуть сложнее. Если брать в расчет вероятностные кандгены — например, на базе semantic ids, где можно посчитать вероятность на этапе инференса — то, добавив поправку, можно настроить количество свежих айтемов для пользователя. Для векторного отбора кандидатов — сложнее, так как вероятность будет известна уже после похода в БД за кандидатами.
Вот такие мысли по статье :)
Делитесь, как еще вы решаете cold-start проблему для айтемов.
Сегодня расскажу про статью от Google: «Item-centric Exploration for Cold Start Problem»
На недавнем RecSys 2025 было много неплохих работ, которые зацепили сходу.
Сегодня хочу рассказать про простую идею, которую можно переиспользовать везде, где важна вероятность.
Например, для кандидатогенерации. В моем докладе про кросскат мы предсказываем не айтемы, а категории товаров. Для каждой категории находим вероятность и пропорционально ей семплируем уже айтемы из этой категории.
Проблемы рекомендательных систем:
Допустим, мы научились предсказывать вероятность клика/контакта от показа — но насколько такой вероятности можно доверять?
Если айтем новенький и по нему мало коллаборативных фичей-счетчиков, то модели ранжирования поставят его сильно ниже. Похожая ситуация и в кандидатогенерации.
Что предлагают авторы:
Давайте не показывать айтемы слепо. Посчитаем честную конверсию для айтема из показа в клик/контакт. Также у нас уже есть обученная модель ранжирования, которая предсказывает персональную вероятность клика S на айтем для конкретного пользователя.
Если персональная вероятность меньше, чем глобальная вероятность клика - 2 * std, то этот айтем можно не показывать пользователю — с большой вероятностью он ему не интересен.
Но получается, что мы уменьшаем пул айтемов, не предлагая ничего взамен?
Тут на арену выходят параметры alpha и beta. Когда мы считаем честную вероятность N+/N (N+ — положительное событие "клик/контакт", N — показы), мы можем добавить в числитель alpha, а в знаменатель — alpha + beta.
Таким образом, если у айтема было много N+, то alpha и beta не внесут большого вклада — мы уверены в истинной конверсии айтема.
Но если айтем холодный, то alpha и beta значительно скорректируют (повысят) его расчетную конверсию.
На картинке представлена полная картина: условия фильтрации (1), перерасчитанная конверсия (2) и поправка для оценки std (3).
Результат:
Метод позволяет без дополнительного обучения модели поднять выдачу для холодных айтемов.
Мои мысли:
Такую поправку очень легко использовать в современных индустриальных рекомендательных системах — расчет количества контактов/кликов и показов это уже решенная задача.
Для ранжирования можно дешево "прогревать" новые категории объявлений, не переобучая модель ранжирования, что обходится кратно дороже.
Для кандидатогенерации — чуть сложнее. Если брать в расчет вероятностные кандгены — например, на базе semantic ids, где можно посчитать вероятность на этапе инференса — то, добавив поправку, можно настроить количество свежих айтемов для пользователя. Для векторного отбора кандидатов — сложнее, так как вероятность будет известна уже после похода в БД за кандидатами.
Вот такие мысли по статье :)
Делитесь, как еще вы решаете cold-start проблему для айтемов.
🔥6❤2
Forwarded from Wazowski Recommends
Вместо итогов года, хочу поделиться моим списком лучших — самых значимых или просто понравившихся — статей, которые я прочитал за последние два года (про 2024 раньше не писал). В порядке прочтения.
Unified Embedding
Статья DeepMind о том, что можно использовать одну универснальную таблицу эмбеддингов для многих sparse фичей. Полезная практическая статья.
Обзоры в Рекомендательной и у Дани.
Actions Speak Louder than Words
Громкая статья от Meta. Первая показала, что можно обучать огромные модели для рекомендаций. Ввела HSTU и новое представление истории. Лично для меня это был первый намёк на то, что когда-нибудь мы сможем отказаться от всех ручных фичей.
Обзоры в Рекомендательной и у Даши.
Revisiting Neural Retrieval on Accelerators
Meta показала, что retrieval можно делать на GPU без индекса. Также вводят для второй стадии модель mixture-of-logits (MoL), которая является более выразительной, но всё ещё относительно дешевой в вычислениях функцией. Для меня это была первая статья, показавшая, что retrieval можно делать лучше, чем всем привычным HNSW. И я сам потом работал над этим подходом. Обзоры у меня и у Саши.
А в последующей статье показали, что можно всё-таки и с индексами и без GPU напрямую искать топ по MoL. Обзор в Рекомендательной.
Серия Semantic IDs от DeepMind
- Generative Retrieval (обзоры у Саши и в Рекомендательной)
- Better Generalization (обзор у Дани)
- PLUM (обзоры у Кирилла и в Рекомендательной)
Номер 1 по значимости, самый существенный сдвиг парадигмы последнего времени. Токенизатор рекомендательного мира, представляющий контентную информацию об объектах в виде кодов из конечного словаря, полученного из иерархической кластеризации (RQ-VAE). Использование этой токенизации для нового метода retrieval, для более эффективных эмбеддингов в ранжировании и для связи с LLM. Уже повлияло на всю индустрию. Must read.
Streaming Vector Quantization Retriever
Одна вещь, которая меня больше всего смущала в Semantic IDs, — что RQ-VAE обучается отдельно, не end-to-end совместно с рекомендательной задачей. В этой статье ByteDance как раз исправили это. Правда, тут не иерархический RQ-VAE, а одноуровневый VQ-VAE. Зато real-time.
Обзор в Рекомендательной.
Stop Regressing
Единственная статья не про рекомендации, хотя и в рекомендациях тоже может быть полезной. DeepMind о том, как в задачах регресии (на примере value function в RL) моделирование распределения таргета (вместо точечной оценки) с помощью Histogram Loss улучшает масштабируемость. Про сам Histogram Loss можно прочитать и в оригинальной статье. Для меня это теперь достаточно близкая тема.
Про статью я узнал из выступления Дмитрия Бабаева на ICML Recap (а также в ML Underhood).
Серия OneRec от Kuaishou
- OneRec
- OneRec Technical Report
- OneRec-V2 Technical Report
- OneRec-Think
(и ещё какое-то количество статей, но я, признаюсь, даже последние две ещё только собираюсь прочитать)
Не называю это номером 1 по значимости только лишь потому, что оно во многом является продолжением Semantic IDs. Но всё же доводит их до того, что многие уже называют революцией — первая индустриальная end-to-end рекомендательная система, без нескольких стадий ранжирования. Вот примерно так будут выглядеть системы нового поколения. Must read.
Обзоры у Саши, в Рекомендательной и у Коли (1, 2, 3).
Correcting the LogQ Correction
Приз моей личной симпатии, потому что
1) улучшили знаменитую технику Гугла LogQ-коррекции,
2) я сам какое-то время думал на эту тему,
3) я рад за Кирилла и команду 😉
Обзор у автора.
На этом всё. Надеюсь, это будет кому-нибудь полезно. Мне самому было бы очень полезно, если бы авторы дружественных каналов позаимствовали такой формат! (только не «лучшие посты года»...)
Unified Embedding
Статья DeepMind о том, что можно использовать одну универснальную таблицу эмбеддингов для многих sparse фичей. Полезная практическая статья.
Обзоры в Рекомендательной и у Дани.
Actions Speak Louder than Words
Громкая статья от Meta. Первая показала, что можно обучать огромные модели для рекомендаций. Ввела HSTU и новое представление истории. Лично для меня это был первый намёк на то, что когда-нибудь мы сможем отказаться от всех ручных фичей.
Обзоры в Рекомендательной и у Даши.
Revisiting Neural Retrieval on Accelerators
Meta показала, что retrieval можно делать на GPU без индекса. Также вводят для второй стадии модель mixture-of-logits (MoL), которая является более выразительной, но всё ещё относительно дешевой в вычислениях функцией. Для меня это была первая статья, показавшая, что retrieval можно делать лучше, чем всем привычным HNSW. И я сам потом работал над этим подходом. Обзоры у меня и у Саши.
А в последующей статье показали, что можно всё-таки и с индексами и без GPU напрямую искать топ по MoL. Обзор в Рекомендательной.
Серия Semantic IDs от DeepMind
- Generative Retrieval (обзоры у Саши и в Рекомендательной)
- Better Generalization (обзор у Дани)
- PLUM (обзоры у Кирилла и в Рекомендательной)
Номер 1 по значимости, самый существенный сдвиг парадигмы последнего времени. Токенизатор рекомендательного мира, представляющий контентную информацию об объектах в виде кодов из конечного словаря, полученного из иерархической кластеризации (RQ-VAE). Использование этой токенизации для нового метода retrieval, для более эффективных эмбеддингов в ранжировании и для связи с LLM. Уже повлияло на всю индустрию. Must read.
Streaming Vector Quantization Retriever
Одна вещь, которая меня больше всего смущала в Semantic IDs, — что RQ-VAE обучается отдельно, не end-to-end совместно с рекомендательной задачей. В этой статье ByteDance как раз исправили это. Правда, тут не иерархический RQ-VAE, а одноуровневый VQ-VAE. Зато real-time.
Обзор в Рекомендательной.
Stop Regressing
Единственная статья не про рекомендации, хотя и в рекомендациях тоже может быть полезной. DeepMind о том, как в задачах регресии (на примере value function в RL) моделирование распределения таргета (вместо точечной оценки) с помощью Histogram Loss улучшает масштабируемость. Про сам Histogram Loss можно прочитать и в оригинальной статье. Для меня это теперь достаточно близкая тема.
Про статью я узнал из выступления Дмитрия Бабаева на ICML Recap (а также в ML Underhood).
Серия OneRec от Kuaishou
- OneRec
- OneRec Technical Report
- OneRec-V2 Technical Report
- OneRec-Think
(и ещё какое-то количество статей, но я, признаюсь, даже последние две ещё только собираюсь прочитать)
Не называю это номером 1 по значимости только лишь потому, что оно во многом является продолжением Semantic IDs. Но всё же доводит их до того, что многие уже называют революцией — первая индустриальная end-to-end рекомендательная система, без нескольких стадий ранжирования. Вот примерно так будут выглядеть системы нового поколения. Must read.
Обзоры у Саши, в Рекомендательной и у Коли (1, 2, 3).
Correcting the LogQ Correction
Приз моей личной симпатии, потому что
1) улучшили знаменитую технику Гугла LogQ-коррекции,
2) я сам какое-то время думал на эту тему,
3) я рад за Кирилла и команду 😉
Обзор у автора.
На этом всё. Надеюсь, это будет кому-нибудь полезно. Мне самому было бы очень полезно, если бы авторы дружественных каналов позаимствовали такой формат! (только не «лучшие посты года»...)
❤12👍5
На Тему семантиков айдисов
Глобально есть 3 основных этапа:
1) Подготовка вектора айтемов
2) Подготовка самих семантиков
3) какой нить декодер поверх семантиков
Хочу поделится 2-мя неочевидными на мой взгляд лайфхаками из статей, в которые я верю (но не проверил полностью)
Номер раз: использовать не один, а N векторов айетмов
В статье OneRec ребята используют Qformer для формирования вектора айтма.
Коротко - на основе контента айтема готовят сразу 4 вектора.
И потом применяют kmeans алгоритм сразу к 4 этим векторам
Номер два: использовать LLM для формирования позитивных пар.
Идея простая - давайте возьмем пары айтемов из истории пользователя, которые идут друг за другом.
Тут возникает проблема - что это не всегда что-то осознанное. В статье QARM-2 исследователи используют LLM - Qwen3 0.6B для разметки пар. Подают тайтлы и параметры объявлений из истории пользователя и спрашивают LLM: а есть ли какая то связь?
По результатом репорт - удалось выкинуть 70% нерелевантных пар
Почему верю в оба подхода?
1 вектор айтема может быть сильно беден и отражать только 1 явный сигнал. Для i2i задачи это может быть и не плохо, но в семантиках надо информацию разложить в иерархию, лучше иметь максимально широкое представление про айтем
Разметка LLM уже отлично зашла в нашей другой задаче. Даже небольшая LLM может повысить качество дефолтного датасета. Не ошибка - прогнать свой датасет через LLM и попросить улучшить . Это повысело качество финальной модели
Глобально есть 3 основных этапа:
1) Подготовка вектора айтемов
2) Подготовка самих семантиков
3) какой нить декодер поверх семантиков
Хочу поделится 2-мя неочевидными на мой взгляд лайфхаками из статей, в которые я верю (но не проверил полностью)
Номер раз: использовать не один, а N векторов айетмов
В статье OneRec ребята используют Qformer для формирования вектора айтма.
Коротко - на основе контента айтема готовят сразу 4 вектора.
И потом применяют kmeans алгоритм сразу к 4 этим векторам
Номер два: использовать LLM для формирования позитивных пар.
Идея простая - давайте возьмем пары айтемов из истории пользователя, которые идут друг за другом.
Тут возникает проблема - что это не всегда что-то осознанное. В статье QARM-2 исследователи используют LLM - Qwen3 0.6B для разметки пар. Подают тайтлы и параметры объявлений из истории пользователя и спрашивают LLM: а есть ли какая то связь?
По результатом репорт - удалось выкинуть 70% нерелевантных пар
Почему верю в оба подхода?
1 вектор айтема может быть сильно беден и отражать только 1 явный сигнал. Для i2i задачи это может быть и не плохо, но в семантиках надо информацию разложить в иерархию, лучше иметь максимально широкое представление про айтем
Разметка LLM уже отлично зашла в нашей другой задаче. Даже небольшая LLM может повысить качество дефолтного датасета. Не ошибка - прогнать свой датасет через LLM и попросить улучшить . Это повысело качество финальной модели
arXiv.org
OneRec Technical Report
Recommender systems have been widely used in various large-scale user-oriented platforms for many years. However, compared to the rapid developments in the AI community, recommendation systems...
🔥7👍3❤2
Всем привет!
Хочу поделиться запуском соревы - https://ods.ai/competitions/avitotechmlcup2026
Так как времени не так много, а соревы я люблю то нашел такое хобби:
запускать соревы самому
В этот раз вложились гораздо больше чем год назад (задача про ноды и топ 2 сорева на площадке по количеству участников):
1) Большой относительно рекомендаций объем данных - 5kkk пар событий пользователь-айтем. В 20 раз больше с прошлым годом
2) Более продуманная метрика - есть баланс по вертикалям + геп по времени. В прошлый раз был весьма обрезанный датасет на события контактов
3) Гораздо ближе к текущему проду чем в прошлом году - завязываемся на item_id, а не на ноды
Залетайте в соревку и делитесь инсайдами :)
PS это сорева сделана полностью на добровольных началах из за любви к ds. Ну почти - мне еще дадут мерчь :)
Хочу поделиться запуском соревы - https://ods.ai/competitions/avitotechmlcup2026
Так как времени не так много, а соревы я люблю то нашел такое хобби:
запускать соревы самому
В этот раз вложились гораздо больше чем год назад (задача про ноды и топ 2 сорева на площадке по количеству участников):
1) Большой относительно рекомендаций объем данных - 5kkk пар событий пользователь-айтем. В 20 раз больше с прошлым годом
2) Более продуманная метрика - есть баланс по вертикалям + геп по времени. В прошлый раз был весьма обрезанный датасет на события контактов
3) Гораздо ближе к текущему проду чем в прошлом году - завязываемся на item_id, а не на ноды
Залетайте в соревку и делитесь инсайдами :)
PS это сорева сделана полностью на добровольных началах из за любви к ds. Ну почти - мне еще дадут мерчь :)
🔥20❤6🤯4
🚀 Data Scientist (Recommendation Systems) в Авито
Middle / Senior / Senior+ | Полная удалёнка / офисы (Мск, СПб, Минск)
💰 Middle: 300–450 000 ₽/мес на руки
💰 Senior/Senior+: 450–650 000+ ₽/мес на руки
🧠 Кого ищем
DS, которые не боятся production и хотят внедрять SOTA в персонализацию главной страницы Авито
У нас полный цикл: от чтения статьи до ONNX и A/B-теста на десятках миллионах пользователей.
🔥 Чем предстоит заниматься
🔹 Generative Recommendation
– Semantic ID, end‑to‑end генеративные модели (❤️OneRec, TIGER).
– Масштабирование на multi-GPU/multi-node (кластер H100)
– Построение семантик (Semantic ID) с помощью RQ-VAE / RQ-KMEANS
– Multimodal энкодеры (текст + изображения)
– Файнтюнинг
🔹 Production DL
– ONNX, TorchScript, Triton
– Доставка семантических ID и векторных эмбеддингов (Redis + Sphinx + ANN)
🔹 Аналитика и итерации
– A/B-тесты, продуктовые метрики
– Умение признать проигрыш, закатать рукава и растащить прод
✅ Что нужно уметь
✔️ PyTorch / Lightning
✔️ Обучали трансформеры, Seq2Seq, двухбашенки в проде
✔️ Работа с большими данными
✔️ Читаете статьи (KDD, RecSys) и реплицируете идеи в код
Middle: самостоятельная реализация подзадач, помощь в исследованиях, написание production‑кода.
Senior / Senior+: архитектурные решения, лидирование направлений (OneRec / Multimodal / файнтюнинг), менторство, R&D.
🍀 Будет плюсом
– Опыт в рекомендательных системах (особенно OneRec/GR)
– Зелёные А/Б (и красные — тоже опыт)
– Open Source contributions
- Участие в соревнованиях
🚀 Почему у нас кайф
⚡️ HPC-кластер с H100 — обучайте большие модели
⚡️ Полный Research‑to‑Production — мы сами режем ONNX, поднимаем инференс
⚡️ Прямое влияние — каждый процент качества видят миллионы
⚡️ Сильная команда — бывшие исследователи и лиды, внутренние митапы, бюджет на конференции
⚡️ Готовы запускать самые смелые гипотезы - пару раз положили Авито :harold:
🛋 Условия
✅ Удалёнка из любой точки мира или офис (Москва, Самара, Санкт-Питербург)
✅ ДМС со стоматологией с первого дня
✅ Современная техника (Mac/PC)
✅ Оплата конференций, книг, английского
📩 Как откликнуться
Пиши сразу в Telegram: @tolkkk1
В сообщении:
— ссылка на резюме / LinkedIn
— пара слов о твоём опыте в DL / RecSys
— GitHub / Kaggle (если есть)
Никаких HR-фильтров — читаю лично
Middle / Senior / Senior+ | Полная удалёнка / офисы (Мск, СПб, Минск)
💰 Middle: 300–450 000 ₽/мес на руки
💰 Senior/Senior+: 450–650 000+ ₽/мес на руки
🧠 Кого ищем
DS, которые не боятся production и хотят внедрять SOTA в персонализацию главной страницы Авито
У нас полный цикл: от чтения статьи до ONNX и A/B-теста на десятках миллионах пользователей.
🔥 Чем предстоит заниматься
🔹 Generative Recommendation
– Semantic ID, end‑to‑end генеративные модели (❤️OneRec, TIGER).
– Масштабирование на multi-GPU/multi-node (кластер H100)
– Построение семантик (Semantic ID) с помощью RQ-VAE / RQ-KMEANS
– Multimodal энкодеры (текст + изображения)
– Файнтюнинг
🔹 Production DL
– ONNX, TorchScript, Triton
– Доставка семантических ID и векторных эмбеддингов (Redis + Sphinx + ANN)
🔹 Аналитика и итерации
– A/B-тесты, продуктовые метрики
– Умение признать проигрыш, закатать рукава и растащить прод
✅ Что нужно уметь
✔️ PyTorch / Lightning
✔️ Обучали трансформеры, Seq2Seq, двухбашенки в проде
✔️ Работа с большими данными
✔️ Читаете статьи (KDD, RecSys) и реплицируете идеи в код
Middle: самостоятельная реализация подзадач, помощь в исследованиях, написание production‑кода.
Senior / Senior+: архитектурные решения, лидирование направлений (OneRec / Multimodal / файнтюнинг), менторство, R&D.
🍀 Будет плюсом
– Опыт в рекомендательных системах (особенно OneRec/GR)
– Зелёные А/Б (и красные — тоже опыт)
– Open Source contributions
- Участие в соревнованиях
🚀 Почему у нас кайф
⚡️ HPC-кластер с H100 — обучайте большие модели
⚡️ Полный Research‑to‑Production — мы сами режем ONNX, поднимаем инференс
⚡️ Прямое влияние — каждый процент качества видят миллионы
⚡️ Сильная команда — бывшие исследователи и лиды, внутренние митапы, бюджет на конференции
⚡️ Готовы запускать самые смелые гипотезы - пару раз положили Авито :harold:
🛋 Условия
✅ Удалёнка из любой точки мира или офис (Москва, Самара, Санкт-Питербург)
✅ ДМС со стоматологией с первого дня
✅ Современная техника (Mac/PC)
✅ Оплата конференций, книг, английского
📩 Как откликнуться
Пиши сразу в Telegram: @tolkkk1
В сообщении:
— ссылка на резюме / LinkedIn
— пара слов о твоём опыте в DL / RecSys
— GitHub / Kaggle (если есть)
Никаких HR-фильтров — читаю лично
🔥24❤10⚡2👍1
Хочу рассказать про небольшую идею как можно семантик айдисы и текст поженить в 1 пространство
Референс - GLIDE от спотифая
В чем цель
Хотят чтобы разговорная LLM моделька смогла начать понимать токены сидов с одном пространстве с токенами текстов.
Контекст
В пейпере ребята использую RQ KMEANS для нарезания сидсов по вектору айтема. Потом использовать llm-ку для рекомендаций треков. При этом в zero shot режиме подавать текст в LLM и менять инструкцию на ходу исходя из бизнес требований
Что сделали
Взяли простую идеяю за основу: а давайте модельки на вход дадим токены сидсов и будем генерировать описание /тайтл айтема. Сидсы инитятся новыми токенами в ллмке. И веса самой модели (кроме эмбедингов) - заморожены. И все.
Что думаю
Один мой товарищ на физтехе, который N лет занимается ллмками в Яндексе сказал, что если выбросить эмбеды из ллмки вообще и заморозить корпус и обучить NTP то веса быстро сойдутся. Поэтому очень верю в такой подход и для сидов тоже
Референс - GLIDE от спотифая
В чем цель
Хотят чтобы разговорная LLM моделька смогла начать понимать токены сидов с одном пространстве с токенами текстов.
Контекст
В пейпере ребята использую RQ KMEANS для нарезания сидсов по вектору айтема. Потом использовать llm-ку для рекомендаций треков. При этом в zero shot режиме подавать текст в LLM и менять инструкцию на ходу исходя из бизнес требований
Что сделали
Взяли простую идеяю за основу: а давайте модельки на вход дадим токены сидсов и будем генерировать описание /тайтл айтема. Сидсы инитятся новыми токенами в ллмке. И веса самой модели (кроме эмбедингов) - заморожены. И все.
Что думаю
Один мой товарищ на физтехе, который N лет занимается ллмками в Яндексе сказал, что если выбросить эмбеды из ллмки вообще и заморозить корпус и обучить NTP то веса быстро сойдутся. Поэтому очень верю в такой подход и для сидов тоже
arXiv.org
Deploying Semantic ID-based Generative Retrieval for Large-Scale...
Podcast listening is often grounded in a set of favorite shows, while listener intent can evolve over time. This combination of stable preferences and changing intent motivates recommendation...
🔥9❤2
Ну и раз пошла такая пьянка вот еще статья, которая использует 2 перспективных подхода сразу - https://arxiv.org/pdf/2606.00324
Пейпер от пинтереста
В чем суть?
Также хотим LLM научить понимать сиды . Один из челленжей, что [5, 1] и [6, 1] - префиксы семантиков имеют разный смысл для 1 , которая на 2-ом месте.
Что делают?
Применяют префикс-хеш трюк из метовской статьи - https://arxiv.org/abs/2504.02137 . То есть берем hash([5, 1])/ T - где T размер хэш таблицы. Таким образом можно менять количество эмбедингов, которые кодируют семантики - больше параметров в саму модельку, и помочь начать различать префиксы на уровне обучения.
И вторая идея наследуют вайб прошлого поста: учат дополнительный энкодер по семантикам предсказывать тексты. Это позволяет сразу в модельку зашить информацию про токены семантиков.
Саму модельку учат на последовательностях (text, sisds, text1, sids1) предсказывать NTP. (ниже картинка какие еще есть).
Результат
Пробовали дополнительный энкодер предобучать перед тем как подавать в основную задачу и это вырастило метрику. Также префикс хешинг дал аплифт. В качестве бейзлайна взяли ванила LLM на NTP шечку.
В Итоге притрейн дал качество как и хешинг причем кратный
Пейпер от пинтереста
В чем суть?
Также хотим LLM научить понимать сиды . Один из челленжей, что [5, 1] и [6, 1] - префиксы семантиков имеют разный смысл для 1 , которая на 2-ом месте.
Что делают?
Применяют префикс-хеш трюк из метовской статьи - https://arxiv.org/abs/2504.02137 . То есть берем hash([5, 1])/ T - где T размер хэш таблицы. Таким образом можно менять количество эмбедингов, которые кодируют семантики - больше параметров в саму модельку, и помочь начать различать префиксы на уровне обучения.
И вторая идея наследуют вайб прошлого поста: учат дополнительный энкодер по семантикам предсказывать тексты. Это позволяет сразу в модельку зашить информацию про токены семантиков.
Саму модельку учат на последовательностях (text, sisds, text1, sids1) предсказывать NTP. (ниже картинка какие еще есть).
Результат
Пробовали дополнительный энкодер предобучать перед тем как подавать в основную задачу и это вырастило метрику. Также префикс хешинг дал аплифт. В качестве бейзлайна взяли ванила LLM на NTP шечку.
В Итоге притрейн дал качество как и хешинг причем кратный
❤7🔥2