【レポート】顧客最適な機械学習モデルを提供する対話エンジンサービスとAmazon SageMakerの活用事例 #CUS-21 #AWSSummit

2021.05.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

この記事では、5月12日に行われた AWS Summit Online 2021 のオンラインセッション『顧客最適な機械学習モデルを提供する対話エンジンサービスとAmazon SageMakerの活用事例 (CUS-21)』の模様をレポートします。

セッション概要

"深層学習・自然言語処理を駆使する対話エンジンBEDOREの裏側!Amazon SageMakerを活用した新機械学習システムを大公開!" PKSHA Technologyの対話エンジンサービス「BEDORE」は、顧客毎に自然言語処理を用いた機械学習モデルをオンデマンドに学習し、応答をアップデートすることができるSaaSプロダクトです。本セッションでは、SaaSとして1つのアプリケーションに対してマルチモデルでのサービス提供を可能とするシステム構築事例を、学習・推論パイプラインにAmazon SageMakerを活用した構成を交えて紹介します。本事例を通し、見えてきたAmazon SageMakerの利点・課題についてお話します。

登壇者

  • 株式会社PKSHA Technology Algorithm Solution事業本部 Software Engineer 白木 義彦 氏
  • 株式会社BEDORE Engineering Manager 三好 良和 氏

レポート

Agenda

  • BEDOREの紹介
  • BEDOREにおけるシステム課題
  • Amazon SageMakerを軸とした構成事例
  • 本構成で生じた課題
  • まとめ

BEDOREの紹介

  • エンタープライズ企業を中心に100社以上の導入実績累計1億回以上の対話を提供

BEDOREのどの部分に機械学習を利用したか

  1. 回答不足改善
    • クライアントが対話エンジンを運用する際、対話例の不足をアラートし、改善を促す
    • 改善することで自動で対話する例が増える
  2. 個人情報マスク
    • 対話内で個人情報(住所、メールアドレス、氏名など)の対象になるものをマスキングする機能
  3. 回答分類
    • 入力された会話に対して適切に回答する機能
    • 主な特徴
      • マルチモデル:様々な業界の知識ドメインごとに最適化された学習済モデルを複数内包している
      • 学習のタイミングはクライアントが任意で開始でき、すぐにエンドユーザへ価値提供できるようにする

BEDOREにおけるシステム課題

改善前のアーキテクチャ

  • Amazon EC2ではOSから起動するため、学習全体に速度改善の余地がある、またコンテナ未利用
    • あるバージョンのAMIで起動時のインスタンスステータスチェックに失敗するなど原因不明の機動トラブルも発生
  • 学習後に古いバージョンのモデルを使わないようメモリに載ったモデルをクリアする目的で、インスタンスのRefreshをしたいが、
    • 上記EC2起動トラブルを回避するため、「再起動」の運用にせざるを得なかった
    • さらに学習済モデルをEFSからコピーする処理が残り続け、ステーフルなインスタンスになってしまっていた

Amazon SageMaker を軸としたリアーキテクチャを実施

現在のアーキテクチャ

  • 学習基盤にAmazon SageMakerを選択
    • 学習基盤に必要な機能がサービスとして備わっている
    • Webサーバ+キューイングサービスを用意しなくてもOK
    • 学習コードを同胞したDockerイメージを用意するだけで良くなったため、管理リソースと運用コストを削減できた

導入した効果

  • 学習フェーズでインスタンスのトラブルがなくなった、フルマネージドの恩恵を受けられている
  • 学習に要する時間が 57.4% 減少した
  • クライアントごとにインスタンスサイズを最適化できる

さらに生じた課題

Amazon EFSのRead遅延

  • 当初回答分類の推論に AWS Fargate + Amazon EFSを利用していたが、EFS上の同一ファイルへ複数クライアントからアクセスする際の競合READによりレイテンシーが低下する事象が発生
    • 以下を改善に解決

Amazon SageMaker Multi-Model Endpoints の導入ができていないこと

  • Multi-Model Endpoints
    • 単一Model Endpointを複数の学習済みモデルに拡張
    • APIリクエスト側でモデルを指定し、共有サービングコンテナが指定モデルを使い応答する
    • 1モデル1コンテナの動作でなくなるため、ホスティングコストを大きく削減できる

参考記事

今後はMulti-Model Endpoints 導入を検討する

まとめ

所感

EC2からコンテナ化、Sagemakerへとシフトされ、基盤の改善プロセスをしっかり実施されていて、良いシナリオでした。

今後の推論側の基盤も改善されれば、フルマネージドな機械学習基盤の強みをさらに実感できるかと思いますので期待したいです。