两年搜索推荐的技术演进之路

两年搜索推荐的技术演进之路

缘起

上个月参加云栖大会见识了阿里搜索推荐十年的历程。除了前沿的算法技术包括iGraph图引擎、强化学习、迁移学习、向量化模型等等,还介绍了阿里强大的搜索推荐平台AI·OS。AI·OS平台包含了一系列的组件包括TPP推荐业务平台、RTP深度学习预测引擎、HA3搜索召回引擎、DII推荐召回引擎、iGraph图查询引擎等。平台水平扩展性强,支撑了所有的搜索推荐服务,提升了运维、数据、工程和算法同学的效率。阿里搜索推荐做到现在用了十年,技术上的高投入取得了高回报,搜索推荐创造的商业价值占了电商GMV的绝大部分。
临渊羡鱼,不如退而结网。搜索推荐我们做了两年多和大厂的差距是很大的,好在一直在追赶还没达到望尘莫及的地步。借着大厂学到的经验介绍一下我厂搜索推荐技术上的过去、现在和将来的规划。

过去

跑起来,效果好。起步阶段人员有限大家都是草台班子,先把戏台搭起来让系统跑起来。相对于搜索系统,推荐系统不仅要提供符合预期的功能服务,还要带来价值提升,否则推荐产品的生命力不会长久。 即便是草台班子也有公司强大的数据平台作为支撑,数据平台积累了大量日志数据存放在Hive中。
借助Spark我们实现了协同过滤、关联推荐、用户画像的计算,并将数据存放于Solr中。Solr不仅作为搜索引擎,也承担了很大一部分的存储工作包括Item信息,User信息。这一阶段除了常用的推荐算法,更多地靠分析业务场景的特点,设计合适规则策略来提升效果。Spark程序选择什么语言呢Java?Python?Scala?最后我们选择了Scala,Scala是Spark的原生开发语言文档相对丰富,同时Scala函数式编程语法简洁优雅。

现在

快速接入,稳定性,更优算法。随着搜索推荐效果逐渐显现,越来越多的业务要接入进来。一个一个的对接成本太高,我们开发了返利智能推荐引擎,简化对接流程,提升对接效率。
早期Tomcat服务在Solr机器上,Tomcat调用本地的Solr服务,现在我们将Tomcat和Solr进行解耦,拆分为两个集群提升了高可用。搜索引擎索引任务之前主要使用Solr自带的Dataimport,建立本地任务。随着Solr集群机器的增加对数据库的压力增大,我们开发了索引管理任务,统一接管数据的获取和分发以及索引的创建。同时为了减轻Solr请求的压力,把用户画像数据存放到Hbase上加Redis热点缓存提升性能。借助于TensorFlow、Sklearn、Xgboost,在排序环节中尝试了LR、DNN、Wide&Deep算法。

将来

化繁为简,平台化,精细化。功能越来越多,需要把零散在系统中的常用功能,抽离出来形成独立的服务甚至是平台。可以预见的会有数据存储、监控平台、索引管理、特征处理、离线训练、日志收集、召回服务、排序服务、重排序服务等等。平台内部之间的通信,包括搜索推荐对外提供服务的形式微服务可以作为参考和规范。
目前的推荐依然做的还比较粗犷,统一各个业务线的类目、品牌、行为重新打造更细致的用户画像。同时推荐系统的实时反馈有进一步升级的空间,针对新用户的冷启动多臂老虎机算法或许是个不错的选择。更前沿的算法DeepFM、LightGBM等等都值得一试。推荐的准确性、多样性、惊喜性,智能交互式搜索,多目标多场景的优化会是长期的方向。

小结

架构是迭代演进出来的,不是照搬设计出来的,没有完美的架构只有合适的架构。最后提一下我们的技术栈
编程语言:Java,PHP,Scala,Python
数据存储:Solr,Kafka,Redis,Hive,Hbase,Mysql
机器学习框架:Spark、TensorFlow、Sklearn、Xgboost

编辑于 2018-10-03

文章被以下专栏收录