为了不在直播中看到少儿不宜的景象，阿里做了这些(3)

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，以便之后的排查、分析和恢复。同时，我们将应用部署在两个机房来实现容灾。

算法服务系统架构图

（编辑：ASP站长网）