在这个基础上，我们做了两个优化：一是针对稀疏的频道，实现了支持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的流式的服务框架，采用全配置驱动的方式动态生成工作流，从而达到对产品逻辑、算法策略方面的快速支持。

　　今天的分享由于时间原因很快就要结束了，在摸索如何融合搜索引擎和个性化推荐系统我已经走过三四年，这其中有许多我过去的思考以及在一点资讯团队所做的实践方面的工作。整个兴趣引擎要做的工作还非常复杂且有挑战性，也非常欢迎对兴趣引擎感兴趣的同学能够与我们有一些更多的交流。