直播作为近来新兴的互动形态和今年阿里巴巴双十一的一大亮点，其内容风险监控是一个全新的课题，技术的挑战非常大，管控难点主要包括业界缺乏成熟方案和标准、主播行为、直播内容不可控、峰值期间数千路高并发处理、对算法的高实时响应要求等等。
阿里巴巴集团安全部今年在直播管控中的特色在于大量采用人工智能和深度学习等技术，配合优化后的高性能多媒体计算集群，大幅度降低人工审核成本的同时，提升了对内容风险的防控能力。系统在峰值期间成功处理5400路直播视频，以及共计25万场粉丝连连看游戏，对违规内容进行警告或阻断。主要技术体现在直播内容实时过滤以及多媒体处理集群的优化上。
一、直播内容实时过滤
在直播过程中一些主播为了达到吸引眼球，或者推销商品的目的而做出违规的事情。另外，本次双十一引入了买家之间的互动游戏：连连看，玩法是系统随机抽取两个游戏参与者，调起手机前置摄像头拍摄视频传递到对方手机展示。游戏双方比赛干瞪眼、不许笑等动作。游戏的参与者并不会进行实人认证，需要对内容做实时的管控。双十一期间预估高峰期会有5400路直播同时在线，而一个审核人员的极限承受能力大约是60路，需要大约90个审核人员同时在线审核，很浪费人力，并会因为人工因精力不集中而漏过风险内容，这就得靠人工智能技术来全面防控风险。
那么，直播中有哪些风险呢？
我们分析了淘宝直播开播以来的所有处罚记录，以及在互联网抓取的外部直播数据，发现恶性违规集中在色情低俗，以及敏感人物肖像两个方面。因此，我们在对画面内容做风险判断时调用了两个算法服务：视频鉴黄和敏感人脸检测。由此，实现99%的自动审核，只有约1%的视频会流入到人工审核。
1、智能鉴黄技术
智能鉴黄，就是输入一张图片或视频，算法模型返回一个0-100之间的分值。这个分值非线性地标示图片含色情内容的概率：得分99及以上的图片几乎可以肯定是色情图，可以机器自动处理；得分50-99的需要人工审核；得分50以下的认为是正常图，因为50分及以上可以覆盖>99%的色情图片。智能鉴黄还有两个特性：1）将60%以上的色情图片集中在99及以上的分数段，也即机器可以自动处理掉大多数色情风险；2）需要人工审核的图片占比非常低，在淘宝直播场景大约为0.1%。
智能鉴黄的原理是什么呢？
智能鉴黄是一个色情图像智能识别引擎，为不同的场景和用户提供了个性化的多尺度识别能力，识别准确率高达99.6%， 极大地降低了图片内容管控的成本。我们基于深度学习算法构建了多层视觉感知机，采用改进的Inception神经网络层以及多模型级联，实现了快速地识别多尺度色情内容。智能鉴黄的生成具体步骤如下图所示。
智能鉴黄模型生成步骤
1）明确分类标准
上面这张图的步骤里，制定标准与标注数据的难度比训练模型更大一些。因为现实世界是复杂的，不同的人对同一张图片的认识往往不一样。为了制定标准，运营与算法同学一起讨论修订了数次才有了初版，并且在后续打标过程中根据遇到的问题进行了几次增补，标准才稳定下来。
2）收集样本
样本的获取环节在此略过。数据的规模：考察了近2000网站，以及阿里生态体系积累的色情违规case，共计6000+万疑似色情图片，已经完成了1300+万的高质量标注。这一块是智能鉴黄最重要的基石。
3）样本打标
互联网上的内容重复度高，这6000+万图片中必然有相当比例的相同／相似图片，为了节省标注资源，我们使用了图像搜索技术进行去重，大约剩余2300万图片。图搜是我们自己开发的基于局部特征视觉词的针对图像内容的搜索技术，可以检出经过尺寸放缩、剪切、旋转、部分遮挡、颜色变换、模糊等诸多处理后的目标图像，效果如下图所示。
图像搜索引擎找相似图的例子
阿里巴巴开发了高效率的打标平台（mbox），提供了练习与考试功能作为标前的质量控制；提供校验题的方式作为标中的质量控制，能够自动化计算打标者的准确率，并能够按照设置的条件终止低质量标注者的参与资格。我们观察到，即便是熟练而负责的标注者，其错误率仍然在1%左右波动，因此我们使用训练好的模型对打标样本进行判断，如果机器结果与人肉结果不一致则进行复标。这个过程反复进行，确保标注样本的高质量。
样本标注流程示意图
4）模型训练
标注的结果在次日凌晨自动回流到ODPS表中，可随时读取数据进行训练。训练使用了开源的基于Caffe框架的代码，并根据实际情况做了一些修改。第一次训练时使用了大约100万样本，GPU机器单机单卡的情况下训练时间长达近一个月。后来更换了网络结构，并使用了Pluto团队提供的训练平台，实现了多机多卡训练，可以将千万级别样本的训练时间控制在一周以下。
鉴黄模型生成系统示意图
针对直播场景的管控尺度和时效性要求，我们设计了多阶段分类模型，在召回率略有增加的同时，将响应时间降低了约30%。
多阶段的分类模型
连连看游戏上线后，智能鉴黄迅速命中了数个暴露狂，图片不宜展示。还抓取到商家的一些违规行为（医疗广告露点、展示成人用品、展示大尺度图片、着装不正等），图片略去。从违规case看，直播中的色情风险表现形式多样，可能是翻拍屏幕、画报、真人、成人用品、模型等等，姿态与动作也多种多样。
在整个双十一期间，因为色情低俗、着装不整被处罚的直播一共82场，其中算法命中68场，抓取到了100%的色情低俗风险，以及80%以上着装不正的违规（淘宝直播对着装尺度很严格，某些大街上可见的着装也属于违规），而且仅需要审核约0.1%的截图。在风险覆盖和节省审核人力两个方面都取得了成功。
2、敏感人脸检测
直播中的敏感人物管控属于人脸识别中（1：N）的问题，涉及人物载体形式多样，如动漫、印刷品、PS处理、翻拍屏幕等。人像的表情、姿态、光照、距离、遮挡、模糊等均不可控。
检测系统包括敏感人物入库及用户图片查询两大模块。其中敏感人物入库包括特征提取以及索引的建立。用户图片进行查询的时候，系统会返回与被查询人脸最相似的人物图片、名字及相似度，然后根据业务规则判断是否命中敏感人物。数据库由国内外各领域近2W知名人物人像图片组成，并按敏感程度划分不同等级，提供多层次的管控人名列表。
敏感人物识别主要包括两部分技术：一是人脸的特征提取，二是检索系统的构建。我们选用深度学习算法构建模型，采取五层卷积+两层全链接的基础网络结构，并融合年龄+性别等属性，融合回归及分类多种损失函数进行训练。这种multi-data， multi-task的训练方式充分挖掘训练数据的多维度信息，从而构建泛化性能更好的模型。
敏感人物识别技术架构图
简要描述一下索引算法的流程：
- 1、选一组哈希函数，将数据投影到离散的值上。所有的数据按哈希值分桶保存；
- 2、检索时，被查询数据使用相同的哈希函数计算桶编号，取出桶里所有的数据，计算距离，排序，输出。
搜索性能：在百万数据集上，单次查询RT小于10ms，top10近邻正确率90%（以遍历检索为基准）。
算法系统主要用来管控政治敏感人物肖像，以及明星形象冒用，整个双十一期间算法系统命中产生的审核比为约0.01%。算法累计命中1613场直播，其中38场是正确命中。38场中，有17场背景包含管控人物形象，8场主播使用管控人物形象作为面具，7场与人民币相关，2场利用管控人物做广告，3场丑化管控人物，1场新闻类直播。 38场直播以业务管控标准判断有14场违规。
在整个双11期间，一共有15场涉及涉及99名核心管控人物的违规直播，只有1场未能被算法命中，算法整体召回率93.3%。由于众所周知的原因，政治敏感人物肖像的违规case不能展示。下面是一些用户使用明星照片参与连连看游戏的case：
用户冒用明星形象参与连连看游戏的示意图
可能有人会觉得算法命中的准确率不高，这有两方面的原因：
- 1）整体审核比很低，为了保障召回，所以将阈值设置得比较低；
- 2）由于管控人物中包含一些女明星，容易出现主播与明星撞脸的尴尬，比如下面两位女主播很容易被识别为杨幂。
和明星撞脸的女主播
二、多媒体处理集群的优化
为了平衡管控的时效性和计算资源之间的矛盾冲突，在实际操作中，我们对直播流每5秒截帧一次，图片保存在OSS上，同时推送消息给安全部接口。接口层将消息传递到规则层，在这里配置规则，决定截图需要调用的算法，以及对算法返回的结果进行判断，向审核系统发送消息。
直播管控整体系统框图
我们面临的问题是5400路并发视频需要在5秒之内给出反馈，延时过长会错造成风险外露。图片算法服务本身相消耗计算资源多，是系统中的瓶颈，为此我们采取了以下应对手段。
1、通过消息接入解耦应用
同步接入算法服务是最简单的也最容易维护的，但会面临三个主要问题，1）同步接入给接入方带来了更多资源消耗；2）一旦算法服务不正常，会影响主流程。3）图片量已远远超过审核人力的极限，运营只能覆盖一些潜在重点风险视频，非重点风险视频流不需要流入审核。因此，虽然异步接入也会带来维护成本，但最终决定还是采用异步接入。
2、通过异步回调减少接入的成本
收到异步消息后，节点会调用算法服务，如果采用同步调用，会导致很多线程IO阻塞，需要大量的task,从而需要很多节点；采用异步回调服务，task线程可以立即回收，能减少很多task线程，从而节省节点。本项目中节省了约70%的节点。
3、通过批处理增加吞吐
在直播防控中单张截图会调用2个算法，之前的模式是每张图发2个消息。由于内部是可以并行且非阻塞过多个算法的，单张图一个算法和多个算法成本一样，所以我们将单张图调用多个算法的多条消息合并成一条。吞吐翻倍，按qps评估的机器成本也减半。
4、削峰和异常保护
虽然直播的峰值是5400路并发，考虑到截帧是每5秒进行一次，所以不必要按峰值准备容量。我们按照4s来平滑峰值，机器数也可以减少75%。除了常规的限流措施之外，考虑到审核页面每5秒刷新，如果超过4s没处理的消息选择丢弃，可以避免突发的消息堆积造成雪崩。所有的出错消息都会回写入SLS并同步到ODPS，以便之后的排查、分析和恢复。同时，我们将应用部署在两个机房来实现容灾。
算法服务系统架构图
上线之前按照电商图片场景的经验是95%的算法请求在3s之内返回，上线后实测98%的请求在600ms内返回，平均耗时200ms，并且资源消耗更低。虽然两个场景不完全具有可比性，但至少说明我们的算法服务完全胜任直播防控的实时场景。
本文作者：左芬
本文转自雷锋网禁止二次转载，原文链接