Linkedin协同过滤推荐平台Browsemap赏析

版权声明:本文为原创文章,未经允许不得转载!

随着数据过载越来越严重和为用户个性化的需求越来越紧迫,推荐的作用会越来越大,本文结合Linkedin论文《The Browsemaps: Collaborative Filtering at LinkedIn》[1],主要谈一下Linkedin的Browsemap平台的设计与实现,同时在介绍一些具体的推荐场景或推荐算法时,会结合自己的一些工作经验一起叙述。

1. Browsemap平台的功能

Browsemap是Linkedin开发的一个实现了物品协同过滤推荐算法的泛化平台,该平台可支持Linkedin中所有实体(entity)的推荐(实体包括求职者、招聘贴[2]、企业、社会群体(如学校等)、搜索词等),支持快速开发和部署,并且支持超大型数据集、提供了监控系统和线上统一的调用API。

通过Browsemap平台,基于业务需要,若要实现某个新的实体协同过滤推荐,开发者要做的工作仅仅包括:相关行为日志的接入、编写Browsemap DSL配置文件(该部分后续会详细介绍)和调整相关过期参数等简单工作。一般只需要一两天的开发时间。

2. Browsemap平台的架构

如图1所示,Browsemap是一个同时提供线上和线下服务的系统。主要流程如下:在线下,基于hadoop实现Browsemap Engine,Browsemap Engine会根据Browsemap DSL生成推荐结果,并将推荐结果存储在支持线上高并发读写的分布式KV数据库Voldemort中,最后通过统一的API供线上检索读取,需要指出的是该API是实体无关的(entity-agnostic),并支持A/B测试。



图1 Browsemap平台架构

下面主要介绍一下Browsemap系统的一个创新性的设计——Browsemap DSL(Domain-Specific Language)。Browsemap DSL是构建一个推荐场景(原论文中称为browsemap)工作流(workflow)的描述语言,当然可以简单的把它看成一个workflow配置文件,如图2所示。



图2 基于Browsemap DSL编写的workflow实例

开发者可通过Browsemap DSL定义工作流(workflow)的各个模块,包括模块间的执行流程、模块间的依赖关系、每个模块的输入输出路径、以及相关参数的配置(如特定实体过期时间)等。Browsemap engine通过解析Browsemap DSL就可以完成整个线下推荐算法的实现。Browsemap DSL的设计不仅加快了推荐模块的开发速度,同时还促进了模块共享(如过滤噪声用户模块等),降低了开发成本。

另外需要注意两点:

  • 每个browsemap(推荐场景)可对应一个或多个workflow。
  • 在工作流中的每个模块会对应一个或多个hadoop job,由workflow manager(Linkedin的一个hadoop调度平台)统一管理和调度;其中包括一些基于Hourglass实现的增量计算job。(因为这篇论文介绍的是Linkedin大概五六年前的工作,所以大部分计算还是基于MR的。)

3. Browsemap平台的应用

原论文中介绍了Browsemap平台在Linkedin的7个方面的应用,在此基于58招聘的推荐场景主要介绍其中的4个:给求职者推荐公司(Companies You May Want To Follow)、相似公司推荐(Similar Companies)、相似简历推荐(Similar Profiles)和搜索词推荐(Related Searches)。

  • 给求职者推荐公司(Companies You May Want To Follow)

    1. 通过Browsemap实现item-cf,计算用户和潜在follow公司的相似度值,得到related-companies feature;
    2. 将related-companies feature和用户/公司内容特征一起通过LR训练,得到最终的偏好分值(propensity score)。其中,内容相关特征包括:用户画像特征的industry, location和experience等;企业画像特征的industry, location和description等,具体属性对应关系如图3所示。


图3 用户画像特征和企业画像特征的对应关系
  • 相似公司推荐(Similar Companies)

    与给求职者推荐公司有两点不同:

    1. 内容特征相似度变为公司画像之间的相似度;
    2. 使用的用户行为不仅仅是follow行为,还有view和 employed-at等行为(即基于多行为构建browsemap)。
  • 相似简历(用户)推荐(Similar Profiles)

    通过公司详情页浏览行为(Company-view)和用户画像特征实现该部分推荐。同时将相似简历的属性用于补足简历的缺失属性,得到该用户的虚拟简历(virtual profile)

  • 搜索词推荐(Related Searches)

    提供了四种关联方式:

    1. 协同过滤:在计算搜索词(item)间相关性时会加入时间和空间因素(但论文中没有具体说明如何加入的)
    2. 基于推荐搜索词搜索结果的点击率
    3. 基于搜索词之间的重合度
    4. 基于推荐搜索词的点击率

    针对这四种方式分别实验,线上线下结果均表明协同过滤的结果最好,甚至也好于将这四种方式综合(unified)的结果。

4. 招聘推荐的一些经验

本节主要介绍原论文中提出的做推荐系统时的一些经验教训:

  • 不要重复造轮子:Browsemap平台规范并实现了协同过滤算法的整个workflow,而且整个workflow是基于Browsemap DSL可配置的,如前所述,这种方式使得当需要搭建一个新对象(entity)的browsemap或者添加新的用户行为browsemap时都十分方便。进而可使开发人员集中精力去深入理解产品需求、花更多的精力去优化处理输入的数据和支持更多精细的垂直产品需求。
  • 一图胜千言:样式和展现方式是第一生产力,能带来最大的roi,其次是底层数据建设的质量,最后才是推荐算法。以论文中的例子为例,在简历(用户)推荐场景中,展示用户图片的样式比不展示的CTR提升高达50%,这几乎是任何推荐算法都难以企及的提升。
  • 不同的推荐位可同页共存:不同的推荐算法可用满足不同的用户需求,而且通过A/B实验表明:在同一页面的基于不同算法实现的推荐位几乎是相互独立、互不影响的,并且可共同提升推荐转化效果。
  • 协同过滤解决不了所有的问题:冷启动问题是协同过滤类算法的软肋,解决冷启动问题只能通过实体的画像(属性)或该实体的社交关系等策略。此外,原论文还提到了一种利用用户行为来丰富冷启动实体或低频操作实体画像的策略。

最后,然后简单谈一点个人的思考:

  • 不同的推荐场景需要使用不同的用户行为,如加入一些不恰当的用户行为未必会带来转化率的提升;
  • 需要对每一种行为(behavior event)实现一个推荐工作流,这样才能单独实验每种行为带来的收益,当然也需要基于多种行为实现一些推荐工作流,因为基于多行为协同过滤算法可关联更多的item。

5. 总结

本文首先分析了Browsemap平台的功能和架构,然后主要介绍了Browsemap平台在Linkedin四个主要推荐场景的应用,最后介绍了招聘推荐时的一些经验。如有疑问,欢迎留言交流。

版权声明:本文为原创文章,未经允许不得转载!

参考文献:

  1. Lili Wu, Sam Shah, Sean Choi, Mitul Tiwari, Christian Posse: The Browsemaps: Collaborative Filtering at LinkedIn. RSWeb@RecSys 2014.
  2. https://engineering.linkedin.com/recommender-systems/browsemap-collaborative-filtering-linkedin

发表评论

电子邮件地址不会被公开。 必填项已用*标注