‍♀️ 编者按：本文是支付宝体会科技沙龙第 3 期-走进蚂蚁端智能技能回忆系列文章。作者是蚂蚁集团研制工程师南烽，介绍了蚂蚁千 X 千模技能（包括千人千模、千机千模等）的适用场景，以及在蚂蚁端智能中，千 X 千模从模型研制、模型发布、线上监控等各个环节的技能计划，和在一些实践事务中获得的阶段进展。

点击查看回忆视频>>

布景介绍

传统模型运用方法-千人千面

在介绍千X千模之前，先来举个比方，用传统的办法，咱们是怎么运用模型，对不同的用户进行猜测的。

比方咱们想要猜测小明晚上会挑选吃什么，是会吃米饭呢、还是面条呢、还是饺子。那咱们会怎么做，第一步去挑选一些可以对猜测成果有协助的特征，比方小明老家是哪里的，要是在西安或许喜欢吃面的概率会大一些，也会加入一些节气的信息，比方当天立冬，那吃饺子的概率也会添加一些。

有了特征之后，就需求结构一些练习样本，比方调查1万个用户，老家是哪里的、今日是什么日子作为特征，以及他今日吃的是什么作为标签。有了这些信息，就可以练习一个模型了，让模型去猜测小明晚上会吃什么。

清楚明了，这儿是怎么猜测每个用户呢，便是经过提取到的特征的差异，去猜测出不同的成果。咱们一般把这种形式叫做千人千面。这种形式在云智能里是得到广泛运用的，也得到了很不错的作用。关于端智能来讲，最开始也是选用的这种形式，但在运转的进程傍边，咱们也发现了一些问题。

问题1：机型算力差异

第一个问题，便是机型算力的差异。比较于服务端的布置环境来说，端智能的状况会更杂乱。

先来看下服务端的模型布置方法。服务端的模型都会布置在服务器里，虽然有的布置在物理机、有的在虚拟机、有的在容器中，但关于同一个模型来讲，布置的环境和介质根本都是共同的，也便是模型在各个容器中运转的功能是根本共同的。别的，假如当咱们发现模型运转时刻偏长，并发量又比较高的时分，现有的服务器资源现已不能满意事务的诉求的时分，咱们也可以选用添加一些服务器资源的方法来抗住。

可是在端上，就费事的多。一个是用户手机的功能参差不齐，支付宝的用户覆盖规划很广，运用的手机的算力也都不尽相同，有运用本年最新款旗舰机的用户，也有两三年没有替换手机，那手机的算力差异是很大的。可以看下右边的四张图片，是咱们计算的线上模型的实践运转耗时，可以看到，同一个模型，在不同手机里，运算耗时的分布差异还是很大的。别的，关于一些运转的慢的手机，咱们也不能像服务端相同去扩容，所以关于这种状况，算法同学选用的更多的办法，便是去调整模型的杂乱度，把模型做的更简单，去进步履行的成功率，但也就会带来一个问题，便是模型的精度会有所下降。

问题2：人群特征差异

除了算力的差异，还会存在人群特征的差异。这个问题其实是端智能和云智能都会遇到的。

在练习模型的时分，会运用一切的数据作为练习样本。模型在练习的时分，会朝着大局最优的方向去查找模型的参数。这儿咱们展开来剖析一下。关于一些高频的用户，会贡献出更多的练习样本，那模型在练习的时分，就会更倾向于这些用户，因为这些用户在实践的事务成果中，也会有更高的权重。可是关于一些低频乃至长尾的用户，他们的行为有或许是和高频用户不共同的，可是在模型查找大局最优解的时分，就会必定程度上疏忽模型在这些用户身上的体现，也便是会呈现马太效应。

千X千模

解题思路

针关于以上的这两个问题，介绍下咱们的解题思路，也便是咱们常说的千机千模、千人千模。

关于客户端算力的差异，咱们会思考，怎么让高端机发挥出更大的算力才能，一同也让低端机也可以去运转一些模型。那说到这解法就比较显着了，便是咱们准备一组模型，有杂乱的、也有简单的，让高端机去跑杂乱模型，拿到更好的模型猜测成果，让低端机去跑简单模型，确保模型的履行成功率，也便是按照算力，去分配不同杂乱度的模型。

关于人群的差异，现在有一个词比较流行，叫“精细化”，这个词和千人千模的思路也是比较符合的。针关于用户的特点，咱们可以对用户进行聚类，将相似的用户聚到一同，去针对这个人群，独自去练习一个模型，那这个模型对这个人群的描绘，肯定会强于大局模型对这个用户的描绘。所以咱们在给用户发布模型的时分，也会根据用户所在的人群，去匹配对应的模型。

千机千模和千人千模分别解决了算力和人群的差异问题，咱们自然而然就会有一个思路，是不是可以将这两者结合起来，一同解决算力和人群的差异问题，除此之外，蚂蚁端智能还有一些其他维度的“千模”，咱们将这些一致称之为千X千模。

千X千模工程链路升级

从单模型做到千模型，是不是只需求把1个模型复制1000遍就可以了呢，实践的生产进程远没有这么简单。由1到1000，会对两个环节产生应战，一个是离线研制阶段，一个是线上发布阶段。

先来看离线研制。在做千X千模之前，咱们的离线研制主要以手动为主，从模型练习、到xnn转换、再到git打包、真机评测，都需求手动来完成，并且需求在三四个渠道之间来回跳转和传输数据。当只要一个模型的时分，咱们觉着效率还好，10分钟左右就可以完成悉数的流程，可是当模型变成1000个，假如还是依靠手动来做，那就可不接受了。所以在离线研制阶段，咱们做了全链路的升级，将多个渠道打通，串联起相关的流程，主动的完成离线的一切准备工作。除此之外，与单模型比较，千X千模在离线研制阶段，还需求多产生两份数据，一个是人群库，另一个是设备库，用于在用户拉取模型时，判断用户到底需求拉取的是哪个模型。

前面也提到过，千人千模的这个问题不止在端智能中会遇到，在云智能中，也会有同样的问题，并且云智能的发展远远早于端智能，但为什么云智能没有去解决这个问题呢。咱们知道服务端的模型布置方法是依靠服务器的提前布置的，所以当模型数量从1个变为1000个的时分，对服务端模型的布置速度、资源的运用率都会带来很大的应战，乃至所以无法完成的。可是关于端智能来讲，虽然大局看模型数量从1变为1000，可是关于用户来讲，只会拉取到一个模型，所以对端的运转时来讲，杂乱度没有显着的添加，更多的难点在于云上怎么去准确的发布模型。

端智能一致发布链路升级

接下来介绍下发布阶段的工程完成进程。蚂蚁端智能的发布也是阅历的两个阶段，左面是第一阶段，是在蚂蚁端智能刚起步的时分，咱们选用的技能计划。这儿需求说一个条件，蚂蚁对线上故障的重视程度是很高的，也有规范的流程把控，以及相关的配套才能。一切线上改变，都需求严厉的遵循三板斧准则，也便是可监控、可灰度、可回滚。关于客户端的发布，会有客户端装备中心来承当这个责任，这个链路具有完好的三板斧才能，并且在发生稳定性危险的时分，可以主动的对改变进行熔断，快速止血。所以端智能最开始直接复用了这个链路，可以让事务快速的跑起来

跟着端智能事务规划的发展，咱们也遇到了一些问题： 第一点，千X千模的发布，客户端装备的计划无法支持。客户端装备是根据规矩做的发布，比方根据品牌、机型、操作系统、版本号等等，但千X千模是需求根据每个用户的维度独自计算； 第二点，客户端装备作为一个支付宝APP的根底服务，在日常以及大促阶段都是需求高保的，但端智能的场景，对发布的时效性和到达率的要求并没有那么高，导致客户端装备需求更多的资源来保证端智能事务，这其实是不需求的； 第三点，客户端装备是有装备巨细的约束的，而端智能的发布任务，经常会有比较大的数据传输，很简单就超过了约束巨细。

所以根据以上的问题，咱们对端智能的一致发布进行了链路升级，选用二阶段的办法来完成。先运用客户端装备通道完善的三板斧才能，将端智能的装备ID下发下去，端智能再根据ID信息，重新计算和拉取真正需求用的装备内容。这样虽然多了一次网络请求，可是可以完美的解决上面提到的这三个问题。

千X千模的应战

在做千X千模的时分，也会遇到一些问题，挑几个典型的来说一下：

1. 是不是模型数量越多，作用越好。 最开始咱们的主意是这样的，所以模型数量做的比较多，但实践的状况来看，跟着模型数量的添加，作用并不必定会增加，乃至递减。剖析原因，或许是由于某些人群的样本不行丰富，导致过拟合的状况

2. 千机千模里，模型与设备算力怎么相关呢？ 算力是一个自定义的目标，主要是由硬件来决定的。所以咱们会在离线经过真机测试的方法，对设备进行分级，用于线上的匹配 当然，关于同一个手机，在不同的运转环境下，所能提供的算力也是有差别的。所以未来咱们也会根据线上的运转数据，乃至手机当时的运转环境，去做动态的千机千模

3. 上线后，怎么才能发现有问题的模型呢？ 咱们选用的计划是在线上做圈人试验，监控各个模型的线上体现，发现作用较差的模型的话，会将这个模型替换掉

事务成果

最终看一下千X千模给事务带来的协助。

事务1运用的是千人千模，这个事务在20年的时分开始运用端智能，经过了2年的时刻，目标从92.5提高到了94.6，也达到了一个瓶颈。在今日升级到千X千模的形式，从离线剖析看，绝对值又提高了1个百分点，最近看了下线上的目标，会有1.5个百分点的提高，作用还是很显着的。

事务2运用的是千机千模的才能，在之前为了确保线上模型的履行成功率，是能运用最小的模型，准确率只要85.7，经过对机型进行分级，可以对部分设备下发更大的模型，模型的体现也有必定的提高。