まず認識すべきは、ソフトウェアツールスタックがたくさんのツールで構成されていることだ。

　ソフトウェアエンジニアリングチームが各リリースで使うツールは数十種類に及ぶ。ソースコード管理システム、自動テストスイート、パフォーマンス監視ツール、イベントベースの警告システムなどがその例だ。こうしたツールスタックの構成要素が、ソフトウェア開発サイクルにおいて不可欠であることは誰もが認めるところだ。だが以前はそうではなかった。今では、「GitHub」「CircleCI」「Jenkins」「Docker」「NewRelic」をはじめとする無数のツールが世界中で広く使われている。

　ソフトウェア開発のこうした概念は、機械学習にも当てはまる。機械学習でもコードのソース管理が必要だ。データパイプラインの監視、アプリケーションのコンテナ化、マシンのプロビジョニング、導入エンドポイントのテストを行う必要もある。機械学習では、より大規模で複雑な（特にデータの）操作が必要になる可能性があるが基本は同じで、パイプライン自動化が有益なことも変わらない。

MLOpsを成功に導く4つの要素

　MLOpsには、独自のモデル形態がある。

　MLOpsとは、決定論、スケーラビリティ、アジリティー、ガバナンスをモデル開発とデプロイパイプラインに提供する一連の手法だ。この新しい（と同時に非常に現代的な）パラダイムは、モデルのトレーニング、チューニング、導入のサイクルにおける4つの重要な領域に注目している。それは、機械学習開発の再現性、協調性、スケーラビリティ、継続性だ。

　それでは、それぞれ順に見ていこう。

再現性

　再現性とは、モデルの改善や内外の関係者や規制関係者に対する手法の説明のために、以前の機械学習モデルを数％以内の誤差で再構築できることをいう。これには入力のトレーサビリティーが必要になる。その入力には、データセット、コードのコミット、依存関係とパッケージ、ドライバのバージョン、低レベルのライブラリ、コンテナ、ランタイム、モデルのトレーニングに使用したパラメーター、トレーニング用ハードウェアの仕様、機械学習への具体的な入力（レイヤーの重み付けの初期化）などがある。

　これは簡単な作業ではない。

協調性

　開発者が1人でモデルを開発するのであれば、開発サイクルのこの領域は無関係だ。だが、チームメンバーを増やしながら運用モデルの拡張にチームで取り組むのであれば、適切な協調プロセスがなければシステムは瞬く間に失敗するだろう。

　機械学習チームがうまく協調するには、全てのアクティビティー、リネージ、モデルパフォーマンスを追跡する統合ハブが必要だ。ハブは、フルスタック（概念から研究開発、運用まで）をカバーし、ノートブック、トレーニング実行、ハイパーパラメーターの探索、可視化、メトリック、データセット、コード参照、モデル成果物を可視にする必要がある。

　これには、多くの対象領域の共有が必要になる。

スケーラビリティ

　各機械学習エンジニアにインフラのデプロイを習得するよう求めることは、可能ではあるが賢明ではない。

　というのも、機械学習では大量のデータセットとコストの高いコンピューティング要件を扱う。その上インフラも管理するとなれば、ブラックホールのようにチームの生産性が浪費される恐れがある。データサイエンスチームの各メンバーが需要に応じてコンピューティングインフラを利用できるよう、事前構成する方が妥当だ。

　事前構成済みのリソースを各メンバーが自身でプロビジョニングできれば、スケーリング関係のプロビジョニングのボトルネックはほぼ解消されるだろう。

CI/CD

　優れたMLOpsの最も重要な特徴は、モデル開発のCI/CDパイプラインだ。

　コードをGitHubにプッシュすると、自動コンパイル、テスト、デプロイが実行される。このプロセスは、完全な決定論を求める全メンバーにとって同一である必要がある。機械学習のライフサイクルを標準化すれば、モデルの出力速度を何倍も向上できる。

MLOpsの将来

　機械学習ライフサイクルを標準化する働き掛けは非常に大きい。

　今後わずか数年で、手作業でモデルをトレーニングして導入するという考えは産業革命前の珍しいもののようになるだろう。何年も前にDevOpsを推し進めたソフトウェア開発業界の教訓と遺産によって、この機械学習の過渡期は誰も（機械学習モデルも）予想できないほど進みが速い。

　産業革命前の珍しい見せ物にはならないようにしたい。

ダニエル・コブランはPaperspaceの共同創設者。