О показательности рейтинга пользователя

Возрадуйтесь же, мои ненаглядные пипчанские яшперицы! Ибо вот он, очередной пост - пухленький, текстовый, насыщенный самой желанной, самой нежной и мягонькой теоретической базой! *отборная матерщина в зале* - Ой да ладно! Я надеялся, что вам хоть чуток нравится...

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

И знаете что? И об этом многие догадываются: если разделить рейтинг на такой, который будет только за посты и другой - за комментарии, то из вообще никаким хреном не показательного параметра, можно получить только два не сильно более показательных параметра. Что несколько лучше, несомненно, но не то, чтобы очень. !Внезапно!

Да, граждане пипчане, одним пинком систему рейтинга не починить.

Вот вам пример: за свои посты юзер1 имеет -300 рейтинга, и юзер2 тоже имеет -300 рейтинга. Разница только в том, что юзер1 получил 50 плюсов и 350 минусов, а юзер2 получил 10,000 плюсов и 10,300 минусов. Посты юзера1, получается, минусило 7 из 8-и человек, поставивших оценку, а вот у юзера2 соотношение очень близко к 50/50, а колебание рейтинга в +/-300 пунктов по сути вообще погрешность.

И если юзер1 скорее всего что-то такое прям неодобряемое публикует, то юзер2 просто затрагивает в своих постах очень неоднозначные темы (что по факту куда полезнее для развития ресурса, чем однозначные, но об этом в последующих выпусках).

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

Такое происходит в основном потому, что рейтинг показывает только разницу в количестве набранных пользователем плюсов и минусов.

У такого подхода есть существенные изъяны:

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

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

Я уже предвижу кокоментарии из разряда: "на пикабу работало!". Граждане пипчане, пикабу стал популярен в первую очередь по той простой причине, что у него вообще не было конкурентов в той нише, которую он занял - там можно было реализовывать всякое непродуманное говно - и оно допускалось, потому что ничего альтернативного не было вообще. Сейчас другая обстановочка.

Давайте же попробуем вывести формулу мало-мальски показательного рейтинга. Самое простое, что можно сделать, это определить среднее арифметическое:

R = (P-N)/Gt

Где:

R - Rating, рейтинг

P - Positives, количество позитивных оценок

N - Negatives, количество негативных оценок

Gt - GradesTotal, общее количество оценок

Вроде бы отличный вариант получается. Значение R всегда будет лежать в пределах от -1 до 1. Умножить на 100% или лучше на 1000 промилле и вот он - прекрасный рейтинг, ограниченный сверху и снизу.

Например: юзер1 за посты имеет 1000 плюсов и 750 минусов. Тогда его рейтинг по постам:

P = 1000 - столько плюсов получил

N = 750 - столько минусов получил

Gt = 1750 - столько всего оценок

R = (P-N)/Gt = (1000-750)/1750 = 250/1750 = 0.143

Домножаем на 1000 и получаем красивое значение в 143 пункта рейтинга.

Но и у такого подхода к учёту рейтинга есть свои проблемы в виде слабой репрезентативности на малых количествах оценок, и накапливаемой "устойчивости".

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

А вот накапливаемая "устойчивость" - куда хуже и деструктивнее, и является изъяном самой такой системы рейтинга. Впрочем, она существует и у той системы, что реализована сейчас.

О чём вообще речь идёт, на примере:

Юзер1 имеет 10 плюсов и 5 минусов, юзер2 имеет 1000 плюсов и 500 минусов. Их рейтинг по системе со средним арифметическим будет одинаковым: 333.

Но вот и юзеру1 ставят минус, и юзеру2 ставят минус. Тогда рейтинг юзера1 становится (10-6)/16*1000 ~ 250 (-83), а у юзера2 получается: (1000-501)/1501*1000 ~ 332 (-1). Разница по воздействию весьма разительная: юзер1 за 1 поставленный ему минус потерял целых 83 пункта рейтинга, а юзер2 всего 1 пункт.

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

Как это исправляется? Довольно просто: берутся не все оценки пользователя, а какое-то количество последних, например 1000, то есть сколько бы юзер ни набрал оценок, считается только на основе последних 1000. В этом случае, все юзеры, имеющие больше 1000-и оценок, оказываются в равных условиях относительно колебания своего рейтинга.

Разумеется, чтобы не хранить гору больших значений, можно воспользоваться динамическим вычислением. На примере кода C#:

float _rating;

int _total;

int CalcRating(int grade)
{
     _total ++;

     if(_total > 1000)
          _total = 1000;

     float neoRating = (grade - _rating)/_total + _rating;

     _rating = neoRating;

     return (int)Math.Round(neoRating*1000);
}

И да, я знаю, что это отвратительно неоптимизированный хардкод. Но тут и без того хрен кто что-то понимает, а если я накручу сюда ещё делегат с переключением, чтобы не мудохать постоянную проверку, да горсточку статических переменных, то читаемость этого добра упадёт до уровня "лишь самый посвящённый отдуплит, как это работает".

И да, такой способ вычисления становится немного неточным, после достижения потолка для значения _total, но эта неточность является несущественной, да к тому же общей для всех вычислений рейтинга.

В общем, там во главе угла только формула, которая позволяет получить среднее арифметическое от _total количества оценок. Из хранимых данных только рейтинг пользователя в сыром виде и количество оценок.

Как работает: вот у нас есть рейтинг пользователя 250 (_rating == 0.250), а оценок у него уже 25 (_total == 25). Ему ставят плюс (grade == 1). Тогда:

_total ++; // 25+1=26

neoRating = (1 - 0.250)/26 + 0.250

// neoRating == 0,27884615384615384615384615384615

В качестве результата, если я ничего не напутал (а я это могу), выдаст новый рейтинг, равный 279

Всё веселье в том, что как только количество оценок пользователя становится больше 1000, то оценки начинают влиять на его рейтинг всегда с одинаковой силой, не убывающей со временем.

И чем же хорош рейтинг, рассчитанный таким способом?

1) Не уходит в заоблачные значения, поскольку ограничен диапазоном от -1000 до +1000 (ну или сколько угодно, диапазон можно сделать буквально любым)

2) Не увеличивает собственную "устойчивость" со временем. Да, рейтинг бывалых юзеров будет меняться слабее, чем у новорегов, но не слабее определённого уровня, когда количество полученных оценок превысит 1000 (как и с диапазоном, тут можно сделать другое число). По сути начав пороть неодобряемую херь, юзер с 5-летним стажем сольёт свой рейтинг так же ловко и быстро как юзер-первогодка, потому что миллионы оценок, набранных за долгий строк пребывания на ресурсе, не делают рейтинг старожила сверхустойчивым.

3) Намного более показателен, как параметр, отражающий общую популярность контента, публикуемого пользователем (особенно если предварительно разделён на рейтинг от постов и рейтинг от комментариев). Рейтинг по постам в 750, высчитанный по данной системе, буквально значит, что юзер получает в среднем 4 плюса на 1 минус за свои посты, то есть весьма одобряем сообществом.

4) Позволяет более гибко настраивать систему автоматического бана пользователей. Например, можно настроить бан за рейтинг < -500, то есть когда в среднем на один плюс юзер получает 3 минуса на протяжении определённого времени.

Довольно очевидная проблема заключается в том, что рейтинг, рассчитываемый таким способом, первое время очень нерепрезентативен. Например, если юзер имеет всего 3 оценки: 1 плюс и 2 минуса, то его рейтинг будет -333, что вроде выглядит как жуткая жуть, однако на деле всего лишь результат огромной погрешности расчёта из-за недостаточно большого объёма данных. Это же в свою очередь производит и смежный эффект, в виде серьёзных скачков значения рейтинга на ранних этапах деятельности пользователя. Тот еже рейтинг в -333 за счёт 1-го плюса и 2-х минусов, станет 0 при получении 1-го плюса, то есть наберёт сразу 333 пункта.

Эта проблема может быть решена, в частности, методом "забивки нулями". То есть когда рейтинг новорега изначально ставится в 0, а значение количества полученных оценок устанавливается каким-то существенным значением, например, 100. Как будто он получил сотню нулевых оценок.

Первые оценки новорега в таком случае повлияют на его рейтинг не сильно. На примере: _rating == 0, _total == 100, grade == 1 (плюсик поставили), тогда:

_total ++; // 100+1=101

neoRating = (1 - 0)/101 + 0

// neoRating == 0,00990099009900990099009900990099

И рейтинг новорега поле первого плюса сменится с 0 на 10. В случае, если бы изначально _total == 0, рейтинг с 0, сменился бы на 1000 (максимально возможный) сразу после первого плюса. Легко проверить, заменив в формуле значение 101 на 1.

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