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

通过Storm 聚合之后可以产出时间列、维度列、事实列三种基础效果数据，其中时间列包括数据产生的时间节点即时间戳等；维度列主要包含数据的入口、位置、业务场景、特征等信息；事实列包括信息是否曝光、用户是否点击、购买以及购买金额、商品信息等。
三种基础效果数据相当于样本特征及标签，可用于在线学习，对应的模型结构如下：

文章插图

从模型结构上来看，将GBDT与FTRL进行了融合：基于实时样本流，利用点击 GBDT模型、下单GBDT模型产出叶子节点进行编码，原始特征分桶或者离散后加入模型，利用FTRL更新模型参数存入redis实现在线排序。
目前模型结构相对来说简单，业务效果的提升主要体现在模型调参，在此简单地介绍几个小技巧：

文章插图

n 采样策略：
1）位置截断：考虑到不可能利用所有的实时样本，因此会结合业务特点及数据特点进行位置截断：
如用户不小心刷到位置特别靠后的列表数据，这部分数据对于预测效果价值不大就会丢弃；
2）业务过滤：之所以存在业务过滤，是因为最后的投放不仅仅取决于算法结果，也取决于业务规则。如新店的加入或扶持特定的商家，需要将它的排序强行放在首位，这样带来订单量的提升就不是算法的功劳。
3）根据样本目标设置样本权重：根据不同阶段的目前进行样本权重的调整，比如现阶段的业务目标是优化GMV，将会调高GMV的样本权重。
n 参数更新
为什么采用定时更新参数的策略，而不是实时更新参数？主要是考虑到工程的难度，在线预测服务不可能实时获取参数，否则将影响在线服务性能。目前采用5分钟定时获取模型参数，保证模型抖动不会太剧烈。若由于样本延迟造成正负样本比例发生变化或者特殊情况导致参数发生波动，这样的更新策略就可保证模型的稳定性。
n 样本不均衡
在外卖场景中，正样本特别宝贵。假如与跟正样本相关的订单数据流由于网络等原因造成延迟导致样本数据都是正样本或者负样本，倘若直接使用这类样本实时更新模型就会导致模型参数发生巨大的抖动。因此我们目前采取的方式是利用缓存存储这类样本，然后根据权重拆分样本，分时段与负样本进行混合使得样本的正负比大致稳定，进而解决样本不均衡的问题。
n 输入归一化
特别是线性模型一般推荐数据归一化，否则模型收敛速度特别慢。而在线学习模型，由于不是短时间输入大量样本，这就使得样本量相对较小、收敛速度较慢，归一化后可提升收敛速度。
与此同时采用归一化后的样本数据训练出的权重相对而言是可比较的，业务可解释性更强。
接下来介绍2个小特色：
n 可视化Debug

文章插图

模型上线后若想知道模型效果或者数据排序依据，就采用加入白名单的方式，将实时收集的排序数据通过页面的形式同步地将后端打分依据展示出来，包括排名依据、是否融入了业务规则、特征权重，这样便于排查特征缺失等问题。
App端收集的用户行为数据，如埋点信息、订单信息等，经过数据清洗、聚合后将前后端的数据通过页面形式呈现出来,这便于模型调试、线上问题排查。
n 实时效果对比

文章插图

结合storm产出的维度列信息，利用不同的维度进行数据聚合，实现实时效果对比：
1）分算法版本实时效果：根据不同的算法版本统计点击率、金额等实现了实时A/B test 。
2）分入口实时效果
3）分列表位置实时效果
4）实时特征监控。
作者：刘金，饿了么算法专家。12年毕业后加入阿里，主要从事淘系电商数据开发与挖掘，16年入职饿了么，加入搜索推荐算法组，从无到有开始搭建实时技术在推荐场景的应用，包括实时特征、实时监控及在线学习的落地。