Создание "соседей" для пользователей на основе рейтинга

Ответ 1

В книге "Программирование коллективного интеллекта" http://oreilly.com/catalog/9780596529321

Глава 2 "Составление рекомендаций" действительно помогает описать методы рекомендации для людей, основанные на сходстве между пользователями. Вы можете использовать алгоритмы подобия, чтобы найти "соседей", которые вы ищете. Эта глава доступна в поисковой книге google здесь:
http://books.google.com/books?id=fEsZ3Ey-Hq4C&printsec=frontcover

Ответ 2

Обязательно посмотрите Совместная фильтрация. Многие системы рекомендаций используют совместную фильтрацию, чтобы предлагать элементы пользователям. Они делают это, находя "соседей", а затем предлагают предметы, которые ваши соседи оценили высоко, но вы не оценили их. Вы можете зайти так далеко, как найти соседей, и кто знает, может быть, вам понадобятся рекомендации в будущем.

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

Приз Netflix - это соревнование, чтобы определить, кто может наиболее эффективно решить эту проблему. Следуйте ссылкам со своих LeaderBoard. Некоторые из конкурентов разделяют их решения.

Что касается вычислительно недорогого решения, вы можете попробовать следующее:

• Создайте категории для своих товаров. Если мы говорим о музыке, они могут быть классическими, рок, джаз, хип-хоп... или идти дальше: Grindcore, Math Rock, Riot Grrrl...
• Теперь, каждый раз, когда пользователь оценивает товар, сворачивайте свои рейтинги на уровне категории. Таким образом, вы знаете, что "Пользователь А" любит Хонки Тонк и Киссид Хаус, потому что они часто дают эти высокие оценки. Частота и сила, вероятно, важны для совокупного показателя вашей категории.
• Когда нужно найти соседей, а не путешествовать по всем рейтингам, просто найдите похожие оценки в категориях.

Этот метод будет не таким точным, но быстрым.

Приветствия.

Ответ 3

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

Хорошей возможностью здесь является использование спектральной кластеризации которая требует именно того, что у вас есть: матрицы подобия. Недостатком является то, что вам все равно нужно вычислить свою функцию совместимости для каждой пары точек, т.е. е. алгоритм O (n ^ 2).

Если вам абсолютно необходим алгоритм быстрее, чем O (n ^ 2), вы можете попробовать подход пространства различий. Идея очень проста. Вы инвертируете свою функцию совместимости (например, принимая ее обратную), чтобы превратить ее в меру несходства или расстояния. Затем вы сравниваете каждый элемент (пользователь в вашем случае) с набором элементов прототипа и обрабатываете полученные расстояния как координаты в пространстве. Например, если у вас есть 100 прототипов, каждый пользователь будет представлен вектором из 100 элементов, т.е. е. точкой в ​​100-мерном пространстве. Затем вы можете использовать любой стандартный алгоритм кластеризации, например K-means.

Вопрос в том, как вы выбираете прототипы и сколько вам нужно. Однако были опробованы различные эвристики, однако здесь представлена ​​диссертация, в которой утверждается, что выбор прототипов случайным образом может быть достаточным. В нем показаны эксперименты, в которых с использованием 100 или 200 случайно выбранных прототипов получены хорошие результаты. В вашем случае, если у вас 1000 пользователей, и вы выбрали 200 из них, чтобы быть прототипами, вам нужно будет оценить свою совместимость 200 000 раз, что является улучшением в 2,5 раза по сравнению с каждой парой. Однако реальным преимуществом является то, что для 1 000 000 пользователей 200 прототипов будет по-прежнему достаточным, и вам нужно будет собрать 200 000 000 сравнений, а не 500 000 000 000, что будет улучшено в 2500 раз. Что вы получаете, это алгоритм O (n), который лучше, чем O (n ^ 2), несмотря на потенциально большой постоянный коэффициент.

Ответ 4

Проблема заключается в том, чтобы быть "проблемами классификации". Да, так много решений и подходов.

Чтобы начать исследование, проверьте следующее: http://en.wikipedia.org/wiki/Statistical_classification

Ответ 5

Слышали ли вы о kohonen networks?

Его собственный алгоритм обучения, который группирует аналогичные переменные в аналогичные слоты. Хотя большинство таких сайтов, как тот, который я связываю с вами, отображает сеть как двумерную, мало участвует в распространении алгоритма на гиперкабель с несколькими измерениями.

При такой структуре данных поиск и хранение соседей со схожими вкусами тривиально, так как аналогичные пользователи должны быть хранилищами в аналогичных местах (почти как обратный хеш-код).

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

Кстати, чтобы найти хорошие разделительные переменные, лучшим алгоритмом является дерево решений. Узлы, расположенные ближе к корню, будут самыми важными переменными, чтобы установить "близость".

Ответ 6

Похоже, вам нужно прочитать алгоритмы кластеризации. Общая идея заключается в том, что вместо того, чтобы сравнивать каждую точку с каждой другой точкой каждый раз, когда вы делите их в кластерах похожих точек. Тогда окрестностью могут быть все точки в одном кластере. Число/размер кластеров обычно является параметром алгоритма кластеризации.

Yo может найти видео о кластеризации в серии Google о кластерные вычисления и mapreduce.

Ответ 7

Обеспокоенность по производительности может быть значительно уменьшена, если вы рассматриваете это как проблему сборки/пакета, а не запрос в реальном времени.

Граф может быть статически вычислен, затем латентно обновлен, например. ежечасно, ежедневно и т.д., чтобы затем генерировать ребра и хранилища, оптимизированные для запроса времени выполнения, например. 10 лучших пользователей для каждого пользователя.

+1 для программирования коллективного интеллекта тоже - это очень информативно - жаль, что это не было (или я не был!) как ориентированный на Python, но все же хороший.