We have built a minisite on douban for recsys. Please visit and follow: http://site.douban.com/106414/
最近group里面讨论到了音乐推荐的新颖性，很有意思，这里把一些精华的言论摘录出来 Wu Di 说到热门推荐vs.长尾挖掘的事，我想到了一个实验 还是Oscar同学的那篇博士论文，“Music Recommendation and Discovery in the Long Tail”，对应的答辩PPT里面有张图，是一个实验的数据表格。实验是拿Last.fm的CF引擎跑的。 实验有288个参与者，实验素材是一堆30秒的音乐片段，经过CF处理后，推荐给测试者听，要求他们用5分制打分，同时会问他们一个问题，“你认得出这首歌 / 这首歌的演唱者吗？” 实验结果： 1. 当测试者既认得出这首歌，也听得出这首歌的演唱者时，测试者的平均给分是4.64（发生比率15.5%，下同） 2. 当测试者只听得出演唱者，而认不出这首歌的时候，测试者的平均给分是3.88（12.81%） 3. 当测试者即听不出演唱者，也认不出这首歌的时候，平均给分是3.03（71.69%） 实验得出的一个直观简论是，当推荐结果变得陌生时，用户变得不爽了… Song Hui 关于这个实验结果我觉得是不是换个理解方式？ Oscar的结果1，2，3：当推荐结果陌生时，用户对推荐结果的评价会降低（而非用户变得不爽） 举个例子来说，如果豆瓣电台推荐给我的都是孙燕姿的歌，我都很熟悉，而且我会给很高的评分（正常情况下我是不会给那些我熟悉的歌打分的，不过在这个实验里用户是被要求给所有推荐结果打分）， 但我对推荐系统确很不满意，推荐结果对我来说不够新颖，我更喜欢系统给我推荐一些我不熟悉的东西（如果是我喜欢的就更好了）， 虽然对于这些不熟悉的推荐结果我给的分相比那些熟悉的可能会低，但这并不代表我的用户体验不好。 因此，当推荐结果变得陌生，用户给的评分较低 =？ 用户不爽 Wen GuoZhu 这个实验的一个致命问题是没有考虑时间性，所以它结论的适用场景是实验室内的那一小段时间，而实际推荐系统考虑的是一个长期效果 我的意思是说，这个实验只是实验室里的情况，并不能代表实际的情况。因为实验室里的测试只是一两个小时的听歌喜好，当然是听到熟悉的就会打高分。但实际当中，用户是长年累月在听歌，你要是老给TA播熟悉的，时间长了TA就不乐意了。所以，这个实验的结论并不适用于实际情况。 如果还有进一步的讨论，我会更新这个帖子。
昨天邀请到了IBM CRL的3位研究人员给resys group的成员们介绍了他们在推荐系统方面的一些研究成果，首先要感谢Intel社区给我们提供了场地。 因为我最近半年在IBM CRL实习，和3为researcher在一个组，所以对他们的工作比较了解，所以在这里总结一下我的一些看法。 第一个演讲的是赵石顽，他的演讲内容是 Pharos: Soical map based visual recommender for content-centric website。Pharos是他们去年做的一个项目，这个项目的主要内容是基于挖掘IBM Blog中的用户数据，给用户提供一个全新的浏览web2.0的方式。我们知道，很多web2.0网站都有他们独特的UI，比如delicous, digg，他们的UI设计都比较独到。不过他们的设计大都还是基于传统的网页设计，就是首先有分类，然后分类里面有分类，这样的层次结构。这种结构的缺点就是不利于用户通过浏览的方式来找到自己感兴趣的东西。所以Pharos是希望提供一种新的浏览方式。他的主要手段，是通过数据挖掘，将用户，博主，关键字以tag cloud的形式展现出来。当用户进入系统的时候，在首页上就可以看到很多聚类，每个聚类里用不同的颜色来区分了这个聚类的关键词，和主要用户。tag cloud的优点是可以在有限的空间里展示非常大量的信息。 Pharos里面用到的聚类方法主要是基于LDA的，他们用LDA将不同种类的entity（user, keyword, article)来聚类，而每个类里面通过pagerank来确定entity的权重。 第二个演讲的是袁泉，他主要是介绍了graph model。因为我在IBM的前一段时间就是研究Graph Model融合temporal信息的，所以对他的工作比较了解。Graph Model是一个历史非常悠久的模型，他的特点是万金油，什么东西都可以往上面放。不过他的缺点是很难确定不同种类数据的权重，以及边的转移概率。graph上目前比较常用的都是基于随机游走的ranking算法，这类算法速度非常快。但是，有很多精度高的代数算法，却速度相对比较慢，比如对图的Laplacian矩阵的分析，就需要借助SVD等等手段，当图的规模大了之后，效率还是有一定的问题。 另外，构图也是一个见仁见智的问题，一般来说构图比较简单，只需要将有关系的东西连在一起就行了，不过边的权重很难确定。另外图的算法大都是非learning的算法，我个人一直希望提出一种有目标函数的情况下，自己学习边的权重的算法。 最后一个演讲的是张夏天，他主要介绍了对tag推荐的研究。tag最近是推荐研究的一个热门。他有两个问题，一个是推荐tag，一个是利用tag改善对item的推荐。不过我对这个方面研究的不是很多。在netflix prize中，我们用过一些类似tag的文本信息，比如电影的演员，导演作为tag。当时起的作用不是很大，这也许和电影的diversity不够大有关系。不过tag起作用的，个人感觉还是在top-N推荐上，它对rating prediction的影响有限。 tag分布随时间的演化也许是一个值得研究的方面，夏天介绍了前人的tag对后人的影响，可以发现后人打tag非常依赖于前人的tag，所以tag的冷启动也许是个问题（似乎这个只能通过自然语言理解，来提供了） 总之，非常感激三位的精彩演讲，这一次的演讲比较学术一点，公式稍微多了一点，不过大家如果仔细消化，还是可以获得不少的收获。
自上次关于long tail的讨论后，resys group的又一个精华帖诞生了，就是关于netflix模式的讨论。 Jingjing Deng (Bruce) 近几年来，但凡美国的一些好的business model,到了国内略加修改加以运用，马上获得成功。远的如携程，如家，近的如至尊租车，开心网，均取得的高速发展并且盈利且（或）上市的目标。这次在美国发现了ZIP CAR的租车模式，正感慨呢，发现国内已经开始运用了。但是为什么Netflix，一个最简单的在线租碟模式，却不能在国内出现呢？ 理由一：中国的盗版太严重。的确是，5块钱一张碟，在当前的物价下面，只是一碗小碗不加肉的兰州拉面的价格，拥有成本太低。很多人觉得买了收藏也不错，为啥要费力气去租呢。 但是我们也可以看到这样一个细分市场： 卖盗版碟的最求的是利润，必然是卖最流行的碟最赚钱。但是由于长尾效应，很多人其实有一些“特别的”喜好，这些人的需求如果能够满足，那么这个潜在的市场会很大。 理由二：邮寄成本太贵，而且国人素质太差，容易损坏盘或者不还。 的确是这样。但是Netflix在美国的环境下都能收支平衡，为啥中国还嫌弃贵呢。而且现在有信用卡了，租车的公司都不怕车被弄坏，租碟的人为啥怕碟弄坏呢。。。 理由三：热门正版碟太贵。 的确是这样。但是Netflix最赚钱的是老电影，非冷门电影的小众群体。中国也应该有这样的群体。 如果这样的话，Netflix的business model为啥在中国还没有出现呢？（豆瓣算嘛） 谷文栋 这个问题我的理解有两点： 1、需求一定是有的。起码对我来说，不说频率，但总是会看一些小众电影或者之前的老电影的，这些东西淘碟都是很困难的。 2、在国内，BT目前已经满足了我上面的这个需求。 如果国内搞一个Netflix，我自己会不会用？暂时的结论会倾向于不用。必须能有另外的点能吸引我。 Jingjing Deng BT能满足部分人需求。能满足所有人需求不？答案是否定的。那么这部人的需求要么是没有得到解决，要么是通过其他渠道解决了。这个“其他”渠道是什么呢？ Eric.M 我第一次听到netflix，让我想到小时候，家旁边有租录像或是vcd的店，大概2块钱看一部的样子，我有个疑问，为什么现在这样的店没有了？ Sucirst Yie 并不只是小时候有，我印象很清楚的是2003年的时候，上海还几乎每一个小区附近都能找到一家类似的店，卖碟为主，兼有租赁，一张碟一般1块钱一天； 02年的时候宽带还没普及，那时候非常多的家庭还在用169之类的拨号上网，那个时候租片子买盗版碟非常盛行，我曾经跟我家附近一个店主聊过，我也看着这家店从兴盛到消亡；做租赁的时候这种小店是只能做热片新片的，通常周期只是一个月到2个月左右，所以赚的其实是个辛苦钱，要所有租的人能及时还回来，他才能保证这一个月这部片子能多租出去；后来宽带普及了，应该在03年的时候，至少我的感觉我身边已经没有谁家还没有宽带（至少也是512K吧），这之后买碟（盗版碟）的主力军就明显发生了变化，到今天来说的话，恐怕买碟的以农民工和外来务工者为主了，买盗版碟本身就是对成本敏感，既然现在网络下载能更低成本的获得，那谁还去淘盗版碟呢~~ 网络获得的途径太多了，轻易没法把路统统堵死的 Gray Wang 我们家门口的超市到现在还有呢，2-3块一天。我也曾经想过能不能把这些店铺连锁起来，后来一想，太不靠谱，难度不亚于农村合作社。 Link 我觉得归根结底还是需求的问题，目前的情况是： 1. 有需求，很长尾很小众； 2. 用户的主要需求是发现这些影片，而不是租碟片或付费下载； 3. 盗版已经可以满足； 结论： – 满足这种小众需求需要靠社区，如豆瓣，如“纪录片之家”，聚合这批志趣相投的人是关键； – 豆瓣可以做这块，看看能不能谈下来一些小众出版物，在推荐的时候提供购买链接 谷文栋 Netflix 在美国能做起来，我觉得可能有几点： 1. 美国人的生活还是更休闲一些，需求比国内大。 2. [...]
beyond search忙活了好几个月的东西，希望大家关注。 《Resys China》，是依托于 Resys Group 并专注于推荐系统领域的一份电子杂志。 下面是创刊号的内容目录。 1. 业界新闻 2. 学术动态 * Workshop on Social Recommender Systems * Collaborative Filtering Over Time 3. 精品推荐 * YouTube’s Quest to Suggest More * Recommendation Systems: Increasing Profit by Long Tail * 推荐系统五大问题 4. 系列连载 * Greg Linden，Early Amazon：The First Week 5. 精彩应用 * 开源推荐框架 DUINE 概览 [...]
I have collected more than 3 million tweets about technology from twitter. I use these data to build a web app call geeksensor to find fans and experts of the keywords you provide. For example, following is fans and experts of recommender system in twitter: http://www.geeksensor.com/users.php?q=resys+recsys+recommender
最近在Resys Group上关于推荐系统和长尾的讨论让我很受启发，现转载如下： xlvector: Subject: 大家觉得推荐系统和长尾的关系是什么 有人说，推荐长尾可以增加销售额，把很多本来卖不出去的东西卖出去了 有人说，推荐长尾会引入很多误差 大家怎么看这个问题 王立才: 先看看是否符合长尾理论。。 如果符合的话，我觉得长尾是有意义的，因为世界是丰富多彩的，人和物之间的关联也不可能停留于局部。 Loeb: 就銷售而言，庫存壓力可能可以靠這解決，但是商品天生是不該被庫存，這是個矛盾 長尾是時間函數，但是除此外因子太多不可預測，例如某過氣歌手在某些狀態下 又突然紅了 推薦應該是，處理這些不可控＂某些狀態＂，長尾之於銷售，比較像是沒辦法中想辧法 Gray Wang: 有一个问题是，从理论上来说，长尾越长越好，但是实际上大部分零售或者在线销售者，希望的是总量，也就是长尾和大头覆盖下的阴影。并不一定长尾超过大头就是好的。 “推荐长尾可以增加销售额，把很多本来卖不出去的东西卖出去了”，如果从销售长尾的成本大于大于大头，为什么要销售呢？我想这种只有在充分竞争的情况下才有可能发生。 kuber: “任何革新都在于找到一个可以解释变化中的世界的新的参照标准”。长尾理论是基于生产能力的大大力高，产品极度丰富，同时顾客的要求也越来越个性化。因 此从销售商的角度来说，有时仅仅卖那20%的商品已经不能满足增长的需要，必须要向那80%的产品要利润。同时顾客也不满足于20%的产品，如果你不 卖，顾客有可能去人家那买了。 所以1。不是家家都一定要去做长尾的。2。长尾不一定意味着塞满库存，比如说zara。 安德森提出的办法是，提供尽可能多的产品（每样件数未必多，还是如zara）和让用户很容易的找到它。 要让客户从无尽的产品中找到自己要的，首先当然是搜索。但是个性化推荐绝对是不可忽略的。如果大家有陪女朋友/老婆逛街的话，一定能体会到，一个好的销 售员恰到好处的推荐肯定会大大提高销售机会，如果我们不讨论理性消费还是冲动消费的话，呵呵。我老婆就常常中招。我觉得推荐应该就是一个好的销售员。 除了cross saling 外，推荐应该还有一个功能，就是个性化，找到顾客的小众需求。 xlvector: 很受启发，我最近在做一个实验，这个数据集上，用户的行为过于集中在头部，可能是因为产生这个数据集的系统没有能很好的让用户找到长尾，所以在这个数据 集上，popular推荐的精度反而是最好的。 所以我就在想，这也算是一个盲目追求精度不利于设计好的个性化推荐的反例。个性化推荐还是应该focus在长尾上吧。 比如如果大家拿很多门户网站的日志数据，以追求精度来设计推荐系统，那就只推荐首页，肯定精度最高，但这不符合个性化推荐的本质，是吧？ Guozhu.Wen 的确，在item的头部有足够的用户行为数据可以做出精确的推荐来，长尾部分因为缺乏足够的数据支持往往很难做好。但如果不解决这个问题，这个情况会愈演愈烈，越来越难以解决。解决方案除了算法，也可以考虑从产品层面去解决。 feng ya dong: 如果仅仅集中在头部 推荐就失去了他的意义 比如在sns上 给一个用户推荐一个用户 ，除了满足用户的口味之外，另外一个目的也是想让非活跃的用户活跃起来，促进用户圈子的交融 tinyfool: 从产品角度，我经常想，没有靠谱推荐（尤其是推荐有反作用的时候），产品上应该考虑让推荐消失，这样其实可能会更好。 Google曾试验过一个功能：如果Google发现用户每次搜索后都不会点击顶端的广告的话，就会把这些广告移到右边（搜索结果显示广告的传统位置）去。 http://tiny4.org/tinygoogle/2006/09/google.html 最后这个方法采用了与否我不知道，不过这个思路，我觉得是值得借鉴的。
以前对context recommendation的了解仅仅限于时间推荐，因为时间是一种重要的上下文信息。后来在IBM CRL的实习中，我们对很多实际系统中的推荐算法效果进行了研究，发现推荐精度和不同网站的设计也是很有关系的。 在Resys的讨论中，我提到了Web design对推荐的影响。其实web design也是一种上下文信息，他能够反应出一个用户在web graph上的位置。那么推荐结果的好坏在很大程度上会受这个上下文信息的影响。 举一个例子，比如我到了一个网页，这个网页上有很大链接指向别的网页，如果你推荐这些有链接指向的网页，显然作为预测来说，你的精度会很高，因为你不推荐，用户也可能会点。我们现在的用户评测，过分强调预测了，好像是个预言家。但有些预言是很好做的，比如我预测太阳会从东边升起来。很多推荐结果就是这种无用但正确的预测。 所以，在互联网上，了解一个用户所处的网络环境，用户在Web graph 上的位置，对于找到用户真正需要的东西，还是很有意义的。
感谢fengyadong和openlab的开发者提供了他们的数据给我们做推荐系统的研究。数据可以从下面的链接下载： 下载1 下载2 OpenLab是一个类似传统论坛的网站，不过他加入了一些社会化因素。下面是fengyadong给出的ReadMe。 下面是需要强调的几个原则： 本次提供的数据集来自Openlab多年的社区沉淀,其中包括62190名用户产生的5161篇blog文章，25389篇文章评论，1268871条聊天室聊天记录，1933459条论坛帖子，260723条论坛主题及其他一些周边数据，基于保护用户隐藏的考虑，本次提供的数据集对所有的用户id，条目Id进行了加密混淆，混淆后的数据依然保持原有的关联性、完整性.但无法同openlab任何具体的用户相对应。作为一款开源的社区软件，Openlab希望数据使用者本着Open、Share的精神在http://groups.google.com/group/resys/ 分享您对该数据集的研究过程。使用本数据前，请您确认自己已经认真阅读并承诺遵守以下协议： 1、数据集的使用不能带有任何商业及盈利性目的，在此前提下对数据集进行的研究、使用无须得到openlab的许可。 2、公开发表的论文及其他资料如果涉及该数据集、务必注明来源为www.openlab.net.cn，并在 http://groups.google.com/group/resys/以恰当的方式告知其他关注者。 3、在公开场合公布的与本数据集有关的算法与模型，在开源的前提下，Openlab有权将其工程化，数据使用者应本着Open、Share的精神给予相关的技术支持。 4、禁止对混淆后的数据进行任何还原及还原的尝试，禁止就此问题发表任何公开性的讨论。 我个人对这个数据集的看法是，他提供了用户的不同behavior数据，从而有利于我们研究用户不同行为之间的关系以及一种行为对另一种行为的影响。 这个数据集目前还没有提供日志数据，但OpenLab正在致力于公布这方面的数据，一旦数据公布，我们会尽快通知大家。
2009年12月19号，我们在豆瓣的新办公室举办了第三次resys的线下聚会。这次聚会由豆瓣主办，在这里我和谷文栋首先要感谢一下豆瓣，他们提供了很好的环境，还有好多吃的以及纪念品。 这次活动主要有三个话题，一个是豆瓣的王守崑对豆瓣中推荐系统的总结，一个是百度的张栋博士，介绍分布式和并行算法在互联网中的应用，一个是孙超的推荐也是一种产品。下面我详细说一下我对他们报告的体会。 1. 豆瓣在推荐系统领域的实践和思考 王守崑 这个报告很不错，王守崑对推荐系统的问题做了很好的总结，他根据稀疏性，多样性，时效性，反馈将推荐问题进行分类。这个分类我觉得还是很科学的，在目前的学术研究中，系统研究这几个问题的我还没有见到，在这里我也谈谈我的看法。 一般来说所有的用户喜好数据都是稀疏的，只是程度不同而已，在数据方面，我倒是觉得还有一个指标也很重要，就是item数比上用户数。在电影推荐中，一般用户数都是远远大于item数的，而在文章推荐中，文章数却是远远大于用户数。当然我这里都是说的一个成熟的网站，如果是一个刚出来的网站，用户数显然是很少的。我的研究发现，同一个推荐算法在不同的item/user比下效果会相差很大，所以我觉得item/user是一个对稀疏性和多样性描述的不错的指标。item/user 小的系统一般比较稠密，多样性比较差。item/user大的系统一般比较稀疏，多样性比较好。 时效性的问题其实在于系统的速度和服务器的能力，这个问题基本是靠钱解决的，服务器越多应该解决的越好。最近这几年已经有关于实时推荐的研究，我相信如果google来做这个问题，可能会解决的比较好。 反馈是个重要问题，我和王守崑一样，都是做自动控制出身的，控制的特点在于不需要精确的控制器，好的反馈系统可以弥补控制器的缺陷。反馈依靠的主要是日志，但是如何通过日志来调节推荐系统的参数，这个因为我没有做过实际系统，所以不好说，但是结合后面孙超的报告，我倒是有一个想法。Netflix Prize有3大贡献：Funk SVD, RBM, Ensemble。其中的Ensemble的意思是说，好的推荐系统需要融合各种不同的算法。一个推荐系统可能有很多参数，如果这些参数都要靠日志来调节，显然是不现实的。但是我们可以设计几套典型的参数，从而做出几个不同的推荐器，而调的参数仅仅是这些推荐器的权重，这样反馈可能会比较迅速的起到作用。 2. 推荐也是一种产品 孙超 说实话，这个topic也是我去了IBM后的一个研究方向，这个topic有一个英文词: recommend recommenders，就是推荐推荐器。其实这个idea的起点也是来自于Netlfix Prize的模型融合，但是Netflix Prize的模型融合算法还不是完全个性化的，因为在那个问题中，完全个性化的推荐器会产生过拟合的问题。推荐器其实和特征是联系起来的，比如对一个用户，他比较喜欢和他同年的人的推荐，这就算一个推荐器，或者他比较喜欢和他一个学校毕业的人的推荐，这也是一个推荐器。所以我们认为，recommend recommender的问题其实是多特征推荐的问题。 当然也有推荐算法的不同，比如KNN，SVD，但个人认为，这些算法的差别其实很小，如果你用同样的特征的话，用不同的算法做推荐，推荐Top-N，可能推荐列表相差不大。真正影响推荐列表的可能还是特征的不同。比如内容推荐，还是collaborative filtering。 目前我们正在研究如果给一个多特征的系统建模，已经如何在模型上做推荐，等有相关结果时，我会和大家share我们的研究成果。 3. 大规模机器学习算法在互联网上的应用 首先惊讶的是张栋博士原来在自动化所呆过，所以首先在这里说一声，师兄好。嘿嘿。张栋以前在google呆过一段时间，众所周知，google的强项就在于规模。所以我们戏称，评价一个工程师的指标不应该是懂多少算法，而是处理过多大的数据。同样两个工程师，都用过LDA，显示不出水平，显出水平的是在什么规模的数据上用过LDA。数据超过一定的规模必然就要分布式，并行化。我目前的水平基本在1000W网页这个水平上，1亿还达不到，主要是没见过这么大的数据，所以就没有经验。 张栋博士讲的所有东西，相信大家最终记住的可能就是在machine learning中，MPI的模型好于Map Reduce。不过我也赞同SiXianCe说的，如果同样两个大牛，不用现有的MPI和Map Reduce的实现，自己重新实现一下，最终谁牛，可能还真说不准。 此外，张栋博士总结了machine-learning发展的轨迹，这也是一个高屋建瓴的总结，相信对大家学习machine learning也会有不少帮助。不过我感觉机器学习这几年的发展是越来越实用了，早期的神经网络有点牵强附会，非得把所有问题往神经上扯。其实如果从数学的角度看，不同的算法基本可以归为矩阵和概率，当然我个人私下里怀疑矩阵和概率可能在数学上最终也是等价的。我比较喜欢爱因斯坦的简单理论，不同的算法只是在解决不同问题时强调了不同的方面，他们本质上可能是一样的东西。就像广义相对论方程那样，形式很简单，但不同的物理学家却可以得到不同的数学解，而每种数学解都有一定的适用范围。上次参加Netflix Prize，算是把流行的算法都在那个问题的框架里都实现了一下，最后却发现，把所有的算法合在一起才是个最好的算法，看来还是那句话：存在即合理。嘿嘿。 就说这么多吧，有关这次活动的详细信息可以在 http://www.douban.com/event/11356069/ 看到，PPT和照片都有。 最后要提一下，这次活动有很多人特地从外地赶来，特别是来自台湾的Loeb，不容易。Loeb在文栋的陪同下看了天安门，吃了北京烤鸭，嘿嘿。 最后再次感谢豆瓣主办此次活动。给大家提供了一个交流的平台。
