MLOps実践者たちのリアルなお悩みの解決にコミュニティーがどう貢献できるか:MLOpsイベントレポート
MLOps(機械学習の実運用化)の活動目的&方針を「デザイン思考」で議論した座談会の内容をレポート。デザイン思考フレームワーク&ツール「MURAL」を紹介し、MLOps実践時の悩みと対策案を議論。世の中が抱えているMLOpsの課題を解決するためにコミュニティーの方針を検討する。
MLOpsコミュニティーは「全ての機械学習モデルが現場で実運用化される世界」を目指して2020年夏に始まりました。月1回程度の頻度での活動を目指し、勉強会やワークショップ、ディスカッションなどを行うことで、今後のAI技術の発展に非常に重要な、MLOps(機械学習の実運用化)の普及に貢献していきます。
このレポートでは、2020年9月に行われた第2回のイベント活動である「MLOpsコミュニティ座談会」の様子をお伝えします。今回はコミュニティーの方針を少人数で議論するため参加者を16人に限定し、リモートで実施しました。よく見かけるオンラインの勉強会とは異なるディスカッション形式の勉強会でした。そこで本稿では初めに、どのようなフレームワーク、ツールを使ったのかを紹介し、その後、ディスカッションの大筋を振り返っていきたいと思います。
デザイン思考とビジュアルコミュニケーション
リモートワークもだいぶ定着してきましたが、大人数で議論するとなるとまだまだ困難に直面する点は多いのではないでしょうか。そこで今回は、デザイン思考のワークショップ形式を取り入れました。
デザイン思考とは、デザイナーの思考スタイルを応用した課題解決フレームワークです。発散と収束を繰り返しながら、問題発見/解決に取り組みます。「デザイン」という名前から、ビジネスマンには関係ないと思われがちですが、日常のビジネスミーティングでも効果を発揮します。
デザイン思考をご存じの方は、付箋を使うイメージをお持ちの方もいらっしゃるかもしれません。オンラインで付箋を使うわけにはいきませんので、ビジュアルコミュニケーションツールを活用します。今回はMURALを利用して、参加者がバーチャル空間で、サイレントブレーンストーミングで付箋に記入しながら、ワークショップを進めていきました。
ビデオ会議でたくさんの人が発言すると収拾がつかなくなることが予想されますので、まずは、参加者が5分間黙って付箋に入力します。その後、付箋に記入した内容を、口頭で説明しながら参加者にシェアします。
サイレントブレーンストーミングの良い点は、参加者が等しく自分のアイデアをシェアできる点です。日常の会議では、社内の立場の強い人の発言に重きが置かれたり、声高な人の発言が目立ったりしますが、付箋に書き出すことで多様なアイデアを収集するにはよい手段です。
こうした「発散」のプロセスで出てきたさまざまなアイデアを、今度はフレームワークを使って整理します。今回は似ているアイデアを「クラスタリング」してアイデアをまとめあげます。こうして、「発散」と「収束」を繰り返し、アイデアを洗練させていきます。
コミュニティーを始める際には、コミュニティーの目的や活動方針を議論したい場合は多いでしょう。その際には、上記のような手順でデザイン思考ワークショップを取り入れてみることで議論がスムーズになるかと思います。
MLOpsの定義
まず自己紹介をした後、参加者が考えているMLOpsの定義について、それぞれ発表しました。オンラインの勉強会で全員が発言し意見を共有することはなかなか難しいですが、MURALを使うことで全員の意見を可視化することができ非常に便利でした。
MLOpsという単語は、2018年頃GoogleのエンジニアがDevOps+MLを組み合わせて作ったという説が有力です。ただし、明確に定義されている言葉でもなく、また言葉が作られてからまだ数年しかたっていないこともあり、成熟した体系、知識にはなっていないと著者は考えています。そのため、使う人によって定義や考え方が定かではないのが事実です。実際のところ、本勉強会でMLOpsの定義をそれぞれ記載し共有したところ似ている意味はあるものの、必ずしも一致しているわけではないことが明らかになりました(図1参照)。本座談会にはエンジニアからコンサルタントまで幅広い肩書の人が参加しており、人それぞれ異なる役割や視点を持っていることなどが要因ではないかと思われます。
例として一部を取り上げると「データサイエンティスト&リサーチャーが開発したモデルをシステムに適切に当てはめる行為」や「システムを本番化する上で、データサイエンティストがやること以外すべて」など、機械学習をシステム化する上でのデータサイエンティストの担当で分けていることや、「機械学習(ML)ライフサイクルを支えるもの一式」などライフサイクル全体を指すものなどが挙がりました。
確かにMLOpsについて明確な定義はありませんが、参加者の共通点として機械学習システムの「ライフサイクル」「エンジニアリング」は確認できました。繰り返しになりますが、この定義について正解はありません。しかし、この後のディスカッションでも何度も話題に挙がりましたが、本コミュニティーとしてのMLOpsの定義を明確化し、コミュニティー参加者の視点をそろえることは必要であると考えています。そこで本記事の最後では、この会を振り返り、コミュニティーにおけるMLOpsの定義を決めたいと思います。
MLOpsにおける日々の悩み
このコミュニティーの活動を考える上で、MLOpsにおいて皆さんが悩んでいることをヒントにしていきたいと考え、MURALを使って悩みを共有してもらいました。その結果が図2になります。
機械学習プロジェクトのビジネス企画からチームビルディング、システム構築などさまざまな悩みが出てきた中でカテゴリ分けしていくと、6つの共通パターンが見えてきました:
- 精度 - ビジネス実装の段階になると、よりシビアなモデル精度が求めることは当然としても、「明確な精度基準がない」、また「いくら精度を上げても完璧でなければ受け入れてもらえない」などの点が挙がった。中には、人間でも間違う判断なのに「機械には完璧を求める」など、機械学習への期待値のギャップも指摘された。
- 環境面 - 特にセキュリティ上の懸念から各種ツールの利用に対する制限がかかったり、APIを使ったサービス化により多部門や他サービスにモデル予測を公開できなかったりするケースが挙がった。
- 属人化 - モデル運用における方法論はまだ確立されていない上、実際の運用はモデル構築者とは別の部門に任されることが多い。適切な運用管理/監視はもとよりモデルの定期的な再構築などはほとんどの場合、実施されず、行われたとしても属人的な手段に依存していて、担当者が変わっていつの間にか動かなくなってしまうようなこともある。
- 予算 - 多くの場合、MLOpsは新しい取り組みであり、そこには事前に予算がついているケースが少ない。予算を取るためには費用対効果(ROI:Return On Investment)を示すことが必要だが、モデル構築担当側は運用コストまでを考えずにROIを算出しているケースが多い。
- 理解されない - 「産みの苦しみ」という言葉も出るほど、現状はMLOpsの実施に対して周りの理解が少ないため、成功するために巻き込まないといけない人たちからも理解を得ることができず、なかなかプロジェクトを前に進めることができない。
- システム構築 - 機械学習モデルは主にデータサイエンティストがコードを書いているケースが多いが、データサイエンティストが書いたコードは本番実装を前提としていなかったり、エンジニアリングの「お作法」を踏まえていなかったりするため、システム化には手間がかかる(ことが多い)。また、機械学習システムの設計にはまだ十分な経験を持っていないエンジニアがほとんどだ。
このように、プロジェクト横断的な問題が多く指摘され、どれも機械学習プロジェクトを企画/運用していく上で避けては通れないものばかりでした。ここからもMLOpsの関連領域の広さが分かります。全体を見ると、MLOpsの「今」について一貫性のあるストーリーが見えてきました。
どの現場も、MLOpsにはまだ経験値が浅く、技術的にも、組織的な側面からも成熟が求められています。
悩みに対する解決策
悩みが一通り出そろったところで、いよいよ解決に向けてどのようなアクティビティーが求められているのかを検討していきました。同じくMURALを使って、幅出しとカテゴリ分けを行った結果が図3です。
さまざまな議論がありましたが、大きく5つの方向性が見えてきました:
- MLOpsの定義 - まだMLOpsという言葉の定義が聞く人によって異なるため、お互いに同じことを指していると思い込んでいるが実は違うということがある。コミュニティーを進めていく上で共通の認識を保つ必要があるのではないか?
- パターン化 - システムデザインのパターン化によるベストプラクティスの共有や、逆に失敗や禁じ手といったアンチパターンの共有による失敗防止。実例の共有による学びなどの共有は多数の希望があった。
- 環境整備 - 上記のパターン化とも関連するが、ナレッジとしてではなく、実際にすぐに使えるAPPコンテナやライブラリ、フレームワークなどを共同開発し、公開する。例えば正解ラベル付与のためのツールや、モデルの継続的再学習のためのフレームワークなどのアイデアが出た。
- 相談できる場所 - 困ったことがあったとき、対処に迷ったときなどに、同志や先駆者に相談できる場所があれば助かる、という声。
- 各回でテーマを設ける - MLOpsの定義の広さとも関連するが、この分野にはさまざまな小分類が存在し、それぞれのテーマによって、関心を持つ人たちも異なってくる。イベント開催時においては、テーマを明確にすることによって同じ興味関心を持つ人たちに集まってもらうことができるように工夫するべき。
実際の議論においては、実施したいコミュニティーアクティビティー内容についての各論で、おのおの考え方にギャップがあるようなところも見られました。しかしそれは、さまざまなバックグラウンドの方に参加していただけたことの裏返しでもあり、その結果、有意義な議論ができました。著者としては、まだMLOpsに対する業界全体での知見が限られている中で、分野は違えど、お互いの経験から学べるような場を作っていくことが重要ではないかとあらためて考えさせられました。
むすびに
最後に活発に議論が行われた議題は、コミュニティーの方向性についてです。
参加者がさまざまな経歴や異なる業界に携わっていることもあり、身近に感じている問題が異なることが明確になりましたので、この方向性を決める上でも、本コミュニティーの中でMLOpsの定義を決めることは非常に重要だと捉えました。今回の勉強会の中で集まった情報を基にオーガナイザーで検討した結果、本コミュニティーでは今後、下記をMLOpsの定義として運営していきたいと思っております。
MLOps: 「機械学習を本番運用するためのライフサイクル」を管理する技術と方法論
このライフサイクルはデータ準備、モデル開発、デプロイ、運用を指す。
今回の勉強会は、オンラインにもかかわらず、参加した全員がMLOpsへの悩み、解決策を活発に議論する勉強会として開催できました。しかしMLOpsが成熟した体系として定まっていない背景からも、知見の展開などが不足していることがあらためて明らかになりました。例えば、各人の悩みを出していただいた際に「環境整備をどう整えていくか」「MLOpsのパターンとしては何があるか」などの悩み/課題は複数の人から出てきました。このような共通の課題について、今後は勉強会でも取り上げ、知見の共有と展開を進めていきたいと思っております。
MLOpsの勉強会は今後も定期的にイベントを開催する予定です。次回は2020年10月27日を予定しておりますので、興味がある方は下記のグループにご登録ください!
- ご登録はこちらから: MLOpsコミュニティーのグループ公式ページ
また、MLOpsコミュニティーのオーガナイザーを勤めるDataRobot社ではさまざまな業界のAIのプロジェクトのユースケース集である「DataRobot Pathfinder」を無料で最近公開しました。このユースケース集を活用すれば、機械学習/AIの自社への適用をイメージしやすいかと思います。例えば、本勉強会の日々の悩みで出てきた「周りへの理解」を促すためにこのようなユースケース集を活用しAIプロジェクトに対しの心理的障壁を緩和することで、少しでも多くのAIプロジェクトが成功されればうれしく思います。ぜひご覧ください。
Copyright© Digital Advantage Corp. All Rights Reserved.