#algorithm
#алгоритм
Вопрос:
Я пытаюсь закодировать алгоритм, который действует немного похоже на Amazon «Люди, которые купили это, тоже купили».
Разница между ними заключается в том, что мой просто подсчитывает «продукты», которые вы просматривали за один сеанс, в то время как Amazon подсчитывает каждую покупку / оформление заказа.
У меня возникли некоторые трудности с реализацией и выяснением, каким должен быть алгоритм.
- Пока я считаю по идентификатору сеанса идентификатор продукта, который был просмотрен.
- К концу дня у меня есть много идентификаторов продуктов, которые просматривают многие идентификаторы сеансов.
- Теперь мне нужно создать какие-то клики в БД. То есть, переходя один за другим по идентификаторам сеансов и извлекая все продукты, которые они просматривали. затем записываем его как клик в таблице БД.
- Как только у меня есть клики и просматривается продукт, я просматриваю эту таблицу, чтобы посмотреть, в какой клике он находится, а затем извлекаю все остальные идентификаторы продукта.
Есть ли у вас какая-либо ссылка / идея, верен ли мой алгоритм? Есть ли лучший вариант?
Комментарии:
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 к соответствующей паре / с.
в конце я выровняю веса и пары.
все, что мне нужно сделать сейчас, это по заданному идентификатору продукта просканировать таблицу и найти клику, внутри которой она находится.
если у вас есть предложения по улучшению, пожалуйста, дайте мне знать!
спасибо всем!