Физтех
Недавно добавился в папку с физтехами. В ней есть не только про 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 - айтем

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

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

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

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

Обязательно к ознакомлению)) Ждем 2-ой части

Обещанные слайды лекции

Особенность в рекомендательных системах

Контекст
В последнее время основные статьи в рекомендательных системах связанны с применением нейронных сетей.

Выглядит это всегда примерно так для сценария u2i:
1) Есть айтем -> кодируем через nn.Embedding его фичи
2) История пользователя состоит из айтемов -> используем наработку из 1) + encoder/decoder (трансформеры, aka sasrec/bert4rec) для кодирования вектора юзера.
3) Обучаем на задачу близости вектора пользователя со следующим айтемом/множеством айтемов. Возможно доп задачи: sasrec учится на next-item для всей истории, которые в проде он никогда не увидит

И когда пытаешь завести алгоритм для своей задачи - в первую очередь я замечаю popularity bias . Веса соотвествующие векторам наиболее популярных айтемов/фичей айтемов - чаще обновляеются . В первые итерации модель выучивает именно такие объявления рекомендовать - в своих задач я это замечал.

А следующие батчи/эпохи пытается выйти из этого локального минимума состояния и начать показывать более персональный контент. На эту фазу и уходят основные компуты обучения.

Для решения этой проблемы активно используют:
a) random negative sampling
b) in-batch negative sampling
c) и LogQ сверху

На практике мне хватало a) и b) . Добавление c) при существующих a) и b) доп качество не давало

А что в классике
Изначально рекомендательные системы решались на основе матриц соовстречаемости - тык.
Как это выглядело:
1) Есть айтемы и истории пользователя -> строим матрицу как часто 1 айтем встречался с другим айтемом в этой истории
2) К каждому айтему в истории достаем наиболее часто встречающиеся айтемы используя матрицу соовстречаемости - кандидаты айтема.
3) Вместе с айтемом достаем и некий скор (достаем столбец) - меру соовстречаемости. И если для нескольких айтемов в истории совпали кандидаты, то можем сложить/перемножить скоры - и получить финальный скор для каждого кандидата. Потом отобрать топ K

Главная проблема в классике - как сформировать эту матрицу. Хорошее понимание данных и своего домена может помочь в этом. А применение этих методов может дать представление о том, как устроены данные. Примеры простых эвристик:
1) Поделить строчку на сумму в этой строке -> уберем байс популярности айтема (а нужно ли?) -> если ответ да, то будущий трансформер скорее всего не заведется без in-batch ns.
2) Добавить временную составляющую в историю -> учет трендов (а) -> получилось повысить скор - скорее всего трансформер еще выше сможет его выбить
3) Добавить дот продукт от контетных векторов с весом -> возможно колаборативной информации недостаточно и не все паттерны пользователи уже нашли -> скор вырос - в трансформер можно и нужно засунуть контентную часть

Когда что применять
Мне лично легче начать с классики в новом проекте. Буквально за 2-3 часа можно попробовать кучу матриц соовстречаемостей и сформировать представление о данных. Матричный метод легко параллелится на cpu, в отличии от трансформеров, которые ограничены размером батча и гпу памяти.

И когда уже сформирована интуиция как устроены данные, то можно попробовать хитрый трансформер с учетом полученных инсайдов в классике. У меня ходит кратно больше времени (3-4 дня vs 1 день на классику), чтобы завести трансформер. Это связанно с тем, что 1 такая моделька обучается от 3-4 часов , что гораздо медленнее чем матричные методы. Но зато удается выбить качество выше чем у классических алгоритмов.

В заключении
Но стоит ли оно того?

Велком в комменты: А вы часто сравниваете нейронночные методы с матричными в своих проектах? Пытаетесь выбить из классических методов максимум прежде чем тюнить нейронки? Какие другие аномалии замечали при тренировки нейроннок?

Ускорение раннего связывания для моделей ранжирования

База
В двухэтапных рекомендательных системах используются кандидатогенерация (кандген) и ранжирование.

На этапе кандгена простые модели (например, DSSM, двухбашенные архитектуры) отбирают наиболее релевантные айтемы для пользователя. Из-за большого количества айтемов применяется позднее связывание (late interaction) — например, через скалярное произведение векторов пользователя и кандидатов.

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

Контекст
В последние годы крупные компании (Google, Meta, TikTok, Pinterest ❤️ , LinkedIn, Alibaba ) активно внедряют нейросетевые модели ранжирования, которые учитывают глобальный контекст пользователя.

В статье Amortized Inference предложен метод, улучшающий SOTA-результаты для этой задачи.

Авторы берут за основу две модели с ранним связыванием (early interaction):

BST (Behavior Sequence Transformer) — кандидат добавляется в конец истории пользователя.

TransAct — кандидат конкатенируется к каждому айтему в истории.

Обе модели используют трансформеры, что позволяет оценивать кандидата с учетом всей истории. Однако у них есть ключевая проблема — высокая вычислительная сложность.

Проблема
Для каждого кандидата модель заново обрабатывает историю пользователя.
Сложность:
O(n^2⋅m⋅d+n⋅m⋅d^2)
где:

n — длина истории,
m — число кандидатов,
d — размерность эмбеддингов.

При больших
n и m (например, 1000+ кандидатов) это приводит к высоким задержкам и делает модель непрактичной для прода.

Решение
Авторы предлагают конкатенировать всех кандидатов к истории и прогонять через трансформер один раз, а затем учить модель предсказывать таргет для каждого кандидата отдельно.

Новая сложность:
O((n+m)⋅d^2+(n+m)^2⋅d)

Это дает значительное ускорение, если
m>2 (что почти всегда верно в рекомендательных системах).

Результаты
+0.18% к качеству (A/B-тесты).

+5% к latency (vs. +56% у BST и +52% у TransAct).

Вывод
Метод упрощает инференс, сохраняя качество. Его можно масштабировать с помощью Flash Attention или приближенных вычислений (например, для 3000 кандидатов, как в Авито).

Статья мне понравилась простотой и практичностью — такой подход легче внедрять в продакшене.

Слева BST , справа идея из статьи. Наглядное сравнение почему 1 метод быстрее другого