企业推荐系统里有两个关键词，一个是企业。企业关心的是怎样降低成本，怎样满足自身业务需求，但对开发者来说，引擎或者算法开发，关心的是能不能满足算法的需求，能不能有技术满足先进性，在开发平台是跟上百家的客户做了深度的交流研发出来的平台。还会分享两个部分，一个是EasyRecTorch版本，就是 GPU版本的算法框架，另外一个是FeatureStore，是特征工程管理的一个框架。今天的分享分成了4个部分，第一个部分推荐系统面临的挑战，推荐系统的挑战非常复杂。第二个是解决方案。第三个部分是算法框架。第四个部分有推理，怎样去完成高性能的推理，例如一个 QPS ，或者是请求高时，广告系统要做推荐打分时，成本是非常高的，怎样去解决这个问题。第四是如何管理这些特征，要做算法的迭代。
一、推荐系统面临的挑战
推荐有非常多的问题，最核心的是推荐的引擎，第二个是推荐的算法，围绕算法上游是需要各种数据的输入，所以数据是不是正确，数据治理的问题。实验的数据是不是真实有效，中间有没有问题？引擎怎样快速把推荐的流程，召回排序、过滤的流程串起来，中间提供了一系列的数据推荐系统排查的工具，有这个系统后怎样去把问题解决，推荐引擎的离线和在线实时架构映射到阿里云的产品上，再看一下刚才说的MaxCompute和dataworks。数据是放在MaxCompute的里，代码是放在dataworks，这里的代码不需要开发者从头开始手写代码，核心是通过推荐算法定制来产出代码，自动生成代码，通过 PAI 平台来训练模型，这里有传统的机械学习模型或者向量召回的模型，模型打分放在推荐打分服务里，这里后面讲打分服务器，这个是用c++做了很多优化，作为高性能。召回引擎是可以用各种各样的数据库都可以，比如hologres，Redis等等。核心的引擎是怎样串起来召回曝光过滤出传统的推荐引擎的链路，一般的推荐系统肯定都会需要 AB 服务，这里也集成了自己的 AB服务，最后FeatureStore管理特征、实施行为。
要做各种算法迭代时，特征管理不可能只上一次,特征会不断的迭代，运营可能某个月加了特征，下个月又加了特征，所以需要一个平台来管理迭代。
现在来看在线学习的系统，在线学习主要看数据流，有实时的曝光点击的行为样本，然后通过 flink 回流回来后，然后再和FeatureStore管理实时的特征，离线的特征，用户序列特征，join 成流失的样本。
在MaxCompute的平台上做模型的在线训练，训练好后增量保存，在推荐引擎在打分时就用新的模型打分，可以做业务广告业务或者新闻咨询业务、小视频直播，行为变化非常快的事物。
接下来看怎样解决这个问题。是从20年就开始思考怎么去做，也集成了一些阿里内部的平台的经验，例如大家可能知道的TPP。
开始是想怎样去算法将它配置化，不希望每次开发一个新的算法，都要从头开发，改它的特征模型就可以完成一个新的算法。要扩展时也希望改配置文件，自动生成模型的结构，算法和引擎都可以配置化后，再向整个系统，只需要输入用户的表、用户特征、物品特征，行为，就可以定制，推荐算法定制出召回排序的整个流程，特征存在哪里，就流向哪里，在系统里配置即可完成产出。
在后面不断的完善22年、23年，不断完善相关的功能。到24年时，目前已经完善的差不多。还有今天想说的EasyRecTorch版本，这是全新从训练推理的解决方案。在PAI-Rec的能力是分成了几个部分，这个是一个pass平台，更多面向的是开发者，但对开发者的技术能力、起步的要求不高，对接的产品多，希望这个产品能够帮助开发者不断的提高技术能力。
二、如何解决推荐系统开发效率的问题
第一部分是系统的搭建和部署，要对接开通很多阿里云的产品，定制会一步步向导通过配置静态表或者实质行为表，然后产出代码，这个代码看到中间的这个部分。产出的代码和隐形部署基本上是一一对应的，产出出来的召回会在引擎里去部署，产出的模型有个金牌的模型可以对接，产出的代码引擎对接好了后，配置实验，看上线，报表后场景的迭代满足运营的需求。
接下来看在PAI-Rec的视角下产品有哪些功能。主要是有6个步骤，6个步骤是不断循环的，建一个推荐场景，例如首页的猜你喜欢，先做数据诊断，看数据是否正确，定制出代码，将这个代码部署在 dataworks ，dataworks 提供 openAPI ，直接把代码部署上去。在这个代码上去做修改，把产出的数据模型，例如用户特征，排序模型，金牌模型、召回模型通过 PAI-Rec引擎对接好，对接好后去看排查工具、去看推荐出来的东西和用户是否相关，例如最近在看衣服，推荐出来的是否与衣服匹配。再去对接实验平台时，最后用运营去干预，再去看实验的报表，再不断的迭代，查看点击率是否、转化率有问题或者是人均的 gmv 有问题。通过这个循环的不断迭代后，可以建设一个更好的推荐系统。
更核心的推荐算法定制对接的流程。这里核心的MAXCompute 标准表有三个表，用户、物品和行为表，行为表可以是天际的表，也可以是实时的行为表。在定制后产出的代码，会对接到不同的地方，在PAI里做模型的训练，召回排序模型，在线学习训练，把产出的数据存储到规划室，把模型部署在PAI里，用户的特征、物品特征部署到特征平台，特征平台是通过视图来管理用户特征或者是物品的特征表，最后通过推荐引擎把整个链路串接起来，召回、曝光过滤，再做排序重排，整个流程后，推荐服务即可对外提供服务。
接下来看推荐定制，刚刚说了很多流程是怎样做的，实际上是能做到新的推荐场景，在数据没有问题的情况下，只需要花一周的时间即可建设首页的推荐场景，第一周是把基础数据做好，基础数据做数据诊断，哪些特征是可用的，训练的天数需要多少天。第二步推荐算法的定制配置。第三步，在线引擎里部署，最后第四周发布后，统计中间数据，统计实验报表，还有实验报表可以查看，指标可以自定义，将推荐系统周边的脏活累活干完，即可方便的做推荐的效果。
排查工具是一致性的检查，一致性是非常重要的，离线的效果是非常好的，算法的AUC都提高了，但是一上线发现效果不好，原因很大部分是查询某个用户特征没有取对，或者物品特征不对，或者实时特征是错误的。这时提供了一套工具把这些中间的数据在线的离线的数据都存起来，然后通过打分做对比，找出哪个特征可能是不一样的。
三、高性能推荐算法和推理服务
第一个框架在TensorFlow版本上已经推广很多年，也在github上面有很多关注。数据的输入可以有多种的，例如OSS、MaxCompute上面的输入数据，输入数据可能有各种在数据库里的格式，例如String、 int、float，怎样解释这些数据，可能是 ID 特征或者是组合特征，或者是现在推荐用的最多的序列特征。再看在一个深度的模型是哪些，最终预测时是要预测点击率还是转化率，又或者是时长，这些可以通过配置实现，也可以自己扩展算法，满足在dffm加一个模块，也可以自己加入。训练主要是 PS 架构的， PS 架构TensorFlow本身有问题，所以在PAI-TF上做了优化，也提供了功能，特征模型蒸馏的，例如要通过金牌模型蒸馏出一个初排的模型，可以把召回的候选集扩得更大。
在推理时，做 GPU 和 CPU 的优化，算子融合的优化，所以在这里强调推理时速度提升了大约三倍。
离线做好的特征是一个用户或者是物品特征，用户到推荐场景召回一堆东西，不知道用户的候选集是什么，所以组合特征就是用户和候选的特征，要通过 FG 实时组合算出来。这里提供了组合的特征生成器做特征变换，特征变换离线和在线其实是做了同样一套的 C++ 代码来实现。简单说做一个 LOOKUP ,做一个交叉的特征或者离散化，同样的组合特征做一个组合。
再看推理服务时，是高性能打分服务做了优化。首先是工程管理，特征工程把物品的特征都cash在本地，比如有500个万个物品，把它放在这，用户在请求时，推荐引擎请求，只需要把用户特征传进来，然后在这里这两部分去做特征的转换拼接，比如说有1000个候选，展开成1000个候选的特征，然后再去模型进行推理打分。召回有向量召回的模型，也需要部署在这里，金牌和出牌的模型也是部署在这个地方。
接下来看算法部分。在今天之后会开源torch版本的开发框架，原来可能需要10分钟训练，但是用了 GPO 训练后只需要一分钟。因为在推荐里用了非常多的 ID 特征，在 CPU 情况下训练，TensorFlow天生的就没法去做大量的并行化，但在用TorchRec版本时，做了很多 GPU 的优化，因为不是传统的 PS 架构，通信快了很多。这里还做了比较核心的改造，是把特征的表达和特征变化写在这，只需要在这描述一次，然后在训练时和推理时都会同样用这个特征变换去做在线服务。管理也做了优化，会比TorchRec默认的管理的效率更高。数据特征模型提供了使用较多的模型。
FG 的是做了更多的优化推出V2的版本。增加了分词，分词是文本相关性、做文本相关推荐时非常重要，然后是复杂的类型。以前存序列特征是用字符串来存储，现在用复杂的类型来存储的话，效率就会高非常多。整个从MaxCompute的，是可以支持map和area的存储，然后将它取出来，再到训练推理时，保证它的类型是不变的。中间不需要做复杂的反序列化，性能提高非常多。
刚才讲了推理性能，这里做了训练速度的测试，所以训练速度基本上提高了9倍左右。以前每天只能增量训练一个模型，增量训练模型的效果会下降，但提升了性能后，每天还是训练两个小时，但是可以用全量30天的数据全量的训练，效果就不会衰减。当然也可以有一次跟原来做增量的训练，增量训练可以用更节约的成本，提高了训练速度后，成本可能只有原来的1/3~1/5左右。
四、高效特征管理
最后一部分是特征平台部分，特征平台在平台里是如何使用的，特征里有user和item两个部分，user和item是两个实体，然后每个实体可以有很多特征视图，特征视图不是一次性做好，最开始上模型时只有离线的特征，逐渐的增加实时的特征视图，或者运营想起时再加。特征管理离线管理好后可以导出样本，发布到在线系统里，例如Hologres、TableStore，PAI-FeatureStore，PAI-FeatureStore内置的一个存储叫Feature DB , PAI-Rec引擎里只是去读用户的特征，通过FeatureStore，SDK去读，这里要强调一下，整个系统其实可以拆分使用。可以只用Erec算法框架，推荐算法的定制可以拆开不用，或者是免费的直接使用算法框架即可。
推理服务也可以使用，可以跨云跨网络的，也有客户在其他的云，自己的机房，把打分服务也就是金牌服务打到这做推理，因为提供推理的性能更好，模型的效果也更好，成本更低，因此把打分服务迁上来。
再看一下 PAI FeatureStore 的架构， PAI FeatureStore 其中一个是对离线数据特征，另外一个是实时处理特征，数据都是从实时数据回流回来，例如DataHub ，看如何使用，是每天算一次，或者是每分钟、每小时都去算。算完后通过 FeatureStore 的 SDK 存到系统里，工程链路是复杂的，提供了各种 SDK ，不仅PAI-Rec可以管理用到这些特征，还可以提供例如 java 的 SDK 可以在java 系统里把 FeatureStore 集成进来，可以取用户特征或者取物品特征来组装，然后打分。
Feature DB 的实时特征电路，就是 Feature DB 是在 PAI-FeatureStore 里内置的存储，刚才在 E-Rec版本的时介绍了需要训练模型怎样性能高，要存储做一些配合，需要把 area和 map的数据，需要存储在 Feature DB 里，用户的序列特征，链路是用户需要把实时的行为需要写进来，写进来这里会存储后放到 Feature DB 里。序列特征就是行为序列，这里简化了。推荐引擎只是去读序列特征，推理的时候用上。序列特征还有个复杂问题，访问的物品序列只是一堆的 ID 序列，例如看了100个商品，但是100个商品在模型推理时，还要带上例如价格内幕，或者品牌型号东西，这些东西都是在 E-Rec-pression里 Feature SDK 里去组合好这些特征，然后再去做打分，所以 SDK 就把细节给隐藏在内部，大大减少了工作量。
最后提供了一FeatureStore 的生产的 SDK ，是把推荐算法定制里产出特征的核心的功能将它抽离出来变成开放的 SDK ，只需要去注册特征的定义，比如说特征是用户一天的曝光的次数，统计曝光的次数，事件统计或者窗口统计特征，假如要统计30天的特征，每次都拿30天的数据来计算，非常消耗资源，所以在这里把中间数据自动扩展，自动去做增量统计的功能都包含，自动会产出中间表，最后可以调度执行，可以大大的节约计算的资源。如果每天有几千万的曝光或者上亿的曝光时，资源节省量是比较大的。算出来的特征可以注册在 FeatureStore 里，可以跟刚才的 FG 做对接,FeatureStore 可以使用，整个的流程可以串起来。
综上所述，介绍了两个内容，一个是推荐算法、开发平台PAI-Rec ，核心功能就是推荐算法定制，然后发布了E-Rec-Torch版本的开源框架，然后还有一个 PAI FeatureStore 的特征平台管理的工具。
