阿里新一代 Rank 技术

导读： 本文的主题为新一代 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 天的定义为长期。比如图中 40~60 这个部分，就是指 SIM 推荐且被用户点击的 item，该用户在过去的仅在 40~60 天有过同类目的行为，在其他时间都没有与相同类目的 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 是不一样的。如果在推荐上假设我的目标要优化整个成交额，不同的用户，在不同的时期，当时的购买力都是不一样。对于最大化的系统的收益来说，每条流量的潜在收益不一样，那么我们为什么要给每条流量分配同样的计算力？用同样的计算方案？能不能够，比如说对算力不敏感的流量，分配少一点的计算资源，对价值很低的，分配少一点的计算资源。对于那些潜在价值高，同时对算力敏感的流量提高算力，提高模型复杂度。不仅是算法结果不同，而是对不同的流量算法方案也不同，做到真正的个性化系统服务。

3. DCAF

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

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

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

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

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

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

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

4. DCAF 调控

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

5. DCAF 实验结果

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

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

相关工作的细节是有公开的，大家可以去阅读相关论文，有相关的问题和想法，可以跟我邮件沟通。

05 心得分享

最后，分享一点心得：

第 1 点 ，算法 &工程 co-design，定向广告团队持续的做一些微小的工作，有个很大的因素在于算法和工程非常和谐，并且共同的坚持算法 &工程 co-design 的一个理念。大家都认为在最初设计的时候，要共同考虑算法 &工程，算法 &工程同步前进。这个合作关系就不只是嘴上说说，更多是做出来的。很多时候这些项目是共同来考虑，这就让我们整个迭代的成本降低了，在最开始选择方案的时候，不需要算法证明什么，或者工程今天就要搞这个技术路线，之后算法再受限的迭代。这种紧密的合作保障在设计方案之初，就从算法 &工程的视角协同考虑，整个迭代成本非常低，迭代的速度变快。

第 2 点 ，从作为算法工程师的视角来讲，虽然现在技术是 Data-driven 的，但是算法工程师自己是不能仅唯数据论，做算法研究不能把目标定义为在某个 data 下，提升某个技术指标，或者只关心现在看到这个结果。有很多 task 的一些问题，因为整个数据循环，很难通过唯数据论就找到大部分的答案。如果算法工程师也跟 model 一样，仅仅通过数据现象去指导自己的思路。我们就会像线上的模型一样，被数据探索空间限制住。模型本就是我们这些技术人员设计出来，如果我们也只从当下看到的数据里面去找答案，那么我们的视野也是局限。我们需要有对一些问题有更多的相信和坚持，如 explore、fairness、尊重用户，我们相信去研究这些问题是有收益的，我自己非常相信这一点，一直以来坚持这一点。我们要做的事情不仅仅是提升目前数据上的一个指标，而是提供更好的技术能力，更尊重用户，提供更好的服务，把这系统里面我们能知道的，我们去相信有人性的一些问题解决掉。我相信未来会有更多的同学能够加入相关的研究当中来，现在看到的相关的工作还比较少，但是肯定会在短期之内就会有一些非常有代表性的工作爆发出来。总归念念不忘，必有回响，相信这些坚持会看到一些结果。

作者介绍：

周国睿，阿里巴巴高级算法专家

周国睿，北京邮电大学硕士。研究领域包括大规模机器学习、自然语言处理、计算广告、推荐系统等。目前在阿里妈妈定向广告团队，负责排序算法和算法平台相关的工作。研究成果发表于 KDD/AAAI/CIKM 等会议，其研究工作均落地于实际系统。

本文来自 DataFunTalk

原文链接：

阿里新一代Rank技术