第3回勉強会：異音検知プラットフォーム開発を通した機械学習プロダクト開発の体制と課題：MLOpsイベントレポート
異音検知のプラットフォームを開発する際に、リサーチャとソフトウェアエンジニアでどのようなMLOps体制を組んだのか。また、そこでは何が課題となったのか。MLOps導入の参考にしてほしい。
MLOpsコミュニティーは「全ての機械学習モデルが現場で実運用化される世界」を目指して2020年夏に始まりました。月1回程度の頻度での活動を目指し、勉強会やワークショップ、ディスカッションなどを行うことで、今後のAI技術の発展に非常に重要な、MLOps（機械学習の実運用化）の普及に貢献していきます。
このレポートでは、2020年10月に行われた第3回勉強会の様子をお伝えします。今回の勉強会ではHmcommの齋藤翔太氏による「異音検知プラットフォーム開発におけるMLOpsの実際と考察」というタイトルで発表が行われました。発表は1つにも関わらず、100人以上の参加者がリモートで参加し、多くの質疑応答が行われ盛況なイベントとなりました。
本発表での用語の整理
はじめに、齋藤氏は用語の整理／定義をしました。データサイエンティストという用語が頻繁に使われるようになり、一つの職種として認知されるようにはなりましたが、具体的な仕事としては人によってイメージ／想定するものや捉え方が異なることがあると著者は考えております。そのような状況もあり、用語の整理を最初にされたことは非常に重要で、このおかげもあり後半の発表で著者の伝えたいメッセージを咀嚼（そしゃく）しやすかったです。
ここでは、リサーチャ、ソフトウェアエンジニアを図1のように定義しており、データサイエンティストがリサーチャの中に入っているのが特徴的です。会社ごとにこのような定義は異なると思いますし、もし研究という文脈のデータサイエンティストを知らない人はそのように含む場合があると気づきにもなったのではないでしょうか。
本発表で扱うビジネスとプラットフォームの紹介
次に、発表者が担当している事業の紹介になります。異音検知の事業になりますが、このビジネスは聞き慣れていない方も多いかもしれませんし、著者も初めて聞くビジネスでした。
齋藤氏によるとこのビジネスがもたらす利点としては、例えば機械の音をモニタリングするときに水漏れの音を確認できたらAIが故障と判断し、操業を一時停止し早期に故障を検知することができるなどがあります。図2のように異音は身近に存在します。そういった異音に対してAI／機械学習を適用してその検知を自動化できれば、機械の自動故障検知／停止や人的被害の早期発見／防止につながり、社会問題も解決できるインパクトを持っていると齋藤氏は説明しました。
齋藤氏は次に本発表で取り扱う異音検知プラットフォームFAST-Dのシステム概要を説明されました。このシステムでは図3に示すように、人が学習用のデータとそのラベルをプラットフォームに投入し、学習モデルを自動的に生成して、IoTデバイスに配布します。そのIoTデバイスでは音声を取得しているので、その音声から異音を検知し、ユーザーへ異常通知を行います。
本発表で定義するMLOpsの定義
次にMLOpsの定義について、グーグルやマイクロソフトでのMLOpsの定義を引用しながら齋藤氏ご自身の意見を交えて説明しました。リサーチャもソフトウェアエンジニアも、「世の中をよりよくしたい」「ユーザーの課題を解決したい」という目的は一致しています。ResDevOps（研究部門も巻き込んだDevOps）という概念を引用し、「リサーチャの役割か」「ソフトウェアエンジニアの役割か」とロールを分けることなく課題を解決することが重要であると指摘しました。それを踏まえて齋藤氏は本発表で、
ResDevOps体制で開発された学習モデルを、AIシステムを通じて課題を解決したいユーザに向け、安全、かつ、期待品質で提供する体制、及び、活動のこと
をMLOpsの定義としました（図4）。
MLOpsの体制と開発フロー
次に、MLOpsを実現するための開発体制と、前処理および学習モデル生成の開発フローが紹介されました。
まずリサーチャとソフトウェアエンジニアではバックグラウンドが異なることが説明されました。バックグラウンドが違うだけではなく、ロールの目的にも関わりますが、利用したいプラットフォームや作業の性質も違います。リサーチャは、モデルの精度を上げるためTry and Errorの回数が多く、オンプレミスの高スペックのマシンを期待する方向にあります。一方のソフトウェアエンジニアは、クラウドで運用トラブルや運用構成は最小限に行いたいという方向にあります。
そのような方向性の違いの中、効率的に効果的にユーザーへ価値を提供するため、ソフトウェアエンジニアからリサーチャへコミュニケーションを取っています。図5に示すように前処理では、まずはリサーチャが多様な前処理を実装します。次にソフトウェアエンジニアがその仕様をヒアリングし、それをクラウドのマネージドサービスによる最適なソリューションとして構築する、ということを行っています。リサーチャが実装した前処理のコードは、具体的にはAWS Lambdaに移植することが多いですが、Lambda特有のコードの書式があるので、それに合わせて書き換える手間がかかるという欠点もあります。できるだけコードを変えずそのまま移植するなら、Amazon ECSでコンテナを活用しているとのことです。
また、学習モデルの生成に関してソフトウェアエンジニアは、リサーチャに最新のコードを確認して、それをAmazon SageMakerに移植して活用します。学習モデルをプロダクトに適用するために、複数のモデルを作成し最もよい精度のモデルを選択します。そのために、機械学習のインスタンスを同時に立ち上げながらモデルの精度を比較しているとのことです。モデルの評価の際には、テストデータとリサーチャから受け取り結果が一致しているかを確認することも重要であることを説明されていました。
現状のMLOpsの取り組みにおける課題と取り組み
ResDevOpsの体制として前掲の図5の環境を既に確立できているので、リサーチャとソフトウェアエンジニア間でコミュニケーションが取りやすく、仕様を都度確認できている、と齋藤氏は説明されていました。また、スクラム開発を導入しているため、毎日のアップデートを確認するだけでなく、1〜2週間に1回、KPT（Keep／Problem／Tryによる振り返り）や反省会を行い、改善サイクルを回しているそうです。
問題点を挙げると、リサーチャに関してはPoCの進捗（しんちょく）速度が速いため、ソースコードと結果の関連管理が乱雑になりがち、と齋藤氏は指摘されました。これは経験とセンスもあるので一概に問題点とは言い難いところはあるがよりよくしたい、とのことです。
ソフトウェアエンジニアの問題点は、リサーチャが考えたものを移植するので、推論に適した精度に達さないことがあることです。もちろんできるだけ最終的に推論精度に達するように注力しているそうです。ただ、注力するためにチームの総力をかけすぎることもあるので、もっとよくできないか考えているようです。
また、AI／機械学習による音声処理はまだまだ新しい分野であるため、努力して開発したものの次のバージョンで変えることも多々生じるとのことです。費用対効果の見極めが難しいのが課題として挙がっているそうです。
理想としては、開発環境が統一され、使うコードが一つになっており、1人に技術や知識が依存しないことです。その理想につなげるために改善として、リサーチャ側での開発フレームワークの開発と適用や、毎日1人、技術発表の実施を行いナレッジの共有を行っているようです。
おわりに
齋藤氏の発表していた“データサイエンティストが作成し、それをソフトウェアエンジニアがプロダクトに移植する場合に、そのままコードを移せない”という話は、著者はどちらのロールも経験があるため、どちらの気持ちも分かります。その一方、全体を考えると最適な状況でないのは間違いありません。コンテナにまとめるなどもありますが、プロダクトとして最適にするには移植する必要があり、運用を考えたモデル作成、推論環境の構築は今まさに多くの企業で課題になっていることかと思います。そのような課題に対して現状の課題と取り組みを共有されたことは非常に学びがある発表だったと思います。
本勉強会の資料は下記URLにスライドがアップロードされております。より詳細をご覧になりたい方はそちらをごご覧ください。
今後もMLOpsコミュニティーは定期的に、MLOpsを普及するために勉強会を開催していく予定です。次回の開催は2月18日を予定しております。発表者も募集していますので興味ある方はご連絡ください。
Copyright© Digital Advantage Corp. All Rights Reserved.