阿里妈妈内容风控模型预估引擎的探索和建设

发布一下 2022年12月30日 08:40 0 0

作者：徐雄飞、金禄旸、滑庆波、李治

内容作为营销的重要载体，能够促进信息的交流和传播。在营销场景中，广告高曝光的特性放大了风险外漏带来的一系列问题，因此对内容的风控审核就显得至关重要。本文将为大家分享阿里妈妈内容风控模型预估引擎的探索和建设。

一、业务背景及问题

1.1 业务背景

内容作为营销的重要载体，能够促进信息的交流和传播。在营销场景，广告内容需要满足广告法要求，常见的风险类型有两类：一类是面底线的A类风险，如政治等，一类是面向平台调性，广告法要求的B类风险，如低俗不雅、公序良俗等。一旦风险外漏，由于广告高曝光的特性，会导致舆论压力，甚至有业务关停的风险。

阿里妈妈内容风控核心由机审、人审两部分组成，其中机审防控包括增量和全量防控（链路如下图所示），机审与人审环节都依赖模型服务，由于广告数据和主站存在差异，且风控的强对抗性、模型都自研实现。随着模型不断增多，模型的线上服务部署和管理变的越来越臃肿，出现诸多问题。

1.2 现存问题

现有的模型预估引擎（Inference-kgb）由于历史业务演进、临时性支持妥协，随着模型数量不断增加问题逐渐暴露出来，下面从能力、效率、质量、成本四个方面详细分析现有的问题，为我们重构新的引擎打下基础。

1.2.1 能力问题

缺乏统一的加速方案：仅部分模型通过GPU进行加速，大部分模型性能较差；异构混部模型缺乏通用的接入、导流、蓄洪和限流等服务特性和运维特性。

一致性问题：离线和在线模型结果一致性难以保障，没有形成通用方案；跨平台模型Case by Case上线，没有统一的服务API；运维干预纯靠人工经验，无可靠的管控API。

1.2.2 效率问题

研发周期长：Inference-kgb框架底层采用C++实现，算法同学上线前需要将训练的Python代码翻译成C++代码，开发周期长且部分库无法直接翻译需要手写，会导致实验结果和线上不一致。

部署上线流程复杂：每个模型上线都需要代码开发，像分类模型代码及配置都相同只更换模型文件，由于框架限制需要走完开发、测试、部署、上线全流程。过去模型部署链路在/近/离线是分别管理的，模型上线过程中需要跨多个平台进行配置，操作繁琐。每次模型上线需要通过邮件申请Metaq（阿里内部消息中间件）消息，等Metaq同学回复邮件后才能够继续发布流程；研发流程无法保障多人协作安全、高效。

1.2.3 质量问题

缺乏统一的接入标准：早期整个框架是完全自研实现，可参考的方案较少，不断演进之后与业界方案存在差异。如缺乏统一的Tensor in Tensor out模型层面无业务语义的接口，用户接口设计不合理，接口核心字段为imageUrl和textString导致很多字段都通过拼接的方式传入textString中；输入非结构化存在诸多问题，如离线冷启动执行模型时，需要手动按照线上逻辑进行字段拼接。

子模型问题：将多个通用分类、检测模型部署在一个服务中，然而服务及运维属性都是按照模型粒度设置的，无法根据子模型定制：如Cache、计算资源等是针对整个服务维度生效的，无法根据子模型进行精细化控制。

同质代码缺乏复用：如检索类模型提取向量特征之后需要进行检索库匹配操作，过去的服务框架将特征提取和检索融合在一起，由于检索库的差异会导致部署模型数量膨胀。

1.2.4 成本问题

GPU利用率低下：部分大流量的模型之前没有GPU版本，GPU模型普遍使用率比较低。离线无法充分利用资源提取特征，由于模型缺乏GPU镜像，导致离线提取特征是无法充分利用智能引擎(MDL)资源池、主搜(Hippo资源调度)资源池的离线GPU资源。

二、业界对比选型

基于以上问题，我们考虑对现有模型预估系统（Inference-kgb）进行重构，优先考虑复用集团或开源现有的能力，因此我们对集团及开源方案进行了调研。

2.1 业界方案对比

分别调研阿里云EAS、达摩院Aquila、CRO灵境、阿里妈妈HighService、开源TritonServer。

2.2 业务诉求

以上平台/框架，有些包含完整的模型部署、运维功能，有些只包含模型加速功能。我们尝试推演将模型整体部署到平台上，遇到以下几个问题：

资源互通问题：以上平台（如EAS），需要在ASI（Alibaba Serverless infrastructure）上统一申请资源，现有的Hippo资源无法直接迁移过去使用。
离线计算问题：目前已有平台解决的基本都是在线服务部署的问题，由于风控业务特性，我们遇到风险事件时需要在离线环境进行大批量的特征提取及全量数据的风险防控，在指定时效内完成风险清理，这部分没有现有能力支持。
缺乏偏业务语义的功能：针对偏业务语义的功能，平台没有很好的支持，如模型对应的风险管理，版本迭代后的业务效果，模型结果复用等。

考虑到业务诉求及已有能力最大程度复用，核心构建上层偏业务的服务能力，底层能够接入EAS、HighService、Aquila 等多种Backends，进行模型服务和加速。

三、模型服务框架

风控业务场景，模型服务核心解决机审风险识别及人审工单拦截等相关问题。模型分别服务于在/近/离线业务，引擎内核复用同一套逻辑，确保在/近/离线数据一致，底层接入多种Backends，对模型进行部署、加速。可以在各个调度器及资源池中进行计算。重构后新的风险预估引擎RD（RiskDetection）层次结构如下图：

RD内核部分，参考NIVIDIA Triton Server实现（NVIDIA开源推理框架），我们定义了一套标准业务接口，支持多Backends对接的在线服务。其中Standard API支持Tensor in Tensor out标准模型协议，由Model、Version、Tensor标准三元组构成，模型内部支持动态Batching特性。通过对接集团及开源社区已有的Backends低成本的实现模型预估能力。

3.1 标准化接口

接口定义分为面向业务及面向数据两个维度，面向业务包含图片、文本、视频等内容识别输入输出接口；面向数据面，我们与主流的KServe（开源云原生模型推理框架）对齐，采用Tensor in Tensor out进行模型预估逻辑。

3.1.1 业务接口

业务侧支持图片、文本、视频等素材类型，包含检测、识别、分类、检索等模型服务。过去的系统（Inference-kgb）所有的模型都共用一个接口，输入是图片、文字，输出是Map对应的K,V。系统运行一段时间之后，发现输入、输出变的越来越复杂，于是在字段上进行各种拼凑，导致输入、输出变的越来越复杂。吸取Inference-kgb的经验教训，也参考阿里云等开源接口设计，我们针对不同类别的模型进行独立接口设计。

3.1.2 数据面接口

在模型内部，都是以Tensor数据格式进行传输，我们支持调用方通过Tensor接口调用模型服务，通过TensorFlow、KServe以及内部EAS对TensorFlow/PyTorch模型的服务接口抽象，定义我们自己需要的TensorFlow/PyTorch模型服务标准API如下图：

3.1.2.1 Predict接口

1）TensorDataType：TensorDataType用于标准化指定Tensor的数据类型。

2）TensorShape：用于标准化指定Tensor的维度。

3）TensorDataContent：内部的EAS和外部开源的TensorFlow其实都没有TensorDataContent这个抽象，都使用的完全平铺的方式定义Tensor内容，KServe最新版本对TensorData做了抽象，是能够包含EAS和TensorFlow的定义的，因而采用。

4）InferParameter：InferParameter这个数据结构，内部的EAS和开源的TensorFlow都没有定义，但是KServe最新版本的API定义里预留出来了，目的是未来能够基于标准化的Tensor定义支持跨多个不同的非标准化推理服务平台后端，通过拓展参数增强跨平台的可移植性。考虑到内容风控未来线上模型也会对接多个非标准化Backend，所以考虑在前面统一的API Protocol标准化Tensor结构定义的基础上，也引入InferParameter以实现跨平台的对接能力。

5）TensorEntity：把TensorDataType、TensorShape、TensorDataContent和InferParameter组合，得到一个标准化定义的TensorEntity数据结构。

6）PredictRequest：如前面所述，我们把原子的Tensor in Tensor out的推理服务命名为Predictor，PredictRequest则是每个Predictor角色的标准化输入接口入参，这里提取EAS、TensorFlow和KServe各自有用的部分组合而成。

7）PredictResponse：PredictResponse核心返回数据结构是TensorEntity，同时把PredictRequest原始请求的模型信息、拓展参数信息也带回来（参考KServe设计，原生TensorFlow和EAS没有）。

3.1.2.2 Metadata接口

1）TensorMetadata：Tensor的元数据由Tensor名、Tensor数据类型和Tensor维度组成的三元组表示。

2）ModelPlatform：后端支持的模型框架平台类型，目前支持原生的Tensorflow、PyTorch、TensorRT三类，以及集团内部HighService、EAS、Aquail等。

3）ModelMetadataRequest：ModelMetadataRequest是用于请求模型推理服务元信息的标准化抽象接口，由模型名(name) + 模型版本(version)构成二元组。

4）ModelMetadataResponse：根据ModelMetadataRequest指定的模型名+模型版本二元组获取详细的模型推理服务信息，主要由传入的模型名、模型版本、输入Tensor元数据和输入Tensor元数据这四部分组成。

3.2 RD内核技术方案

RiskDetection：提供标准的模型用户接口，提供模型服务特性和运维特性，串联模型前处理、模型预估、模型后处理阶段。

Predictor：提供模型标准数据面Tensor in Tensor out接口，兼容多种RTP协议的Backends。Predictor逻辑上是拆分成独立的服务，物理实现为了减少I/O请求，可以考虑和前后处理部署在同一台机器上。

Transformer：Transformer用于模型服务的前后置处理，它和Predictor共同完成一个完整的模型推理请求。Transformer一方面可以通过拓展前处理逻辑把外部输入转换成Predictor接收的标准输入格式，另一方面可通过拓展后处理逻辑把Predictor返回的结果做进一步转换供给业务方应用。

Backends：底层具体采用的模型服务框架，包含集团及开源解决方案。

3.3 数据一致性保障

风控业务包括了在/近/离线场景，不同场景对资源、时效、吞吐等要求不一样，各场景提取出来的特征需要保障最终一致。对一致性保障可以划分成两个层级：特征完全一致、业务效果一致。

1）特征完全一致：高保障业务场景，对风险判断要求更严格，我们需要确保模型输出Tesnor保持一致，因此在/近/离线需要保证镜像、模型文件版本、计算资源完全一致。

2）业务效果一致：在一些保证级别要求不高，且计算量大的场景，我们允许在/近/离线计算资源不一致，如在线采用GPU，离线采用CPU（GPU通过TensorRT 半精度加速后结果有损），只需要在业务效果上保障一致即可。

四、模型推理加速

过去的Inference-kgb基于原生TensorRT进行模型加速，随着模型迭代更新越来越频繁，每次算法同学训练模型到上线都需要将Python代码用C++重新实现一遍。通过对集团及开源方案调研，现有的框架很多都支持Python直接进行模型部署、加速，能够解决Python语言带来的GIL锁冲突问题，新的框架我们采用Python进行模型预估开发，并且能够支持多种模型加速Backends(如HighService,EAS,Aquila等)，可以直接复用已有能力，无需从0开始重新搭建模型推理加速功能。由于整体框架初见雏形，我们先接入了HighService和EAS两个Backends，支持我们核心模型的落地。

4.1 HighService Backend接入

HighService是阿里妈妈异构计算团队内部开发提供的，基于Python多并发异构计算服务框架。HighService框架通过解耦GPU及CPU计算，使用多进程进行CPU计算，充分利用多核CPU资源，在多个CPU进程与单个GPU进程之间通信，避免GPU进程饥饿，同时CPU进程数不受GPU大小内存限制。内部集成了TensorRT加速功能，成倍地增加了PyTorch模型的计算能力。使用HighService框架服务的动机，除了它的高性能以外，还有一个重要原因，就是利用Python模型易于迭代、维护、定位问题的优势，可以更好地服务业务，解决了业务方研发周期长的痛点。相比于过去的Inference-kgb框架，利用HighService的RD框架上线一个GPU模型的研发周期得到大幅度提升。

4.2 EAS Backend接入

EAS广泛在集团使用，它与PAI平台（模型训练平台）无缝衔接，并且底层拥有完善的Blade加速方案，服务和运维特性非常全面。在与EAS同学深入沟通后，发现由于计算资源池及离线业务特殊性等原因，无法直接将服务完全托管。但EAS提供的SDK能够给支持模型的部署、加速能力，这部分能力可以直接接入RD作为Backend，接入后基于镜像部署可以同时支持在/近/离线的业务。

EAS主要的接入方式有两种：Processor方式接入和Mediaflow方式接入，Processor方式需要将模型部署在EAS平台上，能够方便的部署模型，并且提供标准化的Tensor接口；由于我们无法直接将模型部署到EAS平台，因此我们采用Mediaflow的方式接入。具体实现demo如下：

Mediaflow方式是EAS团队今年新研发的方式，可以将整个模型流程采用DAG进行串联（也可以是单个节点），能够轻量级接入SDK，并且享受到底层Blade加速效果。

五、业务支持及效果

完成RD系统重构，我们进行压测及效果验证达标后，开始对接业务。目前RD主要服务于阿里妈妈内容风控在/近/离线模型计算，为内容风控机审风险识别和人审提效服务。在/近线都是常驻型服务，拉起后提供HSF服务接口，离线是通过批量任务的方式启动。

5.1 在/近线业务支持

对比过去的Inference-kgb服务拉起配置较为繁琐，需考虑了多个子模型DAG之间的串联，采用OP算子进行关联。每个模型上线都需要开发OP，哪怕仅更换模型文件拉起不同的服务。我们将子模型组装DAG前置到业务编排组件，RD就是纯粹的进行特征提取、模型计算，因此在服务拉起及服务运维方面有较大提升。

5.1.1 快速服务拉起

拉起服务主要依赖镜像+模型文件+模型配置三元组，三元组唯一确定一个模型服务，因此快速拉起服务的首要任务就是管理服务依赖的三元组。

镜像：RD所有支持的模型都共用相同的镜像，同时支持CPU、GPU模型运行，这样方便整体的管理和运维。统一镜像也会带来一些负面作用，如修改A模型可能会影响B模型，这个需要我们在开发过程中，修改到公共部分时特别小。需要借助单元测试、集成测试等标准化流程规避此类问题。
模型文件：统一管理在OSS上，由模型名称+版本号唯一确定一个模型文件。可以根据模型文件恢复历史任意的模型服务。该功能为后续做模型效果对比等功能提供底层能力支持。
模型配置：吸取过去的Inference-kgb复杂模型配置教训，RD极大的简化配置内容，将配置分为静态和动态两部分。静态模型配置：如模型代码路径，模型Backend配置，模型是否需要Cache等，这些配置与部署的模型实例无关。如部署GPU、CPU版Face，以上配置都是相同的。动态模型配置：如服务接口、模型版本、资源类型等，每个部署实例有不同的配置。动态配置能够方便的启动相同模型的不同服务版本，能够支持业务进行效果对比或者CPU、GPU混部等能力。

如上图，通过以上设计我们能够更方便的针对同一个模型启动各种版本，使用不同类型和保障级别的资源，支持各种隔离级别的业务。

5.1.2 模型服务/运维特性

参考集团及开源方案，核心服务/运维特性主要包括Caching、Batching、Scaling，支持以配置化地方式拓展服务/运维特性从而拓展系统处理能力，主要特性描述如下：

5.2 离线业务支持

通过在线防控，我们能够解决增量风险问题，然而如果有风险外漏，或者监管调整，我们都需要对全量数据进行风险防控。同时算法同学需要在离线进行大量实验、评测，这些都依赖于离线具备大规模模型计算能力，因此RD需要具备离线计算的能力。

5.2.1 离线任务对接

Starling是阿里妈妈风控自研的基于主搜Drogo（资源调度管理平台）之上进行业务调度平台，底层使用主搜Hippo资源池。风控场景在离线需要提取百亿级图片、文本特征进行实验或者风险防控，模型计算需要大量的计算资源，Hippo资源池拥有海量非保障（离线）资源，Starling的初衷是可以削峰填谷地使用这些资源支持业务特性。

RD对接上Starling之后，便拥有了离线调度计算的能力，能够灵活的拉起Hippo资源，并与ODPS（对外产品为MaxCompute）打通，对ODPS数据进行读写。同时能够通过ODPS进行任务调度，进行定时增量数据特征提取。

如上图为RD与Starling对接的架构图，Starling的Master节点管理和调度RD进行模型计算，和模型配置文件分发，Starling SDK实现ODPS对接及Slave节点状态上报。

上图为通过ODPS配置Starling任务节点进行调度，实现定时特征提取功能。

5.2.2 单容器多实例部署

对于模型计算而言，离线与在线存在的核心差异是数据源及消费方式，在线是流式源源不断输入，离线则是固定数据集运行特定的模型。一个任务计算量是亿甚至百亿级别，内容场景有很多图片模型。考虑到拉图成本及多模型任务依赖的管理成本，我们通过单容器支持多个模型运行的方式，节约拉图60%左右，以及简化任务配置实例。

支持单模型多实例部署的前提是模型之间没有相互冲突，所以CPU资源上更容易实现，GPU资源由于16G显存的限制，很容易OOM。CPU也需要根据模型大小、内存申请等控制实例部署个数，例如30G内存部署3个模型。以下是合并前和合并后任务节点的配置，可以发现合并之后节点明显简洁得多。

5.3 业务效果

RD上线在/近线迎来首个双十一考验，离线需解决大规模特征提取问题，无论是性能、效率都需要有显著提升，能够给业务带来可感知变化，接下来分别介绍在/近/离线因为RD上线带来的相关改变。

5.3.1 离线清理支持

离线部署6个核心模型支持全量及增量数据提取任务，通过Starling使用非保障资源批量提取增量百万级图片特征可在20分钟内完成。

5.3.2 双十一业务支持

大促结束后平台要求广告主在规定时间内下线双十一相关内容，因此相当于整体的广告内容这个时刻开始全量更新一次。

RD目前对外提供的接口是同步请求方式，QPS超过模型服务单机承载能力（CPU/GPU Load打满）时，会造成模型服务RT成倍增长影响业务稳定，因此需要对每个模型进行精确限流。内容风控模型服务众多，从模型部署角度上讲：同一个模型可能跑在GPU或者CPU上，也有可能部署在不同机房（机房拉图带宽有上限，需要多机房部署），不同集群之间有Backup的关系（比如GPU集群被限流则自动将流量导入到CPU集群），从业务角度上讲：对于高优先级场景中的底线类风险需要百毫秒级以内得到模型结果，而一些低优先级的体验类风险则可以使用一些便宜的机器进行计算，能够承受一定RT延迟。仅依赖HSF（阿里RPC框架）的限流配置或Sentinal限流（阿里分布式限流框架）组件远不能满足这种异构部署和业务上多样化的导流需求，因此我们自建了InferenceProxy服务来支持基于业务标签的QoS和导流能力，在保护下游RD服务能力的同时，对物理层面的调用关系进行配置化的编排。

导流表其中几项配置如下：

由用户自定义的一段逻辑从请求原始Payload提取信息并打上标签，例如上面这个请求会打上label=1125这个标签。执行时会首先查出符合条件的所有导流项：1、2。按照同优先级+权重的方式分配流量，详细来说：其中1和4的priority都是0，1的weight是10, 4的weight是50，则这个请求以1/6的概率打在服务1上，以5/6的概率打在服务4上。

如果请求priority=0的服务失败或超时，则会打到priority等于1的第二项服务2上，仍旧超时或失败，则该请求会进入离线兜底队列。参考导流表设计，一个请求到来时，会筛选出符合条件的几个导流策略，按照priority进行排序分层，各priority之间使用责任链模式串联，如果请求失败或超时，则进入责任链的下一个策略priority进行执行。

核心类图：

过去的Inference-kgb由于性能问题，TOP3请求的模型存在严重的性能瓶颈。RD上线后，我们可以同时支持GPU版和CPU版在线上运行，性能相比线上CPU版有了几十倍的提升，通过InferenceProxy进行模型服务接入，能够精准的控制机器和流量配比。

通过InferenceProxy切流方案，我们能够将新的RD安全稳定的接入到在线服务中，承载TOP3模型流量，优雅解决了双十一大促过程中模型积压的问题。切流链路如下所示：

六、未来展望

6.1 能力方面

模型推理加速：完成Inference-kgb迁移RiskDetection GPU加速，并且持续打磨HighService及接入更多Backends，让模型接入更加简单方便，形成标准化接入流程；新增CPU通用加速流程，形成CPU标准化加速方案，并在ID模型上落地；调研PPU加速方案，尝试采用PPU解决在/近/离线资源瓶颈问题。

服务运维特性：完善核心三大服务及运维特性：Caching，Batching、Scaling；其中Batching、Scaling依赖Backends提供相应的能力，ID实现通用配置化管理。

6.2 效率方面

模型源数据管理：模型文件、镜像、配置进行标准化管理，在/近/离线复用同一套管理标准。

简化模型发布流程：借助已有平台标准化模型效果验证、配置、部署、回滚、灰度发布流程。

6.3 质量方面

代码质量：由于Drogo多Role部署不能直接按照Aone发布流程部署，需要手动在Drogo上部署，导致Aone上设置的CodeReview、单元测试等卡点无法直接生效。因此我们需要制定发布标准，并严格按照标准执行。

服务质量：标准化开发、测试流程，对模型服务质量、代码质量、服务质量提出明确要求，并遵守标准规范，不合规范不允许上线。完善系统监控，报警信息。

6.4 成本方面

提升资源利用率：通过CPU、GPU加速、Batching等功能提升系统性能，从而达到减低计算成本的作用。通过弹性缩扩容落地，更加合理使用资源提升整体资源使用效率。

对模型类型约束：相同类别的模型尽量复用同一套代码（如分类模型）限制模型类别，不过度限制模型数量。类别固定有利于模型更方便的复用，减低开发、运维成本。

降本增效：持续度量模型ROI，替换低ROI模型及策略。