MLOpsコミュニティの運営と学び
本投稿はテックコミュニティの運営の知見と、そこから得られたMLOpsのノウハウをまとめたものになります。
２０２１年の４月くらいからMLOpsコミュニティの運営に参加させて頂いています。本コミュニティは元々DataRobot JapanがMLOpsの情報共有や推進を目的に2020年くらいに始めた業界横断コミュニティです。
DataRobot Japanがスポンサーとして配信システムのRemoを提供してくださっていますが、実際にはDataRobotに関わらない内容で勉強会を開くことが多く、業種や企業を問わないオープンなコミュニティとして運営しています。
毎月一回、１時間程度の勉強会と交流会を開催しているので、MLOpsや機械学習の実用化に興味のあるエンジニアは是非ご参加ください。
宣伝
2021年最後のMLOps勉強会は12月8日（水）を予定しています。
内容はベクトル近傍探索技術とA/Bテストの2本立てです。
ぜひご参加ください！
私がコミュニティを運営する目的
MLOpsコミュニティを運営する目的はconnpassに書いてあるとおりいくつかありますが、個人的には以下3点を目標にしています。
- 機械学習を実用化する方法論をオープンにしていく。
- 機械学習界隈以外にも機械学習を選択肢のひとつにする。
- 機械学習の「機械学習以外」エンジニアが活躍するための啓蒙活動。
それぞれについて説明します。
1.機械学習を実用化する方法論をオープンにしていく。
機械学習を実用的に使って価値を生むためには機械学習以外の開発や運用が必要、というのは頻繁に言われていることです。しかしその実用化のためのオープンなノウハウはまだまだ乏しいというのが現状です。新製品やサービスに機械学習を使っている事例や、生成系のディープラーニングで面白い絵や文章が書けた、という情報は多々ありますが、プロダクトとして世の中で使われるようにするために必要な実用化のノウハウは全然足りていません。機械学習に限らずソフトウェアプロダクトを実用化するためには、ソフトウェアを使うためのインターフェイスデザインや実行環境構築、更新や障害対応等の運用、コスト対効果と価値検証といったタスクが必要になります。これら非機能要件やビジネス要件に、機械学習を組み込んだソフトウェアで課題解決するのが機械学習の実用化に必要な業務になります。機械学習のモデルを開発するだけでは終わりません。
2.機械学習界隈以外にも機械学習を選択肢のひとつにする。
機械学習を活用できる領域は日進月歩で広がっています。分類や回帰だけでなく、変形（超解像や文章要約）や生成（文章作成や画像生成）のような領域でも機械学習の有効性は証明されています。様々な領域で使われるということは機械学習の専門家のいない界隈でも機械学習が有効なこともあるわけです。本当にその領域で機械学習が有効か判断することは難しいかもしれませんが、それはすべての施策に言えることです。簡単に使って試して良し悪しを判定できるならそれに越したことはないので、機械学習は機械学習エンジニアやデータサイエンティスト以外も簡単に使えるツールになっていくことが望ましいと思います。
3.機械学習の「機械学習以外」エンジニアが活躍するための啓蒙活動。
私は機械学習が日本で流行り始めた２０１６年頃から機械学習そのものよりも機械学習を実用化するエンジニアリングや基盤開発を仕事にしてきたのですが、当時の機械学習界隈で機械学習のためのシステムを作ることに価値を見出すエンジニアや企業は極少数だったように思います。AIブームによって機械学習やディープラーニングが世の中のバズワードになったのはご存知のとおりですが、単にモデルの精度を高めるだけでなく、それを安く早く安定してプロダクトに組み込むエンジニアリングが必要になってくると信じて働いてきました。運良く２０２１年現在ではMLOpsエンジニアの求人が増えてきていますし、機械学習エンジニアの求人でも機械学習の開発＋ソフトウェアエンジニアリング能力を要件にする案件も多々見るようになってきました。新技術（機械学習は新技術ではないですが）が世間に広まる条件は世の中で実際に使われているプロダクトにその技術が実際に問題なく使われることだと思います。実用化するための技術は新技術そのものと同じくらい難しいですし、機械学習をDevOpsするスキルのあるエンジニアがもっと世の中で価値あるエンジニアとして認識される（そして単価も高くなる）よう、機械学習の実用化とMLOpsの重要性を広めていきたいと思っています。
MLOpsコミュニティで得られた知見
MLOpsコミュニティでは毎月一回MLOps勉強会を開催しています。勉強会ではMLOpsや機械学習の実用化を目指して開発しているエンジニアに登壇いただき、20分~30分程度で事例や知見、ノウハウを話してもらい、その後QAで質問に答えてもらっています。
これまで扱った勉強会のテーマには以下が含まれます。
- 機械学習基盤（MLFlow、Vertex AI、KubeFlow、AirFlow、Polyaxon等）
- エッジAI（スマホ、ロボット）
- ライブラリ（DVC、ONNX、PyTorch Lightning）
- 手法（Continuous Training、アノテーション、特徴量エンジニアリング、近傍検索、A/Bテスト）
この記事では機械学習の実用化を進めるにあたって各社が実施しているプラクティスを紹介します。技術やライブラリについてはGoogle検索すれば見つかります。しかし開発手法や進め方はそう簡単には見つからないのが実情なので、ここに再掲します。
なお、一部の勉強会については資料や動画がconnpassに掲載されているので御覧ください。
知見1. データ基盤とアノテーション
データがないと機械学習を始めることはできません。そしてビジネスで用いるデータの多くは時間とともに変化します。新しいデータが追加されることもあれば、データの意味が変わることもあります。最新のデータを常に素早く得られる環境（いわゆるデータ基盤やデータパイプライン）が整っていることは、機械学習エンジニアやデータサイエンティストが活躍する重要な条件となります。データ基盤が整っていない職場でいきなり機械学習エンジニアに活躍させようとしても、使うデータが得られずに活躍が難しいことが多いのです。そうした職場の場合、機械学習エンジニアやMLOpsエンジニアの最初の仕事がデータパイプライン開発になることもあります（私はその経験があります）。
MLOpsコミュニティで自社事例を話しているセッションでは多くの場合、機械学習システムと一緒にデータ基盤も語られています。使っている基盤がBigQueryだったりAirFlowだったり自作だったり様々ですが、機械学習の開発を潤滑に進めるためには安定したデータ基盤の存在が不可欠と言えます。データ基盤はそれ自体ではビジネス的な価値を生みませんし、理解のない環境だとコストと見られることもあります（私はその経験があります）。しかし必要なデータを揃えたデータ基盤は、エンジニアサイド、ビジネスサイド、経営サイドといった広いステークホルダーに判断基準と開発リソースを提供する重要なシステムになります。
加えて機械学習には正しく充分なデータも必要です。データパイプラインによって大量のデータをデータ基盤に登録し、すぐ使える状態になるかもしれません。しかし既存のデータが正しいかどうか、充分かどうかは別問題です。つまり、既存のデータに対して、機械学習やデータサイエンスを用いて課題を解決するにはデータが不十分な場合があります。たとえば猫の画像分類モデルを作りたい場合、猫の画像が大量にあっても、その画像に猫のラベルが貼られていないと画像分類モデルを作ることはできません。既存のデータに新しい意味を付与する作業をアノテーションと言います。データパイプラインとアノテーションによって課題解決に必要なデータを揃えることで、機械学習の開発を始める条件が整うのです。
第7回MLOps勉強会 株式会社メルペイ様による特徴量エンジニアリング基盤
Fintechにおける信用取引に機械学習を導入しています。Fintechでは推論の間違いがビジネスに致命的な影響を及ぼすため、データエンジニアリングや特徴量エンジニアリングでバグが生じないようにAirflowやBigQuery、Tensorflowの各所にData Validationを導入し、データの正確性を担保しています。
第7回MLOps勉強会 株式会社FastLabel様によるデータアノテーション
株式会社FastLabel様はアノテーションサービスを提供しています。Andrew Ng先生が提唱するData Centricな機械学習の実現に向けて、良質な大量のデータを作成することを目標とし、アノテーション作業を効率化するためにディープラーニングや人間による監督のワークフローを導入しています。
第12回MLOps勉強会 株式会社メルカリ様によるEdge AI
株式会社メルカリのEdge AIチームでは「リアルタイム売れるかチェック」の実装にEdge AIとしてスマホサイドでのディープラーニングの推論を導入しています。スマホサイドで推論することでユーザの待ち時間を短縮し、ユーザ体験を向上させる狙いです。Edge AIによってユーザ体験が向上したことをデータドリブンに評価するため、「売れるかチェック」と「リアルタイム売れるかチェック」のユーザ離脱率を比較し、後者のほうが離脱率を改善できていることを解説しています。
知見2. ペアプログラミング
続いて機械学習の開発におけるペアプログラミングの重要性です。機械学習を扱うプロジェクトでチーム開発する場合、チームメンバーには機械学習エンジニアやデータサイエンティストに加えてソフトウェアエンジニア（バックエンドエンジニア、インフラエンジニア、フロントエンドエンジニア等）も参加するでしょう。互いに協力してプログラムを書いてプロダクトを開発することになりますが、多くの場合、機械学習エンジニアのアウトプット（プログラムやモデルファイル）が他のエンジニアのインプット（推論モデルを動かすプログラムを書く）になることが多々あります。こうした時に発生するハレーションが、機械学習エンジニアの書いているプログラムが読めなくてソフトウェアエンジニアがプログラムを再実行しながら書き直すという事態です。
または機械学習を使ったプロダクトが増えてきて、機械学習を開発するための統一した機械学習基盤を用意したいということもあります。昨今であればKubeFlowやGoogleのVertex AI、Amazon SageMaker、OSSのAirflowやPrefect、Polyaxon等が選択肢になるでしょうか。どれを採用するにしても、機械学習基盤を使うためにはその基盤の仕様に則ったコーディングや開発スタイルが必要になります。その開発内容には、機械学習のモデル学習プログラムの書くような機械学習エンジニアが一般的に実施している作業もあれば、インフラ選定やパイプライン定義、REST APIへのリクエスト、データ管理、バージョン管理等、機械学習エンジニアがあまり馴染みがない作業も含まれるでしょう。
チーム開発においても機械学習基盤の導入においても、機械学習エンジニアが機械学習だけではない領域で作業することになり、その開発方法やノウハウを身に付ける必要があります。機械学習エンジニアやデータサイエンティストは、必ずしもソフトウェアエンジニアとして働いた経験があるとは限りません。ソフトウェアエンジニアリングにおいては常識となる知識やスキル（Gitの使い方やフォーマッタの使い方、コードレビューの方法、Jupyter Notebookをインターネットに公開しない方法等）が備わっているとは限りません。逆にソフトウェアエンジニアが機械学習のお作法やコードの書き方、読み方に精通していることは稀です。
チーム開発を始めるにあたり、機械学習エンジニアとソフトウェアエンジニアでペアプログラミングから始めるのは良い作法と言えます。MLOps勉強会でも、機械学習のチーム開発や基盤導入に成功しているチームの多くがペアプログラミングの重要性を説いています。新しく機械学習エンジニアがJoinしたり、基盤を導入したり、プロジェクトを開始する際にはペアプログラミングから始めることが多いようです。期間は1日程度のこともあれば、1週間くらい基盤の使い方をしっかり教え込んで、手離れ良くする場合もあるようです。
第9回MLOps勉強会 Mercari US様によるPolyaxon
Mercari US様では機械学習の開発、実験管理にPolyaxonを導入し、学習の自動化や実験の管理を共通基盤で実現しています。Polyaxonを使用して機械学習のモデルを開発するにあたり、Polyaxonの使い方やコーディング手法を機械学習エンジニアに教える必要があり、ペアプログラミングによって解決しています。
第10回MLOps勉強会 株式会社Repro様によるVertex AIの導入
2021年中盤にGoogle Cloudで新たな機械学習基盤としてVertex AIが提供されました。本セッションでは株式会社Repro様がVertex AIを導入するために検証し、使い方を説明してくれました。Vertex AIはKubeFlowをベースに実現されていますが、その使い方やコーディング手法を含めて機械学習エンジニアとソフトウェアエンジニアでペアプログラミングで開発を効率化しました。
知見3. フレームワークと開発環境の共通化
エンジニア間の開発環境を共通化する利点は、プログラムを安定して開発、ビルド、実行できることにあります。共通化していれば、あるエンジニアの環境で実行可能なプログラムは別のエンジニアの環境やCI/CD環境でも再現できるはずです。共通化するレベルは異なりますが、PythonであればPoetryやPipenvで言語のバージョンやライブラリのバージョンを共通化し、実行環境はDockerで定義してGitで管理するのが一般的だと思います。機械学習の場合、これに加えてデータやパラメータの共通化が課題になります。学習に使用するデータやパラメータが異なると学習の結果が異なることになるため、あるプログラムで使うデータやパラメータは共通化しておいて、実験時に変更するのであれば変更を記録しておくことが求められます。パラメータの一括管理であればHydraというライブラリが便利ですし、データとパラメータの記録であればDVCを使うことができます。
これに追加で、開発する構造の共通化も重要です。同じ機械学習の学習プログラムを書くにしても、片やJupyter Notebookで全て書いており、片やPythonスクリプトで書いているようだと、お互いにコードレビューすることは難しいでしょう。または同じPythonで書くにしてもディレクトリ構成や実行方法を定義しないと、プロジェクトやモデルによってコード品質や構造が異なるものになり、別のプロジェクトのコードを理解するのが難しくなります。社内で機械学習チームが存在し、複数のメンバーが在籍しているなら開発環境やコードの構造は共通化しておくほうが良いでしょう。
手前味噌ですが、私が機械学習のモデルを開発するときのディレクトリ・ファイル構造は以下のようにしています。もちろん開発対象やプロジェクトによって多少異なりますが、コードの配置や使用するライブラリは概ね同じもので実現しています。
ml ... ルートディレクトリ
├── data ... データを保持するディレクトリ; DVCで管理
├── Dockerfile ... 学習用DockerImageのファイル
├── __init__.py
├── hydra ... Hydraで使用するパラメータファイルのディレクトリ
│ ├── default.yaml ... パラメータ
├── outputs ... 学習で出力したモデルやログ、推論結果等を保存するディレクトリ; MLFlowで管理
├── poetry.lock ... Poetryで定義したライブラリ一覧
├── pyproject.toml ... Poetryの設定
├── requirements.txt ... poetryから出力したライブラリ一覧
└── src ...
├── __init__.py
├── configurations.py ... 基本的な設定値の定義
├── repository ... データI/O用コードのディレクトリ
│ ├── __init__.py
│ ├── data_manager.py
│ └── schema.py
├── jobs ... 各種実行ジョブを定義したコードのディレクトリ
│ ├── __init__.py
│ ├── evaluate.py ... 評価の実行
│ ├── optimize.py ... ハイパーパラメータチューニングの実行
│ ├── predict.py ... 推論の実行
│ ├── register.py ... 外部へのデータ登録の実行
│ ├── retrieve.py ... 外部からデータ取得の実行
│ └── train.py ... 学習の実行
├── main.py ... 実行ファイル
├── middleware ... 汎用的に使用可能なミドルウェア
│ ├── __init__.py
│ ├── logger.py
├── models ... 前処理や機械学習モデルを定義するコード
│ ├── __init__.py
│ ├── base_model.py
│ ├── random_forest_classifier.py
│ └── preprocess.py
└── optimizer ... ハイパーパラメータチューニングのコード
├── __init__.py
├── optimizer.py
└── schema.py
こうした構造を毎回作ることもあれば、たとえばcookiecutterやjinjaでテンプレートを作ることも可能です。または機械学習基盤を使うにあたって、必要なライブラリを網羅したテンプレートを用意しておくという手段もあるでしょう。DevOpsやMLOpsは個人よりもチーム開発で使われるプラクティスであるため、チーム開発を円滑化に進めるための開発環境の共通化は重要な要素になります。
第4回MLOps勉強会 Sansan株式会社様によるDVCの活用
DVCを活用し、研究開発におけるデータの管理、バージョニングを実現する方法を講演しました。機械学習開発では多様なデータで検証してより良いモデルを開発しますが、その際にどのモデルがどのデータで学習したのかをGitとともに管理するためDVCを導入しています。
第10回MLOps勉強会 日本マイクロソフト株式会社様によるMLFlowの活用
Microsoft AzureではMLFlowを機械学習開発のライブラリの一つとして選択しており、MLFlowで学習ログを取得したモデルをMicrosoft Azure内で管理し、評価の見える化や推論器のデプロイを実施可能にしています。
第13回MLOps勉強会 JX通信社様による機械学習開発の共通フレームワーク化
JX通信社様では機械学習開発の効率化のため、開発レポジトリのディレクトリ構成やコードをテンプレート化し、共通フレームワークの中で開発する状態を実現しました。
知見4. 出口を作る
DevOpsにしてもMLOpsにしても、やろうとしているのは開発と実行のフィードバックループを仕組み化することだと思います。MLOpsの場合はその一部に機械学習パイプラインや自動学習（Continuous Training, CT）、リリース自動化（Continuous Deployment, CD）が組み込まれるのですが、目的はあくまでフィードバックループを素早く正確にまわしてビジネス価値を高めることであって、機械学習パイプラインやCT/CDを導入することではありません。最終的にはプロダクトの中で機械学習を有効活用して、社内外のユーザに価値を提供することが目的になります。その価値の由来が時間とともに変化し、定期的に更新が必要な場合にCT/CDが有効になるのだと思います。
多くのデータは時間とともに変化しますが、その変化が自動的にわかるかどうかは別問題です。たとえば株価予測や需要予測のように時間経過で結果が判明するものもあれば、違反検知のように人間が判断しないと発見できないデータもあります。前者であれば時間経過で定期的に機械学習パイプラインを実行し、推論結果を自動的に取得することができるでしょう。対して後者は人間がデータを作らないと新しいデータを得ることはできないため、時間経過による自動化は難しいでしょう。もちろん特定の違反データが一定量以上になったら機械学習パイプラインを実行するという自動化は可能ですが、いずれにしても人間の作業を加えたワークフロー（ヒューマンインザループ）が必要になります。つまり、機械学習パイプラインを有効活用するためには機械学習の出口となるビジネスの枠組みに当てはめる必要があるということです。
こうしたビジネススキームに合った機械学習パイプラインの実現は以下のセッションで取り上げています。
第6回MLOps勉強会 株式会社α様によるWeb広告のMLOps
このセッションではWeb広告配信のRTB（real time bidding; リアルタイム広告枠取引）最適化で機械学習を導入しており、そのモデル開発、改善にTFXやArgoを用いた機械学習基盤を導入しています。
第13回MLOps勉強会 JX通信社様によるニュース速報のMLOps
このセッションではJX通信社様によるニュース速報配信のため、配信対象のニュースを選定する部分に機械学習を導入しています。配信対象の判定には人間の判断を加えてヒューマンインザループを実現しています。
まとめ
というわけで、MLOpsによる機械学習開発の実用化や効率化はどんどん加速しています。MLOpsに興味がある方はぜひMLOps勉強会に参加（または登壇）してください！