Project Tomodachi » 讨论
Tomodachi #1 - Mio 3
#1 - 2011-2-24 11:59
aligo
最近看到bangumi多了用户同步率计算,我又手痒了
第一步还是先根据评分计算条目同步率,然后再是根据同步的条目计算用户的同步率
继续优化上次的条目相似度算法,因为性能原因暂时放弃上次的预测打分功能
区别在于根据幂律分布,把主流条目(打分人数多)与非主流条目(打分人数少)的相似度进行调整(每pow=log(条目打分数比,4),相似度*0.618pow)
灵感来自我发现bangumi现在的用户同步率,如果随便找一个收藏条目多的用户,你得到同步率肯定和他很高,这肯定有问题
另外似乎得找一个合适的方式,把用户收藏如看过/在看/抛弃的数据,也转化为隐式打分进行评估?
Bangumi的rate表
生成日期:2011 年 02 月 24 日 00:41
raw:382,472条,18.0 MiB
打分数据:242,213条,6.6 MiB
有效项目:8,849条
测试条件:
CentOS 32bit
Xeon 3.06GHz * 1
512MB RAM
MySQL 5.5.8
PHP 5.3.5,使用PDO_SQL方式连接,使用foreach遍历数据
结果
时间:(8849/8849)Subject11329 done!......376.82082986832s
容量:4.1 MiB 304,506条
第一步还是先根据评分计算条目同步率,然后再是根据同步的条目计算用户的同步率
继续优化上次的条目相似度算法,因为性能原因暂时放弃上次的预测打分功能
区别在于根据幂律分布,把主流条目(打分人数多)与非主流条目(打分人数少)的相似度进行调整(每pow=log(条目打分数比,4),相似度*0.618pow)
灵感来自我发现bangumi现在的用户同步率,如果随便找一个收藏条目多的用户,你得到同步率肯定和他很高,这肯定有问题
另外似乎得找一个合适的方式,把用户收藏如看过/在看/抛弃的数据,也转化为隐式打分进行评估?
Bangumi的rate表
生成日期:2011 年 02 月 24 日 00:41
raw:382,472条,18.0 MiB
打分数据:242,213条,6.6 MiB
有效项目:8,849条
测试条件:
CentOS 32bit
Xeon 3.06GHz * 1
512MB RAM
MySQL 5.5.8
PHP 5.3.5,使用PDO_SQL方式连接,使用foreach遍历数据
结果
时间:(8849/8849)Subject11329 done!......376.82082986832s
容量:4.1 MiB 304,506条
#2 - 2011-2-24 20:03
我不存在
#3 - 2011-2-25 19:06
aligo
#4 - 2011-2-25 21:15
aligo
#5 - 2011-2-26 11:50
aligo