この記事は、Merpay Tech Openness Month 2021 の20日目の記事です。
こんにちは、メルペイのMachine Learningチームのmatchanです。
今回は「MLを活用した不正検知システム」をテーマに、ここ最近のMLOpsに関わるコンポーネント充実化の恩恵により、教師あり学習を枠組みとしたシステムの一巡フローの自動化が容易になってきたので、その取り組みを紹介します。
はじめに
メルペイではMLを活用したさまざまな不正検知システムをつくっています。不正検知システムを構成するMLモデルもさまざまありますが、教師あり学習のモデルが多数を占めています。今回紹介する内容は、そんな教師あり学習のモデルを活用した不正検知システムに焦点を当てています。（以下、教師あり学習のモデルを活用した不正検知システムを単に「不正検知システム」としています）
不正検知システムは一度リリースしたら終了ではなく、日々運用・アップデートしていく必要があります。特に、不正検知システムは新たな不正トレンドに対応していくために、モデルの継続的学習や特徴量アップデートが重要になってきます。もしリリース後にモデルの学習を行わないと、リリース時より後に登場した不正のパターンに対応することは難しくなっていきます。これまでメルペイでは、モデルの継続的学習や特徴アップデートの多くは手動ベースで行われてきました。
しかし、Vertex AIの登場やFeature Storeなど、ここ最近のMLOps環境の充実化によって、モデルの継続的学習や特徴量アップデートなどのパイプライン構築や自動化が容易になってきました。
モデルの継続的学習や特徴量アップデートの自動化
不正検知システムが初回リリースされた後も、基本的にモデルの再学習や特徴量のアップデートは継続的に行われていくかと思います。例えば、新しい不正手口の登場、不正トレンドの変化、既存の不正手口が検知させることによる不正パターンの変化など、このような学習時点で存在していないデータの生成過程による分布の変化が発生すると、教師あり学習モデルの精度は基本的に低下していくかと思います。
そのため、これまでは精度指標を監視しながら、一定値を超えたら定期的にモデルの再学習や特徴量のアップデートを手動ベースで行い精度を維持・向上してきました。
そんな中、Vertex AIが登場してそのコンポーネントの一つであるVertex Pipelinesの利便性が高いこと、Feature Storeの一つであるfeastがアップデートを続けており機能が充実していることを受けて、それらを活用しながら上記のシステム化を進めています。また、Vertex PipelinesについてはAI Platform Pipelines時代に抱えていた運用上の懸念点などがクリアになったことも採用理由でした。（先日の記事でも導入経緯が触れているので割愛します）
パイプラインの実装的な話は先日の記事に詳細があるため割愛します。そのため以下では、どのコンポーネントを使い何を実現しているかにフォーカスした紹介をします。
モデルモニタリングのパイプライン
モデルが精度面で期待通りのパフォーマンスを定期チェックするパイプラインを構成します。
パイプラインを構成する主なコンポーネントは以下になります（現状、Vertex Pipelinesの定期実行はいくつかの理由により、ワンショットのパイプライン実行とCloud Scheduler、Cloud Pub/Sub、Cloud Functionsを組み合わせて実現しています。）
- Vertex Pipelines
- Cloud Pub/Sub
- Cloud Functions
- Cloud Scheduler
このパイプラインでは定期的にモデルの精度面の指標を監視し続けています。指標がある一定値を超えたら、モデル学習のパイプラインを実行する構成で構築しています。
モデル学習のパイプライン
モデルの学習データはFeature Storeから取得して、学習から評価、サービングエンドポイントのデプロイを行うパイプラインを構成します。
モデル学習を行うパイプラインを構成する主なコンポーネントは以下になります
- Vertex Pipelines
- Vertex Endpoint
- Feature Store (feast)
このパイプラインでは、Feature Storeから学習データを取得する際は、現在稼働中モデルで使用している特徴量だけでなく、特徴量候補としてStoreされてるすべての特徴量を取得して特徴量選択を行います。そうすることで最新の不正トレンドにも対応し続けるための特徴量出し入れや追加アップデートの自動化を実現します。
Feature Storeのパイプライン
Feature Store (feast)にさまざまな特徴量を定期的にingestするためのパイプラインを構成します。
パイプラインを構成する主なコンポーネントは以下になります
- Vertex Pipelines
- Feature Store (feast)
- Cloud Pub/Sub
- Cloud Functions
- Cloud Scheduler
このパイプラインでは、Bigqueryに存在するデータソースに対してSQLで特徴量計算を行い、Feature Storeのoffline storeに定期的にIngestする構成になっています。
feastについて詳しく気になる方は、公式をご覧ください。Merpay Tech Fest 2021でもfeastについて触れられています。
オンラインテストの自動化
これまでメルペイでは、オンライン時においても新しいモデルが旧モデルよりもパフォーマンスが高いことを手動ベースでテストしてきました。
上記のモデルの継続的学習や特徴量アップデートの自動化のパイプラインが走ることで、新しいモデルのエンドポイントがデプロイされますが、同様のテストも自動化したいところでした。モデルのエンドポイントとして採用しているコンポーネント Vertex Endpointには、そんな願いを簡単に叶えてくれる機能が含まれていました。
デプロイするモデルへのリクエスト割合の制御
リファレンスに以下の記載があります。
トラフィックの分割
上記の例の –traffic-split=0=100 フラグでは、Endpoint が受信する新しい予測トラフィックの 100% を新しい DeployedModel に送信します。これは、一時的な ID 0 で表されます。Endpoint にすでに他の DeployedModel リソースがある場合は、新しい DeployedModel と古いリソースとの間でトラフィックを分割できます。たとえば、トラフィックの 20% を新しい DeployedModel に、80% を古いリソースに送信するには、次のコマンドを実行します。gcloud beta ai endpoints deploy-model ENDPOINT_ID\ --region=LOCATION \ --model=MODEL_ID \ --display-name=DEPLOYED_MODEL_NAME \ --machine-type=MACHINE_TYPE \ --min-replica-count=MIN_REPLICA_COUNT \ --max-replica-count=MAX_REPLICA_COUNT \ --traffic-split=0=20,OLD_DEPLOYED_MODEL_ID=80
つまり、新しいモデルと旧モデルのエンドポイントそれぞれへのリクエスト数を制御できる機能がVertex Endpointに含まれていました。私たちはこの機能をオンラインテストに活用することを検討し、現在構築中です。
おわりに、さらに向こうへ
今回は、MLの教師あり学習を枠組みとしたシステム運用の自動化への取り組みの紹介でした。教師あり学習の枠組み自体は自動化できる部分が多いと思いますが、自前でそのシステムを構築することは一定のハードルがあると感じていました。しかし、Vertex AIなど最近の優れたマネージメントサービスを組合わせることで、理想的なMLOpsが低コストかつ短時間で実現できるようになってきました。今後私たちは優れたサービスの恩恵を受けつつ、教師あり学習以外の問題設定や価値のある課題の発見、Feature Storeの拡充や管理により多くの時間取り組んでいきたいと思っています。
最後まで読んで頂きありがとうございました。
