РИСЕРЧОШНАЯ
2.29K subscribers
107 photos
3 videos
93 links
Канал Дани Картушова о рекомендательных системах и AI.

Более подробно — в первом сообщении.

Автор — @redpf

Каналы — @researchoshnaya · @danyatyping
Download Telegram
‼️ Кстати, важная новость!

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

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

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

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

➡️ @danyatyping
Please open Telegram to view this post
VIEW IN TELEGRAM
7👍4🔥3🐳1
4️⃣5️⃣6️⃣

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

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

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

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

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

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

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

MADE IN
@researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
12🔥6👏4🐳1
Нашёл имбовый датасет для ресёрча — 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥127👏5👍1
🏋️Вот что я узнал на Practical ML Conf

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

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

Зато было то, ради чего я всегда жду такие мероприятия. Например, доклад Коли про 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 строит многоуровневую сеть. На верхних уровнях остаются только дальние связи — это как авиамаршруты между крупными городами.

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

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

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

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

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

#RECSYS

MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1854👍3🐳1
ACM начали выкладывать видео с RecSys 2025

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

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

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

#RECSYS

MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1062
💎 А какие каналы читаете вы по рексису?

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

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

Остальных напишу в комментариях 🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
7🔥5👀4💯1
4️⃣5️⃣6️⃣

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

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

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

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

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

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

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


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

MADE IN
@researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥26👍75🤯5🤓3❤‍🔥1🙊1
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
Please open Telegram to view this post
VIEW IN TELEGRAM
❤‍🔥12🔥125🤔1😱1
Китайцы выкинули 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯12👍31😱1
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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥224❤‍🔥3👍2😁1
4️⃣5️⃣6️⃣

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

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

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

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

➡️ Steering LLM Reasoning Through Bias-Only Adaptation

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

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
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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10❤‍🔥3👀31👍1🤓1
Любишь 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
Please open Telegram to view this post
VIEW IN TELEGRAM
19🤔8👍7🤯2❤‍🔥1🔥1
🎉 ИТОГИ 2025 ГОДА

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

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

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

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

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

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

MADE IN @researchoshnaya
Please open Telegram to view this post
VIEW IN TELEGRAM
❤‍🔥117🔥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) я рад за Кирилла и команду 😉
Обзор у автора.


На этом всё. Надеюсь, это будет кому-нибудь полезно. Мне самому было бы очень полезно, если бы авторы дружественных каналов позаимствовали такой формат! (только не «лучшие посты года»...)
🔥126🤓4😡1
Наткнулся на пост Вовы про описание «генеративных» моделей в рексисе https://xn--r1a.website/ducks_recs/8

GR подходит к этой проблеме иначе. Модель генерирует и выдаёт последовательность кодов, а маппинг code -> item хранится в обычном KV-хранилище. При появлении нового айтема, ему можно сразу назначить код и добавить соответствующую запись. Теперь у модели есть возможность выдавать новый айтем сразу после появления (при некоторых уточнениях).


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

Но можем ли мы это называть генеративной моделью? Наверное сама генеративность заключается в том, что мы ближе к LLM (gpt) моделям. Что у нас должен быть какой-то alignment, какой-то scaling law с возможностью масштабировать это дело.

А вы как считаете?
🤔74👍3
Встречайте новый формат инженерного диалога

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(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 решили назвать "Феникс". Когда-то я в Яндексе инициировал похожий проект про упрощение ранжирования в единую нейросеть с трансформером, и тоже назвал её Фениксом. Вот так вот нейминги совпали :)
❤‍🔥74🔥4👀2