Реализация Slope One предлагает плохие рекомендации - PullRequest
Новая
       6

Реализация Slope One предлагает плохие рекомендации

3 голосов
/ 06 февраля 2011

Я пытаюсь реализовать алгоритм наклона Один через PHP для рекомендации элементов на основе пользователя.Для этого я использую библиотеку OpenSlopeOne .У меня проблема в том, что сгенерированные рекомендации не имеют никакого отношения к пользователю.

В настоящее время у меня есть две таблицы: user_ratings и slope_one.Таблица user_ratings довольно проста.Он содержит оценку за элемент, заданную этим конкретным пользователем (user_id, item_id и user_item_rating).Таблица slope_one соответствует схеме по умолчанию OpenSlopeOne: item_id1, item_id2, время и рейтинг.

Таблица slope_one заполняется с использованием следующей процедуры SQL: 

CREATE PROCEDURE `slope_one`()
begin                    
    DECLARE tmp_item_id int;
    DECLARE done int default 0;                    
    DECLARE mycursor CURSOR FOR select distinct item_id from user_ratings;
    DECLARE CONTINUE HANDLER FOR NOT FOUND set done=1;
    open mycursor;
    while (!done) do
        fetch mycursor into tmp_item_id;
        if (!done) then
            insert into slope_one (select a.item_id as item_id1,b.item_id as item_id2,count(*) as times, sum(a.rating-b.rating) as rating from user_ratings a, user_ratings b where a.item_id = tmp_item_id and b.item_id != a.item_id and a.user_id=b.user_id group by a.item_id,b.item_id);
        end if;
    END while;
    close mycursor;
end

И для получения наиболее важных рекомендаций для данного пользователя я выполняю следующий запрос: 

SELECT
    item.* 
FROM
    slope_one s,
    user_ratings u,
    item
WHERE 
    u.user_id = '{USER_ID}' AND 
    s.item_id1 = u.item_id AND 
    s.item_id2 != u.item_id AND
    item.id = s.item_id2
GROUP BY 
    s.item_id2 
ORDER BY
    SUM(u.rating * s.times - s.rating) / SUM(s.times) DESC
LIMIT 20

Как уже говорилось, это просто не работает.Я работаю с довольно большим набором данных (более 10 000 рекомендаций), но я просто не вижу никакой формы корреляции.На самом деле, большинство рекомендаций кажутся идентичными для пользователей, даже с совершенно несопоставимыми оценками элементов.

Ответы [ 2 ]

5 голосов
/ 06 февраля 2011

(Да, я намеренно даю другой ответ.)

Другой ответ заключается в том, что все эти алгоритмы имеют свои сильные и слабые стороны и преуспевают в один день, но не в другие. Но некоторое время назад у меня было похожее замечание о склоне-1, и я даже получил некоторые комментарии от Даниэля Лемира, который первоначально предложил реализацию.

Рассмотрим, что происходит, когда данные становятся на 100% плотными - каждый пользователь оценивает каждый элемент. Разница рейтинга между элементом A и элементом B представляет собой среднее для всех пользователей u, занимающихся совместной оценкой, разницы в рейтинге: среднее (r_uB - r_uA). Но, как оценивают все пользователи, это просто приближается к средней оценке (по всем пользователям) для B, минус средняя оценка для A: средняя (r_uB) - средняя (r_uA). Назовите эти средние (B) и средние (A) для простоты.

Представьте себе предмет Р с самым высоким средним рейтингом в целом. Разница между A и P будет больше, чем разница между A и любым другим B; это (среднее (P) - среднее (A)), против (среднее (B) - среднее (A)). Различия P всегда выше, чем у любого другого B (среднее (P) - среднее (B)).

Но поскольку алгоритм оценивает предпочтения, добавляя эти различия к рейтингам пользователей и усредняя их, P всегда становится главной рекомендацией для всех пользователей. Независимо от того, что рейтинг пользователя, и независимо от различий, сумма для P (и, следовательно, в среднем) является наибольшей. И так далее.

Это тенденция, когда данные становятся плотными, и я думаю, что вы уже видите некоторое эхо этого эффекта. Это не «неправильно» (в конце концов, P высоко ценится!), Но интуитивно кажется неоптимальным, так как рекомендации становятся не персонализированными.

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

Другой вариант, реализованный в Apache Mahout, заключается в использовании лучшего взвешивания при расчете оценочных предпочтений. Он имеет возможность взвешивания против различий, которые имеют высокое стандартное отклонение, и для тех, кто имеет низкое стандартное отклонение. Это благоприятствует различиям, рассчитанным для многих пользователей. Это грубый шаг, но помогает.

1 голос
/ 06 февраля 2011

Вы можете попробовать реализацию Java в Apache Mahout .* Mahout in Action содержит выдержку , которая описывает его использование.Это может быть полезно в качестве второй точки данных и поможет отличить алгоритм от проблем реализации.

Начиная с Mahout 0.9, напоминания прекращены.Смотри https://mahout.apache.org/

...