支撑ProtectionAI的幕后技术故事
- 8月9日
- 讀畢需時 6 分鐘
感谢大家一直以来对PAPS活动的支持。
这次为大家介绍一下PAPS正在开发的"ProtectionAI"背后的一些技术故事。
为了持续寻找受害影像，必须不间断地收集互联网上海量的图片和视频、检测人脸并进行比对。
这部分工作平时不容易被看到，但为了让ProtectionAI运转，其实叠加了各种各样的技术巧思。
■ 什么是ProtectionAI
未经本人同意被拍摄或在互联网上扩散的私密性影像（NCII），即使删除一次，也常常会被反复发布到其他网站和页面。ProtectionAI是这样一个系统：基于希望使用者本人提供的面部照片，将面部特征数值化，在互联网上寻找可能拍有其本人的图片和视频，并连接到删除请求。
为此，需要持续核查海量的图片和视频，检测其中是否有人脸，并比对特征。
让这一"持续搜寻"的处理不停摆，关系到受害者的持续恢复。
■ 支撑图像视频收集的"Paprika"
在之前的通讯中，我们介绍过PAPS开发的收集系统"Paprika"。Paprika是被称为"爬虫"的系统，自动巡回互联网页面收集图片和视频。开发不断推进，终于接近完成形态。
目前在约150台VM（虚拟机）上常时运行约300个Chrome浏览器获取数据。不过，每个网站的结构各不相同。
在某个网站能轻松获取图片的方法，在另一个网站完全行不通，这并不罕见。
因此Paprika运用了名为"Code-Gen Loop（代码生成循环）"的机制。
这一机制让被称为LLM的AI编写程序、实际运行、确认结果，若不成功则自动反复修正。ChatGPT等也是利用LLM的服务之一。
例如，当无法顺利从某个网站获取图片或视频时，AI会用Python编程语言编写代码。执行失败后，再根据结果重写代码，不断改进直到能够获取。
话虽如此，每查看一个网页就运行一次AI，费用将十分庞大。因此，一旦某个程序成功获取，就将其保存为可在同一网站反复使用的"技能"。下次调查该网站的其他页面时，就无需让AI从头编写程序。
将AI思考的部分与重复使用已学会方法的部分分开，从而高效巡回大量页面。
■ 面部特征数据突破8,000万条
ProtectionAI用于比对的面部特征数据已超过8,000万条，相当于每天88万张图片（每分钟学习约600张）。
每一条数据都是找出所需图片和视频的线索。另一方面，从互联网收集的图片中不仅有照片，也包含插画等。人脸检测系统有时会把并非真实人物的插画判断为"人脸"，使比对中混入不必要的数据。
这类"噪声"越多，搜寻所需数据的处理负担就越重。
因此，我们目前也在开发自动识别并去除这类噪声的专用AI模型。
■ 幕后① 从视频中找人脸的处理非常"重"
在ProtectionAI的各项处理中，视频尤其艰难。
静态图片只需分析一张即可，而视频是由大量连续静态帧构成的。
因此，要在一部视频中寻找人脸，必须逐帧分析构成视频的众多画面。
如果只用CPU处理，即便是高性能CPU，同时分析几部视频就会达到处理极限。
于是我们投入了擅长图像处理和大规模并行计算的"GPU"。
使用GPU后，视频和图片的处理效率远高于仅用CPU。但增加GPU并不能解决一切。
为了持续向GPU输送大量数据，必须同时提速"存储位置"和"数据传递机制"。
■ 幕后② 用RAM跨越SSD之"墙"
ProtectionAI以高速读写非常大量的数据。
因此，消费级SSD（存储硬盘）不仅速度，"耐久性"也成了问题。在PAPS的运用环境中，持续大量写入曾在约半年内就达到SSD写入寿命上限。SSD读写跟不上时，即使CPU和GPU有余力，系统整体的处理速度也无法提升。
于是我们决定把临时保存处理中数据的"MinIO"系统放在RAM而非SSD上运行。RAM就是通常电脑里所说的"内存"，读写速度远快于SSD。当然，存在RAM里的数据断电即失。但这里存放的是处理过程中的临时数据，需要时可从原始数据重新生成，即使丢失也能恢复。
此外，约300个Chrome浏览器的大量读写也造成SSD速度下降并影响寿命。于是Chrome使用的临时数据也改用被称为"RAM Disk"的内存存储区域。
这样既改善了数据读写速度，也大幅减轻了SSD负担。当然，代价是需要大量RAM。而且目前服务器内存的采购成本也是一大难题：一年前约10万日元购入的96GB DDR5 RDIMM，如今有的价格已涨到约9倍。
仅靠新品凑齐所需容量并不现实。于是我们从eBay等收购2015年前后销售的二手服务器部件（因当年部件已绝版，为适配现今标准甚至用台钻打孔等土办法），以及二手DDR4 LRDIMM，增加了约1TB内存。经过这些努力，目前整个系统运用着约2.4TB的内存。在光鲜的AI技术背后，二手服务器和二手内存其实也在大显身手。
■ 幕后③ 明明是万兆线路，速度却上不去？
ProtectionAI和Paprika要收集大量图片和视频，通信量逐年增长。于是我们把互联网线路换成最高10Gbps的光纤，内部网络和主要服务器也更新为支持10Gbps。然而实际运用中，通信速度却停在2～3Gbps附近。查看监控系统发现，路由器上出现了大量丢包。
深入调查后发现，处理IPv4通信的转换负荷集中，导致路由器CPU的一部分持续满载。于是我们决定用基于Linux的开源路由器系统"VyOS"自己打造路由器。
由于已经购买过昂贵的路由器，预算有限。我们以二手服务器部件为主在eBay上采购，花费约6万日元。从技术博客查找连接所需的设置、切换前夕发现设置脚本的重大bug……过程并不轻松。即便如此，我们还是在凌晨4点以约30分钟的断网完成了切换。
结果，平均通信量从约1.14Gbps增至2.17Gbps，此前约6.8%的丢包率也降到几乎0%。
与其说是"提速了线路"，不如说是消除了此前在路由器处发生的"拥堵"。在ProtectionAI中，不只是CPU和GPU，SSD、RAM、网络等任何一处堵塞，整体处理都会变慢。
我们正一个个改善这些不易察觉的瓶颈，打造能稳定持续搜寻更多图片和视频的环境。
■ 幕后④ 统筹十台规模设备的自研流水线
即使有很多服务器和GPU，如果各自为政，也无法发挥足够性能。"把哪项工作交给哪台服务器""处理完成后接下来运行什么"——需要一个为整体做交通疏导的机制。
像这样协调多台计算机管理处理的做法称为"编排"（orchestration，可以想象乐团指挥）。世上也有"Ray"等著名的分布式处理系统，但PAPS试用后发现，对于当前用途和十台左右的规模来说功能过于庞大，有些地方并不合拍。于是我们开发了贴合ProtectionAI规模和处理内容的自研流水线系统。
它一边确认各服务器和GPU的状态，一边进行"把下一项处理交给空闲设备"的交通疏导。
在打造这一机制的过程中，我们也撞上了一个大问题。
处理量不稳定，时快时慢地"振荡"，GPU时常陷入等待而停转。即使有高性能GPU，如果供给工作的一方跟不上，宝贵的计算能力也无法用尽。
于是我们引入了类似汽车换挡的思路。起步时和高速行驶时适合的挡位不同。同样地，我们引入了根据系统处理状况改变GPU工作分配方式的机制。
结果，我们得以在抑制处理波动的同时稳定运转GPU，持续处理更多的图片和视频。
■ 让技术服务于受害者
在ProtectionAI的开发中，我们面对的不只是AI模型本身，还有：
"如何收集海量的图片和视频"
"如何快速分析大量视频"
"如何让设备不停歇地持续运转"
等各种课题。
每一项也许都是朴素的改进。
但正是这些积累，让我们能更快、更持续地搜寻更多图片和视频。而这一切的尽头，是让因违背本人意愿扩散的性影像而受害的人，能早一点连接到支援。
今后我们也将继续报告ProtectionAI的开发进展及其幕后故事。
恳请大家继续支持PAPS的活动。
