「MLOpsは過学習していますその理由をここで説明します」

Explaining why MLOps is overfitting here.

VC調査によると、MLOpsカテゴリーに属する数百の企業が現在活動していることが示されています。

MLOpsシステムは、MLプラクティショナーが開発から本番までのワークライフサイクルを堅牢かつ再現性のある方法で管理するためのインフラストラクチャを提供します。MLOpsツールはE2Eのニーズをカバーすることもありますし、特定のフェーズ（例：研究/開発）やアーティファクト（例：特徴量）に焦点を当てることもあります。

データの世界には、アドホックなSQLステートメントを主に使用するアナリストから、独自のアルゴリズムを実行するPhDまで、さまざまなデータプラクティショナーが存在します。

すべてを支配するDevOpsのアプローチはありますか、それともMLは独自のアプローチと最適なベストプラクティスと一致するインフラストラクチャを必要とするユニークなプラクティスですか？

• 「リアルタイムデータのためのPythonでのChatGPT APIの使用方法」
• 「12か国がソーシャルメディア巨人に違法なデータスクレイピングへの対策を迫る」
• 「季節変動をマスターし、ビジネス結果を向上させる究極のガイド」

この質問に答えるために、DevOpsの基礎とデータプラクティショナーのニーズに合った自然な専門知識であるDataOpsについて調べてみましょう。その後、MLのニーズを調査し、DataOpsとはどのように異なるかを理解しようとします。

最後に、MLプラクティショナーがどれだけのインフラストラクチャを処理する必要があるかについて考えてみましょう。他のデータプラクティショナーとは異なるのでしょうか？ソフトウェアエンジニアと比較してどのような立場にあるのでしょうか？

この質問は、実践者への提供されるOpsの必要性を推進する観点からも関連しています。

DevOpsとは何ですか？

**「DevOpsは、ソフトウェア開発およびIT業界における方法論です。DevOpsは、ソフトウェア開発（Dev）とITオペレーション（Ops）の作業を統合し自動化する一連のプラクティスとツールとして使用され、システム開発ライフサイクルを改善し短縮する手段となります。」**

DevOpsはアジャイルソフトウェア開発と補完的であり、いくつかのDevOpsの側面はアジャイルの作業スタイルから派生しています。

さて、詳細を見ていきましょう。アジャイル手法はDevOps手法の一部であり、製品デザイナーとユーザーの間に短いフィードバックループを維持する能力に頼っています。

短いフィードバックループを維持するためには、開発から本番への効率的なソフトウェアデリバリーライフサイクルを持つ必要があります。このプロセスを維持するために必要なインフラストラクチャとツールは、DevOpsチームの責任です。

つまり、効率が重要です。

要するに、主要なコンポーネントは次のとおりです：

1. 開発環境：コラボレーションや新しいまたは変更されたコードのテストが可能な開発環境。
2. 継続的統合：コードベースに新しい/変更されたコードを継続的に追加することができ、その品質を維持する能力。
3. ステージング：本番環境に展開する前に、新しい/変更された機能を含むシステムの品質を確保するために、本番に類似した環境で品質テストを設定して実行すること。
4. 継続的デプロイメント：新しい/変更された機能を本番環境に展開する能力。
5. モニタリング：本番環境の健全性を観察し、問題が発生した場合に迅速に元に戻す能力。
6. モジュラリティ：新しいサービスなどのコンポーネントを本番環境に簡単に追加できる能力を保ちながら、本番の安定性と健全性のモニタリングを維持する能力。

組織の構造によってさまざまな役職が存在するかもしれません（DevOps/SRE/Production Engineering）、しかし彼らの責任は変わりません。

この機能は、開発から本番へのコードの移動に必要なインフラストラクチャを提供する責任を持っています。製品エンジニアリングチームは、開発環境の一部としてより専門的なツールの選択に参加する場合があります。

この目標をサポートし、これらのアジャイルプロセスを可能にするために、ソフトウェアエンジニアはGitなどのソースコントロールやJenkins、Unit、Integrationテストプラットフォームなどの自動化ツールを含むさまざまなツールについてトレーニングを受けます。

どのソフトウェアエンジニアも、アプリケーションのライフサイクル管理を理解し、それをサポートするツールとの作業を理解するための最も重要な「オンジョブトレーニング」を行っていることを知っています。そのスキルを習得すると生産性が大幅に向上し、その後は日常業務の自然な一部となります。

出典：AWS

DataOpsとは何ですか？

DataOpsは、データ集約型アプリケーションのためのDevOpsです。これらのアプリケーションは、データパイプラインに依存してアプリケーションの中心となるデータの派生物を生成します。

データ集約型アプリケーションの例：

• 内部BIシステム
• 疾病の診断と治療の改善のために患者の大規模なデータセットに依存するデジタルヘルスアプリケーション
• 自動運転機能を持つ車
• 製造ラインの最適化
• 生成AIエンジン
• その他多数…

DataOpsチームの目標は、DevOpsチームと似ていますが、テクノロジースタックにはデータの専門家が短いフィードバックループを実現するための技術が含まれています。

これらの技術には、分散ストレージ、分散コンピューティングエンジン、分散インジェストシステム、データパイプラインの管理を行うためのオーケストレーションツール、データ重視のアプリケーションの品質テストと製品モニタリングを可能にするデータ可観測性ツールなどが含まれます。

要するに、この専門知識を活用することで以下のことが可能になります：

1. 開発環境： コラボレーションと新しいまたは変更されたデータパイプラインのテスト可能性を提供する開発環境。インフラには機能コードだけでなく、パイプラインコードとデータも含まれます。
2. コードの継続的な統合： 新しい/変更されたコードを継続的にコードベースに追加できる能力
3. データの継続的な統合： 新しい/変更されたデータをデータセットに継続的に追加できる能力
4. ステージング： 新しい/変更された機能をデプロイする前にシステムの品質を確保するためのもの。コードとデータの両方のテストが含まれます。
5. 継続的デプロイメント： 新しい/変更された機能またはデータを自動的に本番環境にデプロイできる能力
6. 本番環境の健全性のモニタリングと問題からの迅速な回復能力。これにはアプリケーションとそれに組み込まれたデータの両方が含まれます。
7. 本番環境の安定性と健全性の維持しながら、新しいサービス/データアーティファクトなどのコンポーネントを簡単に本番環境に追加できる能力。

MLOps vs. DataOps

DevOpsとDataOpsの文脈において、MLOpsはMLライフサイクルを対象としたDataOpsの一例です。

ここでは、この記事の主な質問に答えるよう求められています。MLOpsは本当にDataOpsとは異なるのでしょうか？もし異なる場合、具体的にどのように異なるのでしょうか？

MLベースのアプリケーションはコード、データ、環境のバージョン管理、オーケストレーション、データテクノロジーの提供を必要とするため、これらの領域でのニーズは他のデータの専門家と類似しており、ここで定義されるDataOpsの範疇に収まります。

データ品質ツールとデータモニタリングツールについても同様です。これらのツールの一部は、テストの一部であるかもしれませんが、それはC++開発者のツールとJavaScript開発者のツールの違いとは何も変わりません。

それらをDevOpsから異なるカテゴリと定義しているわけではありませんよね？

このようなツールの必要性は疑問視されていませんし、データ品質とデータモニタリングのカテゴリは成功するでしょうが、それはDevOpsのパラダイムを変えたり、MLOpsを実際の製品カテゴリにするわけではありません。

これによって、本当の違いが存在するのは開発環境です。この違いはDevOpsで知られており、実在します。

ソフトウェアエンジニアリングの実践者は、それぞれ固有の開発環境の要件を持っています。これらの要件は、基本的なコードとデータのバージョン管理と、すべてが必要とする適切に設定されたノートブックに加えて必要となります。

例えば、MLの専門家は良い実験管理システム、ハイパーパラメータの最適化方法、トレーニングセットの作成方法を求めます。

トレーニングセット！それは確かに違いです！データサイエンティストは、モデルのトレーニングに依存するデータのタグ付けの保存と管理のインフラストラクチャが必要です。

このインフラストラクチャの一部はデータ全般的なものであり、タグ付けのメタデータを保存するために使用されるストレージやデータベースのようなものですが、一部はタグ付けプロセス自体やトレーニングセットの管理に非常に特化しています。

これが新しいOpsカテゴリを正当化するものでしょうか？私はそうは思いません。それは、グラフデータベースを必要とするアプリケーションが新しいOpsカテゴリを必要とすることを意味するのと同じです。

なぜMLOpsは過学習してしまったのか？

データサイエンティストのインフラストラクチャのニーズについての多くの議論において、彼らの基本的なソフトウェアスキルについての問題が提起されます。「データサイエンティストにGitの概念を理解することを期待するな」「データサイエンティストは適切なログを持つコードを作成することはできない、彼らはソフトウェアエンジニアではない」といった声明です。

私はその考え方に反対し、それが私たちをMLOpsの過学習に導いたと考えています。

データサイエンティストは非常に熟練した個人であり、バージョン管理の概念を迅速に理解し、CI/CDのための自動化サーバーとの作業の複雑さをマスターすることができます。上記で述べたように、初級のソフトウェアエンジニアはこれを仕事で学びますし、商業会社に価値をもたらすつもりのデータサイエンティストも同様に学ぶべきだと私は考えています。この調査結果もこの意見を支持しています。

それにもかかわらず、Opsソフトウェアエンジニアがどれだけ露出すべきかという問題はまだ解決されていません。さまざまな組織では、組織内でDevOpsがどのように実装されるかについて異なる見解があります。

すべてに共通しているのは、DevOpsチームがインフラストラクチャを提供し、ソフトウェアエンジニアがそれを理解し、使用し、要件を持ち込んで継続的に改善する責任があるという理解です。

データエンジニアに移る場合も、期待は同じです。なぜMLエンジニア/データサイエンティストに対して変わる必要があるのでしょうか？

結論

広範なデータオペレーションを行う組織（近い将来、すべての組織が該当するでしょう）は、DevOpsチームがデータの専門知識を持ち、高品質かつ一般的なデータインフラストラクチャとベストプラクティスを提供することを確認する必要があります。同時に、すべてのデータの専門家がこのインフラストラクチャを最適に管理するための教育を受けていることも確認する必要があります。企業では、それが専門の部門として設けられるかもしれません。

良い実践と内部教育により、データの専門家が必要とする柔軟性を提供する一方で、過度にフィットしたツールの必要性を除去することができます。

過度にフィットしたツールの利点は、短期的には非常にシンプルなシステムに対して、すべてのニーズを一元的に提供することです。

このE2Eツールを購入すれば、なぜDevOpsチームと協力する必要があるのでしょうか？しかし、長期的には、ニーズは簡略化されたユースケースから進化し、専門的なシステムの深さが必要とされます。たとえば、オーケストレーションでは、単純化されたオーケストレーションを提供するE2Eツールの代わりに、Airflow、Prefect、またはDagsterなどの強力なオーケストレーションシステムへの移行が行われます。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!