Попробовал репу для запуска торчовых моделей на 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 метод быстрее другого

Параметры для каждого набора данных.

Замеряли качество на классических рекомендаметльных адасетах + внутренний датасет LinkedIn.

В данном случае сравнивают append (BST) и concat (TransAct)

Коллеги, вы как боретесь с item cold start?


Сегодня расскажу про статью от Google: «Item-centric Exploration for Cold Start Problem»

На недавнем RecSys 2025 было много неплохих работ, которые зацепили сходу.

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

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

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

Допустим, мы научились предсказывать вероятность клика/контакта от показа — но насколько такой вероятности можно доверять?

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

Что предлагают авторы:

Давайте не показывать айтемы слепо. Посчитаем честную конверсию для айтема из показа в клик/контакт. Также у нас уже есть обученная модель ранжирования, которая предсказывает персональную вероятность клика S на айтем для конкретного пользователя.

Если персональная вероятность меньше, чем глобальная вероятность клика - 2 * std, то этот айтем можно не показывать пользователю — с большой вероятностью он ему не интересен.

Но получается, что мы уменьшаем пул айтемов, не предлагая ничего взамен?

Тут на арену выходят параметры alpha и beta. Когда мы считаем честную вероятность N+/N (N+ — положительное событие "клик/контакт", N — показы), мы можем добавить в числитель alpha, а в знаменатель — alpha + beta.

Таким образом, если у айтема было много N+, то alpha и beta не внесут большого вклада — мы уверены в истинной конверсии айтема.

Но если айтем холодный, то alpha и beta значительно скорректируют (повысят) его расчетную конверсию.

На картинке представлена полная картина: условия фильтрации (1), перерасчитанная конверсия (2) и поправка для оценки std (3).

Результат:

Метод позволяет без дополнительного обучения модели поднять выдачу для холодных айтемов.

Мои мысли:

Такую поправку очень легко использовать в современных индустриальных рекомендательных системах — расчет количества контактов/кликов и показов это уже решенная задача.

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

Для кандидатогенерации — чуть сложнее. Если брать в расчет вероятностные кандгены — например, на базе semantic ids, где можно посчитать вероятность на этапе инференса — то, добавив поправку, можно настроить количество свежих айтемов для пользователя. Для векторного отбора кандидатов — сложнее, так как вероятность будет известна уже после похода в БД за кандидатами.

Вот такие мысли по статье :)
Делитесь, как еще вы решаете cold-start проблему для айтемов.