AWS Startup ブログ

【開催報告&資料公開】ML@Loft #2

AWS ソリューションアーキテクトの針原 (Twitter: @_hariby) です。ML@Loft はいわゆる機械学習の「お悩み相談会」で、5/13 (月) に AWS Loft Tokyo で第2回目を開催しました。第1回目 [Blog] に引き続き、機械学習の運用をテーマに Lightning Talk (LT) による話題提供と Round Table によるディスカッションの2部構成で行われました。

イベント開始前、AWS Loft Tokyo からの眺め

本ブログではこの ML@Loft #2 (MLOps) の様子についてお伝えします。次回 6/21 (金) のお申し込みも受け付けているのでディスカッションに参加されたい方はぜひお申込み下さい [ML@Loft #3 (レコメンド)]。

当日のタイムテーブル

まずはじめにファシリテーターの方々から MLOps をテーマに10分の LT をして頂きました。

19:05 – 19:45: LT

System Architecture for Machine Learning – 機械学習を前提としたシステム開発の問題と解決 – (株式会社BEDORE 西川 泰海 氏)

BEDORE 西川さんからは、B2B SaaS の Web アプリを題材として、ここに機械学習を組み込む際に起こる問題とその解決策についてお話し頂きました。Web アプリの中に機械学習モデルが複数含まれる場合や、更にコンピュートリソースも複数ノード含まれる場合、アプリ側に機械学習モデルがいて裏に DB があると構成が複雑になりがちです。B2B SaaS ではマルチアカウントのシステムで各アカウントにモデルが必要、そして (クライアント企業の) 各アカウントでモデルの学習が必要なケースもあります。このとき、アプリのデプロイ、機械学習モデルのデプロイ、モデルの変更、をどのように行うかが問題となります。
その背景には機械学習モデルが大きなステートを持っていることが挙げられ、これらをシンプルに扱う方法が模索されています。通常のWebアプリだとステートはDBに入っていますが、それをアプリかインフラ側でハンドリングしないといけないのが一つの大きな特徴です。
BEDORE では TensorFlow Extended (TFX) と TensorFlow Serving によりこれらの問題を解決されています。特に TensorFlow Serving では、複数モデルのサービング、モデルのバージョニング、モデルの安全な入れ替えを行うことができます。コンピュートノードの裏にいた DB が TensorFlow Serving に置き換わることで、シンプルな構成を実現していると紹介されました。

資料: System Architecture for Machine Learning – 機械学習を前提としたシステム開発の問題と解決 –

量子コンピュータのMLOps (MDR株式会社 湊 雄一郎 氏)

資料: 量子コンピュータのMLOps

MDR 湊さんからは、うってかわって量子コンピュータの話。湊さんは工学部建築学科から設計事務所に入り、その後 MDR を創業して内閣府 ImPACT プログラムの PM 補佐を経て今に至るというユニークな経歴の持ち主です。MDR はフルスタック (アプリケーションからハードウェアまで開発する) 量子コンピュータスタートアップとして、金融・自動車・創薬分野への応用を見据えた量子シミュレーション・組合せ最適化問題・量子機械学習に取り組まれています。
量子コンピュータはいくつかの実装方法が存在します。超伝導量子ビットやイオントラップを用いた (いわゆるゲート型とも呼ばれる) 汎用量子コンピュータは、量子ビットを量子ゲートに通して最後に状態を測定することで計算を行うとモデル化されます。これに加え、日本では量子アニーリング (あるいは各種イジングマシン) も話題となることが多いでしょう。発表では各国の量子コンピュータの取り組みについて冒頭でまとめて頂きました。
また、MDR は OSS で Blueqat という量子コンピュータのシミュレーションを行うためのライブラリを提供しています。Blueqat では量子ゲート (パウリゲート・CNOT ゲート・アダマールゲートなど) を並べた回路を Python で記述した上で、初期化した量子ビットを入力し、測定を行います。最近では、既存のコンピュータと量子コンピュータと併用したアルゴリズム開発も盛んで、その一つである Variational Quantum Eigensolver (VQE) と呼ばれるハイブリッド計算アルゴリズムや、ベイズ最適化を用いて量子コンピュータに最大カット問題を解かせる手法についても紹介がありました。
MDR では Amazon SageMaker や API Gateway, AWS Lambda, Amazon DynamoDB をはじめとした AWS サービスを組み合わせて、セキュア・高スループット・開発者フレンドリーかつ量子マシンへの負荷を軽減したアーキテクチャを実現されています。

研究開始から運用までの機械学習モデル開発 (株式会社ABEJA 藤本 敬介 氏)

資料: 研究開始から運用までの機械学習モデル開発 

ABEJA 藤本さんからは、研究開発から運用へとスムーズにつなげるためのポイントについて、特に機械学習モデルを開発するリサーチャー目線で、基盤設計の指針となるような知見をお話し頂きました。機械学習システムの運用には従来の Web サービスと異なる点が多くあります。例えば、データの収集/蓄積・学習・精度検証・デプロイ・結果の保存などを上手にサービスに取り入れながら運用することが重要となるため、それらの手法・経験が MLOps というキーワードで語られます。機械学習基盤上でモデル開発をすることの必要性について、データ・モデル管理と、実験内容および環境の再現性、大規模なデータ使って潤沢なインフラで学習を回すためにはローカル環境では厳しいと話された上で、手法検討・開発・実験の3フェーズについて要求をまとめて頂きました。
手法検討の際には、ベースとなるコード・モデルの動作確認も合わせて行います。この時、1. 自分で新規手法を提案する場合、2. 既存手法を論文ベースで実装する場合、3. 既存のソースコードをカスタマイズして利用する場合、4. あるいは既存の AI サービス (Amazon Rekognition など) を利用する場合が考えられます。要するに、毎回新たにモデル開発を行う訳ではないので、モデルの再利用性が重要となります。フルスクラッチでコードを書ける自由度を残しつつも、既存資産を活用できることが機械学習基盤には求められる、というのが手法検討観点での結論です。
続いて、モデル開発のフェーズでは実際のデータを用いてニューラルネットワークが期待する結果を出してくれるよう試行錯誤を行います。ロジックの確認と合わせてデータの確認 (大事！) も行い、段階的に解きたい問題に対するモデルの完成度を上げていきます。ここではロジックの修正・データの変更・データの確認がやりやすいことが求められます。
そしてモデルが高い精度を出せるよう、ひたすら実験を繰り返して頑張ります。チューニングのためには、ネットワークの再設計 (深さ・チャネル数・正規化・活性化関数) や Data Augumentation、最適化手法 (SGD/Adam/AdaBound) の検討などを行います。自動・手動のハイパーパラメータ探索を行いつつ、上手くいった実験結果をまとめておき比較しますが、一回の試行時間が長い (数時間 – 数日) 場合はこれが大変です。複数パターンを並列実行でき、過去の実験条件の管理を、再現性をもってできることが機械学習基盤には求められます。
以上が、モデル開発者の観点から見た機械学習基盤に求めることでした。

AWS で MLOps を考える時の選択肢 (アマゾン ウェブ サービス ジャパン株式会社 針原 佳貴)

資料: AWS で MLOps を考える時の選択肢

前回の ML@Loft で AWS の話も聞きたい、とリクエストを頂いたので、AWS が提供する機械学習基盤である Amazon SageMaker と、機械学習ワークフローの自動化周りについて、どういう選択肢があるか概要をお話ししました。機械学習の一般的なワークフローの中で、モデルの開発・トレーニング・デプロイと、推論・データ蓄積・再学習の流れが相補的な関係になるよう設計しつつ、それらのサイクルを適切に自動化することは継続的な運用のために重要です。それらを AWS 上で実現するためには、機械学習・深層学習モデル開発 (Jupyter Notebook / JupyterLab)・トレーニング (Docker コンテナ)・デプロイ (REST API エンドポイント) を簡単に行えるマネージドサービス Amazon SageMaker を使うことを現時点ではお勧めしています。これと合わせて、ワークフロー管理ツールである AWS Step Functions (マネージドサービス) や Apache Airflow (注: こちらはマネージドではない) を用いてワークフローを自動化する方法について説明しました。また、Kubernetes / Kubeflow と Jupyter Hub による環境を Amazon EKS を使って構築する方法についても紹介しています。
Amazon SageMaker についてもう少し知りたい場合は、AWS Black Belt Online Seminar Basic [Movie, Slides], Advanced [Movie, Slides] や、実際に使っているお客様の感想は Amazon SageMaker 事例祭り [Web#1, Blog#2, Blog#3, Blog#4] をご覧ください。他にも Keras のコードを Amazon SageMaker に持ってきてトレーニング・デプロイ (TensorFlow Serving) する方法 [Blog]、RDS を立てて Optuna を使う方法 [Blog]、オンプレ資産の GPU を使う方法 [Blog] などをまとめています。ハンズオンも定期的に開催しています。

19:50 – 20:40 ラウンドテーブル (ディスカッション)

後半は各テーブルに分かれて、実際他社では機械学習の運用周りをどうやってるのか？といったリアルな声を聞きながらディスカッションが行われました。上記 LT 登壇の4人に加えて、バンクーバーから来ていた AWS データサイエンティストの Thomas Delteil もファシリテーターとして議論に加わりました。書ききれないのでごく一部ですが、当日の参加者共有メモから質問・回答形式でご紹介します。

  • マルチアカウント問題について話していたがそんなこと起こるのか？
    • モデルを1社で持ってる時はあまり問題にならない (B2C Web サービスとか)
  • TensorFlow Serving を使って全部解決した？
    • 10社のモデルを全部1つのところへは載せれない
  • LT であったのと別のパターンはある？
    • 開発環境・GPU 環境をクライアント企業ごとに分けて、会社ごとのコンテナイメージで学習、どこかにモデルを保存した上でサービング
  • 10人で機械学習やる、とは？
    • マイクロサービス的にモジュールを分けて担当アサイン。例えば、音楽ドメイン (アーティスト・曲名) 、天気ドメイン (アルゴリズムの調整)、音声合成、チャットとか
    • モデルのサービングは単一のプラットフォームでやってる。
  • デプロイ時に考えられるリスクは？
    • 動かないモデルがデプロイされて、エラー出まくるとかある
  • モデルのサイズはどれくらい？
    • テキスト (NLP) だと 数 GB いかないぐらい
    • BERT は超巨大モデル
  • モデルの切り替えはどうしてる？
    • ホストベースは EC2 だと面倒
    • TensorFlow Serving のプロセスベースの切り替えの方が楽
    • それか SageMaker に任せてモデル更新
    • Kubernetes はエンジニアが Kubernetes 向けに成熟してる必要あり
  • Kubernetes は使わないの？
    • アプリがインフラをいじるのが怖い
    • オペミス起きないように GUI だけで操作するとかしてる
    • むしろ Kubernetes 使うかどうかより適切に自動化すべし
  • コンテンツのレコメンドをしたい
    • 動画サムネイル、A/B テスト、CTR 改善などについてお話
    • モデルサイズが大きいのでノード (インスタンス) 分けた方がいい
    • 次回はその話の予定 [ML@Loft #3]
  • リサーチャー・デベロッパーが思い思いに動いて困ってる
    • プラットフォーム観点では GPU 利用効率の最適化で空きが出ないように。AmazonSageMaker とかで環境統一がいいのでは
  • 実験の管理をしたい
    • コード・ライブラリ・データ・中間生成物・最終的なモデル成果物をセットで扱いたい
    • ライブラリによっては研究室が作ったものなどデバッグ必須なものもある
    • コンテナ化してリモートで動かせるほどエンジニアが成熟してない
  • 機械学習モデルのデプロイ・管理ワークフロー
    • 実験コードを動かす仕組みを用意しておく必要がある
    • ロールバックの仕組み、精度が悪いと止める仕組みが重要
  • AWS 使う時どうやってサービス選定してるか
    • AWS マネージドサービスからスタートした。やはり便利。請求はアラート鳴るようにしたり、こまめにチェック。
  • 量子コンピュータは実用化された？
    • 量子コンピュータで AI に参入するところが増えてきているものの、量子コンピュータが世の中で使われるようになるまでまだまだ時間がかかりそう
    • 昔の機械学習みたいな雰囲気がある。今後うまくいくか、いかないかは注目が必要
  • 機械学習・深層学習特有の課題は？
    • 結果に曖昧さが残るところで、様々な環境下で同じパラメータが常に使えるとは限らない
    • 外乱みたいなものが来ないことをどう保証するか課題になりがち
  • 自然言語処理やろうと思って、なかなか手を付けれていないです
    • 自然言語処理では前処理が中心になる。ローカルでやりがちだけど、自然言語ライブラリとかを一から入れるの大変
  • 汎用化を考える必要がある。組み込みの場合、軽量化が重要
    • モデルのコンパイラは TVM とか [GitHub]
    • SageMaker Neo というのもあります
  • エンジニアの人数が限られているため、運用コストが課題
    • ありがち。マネージドサービスとか上手く使って仕組みで解決するのが王道
  • どれくらいの打率で PoC 止まりにならず商用までいけるのか？
    • 担当者がどの程度機械学習を理解しているかに依存する
  • 機械学習って、どうやって提案しますか？PoC から先へ進めるためにはどうすれば？
    • 分析で終わりではなく、運用まで提案することが重要
  • Amazon SageMaker で作ったモデルを他社に提供したい
    • Amazon SageMaker は AWS Marketplace と統合されています [docs]
  • 機械学習のワークフローは、自動か・手動か
    • B2C でたくさんデータが集まるのであれば自動化した方がいい
    • あまりデータの集まらないケースでは、手動で適時行ってもよい
    • 手動で小さいプロジェクトや PoC プロジェクトは回すことはできるが、今後大きいプロジェクトをハンドルしていくには、自動化を前もって検討していく必要があると思われる
  • MLOps の観点から、Amazon SageMaker はどう？
    • 例えばモデルとハイパーパラメータの管理など、独自に実装していく場合も最終的には同じところにいきつく場合は多い。ドキュメントを勉強する手間を考えても最終的に Amazon SageMaker を使った方がいいということは結構ある
    • ただ、Amazon SageMaker に慣れるのに時間がかかることもあるので、SageMaker コミュニティで聞いてみたりすると導入のヒントになる
  • S3 のデータのバージョニングと Amazon SageMaker のモデルの管理はどの辺に気をつければいい？
    • 特にデータのバージョニングは現在 S3 のパスを唯一にする必要がある
    • 画像認識とか追記が単体ファイルに対してない場合は、入力ファイルリストを JSON とかでつくって管理は可能
  • データセットのバージョニングとは？
    • 学習のサイクルを回していると、アノテータが新しくつけたアノテーションが間違っているときにロールバックする必要がよくあり、データセットのバージョニングも必須
  • Optuna を使うケース
    • 複雑なパラメータ空間でパラメータ探索を行う場合に書きやすい
  • ハイパーパラメータのチューニングは実務で行っているか？
    • タスクによる。論文に載っているようなネットワークでも、特定のデータセットに対して最適化されている場合があるため、実際のデータセットごとに行っている。
    • フルスクラッチでモデルを作るような案件に関してはやる必要がある
    • オーバーフィットもあるため、ごりごりなチューニングを行うことはない
    • そこまでハイパーパラメータが大きくパフォーマンスに影響しない場合 (ビジネスインパクトという観点で) は、やってはいるが、ごりごりではない

などなど、多くのディスカッションが行われました。ご参加頂いた皆様、改めてありがとうございます。次回の ML@Loft #3 は、6月21日 (金曜日) 開催予定です。今後も ML@Loft を盛り上げていけるようご協力頂けると幸いです。

このブログの著者

針原 佳貴 (Yoshitaka Haribara)

スタートアップ ソリューションアーキテクト、好きなサービスは Amazon SageMaker、趣味はドラムです。