【腾讯分享】游戏图像异常检测AI实践

41次阅读

共计 2589 个字符,预计需要花费 7 分钟才能阅读完成。

AI 技术在图像检测和识别上虽然已经取得了很多突破,但是在游戏图像异常的 AI 检测中,由于受到非真实场景、缺乏大量学习样本等多样化因素的制约,使得游戏图像异常的 AI 检测面临着巨大难度。本期内容,腾讯 Turing Lab 副总监张力柯将分享游戏图像异常 AI 检测的实践经验。
问题简述
AI 技术在图像上有很多的突破,但是对于游戏图像的异常检测依然存在很多难点。因为游戏不是真实的场景,它不像无人车或者人脸识别,有大量真实的场景和数据集,游戏图像异常检测缺乏大量可供训练的数据集。

其次游戏图像异常的原因和现象都是多样化的。游戏图像产生异常,可能是硬件、游戏引擎、美术资源、业务代码等多种原因导致的;游戏图像异常的表现也是多种多样,如黑屏 / 白屏、色块色条、贴图错误、开发遗留信息、像素错误等。
早期尝试及难点分析
腾讯从 2016 年就开始着手花屏等游戏图像异常问题的研究。最开始采用传统的图像分析方法,比如,色块、几何特征等。后来尝试过简单的机器学习,但效果不是特别好。

效果不好主要有以下三个难点问题:

算法方案
腾讯从 2017 年开始尝试使用深度学习方案,用 CNN 和 GMM 两种方法,取得了一定效果。游戏场景是多变的,因此需要对每个场景建立模型,这个是比较困难的。我们首先用 GMM 生成异常图像,这个听起来高大上,但效果并不好。因为很多游戏异常画面是有先验知识的,不至于用深度学习来分辨。第二个是场景分类,在 2018 年年初我们采用了手工分类的方法,从粗粒度分类到精细分类,最后取得了较好的效果。

以上为我们的算法整体框架。用户上传视频后使用算法进行画面分类,把画面分成登录画面、战斗画面等,然后生成异常样本。因为我们要求上传的游戏视频是正常的,不包含任何异常画面。我们用算法来生成异常画面,等负样本和正样本数据比例达到 3:7 或者 4:6,才能进行正常的深度学习。

自动场景划分怎么实现?首先对上传的视频进行帧提取,然后进行图像特征的提取。我们用的方法是提取局部特征,再进行图像全局描述。深度学习需要有足够的训练集去标注,然后需要长时间的训练。如果对每一个游戏都要做这个工作,这个工作量就太大了。通过这个方法,可以达到较好的效果,我们通过聚类,将图片分成不同的局部,自动切分成不同的场景,尽量达到足够的效果。
这是工程实践与服务实践、学术方法与工程思路很好的平衡。大家可能会想深度学习可不可以避免人工设计,但是有多少 AI 就有多少人工,深度学习的负面作用就是需要标记很多东西,需要做好取舍。

划分了场景以后生成异常图片,常见的就是图片错位、色块、雪花等。异常样本归纳起来就比较好做了,因为生成的图片叠加,色块、大小、颜色都可以自己控制。然后开始对图片进行二分,用 CNN 的模型。CNN 的模型比较常见,没有什么太多可以说的。我们在输入的时候是把图片做成 80×45 这样的小图片,是为了增加处理速度。

在腾讯几个主流游戏上,AI 异常图片识别的准确率达可以到 99%,这是实验数据,在正式的实际业务应用中,我们会发现效果没有这么好。主要是因为游戏版本变化很大,经常存在画面的调整,而使用者无法每天都训练新的模型。、

工程部署
工程部署采用了比较常见的方式,下面是我们工程部署的整体框架。我们分成线下训练、线上模拟两部分。它通过消息队列,传到不同的工作组。这是一整套的算法方案,从抽取帧,到聚类,再到 CNN 模型的训练。

工程的应用和算法研究的不同。算法研究主要讲究数据并行和模型并行,很少提任务并行。我们采用的思路是任务并行。因为我们的目的是并发处理不同的训练任务,不在于每个任务多快,而在于可以一起处理。我们的思路跟机器学习加速的思路是不一样的。
在部署的时候,我们开始使用用模型直接调用,发现存在高并发的问题。后来我们采用 TensorFlow 分布式部署,将前面的模型转换到 TensorFlow,发现效果不错。但是 TensorFlow 会对服务器的内存造成很大的压力,我们对场景建立模型,准确度越高,场景就越多,系统内存压力就越大。

在工程部署时有哪些那点问题呢?第一个是模型管理,因为腾讯的游戏数量繁多,游戏细分场景也很多,只靠 TensorFlowServing 是不够的,还需要自己封装。其次就是模型内存占用的问题,因为单一模型占用内存就可以达到上百 M,游戏所有识别模型的数量可以达到数十甚至上百个,内存压力会很大。第三就是模型更新的问题,是自动更新还是重启服务,自己开发的话会有问题。TensorFlow 在最新的版本里提供了模型更新的功能,这个问题也解决了。

TensorFlowServing 如何部署?Stateless service 可以作为集群部署,然后使用 Haproxy 进行识别请求分发。期初,我们考虑过一个服务器服务多个游戏来节约内存,但是这样容易把逻辑搞混,而且我们无法知道游戏后面的模型会不会增加。因为有的游戏随着游戏的不断运行,它可能会增加不同的关卡、玩法和不同的场景,它的模型会慢慢的变大。这时再动态修改配置就会很麻烦。后来我们进行了简化,每个 TensorFlowServing 就读一个游戏的模型,这些模型可能是几十个、上百个。总体思路是一个服务器对应一个游戏。

这是部署之后的负载能力,我们平时通常保持 100 到 200 TF Serving Pod,平时测试也是并发 100 到 200 部手机。瓶颈不在于服务器的问题,在于带宽,因为我们是做图片识别,传进来的是 100 个不同分辨率的手机,有时候传输的是原图,对带宽的要求是比较高的。我们使用的是 Kubernetes based,它可以很方便的将我们的负载能力扩展到上千。
总结
前面分享了我们目前的一些实践方案和成就,主要讲的是异常画面如何通过 AI 去检测识别。后面我们想实现的功能是从画面异常到功能异常的 AI 检测。
比如,你在游戏里面开枪发现子弹可以穿墙击中敌人,或者说你放了个大招,但是特效没有出来,如何去判断这个功能的异常?在游戏开发的过程中,很容易发现这些问题。怎么识别这些问题,需要跟游戏的特性和游戏的策划更深入的了解。
此外,对于未知画面的识别,比如弹窗或者是外部的运营画面弹出,这也是我们要探索的方向。
现在全球都没有一个完整的游戏画面用来做机器学习的数据集。以后我们累积更多数据集时,我们可以把这些数据集开源出来,跟大家一起进行研究,做到游戏方面虚拟世界的 Engine,做到游戏世界广泛的图象识别。

正文完
 0