基于推荐系统架构的思考

想象一下,站在推荐引擎面前的你被抽离出一个数字的躯体。你找到一面镜子,却惊诧的发现自己的身体被无数数据所填充,许是:科技10%、篮球4%、热火队2.3%、历史1%、自然0.3%。你仔细观察,甚至发现了很多连你自己都没有注意到的细节:虽然热爱旅游,但你喜欢博物馆远多过自然景观。当然,你也会发现自己的身体上仍然有一团团的迷雾,那是尚未被系统所发掘的兴趣点。

专门为你适配的内容如一群萤火虫般朝你涌来,你伸手点击了一条内容将它点亮。就在点击的那一瞬间、你身上的迷雾有一丝散去了,同时显示出了新的兴趣点:“极限运动:0.01%”,那些原本就存在的密密麻麻的数字也有一些发生了变化:有的权重上升、有的权重下降。每一次选择与反馈,你都在进化着自己的数字躯体。

现在,你生出了双翅、原地飞翔了起来,能够从高处俯瞰整个推荐系统。你看到了一个又一个数字拟态的人,在不同的信息流中畅游。每个人身边围绕着许许多多的信息光点、又同其他人之间有着若隐若现的连接。一个个信息被阅读的点亮、被忽略的变暗。每一个被点亮的光点就像被延续了生命一样,得以被分裂成更多光点、顺着人和人之间的连接,飞舞到更多的人身边。此起彼伏的光点明灭,共同照亮了整座系统,让它仿佛有生命一般慢慢扩张。

648ffe666235445692c0c8433d28f811.png

图片制作:https://wordart.com/create

这个过程听起来或许科幻,但用来描绘推荐系统,怕是再恰当不过了。

推荐是一个协作与进化的过程:

  • 对于内容而言,每一个用户既是消费者又是决策者,被认可的内容得以进一步扩散,不被认可的内容被纠偏、不至于影响更多的人。

  • 对于用户而言,每一次行为反馈都在不断完善自己的用户画像;而系统的兴趣探索行为,也在进一步给这幅画像补充了更多维度。

大致了解推荐系统的架构,能够帮助我们认知到:信息是如何匹配给用户的,而用户的选择又是如何影响后续的信息分发的。

作为一个工程问题,推荐系统的架构与搜索系统的架构具有一定的相似度:都做的是信息与用户意图之间的匹配。

搜索系统是将海量内容与用户表意明确的查询相关联,推荐系统则是将海量内容与用户没有明确表达的偏好相关联。

如果我们将推荐问题极度简化:用户只有一个爱好“NBA”时,那么推荐引擎给用户的结果就可以近似搜索引擎在“NBA”这个搜索词下的结果。

那么,一个简化的搜索架构是什么?

ef74f070607744fb88ec7a8dd94903ab.png

离线部分,专注在内容的搜集和处理上。

搜索引擎的爬虫系统会从海量网站上抓取原始内容,针对搜索体系的不同要求建立索引体系。在上图中,为了新内容能够更好的被用户看到,就专门建立了时效性索引数据用于存储几个小时之内的新内容。这是一个基于关键词的倒排索引,每一个关键词对应一长串提及该关键字的文章。比如,“教育”这个词命中文章1、2、3;“NBA”命中了另外一批文章1、2、4。

在线部分,负责响应用户的搜索,完成文章的筛选、排序并最终返回给用户。

用户输入一个搜索词“NBA”,这个词汇会首先经过搜索词的处理(会经过分词、搜索词变换等步骤),例如“NBA”和“美职篮”是同义词,那么在两个词都可以应用在索引的查询。

经历完搜索词处理后,进入召回环节。系统会通过多种召回方式,从索引数据里获得候选集合。在图中,就分别查询了全量的索引数据和时效性索引数据,获得了8篇文章的集合。

在召回的候选集之上,会进行排序的步骤,通过进一步计算获得最终结果反馈给用户,如图中的文章10和文章1。

用户的点击反馈也会影响排序环节的模型。在上图中,用户在展示给他的两篇文章中只点击了文章10,这一特征会被模型记录以统计文章10和文章1在搜索词 “NBA”下的表现情况。

借由搜索系统为参考,可以更好的理解推荐系统。

e0c0098d1a5b4dd69cba8e2c28fc2f3f.png

离线部分,同样需要通过各种方式来获取待推荐的内容(用户提交、协议同步、数据库导入等)。并依据推荐引擎处理的不同维度对这些内容进行索引处理,如话题、类目、实体词等。在上图中展示了两个维度:分类维度和实体词维度。

在线部分,其理亦然:量化用户的请求,完成文章的筛选和排序。

推荐与搜索最大的差异,在于用户表意的不明确性,故而,需要尽可能的完善用户的长期画像(对哪些类目、实体词、话题感兴趣)和短期场景(时间、地点),以此获得用户的意图,从而进行意图和内容的匹配。

  • 当用户打开内容推荐软件时,提交给系统的信息如:时间、地理位置、网络环境、手机设备型号、登陆用户ID等。

  • 基于用户ID,推荐系统会取出用户的画像数据(User Profile)。在分类维度,用户对体育和科技的内容感兴趣;在实体词维度,对于NBA感兴趣。

  • 根据用户的画像信息,发起不同的召回过程(类目查询和实体词查询),获取各种类型的内容构成候选集合。

  • 按照特定预估目标(如点击导向、互动导向)对候选集统一排序,并反馈给用户。

值得注意的是:对于推荐系统而言,用户的行为不仅具有针对内容价值评估的群体投票意义(如:某篇关于NBA的文章,偏好NBA的用户都不点击,那么其在“NBA”这个实体词下应该权重降低)同样具有针对自身画像的个体进化意义(如:用户总是点击有关于热火队的NBA文章,那么这个用户的画像中会补充“热火”这个实体词,影响后续他自己的推荐内容流。)

了解了推荐系统的基础架构之后,站在不同角度的我们就有了不同的优化空间和迭代导向。

用户

我们常常说要把用户当做小白来看待,以不断降低用户的使用成本。但不论怎么让产品普世化、小白化,每一个产品都客观存在由浅入深的功能进阶。如果你想享有更有效率更为顺心的服务,我建议你去“训练”推荐系统。

请不吝于表达和互动,用你的反馈支持服务提供商和内容创作者。对于令你满意的服务和产品,登陆是最好的肯定。在你登陆后,你的所有行为轨迹就不至于丢失、在更换设备之后仍然能够获得稳定的服务体验。对于令你满意的内容、请果断的点赞、评论;对于你喜欢的作者,亦可以关注他后续的动态。“赠人玫瑰、手有余香”,这些典型正向反馈能够让算法更快速的收敛、确定你的喜好。

自媒体

对于内容创作者来说,清楚自己的内容是如何接触到用户的,才能够更好的“包装”内容。一篇内容有机会触达到用户,是因为它能够被机器所理解;一篇内容有机会扩散给足够多的用户,则是因为它能够收获用户的满意点击。服务于机器、服务于人,这样的内容才能够在推荐系统中获得良好的分发量。更详细的内容,会在后续同大家探讨。

产品经理

对于产品经理来说,理解推荐系统架构有助于我们更好的优化产品体验、迭代分发策略。

其一、完善用户画像。在上面的介绍中我们知道,一个用户的画像越丰富,就越能够让一次查询变得丰富,从而获得更多的候选集合,进而可能得到更好的推荐体验。

以NBA为例,每年的6月下旬到10月底之间,是NBA的休赛期。在这一周期内,除了偶尔哪个球星的花边消息还算得上NBA相关新闻外,你基本看不到什么有关NBA的内容。对于推荐系统来说,如果对用户的认知只停留在NBA上,那么这段时间显然没有办法给用户提供优质的消费内容。只有你知道用户尽可能多的兴趣,内容推荐的体验才不至于某一内容源的断供而发生断崖(2017年8月,网易云音乐的下架风波其实是对于这一事件最好的注脚。)

完善用户画像,既可以通过尽可能多的外部渠道数据来帮你塑造用户,也可以借由产品设计和运营活动引导用户多沉淀行为;以支付宝为例,一次过年的集五福活动,就让它收获了数以亿记的关系链数据。而紧随其后的蚂蚁森林、蚂蚁庄园等轻社交游戏,间接上丰富了用户的线下支付数据、用户的健康数据等。

第二、优化垂类内容分发、优化信息召回。

如果说用户画像的完善是一种输入层面的完善,那么召回的完善就是对输出候选集更好的完善。

我们可以用企业的招聘过程来类比,招聘的诉求就是给合适的岗位(输入的意图)找到合适的人(输出的信息)。在进入终面环节前,不同候选人会有不同的遭遇:有些人会经历简历筛选、笔试筛选、群面筛选,也有些人会通过内推渠道直接跳过简历筛选和笔试环节,直接进入最终面试。

第一个问题:为什么在面试前会有这么多不同的筛选方式?

这些筛选其实是基于不同角度进行的召回:如果你是行业领军企业中的人员,那么基于行业口碑的背书,完全不需要笔试环节就可以直接进入面试。如果你只是初出茅庐,但是学习背景同岗位高度匹配,那么简历上陈述的信息就会帮助你通过简历的筛选进入笔试环节。不同的筛选方式共同作用,从而得到了一个进入终极面试的候选人集合。

下一个问题,最终面试可以轻易修改么?

当然不行,终极面试是一个排序环节,是最终的公平性保证。就算你是老江湖,一样有可能在特定领域里水土不服;如果确实才华过人,就算历经关隘,初出茅庐的小将定能过五关斩六将。

这就是为什么,我更建议大家修改召回模块而非排序模块的原因。召回模块的修改,扩充了候选集合能够让我们拥有更多可能性;而排序模块的主观修改,则极可能让我们损失公平性、降低效率。

第三,完善规则系统,优化用户的使用体验。

由于规则是在排序环节之后生效的、对于系统的影响最大,故而,它是产品经理最强意志的体现。

一方面,规则是最快速的上线生效途径,可以用于纠偏、提权等等操作。举个例子,在《中国有嘻哈》开播之前,大众是不知道红花会是什么的。彼时你搜索红花会,搜索会告知你它是金庸先生《书剑恩仇录》里的一个江湖组织。而当《中国有嘻哈》开播以后,所有人突然开始搜索红花会了,系统的滞后性让它无法快速理解用户的真实意图。这时,就该产品经理进行规则干预了,标注红花会是一个嘻哈团体。

另一方面,我们需要认识到的是:短期的干预是应该逐步被长期的机制所替换的。规则就像打补丁,短期上线能够遮住窟窿,但长期补丁叠补丁这衣服就没法穿了。太多的规则系统会严重增加系统的复杂度、降低可理解性。同样以“红花会”为例,在这个问题上,我们应该下力气解决的是系统的滞后性,让它能够更快速的实现搜索内容的进化。如果有一天,有位流量明星主演了《书剑恩仇录》,那么大众对“红花会”的认知,是否又会重回武侠小说了呢?系统里配置的规则“红花会==嘻哈团体”是否又会变得不合时宜呢?

我个人笃信的是:人力所能覆盖的规则语义和逻辑复杂度从长线来看是无法胜过机器的。对于初始场景或应急情况,规则系统必不可少,是我们保证服务质量底线的措施。但随着系统的逐步复杂和进化,产品经理也应该学会退位,让机器不断逼近更好的上限。

作者:闫泽华

关键字:产品经理, 用户

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部