协同过滤学习笔记: 稀疏?
上一篇里说到, 遇到稀疏的数据集的缺失数据的时候, 如何补充值的问题,
我采用的是补充一个评分均值以期减少这个引入的评分所产生的影响.
当然稀疏数据集同样面对的问题还有”cold start”, 系统越大, 这种效应越明显,
即一个新加入的项目不可避免的遇到评分人数相对的极低的现象,
按照上一篇我第一种考虑的方法, 这些新项目都会被不可避免的排除掉了.
当然这里又可以引出些讨论:
比如是不是根据评分的timestamp引入另外一个因子, 对近一段时间内的timestamp有更高的权重以期让那些低评分数的新项目出现呢?
不过我不想把这个系统改造得过于繁琐, 但是不可避免的, 如何去”揣测”和填充空缺的数据集是一个大问题.
Slope One算法可以简单的根据已有的用户的打分规则, 来推测当前用户”应该”或者”可能”的打分.
不过我把Slope One应用到我的”极其稀疏”的数据集中的后果就是, 使得结果更向那些孤立值倾斜.
我试图设立一些阈值来限制这些孤立”噪声”的出现, 但是效果很差.
我终于明白其实我这个根本不是什么稀疏不稀疏的问题 ,
是数据太少了, 还不足以通过协同过滤得到有效的结果.
我这几天也一直在考虑音乐站有关量化对于曲目, 专辑, 歌手的评分的问题,
毕竟一个量化的数值, 对于协同过滤以及其他任何算法来说, 都是一个必须的数字.
引入曲目后, 有些东西变得更微妙了,
比如A用户可能喜欢X专辑中的所有歌, 除了最后两首,
但是对喜欢的歌标记”喜欢”是非常烦琐和机械化的操作, “既然我默认喜欢, 为什么就不简单的放下去就行了呢?”
播放行为在最开始的时候, 应该是随机的, 除非用户从某个tag开始收听节目,
当然这要涉及到具体这个音乐站怎么被设计来生成播放清单了.
这样无数的行为都可能对评分产生微妙的影响,
让我的微小的脑子想得十分生涩的痛苦.
所以, 也许所谓的”烦琐”的标注”喜欢”的动作,
是必须的, 为了你听到更好的音乐推荐, 动动鼠标吧.
Comments (4) ·· Tags: Slope One·协同过滤·数据挖掘