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

#algorithm

#алгоритм

Вопрос:

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

Разница между ними заключается в том, что мой просто подсчитывает «продукты», которые вы просматривали за один сеанс, в то время как Amazon подсчитывает каждую покупку / оформление заказа.

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

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

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

Комментарии:

1. Название заставило меня на секунду подумать, что это спам … лол

2. вас также заинтересует ссылка на машинное обучение: рекомендательные алгоритмы?

3. Возможно, немного поздно, но я бы рекомендовал взглянуть на User-based Collaborative Filtering approach

Ответ №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       |
  

Запрос

 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 не отображается в результатах.

Комментарии:

1. не могу понять, что вы сделали. подсчет мне не поможет. поскольку мне нужно знать идентификаторы продуктов в одной и той же группе

2. @Himberjack добавлено дополнительное разъяснение, извините.

Ответ №2:

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

Ответ №3:

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

Комментарии:

1. ДА. Что я делаю, так это добавляю 1 каждый раз, когда сталкиваюсь с парой идентификаторов продукта

Ответ №4:

Вам не понадобятся никакие (любые! 1 )

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

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

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

Примеры такого подхода можно найти (на Python) в Programming Collective Intelligence, опубликованном O’Reilly

Ответ №5:

ОК. Я думаю, что я понял это. часть работы — это реализация кода.

Что я сделал, так это сгруппировал по идентификатору сеанса, ProductID . затем в моем коде я перебираю каждый идентификатор сеанса и создаю словарь с парами. например, если у меня есть 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 к соответствующей паре / с.

в конце я выровняю веса и пары.

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

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

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