一、 “四个关键”为你揭开推荐系统的神秘面纱

个人认为,推荐系统是根据用户以及不同的场景差异,对信息进行合理的排序、过滤,解决信息过载问题的一套机制。这个定义中包含四个关键点,如下:

1.“根据用户以及不同的场景差异”

对于很多刚开始做推荐的人可能会忽略这一点,大部分人在思考推荐时想的更多的可能是基于用户来做,但其实我从众多实践中发现,很多时候推荐产生价值不仅仅只是说以用户进行区分,相关场景的差异会对于最后推荐效果产生巨大的影响。

2.“推荐的本质是对信息进行合理的排序、过滤”

很多人认为推荐是一个魔盒,非常神奇,其实究其本质是企业有成千上万甚至上亿的 item,不管这些 item 是文章、视频,还是电商里面的商品,然后现在有某个人在一个具体的场景里面,企业需要把这些 item 给他看,那应该把哪个放在第一个?这就是推荐系统背后的运作原理。

3. “推荐系统要解决信息过载的问题”

举个例子,如果你的企业只做爆款商品,整个公司只卖两个商品,这样用户一看就明白了,显然也不需要推荐,所以做推荐的一个前提条件是你公司本身提供的业务里面的信息太多了,对于一个正常的自然人来说,他处理不了那么多信息的时候,企业才需要去帮助用户解决信息过载的问题,从而为用户设计这样一套机制。

4.“一套机制”

这点很好理解,推荐系统是由不同的算法、规则等构成的一套机制。这四点是我从产品视角为你解读了什么是推荐系统,以及他的一些简单作用。

二、推荐系统、广告系统、搜索系统三者有何不同?

事实上,解决我在前面提到的一系列问题,推荐系统并不是唯一的方法。比如,前面所提到的排序、过滤,做技术的同学应该很容易联想到,搜索和广告系统也涉及排序、过滤,且搜索也一定程度上解决了信息过载。那么,这三个系统,它到底有什么区别呢?我从 5 个方面对其进行了对比,下面将一一讲述:

1.用户获取信息的方式。

广告与推荐系统,用户都是被动的,但搜索不一样,用户是主动搜索的,他需要输入一些关键词,会加入一些自己的意见和重点。

2.点击率要求。

这三个系统对点击率都有要求,仅在要求上有些区别,这就不详述了。

3.惊喜度要求

对于广告和搜索系统来说,不需要太多的惊喜度。比如,如果我搜一个关键词,搜索到我想要的资料时,并不会觉得很惊喜,甚至认为是理所当然,但是在推荐系统里,用户往往对惊喜度是有要求的。

具体来说,用户对于一个推荐系统的期望是希望产品能够给他们一些惊喜,如用户 A 虽然不知道产品用了什么数据、什么方法,但如果突然推荐了一首可能他已经快遗忘的自己却很喜欢的歌时,他就会因感到产品“好懂我”而惊喜。

4.个性化要求。

在广告和搜索系统,个性化的需求是可有可无的,不管有没有系统也能正常运作。但是,对于推荐系统来说,个性化要求非常高,甚至越高越好。因为个性化推荐针对的是差异化的单个场景,一定会有个性化的要求。

5.用户反馈。

广告和搜索系统存在比较隐性的反馈,即对于搜索结果好不好?一般很少有搜索引擎厂商会直接问用户,你喜不喜欢搜索结果,更多是厂商去判定广告效果和搜索效果,一般是通过 CTR,或通过整个产品的某些长期留存表现来判定。但是,对于推荐系统来说,很多推荐产品会直接地问用户的喜好,存在很明显的显性主观表达。

因此,同样是解决类似的一系列问题。 但是这三个不同的系统存在极大的差异(如下图),这些区别直接决定了企业去判断某个业务适不适合使用个性化推荐,以及该如何做好个性化推荐。

三、什么样的产品或业务适合采用个性化推荐?

个人认为,具有媒体性的产品(Media Product)适合使用个性化推荐,这里指的不是只有与媒体相关的才能使用推荐,公司业务为电商的就不行,其实它只是一个概念,包含四个点,但不一定要同时满足,下面我将一一解说。

1.口味很重要(Taste)

产品中的 Taste 本身很重要。举个例子,网上曾有一个很火的梗,在淘宝搜索连衣裙,排在第二位的连衣裙价格,代表了在整个淘宝体系里判定你个人的客单价范围。我们当时试了一下,发现一个特别有趣的现象,就是一般女生搜索出来的价格都会很低,大概一两百元,而我和一些男同事搜索出来会高很多,如我搜索的基本上是一千八左右的连衣裙,仔细想一想也有原因,像女生天天逛淘宝,大大小小什么商品都买,但我上淘宝基本上都是要买相机、电脑,这些价格都在几千或上万元。很容易发现,我们所有人对于买的东西的方向和口味是有差异的。

事实上除了存在差异还存在要求,很多人不希望被一个平台判定其口味是某个方向。比如一个具备推荐系统的网站总给你推荐一些下三滥、低俗的东西,他会想“天哪!我是这样一个人吗?”因此,大家对于一个平台的口味和自己的口味都是有要求的。

2.单位成本不重要(Cost)

“单位成本不重要”我们可以通过这个例子来理解,比如以前我们每天看报纸,因为报纸的单价较便宜,对应到现在的产品,比如我听一首歌、看一篇文章、买一个常规的商品,你的消费行为的 cost 消耗都不高,且不那么重要。

3.有瀑布效应(Information Cascade)

瀑布效应指的是,一旦在社区或平台里产生了一个趋势,那么整个平台的其他人都会跟随这个趋势,比如,微博上转发超过三四千的动态,可能会慢慢地被转发的更多,整个社区会形成这样的一些趋势和倾向,瀑布效应在平台和社区较容易形成。

4.多样性(Diversity)

这一点指的是你的平台的内容本身是具有多样性的,这是推荐的基础。如果整个平台的内容在各种维度、属性上都一致,那么很难做推荐。

基本上,只要满足以上 1-2 个点,我们就可以说它是一个偏媒体型的产品。这方面一个很经典的例子,我们可以看下图,在图中的王守崑是原来负责豆瓣最早的推荐系统的架构师,这是他在很早之前分享中的一页 PPT,我觉得这是讲一个产品适不适合上推荐最直观的一个例子。

当时他们在做豆瓣推荐的时候,首先思考到底应该优先在什么频道上推荐,为此设置了一个判断的标准,开始列一些指标,如下:

豆瓣会根据各个频道的用户数、条目数(豆瓣收录的图书、电影、音乐多少)计算稀疏性,比如图书的条目数是 300 万,同时记录图书用户群体人均会在豆瓣收藏几本书(点看过的视为收藏),豆瓣用人均的看过的次数除以总的条目数算出的值叫做稀疏性。如果一个产品稀疏性太低,那么继续使用现行的推荐系统的相关算法就会出现问题,因为整个待推荐的内容面临很大的群体,如果每一个人喜欢的东西太少时,他就会散落在整个大群体的各个方面,你很难找到人和人之间具体的关系,因为每个人在整个系统里面的表达兴趣太少了。因此,稀疏性低的产品做推荐,要么是工程难度比较高,那么效果可能不太好,一般说稀疏性高一点的产品更容易找到人与人之间契合的东西,当然稀疏性也不能过高,如果稀疏性达到百分之八九十,那所有的用户可能就过于相似,所以豆瓣比较强调稀疏性。

关于多样性,有一个有趣的点需要注意。比如图书的多样性高,大家可能理解图书仅根据一个侦探小说就能分出几十个类型;电影的多样性低,好像和常规的理解不一样,事实上因为电影现在是高度工业化和商业化的产品,他们的类型聚集度是相当高的。所以这给了大家一个启示,在判断自身产品时,不要完全凭直觉,而要真的拿自己公司的实际数据说话。

时效性很好理解,我就不解释了。反馈是指在某个品类中,企业做出一个推荐行为,用户什么时候能给企业一个反馈,也就是用户表达自己喜好的反馈时间周期是快还是慢。比如图书就会很慢,读完可能需要十天半个月,拖延症的人可能还要读半年左右;文章就会很快,只要点我的文章就可以定义为偏好,把这篇文章滚动到底就是喜欢;音乐也是,听完就是喜欢,很快跳过就是不喜欢。

最后,豆瓣会综合前面所有的这些维度属性来判断推荐效果。在图中他们认为推荐效果最好的是单曲,原因是单曲的稀疏性特别高,虽然多样性相对来说低级别,但是因为稀疏性高,加上反馈周期特别快,综合起来效果最好。事实上,这也是为什么大家在互联网的花花世界中,还能记得豆瓣 FM 这个产品。不过,豆瓣在其他方面的推荐效果也不错,比如图书。

以上,就是豆瓣当时内部的一个评估过程,揭示了企业想要做一个推荐产品的时,到底该如何去衡量这个业务适不适合做,效果将怎样,需要定一个衡量的标准。

四、以商业为目的,推荐要做成什么样?

推荐的商业目的一般分为以下几种:

1.用计算机经验取代运营经验(节省成本、提高效率)

这一点非常重要,很多人提到推荐系统会认为是由公司的技术部门负责,像变魔法一样,就把某个事情从人工运营变成了机器运营,然后运营的同学就好像没活干了,但事实不是如此,其实本质上来说它是取代运营经验,但是有个前提条件是你们公司本来有运营经验,我很少见到公司使用推荐系统是完全抛开运营团队,单靠技术团队自己的力量,把推荐系统运作得很好。

事实上,我们可以这样理解这一点:运营积累了一些经验,但是只能通过运营人工的进行一次次干预,这样往往只能对整个区域进行干预,没有办法把经验落地到每一个具体的用户身上,干预每一个用户的体验还是很难。因此,推荐系统就可以帮助解决提升每个用户的体验问题。

2.充分利用流量(提高变现能力)

事实上,很多企业的产品设计以及各种运营方案,可能只能解决众多流量的其中 60% 的需求,另外 40% 的需求被忽略了,或者是不得不忽略,因为企业没有办法给每一个用户或者每一群用户单独配一个运营。此时,推荐系统就可以起到类似分流量的精细化运营的作用。

3.促进信息流动(留住小众用户)

这个价值点可能很多企业没有注意到,因为大多数想使用个性化推荐的公司,都在考虑公司如何赚钱?或用户如何能得到更好的体验?但是,很多产品的推荐系统还有一个很重要的作用是促进信息流动,从而留住小众用户。在很多形态的产品中,不管是社区型的产品,还是电商型的产品,它都会存在一些商品,如果产品的机制运营的不错,这些商品会在短时间之内成为整个社区的话题和爆款。

但是可能社区本身的积淀或产品的话题程度,不可能让它持续地成为话题,但是一定要制造话题,因为其一可以彰显整个社区多样性,其二小众的群体也觉得自己能在大平台得到展现,会更容易留下来,但如果整个社区缺乏这种能力,展示在推荐位置的永远是热门的大众内容,那么长尾的小众社区、小众用户、小众商品就会涌入其他平台,企业便很难养起来那一部分的风。

回到当下来看,像抖音这样的产品,为什么能够让那么多人参与进去?核心在于聚集了多样化的用户,比如经常在抖音上看到一些播放量、点赞量都是几十万的用户,你点进去他的主页来看历史的视频播放,你会发现这个用户可能只有那一个视频几十万,其他的视频只有几百、几千的播放量。但这就是推荐系统的魅力,用户不需要一直是一个大 V,只要偶尔一个内容能够成为爆款,那么平台就能够把这类用户筛选出来,让他吸引更多的人参与进来,而避免说被少数的大 V、头部流量把整个平台给遏制住,这是一个比较有意思的商业目的。

五、产品、运营必知的推荐系统算法

这里是针对常见的一些做推荐的基础思想和算法进行简单的扫盲(之后神策数据公众号会有一篇文章“推荐系统的实践与思考”会对最新的一些推荐系统的架构构建进行专门的介绍),以下三种是比较常见的:

协调过滤(CF)、隐语义模型(LFM)、优势排行(Edgerank),我们最常见到的是CF、其中 Edgerank 主要用于类似 Facebook 做社交的企业。

1.协调过滤(CF)

事实上,大部分的推荐系统的本质是“物以类聚,人以群分”,思路大概可分为两个方面:其一,研究物品,即研究被推荐系统推荐的 item 进行推荐,被称为基于物品的推荐(Item-based);其二,研究人,即根据人的喜好进行推荐,被称为基于用户的推荐(User-based)。

基于物品的协同过滤是什么意思呢?举个例子,某个电商企业的商品 i 和 j 被同一类人喜欢,因此可以将其归为一类,当用户 u 喜欢 i 但是没有看过 j,就可以把 j 推荐给 u。

基于用户的协同过滤又是什么意思呢?前面提到的物品的协同过滤是先把物品归为一类,然后再推荐相同类的,而基于用户的协调过滤是我们先分析用户。举个例子,我们把用户 A 和 B 归为一类,然后,就可以把 B 喜欢的商品,A 还没看过的 i 也推荐给 A。

2.隐语义模型(LFM)

隐语义模型相对协同过滤会复杂一些,但是本质上也较相似,这根据用户的行为和物品的特征,用机器学习的方法先把物品进行分类,然后再计算用户 A 对每一个类别的兴趣程度。举个例子,某个企业通过机器学习把物品分成了十个类,然后该企业计算用户 A 对每个类别的兴趣程度,可以划分为 1、0.8、0.7、0.5、0.3 等。之后,企业继续计算一个物品 i 对于每个类别的权重,也就是物品 i 到底该被划分到哪个类别,最后,企业根据这两个信息和权重计算出用户对物品 i 的喜爱程度。相比协同过滤,LFM 分的更精细,事实上,现实中不管是人的属性还是物品的属性都千差万别,很难通过单纯的把物品或人分为一类就能满足推荐的需求。

3.优势排行(Edgerank)

Edgerank 是 Facebook 完全基于自身信息流分发构建的一个算法。这能帮助大家理解有时候推荐算法不是简单采用市面上恒定的算法,而要根据公司实际的需求调整。Edgerank 会算三个指标:亲密度(Affinity Score)、边的权重(Edge Weight)、新鲜程度(Time Decay)。

亲密度(Affinity Score)。比如用户 A 发了一些文字信息、视频、图片等,用户 B 从一些第三方应用分享的这些文字、视频、图片来到用户 A 的信息流,Facebook 就会首先算用户 B 与用户 A 的亲密程度(同学?情侣?曾经互动过?),通过系统来计算出 AS 的亲密度分数,当判定为存在亲密度,就会再计算边的权重。

边的权重(Edge Weight)。这指的是用户 B 通过什么样子的边连接到你,是图片?文字?还是通过分享自己喜欢的文章,像这种不同的连接类型,叫做边。 边的权重的不同会帮助更好的推荐。举个例子,如果发现 Facebook 的用户更喜欢看照片,照片的边的权重就会更高;如果用户总发一些没有营养的鸡汤文,这些文章边的权重就会下降。

新鲜程度(Time Decay)指的是内容本身的发布时间的早晚,越近发布的权重会越高。

Facebook 会综合这三个指标给用户做推荐,但是对大多数企业来说无法直接套用,因为这是根据 Facebook 自身信息流的分发需求提炼出的影响因子。

之所以为大家介绍这三种模型,是想让大家简单了解现在做推荐的常规手段,但事实上现在的工程实践远比上面的这些基础模型复杂,我们再来看一下推荐系统的架构图,这不是纯技术角度的架构图,比较偏产品视角。事实上,做推荐系统往往是一个过程,通过多种算法得到一个初步结果,然后再对初步结果进行过滤、排序,再生成一些推荐原因,最后展示推荐结果。在整个过程里面,产品运营参与的环节也比较多,这就是我的一个理解。

更多互联网干货和案例,可关注【神策数据】公众号了解,回复关键词还能进交流群、获得报告、行业案例等福利哦~

神策数据张涛:个性化推荐从入门到精通相关推荐

  1. 神策数据 VP 张涛:个性化推荐从入门到精通(附推荐产品经理修炼秘籍)

    本文内容来自于近期神策数据举办的<智能推荐--应用场景与技术难点剖析>闭门会上的分享内容整理,分享者为神策数据副总裁张涛,曾就职于腾讯.映客和豌豆荚等知名互联网公司. 大家好,我是张涛,在 ...

  2. 【回顾】神策数据VP张涛:个性化推荐从入门到精通

    本文内容来自于神策数据举办的<智能推荐--应用场景与技术难点剖析>闭门会上的分享内容整理,分享者为神策数据副总裁张涛,曾就职于腾讯.映客和豌豆荚等知名互联网公司. 大家好,我是张涛,在加入 ...

  3. 个性化推荐从入门到精通(附推荐产品经理修炼秘籍)

    本文内容来自于神策数据举办的<智能推荐--应用场景与技术难点剖析>闭门会上的分享内容整理,分享者为神策数据副总裁张涛,曾就职于腾讯.映客和豌豆荚等知名互联网公司. 大家好,我是张涛,在加入 ...

  4. 个性化推荐从入门到精通

    今天的分享将为大家解答以下几个问题:你的公司是否适合采用个性化推荐?如果需要个性化推荐,该如何做好?产品运营在参与到一个推荐系统的构建当中,有哪些常见的坑?有哪些可以避开这些坑的一些简单方法?以及如何 ...

  5. 神策数据张涛:AARRR 模型面临的新挑战

    本文根据神策数据副总裁张涛以<AARRR 模型面临的新挑战>为主题的演讲分享整理而成.将为您介绍以下内容: AARRR 模型过去所解决的问题 环境改变了,问题也会跟着变 如何重新看待 AA ...

  6. PPT 下载 | 神策数据张涛:企业服务客户全生命周期运营三步曲客情诊断 解决方案库...

    本文根据神策数据副总裁张涛关于企业服务客户全生命周期系列的直播内容整理,共 3 篇,上篇回顾<PPT 下载 | 神策数据张涛:企业服务客户全生命周期运营三步曲总览篇>,本篇主要内容如下: ...

  7. java从入门到精通_Java大数据:数据库开发从入门到精通

    在Java大数据开发任务当中,数据存储是非常关键的一环,涉及到分布式文件系统.分布式数据库,数据库是后端系统当中支持数据存储的重要组件.今天我们就来聊聊Java大数据,数据库开发从入门到精通,应该如何 ...

  8. Java大数据:数据库开发从入门到精通

    在Java大数据开发任务当中,数据存储是非常关键的一环,涉及到分布式文件系统.分布式数据库,数据库是后端系统当中支持数据存储的重要组件.今天我们就来聊聊Java大数据,数据库开发从入门到精通,应该如何 ...

  9. 神策数据张涛:微信生态数字化运营解决方案

    本文根据神策数据副总裁张涛关于微信生态数字化运营解决方案相关直播内容整理而成,本文主要内容如下: 微信生态运营现状 & 痛点 微信生态数字化运营解决方案 运营落地场景 & 案例展示 一 ...

最新文章

  1. 两个下拉框相关联ajax,触发第二个下拉框以显示基于从第一个下拉框中选择的值的值ajax...
  2. 基于Live555的多路视频流的流媒体服务器框架
  3. 离群点检测算法——LOF(Local Outlier Factor)
  4. 树转化为二叉树_森林转化为二叉树(详解版)
  5. hadoop基石HDFS
  6. SQL Server 2008连载之存储结构——基本系统视图
  7. 国外persona用户画像_使用Mozilla Persona验证用户的指南
  8. fcc无线充电认证_FCC规定了无线路由器固件,轮椅和胰岛素的开放状态以及更多新闻
  9. 2017.8.5 One-Dimensional 思考记录
  10. sock 文件方式控制宿主机_docker的容器可视化工具portainer
  11. docker下安装mysql数据库
  12. [PyTorch] 基于Python和PyTorch的cifar-10分类
  13. 语音处理的分帧,帧移,加窗,滤波,降噪,合成
  14. 关于c#中的string
  15. Java之美[从蛮荒到撬动地球]之设计模式四
  16. 新炬网络签约GBASE南大通用 让中国用户用上世界级国产数据库
  17. MySQL学习笔记.安全管理
  18. 【转载】CSRF攻击与防御(写得非常好)
  19. 【Pandas总结】第八节 Pandas 合并数据集_pd.merge()
  20. 什么是序列化 怎么序列化 为什么序列化

热门文章

  1. 童言无忌的最高境界(笑到抽筋)
  2. Python:矩阵相乘
  3. requests爬虫遇到404怎么办_Python网络爬虫2 – 请求中遇到的几个问题
  4. 创业老板野心有多大?我觉得可以搞个爱奇艺离线版试试……
  5. autodesk产品无法安装解决方案
  6. springboot 项目如何存放微信的验证文件
  7. 肠道短链脂肪酸如何让人变胖或变瘦
  8. WebRTC基础介绍
  9. 使用支付宝沙箱演示支付宝支付
  10. 用Inkscape绘制logo教程