Где у покупок подлежащее? FAQ про NLP в рекомендациях В комментах к одному из прошлых постов подписчик задал несколько хороших вопросов про перенос методов из NLP в RecSys. Т.к. обещал ответить, отвечаю. Что в RecSys вместо пробелов? Пробелы не нужны, т.к. границы товаров уже известны: каждый ID - отдельный токен. Если товар кодируется несколькими токенами, границы задаются форматом: фиксированной длиной кода или разделителем. В NLP так-то мы тоже анализируем последовательность токенов только после токенизации, в RecSys аналогом токенизации можно считать выбор, кодируем мы товар его свойствами (и они токены) или id товара - это условно как n-граммы или слова в NLP. В языке есть грамматика и обязательные последовательности. А в рекомендациях? Правила языка все равно не обязывают автора текста их соблюдать неукоснительно, в NLP модели смотрят на статистику - как люди говорят, тому модель и научится. В рекомендациях также: после принтера необязательно покупать картридж, но тот факт, что он вам все равно скорее всего понадобится, влияет на статистику покупок и полезен для прогноза. Насколько важен порядок? Тут по-разному. "Посмотрел десять камер, купил одну" и "купил камеру, посмотрел десять других" - одинаковый набор действий, но потенциально разные ситуации. А вот порядок добавления хлеба и молока в корзину может ничего не значить (а может и значить, что после одного товара вспомнил о другом, и это может быть важно для RecSys). Но строго говоря, пользу порядка надо проверять на конкретных данных. Те же позиционные эмбеддинги в рекомендациях вам использовать не обязательно и вообще те модели, где порядок сильно влияет на прогноз. Что такое attention в рекомендациях? Купил плавки два года назад - предложат сланцы? Attention обучается сам на исторических данных, а уж что он там выучит вопрос статистики: если в тексте он выхватывает синтаксическую и смысловую связь между словами (и то, это всего лишь наша человеческая интерпретация), то в просмотрах или покупках он будет учиться понимать, на какой именно товар из логов смотреть, когда оцениваешь вероятность покупки картриджа или чехла для айфона. Т.е. это не просто тапки к плавкам и шоколадка к минералке, а в том числе "всегда покупал андроиды, чехол на айфон маловероятно заинтересует" и прочая "бизнес-логика", которую можно перечислять вручную, а можно просто усвоить при обучении на данных. Если история состоит из покупок одного и того же товара, что предсказывать дальше? Возможно, снова его же. Для кошачьего корма, например, прекрасный прогноз. Если других сигналов нет, информации о новых интересах мало, а "обязательно покажи что-нибудь новое" - отдельная цель, которая может конфликтовать с точностью предсказания. Но если таковая цель есть, то к логам с одним только кошачьим кормом показать красивую игрушку для кошки или автоматический кошачий туалет или поилку с фонтанчиком - все равно намного лучше, чем рандом. LLM для этого, разумеется, не нужна, то в целом любые методы из NLP справятся. Те же совместные встречаемости слов по PMI (pointwise mutual information), десятилетиями использовавшиеся для выделения в текстах коллокаций, прекрасно применялись и для бейзлайна в рекомендациях или отбора кандидатов в рекомендации. И прекрасно справятся с кошачьими игрушками к кошачьему корму. Куда при генерации Semantic ID делась проблема полноты кандидатов? Принципиально - никуда. Semantic ID - способ кодирования айтема, а не гарантия полноты поиска. Но как только у вас вместо ID айтема появляется эмбеддинг, вы всегда можете найти ближайшие к нему в пространстве эмбеддингов. Даже если они будут не очень похожи на запрос, это уже в любом случае что-то. В случае Semantic ID вида "несколько дискретных кодов" (ну как город, улица, дом в обычном адресе) становится еще проще - вы просто берете в кандидаты ближайшие "дома" с той же "улицы". В целом все то же самое можно делать и без умных сложных методов, а просто с хорошим деревом категорий в каталоге, но такое удовольствие есть у нас не всегда, особенно для новых товаров/фильмов/треков/видосов (особенно на UGC платформах).