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

Slide 1

Slide 1 text

Pocochaでの画像審査モデルと API開発 Image screening model and API development in Pococha 井本裕(Yutaka Imoto) 夏目亮太(Ryota Natsume)

Slide 2

Slide 2 text

自己紹介 2 - 井本裕(Yutaka Imoto) - データ本部データ基盤部MLエンジニアリング第二グループ - MLOpsエンジニア / クラウドアーキテクト / プロジェクトリーダー - 2013年よりDeNAにジョイン - グローバル規模のゲームプラットフォーム・アカウントサービスのサーバーサイド開発に従事 - 位置情報システム(GIS)のアルゴリズム開発に従事 - 夏目亮太(Ryota Natsume) - データ本部AI研究開発部第三グループ - AIエンジニア - 2020年よりDeNAにジョイン - 株式会社ZENKIGENにて動画解析AIを用いたプロダクトの立ち上げ - PocochaのCS領域への機械学習活用に従事

Slide 3

Slide 3 text

Table of Contents Pococha でのAI審査のニーズとモデル開発 - AI審査の課題と背景 - モデル開発 Tips 3 API開発 - APIサービングまで - 弊社でのDevOpsの一連の流れをご紹介 - 開発Tips

Slide 4

Slide 4 text

Pococha とは - ライブ配信アプリ - 配信をするライバーと、コメントやアイテムで応援するリスナーの双方向コミュニケーションサービス - Pocochaの特徴：多様な小規模コミュニティ - 2017年に国内でPocochaを開始し、大きく成長 - 成長フェーズの事業であり、今後も非連続な成長を目指す 4 source: 個人投資家向け会社説明会 https://ssl4.eir-parts.net/doc/2432/ir_material/196793/00.pdf

Slide 5

Slide 5 text

課題と背景 5

Slide 6

Slide 6 text

- 戦略・企画 - カスタマージャーニーを考え企画を作る - UXの向上 - リスナーとライバーの最適なマッチングを提供し、双方のサービス体験品質を向上させる - 健全性の担保 - 配信内容やコメントの健全性の審査を、AIで助ける - 本日の内容 6 PocochaでのAI施策

Slide 7

Slide 7 text

Pocochaでの審査体制 7 Pocochaでは、ユーザーのコミュニティの安心・安全を重視し、様々な施策を実施中 - 審査チーム - 24時間体制で人間が審査を実施 - 審査担当が一つ一つ内容を確認 - 前後の配信や行動を調査した上で、統一的な基準に沿って対応 - 審査や対応内容 - 通報対応 - 配信に違反行為がないか見回り(配信審査) - プロフィールの審査

Slide 8

Slide 8 text

事前検知の重視 8 より早く違反行為を止めたい立場から、社内での「事前検知」を重視 - 通報を受けて停止 - 事前検知の手段として、配信審査は特に重視。審査チーム内でも一番人員が張られている目標 - ユーザーにとって安心安全なコミュニティとする - 違反行為を確実に検知される環境にする - ライバーが公平にランキングを競えるようにする

Slide 9

Slide 9 text

配信監視システム - 人間の審査をAI審査が助ける - Human in the loop - 警告・BANは人間が決定する 9

Slide 10

Slide 10 text

高リスク画像検知APIの内製化 10 - 配信のキャプチャ画像が何らかの違反カテゴリの画像であるか、OKであるか予測する - NGであれば、人間が優先的に審査 - 当初はAmazon Rekognitionを利用 - DetectModerationLabels - 「暴力的」「性的」「不快」等のカテゴリー - それぞれのスコアをAPIが返す - スコアが一定の値を超えると審査スタッフに通知 - マネージド・サービスであり、導入コストが極めて低かった - 導入決定からリリースまで素早い

Slide 11

Slide 11 text

- 内製化へのモチベーション - 弊社の審査基準と、Amazon Rekognitionの基準が異なる - 弊社の審査基準のほうが、NGとされる範囲が広い - より精度を高めたい - その後サービスグロースにつき、コスト削減のニーズが高まった - また、人間による審査結果を学習用データとして利用可能であった - 高リスク画像検知モデルを開発し、マイクロサービスのいちAPIとして提供することにした - 本日の残りの流れ - 内製モデルの開発 - 内製モデルのAPI提供高リスク画像検知APIの内製化 11

Slide 12

Slide 12 text

内製モデルの開発による違反の検知 12

Slide 13

Slide 13 text

内製モデルの開発による違反の検知 13 このAIモデルを内製する配信中の画像 AIモデル推論結果車載配信：98% （運転しながら配信するという違反）配信中の画像を入力として、違反しているかどうかを内製のAIモデル判定・検知する

Slide 14

Slide 14 text

モデル開発における課題に対するアプローチコスト削減、ライブ配信特有の検知対象・精度を課題を、以下のアプローチで解決した 14 コスト削減ライブ配信特有の検知対象・精度向上マルチタスクの分類による複数の不正項目の同時検知 Human-in-the-loopを用いた効率的な学習データの収集画像車載配信未成年アダルト CNN MLP 著作権違反

Slide 15

Slide 15 text

モデル開発における課題に対するアプローチコスト削減、ライブ配信特有の検知対象・精度を課題を、以下のアプローチで解決した 15 コスト削減ライブ配信特有の検知対象・精度向上マルチタスクの分類による複数の不正項目の同時検知 Human-in-the-loopを用いた効率的な学習データの収集画像車載配信未成年アダルト CNN MLP 著作権違反 Human-in-the-loopの実応用について重点的に苦労した点や学んだ点を共有します

Slide 16

Slide 16 text

モデル開発における課題に対するアプローチコスト削減、ライブ配信特有の検知対象・精度を課題を、以下のアプローチで解決した 16 コスト削減ライブ配信特有の検知対象・精度向上マルチタスクの分類による複数の不正項目の同時検知 Human-in-the-loopを用いた効率的な学習データの収集画像車載配信未成年アダルト CNN MLP 著作権違反 Human-in-the-loopの実応用について重点的に苦労した点や学んだ点を共有します

Slide 17

Slide 17 text

- 検出対象ごとに外部APIや内製APIを適用すると、検出対象のラベル分費用が嵩んでしまう - そこで、マルチタスクなモデルを採用して、一度に複数の検出対象について推論した - コストをほぼ一定のまま検知対象を増やすことが可能となったマルチタスクの分類による複数の不正項目の同時検知 17 CNN MLP 車載配信 CNN 画像 MLP 未成年アダルト画像車載配信未成年アダルト外部API CNN MLP 複数の不正項目を同時検知することで、コストを上げずに検知対象を増やすことを可能にした

Slide 18

Slide 18 text

モデル開発における課題に対するアプローチコスト削減、ライブ配信特有の検知対象・精度を課題を、以下のアプローチで解決した 18 コスト削減ライブ配信特有の検知対象・精度向上マルチタスクの分類による複数の不正項目の同時検知 Human-in-the-loopを用いた効率的な学習データの収集画像車載配信未成年アダルト CNN MLP 著作権違反 Human-in-the-loopの実応用について重点的に苦労した点や学んだ点を共有します

Slide 19

Slide 19 text

各種システム・定期的な見回り・ユーザからの通報・ルールベース・etc. Human-in-the-loopを用いた効率的な学習データの収集 19 教師データは、審査システムのフローの中で集めるように設計（Human-in-the-loop） - 審査システムの流れ - ① 各種システムや機械学習APIのアラートをトリガーに、審査すべき配信を優先度つきキューに追加 - ② 優先度順に、人間が配信を目視チェックを実施 - ③ ②での審査結果（OK, NGなど）を機械学習モデルの訓練用のデータセットに順次追加データセット機械学習API NGの場合警告、BANなど訓練に使用アラート優先度つきキュー目視チェック ① ② ③

Slide 20

Slide 20 text

Human-in-the-loopを取り入れるメリット - AIによる完全自動判定ではなく、人間の目視チェックを入れることで、誤対応の確率を下げることができる - 教師データが少なく、機械学習モデルの精度が十分でない場合でも、審査の効率化に用いることができる - 人間が判断した結果をもとに、継続的にモデルを改善することができ、精度の向上が期待できる - 人間による審査がモデル改善のためのアノテーションとなり、審査するほど審査効率が上がっていく各種システム・定期的な見回り・ユーザからの通報・ルールベース・etc. Human-in-the-loopを用いた効率的な学習データの収集 20 データセット機械学習API NGの場合警告、BANなど訓練に使用アラート優先度つきキュー目視チェック審査効率向上モデル精度向上データ数が増える

Slide 21

Slide 21 text

Human-in-the-loopを取り入れるメリット - AIによる完全自動判定ではなく、人間の目視チェックを入れることで、誤対応の確率を下げることができる - 教師データが少なく、機械学習モデルの精度が十分でない場合でも、審査の効率化に用いることができる - 人間が判断した結果をもとに、継続的にモデルを改善することができ、精度の向上が期待できる - 人間による審査がモデル改善のためのアノテーションとなり、審査するほど審査効率が上がっていく各種システム・定期的な見回り・ユーザからの通報・ルールベース・etc. Human-in-the-loopを用いた効率的な学習データの収集 21 データセット機械学習API NGの場合警告、BANなど訓練に使用アラート優先度つきキュー目視チェック審査効率向上モデル精度向上データ数が増える落とし穴もあるよ！

Slide 22

Slide 22 text

事前にしっかり設計しないと「審査時につけるラベル」と「学習時に必要なラベル」が一致しないことが多く発生する - せっかく審査時にデータを蓄積しても、モデル学習に利用しづらいデータになってしまっていることがある - 実際にあった「ラベルの不一致」の例を紹介 - ① ラベルの種類の不一致 - 例：検知優先度や頻度、特徴が異なる違反に同じ審査ラベルがついている - ② ラベルの対象の不一致 - 例：画像を入力として学習や推論するが、審査ラベルは配信単位についている Human-in-the-loopを導入する際の難しさ 22

Slide 23

Slide 23 text

違反している配信を検知するモデルを開発したとする - 検知結果は、一見、精度が高いように見える - しかし、実際には... Human-in-the-loopを導入する際の難しさ - ラベルの種類 23 違反配信健全な配信正例負例違反スコア → 閾値推論学習データ検知（閾値以上）ほとんど正解！

Slide 24

Slide 24 text

問題：検知優先度や頻度、特徴が異なる違反が、同一審査ラベル（例：アダルト）として記録されていることがある - → 稀にしか存在しないが、優先度高く検知すべき配信を見逃していることがある - 教訓：事前にどのような種類のラベルを審査時につけるかを、審査チームと認識を合わせておくべき Human-in-the-loopを導入する際の難しさ - ラベルの種類 24 正例負例違反スコア → 閾値推論学習データ検知（閾値以上）頻度が低く検知の優先度が高い違反配信頻度が高く一般的な違反配信健全な配信が検知できてない！

Slide 25

Slide 25 text

問題：検知優先度や頻度、特徴が異なる違反が、同一審査ラベル（例：アダルト）として記録されていることがある - → 稀にしか存在しないが、優先度高く検知すべき配信を見逃していることがある - 教訓：事前にどのような種類のラベルを審査時につけるかを、審査チームと認識を合わせておくべき Human-in-the-loopを導入する際の難しさ - ラベルの種類 25 頻度が低く検知の優先度が高い違反配信頻度が高く一般的な違反配信健全な配信 25 正例負例違反スコア → 閾値推論学習データ検知（閾値以上）ほとんど正解！

Slide 26

Slide 26 text

Human-in-the-loopを導入する際の難しさ - ラベルの種類 26 正例負例違反スコア → 閾値推論学習データ検知（閾値以上）頻度が低く検知の優先度が高い違反配信頻度が高く一般的な違反配信健全な配信が検知できてない！問題：検知優先度や頻度、特徴が異なる違反が、同一審査ラベル（例：アダルト）として記録されていることがある - → 稀にしか存在しないが、優先度高く検知すべき配信を見逃していることがある - 教訓：事前にどのような種類のラベルを審査時につけるかを、審査チームと認識を合わせておくべき

Slide 27

Slide 27 text

今回の対応策：優先度高く検知すべき配信に対して、追加でラベルを付与して学習することで解決した Human-in-the-loopを導入する際の難しさ - ラベルの種類 27 正例① 正例② 違反スコア② → 閾値推論学習データ検知（閾値以上）頻度が低く検知の優先度が高い違反配信頻度が高く一般的な違反配信健全な配信も検知できた！負例違反スコア① → 閾値

Slide 28

Slide 28 text

問題：モデルの推論対象と人間の審査対象が異なることがある - モデルの推論対象：画像が違反に該当するかどうか - 人間の審査対象：配信が違反に該当するかどうか - → 配信の全画像が違反しているとは限らないため、配信に対して付与した審査結果を、そのまま学習に使えない - 教訓：事前にどのような対象（画像・配信等）にラベルをつけるかを、審査チームと認識を合わせておくべき Human-in-the-loopを導入する際の難しさ - ラベルの対象 5 1 4 3 2 6 7 8 9 10 11 12 13 配信内の画像番号この配信は違反している 7, 8枚目の画像は違反している違反画像人間モデル健全な画像

Slide 29

Slide 29 text

今回の対応策：一定のルールで疑惑画像を絞り込んだ後、再度目視でのデータクリーニングを実施 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 違反画像健全な画像一定のルールで絞り込み例：配信が停止される直前数分間を抽出目視でチェック

Slide 30

Slide 30 text

ラベルは、二値で問題ないか？（二値 / 多段階 / カテゴリ）判断の根拠となる補足情報は必要か？（他条件や根拠となる事項）審査時のラベルと学習時のラベルでの違いの典型例 30 ラベルの種類何に対してラベルをつけるべきか？（画像 / 配信 / 配信者 / ユーザペア）ラベルの対象教訓まとめ：審査時に残すラベルの種類や対象について、審査チームと議論して決める

Slide 31

Slide 31 text

内製モデルのAPI提供 31

Slide 32

Slide 32 text

API開発の話 32 - アーキテクチャ - 運用の責任分界の設定 - 認証 - 非同期処理

Slide 33

Slide 33 text

33 アーキテクチャ GKE / API Cloud Load Balancing GCS /モデルアプリサーバーキャプチャ画像 S3 違反画像検知API 画像取得事業部 Pocochaサーバー AI用 GCP Project 配信

Slide 34

Slide 34 text

アーキテクチャ 34 - 運用主体 - Pococha クライアント・サーバー：事業部 - 違反画像検知API ：データ本部（筆者所属） - 違反画像検知API - 独立したマイクロサービスとして事業部に提供 - 審査対象のキャプチャ画像は、事業部のS3を参照 - 違反画像検知APIの運用 - アラート対応はデータ本部のエンジニアで担当 - 共通基盤チームと、筆者らPococha AI担当チーム

Slide 35

Slide 35 text

運用の責任分界点 - 別組織に向けた機能提供であり、運用の責任分界点を事前に決めておくとスムーズ - 事前に決めたこと - 使用性 - APIインターフェース - 性能 - スケーラビリティ - 最大Requests per Second (RPS) - トラフィックが跳ねる場合 - 保守 - 休日・夜間も障害対応が必要か / 推論APIダウン時にはフォールバックが可能か - 長期の連休の場合の連絡体制 - 障害発生時の連絡体制 - スケーラビリティは負荷試験で確認 35

Slide 36

Slide 36 text

負荷試験の実施 - 負荷試験 - 想定最大QPSを流す - 想定スパイクの再現 - 長時間トラフィックを流しメモリリークチェック - 負荷試験で発見した問題 - FastAPIの非同期処理 - サーバーのパスを割り当てる Path Operationで、 async def を用いていた - 外部との通信、GPUなど、メインスレッドがブロックされたときにスレッドが止まり、極端に性能が下がる 36 source: https://fastapi.tiangolo.com/ja/async/

Slide 37

Slide 37 text

負荷試験結果 37 改修前後でレスポンスタイムが改善改修前 10,000ms以上改修後 400ms以下

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

- AWS Rekognitionの利用量を、前月比約５０％にすることができた - 内製化に伴う追加のインフラ費用は、既存の別の画像審査APIとモデルを統合したため、発生せず - 内製化に伴い、高リスク画像検知のPrecisionは47.5%、Recallは44.2%改善した - 引き続き、違反画像検知以外の用途では、Amazon Rekognitionを利用継続中 - 大規模なトレインデータで学習された精度の高いモデル - ユースケースにマッチしている箇所では大変便利内製化の効果 39

Slide 40

Slide 40 text

まとめ 40

Slide 41

Slide 41 text

- Pocochaでの、コミュニティの安全性・健全性の維持・向上のための、AI施策を共有しました - 違反検知のための、内製モデルの開発事例をご紹介しました - 内製モデルをAPIとして開発提供する、MLOpsの一連の流れをご紹介しました - 今後も新機能を開発予定であり、採用強化中です！ 41 まとめ