人工智能应用架构的思考

一、Paddle Lite 和 PaddleSlim

目前在深度学习领域分类两个派别，一派为学院派，研究强大、复杂的模型网络和实验方法，为了追求更高的性能；另一派为工程派，旨在将算法更稳定、高效的落地在硬件平台上，效率是其追求的目标。复杂的模型固然具有更好的性能，但是高额的存储空间、计算资源消耗是使其难以有效的应用在各硬件平台上的重要原因。所以，卷积神经网络日益增长的深度和尺寸为深度学习在移动端的部署带来了巨大的挑战，深度学习模型压缩与加速成为了学术界和工业界都重点关注的研究领域之一。

1. 端侧推理引擎的背景

随着深度学习的快速发展、特别是小型网络模型的不断成熟，原本应用到云端的深度学习推理，就可以放到终端上来做，比如手机、手表、摄像头、传感器、音响，也就是端智能。此外，可用于深度学习计算的硬件也有井喷之势，从 Intel 到 Nvidia、ARM、Mali、寒武纪等等。相比服务端智能，端智能具有延时低、节省资源、保护数据隐私等优势。目前已经在 AI 摄像、视觉特效等场景广泛应用。

然而，深度学习推理场景中，多样的平台、不同的芯片对推理库的能力提出了更高的要求。端侧模型的推理经常面临算力和内存的限制，加上日趋异构化的硬件平台和复杂的端侧使用状况，导致端侧推理引擎的架构能力颇受挑战。端侧推理引擎是端智能应用的核心模块，需要在有限算力、有限内存等限制下，高效地利用资源，快速完成推理。因此，飞桨期望提供面向不同业务算法场景、不同训练框架、不同部署环境， 简单、高效、安全的端侧推理引擎。

2. Paddlelite 的特色

为了能够完整地支持众多的硬件架构，实现在这些硬件之上的各种人工智能应用的性能优化，飞桨提供端侧推理引擎 Paddle Lite。截止到现在，Paddle Lite 已广泛应用于搜索广告、手机百度、百度地图、全民小视频等多个重要业务。

Paddle Lite 具备如下产品特色：

1） 移动端和嵌入端的模型部署工具，可使用其部署 PaddlePaddle、TensorFlow、Caffe、ONNX 等多种平台的主流模型格式，包括 MobileNetV1、YoloV3、UNet、SqueezeNet 等主流模型。

2）多种语言的 API 接口：C++/Java/Python，便于嵌入各种业务程序。

3）丰富的端侧模型：resnet、effcientnet、shufflenet、mobilenet、unet、facedetection、unet、ocr_attention 等。

4）支持丰富的移动和嵌入端芯片：ARM CPU、Mali GPU、Adreno GPU，昇腾 &麒麟 NPU，MTK NeuroPilot，RK NPU，寒武纪 NPU，X86 CPU，NVIDIA GPU，FPGA 等多种硬件平台。

5）除了 Lite 本身提供的性能优化策略外，还可以结合 PaddleSlim 可以对模型进行压缩和量化，以达到更好的性能。

3. 架构设计

架构图如上所示，Paddle-Lite 架构侧重多硬件、高性能的支持，其主要设计思想如下：

1）引入 Type system，强化多硬件、量化方法、data layout 的混合调度能力。

2）硬件细节隔离，通过不同编译开关，对支持的任何硬件可以自由插拔。

3）引入 MIR(Machine IR) 的概念，强化待执行环境下的优化支持。

4）图优化模块和执行引擎实现了良好的解耦拆分，保证预测执行阶段的轻量和高效率。

二、AIOps 的思考

1. 背景

AIOps，最初的定义是 Algorithm IT Operations，是利用运维算法来实现运维的自动化，最终走向无人化运维。随着技术成熟，逐步确定为 Artificial Intelligence for IT Operations——智能运维，将人工智能应用于运维领域，基于已有的运维数据（日志、监控信息、应用信息等），通过机器学习的方式来进一步解决自动化运维无法解决的问题。

早期的运维工作大部分是由运维人员手工完成的，手工运维在互联网业务快速扩张、人力成本高企的时代，难以维系。于是，自动化运维应运而生，它主要通过可被自动触发、预定义规则的脚本，来执行常见、重复性的运维工作，从而减少人力成本，提高运维的效率。总的来说，自动化运维可以认为是一种基于行业领域知识和运维场景领域知识的专家系统。随着整个互联网业务急剧膨胀，以及服务类型的复杂多样，“基于人为指定规则”的专家系统逐渐变得力不从心，自动化运维的不足，日益凸显。 

DevOps 的出现，部分解决了上述问题，它强调从价值交付的全局视角，但 DevOps 更强调横向融合及打通，AIOps 则是 DevOps 在运维（技术运营）侧的高阶实现，两者并不冲突。AIOps 不依赖于人为指定规则，主张由机器学习算法自动地从海量运维数据（包括事件本身以及运维人员的人工处理日志）中不断地学习，不断提炼并总结规则。AIOps 在自动化运维的基础上，增加了一个基于机器学习的大脑，指挥监测系统采集大脑决策所需的数据，做出分析、决策，并指挥自动化脚本去执行大脑的决策，从而达到运维系统的整体目标。

下图是百度运维发展历程：

从 2014 年开始，从最开始的行业领域知识加上运维专家经验，到之后加上人工智能算法，演进成 AIOps，从数据建设和智能监控场景入手，逐渐覆盖到智能故障管理，变更管理，容量管理和服务咨询。

综上看，自动化运维水平是 AIOps 的重要基石，而 AIOps 将基于自动化运维，将 AI 和运维很好地结合起来，这个过程需要三方面的知识：

1）行业、业务领域知识，跟业务特点相关的知识经验积累，熟悉生产实践中的难题。

2）运维领域知识，如指标监控、异常检测、故障发现、故障止损、成本优化、容量规划和性能调优等。

3）算法、机器学习知识，把实际问题转化为算法问题，常用算法包括如聚类、决策树、卷积神经网络等。

百度的故障管理场景如图所示，主要包括故障发现，故障止损，故障诊断智能预警等。

2. 故障发现

运维的黄金指标有请求数（流入状态），成功率（流出状态），响应时间（用户相应感受），系统容量（系统并发负载）等。其预测难点在于基线预测算法在遇到节假日这种不规律的情况时不准确，另外在于配置上的，忙闲时间机器需求差异很大，容易造成资源浪费。

2.1 基线预测算法

基线预测算法主要采用鲁棒回归+周期数据多模式挖掘相结合的算法。鲁棒回归算法的思想是假设较小窗口内符合线性趋势变化，即局部符合线性。周期数据多模式的思想是对于不同的节假日，春节等特殊时期采用多种基线模型进行匹配。

3. 故障自愈

出现故障第一时间的原则是故障止损，而不是查明原因，甚至解决问题。先将损失止住，再进行分析。

传统的人工故障止损有以下三个不足：相应可能不够迅速，决策可能不够准确，操作可能出现失误。AIOps 中的故障止损叫做故障自愈，相对人工智障止损的不足，它可以 7*24 小时快速相应，全局一致性信息决策，程序自动化准确操作。

故障自愈的场景和止损方法如下：

4. 故障诊断

如下图所示，为一个系统的运行流图，G 节点此时出现故障。

人工故障针对的做法通常从两个方向出发，一是找出 A 上的某故障跟 G 节点的关系，二是追查 G 节点异常的原因。这很大程度依赖人工历史经验，不易准确快速定位原因。AIOps 的智能故障诊断方法的做法是利用黄金指标综合进行，做法如下所示：

5. 智能预警

一个很重要的运维手段就是在故障发生之前进行预警，从而减少实际损失。人工的预警方法通常是根据经验，考虑的指标覆盖范围小，且阈值的设置较为困难，容易产生误报和漏报。AIOps 的智能预警可以覆盖上万个指标，且通过机器学习自动学习到相应阈值，而无需人工干预。智能预警如下图所示：

三、快手推荐系统 Dragonfly 架构启发

1. 背景

以推荐系统为例，通常在线推荐系统包括召回，排序，重排三个模块。召回是利用如 ANN 检索，倒排检索算法，将候选项从千万降到十万的数量级；排序是利用 CTR，LTR 等指标，将候选项从十万降到千的数量级；最后重排是利用多样性打散，强插，混排技术将候选项从千降到十的数量级。

为了快速复用，采用的如上图的分离的系统架构，算法人员和架构人员的代码交织在一起，那么如何将业务代码和架构代码进行解耦呢？David Wheeler 说过，所有的计算机问题都可以通过增加一层抽象来解决。

2. 实现方法

快手架构的基本思想是构建了一种 DSL 语言 Dragonfly，让算法人员用类 python 方式开发，而不用关注底层的实现，架构人员专注于用 c++实现底层架构。下图右侧的图就是一个算法人员实现的例子，就是纯 python 代码，容易实现，易于阅读。

具体解决方案是将算法都细分成算子的粒度，如下图所示，所有的人工智能算法都是由各种算子进行组合搭建而成，架构人员负责开发这些算子的实现，算法人员在封装好的算子基础上进行运用。因此算法人员不关注底层实现，专心关注与上层逻辑，去编写 DSL 语言，然后提交配置即可；架构人员不关注上层逻辑，只负责编写底层算子。

在实现这种改进之后，最大的优点就是新场景的接入成本从 7 人日缩减到 1 人日。这种利用算子话粒度解耦的思想是我们是可以借鉴的，我们在做算法开发时，很多代码都交织在一起，不能抽取出来，导致很多重复性的工作。如果把这些算法进行一步步的切分，分成很小的算子粒度，就能够方便进行解耦，是的算法人员可以任意组合拼接算子，实现业务算法。

参考文献：

[1]《Paddle Lite 端侧部署》作者：吴建明

https://www.cnblogs.com/wujianming-110117/p/14398502.html

[2]《架构设计》Paddle-Lite

https://paddlepaddle.github.io/Paddle-Lite/v2.2.0/architecture/

[3]《故障管理场景 AIOps 实践与探索》 作者：陈云

https://ppt.infoq.cn/slide/show?cid=83&pid=3355

[4]《Dragonfly 快手通用策略 DSL 在推荐系统架构的应用和演进》作者：方剑冰

https://ppt.infoq.cn/slide/show?cid=83&pid=3295

[5]《百度飞浆轻量化推理引擎 Paddle Lite 的实现和应用》作者：严春伟

https://ppt.infoq.cn/slide/show?cid=83&pid=3273

原文链接：人工智能应用架构的思考