20190417 amazonsagemaker事例祭り snsmixi 岩瀬靖彦 · 2020-04-15 ·...
TRANSCRIPT
「不適切コンテンツ検出」 の機械化と安定運用
株式会社ミクシィ Vantage スタジオ mixi 事業部 岩瀬 靖彦
本スライドは、ミクシィ社エンジニアブログ 「機械学習による不適切コンテンツ検出」の実装と成果 ‒ mixi developers の記事を基に作成しています
ご興味をお持ちいただけましたら、ブログ記事もあわせてご覧ください
1. 事業紹介 2. 「健全性維持」という課題と対策3. アーキテクチャ解説 ⅰ. カスタムアルゴリズム ⅱ. 中間生成物の管理 ⅲ. 定期実行タスク 4. まとめ
1. 事業紹介 2. 「健全性維持」という課題と対策3. アーキテクチャ解説 ⅰ. カスタムアルゴリズム ⅱ. 中間生成物の管理 ⅲ. 定期実行タスク 4. まとめ
事業紹介 : SNS mixi
• 2004年3月開始のソーシャル・ネットワーキング サービス(祝15周年)
• 「心地よいつながり」を軸に、日記、コミュニティ、イベント、ニュース、ゲームなど多様なコミュニケーション機会を提供
1. 事業紹介 2. 「健全性維持」という課題と対策3. アーキテクチャ解説 ⅰ. カスタムアルゴリズム ⅱ. 中間生成物の管理 ⅲ. 定期実行タスク 4. まとめ
「健全性の維持」とは
• ルール(規約)を守って、利用者の方に安心してサービスを使っていただくための活動
• パトロールや利用者からの通報によって不適切投稿を検知/削除し、迷惑行為や犯罪行為を抑止している
• UGC/CGM(ユーザの生成するコンテンツで成り立つメディア)を管理するうえで必須の要件といえる
不適切投稿の一例(日本語文の例)
• 投稿種別は短文/長文/画像など多様なため、コンテンツにあわせた判断が求められる
• 犯罪行為など社会に大きな影響を与えかねない事例があるため、ある程度コストを負っても監視を行う必要がある
「健全性維持」のための活動と課題
• スタッフによるサイトのパトロールや、24-365 の通報対応を実施してきた
• 違反は経験的に 数は非常に少ないものの毎日確実に存在 するため、スタッフには数件の違反投稿を発見するために数万件の問題ない投稿に目を通す ような負担がかかっていた
課題への対策 : 機械化による負荷軽減
• 規約違反投稿の検出を機械化する取り組みを実施(2018年)
• 過去行ってきた不適切判断を学習データとして、投稿の 危険度を判定するモデル を作成し、人間に代わって判断を行う ことを目指した
取り組みの成果
•数ヶ月かけて試験運用と精度調整を行い、十分な精度で危険度判定ができるようになった
•監視対象の80%以上の判断を機械に任せることができた •スタッフは判断の難しい投稿への対処や通報対応、お問い合わせへの回答に重点的に対応できるようになった
1. 事業紹介 2. 「健全性維持」という課題と対策3. アーキテクチャ解説 ⅰ. カスタムアルゴリズム ⅱ. 中間生成物の管理 ⅲ. 定期実行タスク 4. まとめ
危険度判定モデルの概要(言語処理の例)• 投稿種類にあわせて、短文/長文/画像など処理の異なる複数のモデルを作成した
• 投稿内容に危険があるか否か の二値分類モデル
• 投稿データをリクエストとして受け取り、加工整形して、MLモデルへ引き渡して推論結果を取得し、結果(不適切か否かのラベル)を返却
推論結果
入力文の受け取り、加工整形 (日本語処理)
分類モデルによる推論
推論結果の整形、返却「不適切」
「適切」
推論エンドポイント
危険度判定モデルの開発工程と生成物
• 前処理:生データの加工整形による訓練データ/辞書等の生成(学習の準備)
• 学習:訓練データを使ったトレーニングによる危険度判定モデルの生成
• 推論:学習済みモデルと辞書等のデータを配置したエンドポイントの設置
Vocab / Vectorizer Data
Training Jobs
Model Artifacts
Input Data
Preprocess Jobs
Endpoints
Raw Data
MLシステムの構成
• SNS mixi のシステム全体がAWS上に構築されており、追加した機械学習システムもAWS上で完結する構成としている
SageMakerによるモデル開発/運用
• モデルの開発/運用の管理全般に SageMaker を利用
• 実行するコードは必要に応じてコンテナ化し、ECRへ登録する
• 学習/推論の各プロセスはSageMakerによって一元管理され、生成物はすべてS3へ格納される
前処理:訓練データ/辞書等の生成
• 前処理:Preprocess生データとなる文章群を加工整形(単語分割/ID変換/ベクトル化など)して、訓練データと辞書等を生成し、S3へ出力する
• 実行コードと環境をECRへ登録しておき、ECS Taskとして起動させる
学習:危険度判定モデルの生成• 学習:Training前処理済みのデータセットをS3から取得して分類モデルの学習を行い、危険度判定モデル(学習済みモデルファイル)を生成してS3へ出力する
• 実行コードと環境をECRへ登録しておき、ECS Task として起動させる
推論:エンドポイントの作成/更新
• 学習済みモデルと辞書等を配置し、リクエスト(任意の文章)ごとにモデルによる推論結果(危険か否かのラベル)を返すエンドポイントを構築する
• 実行コードと環境をECRへ登録しておき、ECS Task から作成/更新を行う
推論:REST API として組み込む• API Gateway と Lambda を経由させて REST API とする
• SageMaker の作成するエンドポイントは AWS SDK による認証を必要とするため、アプリケーション側で AWS SDK が使えない場合は REST API 化が必須
• アプリケーションから投稿ごとにAPIへ推論リクエストを投げ、危険度判定結果を得る
運用フローへの組み込み
• 既存の投稿監視フローに、投稿の危険度判定を行うAPI (赤枠箇所)を組み込み
• アプリケーションサーバから投稿ごとにREST API へ危険度を問い合わせ、判定結果を受け取りDBへ格納する
危険度判定モデル呼び出し後の処理• 機械判定で危険度が低いと判断できたものは監視対象から除外し、判断の難しいもののみスタッフが監視/検証を行う
• 機械判定結果は投稿監視システムからも参照でき、スタッフにより判断の妥当性を確認できる80%以上 を判断確定
判断未定の 20% のみスタッフが検証
アーキテクチャの詳細解説(3点)
•以降、カスタムアルゴリズムの利用法、中間生成物の管理方法、定期実行タスクの作り方について補足
1. 事業紹介 2. 「健全性維持」という課題と対策3. アーキテクチャ解説 ⅰ. カスタムアルゴリズム ⅱ. 中間生成物の管理 ⅲ. 定期実行タスク 4. まとめ
カスタムアルゴリズム
• SageMaker には組み込みアルゴリズムや Tensorflow 等のフレームワークで学習/推論を行う環境が多く提供されている(コンテナを暗黙的に利用)
• 提供されているアルゴリズム/環境で実現できないロジックがある場合、独自にコンテナ作成し、ECRへ登録して呼び出す必要がある
Built-in Algorithms
Machine Learning Frameworks
Custom Algorithms
& Custom Container
例:コンテナ内で日本語処理したい•日本語を扱う場合、文章の単語分割や品詞解析、ステミングなどの処理を必要とする場合がある
• たとえば推論時の入力文を形態素解析したい場合Mecab 等の動作環境が必要になるが、現状こうした日本語処理を行う場合には独自コンテナが必要
• N-gramならカスタマイズ不要、形態素解析やサブワードなどのトークナイザならコンテナが必要になる
独自コンテナのベース/サンプル
• Github の SageMaker Examples に、独自アルゴリズムのためのテンプレートDockerfile があり、それをベースにコンテナ作成できる
• scikit_bring_your_own など
例:Mecab-NEologd をインストールする
• 形態素解析器として Mecab、辞書として mecab-ipadic-NEologd、mecab-python3 をインストールするDockerfile の例
カスタムアルゴリズムまとめ
•カスタムアルゴリズムをコンテナ化することで、たとえば推論用エンドポイント内で日本語処理を行うなど、任意の処理が実行できる
•実行コードをコンテナとしてECR登録し、インスタンス構築時に適切に配置して動かす
日本語処理 入力の加工整形
& 分類モデルによる
推論 &
推論結果の返却
推論結果
1. 事業紹介 2. 「健全性維持」という課題と対策3. アーキテクチャ解説 ⅰ. カスタムアルゴリズム ⅱ. 中間生成物の管理 ⅲ. 定期実行タスク 4. まとめ
生成物のバージョン管理と関連づけ
• 前処理/学習/推論の各プロセスで使用/生成する成果物には依存関係があり、バージョン管理と関連づけが適正に行われる必要がある
• モデルをトレーニングした際のハイパーパラメータ、使用したコンテナイメージや入力データ/中間データ等がいつでも関連づけて把握できることが重要
Training Jobs
Algorithms (ECR)
Model Artifacts (S3)
Input Data (S3)
Preprocess Jobs
Endpoints
Vocab / Vectorizer etc.(S3)
SageMaker による入出力管理
• SageMaker では、仕様に従って入出力を行うことにより、トレーニングジョブとコンテナイメージ、入力データ、モデル、エンドポイント等の関連付けが記録され、管理できるようになっている
• 関連づけはマネジメントコンソール(WebUI)から確認可能
Training Jobs
Algorithms (ECR)
Model Artifacts (S3)
Input Data (S3)
Preprocess Jobs
Endpoints
Vocab / Vectorizer etc.(S3)
SageMaker による入出力管理
• SDK( describe_training_job 等)からも関連づけが確認できる
• 入出力データの実体を把握できる(それぞれ s3://.../{training_data}、 s3://.../output/ 等に存在している)
課題:管理されない依存関係がある
• アルゴリズムによって、先の日本語処理のように単語⇄ID変換したり単語⇄ベクトル変換したりするケースがある
• 学習/推論プロセスで同じ辞書を必要とするため明示的な関連づけが必要だが、SageMaker で管理されないため、独自に依存関係を管理する必要がある
Training Jobs
Algorithms (ECR)
Model Artifacts (S3)
Input Data (S3)
Preprocess Jobs
Endpoints
Vocab / Vectorizer etc.(S3)
解決策:前処理ID(PPID)を共有する• 辞書データやベクトライザは前処理プロセスで訓練データとともに生成するため、前処理プロセスの固有ID(PPID)を発行し、PPIDを生成物に明記する
• 例:PPID:preprocess job ID
• 例:データ出力先パス
Training Jobs
Algorithms (ECR)
Model Artifacts (S3)
Input Data (S3)
Preprocess Jobs
Endpoints
Vocab / Vectorizer etc.(S3)
学習プロセスの生成物にPPIDを付与する
•学習プロセスで、参照したデータセットのPPIDを切り出し、生成するジョブ名やモデル名に付与する
• 例:TrainingJob名
• 例:Model名
• 例:Modelファイル名
Training Jobs
Algorithms (ECR)
Model Artifacts (S3)
Input Data (S3)
Preprocess Jobs
Endpoints
Vocab / Vectorizer etc.(S3)
推論環境へPPIDを使い辞書等を配置する
• 推論エンドポイントではコンテナ内(/opt/ml/model 以下)にModelファイルが展開されるため、Modelを参照することで、Model名に含まれるPPIDが取得できる
• PPIDを含む辞書データ等のS3パスを組み立て、S3からデータ群をダウンロードしてコンテナ内に配置できる
Training Jobs
Algorithms (ECR)
Model Artifacts (S3)
Input Data (S3)
Preprocess Jobs
Endpoints
Vocab / Vectorizer etc.(S3)
中間生成物の管理法まとめ
•この方法により、エンドポイントで利用されている現行モデルがどの辞書を使っているか?どのデータセットで学習したものか?等を明確にできる
•依存する生成物を適切に配置することで、学習/推論で期待する挙動が得られるようになる
Training Jobs
Model Artifacts (S3)
Input Data (S3)
Preprocess Jobs
Endpoints
Vocab / Vectorizer etc.(S3)
1. 事業紹介 2. 「健全性維持」という課題と対策3. アーキテクチャ解説 ⅰ. カスタムアルゴリズム ⅱ. 中間生成物の管理 ⅲ. 定期実行タスク 4. まとめ
機械学習プロセスを定期実行させるケース
• 投稿データの傾向は時代を経るにつれ変化するため、モデルは新しいデータを加えて定期的に更新したい需要がある
• たとえば前処理プロセス(最新データを取り込んだり辞書を更新)と学習プロセス(前処理データによるモデル更新)を月次等の周期で実行させたいというケース
苺野菜アイス
⼿押し
定期実行タスクの要件
• cron 起動させたい
• バッチスクリプト動作に十分な環境がほしいが、リソースはスポット利用でよい
• アプリケーション側にある既存のバッチサーバと環境構成が異なる場合、構成管理上、混在を避けたい
解決策:ECS Scheduled Task
• バッチスクリプトの動作環境をコンテナとしてECRへ登録し、ECS Scheduled Task として起動させる
• cron 設定/起動が可能
• タスクごとに使い切りの環境のため経済的
• 細かな設定が不要でメンテナンスコスト低い
解決策:その他の選択肢
• 必要十分の機能を備えているため、要件的な不備のない限りECS Scheduled Task でよい
• GPU利用など細かなマシン設定やタスク依存設定を必要とする場合は、 AWS Batch & CloudWatch Events 等の組み合わせも選択肢になると思われる
機械学習プロセスの定期実行まとめ
•新しいデータ傾向への対応のため、前処理や学習の工程を定期的に実行したいケースがある
•機械学習プロセスの定期実行には ECS Scheduled Task がおすすめ
1. 事業紹介 2. 「健全性維持」という課題と対策3. アーキテクチャ解説 ⅰ. カスタムアルゴリズム ⅱ. 中間生成物の管理 ⅲ. 定期実行タスク 4. まとめ
まとめ(ビジネス面)
•SNS mixi では、サービス運営において負担の大きかった領域を機械化し、80% 以上の負荷削減を実現できた
•負荷削減によって、人的資源をより複雑な課題へ集中投下できるようになった
まとめ(技術面)
•SageMaker をはじめ AWS のサービス群を組み合わせることによって、MLモデルの開発と導入、モデル更新などの運用を低コストで実現できた
• SageMaker で自然言語(とくに日本語)を扱う場合には、現状細かな工夫が必要になるが、サーバセットアップや諸々のインフラ管理コストを削減できるメリットは大きい
ご静聴ありがとうございました