深度学习在省钱快报推荐排序中的应用与实践

导读：省钱快报是一家中小型综合类电商APP，近2年平台规模有了较大增长，AI在平台业务发展中发挥了巨大作用。本文以推荐场景优化在省钱快报的发展为脉络，对于中小型电商公司在资源有限的客观条件下，对机器学习和深度学习的运用进行了架构和模型的相关探索。

01. 业务背景

省钱快报推荐业务主要涉及首页feeds推荐、详情页相似商品推荐、收藏、个人中心等其他入口的推荐，业务指标着重关注ctr/cvr/gmv等，产品形态上和淘宝、京东等大致一样，不同之处在于下单的动作发生在第三方app上。简单来说用户在快报上的成交链路为浏览->点击->领券->跳转至第三方平台详情页并下单。因此不同于一般电商业务，快报的交易场景下转化漏斗较多，漏斗各层都需要关注。点击率、领券率、下单率每个环节都需要最优化，而各个指标又相互牵制相互影响，优化过程困难重重。

02. 系统架构

数据流

数据流分为离线部分和实时部分，离线部分主要包含了app曝光日志、线上服务特征日志的收集、拼接、清洗等，大体上是一个label match的过程，这一过程的准确性决定了后续阶段模型能够给业务带来的收益，如果label match出错了，那训练出来的模型也必然是不可用的，一定不会带来好的应用效果。数据拼接的任务一定要尽可能的保证曝光、点击、订单的量和比例都能和BI报表的统计数据对的上，这是训练出可靠模型的前提。快报团队非常重视数据的准确性，我们从多个方面检验和保证最终数据的准确无误。这中间最重要的是需要设计一个跟踪用户请求、曝光、点击、订单整个转化链路的唯一ID，我们称之为traceID，主要通过这个ID来完成label match的过程。

模型训练和评估

快报模型团队在tensorflow的基础上自研开发了一套轻便灵活的模型训练系统，整个模型训练、评估和上线的过程都通过配置文件完成。另外鉴于训练资源的问题我们开发了增量训练的功能，即base模型为过去90天的数据训练的模型，之后的模型在base模型的基础上逐天增量训练，一般情况下增量训练能在一个小时内完成。同时相比于batch模型 ( 每天训练过去90天的模型 ) 增量模型能更好的学习到近期的数据分布，从auc上看这种训练方式能提升接近1个点的auc。

模型训练部分有几点经验可以说一下：

• 为了保持线上、线下特征一致性，我们在线上会直接把特征落下来。第一，省去线下再次进行特征抽取的过程。第二，可以尽可能的保证特征的一致性，避免因为线上、线下特征不一致导致模型效果不理想。
• 训练数据集和测试数据集应该严格按照时间划分，防止发生穿越情况，测试数据集必须是"未来"的数据，一般我们会用昨天以前的若干天数据作为训练数据，用当天 ( 可能若干小时，一般建议选择8点到12点这段时间数据 ) 的数据作为测试数据，每次模型调参训练时训练集、测试集应当固定，以保证评估结果的可对比性。
• 根据我们的经验，从远到近按天shuffle训练的效果要好于多天一起shuffle训练，auc在千分位有若干点提升。
• 评估主要看auc、user auc。

模型在线服务

对于深度模型，模型服务模块我们直接使用了tensorflow serving，FM模型的服务是自己开发的Java微服务，不多表述，主要说一下tf serving在我们预估服务上的应用。

tf serving有很多优秀的特性：

• Google开源，开箱即用，安装、使用简单
• 支持模型版本控制、回滚
• 支持并发，吞吐量高
• 支持模型热更新
• 支持RESTful/HTTP或者gRPC接口

自己开发深度模型的预测服务需要大量的工作，鉴于G厂已经开源了tf serving，而其性能经过验证也是符合我们线上要求的，所以我们利用tf serving来完成模型的预测工作。由于在FM的阶段我们已经积累了很多模型服务的基础功能，例如模型热更新、模型上线/下线切换、版本管理等等，因此这些没有用tf serving自带的功能，而是主要通过集成consul来配合完成上述功能和预测服务的注册发现的。

在推荐业务的模型中我们用了大量ID类特征，所以开了比较大的特征空间 ( 2的28次方 )，整个模型文件大概19G左右，线上预测的平均耗时在10ms左右。根据我们的经验，最能提升性能的优化就是对请求进行分片，并行请求模型服务，这样大概能提升40%左右的延时，当然耗时主要还是跟模型的复杂度有关，因此需要在模型复杂度 ( 效果 ) 和耗时之间做出合理权衡。

03. 模型演进

快报推荐模型的演进过程大致是从FM->DeepFM->custom DNN这样的一个过程，中间还经历了Din/Dien/ESMM等探索和过渡期。

base模型 ( FM )

一般的模型演进过程都是从LR或者GBDT开始，我们直接跳过了LR的阶段，直接过渡到了FM作为第一个模型。究其原因，FM早在13年左右就已经开始被大范围使用，而我们在18年中才开始应用模型进行排序工作，FM模型的效果已经得到各大厂的广泛验证，因此我们也比较有信心将FM作为base model。

相比于历史更悠久LR模型，FM模型可以自动做二阶的特征组合，相比于需要人工进行特征组合的LR来说FM在这方面完爆之。

看公式，FM只是比LR多了后面交叉项的因式分解部分，实际上这也算是如今大行其道的embedding的雏形了。公式上看直接计算FM复杂度是O(KN2)，但是上述公式在简化后可以在O(KN)复杂度内计算，而在稀疏情况下往往大量x为0，因此计算通常远远小于O(KN)的复杂度，同时稀疏模型的模型文件也可以大幅压缩，在实际应用中我们去除了w和v全为0的参数，模型文件压缩了80%左右，同步模型所需的带宽和predictor服务所需的内存也大幅减少。

我们上线的第一版模型是FM+FTRL的组合，经过多次迭代auc大致在0.68～0.69左右，线上累计ctr提升30%+。

FM到DeepFM

经过小半年的迭代，FM逐渐有点力不从心，在特征上挖掘和利用的差不多的时候我们逐渐开始把方向转向深度模型，希望深度模型能进一步带来效果提升。

深度模型在15、16年之后慢慢变成主流，在Google开源tensorflow，发表wide&deep模型，推出alpha go之后，深度模型便彻底火了起来。但是在推荐/搜索领域深度模型真正应用的好的也就是头部几个大厂，小公司印象里有成功应用的并不多见。我们在18年底押注深度学习，经过调研后第一个模型便确定为DeepFM，因为FM模型我们已经做的相当成熟练，因此从FM升级到DeepFM是理所当然。

DeepFM本身并不复杂，从本质上讲只是在FM的基础上增加了若干层神经网络而已，embedding层都是共享的，因此可以端到端的训练。相对于FM模型，DeepFM的NN部分可以增加高阶的特征交互，弥补FM在高阶特征组合上的补足 ( 原理上FM可以任意阶组合，但是受限于计算复杂度，一般应用中只有二阶 )。相较于FNN这种把FM的输出当作NN输入的模型，DeepFM可以端到端的训练，而且能同时保留二阶和高阶的特征组合。

在FM迁移到DeepFM后，并没有取得预期的效果，auc和FM持平，经过多次调优依然不能超越FM。究其原因，我们推测有如下两点：

• 在我们的推荐排序场景下二阶的特征组合已经可以完全满足组合特征的需求；
• 我们FM实现过程中未出现的特征参数是没有初始化的，也就默认是0。但tensorflow会初始化一个随机值，这有可能影响到最终评估的效果。

后来翻阅各种资料，受YouTube Net ( Deep Neural Networks for YouTube Recommendation )、和DIN ( Deep Interest Network ) 等文章的启发我们把用户的点击序列加入到模型当中，用户的行为序列往往能非常好的刻画该用户的兴趣分布。和DIN不同的是，我们没有对用户行为序列做attention，我仅仅把序列做了一次sum。总的来说和sum相比attention并没有明显优势，而且计算量更大。另外average的效果也略差于sum，看其他一些团队的经验貌似也有类似结论，所以我线上模型仅对序列做了sum。这一次改动auc提升了2个点左右，线上ctr有接近10%的提升。

其他模型探索

在DeepFM成功上线并取得不错效果之后，我们又花了很长一段时间探索了诸如DIN/DIEN、ESMM、DCN、xDeepFM等当时一些思路新颖的模型，下面主要回顾一下在这些模型上的尝试。

1. DIN/DIEN

DIN/DIEN是阿里妈妈团队的ctr模型，主要用在广告ctr预估上业务上，当然推荐排序场景也可以应用。上图中和Base模型相比DIN的主要思想是引入attention，一般网络中对序列特征等多值/变长的特征处理方法通常是embedding之后做sum/average/pooling等操作，将其变为定长。序列有长有短，这类操作往往导致信息损失和误差。我们认为序列中每个元素都代表用户的兴趣点，引入attention之后便可以通过网络来学习整个序列，每个点都可以学到一个归一化的权重，整个序列可以通过加权和来表示，则兴趣的表示更加合理，理论上效果要好的多。

而DIEN更进一步引入RNN来提取兴趣，序列按时间先后顺序先通过RNN再对RNN的输出做attention，可以兼顾长短期兴趣及兴趣的演进，因此比DIN更加合理。

我们在实验中使用了过去30天点击过的物品序列，物品所属类别序列，物品品牌序列等，序列长度为50，其他特征方面和DeepFM差不多，经过多次迭代和调整，线下auc相比DeepFM没有提升，最终没有上线。DIN/DIEN对数据要求比较高，我们最长商品点击序列定为50，实际上大部分样本序列都非常短，序列的延续性不高，这些因素都影响了模型能力的发挥。

2. DCN、xDeepFM

DCN和DeepFM相比主要区别是左边FM部分替换为一个cross network的网络，其中第L+1层表示为Xl+1=X0XlTwl+bl+Xl，可以简单理解为前一层和第0层 ( 即输入层 ) 的特征组合。虽然cross net可以非常方便的控制任意高阶的特征组合，相比FM的二阶组合更具优势，但是从公式可以看出每一层都与输入层有太强的关联，因此高阶的特征交叉和一阶特征有很大相关性。

微软出的xDeepFM则更进一步将DeepFM左边FM部分替换为CIN ( Compressed Interaction Network )，xDeepFM及CIN的结构如下图：

Xk即为K阶的特征组合，相比于DCN中的cross network，CIN表达能力更强。在CIN中第K层表示为Xh,*k=∑i=1Hk-1∑j=1mWijk,h(Xi,*k-1·Xj,*0)，通过堆叠点乘和1维卷积操作，CIN能更充分的进行高阶特征融合，在加上右边的RNN，使得模型可以兼具更强的记忆和泛化能力。在我们的实验中，使用的特征和base model保持一致，仅仅改变网络结构，实验结果是DCN和DeepFM持平，xDeepFM在auc上仅有非常微弱的优势，但其计算量太大，线上预估时长较长，最终没有上线。

3. ESMM

ESMM也是阿里团队出的模型，其主要思想是将ctr/cvr两个目标放在统一的空间里进行训练，以解决cvr模型对于曝光样本的不可见和多目标优化、训练的问题，这个模型会放在后面多目标优化一节详细说明。

4. 自定义网络模型

经过DIN/DIEN/DCN/xDeepFM等一系列模型的研究之后，我们开始反思为什么这些大名鼎鼎的模型在我们的业务中没有达到预期？一方面业务不同、数据不同，没有一个万能的模型。另一方面我们在照搬这些模型的时候也许有一些细节没做好，这块后续还会进一步研究。之后我们从业务出发，逐渐开发和调整自己现有的网络结构和参数，最终我们的自定义网络经过多次迭代和优化，累计auc提升了接近2个点，下面是最终的网络结构。

模型效果对比

5. pairwise model

我们在pairwise model方面也做了好一些尝试，模型上改动不大，主要是loss部分改为BPR ( Bayesian Personalized Ranking ) loss，训练数据由pointwise调整为pairwise。

在pair构造方面主要尝试过以下几种方式构造 ( positive>negative ) 的样本对：

• 同一次请求内行为：订单>点击>曝光，对曝光进行下采样，控制样本量
• 同一次session内行为：订单>点击>曝光
• 用户一天内推荐列表所有行为：订单>点击>曝光，对曝光进行下采样，控制样本量

以上方案均按skip above思路只用最后一次点击以上的曝光样本做负样本。

pairwise方法考虑到了item之前的偏序关系，相比pointwise方法在列表排序场景中显得更合理，但是在实际应用中没有达到预期的效果。我们总结了pairwise方法的一些不足之处：

• 评估指标调整为ndcg，但是用下单、点击、曝光来作为标签也不是很合理
• 样本量和pointwise方法相比会急剧膨胀，如果不做合理的下采样，模型将难以训练
• 对数据噪声更敏感，一个错误数据可能会影响到许多pair
• pair的构造过程相当于强行改变来原有的数据分布，样本构造不合理则模型很难有好的效果，而构造合理的pair往往很困难

根据我们经验，pairwise方法的难点主要集中在样本构造方面，想要合理的构造训练的pair对是困难的，订单和点击构造多少pair、订单和曝光构造多少pair、点击和曝光构造多少pair都是很难确定出合理的数值的，考虑的训练成本问题需要进行负采样，这也会损失部分信息，从我们的经验来讲，总体上pairwise方法不太适合做feeds类产品的排序而更适合在搜索领域去应用。

6. 模型总结

在省钱快报推荐业务近2年的模型应用中，我们总结了以下一些经验：

• 在模型应用过程中选一个好的base model是第一步，强烈推荐第一版模型先上LR/GBDT等模型。第一版模型主要是打好一个基础，在数据、特征、label match、模型评估等方面先建立起完善的pipeline和环境，之后才能更好的发力。如果第一个模型太过复杂，模型可解释性差，那就不容易排查问题，而且复杂的模型对数据/特征/评估等环节的要求更高，因此第一版模型不宜采用太复杂的模型。
• 没有通用的模型，只有适合的模型，模型要随业务变动，往往根据业务特点针对性挖掘一些好的特征、增加一些训练数据比应用更新更复杂的模型来的更直接，所以我们也一直强调数据大于模型。
• 线下实验在评估的时候，一定要对齐测试样本，如果不能对齐测试集则auc就没有可比性。
• 每次线下实验不应该加太多特征、调太多参数，尽量保持耐心，每次实验最好只改变一处，这样方便得到可靠的实验结论。
• 轻易不要改变原始数据的分布。

对于深度推荐系统，有如下一些经验与思考：

向量化的必要性：

应该先从一个更宏观的角度来看向量的问题，不只是在推荐系统，或是NLP这些，而应该一切事物。如果前一句成立，则向量化就是必要的。而为什么说一切事物，其灵感直接来源于NLP，如E(法国) + E(首都) ~ E(巴黎)。如一个个词一样，所有事物都在某个空间中可以用向量准确的表达，在推荐系统则可能有E(couponA) + E(couponB) + … ~ E(couponC)。但是，显然我们没有NLP中对词的表达准确，所以一个优化的思路就是如何更准确的表达向量。要更准确，对应向量所要含有的信息量就应该足够大，显然现在使用的16维度向量不可能很好的包含这些信息。理想状态下，人看到一个商品，基本已经知道了这个商品的大部分特征，如类目，品牌，大致价格等。目前的算法是死的，要人为的指导它学习的方向，所以用商品向量+类目向量+品牌向量…作为一个商品就会有更足的信息这也是加类目序列的初衷。同时这样也可以看作将原来16维度的商拓展到了16*N，当然这样的拓展是不如直接使用高纬度向量的。

关于不做Mask：

输入的序列必须定长，假设取用户历史最近的50个点击，必然有很多用户没有50个点击。对于点击序列不做Mask将输入相同的随机初始化的向量，如下所示，全0向量对"缺失商品"的表达能力，很可能是不如网络学习的结果的。注意：这种方法是对于随机初始化的向量，且向量可学习。

序列：[S:12312,S:2345235,S:345345,S:-1,S:-1,S:-1,S:-1,S:-1,...]
 S:-1 -Hash-> 325344354 -embeding_lookup-> [.3,.5,.6,.7...]
 S:-1 -Hash-> 325344354 -embeding_lookup-> [.3,.5,.6,.7...] -Mask-> [.0,.0,.0,.0....]

关于特征交叉：

很多方法如PNN，LatentCross都是在对特征做交叉以更深的挖掘特征中信息。快报目前的特征是全部哈希后的随机初始化向量，在同一个特征域内，网络能对这种交叉关系进行比较好的学习。所以PNN中的以特征做点积、内积的方式并没有收益。

DeepFM，FM也是一种特征交叉的方式，不同于一般的经验，在我们的数据集上去掉FM部分是有一些收益的。我们的理解是普通特征经过了embeeding ( 如性别0, 1->性别向量X1, X2 ) 再通过网络训练，一方面本身的信息量放大了，另一方面特征直接的交叉关系可被网络学习到。所以DeepFM在我们的特征工程下是负收益。

04. 多目标优化

快报推荐业务主要关注ctr、cvr两个指标 ( 当然还有人均gmv、人均订单、arpu等 )。

ctr/cvr平衡

针对ctr、cvr我们分别训练了2个单独的模型来做针对性优化，其中ctr model以曝光为负样本，点击为正样本，cvr model以点击为负样本，下单为正样本。

做过电商的都知道，ctr和cvr往往反着来的，提升ctr的同时cvr就可能下降，提升cvr那么ctr就可能下降，算法同学需要权衡ctr、cvr两个指标取得一个最优解。

我们线上最终排序的时候基本上是CTRt*CVR这种方式，对于t的确定，我们通过线下计算来确定，基本上希望按最终公式排序后的点击auc能够不降或者微降，同时下单auc能提升，因为总的来说先有点击后有订单，所以点击这一步需要保证不能降太多。最终我们用这种方式上线后ctr微降1%左右，cvr提升10%，总体达到了不错的效果。

目前我们的目标还比较少，基本通过上述公式可以比较好的满足业务需求。

我们也尝试过在线上通过一个简单lr模型来更好的拟合ctr和cvr，但是最终效果不太理想，从总的思路来讲我们需要让整个转化漏斗的每个环节的敞口最大化。

ESMM

在ctr和cvr分别建模的情况下cvr模型由于下单样本相对于曝光/点击样本来说非常少，导致cvr模型难以充分训练。另外只用点击到下单的样本则丢失了曝光样本当中的大量信息，模型的预估也存在偏差。受到阿里ESSM模型的启发我们也尝试将ctr、cvr融合在一个模型进行建模。底层的输入一致，ctr任务和cvr任务共享embedding层，对于cvr来说可以在整个曝光的大空间内学习embedding向量。

因为有两个网络因此模型训练时长大致也增长一倍，从模型服务的角度讲好处是请求模型时只需要请求一个模型就可以。在具体应用时我们可以得到三个预估数值：pctr、pcvr、pctcvr，在线下评估的时候分别评估了pctr对应的点击auc，pcvr对应的下单auc，二者组合对应的点击/下单auc，从最终线下评估结果看ESMM要差于两个模型分开训练，最终线上的效果也低于基线。

ESMM之所以没有达到预期，猜测有若干原因：

• 在我们的场景中往往ctr高的商品cvr低，cvr高的商品ctr低，两个任务的关联性有时候刚好是反的。
• 我们没有精细调整两个任务loss的权重，也许这块可以优化。
• pcvr其实实际是曝光到下单也即pctcvr，论文中关于ctr、cvr、pctcvr三者的关系说的有点模糊。

在ESMM方面有应用经验的同行可以给点意见，一起交流分享一下。

05. 模型调优

超参数及特征上的探索

由于模型较为复杂，数据量大，训练成本高，无法用网格法暴力调参数，使用分阶段调参。

顺序为：隐层大小->学习率->Batch Size->Drop out/L1/L2的顺序进行参数调优。

在快报的数据集分布上，改变学习率带来的提升比较明显，由于Adam优化器占用内存大，使用Adagrad所以对应的batch size较小，可能不同于其他文章中分享的经验。网络层数越高准确度越高，结构影响很小，当达到一定层数后再提升带来的收益很小，综合考虑计算成本取了500*300层。

输入的数据全部是哈希之后embedding的所以有一个哈希空间和embedding向量维度的取舍，向量维度越高越准确，哈希空间也是。所以要根据机器内存综合考虑哈希冲突率和向量维度的影响。

下表为在其他参数不变的情况下，调整不同参数带来的AUC变化。

激活函数

激活函数方面，选择了常用的Relu。尝试过prelu和dice ( DIN中提出的激活函数 )，有略微的正收益，其中Dice>Prelu。

值得一提的是Dice激活函数在运算中进行了相当于BatchNorm的操作，在预测中Batch有变化时，输入结果将随之变化。例如，输入(x1, x2)得到预测结果(y1, y2)和输入(x1,x2,x3)得到预测结果(z1,z2,z3)时会导致(y1 !=z1, y2 != z2)，不便于Debug，故未应用在线上模型中。

特征处理

数据和特征对于模型的重要度不言而喻，在特征挖掘方面因业务而异，没有统一的标准，我们主要分用户侧特征、商品侧特征、店铺特侧特征、上下文及交互特征等。

在特征处理上我们基本分两大类方式：

• ID类特征和category特征在id化 ( 为了方便我们采用hash方式 ) 后做embedding。
• 数值类特征按等频分桶 ( 部分特征也会根据业务做一些数值变换 ) 进行离散化之后做embedding。

对于缺失值我们以业务字段对应的默认值填充。另外关于特征选择，我们首先会评估特征的覆盖率，准确性和获取难度等。然后会做一下相关性分析，经过以上步骤如果特征可用，我们会先直接加入该新特征，并在后续考虑是否做一下特征交叉等。

有了深度模型之后特征选择、特征工程往往容易被忽视，因为什么特征都全部embedding之后放到网络里面就可以了，但是原则上加特征之前还是需要做个简单评估，并且建议特征最好一次加1-2两个，加特征实际上是有成本的，尽量避免一次性进行大批量的特征加入。

position bias

推荐列表上不同位置的点击率天然有差别，我们在做排序时，需要考虑到这种差别。因为position是排序之后确定的，因此在预测时是不知道的，一般的做法是在训练时加入position信息作为特征，在预测时给position一个默认值，以达到消除position偏置的效果。一开始我们也是按照这个思路去做的，在预测时尝试给过多个默认position，但是在线上实验时，效果总是不及baseline。后来无意中看到Google的Rules of Machine Learning- Best Practices for ML Engineering一文中有关positional feature的rule才恍然大悟，原文引用如下，希望对在研究position bias相关内容的同行有所帮助：

Note that it is important to keep any positional features somewhat separate from the rest of the model because of this asymmetry between training and testing. Having the model be the sum of a function of the positional features and a function of the rest of the features is ideal. For example, don’t cross the positional features with any document feature.

也即在使用位置特征的时候需要保证位置特征和其他特征相互独立，而不论FM还是NN模型中位置特征和其他特征都有交互，因此线上效果一直不符合预期。受此启发我们重新调整了模型之后上线效果和base比上下小幅波动，基本持平，之所以没有预期的提升，我们认为在我们的场景中position bias的影响并不大。

06. 模型serving

tf-serving

tf serving这块没有太多可说的，部署也很方便，直接用docker去安装就可以了，非常简单。稍微不同的地方是我们对它做了一点包装，给tf serving集成到了consul，以方便模型预测服务的微服务化。由于tf 模型内存消耗大，我们模型更新的时候不是热加载的，模型更新过程中模型服务会中断，这个时候系统会先把要更新的模型实例从consul上解除服务注册，等到模型更新完成后重新注册到consul上，然后继续提供模型预测服务。考虑到流量问题我们模型的更新是一台一台依次更新的。

online feature

网上很少有人介绍模型预测部分线上特征的构造，大体上基于tensorflow的模型在预测阶段有两大方案：

• 所有特征提取、构造的代码写成op，打到模型文件里。这种方案输入模型预估服务的一般是原始文本/数值特征，特征的提取转换都发生在预估服务中，也就是tensorflow serving帮我们完成特征提取/转换的工作。
• 特征的提取和构造单独抽出来，作为一个服务，客户端先请求特征服务，由特征服务构造特征并请求模型预估服务。这种方案下特征处理在模型外部，输入到模型的是处理好的数值特征。

两个方案各有优缺点，方案一更直观一些，缺点是需要单独编写op，还需要保证特征一致性，另外在预测服务机器资源紧张时大量特征构造会拖累模型inference的速速。方案二流程上更繁琐一些，需要把特征构造抽象出来单独作为一个微服务，但好处是可以减轻tensorflow serving的压力，另外可以在特征服务上做针对性缓存进一步提升特征提取的速度，减少大量重复计算。

我们经过反复考量最终选择了方案二，采用方案二后调整特征不需要重写op，也更容易保证线上下线特征的一致性，模型与特征分离，线上特征提取和落特征日志可以更灵活和方便，这些优势给我们带来了很大便利，让我们后期各种模型迭代能很快地进行。

07. 总结

在深度学习火热的大背景下，各个公司都在着力于如何用深度学习模型来提高自己的业务指标，快报作为导购领域的领头羊也借鉴了大量业界先进思想和模型，尝试了许多种不同的排序模型，最终磕磕绊绊在业务上取得了相当不错的成绩。但我们模型演进的路径却不太一样，我们最终借鉴了一些其他模型的思想构建了一个非典型性的神经网络，在这中间最大的感想就是在不同阶段不同场景需要找到适合的模型，模型本身没有高下之分，重点还在于如何应用，而这需要长期的业务经验的积累。

今天的分享就到这里，谢谢大家。

团队介绍：

省钱快报算法团队 负责省钱快报 推荐、搜索 等业务的 支持 和 效果提升。致力于打造一个面向业务的高效召回和排序算法平台，能够在业务形态多变和新业务不断开展的情况下，快速灵活的支持业务，持续优化底层召回排序策略和算法。在重视算法的同时，同样重视策略、数据和工程体系，积极跟进业内最新的成果，面向业务做契合业务的实践和创新。

参考资料：

[1] Factorization Machines

[2] DeepFM: A Factorization-Machine based Neural Network for CTR Prediction

[3] Deep & Cross Network for Ad Click Predictions

[4] xDeepFM: Combining Explicit and Implicit Feature Interactions for Recommender Systems

[5] Deep Interest Network for Click-Through Rate Prediction

[6] Deep Interest Evolution Network for Click-Through Rate Prediction

[7] Entire Space Multi-Task Model: An Effective Approach for Estimating Post-Click Conversion Rate

[8] Deep Neural Networks for YouTube Recommendations

[9] Rules of Machine Learning- Best Practices for ML Engineering

[10] PAL: A Position-bias Aware Learning Framework for CTR Prediction in Live Recommender Systems

[11] BPR: Bayesian personalized ranking from implicit feedback

本文来自 DataFunTalk