在推荐场景会遇到数据二八分布的问题，20%的场景应用80%的样本，这就导致一个问题：单模型对大场景预估更友好。如何兼顾各场景，提升模型个性化能力是个性化建模的痛点。
业界方案：
针对业界模型存在的问题，我们提出了如下解决思路：
整体思路是利用元学习在云端为每一个用户部署一套个性化模型参数，最终达到对成本和性能没有损失的效果。
元学习指的是学习到通用知识来指导新任务的算法，使得网络具有快速的学习能力。例如：上图中的分类任务：猫和鸟、花朵和自行车，我们将这种分类任务定义成K-shortN-class的分类任务，希望通过元学习，学习到分类知识。在预估finetune过程，我们希望对于狗和水獭这样的分类任务，用很少的样本，进行微调就能得到极致的预估效果。再举一例，我们在学习四则混合运算时，先学习加减，后学习乘除，当这两个知识掌握了，我们就能够学习这两个知识融在一起如何来算，对于加减乘除混合运算，我们并不是分开来算，而是在加减乘除的基础上，学习先乘除后加减的运算规则，再用一些样本来训练这个规则，以便快速了解这个规则，以至于在新的预估数据上得到比较好的效果。元学习的思路与此类似。
元学习有三种分类：
Model-AgnosticMeta-Learning(MAML)是与模型结构无关的算法，适合通用化，分为两部分：meta-train和finetune。
meta-train有一个初始化θ，进行两次采样，场景采样和场内样本采样。第一步，场景采样在这一轮采样过程中，全体样本有十万甚至上百万的task，会从上百万的task中采样出n个task；第二步，在每个场景上，为这个场景采样batchsize个样本，把batchsize个样本分为两部分，一部分是SupportSet，另一部分是QuerySet；用SupportSet使用随机梯度下降法更新每个场景的θ；第三步，再用QuerySet为每个场景计算loss；第四步，把所有的loss相加，梯度回传给θ；整体进行多轮计算，直到满足终止条件。其中，SupportSet可以理解为训练集合，QuerySet理解为validation集合。
将元学习算法应用在工业化的场景中会有比较大的挑战：元学习算法的meta-train过程涉及到两次采样，场景采样和样本采样。对于样本而言，需要把样本组织好，同时按照场景的顺序存储下来并进行处理，同时需要一个字典表来存储样本和场景的对应关系，这个过程十分消耗存储空间和计算性能，同时需要将样本放到worker中进行消费，这对工业化场景具有非常大的挑战。
我们有如下的解决方法：
首先在meta-train中实现batch内场景和样本的选择，每个batch内会有多条数据，每个数据属于一个task。在一个batch内，将这些数据按照task抽取出来，抽取出来的样本放到meta-train训练过程中，这样就解决了需要独立维护一套场景选择和样本选择的处理链路的问题。
通过实验调研以及阅读论文，我们发现，在fine-tune以及在元学习过程中，越接近预估层，对模型的预估效果影响越大，同时emb层对模型的预估效果影响较大，中间层对预估效果没有很大的影响。所以我们的思路是，元学习只选取离预估层较近的参数就可以，从成本上考虑，emb层会导致学习的成本增加，对emb层就不进行元学习的训练了。
整体训练过程，如上图中的mmoe的训练网络，我们对tower层的参数进行学习，其他场景的参数还是按照原始的训练方式来学习。以user为维度来进行样本的组织，每一个用户有自己的训练数据，把训练数据分为两部分，一部分是supportset，一部分是queryset。在supportset中，只学习local侧的内容进行towerupdate，进行参数训练；再用queryset数据对整体的网络进行loss计算后梯度回传，来更新整个网络的参数。
因此，整个训练过程是：整体网络原训练方式不变；元学习只学习核心网络；从成本方面考虑，embedding不参与元学习；loss=原loss+元loss；fintune时，把emb进行存储。serving过程，用emb微调核心网络，同时可用开关来控制元学习随开随关。
对于传统的样本存储方式，如果在serving过程，直接进行finetune，会存在较严重的问题：需要在线上维护一套样本存储链路；多套在线实验需要维护多套样本。同时，finetune过程，用原始样本进行finetune，样本要经过emb层、bottomlayers层以及meta-learning层，但是元学习在serving过程仅需要学习meta-learninglayers，不关心其他部分。我们考虑在serving过程，仅保存meta-learninginput存到模型中，这样就能节省样本链路的维护，同时达到一定的效果，如果只存emb这一部分，可节省该部分的计算成本和维护成本。
我们采用如下的方法：
这个模型在serving阶段，会使用embedding，embedding输入到bottomlayers，打分时，并不像原始的方式一样，而是通过meta-learninglayers拿到supportset中的数据，将该层的参数更新，使用更新后的参数进行打分。这个过程在GPU上无法进行计算，因此我们在CPU上执行该过程。同时，无量GPU推理做了AutoBatch合并，将多个请求进行合并，合并后的请求在GPU上进行计算，这样处理，梯度会随着batch的增加而变化，针对该问题，我们在batch和grad的基础上，增加一个num维度，计算梯度时，将grad进行相加，按照num进行处理后，保持梯度的稳定性。最终实现成本和性能可控，同时实现了千境千模。
元学习在双塔召回场景下的使用，是以用户为维度进行建模，包括user塔和item塔。模型的优点是：可插拔，无需改动样本和线上架构，稳定无风险；缺点是supportset是前一个小时的数据，存在实时性的问题。
元学习的另一个应用场景是在序列召回场景，该场景是以用户为场景来建模，以用户的行为序列作为supportset，用户行为序列只有正样本，我们会维护一个负样本队列，采样队列中样本做为负样本，并拼接上正样本作为supportset。这样做的好处是：实时性更强，成本更低。
最后，元学习也应用在排序场景中，如上图中的mmoe精排模型，实现方式有两种：仅使用finetune，以及同时使用meta-train和finetune。第二种实现方式效果更优。
元学习在不同的场景中都取得了较好的收益。
每个场景有多个推荐的入口，需要为每个场景都建立一套召回、粗排到精排的链路，成本较高。尤其小场景和中长尾流量数据稀疏，优化空间受限。我们能否将一个产品内相似推荐入口的样本、离线训练和在线服务融合成一套，达到节省成本并提升效果的目的。
如果将跨域的模型使用多任务模型，就会产生比较严重的问题，并不能拿到比较好的收益。
在腾讯实现跨场景建模具有较大挑战。首先在其他企业，两个场景的特征能够一一对应，但在腾讯的跨域推荐领域两个场景的特征无法对齐，一条样本只能属于一个场景，数据分布差异大，预估目标难对齐。
针对腾讯跨域推荐场景的个性化需求，采用上述方式进行处理。对于通用特征进行sharedembedding，场景个性化的特征自己独立embedding空间，在模型部分，有共享的expert和个性化的expert，所有的数据都会流入共享的expert，每个场景的样本会数据各自的个性化expert，通过个性化gate将共享expert和个性化expert融合，输入到tower，用star的方式来解决不同场景的目标稀疏的问题。对于expert部分，可以采用任意的模型结构，例如Sharebottom、MMoE、PLE，也可以是业务场景上的全模型结构。该方式的优点是：模型的通用性强，适合各类模型融合接入；由于可以直接将场景expert迁移，对原场景效果无损，实现跨场景知识迁移效果提升；融合后模型减小，训练速度提升，同时节省成本。
我们进行了通用化建设，红色部分是需要个性化接入的内容，例如：个性化特征、个性化模型结构等，用户只需写入个性化的代码即可。其他部分，我们已经将整套代码接入ModelZoo，可直接继承使用，并将其封装成机器学习平台工作流组件，可直接运行，该方式减少了多场景学习调研和接入成本。
跨域推荐可通过多种方式来使用。第一种，多场景单目标的模型结构，可直接使用多场景的建模架构，不建议使用tower侧的star；第二种，多场景多目标的融合，可直接使用多场景的建模框架；第三种，同一个精排产品，不同目标模型融合，可直接使用多场景建模框架，不建议使用tower侧的star；最后一种，同产品多个召回、粗排模型融合，目前正在进行中。