京东个性化推荐系统实战(下)

        推荐系统架构,推荐系统由品类平台,素材、特征召回平台、模型计算打分服务,排序服务构成。

京东个性化推荐系统实战(下)

       将请求封装成QueryInfo对象,通过对象来向下完成一步步数据召回。首先是通过QueryInfo对象召回品类、分类信息。

       前边有人问到是怎样实现通用化?好问题,当时答得不太好,现在梳理总结一下,分类平台通过配置品类、分类信息,

配置选取个数、配置过滤品类信息,通过每一种配置情况构建分类信息,分类信息完全由配置文件构成。

 

       召回品类扩展QueryInfo对象构成QueryInfoExtern对象,为下一步进行素材、特征召回做准备,因为品类、分类数据量

少,传输时不会因为数据量消耗太多时间,而素材、特征召回量极大,可通过分布式形式将素材进行召回,此时召回量最大

可满足线上服务要求,召回之后,每组分别进行打分计算,打分之后进行取前边数据进行返回。

       再由品类召回节点合并将高分素材进行返回,熟悉ElasticSearch同学,会发现和ElasticSearch集群架构很像,其实推

荐本身和搜索就有很多相似之处,研究搜索引擎对于推荐引擎构建也会大有益处。

 

       数据返回之前由排序服务对数据按展示效果进行商品按照品类、分类进行分隔,文章内容按标签、主题进行分隔。分隔

目的是为了好的展示效果,提升用户体验,通过上面这一系列过程构建成推荐系统大致过程。

 

       除了上边架构逻辑,还存在存储以及数据流转体系。分类、素材、特征存储在redis、HBase中供服务读取使用。

       对于实时反馈,用户点击、浏览会通过存储在redis中用于过滤,以及调整后续推荐分类、素材权重,已作为一种最实时

反馈手段。

       

京东个性化推荐系统实战(下)

 

       上报特征本身通过JDQ消息队列进行上报,上报异步进行,通过先写日志文件再上报日志文件内容,来达到异步上报,

以避免同步上报导致线上服务性能受影响。JDQ本身基于开源kafka打造。

       JDQ本身为了资源情况限制上报速度为5M/s,为了更好利用上报机器资源,会构建内存队列,充分利用内存资源来控制发

送速度,而不是一味通过扩容来解决问题。

 

       日志白名单本身按照服务、属性、关键字进行存储,在ElasticSearch中可方便按属性、关键词检索使用,通过图形化界

面展示,方便快速定位线上问题。

       监控本身除了Ump对系统功能、性能、可用性进行监控,引擎本身就要配备全面监控避免程序某个分支存在问题,导致

线上服务正确性、可用性存在问题,再有因为程序很多由配置文件动态构成,性能也要进行全面监控。

 

       对于线上效果,线上模型与分支进行绑定,当分支A效果实时效果好于B效果,要将线上模型进行更新调整,监控时间

以几个小时效果为准。线上效果也要进行相应监控,如效果不好要对效果进行报警,以便算法人员对情况进行处理。

       推荐系统本身涉及算法层、数据层、业务层、线上服务多个层,实际也会涉及多个组,怎样沟通效率以及开发效率以及

整个系统架构开发灵活性也是每个参与其中的人应该去思考的。其他公司同学也遇到类似问题,我们也进行相应沟通,能够

效率最大化沟通就是我们一致的目标。

       推荐系统抽象性需要对推荐业务有足够理解,并能跳脱推荐业务站在更高层次,将系统进行组件式、动态式、配置化设计

以及实现。一是避免重复开发,一是留有更多时间去思考如何去做更有价值的事。

       

       推荐系统不单单是去不断提升转化率、点击率、gmv,同时我们也要多考虑考虑怎么样给用户带去更多有价值内容,有价

值信息,不单单是推荐一些低俗无底线内容来达成kpi,如果工作全部以kpi为导向,我们最终能获得多少提升呢?

       最近一段时间对于推荐系统一点总结,以便后续查看,如对读者有些帮助,就更好了。  

扫码关注公众号

            扫码关注

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zyyzdp.html