252
Subscribers
No data24 hours
+57 days
+530 days
Data loading in progress...
Similar Channels
No data
Any problems? Please refresh the page or contact our support manager.
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
March '25
March '25
+175
in 0 channels
February '250
in 0 channels
Get PRO
January '250
in 0 channels
Get PRO
December '24
+60
in 0 channels
Get PRO
November '240
in 0 channels
Get PRO
October '240
in 0 channels
Get PRO
September '24
+18
in 0 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 05 March | +1 | |||
| 04 March | +1 | |||
| 03 March | +3 | |||
| 02 March | +1 |
Channel Posts
Попробовал репу для запуска торчовых моделей на go.
В чем суть?
На питоне очень приятно предобрабатывать данные для тренировки модели и реализовывать сами модели. Но в рантайме держать питон сервис уже не так приятно - есть ограничение на большую нагрузку.
Как можно подойти к проблеме?
Конечно же перевести deep learning модель на компелируемый язык. Например на go. Для этого нужно экспортировать модель в onnx формате. И заюзать репу выше. Она как раз умеет работать с onnx форматом, избавляя от питона в рантайме
Мой опыт
Попробовал перевести сервис с одной из моделей. Архитектурно - это небольшой трансформер с 2 слоями attention.
На небольшой нагрузку (~1kRPM) модель отрабатывает дольше (примерно на 10-20%). Но открывает возможности для более гибкой предобработки данных для моделей не ограничиваясь одним сервисом.
| 2 | Тестовый пост для комментов | 414 |
| 3 | Физтех
Недавно добавился в папку с физтехами. В ней есть не только про ds, но и про жизнь.
Из тех, что я читаю +- регулярно есть:
- канал Маши про жизнь и путешествия
- канал Леши про LLM
- канал тим лида из ДоДо про соревки и индустрию
Можно посмотреть, чем занимаются выпускники после вуза 😎 | 442 |
| 4 | 5 место - стоит посмотреть выступление (предыдущий пост). А также участник скинул примерный код нейронки.
class UserTower(L.LightningModule):
def __init__(self, user_id_emb_dim):
super().__init__()
self.save_hyperparameters()
self.id_embedding = nn.Embedding(num_embeddings=n_users, embedding_dim=user_id_emb_dim)
nn.init.orthogonal_(self.id_embedding.weight)
self.user_emb_dim = user_id_emb_dim + 1 + 3
def forward(self, user_id, gender, age, age_norm):
user_embedding = torch.cat([
self.id_embedding(user_id.long()),
gender.unsqueeze(-1).float() - 1,
age_norm.unsqueeze(-1),
torch.pow(age_norm.unsqueeze(-1), 2),
torch.sqrt(age_norm.unsqueeze(-1)),
], dim=-1)
return user_embedding
class ItemTower(L.LightningModule):
def __init__(self, item_id_emb_dim, source_id_emb_dim):
super().__init__()
self.save_hyperparameters()
self.id_embedding = nn.Embedding(num_embeddings=n_items, embedding_dim=item_id_emb_dim)
nn.init.orthogonal_(self.id_embedding.weight)
self.source_id_embedding = nn.Embedding(num_embeddings=n_source_id, embedding_dim=source_id_emb_dim)
nn.init.orthogonal_(self.source_id_embedding.weight)
self.item_emb_dim = item_id_emb_dim + source_id_emb_dim + 3 + 32
def forward(self, item_id, source_id, duration, duration_norm, embeddings):
item_embedding = torch.cat([
self.id_embedding(item_id.long()),
self.source_id_embedding(source_id.long()),
duration_norm.unsqueeze(-1),
torch.pow(duration_norm.unsqueeze(-1), 2),
torch.sqrt(duration_norm.unsqueeze(-1)),
embeddings,
], dim=-1)
return item_embedding | 392 |
| 5 | Для истории приложу материалы по решением
Разбор решений
1 место - пост c описанием решения
2 место - статья, пост в канале участника и пост в группе
4 место - гитхаб | 308 |
| 6 | Дата ёлка
18 января во Вконтекте проходила DataЁлека от ODS. Главным событием был разбор решений VK Rec Sys Challenge (в самом соревновании админ занял 24 место).
Это были мои первые соревнования по рекомендательным системам - и очень полезный опыт, который неплохо прокачивает MLSD. Уже жду следующего Challenge.
Разбор решений и постановку задачи можно посмотреть в вк видео.
Я же считаю важным выделить подходы, которые стоит добавить в "джентльменский" ("дамский") арсенал:
1) Стабилизация обучения нейронок
Нейронки обучаются нестабильно - от изменения распределения для инита изначальных весов могут сильно поменяться метрики. Классическое решение - это брать из распределения, использовать нормализации, более хитрые функции активации (учебник ШАД в помощь). Но не стоит забывать и про технику, когда инитом может послужить эмбединги, обученные на другую задачу (5 место и 2 место) . Можно натренировать например ALS модель, чтобы получить эмбединг юзера/айтема и использовать их в более сложных полносвязных нейронных сетях (5 место, Стас Чистяков) или трансформерах (2 место - правда в его решении тренировались эмбединги для параметров айтемов, Кирилл Хрыльчинко)
2) Фича фреймворк
Запомнилось решение 3 места (Иван Брагин) - оно по структуре было ближе всего к моему подходу. Что мне понравилось: у Вани в решении был классический катбуст с фичами, которые он придумывал сам. НО - он написал фреймфорк, который позволял быстро генерировать фичи для трейна, ивала и теста, чтобы они не разъехались - логика расчета оставалась неизменной, но применялась на разных датасетах . По словам участника написание фреймфорка и обкатка заняло 2 недели, но сильно облегчило проверку гипотез - у Вани больше 150 отправок, что подтверждает его слова.
3) end2end - наше все
Кирилл (2 место) удивил больше всех своим решением - в отличи от многих других решением финальный артефакт - это end2end сетка, в которую можно добавлять фичи (за счет DCN головы скорее всего) с трансформером для обработки последовательностей. Кода я не видел (может там и Яндекс Монст на 1000+ гпухах 😊😊😊).
Что мне понравилось: когда у тебя end2end решение, это конечно требует много "мыслетоплива", чтобы завести. НО - пропадают степени свободы в других местах пайплайна : как правильно собрать ансамбль в конце соревнования, методы предобработки данных и подробный EDA - все это можно опустить и сконцентрироваться на развитии модели и получить достойный скор. Отмечу, что решение с 1 места использует под капотом более классический подход - много стекинга и моделей для создания отдельных фичей, этот поход все еще жизнеспособен (пока)
PS во время докладов решений, которых было 3, можно было задавать вопросы. За лучший вопрос давали приз. У меня получилось забрать 2/3 призов . Достойный вопрос не задал на тему с нейронками - надо подтянуть 😊 | 429 |
| 7 | ВАУ!!! 100 подписчиков!!! Спасибо ребят, что залетаете и читаете обзоры на статьи!!!
В прошлом году было много интересных статей, в этом будет еще больше 😃 | 345 |
| 8 | Сейчас пробую завести автоэкондеры для матричной факторизации. Если даст какой то профит (или и не даст), то закину постик | 838 |
| 9 | А что по ресурсам?
В статьях от Бигтех компаний (Алибаба, Пинтерест ) часто указывают ресурсы для тренировки и раскатки в продакшен.
ECR - это прежде всего академический ресерч, поэтому в этой статье нет смысла писать про нагрузку и ресурсы.
Уместное использование LLM в проде есть в статье - OmniSearchSage (про нее был постик). Там использовали LLM для генерации описаний к контенту, где мало текста, но картинка содержит много информации о пине. Но это все еще не CR
Интересно посмотреть - завел ли кто-нибудь уместно CR в прод | 932 |
| 10 | Что я думаю
Мне понравился подход и метод как подошли к задачи рекомендаций - сделать отдельный токен для фильма/ для сущностей и учесть как они влияют на эмоции человека - видно, что люди глубоко подошли к пониманию данных. Пока не совсем прозрачно как адаптировать под другие домены - e-commerce, рекомендации музыки и т д, Также датасет был небольшой - около 10к диалогов, что для современных рек систем крайне мало. Возможно если использовать классические LLM или UniCRS на большом объеме данных, то модельки смогут сами уловить сигнал с эмоциями/фидбеком пользователя (если конечно переобучать и уделить ресурс этому сигналу).
Похожий подход хочется попробовать в работе - сейчас я занимаюсь рекомендациями основанными на параметрах объявлений. В терминах статьи это и есть entities - может неплохо выйти | 807 |
| 11 | Winner Recsys 2024: тук-тук и LLM в реки 💦
Не так давно прошла главная конференция по рекомендательным системам, в которой лучшей статьей года объявили Towards Empathetic Conversational Recommender Systems (ECR). А это статья с использованием LLM для задачи рекомендательных систем или поиска.
Почему это удивило?
Когда LLM только начинали входить в моду, то решили попробовать для задачи ранжирования и поиска. Первые статьи выглядели в стиле “А давайте подадим историю пользователя в LLM и попросим генерировать подходящее объявление из данного контекста?”. Ограничения такого подхода очевидны - 1) огромное количество айтемов может не поместить в контекст 2) тревиальные рекомендации, за счет незнания данных в нашей платформы. Решение этих проблем было прдложено напрмиер в UniCRS - модель как акинатор пробует отыскать подходящий айтем, задавая вопросы. Отличие в том - что ни пользователь, ни модель не знают , что хочет сам юзер с самого начала, а осознают, что нужно во время диалога. ECR как раз идейная наследница данного подхода
В чем суть и почему это так круто?
У ECR есть 2 основных модуля - 1) отвечает за предсказание айтема для пользователя 2) пояснение к рекомендации: почему именно этот этот айтем интересен пользователю. Модель использовали на датасете с фильмами - диалоги пользователей и других CR. В качестве таргета 1 и 0 - если модель нашла и не нашла подходящий для пользователя фильм.
Модуль 1: эмпатичная рек система
На основе того, какие чувства (нравится, восторг, отвращение и тд) проявляет пользователь к сущностям (актеры, жанры и тд) в диалоге модуль пытается предсказать подходящий фильм. В нем также используется информация о глобальном отношении пользователей к фильму и сущностям - в модель подают отзывы о фильмах.
Очень советую перед чтением абзаца ниже внимательно следить за схемой модели.
Архитектурно это выглядит так: есть диалог пользователя, из которого достаем сущности (local entities) , также достаем эмоции пользователя(user emotions) . Собранные “чувства” тонизируем и складываем в 1 вектор - вектор чувств пользователя . Конкатим вектор чувств и вектора сущностей - понижаем размерность с помощью W матрицы - получаем вектора сущностей с учетом эмоций(Emotional Aware entity representation). Также достаем глобальные сущности из отзывов на основе соовстречаемости в отзывах к фильму (global entities). Вектора локальных сущностей (local emotion-aware entities) складываем в список вместе с глобальными сущностями (global emotion-aware entities representation), добавляем промт для нашей задачи (task-specific tokens), сюда же диалог пользователя с моделью и рекомендательный респонс к прошлому фильму (как он формируется в 2) модуле). Подаем это все в LLM модель и просим предсказать фильм.
Модуль 2: эмпатичный поэт
В когда мы предсказали фильм для рекомендации пользователю, то нужно привлечь его внимание к тем сущностям, которые могут его заинтересовать в этом фильме - например, что Бред Пит (сущность: актер) очень круто сыграл в этом фильме и тд. Этот модуль тоже принимает на вход сущности фильма, токены с описанием задачи и сам фильм, но учим мы его генерировать отзыв к фильму. Отзывы берем только те, что 10/10, поэтому в них много “хвалебных” и эмоциональных описаний. В проде используем модельку для генерации текста
Результаты
Модель побила все модели на этом датасете (даже UniCRS). Ее сравнивали с большим-большими генеративками (ChatGPT-3,ChatGPT-3.5 и тд ) - с ними она тоже справилась. | 684 |
| 12 |  Дроп скоро появится | 583 |
| 13 | PS статья от алибабы . И я узнал это только после перечитывания статьи. Для меня это было шоком, так как архитектура подхода не выглядит как монстр с 1000 и 1 щупальцой. А подход относительно элегантный :) | 727 |
| 14 |  +1No text... | 703 |
| 15 | Учтем иерархию элегантно
В задачах связанных с маркетплейсами и e-commerce появляются категории товаров. Часто эти категории разбиваются на подкатегории, а те уже на микро категории и т д . Принято даже называть деревом категорий. Часто такая разбивка создается людьми на основе уже состоявшихся товаров на платформе - принадлежность айтема к одной из микро-нано-категории однозначно определяет часть свойств товара и хочется этот сигнал учесть в рекомендательной системе
В классическом подходе берут эмбеддинг миро категории и подмешивают например к векторам тайтла, описаний при построении вектора айтема. Вектор микро категории будет в себе содержать информацию о родителях-категориях , так как система. И это неплохо работает - классическая категорийная фича
В статье Deep Hierarchical Classification for Category Prediction in E-commerce System предложили методы, как учесть ветку товара. Например если товар ложка, то полезно учесть, что это из категории “посуда”, из подкатегории ”столовый прибор”, тогда для других “посуд” , по которым меньше статистик, будет полезна информации о родителях-категорий.
Сама статья про классификацию айтемов по дереву, но ее идеи можно переиспользовать для рек системы.
Я выделил 2 полезные:
Учет в векторе айтема всех категорий в дереве, к которым принадлежит
Сохранить информацию о иерархии в векторах категорий
1) Все категории в товаре
Идея в том, чтобы проинициализировать вектор каждого уровня иерархии в дереве, кроме рутовой, и матрицу весом W размера (l * emb_dim, n_l) , где n_l - количество категорий на данном уровне для каждого уровня дерева. Изначально инитим вектор айтема на основе его описания тайтла и параметров (предположим мы это уже умеем делать). Далее обогащаем вектор с предыдущего уровня вектором иерархии, то конкатенировать все вектора в ветке и умножить на матрицу W (картинка 1). Полученный вектор имеет размерность (n_l) - к нему применяют софтмакс и обучают логлосс. Метка класса - категория товара на уровне l . Такую операцию проделываем для каждого уровня.
2) Сохранение иерархии
После получения логитов иерархии закидывают их в доп лосс функцию. Идея в том, чтобы добавить параметр Dl . Если предсказанный на l-1 уровне категория не является отцом-категория для l уровня то дополнительно штрафовать при обучении
Мое мнение
Подход не сложно реализуемый - является надстройкой поверх существующего метода. Когда рек система уже развита и есть хорошие вектора объявлений, это будет плюсом. Я бы попробовал подать на вход вектор пользователя и попробовать угадать какие категории товаров интересны ему. Также можно находить интересный параметры. Метод использует простые линейные умножения, что легко поддерживать в проде и объяснять, что происходит.
С точки зрения вклада в изучение глубины данных в эпоху развития CRS (рекомендации с помощью llm) данный способ выглядит замудренным - гораздо проще закинуть в llm и попросить отыскать параметры-категории для айтема и пользователя. Но можно попробовать в тандеме - LLM создает разметку для этого метода, а матрички будут аппроксимировать работу LLM | 637 |
| 16 |  Предыдущая статья была из Alibaba: продуктовое применение подхода. Статья на которую они ссылаются из академических кругов - ICL имеет еще более страшную архитектуру. В ней подробно раскрыты проблема "вектора пользователя" | 628 |
| 17 |  PS по традиции стремная архитектура сети, которая не внушает доверия :) | 605 |
| 18 | А вектор пользователя это хорошая идея?
В рекомендательных системах распространен подход, когда мы пользователя представляем вектором Vu, а контент (айтемы) Vi . Эти вектора обладают свойством, что чем выше dot(Vu, Vi) , тем релевантнее данный айтем пользователю. Dot- мера близости, например: 1-cos(x, y), x.T@y, |x-y|. Чаще выбирают простую функцию в качестве меры.
Основные плюсы
1) Многие базы данных уже оптимизированы для быстрого расчета
2) Есть множество алгоритмов для приближенного поиска
3) Относительно легко интерпретировать - "соседи" айтема в векторном пространстве похожи на сам айтем
Основные минусы
1) Нужно держать базу векторов для всех айтемов
2) Нужно рассчитывать или хранить вектор пользователя. Эта проблема решается батчевыми рекомендациями
3) Кучность соседей - если взял 1 кандидата из кучи, то скорее всего вытянишь его соседей. Пользователь может получить однообразную выдачу.
В этом посте я хочу подробнее остановится на 3-их пунктах в обоих абзацах.
Если вектор пользователя оказался близок к одному айтему, например по L1 мере: |Vu-Vi|=n. В таком случае соседи айтема будут обладать свойством |Vi - Vneighbor| ~ ε - небольшое число, то использую свойство метрики L1: |Vu - Vneighbor|<= ε+n ~ n, а значит сосед с большой вероятностью попадет в выдачу к пользователю.
Пример
У нас есть пользователь, который интересовался айфонами и машинами на Авито. Если полученный Vu окажется близок хотя бы к 1 айфону, то окажется близок и множеству других айфонов. Почему? Потому что айфоны друг от друга сильно не отличаются, много айтемов с одними и теми же параметрами и описаниями.
Почему возникает такая проблема?
Объяснение на пальцах: Вектора используются небольшой размерности <500. Если у платформы много категорий и типов товаров (например 50) то образуемое ими подпространства будут иметь размерность <10 чего может сильно не хватить
Какие я видел методы борьбы с этим
Выделю 2 подхода - эвристики (самый рабочий), intent learning.
Эвристики
Сюда я бы отнес всякие лайфхаки и инженерные трюки.
Например, если у нас много категорий, в каждой категории считать свой вектор пользователя и искать knn.
Тут же можно считать вектор пользователя за разные периоды его активности - вектора на истории с гепом в неделю и замешивать кандидатов с разным весом. Это позволит учесть в выдаче, что было интересно давно пользователю, а также новые интересы.
Я стараюсь на работе применить такой метод в первой итерации. Если созревает продуктовая гипотеза, то гораздо проще изменить параметры модели или предобработку истории, чем собирать датасет и менять архитектуру
intent learning
Идея учить сразу несколько векторов пользователя. Одна из свежих статей, которая использует этот подход и ссылается на предшественниц. Причем есть много способ как при обучении получить несколько векторов:
* отдельно обучать краткосроный и долгосроный вектора пользователя
* если не платформе несколько типов событий, то под каждый обучать отдельно
* Получать n векторов сразу и каждым предсказывать n объявлений вперед
Идея очень льстит - из коробки получаем "умные" вектора пользователей. Перед тем как пилить подобные оверхеды, сначала я проверяю свой чеклист с вопросами:
* а какая продуктовая потребность?
* какой сигнал должна выучить модель?
* могу ли я апроксимировать этот сигнал эвристиками и протестировать в оффлайне/онлайне?
Если эвристика заходит и пользователям и вправду уместен сигнал, то можно заносить в модель и смотреть как она справится | 612 |
| 19 |  PS. если кто-то сомневается, что начинать с трансформерных подходов это не перебор. Ставьте 🙈- если согласны что это оверхед для 1-ой итерации, 😎 - все просто и понятно | 506 |
| 20 | Про подход
Хочется посмотреть на реальных данных - на сколько важна история пользователя при формировании "похожих" . На практике под каждый интент пользователя приходится делать отдельный ресерч и пилить отдельную модель, но если появляется вариант убрать такую "ручную" работу, то можно брать новые челленджи для продукта, а не копаться, какую вкладку использовать - "похожие" или "покупают вместе" или "распродажа". | 513 |
