機械学習による「不適切コンテンツ検出」の実装と成果

IWASE, Yasuhiko

·

Follow

Published in

MIXI DEVELOPERS

·

14 min read

·

Jan 30, 2019

--

1

Share

こんにちは、株式会社ミクシィで SNS「mixi」事業を担当している岩瀬です。

本記事では、「mixi」における 「健全化活動」と、近年実施した「機械学習による不適切コンテンツ（規約違反投稿）検出」の取り組みについてご紹介したいと思います。

はじめに

「mixi」 は、サービス開始からまもなく 15 周年を迎えるソーシャルネットワーキングサービスです。

長く運用したサービスでは古くなった仕組みの更新が欠かせませんが、「mixi」でもそうした取り組みの一つとして、 2018 年末にかけ「健全化活動」にかかわる仕組みの更新を行いました。

今回のケースでは、「健全化活動」において懸案とされてきた課題に対して、機械学習による解決を試みました。「機械でできることは機械に任せ、より複雑さの求められる領域に人間が注力できるようにしよう」とする取り組みです。

「mixi」の「健全化活動」と課題

「mixi」の「健全化活動」では、「mixi」サービスを安心してご利用いただくために、「利用規約に違反する投稿の監視（パトロール）」「通報への対応」や「不正ログインの検知」などの活動を行っています。

弊社コーポレートサイトでも「ミクシィの健全化活動」として記載がありますので、詳しくはそちらをご参照ください。

利用規約に違反する投稿の監視

「mixi」は「日記」「メッセージ」「コミュニティ」など多様なコミュニケーション手段を提供していますが、誹謗中傷や違法行為などサービス規約に違反している投稿に対して、迅速に削除したり、 投稿者の方に警告をだして修正を促したりといった対応を行っています。

例えば、次のような投稿には問題があるとみなされます。

不適切な単語や隠語を用いたこうしたやり取りは、犯罪へとつながりかねない危険な投稿です。例にある「苺／いちご」そのものは全く問題のない単語ですが、「お金欲しい」からの一連の文脈によって、危険な投稿と判断することができます。

こうした短文投稿のほか、長文中の不適切表現や、不適切な画像の投稿に対して、人間のスタッフが文脈や状況をきめ細かに確認しながら、利用規約に違反しているかどうかを判断しています。

膨大な投稿から違反投稿を検出するむずかしさ

規約に違反する投稿は、経験的に「数は非常に少ないものの毎日確実に存在する」ため、監視をするスタッフは「数件の違反投稿を発見するために数万件の問題ない投稿に目を通す」といった作業を強いられます。キーワードフィルタ等が長年適用されてきましたが精度は十分でなく、検出には多くの時間と労力が必要でした。

違反投稿のなかには犯罪につながりかねない危険なものもあり、投稿数が膨大であっても安易に作業を削ることはできません。一方で、毎日数%の違反のために膨大な投稿を監視しつづけるには、運営上の困難があります。

投稿監視にかかる時間と労力は、通報対応などほかの仕事に貢献できる力を削ぐもので、その負担軽減は長年にわたって課題とされてきました。

機械学習による解決

この課題の解決のため、「投稿内容の危険度判定モデル」を機械学習によって生成し、「人間に代わって違反投稿かどうか判断し、危険度に応じて自動処理する」ことを目指しました。

「健全化活動」スタッフが長年行ってきた「判断」の積み重ねは記録されており、良質なラベルつきデータは十分にありました。「教師あり学習」にとって「正解データをどのように得るか」は最初の課題ですが、すでにクリアされている状況です。前後の文脈や属性データなどを機械に与え、人間と同様の判断ができるように学習を行いました。

また「mixi」で投稿されるコンテンツは短文／長文／画像など種類があるため、「長文の危険度判定モデル」や「画像の危険度判定モデル」など特徴的な内容ごとにモデルを用意して適用しました。

「投稿内容の危険度判定モデル」を適用したフロー

1. 「mixi」サービス利用者から投稿が行われる
2. 投稿内容から危険度判定を行う
3. 危険度に応じて投稿ごとの監視ステータスを決定する
   3-1. 「安全」と判断されれば監視対象から除外する
   3-2. 「危険」と判断されれば人間のスタッフへエスカレーションする
4. 投稿内容と「危険度」「監視ステータス」をデータベースに登録する
5. 機械が「危険」と判断した投稿に対して、投稿監視ツールを経由して、人間のスタッフが「投稿内容が規約違反かどうか」を総合的に判断／対処する
6. 「機械による判断」と「人間スタッフによる判断」の違いをモニタリングする（モデル精度を検証し、必要に応じてモデル更新を行う）

MLシステム構成

コンテンツ種類ごとに若干異なりますが、MLモデルを生成／利用する部分は AWS 上で完結する構成としました。

モデルにデータを引き渡して推論結果を得るためのエンドポイントは REST API とし、AWS に限らず他のクラウドサービスやインフラに容易に置換可能にしています（実際に一部エンドポイントは GCP などの API サービスを併用しています）。

機械学習システムの開発を支援するサービスである Amazon SageMaker を利用し、データ整形等の前処理やMLモデル更新などバッチ処理には Amazon ECS の Scheduled Task を使用しました。エンドポイントは REST アクセスのため Amazon API Gateway と Lambda Function を経由する構成にしています。

MLシステムの運用フロー

1. 開発／アルゴリズムの検証

Notebook Instance で起動させた Jupyter Notebook を利用して、任意のアルゴリズム（前処理を含む）の挙動をノート上で検証します。（Amazon SageMaker では Notebook Instance を起動させると環境構築不要で Jupyter Notebook がすぐ使える状態になります）

動作の検証できた成果物は Docker Image としてビルドし、Amazon ECR へpush して任意のインスタンスで利用できるようにします。次以降のステップごとに、「前処理用コンテナ」「学習用コンテナ」「推論エンドポイント用コンテナ」の3つを生成します。

2. 前処理

「mixi」サービス上の投稿データをデータベースから取り出し、機械学習アルゴリズムが利用しやすいよう「規約違反かどうかのラベルつきデータセット」へと整形し、S3 へ格納します。

学習アルゴリズムによってデータ整形の仕様が異なりますが、日本語の自然言語を扱う場合には、形態素解析やステミング、正規化処理を行ったり、単語辞書やベクトルデータを生成したりします。

前処理スクリプトは先述の通り Notebook Instance から Docker Image として ECR へ格納したものを、ECS のScheduled Task から定期的に pull して実行させます。

3. 学習／MLモデルの生成

違反投稿のパターンは時間が経つにつれ変わっていくため、MLモデルは新しいデータセットを加えて定期的に生成するようにします。Training Job スクリプトを Docker Image として ECR へ格納したものを、ECS の Scheduled Task として定期的に pull して実行させます。

Notebook で検証済みの機械学習アルゴリズムにしたがって、S3 に置かれたデータセットを取得して学習を行い、生成した学習済みモデルを指定の S3 バケットへ書き出します。

このとき実行ログは CloudWatch Logs へ出力されるため、モデル精度等を集計しやすいよう適切なログを出します。

4. 推論／MLモデルによる推論結果の取得

アプリケーション側から参照する「推論のためのエンドポイント」は REST API とするため、Amazon API Gateway と Lambda Function を経由して、SageMaker で生成する Endpoint Instances を参照するようにします。

定期的に生成される新しいMLモデルを参照するよう、モデルを切り替える際は参照する学習済みモデルを記載した Config を CreateEndpointConfig で再生成し、UpdateEndpoint により既存のエンドポイントを更新する方法で行っています。

エンドポイント更新処理も Docker Image として ECR 登録し、ECS Task として実行可能な状態にしています。エンドポイントの切り替えは現在は手動実行にしていますが、定期的なモデル生成による精度変化を判断し、自動的に精度の高いモデルに切り替えるようにしたいと考えています。

（余談）推論エンドポイントの組み合わせ

推論エンドポイントは 先述のとおりREST API なため、特定システムへの依存がありません。

そのため、たとえば画像コンテンツでは Google Cloud Vision API を併用するなど柔軟な構成にしています。Cloud Vision API の適用例は、別途掲載した記事「僅少なコストで人力労働を 8割 削減する話」もご参照ください。

モデル精度の評価と継続的な改善

MLモデルが実用に耐える性能を備えているかどうか、適切な指標で判断する必要があります。これはMLモデルを生成するプロセスでも、実際に運用を続けていくうえでも欠かせません。

一般的な指標としては「Accuracy：正解率」がありますが、今回のケースでは「Recall：網羅率」を重視しました。

モデル精度の評価方法

投稿ごとに、MLモデルによる「推論値」と、人間が行った判断を「正解（真の危険度）」として記録することで、表１のような集計結果が得られます（話を簡単にするため数値は簡略化しています）。

「機械判断」が「人間判断」と異なる部分が 誤り（False：表中の色文字箇所） で、誤りが小さいほど精度が高いといえます。誤りには２種類あり、表２のようにそれぞれ「偽陰性：False Negative」「偽陽性：False Positive」と定義されます。

今回の事例はいわゆる「間違いのコストが不均等なモデル」で、「安全なものを危険と判断する（空振り）損失」より「危険なものを安全と判断する（見逃し）損失」のほうが大きいケース です。空振りを増やすことによる不利益は監視スタッフの負担増だけですが、見逃しを増やすことはサービスの健全性を損ねることになります。

「偽陽性：False Positive」を増やしてでも、「偽陰性：False Negative」を最小化する方向で調整する必要があります。

精度の指標

「偽陰性：False Negative」を最小化することを測る指標として、Recall を使用しました。

下記式の通り False Negative の最小化と Recall の最大化は同義のため、「Recall を最大化したうえで Accuracy が最大になる」よう、モデルを調整します。

指標をもとにしたモデル調整

指標をみながらモデルを調整し、表３のような結果を継続して得ることができるようになりました。

「Accuracy：正解率」でみると、調整前モデル（表１）は「97.09 %」のところ調整後モデル（表３）は「82.10 %」と大幅に悪化しているようにみえますが、「Recall：網羅率」では調整後モデル（表３）が「100%」で「見逃し」を発生させていないことがわかります。

今回のケースでは Recall の最大化（「見逃し」の最小化）を重視するため、調整後モデル（表３）のほうが優れていると判断できます。

モニタリングと継続的な改善

「mixi」では投稿の通報機能を備えており、機械判断で「危険でない」とされた投稿について、サービス利用者の方から「危険かもしれない」と教えてもらうことができます。通報数のモニタリングによって見逃しの増加を検知したり、通報ののち人間判断「問題あり」となったデータの機械判断をみて、モデル精度を把握したりすることができます。

また機械が「危険でない」と判断したレコードについて、定期的に人間によるチェックを行って精度を確認します。

投稿データの傾向は時代によって変わるため、MLモデルもその傾向に合わせて継続的に変えてゆく必要があります。運用フローにもある通り、得られた新しいデータセットを用いて定期的にモデルを生成し、その精度を検証できるようにしています。

取り組みの成果

さまざまな改善を経て、機械学習により生成された「危険度判定モデル」は十分な精度を出すことができるようになりました。

「機械が危険と判断したもののみ人間が判断する」といった運用によって、先の表３のモデルのように、人間スタッフが監視しなければいけない対象を 80% 以上削減 💪 することができました。

この負担軽減により、人間スタッフは判断の難しい投稿への対応や通報対応、お問い合わせへの回答に、より丁寧な対応ができるようになりました。

おわりに

時代が変われば投稿内容は変わっていきますし、導入された仕組みも時代に合わせ変える必要があります。構成変更やアルゴリズムの見直しを含め、継続的な改善が必要です。

「mixi」は歴史の長さに応じて、古くなった仕組みをたくさん抱えています。 そうした仕組みの更新や現代化は「mixi」の現実的な課題であり、「健全化活動」の仕組みの更新がその一環で行われたように、サービス全般にわたって継続的に行われています。こうした取り組みは、今後も適宜ご紹介していきたいと考えています。

ここまでお読みいただきありがとうございました。よろしければこの後、ぜひ「mixi」をお楽しみください！ 😆