【AI/ML】MLOpsで実現する成果の出るAIの作り方

皆さんこんにちは、ソリューションスペシャリストの井上です。今回はAI/MLの世界で重要度が増してきているMLOpsについて解説してみたいと思います。

なぜ今AIが必要か?

いままでは世界の変化が緩やかで、過去データを分析すればおおよその未来予測はできました。 ところが今は変化が早く過去のデータがあまり役に立たない状況も出てきています。最近の例では新型コロナがありますね。「データには鮮度がある」という言葉を痛感することも多いのですがもちろんそれだけではありません。例えばZaraなどのFast Fashionに代表されるFast Inventoryモデルは従来のように1年前のデータから流行や在庫数を予測するのではなく、もっと短期間で売れる服を作って売り切るモデルで、最近このようなビジネスモデルが増えてきています。 そのために必要なリアルタイムデータを短時間で分析したり、リソースがなく利用していなかった過去の膨大なデータの分析などは、今までのように人がやっていては到底間に合いません。そこでそれをマシン(AI/Machine Learning(以降ML))に実行してもらう必要性があるということです。 f:id:yojiino:20210107151609p:plain

それならAI/MLをやってみよう! となるわけですが、なんとなく始めるのはお勧めしません。

87%のAI/MLプロジェクトが実用化されていない!?

その理由はこの数字が物語っています。87%というのは2019年7月にサンフランシスコで開催されたTransform 2019というイベントで提示された、AI/MLプロジェクトの失敗率です。 ここ数年で多くの企業がAI/MLの部署を作ったり、プロジェクトを立ち上げたりしています。デジタルトランスフォーメーションの実現にはデータの活用が不可欠で、それを飛躍的にAI/MLが推し進めることを期待されているのですが、実際には多くのAI/MLプロジェクトが道半ばで挫折しています。

なぜ多くのAI/MLプロジェクトは失敗するのか? その理由は4つ、人材不足、インフラとアプリの陳腐化、コラボレーションの欠如、そしてデータのサイロ化です。

1.人材不足

まずは人材の問題から考えてみましょう。AI/MLプロジェクトを継続的に使えるモノにするには以下のようなプロセス、人材が必要だと言われています。「いやいや、成功するかもわからないのに最初から大きな投資はできないよ」という意見はもっともだと思います。でも実際に成功しているケースでもスモールスタートで始めているところも結構あるのです。では何が違うのでしょうか?その差は最初からAI/MLのライフサイクルとペルソナを意識して取り掛かっているかどうかだと思います。例えばAI/ML成功の秘訣は優れたMLモデルの開発ではなく、MLモデルの継続的評価(Causal Inference : 因果推論)とそれに基づく再訓練の仕組みをきちんと設計することだったリします。また人材についてもデータサイエンティストを採用してその人に全部任せっきりだったりすると、生産性が低下して肝心のAI/ ML開発が進まず成果が出なかったりします。一部のオールマイティ型のデータサイエンティストであればこのライフサイクルを自分自身で対応できるかもしれませんが、そのようなスーパーデータサイエンティストは希少でしょうし、実際に運用を始めたときにはスケールできません。結果として本業のMLモデル開発に割く時間が短かくなり生産性が落ちてしまうことになりかねません。そのためそれぞれのペルソナが自分の業務に集中できる環境の構築と、スケールできるプロセス設計が重要になります。

f:id:yojiino:20210107151614p:plain
AI/MLライフサイクルとペルソナの役割

2.インフラとアプリの陳腐化

2つ目はインフラとアプリの陳腐化です。 よく見かける光景として以下のようなものがあります。

  • それぞれのデータサイエンティストが自分で環境を構築・運用、インフラ部門も期待通りの環境の提供が困難
  • リソース共有ができていないためGPUのリソースも無駄が多い
  • すべてがマニュアルプロセスで非効率、オペミスによる手戻りも多い
  • MLモデルのアプリ実装も時間がかかる
  • セキュリティの面は常に心配

上記のいくつかは心当たりがある方も多いのではないでしょうか?このような課題を解決するのはセルフサービス化です。例えば以下のような環境があるとどうなるでしょうか?MLモデルの開発・テスト・リリース、学習に必要なGPU等のハードウェアアクセラレータリソースの自動的な割当、MLモデルのアプリ側への実装・テスト・リリース、そしてMLモデルが現実世界で及ぼす結果の継続的モニタリング。これらすべてが1つのポータルで実現でき、プロジェクトに新たに参加したデータサイエンティストにも同じ環境が即座に用意できるとしたら生産的ですよね。もちろんプロジェクト個人に合わせたデータ、アプリも個人で選択することが可能ですし、それらのアップデートも自動でやってくれるのです。このような環境を最初から準備することは後々プロジェクトを本格稼働する際にとても重要になってきます。

f:id:yojiino:20210107151621p:plain
理想的なデータサイエンティストの環境

3.コラボレーションの欠如

3つ目はコラボレーションの欠如です。最初のAI/MLライフサイクルの図で示しましたように、AI/MLライフサイクルには複数のペルソナが介在します。そしてそれぞれが自分の役割を果たすために複数のペルソナとのコラボレーションが不可欠となります。例えばデータサイエンティストは必要なデータを入手するためにデータエンジニアと打ち合わせをしたり、データのセキュリティやパフォーマンスを確保するためにインフラチームとも打ち合わせをする必要も出てくるでしょう。さらにはMLモデルの組み込みやリリースについてアプリ開発との打ち合わせも必要になります。往々にしてあるのはそれぞれが話す言葉が他のペルソナにはちんぷんかんぷんだったり、一見簡単に思われる要求が実は様々な制約があり簡単には実現できなかったりするということです。そこでMLワークフローに必要なタスクとそこで使われる言語を標準化し、それぞれのやり取りを自動的に行えるようにするプロセスを実現します。このプロセスはMLOpsと呼ばれます。MLOpsについては次の章で説明します。

f:id:yojiino:20210107151629p:plain
解決策はMLOps − プロセス自動化によりセルフサービス化を実現

4.データのサイロ化

4つ目はデータのサイロ化です。データがサイロ化する原因は何でしょうか?必要なデータがどこにあるかわからない、データフローが分断されている、データが大きすぎて移動ができない、原因は多々あると思いますが、まずはデータを保存するストレージシステムがサイロ化していることは大きな要因の一つと言えるでしょう。一般的にストレージの世界では「One size does not fit all」という表現がよく使われます。「一つのストレージシステムで万能に使えるものは無い」裏を返すと「あらゆる種類のデータを扱うにはそれぞれ専用のストレージシステムが必要である」という意味で、それはもちろん正しいのですが最近では少し様子が違ってきています。特にメモリーの大容量化、低コスト化により、一つのストレージシステムで従来のNAS(特にファイルサーバーのような用途で利用される)、高速ブロックストレージ(GPUを利用したトレーニングなどの高速処理が必要な用途で利用される)、オブジェクトストレージ(アーカイブ等低コストで大容量のデータを保存する用途で利用される)の用途を満たすことができるようになってきました。具体的にはCephのようなオブジェクトストレージでも、GPUの処理帯域を十分まかなえるようになってきたのです。Cephはいわゆるユニバーサルストレージとも言えるものでファイル・ブロック・オブジェクトすべてのデータ・フォーマットに対応できます。従来は異なるストレージシステム専用の管理者が必要だったものが1つのストレージで一元管理できます。それだけでもデータのサイロ化はかなり改善するでしょう。 以下の図はMLワークフローとデータフローを表したものですが、この例ではデータレイクからGPUでの学習を行うストレージ、さらにアーカイブ用のデータまで、Cephだけで管理ができるようになります。

f:id:yojiino:20210107151640p:plain
ストレージを統一し管理の複雑さと属人化を排除

少し余談にはなりますが、MLデータフローで今から取り入れておく必要がある技術を紹介しておきたいと思います。それはリアルタイムデータフローです。前述しましたようにMLモデルは鮮度が重要です。一週間に一度のバッチ処理で得られたインサイトからビジネス計画をねっていても後手後手に回ってしまいます。それはビジネス機会の損失、さらにはコストとリスクの増大にも繋がります。すでに現代ではリアルタイム処理が一般化しておりそれはAI/MLの世界でも例外ではないのです。ではリアルタイム処理を実現する技術としては何が必要なのでしょうか?ここでは以下の3つのコンポーネントを紹介したいと思います。

  1. バケット通知ができるオブジェクトストレージ Ceph
  2. ストリーミングデータ処理をする Kafka
  3. イベント駆動のサーバーレス  KNative

この3つを組み合わせてできるリアルタイム処理はイベント駆動型と呼ばれていて、以下のような流れで動作します。この例は肺のレントゲン写真からの早期判断をするシステムですが、新型コロナの早期発見・対応にも応用できることは言うまでもありません。

f:id:yojiino:20210107151645p:plain
リアルタイムデータフローのユースケース

MLOps - AI/ML活用をリアルワールドで実現する

さて、前の章でMLOpsについて触れましたが多くのみなさんが「これどこかで見たことがある!?」と思われたのではないでしょうか?それもそのはずMLOpsはDevOpsのML版だからです。MLOpsという言葉が使われたのは2018年のGoogleのイベントが最初と言われていますので、Googleから引用しますと、「MLOps は、ML システム開発(Dev)と ML システム運用(Ops)の統合を目的とする ML エンジニアリングの文化と手法です。」ということになります。そしてMLOps を実践すると、統合、テスト、リリース、デプロイ、インフラストラクチャ管理など、ML システム構築のすべてのステップで自動化とモニタリングを推進できます。

f:id:yojiino:20210107151651p:plain
MLモデル開発とMLOps・DataOpsの関係  https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf

すでに解説してきましたようにML開発自体はMLモデルを実際に活用するための小さな一つのピースに過ぎません。そのモデルをできるだけ早く開発、リリースし継続的にフィードバックして再学習するループを高速に回すためにはMLOps、DataOpsがとても重要になってきます。 そしてこれらを取り入れることでAI/MLのワークフローは以下の図のようにとてもスッキリします。 最も重要なのはここでは最初に提起した4つの課題が解決できていることです。

  • 人材不足:セルフサービス化によりそれぞれのペルソナが自分の仕事に専念し生産性を最大化できる

  • インフラとアプリの陳腐化: 常に最新の開発・テスト環境が提供されている

  • コラボレーションの欠如:ペルソナ間の無駄な打ち合わせとコミュニケーションミスの低減

  • データのサイロ化:データ管理の一元化とリアルタイム対応によるデータの流動性向上

f:id:yojiino:20210107151655p:plain
Red HatポートフォリオによるAI/MLソリューション

とはいえAI/MLの世界で利用されているコンポーネントはほとんどがOSSです。それを一つ一つ選択、管理していくのは時間のかかる作業ですしスケールすればするほど生産性も落ちていきます。そのため主なOSSを一つのプラットフォームにまとめたソリューションが必要とされてきました。いわゆるML as a Serviceです。レッドハットがリードして開発しているオープンソースフレームワークOpen Data Hub(以降ODH)は以下のようなAI/ML開発に必要なコンポーネントをコンテナ型のサービスで提供するオープンプラットフォームで、オープンソースのAI/MLツールの開発・運用を自動化・セルフサービス化を実現します。

f:id:yojiino:20210107151702p:plain
Open Data HubによるML as a Serviceの実現

ユーザー事例

最後にいくつかユーザー事例を紹介したいと思います。適切なAI/MLの実装をすることにより、あらゆる分野で大きな効果が実現できています。このBlogでは詳細の説明は割愛しますがご興味があればRed Hat担当者までご連絡ください。

ロイヤルバンクオブカナダ銀行(不正検知) (英語)

  • 1300万レコードを20分で分析
  • 数日で新しいMLモデルを更新
  • 従来の10倍のトレーニングが可能に

https://www.redhat.com/ja/about/press-releases/royal-bank-canada-and-borealis-ai-announce-new-ai-private-cloud-platform-developed-red-hat-and-nvidia

・ExxonMobile(MLセルフサービス)

  • 1つの共通プラットフォームを130チームで共有
  • 年間プロジェクト数が10倍に
  • データサイエンティストはMLモデル開発に集中

https://www.redhat.com/ja/success-stories/exxonmobil

・BMW(自動運転システム開発)

  • 230PBのデータ分析基盤を3ヶ月で構築
  • 9万コアのGPUクラスターの設定を自動化
  • レガシーアプリもOpenShift上で活用

https://www.redhat.com/ja/success-stories/bmwgroup

・HCA(敗血症の早期検出)

  • 1日あたり3万人の患者をモニター
  • 治療にとりかかる時間を5時間短縮
  • ヒット率が3.3%から92.2%に向上

https://www.redhat.com/ja/success-stories/hca-healthcare

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。