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

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

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

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

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

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

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

Для истории приложу материалы по решением
Разбор решений
1 место - пост c описанием решения
2 место - статья, пост в канале участника и пост в группе
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сегодня рассмотрим статью поискового ранжирования от 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.


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

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

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

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

Формула рассчета IQP. С - это количество. C(q, p) - количество совместных встреч сущностей, C(q) - общее количество q

Вспоминаем кросс энтропию

А также софтмакс лосс. qi - запрос, ci - контекст, pi - айтем

Берут достаточно большой датасет. Интересно, что тест тоже достаточно большой. Но для такой простой метрики легко оптимизировать рассчет

Самый кайфовый кусочек статьи. Удаляют компоненты нейронки и видят как качество снижается.

Из этих результатов можно сделать вывод:
Сессия пользователя очень сильно влияет на порядок в выдаче - надо с особым вниманием ее брать

Ну и сравнение с текущими подходами. Качество выше, но подходов не так много, чтобы быть уверенным в методе