ProtectionAIを支える、舞台裏の技術のはなし
- 5 時間前
- 読了時間: 9分
いつも、ぱっぷすの活動をお支えいただき、ありがとうございます。
今回は、ぱっぷすが開発を進めている「ProtectionAI」について、少し技術的な舞台裏をご紹介します。
被害画像を探し続けるためには、インターネット上の膨大な画像や動画を集め、顔を検出し、照合する作業を、途切れることなく続けなければなりません。
普段は表から見えにくい部分ですが、実はProtectionAIを動かすためには、さまざまな技術的な工夫が積み重なっています。
■ ProtectionAIとは
本人の同意なく撮影されたり、インターネット上に拡散されたりした私的な性的画像・動画（NCII）は、一度削除されても、別のサイトやページに繰り返し投稿されることがあります。ProtectionAIは、利用を希望する当事者ご本人から提供された顔写真をもとに、顔の特徴を数値化し、その方が写っている可能性のある画像や動画をインターネット上から探し、削除要請につなげるためのシステムです。
そのためには、膨大な数の画像や動画を継続的に確認し、そこに顔が写っているかを検出し、特徴を照合していく必要があります。
この「探し続ける」処理を止めないことが、被害を受けた方の継続的な被害の回復につながります。
■ 画像や動画の収集を支える「Paprika」
以前のメルマガでは、PAPSが開発している収集システム「Paprika（パプリカ）」をご紹介しました。Paprikaは、インターネット上のページを自動的に巡回し、画像や動画を収集する「クローラー」と呼ばれるシステムです。開発も進み、ようやく完成形が見えてきました。
現在は、約150台のVM（仮想マシン）の上で、約300個のChromeブラウザを常時動かしながらデータを取得しています。ただ、ウェブサイトの構造はそれぞれ異なります。
あるサイトでは簡単に画像を取得できても、別のサイトでは同じ方法がまったく通用しない、ということも珍しくありません。
そこでPaprikaでは、「Code-Gen Loop（コード生成ループ）」という仕組みを活用しています。
これは、LLMと呼ばれるAIにプログラムを書かせ、実際に動かし、その結果を確認して、うまくいかなければ修正する、という作業を自動的に繰り返す仕組みです。ChatGPTなども、LLMを利用したサービスの一つです。
例えば、あるウェブサイトから画像や動画をうまく取得できなかった場合、AIがPythonというプログラミング言語でコードを作成します。実行して失敗すれば、その結果をもとにコードを書き直し、取得できるまで改善していきます。
とはいえ、ウェブページを1ページ確認するたびにAIを動かしていては、膨大な費用がかかってしまいます。そこで、一度うまく取得できたプログラムは、同じウェブサイトで繰り返し使える「スキル」として保存します。次に同じサイトの別のページを調べるときには、AIに一からプログラムを書かせる必要がありません。
AIに考えてもらう部分と、一度覚えた方法を繰り返し使う部分を分けることで、大量のページを効率よく巡回できるようにしています。
■ 顔の特徴データは8,000万件を突破
ProtectionAIで照合に使う顔の特徴データは、8,000万件を超えました。1日あたり88万枚の画像（学習1分間に600枚程度）になります。
一つひとつのデータが、必要な画像や動画を見つけ出すための手がかりになります。一方で、インターネットから収集した画像の中には、写真だけでなくイラストなども含まれています。顔検出システムが、実在する人物ではないイラストなどを「人の顔」と判断してしまい、照合には不要なデータが混ざることもあります。
こうした「ノイズ」が増えるほど、必要なデータを探す処理にも余計な負荷がかかります。
そこで現在、こうしたノイズを自動的に見分けて取り除くための、専用のAIモデルも開発しています。
■ 舞台裏① 動画から顔を探す処理は、とても「重い」
ProtectionAIの処理の中でも、特に大変なのが動画です。
静止画であれば1枚の画像を調べれば済みますが、動画は大量の静止画が連続してできています。
そのため、1本の動画の中から顔を探すには、動画を構成している多くのコマを次々に解析しなければなりません。
CPUだけでこの処理を行うと、高性能なCPUを使っても、複数の動画を同時に解析しただけで処理能力がいっぱいになってしまいます。
そこで投入したのが、画像処理や大量の計算を同時に行うことを得意とする「GPU」です。
GPUを使うことで、CPUだけの場合と比べ、動画や画像をはるかに効率よく処理できるようになりました。しかし、GPUを増やせばそれだけですべて解決するわけではありません。
大量のデータをGPUへ送り続けるためには、「保存する場所」と「データを渡す仕組み」の両方を高速化する必要がありました。
■ 舞台裏② SSDの「壁」を、RAMで乗り越える
ProtectionAIでは、非常に大量のデータを高速で読み書きします。
そのため、一般向けのSSD（ハードディスクのこと）では、速度だけでなく「耐久性」も問題になりました。ぱっぷすの運用環境では、大量の書き込みが続くことで、半年ほどでSSDの書き込み耐久性の上限に達してしまうこともありました。SSDへの読み書きが追いつかなければ、CPUやGPUに余力があっても、システム全体の処理速度は上がりません。
そこで、処理中のデータを一時的に保存する「MinIO」というシステムを、SSDではなくRAM上で動かすことにしました。RAMは、通常パソコンで「メモリ」と呼ばれているものです。SSDよりもはるかに高速にデータを読み書きできます。もちろん、RAMに保存したデータは、電源が切れると消えてしまいます。しかし、ここに置いているのは処理途中の一時的なデータです。必要になれば元のデータからもう一度作ることができるため、消えても復元できます。
さらに、約300のChromeブラウザについても、大量の読み書きによってSSDの速度低下や寿命への影響が起きていました。そこでChromeが使用する一時データについても、「RAM Disk」と呼ばれるRAM上の保存領域を使うようにしました。
これによって、データの読み書き速度を改善するとともに、SSDへの負担も大きく減らすことができました。ただし、当然ながら、その分だけ大量のRAMが必要になります。しかも現在は、サーバー向けメモリの調達コストも大きな課題です。1年前に約10万円で購入した96GBのDDR5 RDIMMが、現在では約9倍の価格になっているものもあります。
新品だけで必要な量をそろえることは現実的ではありません。そこで、10年前の2015年頃に販売されていた中古サーバー部品（当時の部品がなく、今の基準に合わせるためホール盤で穴をあけたりアナログなことをしています）や、中古のDDR4 LRDIMMをeBayなどから買い集め、約1TB分のメモリを追加しました。こうした工夫を重ね、現在はシステム全体で約2.4TBのメモリを運用しています。華やかなAI技術の裏側で、実は中古サーバーや中古メモリも大活躍しています。
■ 舞台裏③ 10ギガ回線なのに、速度が出ない？
ProtectionAIやPaprikaでは、大量の画像や動画を収集するため、通信量も年々増えています。そこで、インターネット回線を最大10Gbpsの光回線に変更し、内部ネットワークや主要サーバーも10Gbps対応に更新しました。ところが、実際に運用すると通信速度は2〜3Gbps付近で頭打ちに。監視システムを確認すると、ルーターで大量のパケットロスが発生していました。
詳しく調べると、IPv4通信を扱うための変換処理に負荷が集中し、ルーターのCPUの一部だけが常に限界まで使われていることが分かりました。そこで、Linuxベースのオープンソースルーター「VyOS」を使い、ルーター自体を作り上げることにしました。
既に高額なルーターを購入していることもあり、予算を割けない。そのため、中古のサーバー用部品を中心にEbayで集め、費用は約6万円。接続に必要な設定を技術ブログから調べたり、切り替え直前に設定スクリプトの重大なバグが見つかったりと、簡単ではありませんでした。それでも、深夜4時に約30分の通信停止で切り替えを完了。
その結果、平均通信量は約1.14Gbpsから2.17Gbpsへ増加し、それまで約6.8％発生していたパケットロスも、ほぼ0％になりました。
これは単に「回線を速くした」というより、それまでルーターのところで起きていた「渋滞」を解消した結果です。ProtectionAIでは、CPUやGPUだけでなく、SSD、RAM、ネットワークなど、どこか一つが詰まっても全体の処理が遅くなります。
こうした見えにくいボトルネックを一つずつ改善し、より多くの画像や動画を安定して探し続けられる環境を整えています。
■ 舞台裏④ 10台規模の機材を束ねる、独自のパイプライン
たくさんのサーバーやGPUがあっても、それぞれがバラバラに動いていては、十分な性能を発揮できません。「どのサーバーに、どの仕事を任せるのか」「処理が終わったら、次に何を動かすのか」こうした全体の交通整理をする仕組みが必要です。
このように、複数のコンピューターを連携させて処理を管理することを「オーケストレーション」（音楽のオーケストラの指揮者のイメージ）と呼びます。世の中には「Ray」など、有名な分散処理のためのシステムもあります。しかし、ぱっぷすで試したところ、現在の用途や10台前後という規模に対しては機能が大がかりで、うまくかみ合わない部分がありました。そこで、ProtectionAIの規模と処理内容に合わせた独自のパイプラインシステムを開発しました。
各サーバーやGPUの状態を確認しながら、「空いている機材に次の処理を渡す」という交通整理を行う仕組みです。
▼ 技術ドキュメントhttps://paps-jp.github.io/pipeline/
この仕組みを作る過程でも、一つ大きな問題にぶつかりました。
処理量が一定にならず、速くなったり遅くなったりする「振動」が起き、GPUがときどき処理待ちになって止まってしまったのです。高性能なGPUがあっても、GPUに仕事を渡す側が追いつかなければ、せっかくの計算能力を使い切ることができません。
そこで取り入れたのが、自動車のギアチェンジのような考え方です。車が発進するときと高速で走っているときでは、適したギアが違います。同じように、システムの処理状況に応じてGPUへの仕事の割り振り方を変える仕組みを導入しました。
その結果、処理の波を抑えながらGPUを安定して動かせるようになり、より多くの画像や動画を継続的に処理できるようになりました。
■ 技術を、被害を受けた方のために
ProtectionAIの開発では、AIのモデルそのものだけでなく、
「どうやって膨大な画像や動画を集めるか」
「どうすれば大量の動画を速く解析できるか」
「どうすれば機材を止めずに動かし続けられるか」
といった、さまざまな課題と向き合っています。
ひとつひとつは地味な改善かもしれません。
しかし、その積み重ねによって、より多くの画像や動画を、より速く、継続的に探せるようになります。そして、その先にあるのは、本人の望まない性的画像や動画の拡散によって被害を受けている方を、少しでも早く支援につなげることです。
これからも、ProtectionAIの開発の様子や、その舞台裏についてお届けしてまいります。
引き続き、ぱっぷすの活動へのご支援を、どうぞよろしくお願いいたします。
