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

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

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