基于Google Reader发展起来的个性化推荐系统之三大问题

简介:

郑昀@玩聚SR 20091003

    中科院的xlvector(即项亮,他所在的团队The Ensemble在7月份获得Netflix大奖赛公开测试排名第一,但在9月22日Netflix宣布BPC获胜,原因据说只是因为项亮他们提交结果晚了20分钟)最近发布了一个小工具GRSuggest,有点像之前KuberFeedzShare所做过的“个性化阅读”,都属于“基于某个Google Reader用户的Shared Items中的文章,为该用户推荐他可能感兴趣的其他文章”,基本都是基于 User-based Collaborative Filtering 算法原理。

   项亮在《关于GRSuggest的一些思考》中说:“去重的问题,这个问题在文章推荐中非常常见,很多文章都被转载N次了,经常发现一个几年前的老贴又被转载,其实我的推荐系统本身也是转载”。

   这个延伸出来的是三个常见问题,确实不好解决。

一、火星人现象

   我前一段发了一个tweet:“不知道 Digg 能否解决火星帖频频被推荐的问题,这应该是所有digg类社区共同面临的问题:不管一个帖子或段子有多近期老多频繁被digg,隔一段时间总会有一个人当成宝贝发出来并被一大批火星人推荐。”

   有人认为,火星帖如果是优秀的,当然有权利被翻出来啊。但请注意,在某一个单一社区中,可以假设用户群有相似的知识结构,那么以往的老贴子可以被翻出来,是可以的,天涯社区就屡屡这么搞,但在一个推荐系统中,如果还是不顾用户的知识结构,屡屡出现很多老段子,那就真的是在驱赶用户了。
   火星人现象的关键是,以前大家也讨论过很多遍的:“推荐系统无法获知用户以前的知识结构”的问题。也就是说,一个单一的、新出现的个性化推荐系统,由于不知道用户的知识结构(即以往的阅读经历、经验),推荐的很多Item一定是用户已经熟知和阅读过的,这对于应用创始人和用户来说都是一个很不好的体验,但又完全无法规避。我们举一个很简单的例子,如果你在豆瓣中厮混时间不长的话,总会被豆瓣猜按照你的寥寥无几的动作推荐很多你看过、听过、读过的东西,而且是屡屡如此,你被逼的不得不一个一个点击掉,来让豆瓣了解你许久以来的经历。

   从Google Reader Shared Items衍生出来的推荐系统就存在这个问题,Shared Items并不能反映用户的阅读经历,因为你在GReader里看了一篇文章,不代表你会Shared它,也不一定会Like它。这是问题一:从根子上就无法完整反映用户的阅读经历。

   经过对Shared Items中文用户统计,相当一部分用户(我估计在50~60%)分享的文章所属之channels(即博客源)数量不会超过5个,10%的用户甚至只分享至多2个源的文章。多数中文用户分享的文章都出自“名人榜|LeaderBoard”所列出的这些站点。这是问题二:如此大量的阅读视野狭窄的用户,推荐系统能否发挥作用呢?

二、有时效性和无时效性

    以前刘未鹏针对玩聚SR曾经提过一个很好的建议:“应该将文章分为"有时效性(如新闻时政类)"和"无时效性"(如读书笔记、GTD方法等等),看上去这需要手工分配或者高级的自然语言处理,但我意识到一个很好的办法:一般人们是在greader里面共享时效性文章,在twitter上讨论时效性文章,但"无时效性",或者timeless的文章会收藏到delicious上面,因为greader/twitter代表分享讨论交流,而delicious则代表收藏以后翻查。”

    他观察到一个技巧:“无时效性的文章一般很久以后还会有人往delicious上面收藏,这是个极好的判断依据。而时效性强的文章就不会存在这个属性。”也就是说,你可以通过检查一个文章在delicious的被用户收藏的时间,从中发现哪些文章是有时效性的。

    项亮也提到:“究竟要不要把老帖子翻出来,这个首先要解决一个新闻和文章的区别,对于新闻,翻出来是没有意义的,但对于知识性的文章,还是可以翻出来的。”

    这就是基于Google Reader的推荐系统的另一个问题:要不要推荐时效性强的文章

    如果真的能分辨一篇文章的时效性,那么可以针对“火星人现象”加一个规则:推荐系统不推荐时效性强的文章,因为一是用户完全有可能通过各种渠道早已看到,比如论坛比如twitter比如IM,二是虽然用户不一定看过,但让使用推荐系统频度不高的用户总看过时的文章也会产生这个系统很烂的印象。毕竟,阅读和电影不一样,你可以推荐很老的电影,但不能推荐很老的新闻资讯。

    无时效性的文章还可以这么搞:刘未鹏认为可以“判断时效性是为了增加信噪比,将无时效性的文章单立一个tab来做榜单,可以使后来的用户持续访问到以往一段时间的精华文章,而不是大量的八卦或时政,timeless的精华文章列表的好处是一下能够建立新读者对玩聚SR的高质量的信任。”我后来虽然提供了存档入口,但并没有区分时效性。

三、惊喜很难吗?

    项亮认为:“推荐文章除了要和用户的兴趣相关,还要起到帮助用户拓展眼界的作用,这个方面的研究这几年已经有不少了,也就是找出所谓的能让用户惊喜的东西,但是这方面的算法的主要问题是无法评测,因为不知道什么东西是用户惊喜的。”

    是的,惊喜很难。

    何谓惊喜?就是在用户的知识结构之外,又是用户当下喜欢的条目(文章、电影、音乐、图片、视频)。所谓提及“当下”,是因为一个用户的兴趣点是动态的。

    stumbleupon为何总能给用户带来惊喜?

    stumbleupon的算法设计师Garrett Camp曾给出一张流程图,描述了当按下stumbel!按钮时,stumbleupon的后台流程:

stumbleupon的后台流程

    图中列出了三个因子:

    A、Your Topics,也就是你对网页的动作,比如like、dislike、quick stumbles(指当一个用户stumble!到一个页面时,没有对这个页面做任何投票行为,而直接再次点击stumble!按钮跳转到另一个页面的动作,他们将这个动作定义为:“soft not for me” or “down-vote”)。

    B、Socially Endorsed Pages,就是你的站内好友所like的那些条目。

    C、Peer Endorsed Pages,是系统计算出来的、跟你有相似投票习惯的人所like的条目。

    从中我们可以总结以下要点:

    1、一个能让用户有“惊喜”的推荐系统,必须捕捉足够多的用户行为细节。显然,基于Google Reader的第三方推荐系统,拿到的数据是严重不足的,你无法知道用户有意忽略了哪些文章,你很难拿到他的好友列表,Google不像FriendFeed那样提供Dislike/Hide的按钮;你只知道他何时Share或like了某篇文章从何处(值得注意的一个细节是,如果用户是自己订阅了煎蛋并推荐其中一篇文章,显然煎蛋对用户来说更加重要;相比而言,用户只是从其他人的Shared Items订阅中share了煎蛋的某篇文章,却不去订阅煎蛋,说明煎蛋对他来说可能还不算重要。这个细节有点像“quick stumbles”的思路)。

    2、一个能让用户有“惊喜”的推荐系统,必须拥有海量用户,处理海量数据。今年2月份,stumbleupon 即已突破七百万用户,每天估计处理1千万以上次投票行为,至少新增3万以上个新推荐条目。Google Reader中文用户还是太少,而且用户行为太集中,单凭Shared Items出来的新增文章数目太少。

    这两点都限制了第三方挖掘“惊喜”的力度。

    目前貌似只有twitter能毫无保留地提供各种用户行为细节以及海量数据。

郑昀@玩聚SR 北京报道

目录
相关文章
|
12月前
|
JSON 自然语言处理 Java
「微服务架构」Google和eBay在构建微服务生态系统方面的深刻教训
「微服务架构」Google和eBay在构建微服务生态系统方面的深刻教训
|
12月前
|
机器学习/深度学习 数据采集 自然语言处理
谷歌为1000+「长尾」语言创建机器翻译系统,Google翻译已支持部分小众语言
谷歌为1000+「长尾」语言创建机器翻译系统,Google翻译已支持部分小众语言
|
Web App开发 存储 监控
如何通过Google Chrome远程控制你的Windows 10系统
Google提供了一个免费而又强大的工具--Chrome远程桌面(Chrome Remote Desktop),来允许你连接并控制互联网上的Windows 10电脑系统(这同样适用于Windows 7和8)。根据本文介绍的步骤,你可以在家里或办公室的Windows 10系统上通过设置Chrome远程桌面,来借助互联网进行连接和控制了。
1994 1
如何通过Google Chrome远程控制你的Windows 10系统
|
知识图谱 ice
Google Earth Engine——美国国家环境预测中心(NCEP)的气候预测系统再分析(CFSR)是作为一个全球性的、高分辨率的、大气-海洋-陆地表面-海冰耦合系统设计和执行的数据集
Google Earth Engine——美国国家环境预测中心(NCEP)的气候预测系统再分析(CFSR)是作为一个全球性的、高分辨率的、大气-海洋-陆地表面-海冰耦合系统设计和执行的数据集
662 0
Google Earth Engine——美国国家环境预测中心(NCEP)的气候预测系统再分析(CFSR)是作为一个全球性的、高分辨率的、大气-海洋-陆地表面-海冰耦合系统设计和执行的数据集
Google Earth Engine——地球科学激光测高系统(GLAS)的空间激光雷达数据(2005年)和辅助地理空间数据融合的全球树木高度数据集
Google Earth Engine——地球科学激光测高系统(GLAS)的空间激光雷达数据(2005年)和辅助地理空间数据融合的全球树木高度数据集
192 0
Google Earth Engine——地球科学激光测高系统(GLAS)的空间激光雷达数据(2005年)和辅助地理空间数据融合的全球树木高度数据集
|
知识图谱
Google Earth Engine——陆地数据同化系统(LDAS)结合多种来源的观测数据(如降水表数据、卫星数据和雷达降水测量)
Google Earth Engine——陆地数据同化系统(LDAS)结合多种来源的观测数据(如降水表数据、卫星数据和雷达降水测量)
260 0
Google Earth Engine——陆地数据同化系统(LDAS)结合多种来源的观测数据(如降水表数据、卫星数据和雷达降水测量)
|
编解码
Google Earth Engine——加拿大数字高程模型(CDEM)是加拿大自然资源部(NRCan)测高系统的一部分,源于现有的加拿大数字高程数据(CDED)
Google Earth Engine——加拿大数字高程模型(CDEM)是加拿大自然资源部(NRCan)测高系统的一部分,源于现有的加拿大数字高程数据(CDED)
106 0
Google Earth Engine——加拿大数字高程模型(CDEM)是加拿大自然资源部(NRCan)测高系统的一部分,源于现有的加拿大数字高程数据(CDED)
|
知识图谱 流计算
Google Earth Engine ——全球陆地数据同化系统(GLDAS)摄取了卫星和地面观测数据产品大气分析场、降水场和辐射场数据集
Google Earth Engine ——全球陆地数据同化系统(GLDAS)摄取了卫星和地面观测数据产品大气分析场、降水场和辐射场数据集
1436 0
Google Earth Engine ——全球陆地数据同化系统(GLDAS)摄取了卫星和地面观测数据产品大气分析场、降水场和辐射场数据集
|
传感器 定位技术 ice
Google Earth Engine——该数据集是美国宇航局在研究环境中使用地球系统数据记录 (MEaSUREs) 计划的一部分,包括选定冰川出口区域的月平均速度图
Google Earth Engine——该数据集是美国宇航局在研究环境中使用地球系统数据记录 (MEaSUREs) 计划的一部分,包括选定冰川出口区域的月平均速度图
123 0
Google Earth Engine——该数据集是美国宇航局在研究环境中使用地球系统数据记录 (MEaSUREs) 计划的一部分,包括选定冰川出口区域的月平均速度图
|
定位技术
Google Earth Engine——全球土壤纹理数据集:250米处6个土壤深度(0、10、30、60、100和200厘米)的土壤纹理等级(美国农业部系统)。
Google Earth Engine——全球土壤纹理数据集:250米处6个土壤深度(0、10、30、60、100和200厘米)的土壤纹理等级(美国农业部系统)。
344 0
Google Earth Engine——全球土壤纹理数据集:250米处6个土壤深度(0、10、30、60、100和200厘米)的土壤纹理等级(美国农业部系统)。