AoE( AI on Edge , https://github.com/didi/AoE ) 是滴滴近期开源的终端侧 AI 集成运行时环境 ( IRE )。
随着人工智能技术快速发展,近几年涌现出了许多运行在终端的高性能推理框架,例如 TensorFlow Lite,在实时性、安全性上给开发者带来更多支持和选择,极大的优化了用户的使用体验,但当我们想要在终端侧落地一些具体的 AI 业务时,会发现有些不得不面对的问题:
除了要做推理框架选型,还需要关注数据预 / 后处理逻辑的稳定性,模型分发使用时的包大小、数据安全等问题。这也正是 AoE 的设计初衷,希望完善模型生产到落地应用链路上的各个环节,提供整套的工具支撑体系,帮助开发者在终端轻松部署 AI 模型。以下我们通过滴滴内部一个具体实例应用,介绍 AoE 如何搭档 TensorFlow Lite ,让终端侧 AI 开发变得更加简单。
案例背景
滴滴普惠安全产品技术团队通过手机传感器数据的实时分析,建立了精准、可量化的驾驶行为识别能力,以此为基础刻画精细的安全画像,建立全方位的集驾驶安全、骑行安全、异常检测、流程化策略为一体的识别解决方案,为用户提供精准、便捷的安全应用体系。借助 Google 的深度学习框架 TensorFLow ,我们对算法进行改造优化,极大地提升模型的识别效率和准确率。
模型介绍
通过 TensorFlow 来搭建卷积神经网络( Convolutional Neural Network,CNN )流式处理手机传感器数据,实时识别司机危险驾驶行为。
基于手机传感器识别行车状态,有很多问题需要处理:
- 不同机型间数值差异
- 手机姿态变化导致的模型环境变化校准
- 晃动导致的模型误触发
- 实时数据量大,计算复杂度高
- …
以数据差异校准为例,由于不同设备间传感器数据差异较大,会影响模型最终效果,需要对其进行校准,保证模型输入数据的一致性。
通过自研机型校准滤波算法的处理,不同的机型可以得到一致的数据表现。
AoE的接入使用
稳定性考虑
如前面介绍,我们在数据交给 TensorFlow Lite 执行推理前后,有很多的数据处理逻辑,出于性能和算法保密性考虑,我们把滤波算法等处理逻辑放在 Native 层实现。
众所周知,Android 平台开发一个重要的问题是机型适配,一旦应用在某款机型上面崩溃,造成的体验损害是巨大的。有数据表明,因为性能问题,移动 App 每天流失的活跃用户占比 5 %,这些流失的用户,6 成的用户选择了沉默,不再使用应用,3 成用户改投竞品,剩下的用户会直接卸载应用。因此,对于一个用户群庞大的移动应用来说,保证任何时候App主流程的可用性是一件最基本、最重要的事情。让 Native 操作运行在独立进程中,同时保证了推理的稳定性和主进程的稳定性,即偶然性的崩溃不会影响后续的推理操作,且主进程任何时候不会崩溃。
安全性考虑
TensorFlow 训练出的 pb 模型文件和转换在 TensorFlow Lite 使用的 tflite 文件,可以比较方便的看到网络层信息,在终端侧分发应用时,无法有效保障数据资产安全。
AoE 提供了文件加密机制,方便对模型文件进行快速解密,同时支持自定义加解密算法,示意图如下:
数据加密方案
- 文件加密
首先自选数据加密方案对模型文件进行加密(AoE 内置 AES 加密),生成一个加密文件 - 生成头文件
AoE 对加密文件添加 21 byte 的文件头,分别表示文件加密方案的版本,加密文件的文件长度以及加密文件的 MD5 - 字节混淆
指定一个步长(如 1024 byte),从加密文件头进行遍历,将读取数据切片的特定位(通常是第一位)与文件头片段里的字节依次互换。以此混淆了文件原信息。
数据解密方案
与加密对应的解密模块,通过已知的步长、置换位索引、加密私钥等信息配套的对文件进行信息重建和解析,得到源文件,AoE 以内存态运行,直接将模型源文件装载进推理框架进行执行。
通过这样简单的文件加密规则,既能保障加密实现的高效运行,又能在不同场景下拓展支持多套算法方案。
上线效果
基于 TensorFlow 的优化改造,大大降低了我们算法开发和维护的成本。模型集成 AoE 在滴滴乘客端、司机端上线应用后,没有出现一例因推理执行导致应用主进程崩溃的 Case,稳定支持了多个版本加密模型在 APP 中的集成使用。
总结展望
我们团队会持续完善终端侧 AI 落地的工具支撑体系,特别是对被广泛使用的 TensorFlow 的支持,帮助开发者轻松部署模型,更好的赋能业务。
欢迎关注github,也可添加小助手微信加入AOE开源交流群。
小助手微信:
普惠产品技术github网址:
https://github.com/didi/AoE