Наконец-то ods опубликовали мой доклад, который я рассказывал в начале лета. В нем я делюсь, как можно использовать sasrec модель для рекомендации товаров - https://www.youtube.com/watch?v=YXkcNeCJhgc&t=363s
Приятного просмотра :)

i2i, или triggered-inducted recommendation.
Классика
В традиционных задачах рекомендаций, как user-to-item (u2i), система подбирает элементы для пользователя, основываясь на его истории. Например, если пользователь смотрел ножи и вилки, то логично показать и другие товары из кухонной утвари. В такой задаче чаще всего берут историю пользователя и пытаются предсказать , что он посмотрит в будущем.

i2i
На практике, u2i обычно сочетается с i2i сценарием. Это можно увидеть после того, как кликнуть на айтем, появляются подборки - "Похожих", "Товаров со скидкой", "Покупают вместе". Каждая из них пытается угадать намерение (интент) пользователя. Чаще всего в компаниях используют отдельную модель для u2i и для i2i, но саму связку user-click->item-buy->item в модели не закладывают. Например, в любом маркетплейсе, пользователь сначала кликает на айтем, потом может посмотреть похожие и покупает.

Идея
trigger&target
Triggered-inducted подход заключается именно в том, чтобы учить модель на задачу CTR синхронно u2i и i2i часть системы. Trigger — это элемент, на который пользователь кликнул, а target — это набор элементов, который предлагается пользователю после клика на trigger. И в ранжировании target айтемов важно учесть сигнал, что пользователя привлек именно trigger.

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

Основные челленджи
Учет покупок
У нас есть пользователь и датасет из айтемов (trigger и target). Например, если пользователь смотрел приборы для кухни и уже купил ложку, то при клике на вилку (trigger), хочется , чтобы система поднимала в выдаче другие вилки, ножи, тарелки, но не ложки - у него они уже есть. Если система игнорирует факт покупки, это может привести к ухудшению пользовательского опыта — показ ненужных товаров снижает вероятность покупки.

Учет интента
В системе хочется учесть интент пользователя. И тут скрывается второй челендж - если пользователь кликнул на нож, то ему стоит в target показывать другие ножи или все-таки товары связанные с кухней? Оба этих юзкейса хочется решить в нашей системе

Как можно решить?
Эвристики
Простое решение - использовать эвристик. Можно отслеживать, сколько раз пользователь просматривал товары одной категории, чтобы динамически корректировать выдачу. Например, заметить, что после покупки ложки, не надо показывать ее пользователю, если после события покупки пользователи нашей системы перестают покупать товары той же категории в 1 сессии

Нейросетевой подход
Для более сложных сценариев — можно применить нейросетевые модели, такие как подход из статьи Alibaba. В ней как раз и подсчитали важность связать u2i и i2i рекомендации.
Статья про метод который использует общие веса для trigger и target частей системы. Также в обоих коленах используется история пользователя, что позволит понижать в выдачей уже купленные товары. Есть отдельные блоки для нахождения максимально похожих элементов к данному и для подбор к интенту пользователя (желанию купить кухонную утварь). Подробнее я расскажу в отдельном посте.

Что я думаю?
Про статью
Авторы статьи определили актуальные проблемы - за это "+". Конечно, мы живем в 21 веке и все любят нейронки, но эти проблемы можно учесть и проще. Почему бы просто не отфильтровывать уже купленные товары ? Или подсчитать, сколько раз в сессии пользователь покупал товары одной категории (вилки) или разных (ножи, тарелки) и использовать эти веса для формирования выдачи?
Хотя нейросетевые модели дают прирост в доли процента, и это очень важно в масштабных системах, простые эвристики могут закрыть 90% задач. Они дешевле в реализации, легче масштабируются и гораздо объяснимее. А для оставшихся 10% сложных кейсов уже можно применять трансформеры.

Про подход
Хочется посмотреть на реальных данных - на сколько важна история пользователя при формировании "похожих" . На практике под каждый интент пользователя приходится делать отдельный ресерч и пилить отдельную модель, но если появляется вариант убрать такую "ручную" работу, то можно брать новые челленджи для продукта, а не копаться, какую вкладку использовать - "похожие" или "покупают вместе" или "распродажа".

PS. если кто-то сомневается, что начинать с трансформерных подходов это не перебор. Ставьте 🙈- если согласны что это оверхед для 1-ой итерации, 😎 - все просто и понятно

А вектор пользователя это хорошая идея?
В рекомендательных системах распространен подход, когда мы пользователя представляем вектором 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 объявлений вперед

Идея очень льстит - из коробки получаем "умные" вектора пользователей. Перед тем как пилить подобные оверхеды, сначала я проверяю свой чеклист с вопросами:
* а какая продуктовая потребность?
* какой сигнал должна выучить модель?
* могу ли я апроксимировать этот сигнал эвристиками и протестировать в оффлайне/онлайне?

Если эвристика заходит и пользователям и вправду уместен сигнал, то можно заносить в модель и смотреть как она справится

PS по традиции стремная архитектура сети, которая не внушает доверия :)

Предыдущая статья была из Alibaba: продуктовое применение подхода. Статья на которую они ссылаются из академических кругов - ICL имеет еще более страшную архитектуру. В ней подробно раскрыты проблема "вектора пользователя"

Учтем иерархию элегантно

В задачах связанных с маркетплейсами и 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

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

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

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

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

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

А что по ресурсам?
В статьях от Бигтех компаний (Алибаба, Пинтерест ) часто указывают ресурсы для тренировки и раскатки в продакшен.
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 призов . Достойный вопрос не задал на тему с нейронками - надо подтянуть 😊