"Люди, которые смотрели это, также смотрели" алгоритм

Я пытаюсь закодировать алгоритм, который немного похож на Amazon "Люди, которые купили это и купили".

Разница между двумя заключается в том, что моя только подсчитывает "продукты", которые вы наблюдали за один сеанс, в то время как Amazon подсчитывает каждую покупку/проверку.

У меня есть немного сложности с реализацией и выяснением того, что должен быть algo.

До сих пор я подсчитываю по SessionID идентификатор productID, который был просмотрен.
К концу дня у меня много идентификаторов продуктов, которые отслеживаются многими SessionID.
Теперь мне нужно создать какие-то клики в БД. То есть, один за другим на SessionIDs и извлечение всех продуктов, которые они просматривали. затем, называя его кликой в таблице БД.
Как только у меня есть клики, а продукт просматривается, я просматриваю эту таблицу, чтобы посмотреть, в какой клике она находится, а затем извлекает все остальные идентификаторы product.

Есть ли у вас какая-либо ссылка/идея, если мой алгоритм правильный? Есть ли лучший?

Ответ 1

Я смог достичь желаемого результата с помощью простой структуры БД и довольно простого запроса:

Таблица

TABLE `exa`

| sesh_id | prod_id |
---------------------
| 1       | 1       |
| 1       | 2       |
| 1       | 3       |
| 1       | 4       |
| 2       | 2       |
| 2       | 3       |
| 2       | 4       |
| 3       | 3       |
| 3       | 4       |
| 4       | 1       |
| 4       | 2       |
| 4       | 5       |

Query

SELECT c.prod_id, COUNT(*)
FROM `exa` a
JOIN `exa` b ON a.prod_id=b.prod_id
JOIN `exa` c ON b.sesh_id=c.sesh_id
WHERE a.`prod_id`=3 AND c.prod_id!=3
GROUP BY c.prod_id
ORDER BY 2 DESC;

Результат

| prod_id | COUNT |
| 4       | 9     |
| 2       | 6     |
| 1       | 3     |

Идея заключается в том, что каждый раз, когда сеанс просматривает продукт, он вставляется в таблицу [в этом случае exa]

Затем, на любом конкретном представлении продукта, вы можете проверить и посмотреть, какие другие пользователи просматривают этот продукт, также просматривают, взвешивая по частоте. Итак, в этом конкретном примере, КАЖДЫЙ, который просматривал продукт № 3, рассматривал продукт № 4, поэтому он появляется первым в сортировке. Продукт № 5 просматривался только сеансом №4, а сеанс №4 не рассматривал продукт № 3, поэтому продукт №5 не попадал в результаты.

Ответ 2

Премия NetFlix была выиграна с решением на основе SVD. Реализация матрицы ковариации в таблице базы данных является проблемой. Реализация SVD в базе данных может быть проблемой исследования. Но большинство людей назвали бы это безумным.

Ответ 3

Я бы сделал одно улучшение вашей идеи. Когда вы выясняете клики, которые идут вместе и решают, какие из самых сильных отношений вы должны добавить вес к каждому соединению. Самый простой способ рассчитать вес - это посмотреть, сколько людей, которые смотрели на продукт X, также смотрели на Y. Чем больше взглядов, тем сильнее отношения.

Ответ 4

Вам не нужны никакие (любые!) +1 s.

То, что вам нужно, это история. В случае, если "клиенты, которые купили X, также купили Y", это история покупок. В случае, если "клиенты, которые видели X, также интересовались Y", это история того, кто видел что.

Как только у вас есть история, вы готовы понять свои данные. Здесь вам нужно настроить свой ум на ближайшую соседнюю проблему. Вам нужны ближайшие соседи для X. Координаты - это пользователи, значения - 0 и 1 в зависимости от того, видел ли пользователь/купил предмет.

Самый простой способ рассчитать расстояние - это просто сумма квадратов дельт; его можно легко рассчитать один раз в час (например, если у вас много просмотров, расстояния будут слишком часто меняться), и после этого вы всегда будете иметь таблицу расстояний.

Примеры для этого подхода можно найти (в Python) в Программирование коллективного интеллекта, опубликованное O'Reilly

Ответ 5

Ok. Кажется, я понял это. частью работы является реализация кода.

То, что я сделал, было группировать по идентификатору sessionID, productID. то в моем коде я повторяю каждый sessionID, и я делаю словарь с парами. например, если у меня есть pid 10 и 20 и 30, которые являются кликой в основном. поэтому я вставляю в словарь следующим образом: 1. 10-20, weight 1 2. 20-10, weight 1 3. 10-30, weight 1 4. 30-10, weight 1 5. 20-30, eight 1. 6. 30-20, weight 1.

если я снова столкнусь с одним из значений, я добавлю +1 к соответствующей паре/с.

в конце, у меня будут выровнены веса и пары.

все, что мне нужно сделать, это данный идентификатор productID, чтобы отсканировать таблицу и найти клику внутри.

Если у вас есть предложения по улучшению, пожалуйста, дайте мне знать!

спасибо всем!