Добавление дополнительного фактора (количества кликов) в байесовскую систему ранжирования - PullRequest
Новая
       46

Добавление дополнительного фактора (количества кликов) в байесовскую систему ранжирования

4 голосов
/ 16 мая 2011

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

Я постараюсь объяснить, как все это работает, чтобы вы могли увидеть, какие данные у меня естьв моем распоряжении.

  • Участник сайта оценивает трек в диапазоне от 1 до 10.
  • Этот участник сайта имеет оценку "авторитетности", которая представляет собой всего лишь сумму баллов, набранных за различныедеятельность вокруг сайта.Пользователь получает, например, 100 баллов за оценку, и чем больше оценок он дает, тем выше его рейтинг «достоверности».В базе данных сохраняется только общая оценка достоверности, которая обновляется каждый раз, когда пользователь выполняет действие с прикрепленным вознаграждением.Эти отдельные действия не сохраняются.
  • На основании достоверности этого пользователя по сравнению с другими пользователями, которые оценили трек, для трека рассчитывается средневзвешенное значение, которое затем сохраняется как число от 1 до 100в таблице дорожек.
  • В таблице дорожек количество раз, когда прослушивается дорожка (т. е. количество воспроизведений), также сохраняется как итог.

Таким образом, данныеЯ должен работать с:

  • Общий рейтинг для трека (число от 1 до 100)
  • Количество оценок для трека
  • Количество воспроизведений длятрек

В системе графиков я хочу создать рейтинг, который использует 3 вышеупомянутых набора данных, чтобы создать справедливый баланс между качеством (общий рейтинг, нормализованный числомрейтинги) и популярность (количество пьес).НО система должна учитывать качество в большей степени, чем популярность, поэтому, например, аспект качества составляет 75% от нормированного рейтинга, а популярность - 25%.

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

Сайт написан на PHP и MySQL, если это поможет.

РЕДАКТИРОВАТЬ: в заголовке указано «количество кликов», но это в основном прямой эквивалент"количество пьес".

1 Ответ

3 голосов
/ 18 мая 2011

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

WR = (v/(v+m)) × R + (m/(v+m)) × C

So 

v << m => v/(v+m) -> 0; m/(v+m) -> 1 => WR -> C

и 

v >> m => v/(v+m) -> 1; m/(v+m) -> 0 => WR -> R

Как правило, это должно быть справедливо. Подсчитать рейтинг популярности между 0 и 100 на основе количества игр довольно сложно, если вы действительно не знаете свои данные. В качестве первой попытки вычислите среднее количество воспроизведений avg (p) и дисперсию var (p), затем вы можете использовать их для масштабирования количества воспроизведений, используя метод отбеливания: 

WHITE(P) = (p - avg(p))/var(p)

Это даст вам оценку от -1 до 1, если предположить, что ваши данные выглядят как кривая колокола. Затем вы можете масштабировать его в диапазоне от 0 до 100, снова масштабируя: 

POP = 50 * (1 + WHITE(P))

Чтобы объединить оценку на основе некоторого весового коэффициента w (например, 0,75), вы просто должны сделать: 

RATING = w x WR + (1 - w) x POP

Поиграй с ними и дай мне знать, как у тебя дела.

ПРИМЕЧАНИЕ: это не учитывает тот факт, что использование может «сыграть» популярность, купив трек много раз. Вы можете обойти это, оштрафовав несколько пьес одной песни:

deltaP = (1 - (Puser - 1) / TPuser) Где:

  • deltaP = Изменение в # воспроизведениях
  • Puser = количество раз, когда этот пользователь играл этот трек
  • TPuser = общее количество треков (не уникальных), проигранных пользователем

Таким образом, чем больше раз пользователь проигрывает только один трек, тем меньше он учитывается в общем количестве воспроизведений для этого трека. Если у пользователей разные привычки прослушивания, то TPuser будет большим, и, следовательно, deltaP будет стремиться к 1. Это все еще можно использовать, но это хорошее начало.

...