Б/У ml

Общая архитектура и как связанны фичи запроса, юзера и счетчики

Общий вид поисковой системы. Мы рассматриваем PreRanking

Сегодня рассмотрим статью поискового ранжирования от Pinterest - InterRact

Абстракт
Современные поисковые системы используют многоступенчатый подход:
item corpus -> Retrievial -> PreRanking -> Ranking/Blending
В этой статье хотят решить проблемы, с которыми столкнулся pinterest на этапе PreRanking


Проблема
1) Нужно укладываться в latency - классические DLRM или DCN не поспеют
2) Обычно используют two tower подходы - тут есть ограничение в dot product - может не найти сложные зависимости между векторами айтемов и запросов
3) Вспоминают про BM25, который по сути счетчик в пересечении слов. Ему сложно дается найти семантические зависимости , а также он не учитывает контекст пользователя в данной сессии

Решение
Представляют архитектуру InteractRank. Свойства
1) Двубашенная - вектор запроса, вектора айтема
2) Доп модуль для cross-interaction фичей
3) Используют контекст активной сессии


Данные
Берут кликстрим логов с поиска за T дней. Для каждого поискового запроса собирают показанные айтемы и взаимодействие пользователя с ними (клик, скачивание пина, скриншот и т д).
В качестве трейна берут T-k дней и k дней в тест.


Архитектура
Состоит из нескольких блоков: Query Tower, Item Tower, Segmented Aggregation.
Towers - принимают на вход фичи соответсвующей сущности, прогоняют через Feature Crossing, По сути механизм внимания.

Используют IQP (Segmented Aggregation.) - счетчики совстречаемости для сущности p и q нормированные на частоту q. В качестве p и q могут выступать категорийные фичи: страна, пол, запрос, айтем. Они помогают ухватить долгосрочный интерес.

Лосс
Состоит из 2 - cross entropy для ранжирования выдач и sampled soft max - для Retrieval части:
1) В качестве таргета берут Ui на поисковой выдачи. Если у пользователя есть хотя бы 1 положительное действие, то Ui=1, иначе 0.
2) Семплируют из батача негативы + LogQ и подают в софтмакс. Подают эмбединги айтема и запроса


Оффлайн Метрики
Берут метрику HITS@K.
Получилось улучшить качество по сравнению с Two Tower моделями на 3 процента, при это вычислений стало больше на 10%. Дополнительно смотрят влияние каждого блока на качество (моя любимая часть любой статьи - показатель, что все компоненты уместны)


Железо
Тренируют на 8 карточках A100 по 80 GB. Что в онлайне - не нашел


A/B-test
Основной метрикой берут SIFR = (количество полезных выдач)/(общее количество выдач). Выдача полезная - если было хотя бы 1 целевое действие . Выросла на 6.5%


Что я думаю.

Крутая идея использовать счетчики совстречаемости на этапе преранжирования/кандгена - их можно подготовить заранее. Также показали как выглядит хорошее исполнение поиска:
1) Берем фичи запроса - поверх них внимание
2) Берем айтемы, на их фичах тоже внимание
3) Дот продукт и лосс к нем, Для большей робастности - in batch negative.


Выглядит как классический рецепт для статей такого уровня - еще раз убедился, что она рабочий

Также радует - простая и понятная метрика в оффлайне. Стоит тоже ориентироваться на такой подход .

300...
Кажется придется обзор на нейроранкеры в индустрии делать

Я не буду молчать

Уже больше 3 лет я работаю в Авито в роли DS. Последние мои задачи связаны с применением трансформеров для задачи Retrieval. Для решения задачи приходится много времени уделять подготовки данных и выкатки в прод под АБТ. Из-за того, что главной целью являет качнуть метрику пользователей приходится все катить с горящей задницей.

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

Кроме того, прод постоянно отламывается по непонятным причинам. Приходится 24/7 смотреть в графану - а ведь DS. Все это сильно утомляет.

Сами модели с годами умнее не становятся - в каждой новой статье просто добавляют новые данные и меняют порядок умножения матриц. Сейчас рекомендательные системы - это лишь попытка угнаться за LLM и NLP сферой. Все боятся признать, что хорошая LLM с понимаем интересов пользователей и каталогов товаров легко заменит отделы DS.

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

Попробовал репу для запуска торчовых моделей на go.

В чем суть?
На питоне очень приятно предобрабатывать данные для тренировки модели и реализовывать сами модели. Но в рантайме держать питон сервис уже не так приятно - есть ограничение на большую нагрузку.

Как можно подойти к проблеме?
Конечно же перевести deep learning модель на компелируемый язык. Например на go. Для этого нужно экспортировать модель в onnx формате. И заюзать репу выше. Она как раз умеет работать с onnx форматом, избавляя от питона в рантайме

Мой опыт
Попробовал перевести сервис с одной из моделей. Архитектурно - это небольшой трансформер с 2 слоями attention.

На небольшой нагрузку (~1kRPM) модель отрабатывает дольше (примерно на 10-20%). Но открывает возможности для более гибкой предобработки данных для моделей не ограничиваясь одним сервисом.

Тестовый пост для комментов

Channel name was changed to «Б/У ml»

Физтех
Недавно добавился в папку с физтехами. В ней есть не только про ds, но и про жизнь.

Из тех, что я читаю +- регулярно есть:
- канал Маши про жизнь и путешествия
- канал Леши про LLM
- канал тим лида из ДоДо про соревки и индустрию

Можно посмотреть, чем занимаются выпускники после вуза 😎

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

Для истории приложу материалы по решением
Разбор решений
1 место - пост c описанием решения
2 место - статья, пост в канале участника и пост в группе
4 место - гитхаб

Дата ёлка
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 призов . Достойный вопрос не задал на тему с нейронками - надо подтянуть 😊

ВАУ!!! 100 подписчиков!!! Спасибо ребят, что залетаете и читаете обзоры на статьи!!!

В прошлом году было много интересных статей, в этом будет еще больше 😃

Сейчас пробую завести автоэкондеры для матричной факторизации. Если даст какой то профит (или и не даст), то закину постик

А что по ресурсам?
В статьях от Бигтех компаний (Алибаба, Пинтерест ) часто указывают ресурсы для тренировки и раскатки в продакшен.
ECR - это прежде всего академический ресерч, поэтому в этой статье нет смысла писать про нагрузку и ресурсы.

Уместное использование LLM в проде есть в статье - OmniSearchSage (про нее был постик). Там использовали LLM для генерации описаний к контенту, где мало текста, но картинка содержит много информации о пине. Но это все еще не CR

Интересно посмотреть - завел ли кто-нибудь уместно CR в прод

Что я думаю
Мне понравился подход и метод как подошли к задачи рекомендаций - сделать отдельный токен для фильма/ для сущностей и учесть как они влияют на эмоции человека - видно, что люди глубоко подошли к пониманию данных. Пока не совсем прозрачно как адаптировать под другие домены - e-commerce, рекомендации музыки и т д, Также датасет был небольшой - около 10к диалогов, что для современных рек систем крайне мало. Возможно если использовать классические LLM или UniCRS на большом объеме данных, то модельки смогут сами уловить сигнал с эмоциями/фидбеком пользователя (если конечно переобучать и уделить ресурс этому сигналу).

Похожий подход хочется попробовать в работе - сейчас я занимаюсь рекомендациями основанными на параметрах объявлений. В терминах статьи это и есть entities - может неплохо выйти

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 и тд ) - с ними она тоже справилась.

Дроп скоро появится

PS статья от алибабы . И я узнал это только после перечитывания статьи. Для меня это было шоком, так как архитектура подхода не выглядит как монстр с 1000 и 1 щупальцой. А подход относительно элегантный :)