饿了么推荐算法演进及在线学习实践( 二 )


但是模型结构复杂度的增加使得在线预测达不到工程响应时间要求 。现阶段模型一直在优化,在业务低峰期仍使用此模型,业务高峰期工程上采用降级的方式 。
(二)DeepFM
随后尝试了DeepFM,总体结构和论文保持一致,充分利用DNN提取高阶特征组合以及FM提取二阶特征的能力,实现了自动提取特征,是一个端到端的模型 。该模型在很长一段时间用于首页推荐,实验效果比较理想 。

饿了么推荐算法演进及在线学习实践

文章插图
 
模型经过不断地演化,现阶段外卖推荐系统架构与大部分推荐系统架构类似:
饿了么推荐算法演进及在线学习实践

文章插图
 
1)数据来源:包括业务日志、服务端日志、用户行为日志;
2)基础设施层:包括大数据处理的Spark、Hadoop以及用于实时计算的平台、工具 。可以看出引入了很多开源组件,加入阿里后考虑引入公共基础设施,避免由于开源组件本身存在的问题困扰业务发展;
3)特征层:包括商户、用户、上下文、交叉组合等维度特征;
4)模型层:特征层的数据输入模型层后调用实时数据、用户画像等数据服务层;
5)数据服务层:包含实时数据服务、画像服务、特征服务等;
6)业务层:结合模型输出的结果用于在线业务投放等 。
 
三、 在线学习实践
 
目前在线学习(Online Learing)这几年比较热门,利用一年左右的时间,从无到有搭建了在线学习 。
 
3.1 在线学习的特点为什么要做在线学习?很多时候我们会遇到类似问题:利用离线数据训练的模型效果很好,而在线效果却不理想 。这就意味着离线评测与在线效果之间存在很大的gap 。
饿了么推荐算法演进及在线学习实践

文章插图
 
这是什么原因造成的呢?主要是由于数据分布数据时刻发生变化,特别是外卖业务,用户在不同的时间段会选择不同类型的外卖,而商户会随时上线各种营销活动,这就使得数据分布范围、分布趋势发生很大的变化 。
而在线学习的优势就是利用实时收集的样本数据及用户反馈实时更新模型参数进行预估,最后进行最新的投放,进而实时反馈用户兴趣爱好等变化带来的影响 。
在线学习与离线学习的一个重要区别是它可以简单地理解为数据集无限大,时间序列无限长 。它不需要存储大量的样本数据,而是利用样本流数据逐条地更新模型,样本学习完成后丢弃 。这就避免了离线模型随着数据量增大导致模型无法训练,即便采用分布式训练,训练速度也会变慢 。
饿了么推荐算法演进及在线学习实践

文章插图
 
最后,总结在线学习的特点:
饿了么推荐算法演进及在线学习实践

文章插图
 
3.2理论基础
饿了么推荐算法演进及在线学习实践

文章插图
 
FTRL模型是参照谷歌发表的论文实现的,模型参数、响应速度均可达到电商领域或推荐领域的生产要求 。
 
3.3 在线学习技术栈在线学习使用的技术栈包括以下几个方面,引入了很多的开源组件:
饿了么推荐算法演进及在线学习实践

文章插图
 
3.4 在线学习流程图
现阶段在线学习流程图如下:
饿了么推荐算法演进及在线学习实践

文章插图
 
最左侧是实时效果归属:基于在线排序引擎实时收集业务日志、用户行为日志,利用storm聚合生成一个实时样本流;然后进入在线模型训练实时消费样本流,利用FTRL模型实时更新参数,在不同时间将模型参数快照定时存入redis 。说到快照的好处,它不仅支持模型增量学习,而且即使模型训练终止,也可以加载历史参数从某个节点重新进行模型训练 。
在线预测:定时拉取redis中的模型参数提供线上预测服务 。至于为什么采用定时更新参数,稍后给出答案 。
上述三个模块最终能够形成一个闭环,关键在于将所有的数据源join起来 。
饿了么推荐算法演进及在线学习实践

文章插图
 
那么又是如何做到将所有的数据源join起来,在此特别介绍一下实时归属模块 。将用户行为、服务端日志、订单日志等数据经过清洗、过滤等,在Storm中利用唯一id将整个业务join起来 。在整个数据体系设计过程中给每一次排序打上唯一id,在整个的业务流程环节中标记此id 。特别地,Storm对状态管理支持不是特别好,目前通过web存储的方式进行状态管理,防止任务挂了丢失状态信息 。


推荐阅读