Pocochaでの画像審査モデルの内製化とAPI開発【DeNA TechCon 2023】

youtube：https://youtu.be/Nvi4nhmhSGo

概要：
ライブコミュニケーションアプリ Pococha では、健全性を維持のために、規約に違反している配信動画をAIで検知し、その後人間が審査する仕組みを開発しました。
当初は他社のマネージドAPIを利用していましたが、サービス成長に伴いコスト削減のため内製の画像審査モデルに移行しました。
本セッションでは、どのように学習用データを整備したか、またどのようにモデルを開発したか解説します。
また、APIとして提供するにあたって、認証・パフォーマンス面で工夫した点を解説します。SLAの設定や運用の責任分界の設定など、弊社でのDevOpsの一連の流れをご紹介します。

登壇内でのリンク集：
p4, https://ssl4.eir-parts.net/doc/2432/ir_material/196793/00.pdf
p36, https://fastapi.tiangolo.com/ja/async/
p38, https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html

◆ チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

◆ DeNA TechCon 2023 公式サイト
https://techcon2023.dena.dev/

Transcript

1. Pocochaでの画像審査モデルと API開発 Image screening model and API development in Pococha 井本裕(Yutaka Imoto) 夏目亮太(Ryota Natsume)
2. 自己紹介 2 - 井本裕(Yutaka Imoto) - データ本部データ基盤部MLエンジニアリング第二グループ - MLOpsエンジニア / クラウドアーキテクト / プロジェクトリーダー - 2013年よりDeNAにジョイン - グローバル規模のゲームプラットフォーム・アカウントサービスのサーバーサイド開発に従事 - 位置情報システム(GIS)のアルゴリズム開発に従事 - 夏目亮太(Ryota Natsume) - データ本部AI研究開発部第三グループ - AIエンジニア - 2020年よりDeNAにジョイン - 株式会社ZENKIGENにて動画解析AIを用いたプロダクトの立ち上げ - PocochaのCS領域への機械学習活用に従事
3. Table of Contents Pococha でのAI審査のニーズとモデル開発 - AI審査の課題と背景 - モデル開発 Tips 3 API開発 - APIサービングまで - 弊社でのDevOpsの一連の流れをご紹介 - 開発Tips
4. Pococha とは - ライブ配信アプリ - 配信をするライバーと、コメントやアイテムで応援 する リスナーの双方向コミュニケーションサービス - Pocochaの特徴：多様な小規模コミュニティ - 2017年に国内でPocochaを開始し、大きく成長 - 成長フェーズの事業であり、今後も非連続な成長を 目指す 4 source: 個人投資家向け会社説明会 https://ssl4.eir-parts.net/doc/2432/ir_material/196793/00.pdf
5. 課題と背景 5
6. - 戦略・企画 - カスタマージャーニーを考え企画を作る - UXの向上 - リスナーとライバーの最適なマッチングを提供し、 双方のサービス体験品質を向上させる - 健全性の担保 - 配信内容やコメントの健全性の審査を、AIで助ける - 本日の内容 6 PocochaでのAI施策
7. Pocochaでの審査体制 7 Pocochaでは、ユーザーのコミュニティの安心・安全を重視し、様々な施策を実施中 - 審査チーム - 24時間体制で人間が審査を実施 - 審査担当が一つ一つ内容を確認 - 前後の配信や行動を調査した上で、統一的な基準に沿って対応 - 審査や対応内容 - 通報対応 - 配信に違反行為がないか見回り(配信審査) - プロフィールの審査
8. 事前検知の重視 8 より早く違反行為を止めたい立場から、社内での「事前検知」を重視 - 通報を受けて停止 - 事前検知の手段として、配信審査は特に重視。審査チーム内でも一番人員が張られている 目標 - ユーザーにとって安心安全なコミュニティとする - 違反行為を確実に検知される環境にする - ライバーが公平にランキングを競えるようにする
9. 配信監視システム - 人間の審査をAI審査が助ける - Human in the loop - 警告・BANは人間が決定する 9
10. 高リスク画像検知APIの内製化 10 - 配信のキャプチャ画像が何らかの違反カテゴリの画像であるか、OKであるか予測する - NGであれば、人間が優先的に審査 - 当初はAmazon Rekognitionを利用 - DetectModerationLabels - 「暴力的」「性的」「不快」等のカテゴリー - それぞれのスコアをAPIが返す - スコアが一定の値を超えると審査スタッフに通知 - マネージド・サービスであり、導入コストが極めて低かった - 導入決定からリリースまで素早い
11. - 内製化へのモチベーション - 弊社の審査基準と、Amazon Rekognitionの基準が異なる - 弊社の審査基準のほうが、NGとされる範囲が広い - より精度を高めたい - その後サービスグロースにつき、コスト削減のニーズが高まった - また、人間による審査結果を学習用データとして利用可能であった - 高リスク画像検知モデルを開発し、マイクロサービスのいちAPIとして提供することにした - 本日の残りの流れ - 内製モデルの開発 - 内製モデルのAPI提供 高リスク画像検知APIの内製化 11
12. 内製モデルの開発による違反の検知 12
13. 内製モデルの開発による違反の検知 13 このAIモデルを内製する 配信中の画像 AIモデル 推論結果 車載配信：98% （運転しながら配信するという違反） 配信中の画像を入力として、違反しているかどうかを内製のAIモデル判定・検知する
14. モデル開発における課題に対するアプローチ コスト削減、ライブ配信特有の検知対象・精度を課題を、以下のアプローチで解決した 14 コスト削減 ライブ配信特有の検知対象・精度向上 マルチタスクの分類による 複数の不正項目の同時検知 Human-in-the-loopを用いた 効率的な学習データの収集 画像 車載配信 未成年 アダルト CNN MLP 著作権違反
15. モデル開発における課題に対するアプローチ コスト削減、ライブ配信特有の検知対象・精度を課題を、以下のアプローチで解決した 15 コスト削減 ライブ配信特有の検知対象・精度向上 マルチタスクの分類による 複数の不正項目の同時検知 Human-in-the-loopを用いた 効率的な学習データの収集 画像 車載配信 未成年 アダルト CNN MLP 著作権違反 Human-in-the-loopの 実応用について重点的に 苦労した点や学んだ点を共有します
16. モデル開発における課題に対するアプローチ コスト削減、ライブ配信特有の検知対象・精度を課題を、以下のアプローチで解決した 16 コスト削減 ライブ配信特有の検知対象・精度向上 マルチタスクの分類による 複数の不正項目の同時検知 Human-in-the-loopを用いた 効率的な学習データの収集 画像 車載配信 未成年 アダルト CNN MLP 著作権違反 Human-in-the-loopの 実応用について重点的に 苦労した点や学んだ点を共有します
17. - 検出対象ごとに外部APIや内製APIを適用すると、検出対象のラベル分費用が嵩んでしまう - そこで、マルチタスクなモデルを採用して、一度に複数の検出対象について推論した - コストをほぼ一定のまま検知対象を増やすことが可能となった マルチタスクの分類による複数の不正項目の同時検知 17 CNN MLP 車載配信 CNN 画像 MLP 未成年 アダルト 画像 車載配信 未成年 アダルト 外部API CNN MLP 複数の不正項目を同時検知することで、コストを上げずに検知対象を増やすことを可能にした
18. モデル開発における課題に対するアプローチ コスト削減、ライブ配信特有の検知対象・精度を課題を、以下のアプローチで解決した 18 コスト削減 ライブ配信特有の検知対象・精度向上 マルチタスクの分類による 複数の不正項目の同時検知 Human-in-the-loopを用いた 効率的な学習データの収集 画像 車載配信 未成年 アダルト CNN MLP 著作権違反 Human-in-the-loopの 実応用について重点的に 苦労した点や学んだ点を共有します
19. 各種システム ・定期的な見回り ・ユーザからの通報 ・ルールベース ・etc. Human-in-the-loopを用いた効率的な学習データの収集 19 教師データは、審査システムのフローの中で集めるように設計（Human-in-the-loop） - 審査システムの流れ - ① 各種システムや機械学習APIのアラートをトリガーに、審査すべき配信を優先度つきキューに追加 - ② 優先度順に、人間が配信を目視チェックを実施 - ③ ②での審査結果（OK, NGなど）を機械学習モデルの訓練用のデータセットに順次追加 データセット 機械学習API NGの場合 警告、BANなど 訓練に使用 アラート 優先度つきキュー 目視チェック ① ② ③
20. Human-in-the-loopを取り入れるメリット - AIによる完全自動判定ではなく、人間の目視チェックを入れることで、誤対応の確率を下げることができる - 教師データが少なく、機械学習モデルの精度が十分でない場合でも、審査の効率化に用いることができる - 人間が判断した結果をもとに、継続的にモデルを改善することができ、精度の向上が期待できる - 人間による審査がモデル改善のためのアノテーションとなり、審査するほど審査効率が上がっていく 各種システム ・定期的な見回り ・ユーザからの通報 ・ルールベース ・etc. Human-in-the-loopを用いた効率的な学習データの収集 20 データセット 機械学習API NGの場合 警告、BANなど 訓練に使用 アラート 優先度つきキュー 目視チェック 審査効率向上 モデル精度向上 データ数が増える
21. Human-in-the-loopを取り入れるメリット - AIによる完全自動判定ではなく、人間の目視チェックを入れることで、誤対応の確率を下げることができる - 教師データが少なく、機械学習モデルの精度が十分でない場合でも、審査の効率化に用いることができる - 人間が判断した結果をもとに、継続的にモデルを改善することができ、精度の向上が期待できる - 人間による審査がモデル改善のためのアノテーションとなり、審査するほど審査効率が上がっていく 各種システム ・定期的な見回り ・ユーザからの通報 ・ルールベース ・etc. Human-in-the-loopを用いた効率的な学習データの収集 21 データセット 機械学習API NGの場合 警告、BANなど 訓練に使用 アラート 優先度つきキュー 目視チェック 審査効率向上 モデル精度向上 データ数が増える 落とし穴もあるよ！
22. 事前にしっかり設計しないと「審査時につけるラベル」と「学習時に必要なラベル」が一致しないことが多く発生する - せっかく審査時にデータを蓄積しても、モデル学習に利用しづらいデータになってしまっていることがある - 実際にあった「ラベルの不一致」の例を紹介 - ① ラベルの種類の不一致 - 例：検知優先度や頻度、特徴が異なる違反に同じ審査ラベルがついている - ② ラベルの対象の不一致 - 例：画像を入力として学習や推論するが、審査ラベルは配信単位についている Human-in-the-loopを導入する際の難しさ 22
23. 違反している配信を検知するモデルを開発したとする - 検知結果は、一見、精度が高いように見える - しかし、実際には... Human-in-the-loopを導入する際の難しさ - ラベルの種類 23 違反配信 健全な配信 正例 負例 違反スコア → 閾値 推論 学習データ 検知 （閾値以上） ほとんど正解！
24. 問題：検知優先度や頻度、特徴が異なる違反が、同一審査ラベル（例：アダルト）として記録されていることがある - → 稀にしか存在しないが、優先度高く検知すべき配信 を見逃していることがある - 教訓：事前にどのような種類のラベルを審査時につけるかを、審査チームと認識を合わせておくべき Human-in-the-loopを導入する際の難しさ - ラベルの種類 24 正例 負例 違反スコア → 閾値 推論 学習データ 検知 （閾値以上） 頻度が低く検知の 優先度が高い違反配信 頻度が高く 一般的な違反配信 健全な配信 が検知できてない！
25. 問題：検知優先度や頻度、特徴が異なる違反が、同一審査ラベル（例：アダルト）として記録されていることがある - → 稀にしか存在しないが、優先度高く検知すべき配信 を見逃していることがある - 教訓：事前にどのような種類のラベルを審査時につけるかを、審査チームと認識を合わせておくべき Human-in-the-loopを導入する際の難しさ - ラベルの種類 25 頻度が低く検知の 優先度が高い違反配信 頻度が高く 一般的な違反配信 健全な配信 25 正例 負例 違反スコア → 閾値 推論 学習データ 検知 （閾値以上） ほとんど正解！
26. Human-in-the-loopを導入する際の難しさ - ラベルの種類 26 正例 負例 違反スコア → 閾値 推論 学習データ 検知 （閾値以上） 頻度が低く検知の 優先度が高い違反配信 頻度が高く 一般的な違反配信 健全な配信 が検知できてない！ 問題：検知優先度や頻度、特徴が異なる違反が、同一審査ラベル（例：アダルト）として記録されていることがある - → 稀にしか存在しないが、優先度高く検知すべき配信 を見逃していることがある - 教訓：事前にどのような種類のラベルを審査時につけるかを、審査チームと認識を合わせておくべき
27. 今回の対応策：優先度高く検知すべき配信 に対して、追加でラベルを付与して学習することで解決した Human-in-the-loopを導入する際の難しさ - ラベルの種類 27 正例① 正例② 違反スコア② → 閾値 推論 学習データ 検知 （閾値以上） 頻度が低く検知の 優先度が高い違反配信 頻度が高く 一般的な違反配信 健全な配信 も検知できた！ 負例 違反スコア① → 閾値
28. 問題：モデルの推論対象と人間の審査対象が異なることがある - モデルの推論対象：画像が違反に該当するかどうか - 人間の審査対象：配信が違反に該当するかどうか - → 配信の全画像が違反しているとは限らないため、配信に対して付与した審査結果を、そのまま学習に使えない - 教訓：事前にどのような対象（画像・配信等）にラベルをつけるかを、審査チームと認識を合わせておくべき Human-in-the-loopを導入する際の難しさ - ラベルの対象 5 1 4 3 2 6 7 8 9 10 11 12 13 配信内の画像番号 この配信は違反している 7, 8枚目の画像は違反している 違反画像 人間 モデル 健全な画像
29. 今回の対応策：一定のルールで疑惑画像を絞り込んだ後、再度目視でのデータクリーニングを実施 Human-in-the-loopを導入する際の難しさ - ラベルの対象 5 1 4 3 2 6 7 8 9 10 11 12 13 配信内の画像番号 5 1 4 3 2 6 7 8 9 10 11 12 13 配信内の画像番号 5 1 4 3 2 6 7 8 9 10 11 12 13 配信内の画像番号 14 14 14 違反画像 健全な画像 一定のルールで 絞り込み 例：配信が停止される 直前数分間を抽出 目視でチェック
30. ラベルは、二値で問題ないか？ （二値 / 多段階 / カテゴリ） 判断の根拠となる補足情報は必要か？ （他条件や根拠となる事項） 審査時のラベルと学習時のラベルでの違いの典型例 30 ラベルの種類 何に対してラベルをつけるべきか？ （画像 / 配信 / 配信者 / ユーザペア） ラベルの対象 教訓まとめ：審査時に残すラベルの種類や対象について、審査チームと議論して決める
31. 内製モデルのAPI提供 31
32. API開発の話 32 - アーキテクチャ - 運用の責任分界の設定 - 認証 - 非同期処理
33. 33 アーキテクチャ GKE / API Cloud Load Balancing GCS /モデル アプリ サーバー キャプチャ画像 S3 違反画像検知API 画像取得 事業部 Pocochaサーバー AI用 GCP Project 配信
34. アーキテクチャ 34 - 運用主体 - Pococha クライアント・サーバー： 事業部 - 違反画像検知API ： データ本部（筆者所属） - 違反画像検知API - 独立したマイクロサービスとして事業部に提供 - 審査対象のキャプチャ画像は、事業部のS3を参照 - 違反画像検知APIの運用 - アラート対応はデータ本部のエンジニアで担当 - 共通基盤チームと、筆者らPococha AI担当チーム
35. 運用の責任分界点 - 別組織に向けた機能提供であり、運用の責任分界点を事前に決めておくとスムーズ - 事前に決めたこと - 使用性 - APIインターフェース - 性能 - スケーラビリティ - 最大Requests per Second (RPS) - トラフィックが跳ねる場合 - 保守 - 休日・夜間も障害対応が必要か / 推論APIダウン時にはフォールバックが可能か - 長期の連休の場合の連絡体制 - 障害発生時の連絡体制 - スケーラビリティは負荷試験で確認 35
36. 負荷試験の実施 - 負荷試験 - 想定最大QPSを流す - 想定スパイクの再現 - 長時間トラフィックを流しメモリリークチェック - 負荷試験で発見した問題 - FastAPIの非同期処理 - サーバーのパスを割り当てる Path Operationで、 async def を用いていた - 外部との通信、GPUなど、メインスレッドがブロックされたときにスレッドが 止まり、極端に性能が下がる 36 source: https://fastapi.tiangolo.com/ja/async/
37. 負荷試験結果 37 改修前後でレスポンスタイムが改善 改修前 10,000ms以上 改修後 400ms以下
38. GCP GKEからAWS S3へアクセスの認証について - 認証の課題 - 有効期間が長い JSON サービス アカウント キーを保存しているとリスクになる - OpenID Connectを利用し、サービスアカウントなしで認証可能にしています - 永続的なクレデンシャルを利用せず、GCPから AWS IAM Roleが利用 セキュリティ 38 source: h)ps://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html
39. - AWS Rekognitionの利用量を、前月比約５０％にすることができた - 内製化に伴う追加のインフラ費用は、既存の別の画像審査APIとモデルを統合したため、発生せず - 内製化に伴い、高リスク画像検知のPrecisionは47.5%、Recallは44.2%改善した - 引き続き、違反画像検知以外の用途では、Amazon Rekognitionを利用継続中 - 大規模なトレインデータで学習された精度の高いモデル - ユースケースにマッチしている箇所では大変便利 内製化の効果 39
40. まとめ 40
41. - Pocochaでの、コミュニティの安全性・健全性の維持・向上のための、AI施策を共有しました - 違反検知のための、内製モデルの開発事例をご紹介しました - 内製モデルをAPIとして開発提供する、MLOpsの一連の流れをご紹介しました - 今後も新機能を開発予定であり、採用強化中です！ 41 まとめ