阿里定向广告新一代技术

分享嘉宾：周国睿 阿里 高级算法专家

编辑整理：崔媛媛

出品平台：DataFunTalk

导读： 本文的主题为新一代Rank技术，由来自阿里巴巴定向广告团队的周国睿老师分享，主要介绍当前团队在排序算法方面的新工作和新想法。

01 新一代Rank技术背景介绍

在分享之前先介绍下阿里巴巴整个淘系内部的定向广告形态。

1. 电商场景下定向广告形态

电商场景下定向广告的形态主要分为两种，一种是非商品主体的，比如首页焦点图上的Banner广告，主体可能是一个店铺，或者是一系列商品的集合页。另一种是以商品主体的，本身是商品的一种展示，这两种不同的广告形态，在定向广告业务中都存在，且各自扮演着重要的角色。广告显式展示给用户的内容主要是一些图片和文字，同时在系统内部广告是用账户体系ID来描述的，比如广告ID，Item ID，Shop ID等。排序系统中很重要的一件事的是预估在一个场景下给出用户和一个广告，以及用户对广告的操作反馈。

2. Delineate Rank

这里简单介绍一下我对Ranking问题的一个理解。Ranking特别是在电商场景下，要做的是生成一个有序的topk的最终展示结果，让展示结果是挑出的最好的集合，并以一个最合理的顺序去展示，使收益最大。对于Ranking 技术来说其Fotmulation是在有限的计算资源的情况下如何去最大化展示的集合，使整个Rankging的结果收益最大化，需要在有限的算力下去设计有效的算法-架构，使得最后的Ranking的结果变得更好。

前几年因为硬件计算能力的发展以及整体互联网行业的蓬勃发展提供了足量的数据，Ranking相关的算法进入到深度学习时代，模型、技术创新层出不穷。但是近期技术逐步进入到深水区，特别是近段时间深度学习的基础技术没有太多的突破，整个算法红利在近几年逐步消失。从我们自己团队的视角来说，以一个比较局限的视野来看，从MLR到DIEN，一直到SIM，整个效果的增长是有的，但是整个算力的需求也在增加，在同样的算力需求下对效果的增长的边际已经非常明显，此时我们的算力也触碰到了瓶颈。

面对这些问题我们团队能做什么？

挑战&机遇：

• 模型持续深挖：在资源有限下寻找更有效的算法、模型设计。形成单点效果空间突破-> 坚持模型创新。我们选择在整个Ranking模型上去持续的做创新，认为Ranking model还是有比较大的空间，希望能引入一些业务和产品上新的insight和对模型一些新的理解，在单点打开空间，做出一些突破。
• 架构&算法co-design：坚持设计思路上兼顾算法和架构，更柔性的算法和架构关系->架构&算法同步向前。坚定架构&算法co-design的一个思想，架构和算法一定要同步往前跑，不能先有算法再有架构或者先有架构再有算法。算法和架构无法达成一致的步调是不符合实际的技术需要的，更多的时候可能是团队合作的问题，这样的情况下去做技术的创新成本会比较高，迭代效率也会比较低。
• 算力危机：DL技术迅速吞噬硬件带来的算力红利，算力需求增量带来效果增长边际效应明显->需要把算力优化纳入算法视野。DL的技术和以前的技术有比较大区别，他的更新迭代频率非常的快，很快的就把业界这几年积累的硬件算力的红利开销掉了。这导致我们的算力瓶颈会非常明显。虽然计算成本随着时间依旧是线性增长的，但商业机构的预算是有限的，特别当你处在一个急要还要且要的环境。所以我们需要把算力的优化也纳入到整个算法设计中和算法优化中。而不是简单的把它当做一个独立的、外沿的限制条件。

3. Outline

接下来我分享两个方面的工作：

算法 | 定向广告新一代CTR模型：Search-based Interest Model ( SIM )

SIM是我们建模用户全生命周期兴趣的工作，让模型使用的用户行为的信息长度从过去的1000提升到10000的量级，这个量级应该可以在大部分的场景进行建模的用户全生命周期的用户行为。

算力 | 定向广告新一代个性化算力引擎：Dynamic Computation Allocation Framework ( DCAF )

DCAF是在算力分配方面的工作，我们设计了一套新的算力视角下的一个引擎方案：动态算力分配。主要思想是面对不同的请求流量和请求用户来分配不同的计算资源用不同的算法方案来处理，以达到在一定的有限的资源下系统收益最大化。

02 回顾定向广告模型

1. 回顾定向广告模型

先回顾下阿里巴巴的定向广告模型的发展：定向广告在16年通过一个比较简单的embedding&MLP的方式进入到一个深度学习的领域，在16~18这3年里在电商这个场景沿着兴趣建模的视角，提出了DIN和DIEN。不过从最早的MLR到DIEN的工作中很多的用户行为的序列信息使用长度都集中在100这个量级，视角都集中在用户近期或者说实时的兴趣该如何建模。

在18年~19年我们开始尝试做长期用户兴趣建模的工作，提出了MIMN，把用户行为序列的建模提升到了1000这个量级。在后续是持续想做用户全生命周期的建模的工作，最近我们公开了一个新的工作Search-based Interest Model，把整个用户行为序列建模的长度从1000提升到10000的量级，这是一个平均的数字，我们统计实际最长用户大概是50000的量级。这个能力可以认为是能覆盖其互联网的全生命周期的用户行为序列建模。

2. 谈谈为什么要做life-long视角用户建模

在讲Search-based Interest Model是什么之前，谈谈我们团队为什么一直坚持要做life-long视角用户建模。

电商和线下购物的区别：

电商优势在于更高效的信息交互。在app上浏览商品，成本很低，几秒钟就可以看很多的商品，如果要浏览具体商品的详情页要点击进去可能不到 1 分钟，结构化的信息就会展示在你面前，交互非常便捷。用户和系统的交互会比线下购物发生更频繁的交互行为，也让我们拿到更多的数据，电商很大的优势就是可以利用互联网积攒起来的用户的行为数据和用户的数据来给用户提供个性化的服务。虽然电商的整个交互的行为很多，但是还是有一些问题的。以淘宝举例，它是处在兴趣释放的末端的，很多的行为数据是偏决策结果的数据，而不是决策逻辑的数据，举例：我昨天看这就是街舞，觉得dancer们hiphop的穿搭很好看，于是我产生了新的兴趣去买相关的商品，在淘宝里边通过搜索浏览相关的商品，淘宝人知道的是你近期浏览了hipphop相关的商品，以及发生的一些行为，但是他并不知道这个兴趣触发的逻辑。

而线下的购物是不一样的，线下的时候虽然我们浏览商品的效率较低，但是对每件心仪商品做决策的逻辑信息是更丰富的。比如我们可能会和导购沟通材质，沟通品牌理念，沟通季节，购买用途等等。只不过线下虽然获取信息更丰富，但是却没有有效记录信息的技术。

淘宝等处于成交末端或者说兴趣末端，没有用户关于决策逻辑的数据。这就要求电商要想发挥优势，需要更好的利用用户的决策结果数据，也就是行为数据，我们才有可能去推断用户背后决策的逻辑，更好的建模用户的兴趣变化和当前的兴趣。

过去Ranking相关的算法通常比较"短"，普遍只能有效利用大概100个量级的行为数据，也说明了只是观测了很小的一部分的data。我们以淘宝为例，大部分用户行为数据，如果统计一个比较长的周期，其交互行为量是远超100的量级的，甚至有的用户到50000多次。如果我们只用用户近期的或短期的一些用户行为建模模型会引发非常多的问题。当然我们可以安慰自己说生产线上不能理想化，但是这个做法本身是在忽视用户的长期的兴趣，或者用户长期坚持的兴趣偏好在系统里的一个表现，某种程度上是不够尊重用户的。

如果只用用户的短期行为训练模型具体会带来哪些问题呢？

热点支配的问题：

比如最近突然一个热点出现了，这种风格或者商品非常热门，好多用户都有与之相关的交互行为。那这些用户的所有兴趣都在这个热点上么？其实并不是，这可能只是短期的热点效应。如果从用户全生命周期的行为来看，所有用户都是不同的，他们都有自己独立的兴趣。但是我们只关心短期的的用户行为序列，这些不同是无法发现的，模型很可能因短期的用户行为误判，被这些热点所支配，给所用用户都推荐热门。

长期兴趣的缺失：

很多的用户的长期兴趣比如对价格、材质、风格的偏好等，只是用短短的100个左右的行为是很难建模这些信息捕捉用户长期的偏好的。即使在短期的用户序列里，用户的行为也是多种多样的，类目丰富的。这样具体到某个方面，比连衣裙这个类目，可能最近的100多次行为，只有两三次或者五六次的行为与连衣裙相关。显然这么少的行为信息很难确定用户的购买风格和对材质的要求。

系统视野局限：

这个是个更严肃的问题，当前的推荐或广告系统大部分的技术是data-driven。数据训练模型，模型决定展示的结果从而决定收集的数据。这是一个数据闭环，如果在这样的框架下，我们仅通过短期行为去建模用户兴趣，整个系统会被锁死在一个短期兴趣视野下，看不到甚至不知道长期兴趣对结果会不会有效果，因为这不在系统的观测视野内。

因此我们一直坚持去做用户全生命周期的用户建模，我们认为这样的建模思路也是在更尊重用户。

3. life-long视角用户建模挑战

长期兴趣面对的核心挑战并不是过去提出的算法方案在离线阶段建模精准度不够，或者无法建立长期兴趣的模型。而是在于我们试图解决的是一个真实世界的一个问题。过去的算法方案如果试图建模长期兴趣，那么这样的算法复杂度对于在线系统来说是一定无法接受的。比如我们套用之前的DIN和DIEN，对一个10000长度的用户行为做服务，算法复杂度在用户兴趣的计算方面会随着用户长度的增加而线性增加，那么可以想象我们线上的服务性能是无法抗住这样的压力的。另一点是真实的在线预估系统，对一个用户请求，需要对非常多的广告做预估，并且实时的去请求用户的行为序列数据，那么在线的存储和在线的数据的通讯都会随着用户行为序列的增加而线性增长，这些问题看上去似乎是不可解的。

4. Memory-based模型尝试：MIMN

在18年和19年我们尝试去解决长期兴趣建模存在的相关的问题，做了个Memory-base的一个方案MIMN。MIMN的想法是我们过去算法的问题在于算法复杂度和算法行为序列长度在在线部分线性相关的，如果我们有个办法可以用Memory矩阵来去encode我的用户行为序列，把一个变长的用户行为序列无论其长度是多少，都encode到一个固定size的Memory矩阵去。那我们在在线的时候就用这个固定size的Memory矩阵去计算相关的ctr，这样把兴趣建模的计算和CTR预估的在线计算解耦开来，异步进行，兴趣建模的计算就不再是在线预估的瓶颈。

MIMN的思想是对用户的每一个新增行为，去判断该行为是属于哪个方面的兴趣，对应的写入到Memory矩阵中对应的slot去更新该方面兴趣的描述。用一个固定size的Memory矩阵去记录用的多方面的兴趣。那么这个兴趣记录的过程是和单纯的ctr预估是解耦的，MIMN能把我们整个用户行为序列的建模拉长并且能解决之前的问题。

5. Memory-based方法的问题

在解决了诸多的挑战把MIMN真实的落地后线上后，它确实有显著的效果，但是很遗憾还是有很多的问题：

一个是在系统的可迭代性方面存在很多问题。工业界要解决的问题和学术界不太一样，不是一个静态的问题或者某固定的数据集，去刷指标就可以了。工业界要解的问题是一个动态的问题。比如我们每天用户的行为都会新增，每一天都会遇到一个新的样本，每一天模型的参数可能就需要实时的更新来捕捉这些数据的变化。那MIMN的问题就出现了，我们不停的把用户的行为通过memory的方式encode的到memory矩阵中去，那么这个encode的方式不论是embedding的方式或其他方式写入，我们是以什么样的频率去更新encode本身的参数。那假设上一个版本的encode参数已经把一部分行为信息写入memory了，那么encode的参数更新后，要不要把它擦除掉。然后把所有的用户的行为序列都要写入或者全量更新一遍。全量更新一遍的代价是很大的，我们该怎么解决这些问题呢，这些问题就很复杂。在MIMN的paper中我们就已经详细的讨论了怎么去缓解这些问题，确实是有些方案能缓解这些问题，但是确实增加了系统未来迭代的负担。

另一个问题也是比较致命的，因为我们面临的是一个真实的线上系统。那么受限于计算、通信、存储各方面的压力，MIMN的memory size也不能是无限大的。要在一个有限的空间里去encode一个10000量级长度的用户行为信息，在现有的memory net work相关技术上我们没有找到可行的方案来避免这些行为数据中的信息重复、信息噪声、信息漂移等问题。在我们的场景，MIMN做到1000的长度，在更长的长度几乎就失效了。

6. 回顾定向广告模型

再回看兴趣建模带来的启示：

从DIN和DIEN来看，兴趣建模的一个关键点是用候选的目标商品信息和广告信息对用户行为信息做Search，提取行为信息中有效的部分，辅助建模最后的CTR预估。简单来说就是说把用户行为里面和候选目标商品相关信息搜索出来，然后去建模，效果很好。但是MIMN无法对原始用户行为信息做搜索，因为MIMN已经提前将用户的行为信息做了一次encoding。但是encoding必然会遇到噪声的问题。我们需要找到一个方法可以通过目标商品的信息对用户全生命周期的信息去做搜索，根据搜索到的相关信息做预估建模。如何有效和高效的对用户全生命周期的用户行为信息做search呢，沿着这个思路出发我们做了Search-based Interest Model。

03 定向广告新一代CTR模型

1. 定向广告新一代CTR模型：Search-based Interest Model

Search-based Interest Model的整个思路如上图所示，直接用类似DIN或者DIEN的方案对全行为序列search无疑是在线计算时无法接受的，因此我们想到了能否把搜索解开来，在文中我们提出了两阶段的search模式：general search 和 exact search。从精度角度我们将搜索拆解为一个相对粗糙普适的搜索和一个更为具体精确的搜索。从计算过程角度我们希望general search的大部分计算可以离线完成，并且将历史行为的数量缩小到几百的量级，给exact search部分的建模保留充足的计算复杂度空间。

具体来说我们知道候选的商品信息是什么，我们拿到需要被预估的商品信息后，可以像信息检索一样，对用户的10000多个行为序列构建一个快速查询的索引。待预估商品的信息可以当做是一个query去用户的所有行为中，查询与其相关的行为子序列。这个行为子序列的长度是可以根据系统能力和使用场景控制，比如是100个量级。到100这个量级，如何去利用这个子行为序列的做法就很多了，比如说DIN，DIEN等方法都可以使用，这时候可以做一个比较精细的信息建模，比如说ctr建模。

2. General Search

General search我们在文中提出了两种方案，第一种方案是参数化、较通用的一种方案，我们称之为soft search。此方案我们把用户的原始行为信息和候选的目标商品向量化，让这个向量化具有空间度量性，比如说相似的或者相关的商品在内积空间里距离更近。如此，通过一些最近邻相关的一些检索，比如说MIPS的一些方法，依此构建一个高效的索引，在线时候就能很快的根据候选商品信息，对原始长度10000的行为序列，检索到一个长度可能在100左右的相关用户行为子序列。这个思路和很多团队采用的向量召回的思路比较相近。值得一提的是怎么去做向量化，SIM不是做的相似的度量，而是单独的建立了一个点击预估任务。因为我们的目标不是让相似的商品近同，而是让候选目标商品是通过向量距离找到和自己ctr预估的相关的行为，最后的目标是一个ctr的任务。对用户的所有行为序列的向量化，通过内积判断一个权重，使得点击率预估的更准，找到使这个点击率更相关的这部分行为子序列。如果直接把用户的原始行为子序列输入，那么离线训练可能达到10000长度，训练上也不太能接受。但是这个模块实际上需要训练的是对行为id和商品id的向量，而不是把点击率预估的多准。所以这里有个技巧，可以对样本的原始行为序列进行随机采样，比如把10000的长度直接采样到1000或100使得训练引擎能承受的级别，这样依旧可以满足向量的训练。这部分我们进行过测试，采样和切入一小部分数据不采样，最后的效果是接近的，能保证这个向量是可以用于构建快速检索索引。

另一个General search的方案是我们把它称之为Hard search。在实践过程中，我们发现电商数据天然的账户体系或者结构性让general search有更简单的实现方式。电商场景用户行为大部分交互对象也是item，item有其固有的类目信息category，我们可以对每个用户的历史行为基于category构建一层索引，类目相关的行为可以离线进行挂载。整体用户的行为数据会被构建为一个key1-key2-value的结构，一级索引 key1为user，二级索引key2为类目category，value为该类目下的行为序列，或者也可以进一步扩展为类目相关的行为序列。在线的时候根据用户信息以及每个预估目标商品的类目进行general search，得到一个和当前item相关的子序列。general search后的结果根据我们的数据特性大致会从几万的原始行为量级降低到几百，这个量级就可以轻松的完成在线通信、实时的exact search计算以及CTR的计算。需要注意的是无论是索引结构存放的数据和general search后的结果，都是用户的行为序列原始信息，可以是原始的ID序列。这样保障了我们对信息仅仅做了general search这一步选择维度的过滤，没有类似embedding这样的信息压缩，最大程度的保留了原始信息。

当然了这种简化的general search在我们的离线实验中表现的效果还是弱于基于向量检索的方式，但是其实现成本非常低，只需要有一个支持key-key-value存储的data base就能轻松的实现。同时在线计算部分只增加了exact search的计算开销，能比较轻松的在线服务。并且其对未来的进一步模型迭代也未增加太多成本。综合下来我们选择了这个简化版本的SIM。用category或者其他粒度合适的item描述信息作为一个固定的索引结构，新增的行为可以增量的更新这个索引，训练的时候索引部分是非参的，不会在训练过程中变化。因此可以用最新的检索结果可以对所有的参数进行端到端的训练，相当的轻便，非常适合在实际工业场景中部署。当然所处的数据环境如果没有对行为数据进行类似category这样的结构化处理，那么就得想办法构建其他的索引结构了。

3. SIM视角下的RTP系统

整个Search-based Interest Model 以 Hard search的方案上线后对整个RTP的系统的改造是比较小的。在线预估时会先计算待预估的商品候选集合，一共有多少个unique类目 ( 我们的系统里平均有几十个 )，我们再把userid和类目id拼起来，拼成可能提出的请求的key1-key2请求串，去请求构建好的历史行为索引，把相关的长期行为子序列拿过来，做ctr的预估。SIM对比上一代模型在QPS性能上表现的其实是差不多，但是RTP的rt会增加5ms左右的时间，原因是exact search部分对长期行为子序列的处理增加了计算，会有一部分的时间开销。同时增加了一个额外行为序列的请求，即使是并行也会增加一部分rt。相对于SIM带来的增益，5ms对我们来说是可以接受的。最后我们用hard search 模式的SIM在线上取得了不错的效果，具体数字不再介绍，只要是有过相关工作的朋友都会知道这种方法肯定是有效的，这种效果来源，并不是我们模型设计的多么精细，而是我们有效的用到了更长的用户行为序列。

4. SIM效果

这里面有值得一提的一点是，过去我们在短期行为序列建模的时候，行为发生的时间信息，我们验证了大部分是没有效果。但是在长期行为序列里，特别是几年的行为序列，时间信息就变得有效了，具体time info的使用论文里有介绍，这里就不细节展开了。

右边这个图，是我们想去验证SIM做long-term的兴趣建模时到底有没有做到长期兴趣建模？我们统计了DIEN和SIM在实际在线的推荐结果。d_category的定义：与用户点击的item 类目相同的行为最近发生日期离当前的天数。同时我们简单的将过去14天内的行为类目覆盖的点击行为定义为短期，超过14天的定义为长期。比如图中4060这个部分，就是指SIM推荐且被用户点击的item，该用户在过去的仅在4060天有过同类目的行为，在其他时间都没有与相同类目的item发生交互。同时纵坐标表示SIM的推荐且被点击的item在不同兴趣时间跨度上的数量，我们可以看到虽然SIM和DIEN主要的推荐结果还是集中于近期部分，但是在长期部分SIM的推荐且被点击的结果是显著高于DIEN的。这说明SIM真正更多的推荐出了用户偏向长期行为相关的结果，且用户进行了点击，侧面说明SIM相对更好的建模了长期兴趣。相对DIEN来说SIM真正的给用户展示的更多长期兴趣相关的东西并且用户点击了，说明用户对此感兴趣，这是有效的推荐。这对我们来说是一个非常兴奋的消息，也说明一直以来我们坚持的事情得到了印证。这个思想我们也开始召回、粗排等模块进行尝试，并且取得了一些初步效果。

04 DCAF动态算力分配

接下来我们将分享工作，是在算力优化方面的工作，在这个方向其实我们做的工作比较多，因为时间关系，这里介绍比较新颖的一个，给大家介绍下：DCAF动态算力分配。

我们先来回顾一下过去的算力、架构算法的关系。在深度学习时代之前，因为整个模型的变更，包括架构的变更频率非常短，可能大部分的时候的模型都是不变的，我们在做一些关于数据流、或者特征相关的工作。在这种情况下，算力更多的时候像是一个约束条件，少有和算法以及系统架构联合起来考虑。

但是深度学习时代不一样，深度学习模型开发成本比较低，谁都可以试一试。整个的模型变化频率比较高，同时不同的模型之间的算力需求相比差别非常的大，同时模型OP单元化，一个模型型的整个算力开销基本上是可预估的，这个时候就给算法、架构、算力联合优化提供了条件。

1. 传统Cascade System

接下来介绍的工作，主要解决的是系统引擎里的个性化算力分配相关工作。

过去展示广告或者推荐系统因受最大资源限制，会把给一条请求从全商品库到最终展示结果的流程分为好多个模块。一般分为：召回、粗排、排序，重排等模块。各个模块的候选集大小依次缩小，把大的问题切成好多个子问题，团队中人员组织也往往是这么分配。每个子模块自己的一个目标，有自己的一个候选集的大小，有自己的计算资源等等，用这种方法还挺好的，也挺有效的，把这个复杂的问题，切分成几个子问题，但他一定不是最优解。举个例子，这里面每个模块的候选集到底该是多少，什么样的大小是最合理的？每个模块应该投入的成本是多大？每个模块该给他分配多少的计算资源，给他多少的rt时间，很多时候可能大概率没有在这方面考虑优化，甚至他可能还会引发一些团队的一些摩擦，比如说我做Ranking的，这个地方模型rt时间做的长了，别人的空间就变小。如果从全链路的去考虑这件事情，这种cascade system一定不是最优的，还有一点，我们每个模块儿的结果都在注重个性化，不同的用户或者对不同的请求的结果是不一样的，那么问题就来了，为什么这个链路整个引擎的设计思路以及算力分配的这个方案，候选集的大小，模型要给每条流量一模一样，为什么不能对不同的流量候选的大小不一样，或者算力分配的资源不一样，Latency限制不一样，整个模型不一样，这个地方自由度是一定能够带来效果的收益，在有限的计算力的情况下，去优化整个的结果，那所以我们就定义了这样的一个个性化商品分配的一个问题。

2. Why个性化算力分配

因此我们希望探索一个问题，对于系统的每一条请求，在不同的算力限制下，得到不同的算法方案，最后结果的系统收益其实是不同的。举个例子，我们客观的来讲，对于不同的用户请求来说，对于广告收入来说，不同的用户潜力肯定是不一样的。整个收益价值如平均的ecpm是不一样的。如果在推荐上假设我的目标要优化整个成交额，不同的用户，在不同的时期，当时的购买力都是不一样。对于最大化的系统的收益来说，每条流量的潜在收益不一样，那么我们为什么要给每条流量分配同样的计算力？用同样的计算方案？能不能够，比如说对算力不敏感的流量，分配少一点的计算资源，对价值很低的，分配少一点的计算资源。对于那些潜在价值高，同时对算力敏感的流量提高算力，提高模型复杂度。不仅是算法结果不同，而是对不同的流量算法方案也不同，做到真正的个性化系统服务。

2. DCAF

我们这里把整个动态算力分配定义为一个组合优化的问题。

i：流量，j：算力分配方案

q_j：执行算力方案j时，计算资源消耗

Q_{ij}：对于流量i，执行算力方案j时，取得的收益

C：总体最大计算资源上限

计算资源是各种各样的，我们要使得累计起来的计算资源，在这个C的业务限制下，我们去最大化，得到最大化收益

Xij意思是在i上选择各种方案j。最后问题转化为对偶优化问题，这里推导就不展开了，最后可以发现，整个全局最优可以推导到单条流量的具体的最优方案，那这种情况下就能对的整个算力做一个更优分配。

3. DCAF调控

这个想法是做个性化算力分配，实现平台算力收益空间最大。在在线系统看来，不仅仅以这个流量视角可以分配不同的算力或者用策略让整个的收益空间更大，或者达到同样的收益的情况下用的计算资源更小。同时，我们还能根据在线系统的状态去动态地调节我每一条流量的最大算力的C，从而保障系统稳定性。比如在一批流量最大化的算力上改变C，晚上可能会整个流量比较低，那我可以根据我在线系统的latency、QPS，GPU 使用率等系统指标来动态地调整算力的上下限，让我们的系统保证一定是在一个平稳的状态下运行的，而不是人工的去运维。我们可以通过C来动态的调解系统资源边界，同时动态的调节各个算法。这个方案在618的时候开了一个实验集群，做实验非常有效，首先这个系统的运行非常平稳，无论说当前的状态怎样，第二点是我们确实能够在达到同样的广告效果，比如关注的收入，在保证收入和点击率的这个情况下，我们可以达到用更少的计算资源就能完成。

4. DCAF实验结果

这里是用历史的真实数据做的模拟情况。

图中上面两红色条线指用同样的算力，既用同样的计算资源C不变的情况下，做平均分配或者做动态分配，可以看到在最高点的时候ecpm会增加3.7%。下面两条黄色线对比，在保证动态分配方案的ecpm和平均分配是一样的情况下，算力可以减少多少，可以看出计算资源能够减少49%。假设要减少49%的计算资源，不以最优化分配的策略而是随机的来分配哪些流量增加算力，哪些流量减少算力，则整个ecpm会达36.8%的降幅。而DCAF通过这个模拟可以看出是不会有任何ecpm的损失的。图中的数据是通过历史数据离线模拟的情况，因为我们在真实求解的时候，Qij每条流量不同的算力方案执行的收益是不确定的。举例说明，比如说qj可以是不同的模型，对不同的流量采用不同的模型，也可以是不同的流量采用不同的候选集大小方案，这个收益在离线时候可以通过日志可以模拟出来，但是对于没有去付出算力的情况下，是要通过预估，预估就会带来一定的精度漂移。实际上，在做到同样的ecpm水平的情况下，我们在线只能减少大概25%的计算资源开销。

相关工作的细节是有公开的，大家可�