Neo4j — рекомендация на основе истории поиска пользователя

#neo4j #cypher #neo4j-cql

#neo4j #cypher #neo4j-cql

Вопрос:

У меня есть следующие метки :-

  • Тег
  • Жанр
  • Актер
  • Директор
  • Фильм
  • Пользователь
  • Пользовательскаяистория

У пользователя моего приложения есть панель поиска, где он может вводить и искать что угодно, я сохраняю содержимое поиска пользователей в течение ограниченного периода времени для будущих рекомендаций.Каким будет запрос рекомендации на основе истории поиска пользователей? Нужно ли мне создавать отношения истории поиска? После прохождения некоторого руководства по рекомендациям я немного могу написать следующий запрос —

 MATCH (m:Movie)<-[:LIKE]-(p:Person {personId : 1})
OPTIONAL MATCH (t:Tag)
WITH collect(distinct t.tagName) as c1

OPTIONAL MATCH (g:Genre) 
WITH collect(distinct g.name)   c1 as c2

OPTIONAL MATCH (l:Language) 
WITH collect(distinct l.languageName)   c2 as c3
RETURN c3
  

Это не полный запрос, а приблизительная идея, и я не уверен, что это правильный путь? Кто-нибудь может мне помочь в этом? Большое спасибо!!

Ответ №1:

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

Найдите людей, которым нравятся те же фильмы, что и вам, какие другие фильмы им нравятся, которые вы еще не смотрели

 MATCH (p:Person {personId: 1})-[:LIKE]->(movie)<-[:LIKE]-(other)
WITH distinct other, p
MATCH (other)-[:LIKE]->(reco)
WHERE NOT (p)-[:LIKE]->(reco)
RETURN reco, count(*) as score
ORDER BY score DESC
  

Вы можете применять одинаковые запросы для поиска фильмов с одинаковыми жанрами и т. Д. И впоследствии объединять результаты.

Есть хороший пост в блоге с множеством примеров запросов для рекомендаций с помощью Cypher: http://www.markhneedham.com/blog/2015/03/27/neo4j-generating-real-time-recommendations-with-cypher /

Для рекомендаций, основанных на поиске, простым решением является разделение строки поиска на элементы, например :

 WITH split("action movie with arnold in 1997", " ") AS elements
MATCH (m:Movie)<-[r]-(object)
WHERE object.value IN elements
RETURN m, count(*) as score
  

Это предполагает, что все узлы, представляющие свойство фильма, будут иметь общее value свойство, поэтому :Tag(value) , :Year(value) , :Title(value)

Это своего рода базовая рекомендация, в обычных системах рекомендаций, основанных на истории поиска, вы бы моделировали историю как временную шкалу :

 (user)-[:LAST_SEARCH]->(s)-[:PREV_SEARCH]->(s)..
(s)-[:HAS_KEYWORD]->(keyword)
  

введите описание изображения здесь

Затем вы будете непрерывно вычислять сходство между историями поиска в качестве фонового задания. Распространенным алгоритмом является функция подобия косинуса или правдоподобия

Затем вы можете найти потенциальные похожие запросы и возвращенные фильмы на основе сходства с текущей историей пользователей и другими историями пользователей.

Наконец, конечно, вы можете объединить всю логику рекомендаций и вычислить итоговую оценку.

И на основе вашего комментария :

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

Это больше соответствует шаблону и на самом деле не относится к теме рекомендаций.

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

1. Спасибо за ваш ответ, но у меня уже есть рекомендации на основе ЛАЙКОВ, ОЦЕНОК и просмотров, и они работают нормально, но я хочу, чтобы рекомендации, основанные на истории поиска, были очень похожи на систему youtube reco. Ключевое слово для поиска пользователей может быть любым, например, названием фильма, именем актера, тегом и т. Д. Так, например, если это имя тега, я хочу представить те фильмы, которые имеют один и тот же тег.

2. У меня есть история поиска настроек в соответствии с вашими указаниями, но я новичок в Neo4j и не знаю, какой будет запрос на рекомендацию. Не могли бы вы помочь, пожалуйста?

3. Как вы объяснили, мы разделим строку поиска на «боевик с Арнольдом в 1997 году», но как система узнает, что «действие» — это тег или жанр, «1997» — это год или часть названия фильма ?

4. вам не нужно знать, поэтому все конечные соединения должны иметь один и тот же ключ для значения.