简介：如何通过机器学习 PAI 实现疾速构建举荐模型
作者：程孟力 – 机器学习 PAI 团队
随着挪动 app 的遍及，个性化举荐和广告成为很多 app 不可或缺的一部分。他们在改善用户体验和晋升 app 的收益方面带来了微小的晋升。深度学习在搜广推畛域的利用也曾经十分深刻，并且给各种场景的成果带来了微小的晋升。针对举荐流程的各个阶段，业界曾经有很多的模型，这些模型大部分也有开源的实现，然而这些实现通常散落在 github 的各个角落，其数据处理和特色结构的形式各有差别。如果咱们想要在一个新的场景外面利用这些模型，通常须要做比拟多的改变:
- 输出的革新，开源的实现的输出格局和特色结构通常和线上不统一，适配一个算法通常须要 1 - 2 周左右的工夫，还不免因为对代码的不相熟引入 bug，如果要尝试 5 个算法的话，就须要 5 倍的革新工夫。如果算法资源无限，这时候是不是就要忍痛割爱，放弃一些可能有成果的尝试了?
- 开源的实现很多只是在公开数据集上获得了比拟好的成果，在公开数据集上的最优参数也不肯定适宜理论的场景，因而参数调优也须要较大的工作量；有时候成果不好，并不是因为办法不行，而是选的参数不太好。如果没有系统化的调参办法，很多算法也就是简略试一下，没有 deep explore，哪来对算法的深刻了解呢? 为什么看似简略的改良，你没有可能发现呢? 为什么你也尝试了相似的方向，然而没有搞进去成果呢? 成果通常都是用算力和数不尽的尝试堆进去的；
- 开源的实现用的是 tensorflow 1.4，而线上用的 tensorflow 2.3，好多函数的参数都变掉了(此处心里是不是想骂 google 一百遍，当初山盟海誓说好的 api 不再变呢); 很多开源的实现因为没有在理论场景中验证过，所以其可靠性也是存疑的，可能就会少了个 dropout，少了一个 bn，成果相差甚远；
- 费了九牛二虎之力把模型成果调好了，发现上线也会有很多问题，比方训练速度太慢、内存占用太大、推理 qps 跟不上、离线成果好在线成果跪等等。遇到这么多问题，你还有精力去做你的下一个 idea 吗？你还能斗志昂扬，坚定不移的去摸索新方向吗?
这些问题搞得咱们爱莫能助、天天加班到深夜、不知何时是个头：想要验证一个简略的 idea 都要使出九牛二虎之力。所谓天下文治，唯快不破，对于搜广推畛域的算法同学来说，尤其如此：通过疾速迭代能力验证更多的想法，发现更多的问题，找出最优的特色和模型构造。速度慢了的话，可能你的模型还没调好，业务指标就变了，前端的布局也改了，你的业务方可能都不置信你了，你也就没机会上线了。
说到这里，咱们的诉求就比拟明确了，咱们就是想少写代码，甚至不写代码就能验证咱们的想法。针对这些问题和诉求，咱们推出一个全新的、一步到位的举荐建模框架，致力于帮忙大家解决在举荐建模、特色结构、参数调优、部署等方面的问题，让大家少写代码，少干反复的没有意义的脏活累活(这些 EasyRec 都承包了)，少趟一些坑少踩一些雷(这些 EasyRec 都替你趟了)，让大家可能疾速上线验证新的 idea，晋升举荐模型的迭代效率。
劣势
和其余建模框架相比，EasyRec 在以下几个方面具备显著的劣势:
- 反对多平台和多数据源训练
- 反对的平台包含: MaxCompute(原 ODPS), DataScience(基于 Kubernete), DLC(deep learning container), Alink, 本地;
- 反对的数据源包含: OSS, HDFS, HIVE, MaxCompute Table, Kafka, Datahub;
- 用户通常只须要定义本人的模型，在本地测试通过后，就能够在多种分布式平台上进行训练;
- 反对多种 Tensorflow 版本(>=1.12, <=2.4, PAI-TF)，可能无缝的对接用户的环境，不须要对代码做迁徙和改变;
- 反对支流的特色工程的实现，特地是显示穿插特色，可能显著得晋升成果;
- 反对 HPO 主动调参，显著升高了用户的调参工作量，并在多个场景中晋升了模型成果;
- 实现了支流的深度模型，笼罩召回、排序、粗排、重排、多指标、多趣味等;
- 反对 EarlyStop, BestExport, 特色重要性，特征选择、模型蒸馏等高级性能。
架构
EasyRec 建模框架整体上是基于 Estimator 的数据并行训练形式，通过 Parameter Server 的构造反对多机多卡的训练。EasyRec 的次要模块包含输出、特色结构、深度模型、Loss 和 Metric，每个模块都能够自定义。针对用户在用 TF 进行训练可能遇到的多种问题，如 worker 退出失败、应用 num_epoch evaluator 无奈退出、auc 计算不精确等，EasyRec 做了深度优化。针对 AdamOptimizer 训练速度慢，异步训练慢机，hash 抵触，大样本空间负采样等问题，EasyRec 联合 PAI TF(PAI 优化过的 tensorflow)和 AliGraph 也做了深度优化。
模型
EasyRec 内置了业界先进的深度学习模型, 笼罩了举荐全链路的需要，包含召回、粗排、排序、重排、多指标、冷启动等。
同时 EasyRec 也反对用户自定义模型。如下所示，在 EasyRec 外面实现自定义模型，只须要定义模型构造、Loss、Metric 三个局部，数据处理和特色工程是能够间接复用框架提供的能力的，因而可能显著节俭用户的建模工夫和老本，可能将精力 focus 在模型构造的摸索上。针对常见的模型类型如 RankModel、MultiTaskModel 等，Loss 和 Metric 局部也能够间接复用父类的定义。
主动调参和主动特色工程
EasyRec 主动调参接入了 PAI automl 主动调参的能力，实现了对多种参数的主动调优。EasyRec 外面定义的任意参数都是能够搜寻的，常见的参数包含 hash_bucket_size, embedding_dim, learning_rate，dropout, batch_norm, 特征选择等。当你对某些参数拿不准时，就能够启动主动调参来帮忙你寻找最优的设置；通过主动寻优失去的参数通常会比拍脑袋设置的参数要好，有时候还会带来意外的惊喜。
特色工程通常是晋升举荐成果的要害，做高阶的特色组合通常有助于晋升模型成果，然而高阶组合的空间十分大，无脑组合会导致特色爆炸，连累训练和推理的速度。因而，EasyRec 引入了主动特色工程 (AutoFeature) 的能力，主动寻找有晋升的高阶特色，进一步晋升模型的成果。
搜寻后果(top5)：
模型部署
EasyRec 模型能够一键部署到 PAI EAS 环境，也能够通过 tf serving 部署。为了晋升 inference 性能，EasyRec 引入了 PAI Blade 的能力做 placement 优化，op fusion，子图去重等性能，通过上述优化 qps 晋升 30% 以上，rt 降落 50%。将来还将引入 FP16 的性能，进一步晋升 inference 性能，升高 memory 的耗费。为了反对超大规模的 Embedding，EasyRec 对大模型做了拆分和 op 替换，将 Embedding 存储到 Redis 等分布式缓存外面，冲破了内存的限度。从 Redis 获取 embedding 会比内存慢，通过对高频 id 进行 cache 等来升高对 redis 的拜访来晋升 embedding lookup 的速度。
特色一致性
特色工程是搜广推流程外面的要害局部，也通常是造成线上线下成果不统一的起因。为了可能在疾速迭代中放弃离线在线的一致性，通常采纳的办法是线上线下采纳同一套代码。离线训练数据的结构流程：首先结构 user feature(蕴含实时和离线两局部), item feature 和 context_feature，而后 join 上训练样本 (蕴含 label)，最初通过特色工程的 jar 包生成输出 EasyRec 的训练样本。上线的流程：将 user feature(离线局部) 和 item feature 导入 Redis、Hologres 等分布式存储，举荐引擎依据 user_id 和 item_id 去查问对应的特色，调用特色工程的库进行加工之后，送入 EasyRec 模型预测。在线局部的实时特色通常是应用 blink、alink 等反对流式计算的平台来生成的，而离线局部的实时特色结构有两种形式：离线模仿和在线落特色。这两种形式各有优缺点：因为日志失落等问题，离线模仿通常会和线上有大量的不统一；在线落特色如果要减少新的特色通常要期待比拟长的工夫能力攒够样本。咱们的解决方案是在线将用户行为的序列落下来，而后离线通过雷同的 jar 包来加工出各种统计特色，如 1h/2h/../24h 的点击次数。
在线特色工程对计算效率要求比拟高，而计算量也比离线要大：离线计算的样本通常是 1 个 user 配对 m 个曝光的 item(召回模型的话，会减少一些随机采样的负样本), 而线上计算的样本是 1 个 user 配对 n 个 item(n>>m)。在线计算如果采纳 naive 的计算形式，将一次申请开展成 n 个样本别离进行计算，效率通常是跟不上的。不难发现其中 user feature 的局部做了比拟多的反复计算，对 user feature 做计算效率的优化，可能显著晋升线上的 qps。咱们联合淘系外部应用的 Feature Generation 模块做了深度优化，包含内存调配、字符串解析、反复计算打消、多线程并行计算等，在保障一致性的前提下，显著进步了计算的效率。
增量训练和实时训练
增量训练通常可能带来成果的显著晋升，起因在于增量训练见过了更多的样本，对 embeding 局部训练的更加充沛。EasyRec 反对从上一天的 checkpoint restore，而后在新的一天的数据上持续训练。为了疾速适应新闻、节假日、大促等场景的样本分布产生疾速变动的场景，咱们提供了对实时训练的反对。EasyRec 通过 Blink 来结构实时样本和特色，并调用 Feature Generation 对特色进行加工，而后通过 Kafka、DataHub 读取实时的样本流进行训练。实时训练的稳定性比拟重要，咱们在训练过程中对正负样本比、特色的散布、模型的 auc 等做实时的监控，当样本和特色的散布变动超过阈值时，报警并进行更新模型。保留 checkpoint 时，EasyRec 会同步记录以后训练的 offsets(多个 worker 一起训练时，会有多个 offset)，当零碎产生故障重启时，会从保留的 offsets 复原训练。
成果验证
EasyRec 在多个用户场景 (20+) 中失去了验证，场景中包含商品举荐、信息流广告、社交媒体、直播、视频举荐等。以下是局部客户在他们场景中应用 EasyRec 获得的晋升:
- 某 APP 广告推送: AUC 晋升 1 个点，线上 ctr 晋升 4%，资源耗费升高一半;
- 某大型直播 APP: 基于 EasyRec MultiTower 模型 AUC 晋升 2%；
- 某大型社交媒体: 基于 EasyRec MultiTower 模型 AUC 晋升 6%，线上成果晋升 50%；
- 某大型电商平台：基于 Easyrec DSSM 模型，线上 UV 价值晋升 11%, UVCTR 晋升 4%;
- 某短视频 APP：基于 EasyRec DBMTL 模型，线上时长晋升 30%，+ 多模态特色进一步晋升 10%。
最初，EasyRec 曾经通过 github 开源
(https://github.com/alibaba/Ea…)，在此欢送各位同路人共建，包含：丰盛各个场景的特色结构，引入更多在理论场景中验证过的模型，晋升模型离线在线推理的性能，等等。在这个日益内卷的行业(能够设想 tensorflow 为什么越做越差，跟内卷应该关系十分大，api 的批改比拟随便、存在适度设计扩大艰难的问题、bug 层出不穷，天下苦 TF 久矣)，咱们心愿可能通过这样一个开源的工作，造成大家的合力，照亮咱们独特的路。在这里，咱们也像前辈 xgboost 致敬，心愿这个工作可能像 xgboost 一样发扬光大，影响深远。
原文链接
本文为阿里云原创内容，未经容许不得转载。