Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

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

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/

DeNA_Tech

March 02, 2023
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. 自己紹介 2 - 井本裕(Yutaka Imoto) - データ本部データ基盤部MLエンジニアリング第二グループ - MLOpsエンジニア /

    クラウドアーキテクト / プロジェクトリーダー - 2013年よりDeNAにジョイン - グローバル規模のゲームプラットフォーム・アカウントサービスのサーバーサイド開発に従事 - 位置情報システム(GIS)のアルゴリズム開発に従事 - 夏目亮太(Ryota Natsume) - データ本部AI研究開発部第三グループ - AIエンジニア - 2020年よりDeNAにジョイン - 株式会社ZENKIGENにて動画解析AIを用いたプロダクトの立ち上げ - PocochaのCS領域への機械学習活用に従事
  2. Table of Contents Pococha でのAI審査のニーズとモデル開発 - AI審査の課題と背景 - モデル開発 Tips

    3 API開発 - APIサービングまで - 弊社でのDevOpsの一連の流れをご紹介 - 開発Tips
  3. Pococha とは - ライブ配信アプリ - 配信をするライバーと、コメントやアイテムで応援 する リスナーの双方向コミュニケーションサービス - Pocochaの特徴:多様な小規模コミュニティ

    - 2017年に国内でPocochaを開始し、大きく成長 - 成長フェーズの事業であり、今後も非連続な成長を 目指す 4 source: 個人投資家向け会社説明会 https://ssl4.eir-parts.net/doc/2432/ir_material/196793/00.pdf
  4. Pocochaでの審査体制 7 Pocochaでは、ユーザーのコミュニティの安心・安全を重視し、様々な施策を実施中 - 審査チーム - 24時間体制で人間が審査を実施 - 審査担当が一つ一つ内容を確認 -

    前後の配信や行動を調査した上で、統一的な基準に沿って対応 - 審査や対応内容 - 通報対応 - 配信に違反行為がないか見回り(配信審査) - プロフィールの審査
  5. 高リスク画像検知APIの内製化 10 - 配信のキャプチャ画像が何らかの違反カテゴリの画像であるか、OKであるか予測する - NGであれば、人間が優先的に審査 - 当初はAmazon Rekognitionを利用 -

    DetectModerationLabels - 「暴力的」「性的」「不快」等のカテゴリー - それぞれのスコアをAPIが返す - スコアが一定の値を超えると審査スタッフに通知 - マネージド・サービスであり、導入コストが極めて低かった - 導入決定からリリースまで素早い
  6. - 内製化へのモチベーション - 弊社の審査基準と、Amazon Rekognitionの基準が異なる - 弊社の審査基準のほうが、NGとされる範囲が広い - より精度を高めたい -

    その後サービスグロースにつき、コスト削減のニーズが高まった - また、人間による審査結果を学習用データとして利用可能であった - 高リスク画像検知モデルを開発し、マイクロサービスのいちAPIとして提供することにした - 本日の残りの流れ - 内製モデルの開発 - 内製モデルのAPI提供 高リスク画像検知APIの内製化 11
  7. 各種システム ・定期的な見回り ・ユーザからの通報 ・ルールベース ・etc. Human-in-the-loopを用いた効率的な学習データの収集 19 教師データは、審査システムのフローの中で集めるように設計(Human-in-the-loop) - 審査システムの流れ

    - ① 各種システムや機械学習APIのアラートをトリガーに、審査すべき配信を優先度つきキューに追加 - ② 優先度順に、人間が配信を目視チェックを実施 - ③ ②での審査結果(OK, NGなど)を機械学習モデルの訓練用のデータセットに順次追加 データセット 機械学習API NGの場合 警告、BANなど 訓練に使用 アラート 優先度つきキュー 目視チェック ① ② ③
  8. Human-in-the-loopを導入する際の難しさ - ラベルの種類 26 正例 負例 違反スコア → 閾値 推論

    学習データ 検知 (閾値以上) 頻度が低く検知の 優先度が高い違反配信 頻度が高く 一般的な違反配信 健全な配信 が検知できてない! 問題:検知優先度や頻度、特徴が異なる違反が、同一審査ラベル(例:アダルト)として記録されていることがある - → 稀にしか存在しないが、優先度高く検知すべき配信 を見逃していることがある - 教訓:事前にどのような種類のラベルを審査時につけるかを、審査チームと認識を合わせておくべき
  9. 今回の対応策:優先度高く検知すべき配信 に対して、追加でラベルを付与して学習することで解決した Human-in-the-loopを導入する際の難しさ - ラベルの種類 27 正例① 正例② 違反スコア② →

    閾値 推論 学習データ 検知 (閾値以上) 頻度が低く検知の 優先度が高い違反配信 頻度が高く 一般的な違反配信 健全な配信 も検知できた! 負例 違反スコア① → 閾値
  10. 今回の対応策:一定のルールで疑惑画像を絞り込んだ後、再度目視でのデータクリーニングを実施 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 違反画像 健全な画像 一定のルールで 絞り込み 例:配信が停止される 直前数分間を抽出 目視でチェック
  11. ラベルは、二値で問題ないか? (二値 / 多段階 / カテゴリ) 判断の根拠となる補足情報は必要か? (他条件や根拠となる事項) 審査時のラベルと学習時のラベルでの違いの典型例 30

    ラベルの種類 何に対してラベルをつけるべきか? (画像 / 配信 / 配信者 / ユーザペア) ラベルの対象 教訓まとめ:審査時に残すラベルの種類や対象について、審査チームと議論して決める
  12. 33 アーキテクチャ GKE / API Cloud Load Balancing GCS /モデル

    アプリ サーバー キャプチャ画像 S3 違反画像検知API 画像取得 事業部 Pocochaサーバー AI用 GCP Project 配信
  13. アーキテクチャ 34 - 運用主体 - Pococha クライアント・サーバー: 事業部 - 違反画像検知API

    : データ本部(筆者所属) - 違反画像検知API - 独立したマイクロサービスとして事業部に提供 - 審査対象のキャプチャ画像は、事業部のS3を参照 - 違反画像検知APIの運用 - アラート対応はデータ本部のエンジニアで担当 - 共通基盤チームと、筆者らPococha AI担当チーム
  14. 運用の責任分界点 - 別組織に向けた機能提供であり、運用の責任分界点を事前に決めておくとスムーズ - 事前に決めたこと - 使用性 - APIインターフェース -

    性能 - スケーラビリティ - 最大Requests per Second (RPS) - トラフィックが跳ねる場合 - 保守 - 休日・夜間も障害対応が必要か / 推論APIダウン時にはフォールバックが可能か - 長期の連休の場合の連絡体制 - 障害発生時の連絡体制 - スケーラビリティは負荷試験で確認 35
  15. 負荷試験の実施 - 負荷試験 - 想定最大QPSを流す - 想定スパイクの再現 - 長時間トラフィックを流しメモリリークチェック -

    負荷試験で発見した問題 - FastAPIの非同期処理 - サーバーのパスを割り当てる Path Operationで、 async def を用いていた - 外部との通信、GPUなど、メインスレッドがブロックされたときにスレッドが 止まり、極端に性能が下がる 36 source: https://fastapi.tiangolo.com/ja/async/
  16. 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