データサイエンスパイプラインとモノリティックモデルblob

通常、DevOpsの重要なトピックの1つは、ソフトウェアアーティファクトの自動作成と配信をどのように処理するかです。

データサイエンスの台頭により、新しいタイプのアーティファクトが存在します。たとえば、訓練されたニューラルネットや他の機械学習モデルを表すモノリティックバイナリブロブです。このようなblobはサイズが数GBになる可能性があり、その作成は組織をCI以前の時代に戻す標準化されたAFAIKにはまだなっていません。それにもかかわらず、彼らは自分のバージョンと関連するトレーニングデータのコレクション（コーパス）を持っています。これらは急速に成長する傾向があります。

DevOpsメソッドを使用してこの新しい課題に対処するためのベストプラクティスは何ですか？

個人的には、アーティファクトリポジトリ（アーティファクトを管理するための推奨されるDevOpsツール）が、トレーニング済みのニューラルネットやその他のアーティファクトに適用できない理由はありません。

アーティファクトのサイズには、特定のアーティファクトリポジトリの上限がある場合がありますが、そのような場合、それは技術的またはポリシー上の制限であり、基本的/主要な制限ではありません。

これらのアーティファクトを生成するプロセスにDevOps手法を適用することに関しては、アーティファクトが次の条件を満たしている限り、それらのすべてを同等にうまく適用できるとは限りません。

• 変更のバージョン管理をサポートするある種の仕様から作成されます（ソフトウェアのソースコードに相当）
• 反復可能で自動化可能なプロセスを介して構築されています
• ある種の反復可能で自動化可能な検証（QAと同様）を使用して検証され、最終的にいくつかのサポートデータ（この場合はトレーニングデータ、DBスナップショットに相当）を使用して検証されます

補足：モノリシックソフトウェアコードの配信は依然として重要であり、すべてをマイクロサービスに分割できるわけではないため、DevOpsの方法論（少し注意して）で完全に保守可能です。DevOpsを適用できないようにするために、サイズは十分に重要ではありません。

データサイエンスプロジェクト用のオープンソースバージョン管理システムであるDVCを検討することをお勧めします。

それが完全に処理する基本的なものの1つは、データファイル（コードと共に）の管理です-入力、出力（モデル）、中間結果。意味的には似てgit-lfsいgit-lfsますが、100GBのようなファイルを管理でき、さらに重要なのは独自のストレージ/フォーマットに依存しないことです。完全にオープンソースであり、S3、GCPクラウドストレージ、SSH、FTPなどのデータファイルを保持するサーバーとして、あらゆるネットワークストレージと互換性があります。