当前位置: > 高等教育 >

一点资讯田明军:深度融合搜索+个性化推荐背景下的兴趣引擎构架

时间:2016-12-06  来源:未知  作者:新疆教育新闻网
导读:由InfoQ中国团队推出,面向高端技巧治理者和架构师的寰球架构师峰会(ArchSummit)日前在北京国际会议中心举办。来自腾讯、滴滴出行、一点资讯等互联网企...

由InfoQ中国团队推出,面向高端技巧治理者和架构师的寰球架构师峰会(ArchSummit)日前在北京国际会议中心举办。来自腾讯、滴滴出行、一点资讯等互联网企业的技术专家受邀出席并做主题演讲。

  一点资讯高等技术总监田明军发表主题演讲

在本次大会上,一点资讯高级技术总监田明军详细诠释了深度融合搜索和推荐引擎对获取用户阅读兴趣、实现信息精准分发的必要性,并以一点资讯为例,从技术框架和产品理念角度,分享了兴趣引擎将二者有机融合的心得。

他以为,搜索和推荐两种获守信息的途径和体验缺一不可。一点资讯的兴趣引擎系统通过结合了用户搜索行为所涉及的全网数据,不断学习用户的兴趣再进行推荐,并由用户主动“订阅”深入这一兴趣,建立兴趣之间的衔接点,从而买通用户对信息的主动抒发和被动接收两条通道,使信息获取更加高效、精准,为全方位提升用户体验打下了坚实的基本。

以下为田明军演讲内容精编版:

大家早上好,非常幸运今天有机遇与大家分享一点资讯关于融合搜索和推荐引擎的一些思考和实践。

单一的搜索或推荐引擎不利于全面满意信息散发需求

在移动互联网时代,搜索和个性化推荐都是用户获取信息的两种重要的方式:搜索通常随同着用户的明白表达,用户输入关键词即可找到本人想要的答案;反观推荐,则是用户通过产品出现的内容进行非目标性的兴趣浏览。但这两种体验是不能互替的,单纯根据历史阅读记录进行的个性化推荐并不能了解用户某时刻的本身想法,而另一方面,也很难根据天天一两次搜索行为总结出用户的长期规律。

所以从产品角度来说,搜索和推荐的体验二者不可或缺、关联严密。这也是我们致力于实现二者融合的原因。

但需要注意的是,二者在意图表达方式、训练模型等方面存在着伟大差异,基于这些差别点,我们不能简略的用其中一种系统来实现搜索和推荐融合的目的。

搜索和推荐的融合之路应该怎样走?

对于融合的解决之道,一点资讯选择在搜索和推荐引擎之间参加了一个基于用户兴趣的任意关键词订阅环节。通过搜索发现用户所查询的答案同时,我们也提炼、扩充出针对用户兴趣的表达,并以此固定积淀在用户画像里。因此,搜索让个性化推荐层面,增加了一条高效地获取用户兴趣的途径。

反过来说,通过推荐系统把共性的有趣、有料的内容浮现给用户,通过推荐产品收集到用户更多层面的反馈,从而得到这些内容的普适性特征。基于这些特征的挖掘,我们也能够对内容有更深入的懂得。而再将搜索体验中加入并有效利用这些共性特征,也更增强化、提升了搜索的品德。

接下来,我将从兴趣引擎的整体系统架构中,选取了几项要害技术点,论述一点资讯将搜索和推荐内容休会真正融合的办法:

异构索引引领检索效率晋升 针对搜索+推荐深度优化

为实现深度融合的目标,针对搜索和推荐不同的服务特色和系统性能要求,首先我们提出了异构索引构造。

从上图可以清晰地看出异构索引的数据来源和组织形式。我们可以从图的底部可以看到,发生异性索引数据的平台一分为三:数据平台、编辑运维平台和内容平台。图片顶部则展示了不同数据的索引构建所采用的不同技术。

内容平台方面,对外网抓取的内容和自媒体平台生产的内容,我们树立了通用的倒排索引。

在左侧的数据平台,则通过对用户行为的挖掘,产生基于协同过滤信息的挖掘的推荐列表,以及针对不同人群放置的热文列表,这部分我们使用通用的KV数据库存储。

中间这部分的数据起源于内容平台和编辑运维平台,体现了技术与人工的联合。这部分数据存在内容的竞争机制,变化比较机动,应用了自建的支持排序列表的索引结构。

大家也许会问,为什么会有这样的划分?这主要是基于优化检索性能角度的思考。根据关键词对倒排索引进行查询的方式非常成熟,完全够能够满足搜索系统的需求,然而,传统的倒排索引却很难对推荐需求的几十维以上的特点进行查询。

在这个基础上,我们做了两个优化:一是针对稀疏的频道,实现了支持WAND(一种介于AND和OR之间的索引查询操作符)检索系统加快召回内容的效率;而对于浓密的头部频道,则通过开发频道文章索引库,维护从频道到排序内容列表的映射,将线上查询压力转移到线下,提升检索的效率。

以unified feeder为核心的内容处理平台解决写入困难

方才看到方方面面的索引,接下来,我们必需要解决里面索引的写入的问题。这就需要在统一的内容处理平台,把这些内容写到异构的索引结构里面。

我们的内容处置平台的中心之一,则是unified feeder系统,这是内容处理平台与索引系统之间传递信息的桥梁。

在unified feeder实际工作中,首先针对不同的输入数据,我们存入了许多不同的索引库,这个工作通过统一的配置与模板中心进行管理,可以便利的维护和扩大。此外,unified feeder内部有一个checkpoint系统,在各个关键索引内容写入之后,会向checkpoint系统发送验证信号,假如任何数据写入失败,checkpoint系统会有记载,系统可以主动进行数据的重新写入。这种方式有效的解决了系统容错和异构索引数据一致性的问题。

双层架构的自适应索引召回打破异构索引挑战

接下来我将讲授在有了以上数据基础之后,针对上面的搜索和推荐恳求,我们如何通过自适应索引召回技术,从不同的索引里面获取数据?这主要面临三个方面的技术挑战??决议需要调用的索引后端、异构索引召回效率,以及可扩展性与开发效率。

上图是大家整个召回系统的结构框架。通信模块和存储模块集成了一些异步IO通讯机制和缓存机制,提升了需要到多个索引库里面查询时并发的性能,提升了查询效率。

另外两个技术难点的解决主要靠意图分析和查询生成器,依据搜索和推荐不同的要求去适配到下游不同的索引库里面去取内容,同时在系统中的解耦算法和工程方面,提升系统可扩展性和并发工作的效率。

查询生成过程引入了逻辑层和物理层的概念,物理层即索引池,物理层对外裸露的是异构索引系统的一些详细查询的API接口,通过这些接口的调用真正完成详细的索引对内容的获取。而逻辑层更多体现在算法上,通过对查问的意图剖析,转化为逻辑层一个或多个从索引中获守信息的意图,例如热门,兴趣图谱等。逻辑层到物理层的映射能够懂得相似于搜索引擎里query rewrite的过程,每一逻辑层的意图被翻译成若干物理层索引API的调用。

以逻辑层的兴趣图谱为例,通过这个用户画像里面的具体兴趣,好比,某位用户对“互联网思维”感兴趣,基于兴趣图谱的获取,它会把这个兴趣点转化成频道推荐索引、搜索系统、人工运维的精选池三方面的物理获取门路进行查询,从而召回一些关系兴趣频道的内容,相关源的内容以及人工需要去展现出的内容。

总之,通过这样一种把逻辑层和物理层离开的方式,有效分别了算法逻辑设计和实际索引物理拜访之间的耦合,到达了让二者工作更好并行的效果。

双模型排序框架满意搜索+推荐需求

最后和大家快捷过一下我们为支持深度融合搜索和推荐,在排序框架和算法产品策略支持方面的一些工作。

在排序框架上,我们现阶段主要支持两种模型更新框架,一是周期性batch更新模型的框架,二是支持online learning的准实时模型更新框架。可以知足现有的搜寻和推荐方面在排序方面的需求。

工作流服务框架支持算法产品策略灵活调整

在算法产品策略方面,因需求灵巧多变、对系统开发效率要求较高,我们引入了一个基于Akka actor model的流式的服务框架,采取全配置驱动的方式动态生成工作流,从而达到对产品逻辑、算法策略方面的倏地支持。

今天的分享由于时间原因很快就要停止了,在探索如何融会搜索引擎和个性化推荐系统我已经走过三四年,这其中有许多我从前的思考以及在一点资讯团队所做的实际方面的工作。整个兴趣引擎要做的工作还非常复杂且有挑衅性,也非常欢送对兴趣引擎感兴趣的同窗可能与我们有一些更多的交换。




上一篇:热烈祝贺脑立方南岗分中心盛大开业暨亲子公益讲座圆满举办!
下一篇:献礼国美30周年庆 国美华人金融e签宝、信美分期精彩上线

24小时排行榜