推荐系统的应用案例剖析

吉雅·可汗,新三界与地狱魔族1.4,神池县

下面为您介绍推荐系统的应用案例剖析的文章:

在《程序员》杂志12期A中，我们介绍了推荐系统的数学原理和应用案例，本章将继续讲述推荐系统的应用案例。为了说明推荐系统的详细实施方案，本章首先详细介绍了一个音乐系统推荐的实施案例，之后为了让读者清晰大型推荐系统的原理，简要介绍一个淘宝周边兴趣点推荐的技术方案。

音乐推荐

音乐推荐系统是一个很好的说明说明推荐系统工作原理的例子。

1. 音乐推荐特点

• 物品空间大。物品数很多，物品空间很大，这主要是相对于书和电影而言。
• 消费每首歌的代价很小。对在线音乐来说，音乐都是免费的，不需要付费。
• 物品种类丰富。音乐种类丰富，有很多的流派。
  
• 听一首歌耗时很少。听一首音乐的时间成本很低，不太浪费用户的时间，而且用户大都把音乐作为背景声音，同时进行其他工作。
  
• 物品重用率很高。每首歌用户都会听很多遍，这和其他物品不同，比如用户不会反复看一个电影，不会反复买一本书。
  
• 用户充满激情。用户很有激情，一个用户会听很多首歌。
  
• 上下文相关。用户的口味很受当时上下文的影响，这里的上下文主要包括用户当时的心情（比如沮丧的时候喜欢听励志的歌曲）和所处情境（比如睡觉前喜欢听轻音乐）。
  
• 次序很重要。用户听音乐一般是按照一定的次序一首一首地听。
  
• 很多播放列表资源。很多用户都会创建很多个人播放列表。
  
• 不需要用户全神贯注。音乐不需要用户全神贯注地听，很多用户将音乐作为背景声音。
• 高度社会化。用户听音乐的行为具有很强的社会化特性，比如我们会和好友分享自己喜欢的音乐。

上面这些特点决定了音乐是一种非常适合用来推荐的物品。

2. 音乐推荐的实现方案

目前大部分做推荐的应用推荐逻辑应该都是多种逻辑并行。编辑推荐和用户推荐的歌曲一般会有专门的版块展示。

个性化推荐理论上来讲都是通过算法直接从音乐库里面由程序产出的。

• 冷启动（用户第一次使用）的时候基于热度的推荐会比较多，推荐流行热点音乐总是不会错的。
• 在用户使用一段时间，用户行为达到一定样本量以后，程序开始通过内容和社交关系逻辑产出内容，并且与热门内容按照一定比例推送给用户。
  
• 程序推荐和编辑人员人工推荐结合。
  
• 各个用户好友的歌单的交互。
  

用户所有的行为（包括下载/喜欢、评论、播放完成度、播放次数等）都会以不同的权重呈现在后续的推荐逻辑中。比如，一种权重的设置方法为：

下载+播放 > 喜欢+播放 > 搜索+播放 > 播放 > 下载 > 喜欢

至于准确不准确，合不合口味这个事情，与推荐算法的关系其实是不大的。做内容推荐的关键是内容质量是否过关。也就是音乐库里面对不同歌曲，不同歌手的音乐基因标记的是否正确，是否够专业，Jing.FM可能是近两年相对专业一些的个性化电台。

3. 关于实现方案的分析

先从相似度的问题说起。大多数用户一开始会先从自己熟悉的歌曲开始，然后一般都会给出非常相关的推荐，比如你听周杰伦的任何歌曲，他的其他热门歌曲肯定都会非常相关，比如周杰伦的《东风破》，周杰伦的《游园会》，周杰伦的《七里香》，也不失为一个好的推荐。但是你会发现全都是周杰伦，单调死了。全是周杰伦的理由很简单，因为很多用户都连着听下去呀，听完一首周杰伦到下一首周杰伦，听完这个专辑听下个专辑。如果你往后再翻翻，估计还能找到别歌手的歌曲，但是请记着：你的屏幕就这么大，坑就这么多，再好的推荐不能在靠前的位置被用户看到和消费到终归也还是没用。现在我们来尝试解决这个问题，我们先来做个简单的多样化过滤，我们限制来自同一个歌手的推荐数量，这样后面更多歌手的歌去被推上来了。

现在出现了一个新的问题，陈奕迅这时候发新专辑了，用户一下子蜂拥去听他的新专辑了，包括周杰伦的拥趸们也跑去观望了一下，这样的情况持续了一个多月，这下好了，用户看到的推荐里面现在几乎都能看到陈奕迅的这些歌了，尽管他这的歌跟周杰伦的歌原本不至于这么相关。而且由于这个效应，更多的人从推荐里面点进去了听陈奕迅的这些歌，造成了一个恶性循环，使得你的基于相似度的算法以为他们真的相关，这时候其他真正相关的优质推荐却被挤压到后面了。我们来尝试解决这个问题，最简单的莫过于是计算相似度的时候过滤掉“过于”热门的歌曲了，把这些歌曲推后吧，感觉问题应该也能解决了。

这种结合就是基于热度的推荐和用户行为推荐的结合。

现在一波未平一波又起，假设现在一个非常优秀的新歌手，唱的歌也好有周杰伦的早年的风采，反正就是非常相关，周杰伦的歌迷肯定会喜欢那种。这位新歌手刚出道，宣传力度不大，也只有少数几个地方能听到他的歌曲，只有被小数的几个周杰伦迷给发掘出来了，现在问题来了，我们该如何使得这个歌手被发掘出来呢？这个基本上与上一个问题相反，这是冷门的优秀推荐很难被发掘。这时候我们可以用归一化（Normalization）的小伎俩微调一下。值得一提的是，归一化更能给解决一下上一个提及的太过热门的问题。可以说怎样归一化才是各大厂家的杀手锏吧，虽然都可能大同小异，但是不同行业还是需要细分。

实际上，基于相似度的算法的确是非常自然的推荐算法，事实上当数据足够大、足够干净和精确的时候，基于相似度的算法是很难被打败的。但是设想如果是网易音乐发展初期，没有很多用户数据的情况下呢？又如果是网易音乐急速扩张时期，用户数据很多但是很稀疏的时候呢？又从用户角度切入，设想是一个刚加入的新用户，并没有其它用户数据来源来提供推荐的情况下呢？这些冷启动问题，又该如何解决呢？难道就应该放弃这些用户？可能我们可以做更多的小把戏来调整我们的算法，也可以去尝试一些其他算法，尝试去做一些混合推荐算法系统。但是由于产品的研发周期会变长，开发投入变大，系统变复杂，维护的消耗更大，然后更糟糕的是因为进展缓慢，用户一直看的就是不好的推荐，用户开始流失，数据更加稀疏，最后导致恶性循环。

这时，可以尝试通过别的途径来解决这些问题。

LBS推荐系统的设计方法

在中，我们介绍了POI（兴趣点）的设计及其搜索。由于推荐系统是兴趣点系统的核心，所以接下来，我们将介绍推荐系统。推荐系统是一个很庞大的课题，将分成两期予以介绍：本期讲述推荐系统的设计方法，包含推荐系统的数学基础和设计原理。