いっしきまさひこBLOG

AI・機械学習関連、Web制作関連、プログラミング関連、旅行記録などなど。一色政彦。

Amazon SageMaker 事例祭り(2019 年 4 月 17 日開催) 聴講ノート

※これはセミナー聴講時の個人的なノートをそのまま公開したものです。誤字誤植や勘違いがある可能性があるのでご了承ください。

Amazon SageMaker 事例祭り(2019 年 4 月 17 日開催)

13:45~14:30 Amazon SageMaker の基礎 (アマゾン ウェブサービス ジャパン株式会社 ソリューションアーキテクト 鮫島 正樹)

  • 典型的には「開発と学習(データサイエンティスト)」「推論(エンジニア)」というプロセスがある
  • 「開発と学習」の課題:
    • 環境構築が大変
    • 複数の学習ジョブを並列で実行するのが大変
    • 複数マシンを使った分散学習を実現するのが大変
    • 学習結果を管理するのが大変
  • 「推論」の課題:
    • 推論用のAPIサーバー構築とメンテが大変
    • エッジデバイスへのデプロイが大変
    • バッチ推論の仕組みを作るのが大変
  • そこでSageMaker:
    • 数分で開発環境を起動できる
    • 学習・推論環境は柔軟にスケール
    • 多数のAPIを提供
    • 東京を含む13リージョン
    • SDKはオープンソース
  • SageMakerのメリット:
    • 開発・学習・推論は個別に利用可能
    • 開発: ノートブックインスタンスは数分で起動できる。主要ライブラリはインストール済み
    • 学習: 開発と学習は分離。複数ジョブを同時実行。分散学習可能
    • 推論:APIを叩くだけ。オートスケーリングやA/Bテスト機能もある
    • インフラ管理を気にせずに、すぐに機械学習を始められる
    • さまざまなワークフローを加速させられる
    • オープンソースなので、オンプレミスで利用することも一部だけ利用することも可能
  • 開発: マネージドなノートブックインスタンス
    • 上記の特徴
    • 異なるインスタンスを組み合わせられる
    • 複数人の開発でもコードの管理が簡単
  • 学習: 分散学習と複数ジョブ同時実行
    • 上記の特徴
    • 学習が完了すると自動でインスタンスが止まる
  • 推論:APIエンドポイントやバッチ推論
    • 上記の特徴
    • 推論の負荷に合わせてGPUを適用できる機能「Elastic Inference」もある
  • SageMakerの事例:
    • 事例:Delyの料理レシピ動画のリコメンデーション
    • 事例;SmartNewsのニュースキュレーション
    • 事例;GE Healthcareの医師診断支援
  • SageMakerで必要なもの:
    • 学習データ:
      • 「Amazon S3」に置く
    • 機械学習のコード:
      • 「SageMeker」特有の書き方があるわけではなく通常どおりでよい
      • 気を付けるのは、S3とのファイル入出力とコンテナイメージに合わせた動作定義が必要
    • 実行環境(コンテナ):
      • 「Amazon ECR」にコンテナイメージを置く
  • インスタンスは3種類がある:
    • ノートブックインスタンス(開発用。学習データはS3から読み込む):
      • 16TBまでのディスクをアタッチ可能
      • Pandas標準インスタンス
      • EMRを呼び出すことも可能
    • 学習用インスタンス(自動的に停止して削除される。モデルはS3に格納される):
      • ビルトインアルゴリズム(画像、数値・系列解析、自然言語処理、レコメンデーション、汎用系)を使用可能
      • AWS Marketplace for Machine Learning(AWS Marketplace: Search Results
    • 推論用インスタンス(エンドポイント経由でS3にあるモデルを使う):
      • リアルタイム推論: deploy()関数を呼ぶだけでエンドポイントを構築できる
      • バッチ変換ジョブ(バッチ推論): リアルタイムではないが常時立ち上げなくてよいのでコスパがよい
  • SageMakerのデモ
  • SageMaker Example Notebooks:
  • SageMaker SDK:
  • SageMaker公式ドキュメント:

14:30~15:15 Amazon SageMaker Ground Truth の使い方(アマゾン ウェブサービス ジャパン株式会社 ソリューションアーキテクト 針原 佳貴)

  • データにラベル(Ground Truth)を付けるためのアノテーション支援ツール
  • Amazon SageMaker Ground Truth | AWS
  • 教師あり学習:
    • 予測値とラベル(Ground Truth)の比較
    • アノテーション(ラベル付け)が必要
  • ラベル付けの難しさ: 大規模データセットが必要。人間が行う。精度が必要。時間もお金もかかる。ツールの準備(ユーザーを集めて認証、UI、進捗管理)
  • そこでAmazon SageMaker Ground Truth:
    • 一般的なワークフローをサポート
      • AWS Lambdaを使うなどのカスタムラベルのワークフロー
    • 4種類のラベリングツールを提供
      • 画像分離、物体検出、セマンティックセグメンテーション、文章分類、さらにカスタムジョブも可能
    • アノテーションをするワーカー(人、以下の3種類)との連携・管理機能を提供
      • パブリックワーカー: Amazon Mechanial Turkで24時間365日、50万人の労働力(※日本人ではない)
      • プライベートワーカー: 社員などを登録。データは組織内にとどまる。ワーカー管理はCognitoを利用
      • ベンダーワーカー: AWS Marketplace登録済みのサードパーティベンダーに依頼
    • 大規模データセットに対して自動ラベリング(通常は70%のコストカットにつながる)
      • アクティブラーニングと自動データラベリング: 信頼度が低いデータは人間がアノテーションする。人がラベル付けしたデータからアクティブラーニングのモデルを作成
        • アクティブラーニング=人によりラベル付けされるべきデータと機械がラベル付けできるデータを特定する手法(機械学習のテクニック)
  • Amazon SageMaker Ground Truth の事例は多岐に渡る
  • 価格: 利用料$0.08/個
  • 提供リージョン: 東京あり
  • 4つの利用ステップ:
    • データセットの準備: S3バスケットを用意。アノテーション対象の画像やText/CSVファイルを格納。入力用のマニフェストファイル(input.manifest)で"source-ref"にS3のパスを指定(もしくは"source"に直接テキストを書くこともできる)
      • ジョブ名、入力データセットの場所(入力用のマニフェストファイルを指定)、出力データセットの場所(ディレクトリパスを指定)、IAMロールなどを設定する
        • 出力ディレクトリに生成されるマニフェストファイル(拡張マニフェストファイル:output.manifest)
    • タスクの定義: 画像分離、物体検出、セマンティックセグメンテーション、文章分類のいずれかを選択。もしくはカスタムジョブ
    • ワーカーの選択: パブリック、プライベート、ベンダーのいずれかを選択
    • ラベリングツールの設定: アノテーションの指示書を書く。良い例・悪い例を記載。ラベルを設定
  • object_detection_tutorial.ipynbファイルにAmazon SageMaker Ground Truth で鳥のラベル付けのデモがある:
  • SageMaker Ground Truth公式ドキュメント:

15:45~17:15 Amazon SageMaker 事例発表

「Diversity Insight for Retail」でのSageMaker導入と今後(GMOクラウド株式会社 プロダクトマネージャー 山下久知 様)

  • GMO Cloudには「IoTの窓口」というAI・IoT事業がある
  • SageMakerを利用したSaaSプロダクト「Diversity Insight for Retail」の紹介:
  • SageMakerを導入した理由:
    • 3つのメリット: 簡単にエンドポイントを立てられる、マネージドサービスが良い、スケーラビリティとコストのバランスが良い
  • SageMakerを導入後の課題:
    • もっとコストを下げたい: → 解決策:軽量モデル化によってコストダウン(PyTorchを使って高速化)
    • 推論コストが積み上げって、高負荷になりタイムアウト: → 解決策:インスタンスをスケールアップさせる
      • メモリ不足、コア不足、レイテンシの課題: 推論リクエスト件数の多さ(1画面あたり100万件の推論実行)
      • 見える化(グラフ描画)するコスト
      • など
    • Pythonが遅い: → 解決案:C++やJuliaなど高速な言語に対応したい
  • 軽量化・高速化:
    • バッチトランスフォーム化: バッチ推論する方式に変更
    • エッジの比重を増やす: Jetson Nanoを使うことでエッジ推論の性能や比重を上げたい
  • 非Python化:
    • Julia/C++/MKL-DNNなどで高速推論化していきたい。Pythonと比べると数十倍の差が出ている状況
  • まとめ:
    • SageMakerを利用することで、APIをスピーディに開発できるが、性能チューニングやアーキテクチャ選別などの工夫は結構な工数が必要

「えっ、なぜSageMakerなの?」(株式会社オークネット・アイビーエス ジェネラルマネージャー 黒柳 為之 様)

  • 2017年「KONPEKI」、2018「EDIS」が、書籍でケーススタディとして紹介された
  • 「AUCNET IBS」における画像認識AIの取り組み事例:
    • EDIS
    • SODAI Vision API
    • Andy Photo Book
    • KONPEKI
  • SODAI Vision API:
    • 粗大ごみかどうかを判定して返すAI(LINEで試せる)
    • AWS Lambda、SageMaker、など
      • いかに管理コストを下げ、スピードを上げるか、という理由から使った
  • Andy Photo Book:
    • 大量の写真から笑顔をピックアップするAI
    • 卒業アルバム制作大手の株式会社イシクラと連携して開発
    • AWS Lambda、SageMaker、Rekognition、など
      • SageMakerを使うことでRekognitionのコストを下げた(1/200まで下げられた)
  • サービス用プラットフォーム「Hanzo」:
    • Hanzoはサービスのゲートウェイとなっている
    • EDIS、Photo Book、KOPEKIといったサービスにアクセスできる
  • これまでのAI開発の歴史:
    • 2016年: 仮想マシン+TensorFlow
      • APIなど自前でいろんなことをする必要があり、コストと時間がかかった
    • 2017年: EC2インスタンス+TensorFlow+Keras
      • インスタンスを自前で管理していたので、大変だった(運用コスト)
    • 2018年: SageMaker+Keras
      • 自前ではなくて、利用しやすいAPIを使うだけになった。インスタンス管理も自動。コストと時間を大幅に節約できた
      • アプリケーション化が容易になった。試行回数が増えて、モデルの精度向上につながった
  • SageMakerの欠点:
    • デフォルトで用意されている組み込みアルゴリズムをより汎用的にしてほしい(例えば、画像分類用はResNetだけ、画像の増加パラメーターが指定できなかったなど)
    • インスタンスの起動やデータのダウンロード進捗状況が詳細に欲しい(いつ終わるかは時間を見るくらいしかできない)

「不適切コンテンツ検出」の機械化と安定運用(株式会社 ミクシィ Vantageスタジオ mixi事業部 岩瀬靖彦 様)

  • 「機械学習による不適切コンテンツ検出」の実装と成果 – mixi developers – Medium をベースにした話
  • 「健全性の維持」のために:
    • 不適切投稿の一例「お金ちょうだい」など: 犯罪行為など社会に大きな影響を与えかねない事例があるため、監視する必要がある
    • 機械化による負荷軽減。危険度を判定するモデルを作成する
  • 成果:
    • 監視対象の80%以上の判断を機械に任せられるようになった。残った20%は人間が目視によって判断する
  • 危険度判定モデル(言語処理の例):
    • 短文/長文/画像といった投稿種類に合わせたモデル(二値分類)を作成
    • Amazon S3、ECS、ECR、SageMakerなどを使用。SageMakerによって一元管理されている
    • 前処理: 生データとなる文章群を加工成形してS3に格納
    • 学習: S3からデータセットを取り出してモデルを作成
    • 推論: エンドポイントを生成。API GatewayとLambdaを経由させてREST APIとする
    • 運用フローへの組み込み: 既存の投壺監視フローに先ほどのAPIを導入した
  • 細かな部分のアーキテクチャ解説:
    • カスタムアルゴリズム: 例えばコンテナ内で日本語処理したい場合(N-gramならカスタマイズ不要だが形態素解析なら必要)は独自コンテナが必要になる
    • 定期実行タスク: 新しいデータを加えて定期的に更新したい需要がある。cron起動させたいが、スポット利用でよい。
      • → ECS Scheduled Task を使用。AWS Batch & CloudWatch Eventsなどの組み合わせも選択肢になる