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

Question

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

Глядя на Amazon.com recommendations white paper, они используют следующую логику для автономного детала-элемент подобия:

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 

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

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

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

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

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

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

Answer 1

В этой теме есть O'Reilly book. В то время как технический документ может заложить логику в псевдокоде, подобном этому, я не думаю, что этот подход будет очень хорошо масштабироваться. Расчеты - все вероятностные вычисления, поэтому такие вещи, как Bayes' Theorem, привыкли говорить: «Учитывая личность приобретенного X, какова вероятность того, что они приобрели Z?» Прямое чередование данных слишком усложняется. Вы должны пройти все это для каждого человека.

Answer 2

@Neil или тот, кто приходит на этот вопрос позже:

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

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

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

Answer 3

Давайте поразмыслим о совместной фильтрации. предположим, что мы имеем матрицу

процедура закупки

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

Тогда мы можем вычислить Item схожесть с использованием вектора-столбца, например использование косинус. Мы имеем матрицу пункт подобия симметрии, как показано ниже

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

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

логика Амазонки точно так же с выше, а это цель заключается в улучшить эффективный. По их словам

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