Для всех кому я интересен, и похожий контент, но не про рисерч!
Я активно веду канал @danyatyping и приглашаю ВАС поддержать моё творчество.
Искренне был бы рад вашей активности в комментариях, в чате хочу делиться с вами своим каким-то опытом, фишками про карьеру, про лайфстайл, хобби и мимолетные радости жизни.
А в рисерчошной оставить контент более строгий и тематический.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍4🔥3🐳1
Почему двухбашенные модели тайно бустят только популярные товары
Мои коллеги из Wildberries выпустили классную статью про то, что мы обычно не замечаем при обучении two-tower моделей.
Оказывается, даже если мы используем cosine loss (кажется же, что он не должен учитывать популярность), эмбеддинги популярных товаров растут быстрее. В итоге модель начинает ещё сильнее “подсвечивать” и без того востребованные айтемы.
По сути это значит, что «богатые становятся богаче» — популярные товары лезут в топ рекомендаций просто из-за нормы векторов, а не качества совпадения. Вот такой вот капитализм…
Жаль, что написали на хабр, вообще выходит на научную министатейку. Но несмотря на это там много объясняющей математики (другой вопрос нужно ли она на хабре?) почему такие процессы получаются.
MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12🔥6👏4🐳1
Команда T-Bank выложила на Hugging Face огромный синтетический датасет в кросс-домейн рекомендациях.
В нём намешаны сразу разные сферы: маркетплейс, ритейл, покупки, промоакции, отзывы. Получается такой мини-«мир e-commerce», где видно, как пользователь ведёт себя в разных уголках экосистемы. При этом данные синтетические, так что приватность жива и здорова.
Есть full (~135B интеракций, 44M юзеров, 30M товаров, 1300+ дней) и компактная small (~1B, без платежей).
На самом деле не так уж и много хороших и больших кросс-домейн датасетов. Что сильно ограничивает рисерч в этой теме.
В T-ECD фичи завязаны на пять доменов (marketplace, retail, payments, offers, reviews).
Основное:
События:
Каталоги:
Специальные структуры
Очень круто, что компании начали выкладывать в опенсорс датасеты, хоть и синтетические.
#RECSYS
MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12❤7👏5👍1
На выходных был на конференции от Яндекса. Возможно, кто-то из вас даже видел меня там.
Честно говоря, рексиса оказалось многовато, а по-настоящему сильных выступлений — меньше, чем хотелось бы. Ведущие (не спикеры) выглядели так, будто впервые вышли на сцену: сбивались, терялись, аудитория их почти не слушала.
Зато было то, ради чего я всегда жду такие мероприятия. Например, доклад Коли про Argus (HSTU). Он как спикер очень силён: харизматичный, чёткий, а главное — рассказал массу нового про обучение, кросс-домейн, трики и реальные проблемы, с которыми они столкнулись. Его презентацию точно стоит посмотреть.
В кулуарах тоже вышло насыщенно: обсудили семантики, hashing tricks, Tiger, OneRec и свежую статью Яндекса про logQ-коррекцию.
И да, не могу не отметить бытовое: сырный попкорн, классный кейтеринг и афтерпати с барменами и кальянами. Атмосфера — на уровне.
MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍6🎉5🔥1
Вы когда-нибудь задумывались, как векторные базы данных быстро находят похожие объекты в гигантских коллекциях?
Есть такой алгоритм — Hierarchical Navigable Small World, который сегодня используют большинство векторных хранилищ. Он уже работает эффективно и останется релевантным по мере роста объёмов данных.
HNSW строит многоуровневую сеть. На верхних уровнях остаются только дальние связи — это как авиамаршруты между крупными городами.
Внизу находятся все векторы; они связаны плотно, как улицы и кварталы. Каждый слой вниз содержит больше объектов и короче связи. Такая иерархия позволяет сначала быстро приблизиться к нужной области, а затем выполнить детальный локальный поиск — без перебора всего набора.
Как это выглядит на практике: сначала «подлетаем» по верхнему уровню, затем уточняем район на среднем, и в конце спускаемся в нижний слой для точного поиска.
Сначала алгоритм отбрасывает явно нерелевантное, а потом проверяет ближайших соседей — поэтому он остаётся быстрым даже при миллиардах векторов.
При настройке обратите внимание на три параметра.
#RECSYS
MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18 5❤4👍3🐳1
Помните тот вайб, когда открываешь YouTube и случайно залипаешь на гайд какого-то индуса ML?
Так вот, тут не случайно: ACM выкатили 67 записей RecSys 2025. Да, почти вся конференция теперь в открытом доступе.
— YouTube: ACM RecSys — чтобы сразу включить «фоном».
— SlidesLive — чтобы видеть графики, архитектуры и все те мелкие детали, за которые мы любим доклады
#RECSYS
MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
ACM RecSys
The ACM Recommender Systems conference (RecSys) is the premier international forum for the presentation of new research results, systems and techniques in the broad field of recommender systems. Recommendation is a particular form of information filtering…
🔥10 6❤2
Давайте соберем в комментариях как можно больше классных каналы по рексису, которые вы читаете!
Я начну
Остальных напишу в комментариях
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥5👀4💯1
Как WB сделал «Поиск по фото»
Продолжаю рассказывать про прикольные проекты коллег. В этот раз прикольную фичу — поиск по фото, которой я сам частенько пользуюсь. Особенно если нашел какую-то прикольную вещь в рилсах, или буквально недавно нашел чайник-термос в одном заведении.
С точки зрения юзера схема супер простая: Заскринил — загрузил — выделил нужный объект — выбрал нужный товар. Кстати прикольно, что у нас есть OCR по объектам, я такого в других местах не встречал. Можно по одному фото сразу несколько вещей найти.
Под капотом там не просто CLIP, сначала YOLO вырезает объект, OCR снимает артикулы/текст, потом SigLIP-эмбеддинги улетают в векторный поиск Qdrant (HNSW). Товары лежат уже в эмбеддингах заранее.
Самое интересное — мультимодальная логика: поиск живёт не только в изображении. Фото обогащают тегами, которые заранее сгенерированы LLM офлайн по описаниям и визуальным признакам.
Пост у ребят получился достаточно понятным, почти все технические детали разобрали, мне было легко читать.
MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥26👍7❤5🤯5🤓3❤🔥1🙊1
Недавно прочитал в блоге Netflix очень занятную статью — про Advantage-Weighted Supervised Finetuning.
Если коротко, это их новая техника пост-тренинга для генеративных рекомендательных моделей — такая, знаешь, “упрощённая альтернатива RLHF”, но сделанная очень по-инженерному и приземлённо.
Значит они берут уже натренированную генеративную модель, которая умеет “писать” рекомендации
и дообучают её не просто на пользовательских примерах, а с учётом преимущества (advantage) — насколько текущее предсказание лучше среднего по reward-модели.
По сути это reward-learning без RLHF
Это прикольно, потому что RLHF в рекомендациях — это боль. Нужно как-то разруливать шум, дефицит логов, инфраструктуру и дорогостоящие онлайн-итерации.
Да и честно говоря RL в рексисе не особо приживается пока что.
Кроме того от Netflix наконец-то говорят про генеративные Recsys…
MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥12🔥12❤5🤔1😱1
Alibaba Cloud на конференции SOSP’25 показали систему Aegaeon — призванную оптимизировать inference‑набор генеративных моделей на маркетплейсе.
Каким-то магическим способом они сократили использование GPU на 82% для обслуживания генеративных моделей. Было 1192 GPU — стало 213.
Идея в том, что они делают динамический GPU-пуллинг на уровне токена.
То есть одна видеокарта теперь может одновременно обрабатывать токены от разных моделей, а веса моделей загружаются и выгружаются настолько быстро, что простоя почти нет.
Aegaeon объединяет модели с разной нагрузкой, перераспределяет GPU между ними, следит за токен-latency и tail-задержками.
и делает это без потери качества генерации.
17.7% GPU раньше обслуживали всего 1.35% запросов. после Aegaeon — ресурсы утилизируются почти полностью.
MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
ACM Conferences
Aegaeon: Effective GPU Pooling for Concurrent LLM Serving on the Market | Proceedings of the ACM SIGOPS 31st Symposium on Operating…
🤯12👍3❤1😱1
Недавно на архиве я прочитал работу с громким названием про «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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22❤4❤🔥3👍2😁1
На EMNLP 2025 в Китае представили новый способ быстрого обучения больших языковых моделей логике без особых финансовых затрат. Метод разработали наши исследователи из T-Bank AI Research и Центрального университета.
Его главная фишка в том, что вместо полного “переписывания мозга” в нем используются векторы-настройки (steering vectors), которые точно усиливают логические цепочки в рассуждениях. В будущем метод может помочь сделать языковые модели более интерпретируемыми.
На шести математических бенчмарках метод показал и доказал, что реально эффективен: он сократил память с гигабайтов до сотен килобайт и ускорил один из этапов обучения в сотни раз. При этом у 14-миллиардной модели изменения коснулись только нескольких сотен тысяч параметров.
Для меня главный инсайт в том, что сложные reasoning-навыки можно улучшать точечно, без переобучения всей модели. Получается, что даже при весьма ограниченных ресурсах можно будет создавать специализированных ассистентов.
MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14🔥7❤🔥4🤯2😁1👀1
Можете попробовать угадать в комментах
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔7🤯5🤓4👀2😱1
Главный bottleneck в рекомендациях — embedding-таблицы
Давно хотел рассказать про такую интересную штуку как unified embeddings, и кажется, что этот подход реально БАЗОЙ в генеративных рекомендациях.
Если по-человечески, то раньше каждая фича жила в своей отдельной табличке с эмбеддингами, и, мягко говоря, при миллионах товаров или пользователей это была катастрофа.
В отличие от LLM где вокабуляр составляет 40-50 тысяч токенов, мы оперируем миллионами товаров и пользователей. Поэтому мы ограничены как в расчете full CE, так и в том что-бы хранить все пространство.
И вы знаете, мы неплохо научись бороться с этим бутылочным горлышком. Если нам тяжело и дорого считать всё напрямую — давайте считать приближенно.
Один из таких подходов предложили исследователи Google под названием Feature Multiplexing: вместо независимых таблиц для каждого признака модель использует единое пространство эмбеддингов.
Причем размеры этой таблицы мы можем задавать сами — а лукапы реализовать через агрегацию по хешам. Таким образом, один унифицированный эмбеддинг товара несёт семантику сразу из разных источников.
По сути вы заставляете модель, в каком-то линейном слое, научить правильно декодировать эмбеддинг.
Безусловно за все хорошее надо платить — теперь у вас открывается пассивный навык в виде 1-5% коллизий.
Кроме Google unified матрицы используют Pinterest, Netflix, Yandex, WB, определенно стоит присмотреться!
MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10❤🔥3👀3❤1👍1🤓1
Но мало кто знает, как решить одну из вечных болей — расчёт частот по миллиардам 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 — вам скорее всего придется искать приближенные методы.
MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
❤19🤔8👍7🤯2❤🔥1🔥1
Подписчики, я поздравляю всех с наступающим 2026 годом! А мы подводим итоги года.
За год я написал 73 публикации, которые набрали аж 146 тысяч просмотров. Немногонемало прибавилось аж 603 новых подписчика.
Для меня этот год был и остается одним из действительно сложных, особенно в принятии решений, в прикладывании титанических усилий не всегда дающих ожидаемые результаты. Но несмотря на это, самым продуктивным за все время!
За год произошло новое, но вот что меня радует:
1. Приняли статью про дистилляцию знаний из LLM в RecSys трансформеры
2. Разбирали с вами много статей про генеративный рексис
3. Продвигали рисерч в массы
Очень рад повстречать новых крутых людей в своей жизни, невероятных талантов и прекрасных личностей. Очень рад был познакомиться с ребятами и помогать тем кто начал так-же развивать свои ТГК.
В следующем году хотелось бы достичь отметки свыше 10 тысяч подписчиков, написать еще как минимум одну статью.
MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥11❤7🔥5🙊2👍1
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❤6🤓4😡1
Наткнулся на пост Вовы про описание «генеративных» моделей в рексисе https://xn--r1a.website/ducks_recs/8
Не знаю насколько мы можем себе позволить в проде последовательно генерировать айтемы, наверное по большей части пока что не можем. Но вот что интересно в альтернативном случае это мало чем отличается от любой около декодерной модели (типа sasrec++).
Но можем ли мы это называть генеративной моделью? Наверное сама генеративность заключается в том, что мы ближе к LLM (gpt) моделям. Что у нас должен быть какой-то alignment, какой-то scaling law с возможностью масштабировать это дело.
А вы как считаете?
GR подходит к этой проблеме иначе. Модель генерирует и выдаёт последовательность кодов, а маппинг code -> item хранится в обычном KV-хранилище. При появлении нового айтема, ему можно сразу назначить код и добавить соответствующую запись. Теперь у модели есть возможность выдавать новый айтем сразу после появления (при некоторых уточнениях).Не знаю насколько мы можем себе позволить в проде последовательно генерировать айтемы, наверное по большей части пока что не можем. Но вот что интересно в альтернативном случае это мало чем отличается от любой около декодерной модели (типа sasrec++).
Но можем ли мы это называть генеративной моделью? Наверное сама генеративность заключается в том, что мы ближе к LLM (gpt) моделям. Что у нас должен быть какой-то alignment, какой-то scaling law с возможностью масштабировать это дело.
А вы как считаете?
🤔7❤4👍3
Встречайте новый формат инженерного диалога
T-Sync Conf — офлайн-конференция от Группы «Т-Технологии» для опытных инженеров. 7 февраля в Москве на площадке TAU соберутся платформенные, security- и дата-инженеры, аналитики, DevOps-, SRE-, CI/CD-, AI-, ML-, R&D- и DX -специалисты.
Как все устроено:
— Контуры — тематические зоны, каждая из которых раскрывает отдельный слой инженерной реальности: AI, Data, R&D, Security, Platform и другие направления.
— Вместо классических докладов — круглые столы, стенды, хакатон, воркшопы и мастер-классы.
— Инженерные решения изнутри — возможность посмотреть, как устроены технологии в Т-Банке и других компаниях, и пообщаться напрямую с теми, кто их создает.
А еще много практики, интересных знакомств и живых систем.
Успейте подать заявку
T-Sync Conf — офлайн-конференция от Группы «Т-Технологии» для опытных инженеров. 7 февраля в Москве на площадке TAU соберутся платформенные, security- и дата-инженеры, аналитики, DevOps-, SRE-, CI/CD-, AI-, ML-, R&D- и DX -специалисты.
Как все устроено:
— Контуры — тематические зоны, каждая из которых раскрывает отдельный слой инженерной реальности: AI, Data, R&D, Security, Platform и другие направления.
— Вместо классических докладов — круглые столы, стенды, хакатон, воркшопы и мастер-классы.
— Инженерные решения изнутри — возможность посмотреть, как устроены технологии в Т-Банке и других компаниях, и пообщаться напрямую с теми, кто их создает.
А еще много практики, интересных знакомств и живых систем.
Успейте подать заявку
👀3🔥2🤔1
Forwarded from Information Retriever
xAI выложили в опенсорс код своей новой рекомендательной системы (X / Твиттера).
https://github.com/xai-org/x-algorithm/
Код довольно простенький. Что можно сказать:
* используют jax
* постарались избавиться от эвристик и ручного feature engineering'а
* как и раньше, кандидаты набираются из двух источников — подписки и ML (раньше TwHIN, теперь двухбашенный трансформер)
* в качестве ранжирующей нейросети — тоже трансформер (раньше был MaskNet / DCN / etc)
* также выложили цельный многостадийный рекомендательный пайплайн — набор кандидатов, фильтрации, ранжирование, буст разнообразия авторов, постфильтрации
* есть только код инференса, про обучение инфы нет
Архитектура трансформера дефолтная (вижу роторные эмбеды, rmsnorm) и форкнута с Grok'а. Важно: предобученный Grok не используется, только код. И вообще, везде в тестах и конфигах указаны очень маленькие размеры трансформера (аля два слоя и hidden size 128). Длина используемой истории пользователя в конфигах — то ли 128, то ли 32 (в разных местах по-разному написано). Одинаковая архитектура трансформера используется и в ранжировании, и в кандгене.
Для кодирования сущностей (постов, авторов, пользовательских признаков) используют multi-hash lookup: делают что-то типа
Еще как будто берут мультихэши от айдишника пользователя и подают в трансформер вместе с историей пользователя.
Башня кандидата в двухбашенном трансформере для кандгена очень простая — Linear(SiLU(Linear)).
Ранжирующий трансформер устроен таким образом, что history+user токены видят только history+user токены, а каждый кандидат видит себя и history+user токены (кастомная аттеншн маска). Подают сразу несколько кандидатов, но работает это эквивалентно тому, как если бы отдельно прогнали трансформер для каждого кандидата, добавляя его в конец последовательности.
Multi-action prediction: трансформер предсказывает вероятности сразу для кучи разных сигналов (like, reply, click, repost — полный список в репозитории). Для финального ранжирования, эти вероятности суммируются с весами в единый скор (но как подбираются веса — не пишут). Такую схему использовали и в прошлой ранжирующей нейросети, но только теперь эти вероятности приходят напрямую из трансформера.
tldr: довольно простой пайплайн на трансформерах. Двухбашенный кандген, нейросетевое ранжирование, мультихэши для эмбеддингов. С одной стороны — всё супер просто, ничего особо интересного. С другой — если получилось заменить прошлую рексистему и ничего не сломать — это круто :)
Предполагаю, что какие-то подробности / детали все же не раскрываются (e.g. как рекомендуется холодный контент — для этого должны быть какие-то еще эмбеды кроме мультихэшей).
Из забавного — всю эту трансформерную поделку в xAI решили назвать "Феникс". Когда-то я в Яндексе инициировал похожий проект про упрощение ранжирования в единую нейросеть с трансформером, и тоже назвал её Фениксом. Вот так вот нейминги совпали :)
https://github.com/xai-org/x-algorithm/
Код довольно простенький. Что можно сказать:
* используют jax
* постарались избавиться от эвристик и ручного feature engineering'а
* как и раньше, кандидаты набираются из двух источников — подписки и ML (раньше TwHIN, теперь двухбашенный трансформер)
* в качестве ранжирующей нейросети — тоже трансформер (раньше был MaskNet / DCN / etc)
* также выложили цельный многостадийный рекомендательный пайплайн — набор кандидатов, фильтрации, ранжирование, буст разнообразия авторов, постфильтрации
* есть только код инференса, про обучение инфы нет
Архитектура трансформера дефолтная (вижу роторные эмбеды, rmsnorm) и форкнута с Grok'а. Важно: предобученный Grok не используется, только код. И вообще, везде в тестах и конфигах указаны очень маленькие размеры трансформера (аля два слоя и hidden size 128). Длина используемой истории пользователя в конфигах — то ли 128, то ли 32 (в разных местах по-разному написано). Одинаковая архитектура трансформера используется и в ранжировании, и в кандгене.
Для кодирования сущностей (постов, авторов, пользовательских признаков) используют multi-hash lookup: делают что-то типа
linear(concat(embedding(hash1), embedding(hash2))). В конфигах везде указаны num_hashes=2, то есть по два лукапа на сущность. Для разных признаков используются раздельные таблицы эмбеддингов (в unified подходе была бы одна общая); то есть для авторов, постов, пользователей — разные таблицы. Эмбеддинг события в истории пользователя формируется на основе поста, автора, рекомендательной поверхности и действия пользователя.Еще как будто берут мультихэши от айдишника пользователя и подают в трансформер вместе с историей пользователя.
Башня кандидата в двухбашенном трансформере для кандгена очень простая — Linear(SiLU(Linear)).
Ранжирующий трансформер устроен таким образом, что history+user токены видят только history+user токены, а каждый кандидат видит себя и history+user токены (кастомная аттеншн маска). Подают сразу несколько кандидатов, но работает это эквивалентно тому, как если бы отдельно прогнали трансформер для каждого кандидата, добавляя его в конец последовательности.
Multi-action prediction: трансформер предсказывает вероятности сразу для кучи разных сигналов (like, reply, click, repost — полный список в репозитории). Для финального ранжирования, эти вероятности суммируются с весами в единый скор (но как подбираются веса — не пишут). Такую схему использовали и в прошлой ранжирующей нейросети, но только теперь эти вероятности приходят напрямую из трансформера.
tldr: довольно простой пайплайн на трансформерах. Двухбашенный кандген, нейросетевое ранжирование, мультихэши для эмбеддингов. С одной стороны — всё супер просто, ничего особо интересного. С другой — если получилось заменить прошлую рексистему и ничего не сломать — это круто :)
Предполагаю, что какие-то подробности / детали все же не раскрываются (e.g. как рекомендуется холодный контент — для этого должны быть какие-то еще эмбеды кроме мультихэшей).
Из забавного — всю эту трансформерную поделку в xAI решили назвать "Феникс". Когда-то я в Яндексе инициировал похожий проект про упрощение ранжирования в единую нейросеть с трансформером, и тоже назвал её Фениксом. Вот так вот нейминги совпали :)
❤🔥7❤4🔥4👀2