先日開催されたQCon PlusオンラインカンファレンスでFrancesca Lazzeri博士は、マシンラーニングオペレーション(MLOpe)について、"What You Should Know before Deploying ML in Production"と題して講演し、MLOpsの可能性、オープンソースインテグレーション、マシンラーニングパイプライン、MLFlowプラットフォームという４つの重要なトピックを取り上げた。
Microsoftのプリンシパルデータサイエンティストマネージャで、コロンビア大学ではAIとマシンラーニングの非常勤講師を務めるLazzeri博士の講演は、 大規模データセットの収集とクリーニングから、複数の実験の追跡、運用システムへのモデルのデプロイと監視に至るまで、MLプロジェクトがそのライフサイクル内に出会ういくつかの課題に関する議論で始められた。氏が取り上げたのは、データサイエンティストとエンジニアが考慮すべき4つの重要な領域だ。最初に氏は、モデルの管理とデプロイメント、監視を行う、MLOps機能の概要について説明した。その次には、ディープラーニング用およびマシンラーニングパイプライン管理用のオープンソースツールのいくつかについて議論した。そして最後に、MLFlowというオープンソースのマシンラーニングプラットフォームについて、その概要を説明した。講演後に行われたQ&Aセッションで、Lazzeri博士は、MLOpsを"静的ツール"として考えないように、と警告した。そうではないのだ、と氏は言う。
MLOpsはもっと文化的な存在であって、さまざまなツールをエンドツーエンドの開発環境にいかに結び付けることができるか ... さらには、そこから生まれ機会をどのように最適化できるか、といったことに思いを巡らせるものなのです。
講演はまず、MLアプリケーションの開発とデプロイに伴う、いくつかの課題に関する議論から始まった。MLによるモデルのトレーニングには大量のデータを必要とするが、これらのデータセットの追跡、管理には困難が伴うことがある。さらに、特徴エンジニアリング(feature engineering) — データセットの特徴の抽出とカタログ化 — にも課題がある。正確なモデルをトレーニングするのは、さまざまなモデルアーキテクチャとハイパーパラメータ値を使用した多くの実験を要する場合があるため、これも追跡しなくてはならない。そして最後に、モデルを運用環境にデプロイした後は、それを監視する必要がある。これは通常のWebアプリの監視とは違う — 応答のレイテンシや例外といった標準的なパフォーマンスデータに加えて、モデルの予測を真実の情報(ground truth)と比較評価した上で、実世界のデータが最初に収集したデータから逸脱した場合には、ライフサイクルプロセス全体を再実行する必要があるのだ。
MLOpsは、データサイエンティストやエンジニアが課題をチャンスとして捉えられるようにする。Lazzeri博士は、MLOpsの重要な役割として、以下の7つを挙げた。
- 再現性のあるMLパイプラインを実現する
- トレーニングおよびデプロイ用の再利用可能なソフトウェア環境を構築する
- 任意の場所にモデルを登録、パッケージ、デプロイする
- MLライフサイクル全体にわたってガバナンスデータを追跡する
- ライフサイクル内のイベントを通知および警告する
- アプリの運用上およびモデル上のイシューを監視する
- さまざまなパイプラインを使ってライフサイクル全体を自動化する
続いて氏は、これらの機能を支援するオープンソースパッケージについて論じた。最初に挙げたのは、トレーニングモデルとしてポピュラーなフレームワークであるPyTorch、TensorFlow、Rayの３つだ。コマーシャルユーザを対象にした調査では、約60パーセントがTensorFLowを、約30パーセントがPyTorchを使用している、とLazzeri博士は述べた。Rayは強化学習(reinforcement learning)に特化した多くの機能を備えているが、博士によると、その一部はベータや、あるいはまだアルファの状態であるということだ。さらに氏は、解釈可能かつ公平なモデル(interpretable and fair models)用のフレームワークとして、説明可能な"ガラスボックス"モデルのトレーニングとブラックボックスモデルの説明が可能なInterpre ML、およびモデルの不公平性の検出と修正が可能なPythonパッケージのFairlearnの２つを取り上げて説明した。その他として氏は、さまざまなフレームワークでトレーニングされたモデルを広範なハードウェアプラットフォームに展開可能にする、相互運用フレームワークのOpen Neural Network Exchange(ONNX)についても、その使用を推奨している。
次にLazzeri博士は、データの準備、モデルのトレーニングと評価、デプロイメントを管理するMLパイプラインについて論じた。氏は３つのパイプラインのシナリオを概説した上で、それぞれに適したオープンソースのフレームワークとして、データからモデルへのパイプラインを管理するKubeflow、データからデータへのパイプラインを管理するApache Airflow、コードからサービスへのパイプラインを管理するJenkinsの3つを推奨した。それぞれのシナリオには異なる長所があり、異なるペルソナに — Kubeflowはデータサイエンティストに、Airflowはデータエンジニアに、Jenkinsは開発者やDevOpsエンジニアに — アピールする。最後に氏は、MLライフサイクル全体を管理するオープンソースプラットフォームのMLFlowの概要を説明した。MLFlowには実験の追跡、再現性のある実行のためのコードのパッケージ化、運用環境へのモデルのデプロイ、モデルと関連データの管理を行うコンポーネントがある。
セッションの最後には、Lazzeri博士が聴衆の質問に答える時間が設けられ、何人かがONNXについて質問した。Lazzeri博士は自身の調査結果として、回答者の約27パーセントがONNXを使用していたことを回答した。また、RayやPyTorchによるモデルがONNX上で良好に動作することも付け加えた。開発者がモデルトレーニングの規模を拡大するための優れたソリューションとして、氏は自動マシンラーニング(AutoML)の使用を推奨した。支援するツールは存在するものの、運用環境におけるMLの正確性の監視はいまだ手作業に頼る部分が大きいと述べて、氏は自身の講演を締め括った。