Совместная фильтрация: неперсонализированное сходство элементов от элемента

Question

Я пытаюсь вычислить сходство между предметами по аналогии с тем, что Amazon "Клиенты, которые просмотрели / приобрели X, также просмотрели / приобрели Y и Z". Все примеры и ссылки, которые я видел, относятся либо к подобию вычислительных элементов для ранжированных элементов, либо к поиску сходства пользователя с пользователем, либо к поиску рекомендуемых элементов на основе истории текущих пользователей. Я хотел бы начать с нецелевого подхода, прежде чем учитывать предпочтения текущих пользователей.

Рассматривая рекомендации Amazon.com, в белой книге , они используют следующую логику для сходства автономных элементов:

For each item in product catalog, I1 
  For each customer C who purchased I1
    For each item I2 purchased by customer C
       Record that a customer purchased I1 and I2
  For each item I2 
    Compute the similarity between I1 and I2

Если я правильно понимаю, к тому времени, когда мы находимся в «Вычислить сходство между I1 и I2», у меня есть список предметов (I2), купленных вместе с одним значением I1 (внешний цикл).

Как выполняется этот расчет?

Другая идея состоит в том, что я переосмысливаю это и усложняю, чем мне нужно. Было бы достаточно сделать запрос top-n для подсчета I2, купленного вместе с I1?

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

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

edit: хотя я перечислил python как тег, я бы предпочел хранить логику внутри БД, предпочтительно используя Oracle PL / SQL.

Answer 1

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

        Item1  Item2 ... ItemN
 User1  0        1   ...  0
 User2  1        1   ...  0 
  .
  .
  .
 UserM  1        0   ...  0

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

        Item1  Item2 ... ItemN
 Item1  1       1/M  ...  0
 Item2  1/M     1    ...  0 
  .
  .
  .
 ItemN  0       0    ...  1

Это можно объяснить как «Клиенты, которые просмотрели / приобрели X, также просмотрели / приобрели Y, Z, ...» (Совместная фильтрация).Потому что векторизация Предмета основана на приобретении пользователем.

Логика Amazon точно такая же, как и выше, в то время как ее целью является повышение эффективности .Как они сказали

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

Answer 2

Есть хорошая книга О'Рейли на эту тему. В то время как технический документ мог бы изложить логику в таком псевдокоде, я не думаю, что такой подход будет очень хорошо масштабироваться. Все расчеты являются вероятностными расчетами, поэтому такие вещи, как Теорема Байеса , привыкли говорить: «Если человек А приобрел Х, какова вероятность, что он приобрел Z? Простое зацикливание данных работает слишком усердно. Вы должны пройти через все это для каждого человека.

Answer 3

@ Нейл или кто-либо еще, кто придет к этому вопросу позже:

Выбор метрики подобия зависит от вас, и вы можете оставить его в будущем податливым. Для начала ознакомьтесь со статьей в Википедии о норме Фробениуса. Или, как в ссылке, которую вы предоставили, коэффициент Jaccard cos(I1,I2).

Элемент пользователя & ndash; vs & ndash; пользователь-пользователь & ndash; vs & ndash; предмет-предмет или любая другая комбинация не может быть объективно решена. Это зависит от того, какие данные вы можете получить от своих пользователей, как пользовательский интерфейс извлекает из них информацию, какие части ваших данных вы считаете надежными, и ваши собственные временные ограничения (насколько гибриды идут).

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

Answer 4

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

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