第3回勉強会：異音検知プラットフォーム開発を通した機械学習プロダクト開発の体制と課題：MLOpsイベントレポート

異音検知のプラットフォームを開発する際に、リサーチャとソフトウェアエンジニアでどのようなMLOps体制を組んだのか。また、そこでは何が課題となったのか。MLOps導入の参考にしてほしい。

[シバタアキラ, 小島繁樹, 松館学, 田中翔，共著]

連載目次

　MLOpsコミュニティーは「全ての機械学習モデルが現場で実運用化される世界」を目指して2020年夏に始まりました。月1回程度の頻度での活動を目指し、勉強会やワークショップ、ディスカッションなどを行うことで、今後のAI技術の発展に非常に重要な、MLOps（機械学習の実運用化）の普及に貢献していきます。

　このレポートでは、2020年10月に行われた第3回勉強会の様子をお伝えします。今回の勉強会ではHmcommの齋藤翔太氏による「異音検知プラットフォーム開発におけるMLOpsの実際と考察」というタイトルで発表が行われました。発表は1つにも関わらず、100人以上の参加者がリモートで参加し、多くの質疑応答が行われ盛況なイベントとなりました。

本発表での用語の整理

　はじめに、齋藤氏は用語の整理／定義をしました。データサイエンティストという用語が頻繁に使われるようになり、一つの職種として認知されるようにはなりましたが、具体的な仕事としては人によってイメージ／想定するものや捉え方が異なることがあると著者は考えております。そのような状況もあり、用語の整理を最初にされたことは非常に重要で、このおかげもあり後半の発表で著者の伝えたいメッセージを咀嚼（そしゃく）しやすかったです。

　ここでは、リサーチャ、ソフトウェアエンジニアを図1のように定義しており、データサイエンティストがリサーチャの中に入っているのが特徴的です。会社ごとにこのような定義は異なると思いますし、もし研究という文脈のデータサイエンティストを知らない人はそのように含む場合があると気づきにもなったのではないでしょうか。

図1　本発表における用語の整理（リサーチャとソフトウェアエンジニアの分類）

本発表で扱うビジネスとプラットフォームの紹介

　次に、発表者が担当している事業の紹介になります。異音検知の事業になりますが、このビジネスは聞き慣れていない方も多いかもしれませんし、著者も初めて聞くビジネスでした。

　齋藤氏によるとこのビジネスがもたらす利点としては、例えば機械の音をモニタリングするときに水漏れの音を確認できたらAIが故障と判断し、操業を一時停止し早期に故障を検知することができるなどがあります。図2のように異音は身近に存在します。そういった異音に対してAI／機械学習を適用してその検知を自動化できれば、機械の自動故障検知／停止や人的被害の早期発見／防止につながり、社会問題も解決できるインパクトを持っていると齋藤氏は説明しました。

図2　異音とは？

　齋藤氏は次に本発表で取り扱う異音検知プラットフォームFAST-Dのシステム概要を説明されました。このシステムでは図3に示すように、人が学習用のデータとそのラベルをプラットフォームに投入し、学習モデルを自動的に生成して、IoTデバイスに配布します。そのIoTデバイスでは音声を取得しているので、その音声から異音を検知し、ユーザーへ異常通知を行います。

図3　異音検知プラットフォームのシステム概要

本発表で定義するMLOpsの定義

　次にMLOpsの定義について、グーグルやマイクロソフトでのMLOpsの定義を引用しながら齋藤氏ご自身の意見を交えて説明しました。リサーチャもソフトウェアエンジニアも、「世の中をよりよくしたい」「ユーザーの課題を解決したい」という目的は一致しています。ResDevOps（研究部門も巻き込んだDevOps）という概念を引用し、「リサーチャの役割か」「ソフトウェアエンジニアの役割か」とロールを分けることなく課題を解決することが重要であると指摘しました。それを踏まえて齋藤氏は本発表で、

ResDevOps体制で開発された学習モデルを、AIシステムを通じて課題を解決したいユーザに向け、安全、かつ、期待品質で提供する体制、及び、活動のこと

をMLOpsの定義としました（図4）。

図4　本発表におけるMLOpsの定義

MLOpsの体制と開発フロー

　次に、MLOpsを実現するための開発体制と、前処理および学習モデル生成の開発フローが紹介されました。

　まずリサーチャとソフトウェアエンジニアではバックグラウンドが異なることが説明されました。バックグラウンドが違うだけではなく、ロールの目的にも関わりますが、利用したいプラットフォームや作業の性質も違います。リサーチャは、モデルの精度を上げるためTry and Errorの回数が多く、オンプレミスの高スペックのマシンを期待する方向にあります。一方のソフトウェアエンジニアは、クラウドで運用トラブルや運用構成は最小限に行いたいという方向にあります。