機械学習プロジェクトの管理にまだ Github を使用していますか?これらの新しい、よりプロフェッショナルなツールについて知っておくべきでした!

[[269295]]

ビッグデータダイジェスト制作

編纂者：銭天培、胡佳

「複雑すぎる！機械学習（ML）プロジェクトは複雑すぎる！」

このような不満を聞くと、ソフトウェア開発に詳しい友人たちはしばしば冷笑します。

機械学習とは、データとソフトウェアを扱うことに他なりません。コードを実行し、アルゴリズムを反復するだけの簡単な作業ですよね? しばらくすると、完全にトレーニングされた ML モデルが完成します。

何がそんなに複雑なの？

しかし、実際に機械学習プロジェクトを開始すると、物事はそれほど単純ではないことがわかります。

プロジェクトにしばらく取り組むと、トレーニング データが変更または削除され、トレーニング スクリプトの理解が非常に曖昧になっている可能性があります。

トレーニングしたモデルを振り返ってみると、各モデルがどのようにトレーニングされたか思い出せない場合があります。または、以前にトレーニングしたモデルを確認したいが、モデルが上書きされていることに気付く場合があります。

さらに恐ろしいのは、チームでのコラボレーションです。同僚と仕事内容を共有したいのですが、同僚はコラボレーションに参加するどころか、結果を再現することもできません。

慌てないでください。今日は、機械学習 (ML) プロジェクトを体系的に正しく管理する方法を紹介します。

他のソフトウェア開発プロジェクトと同様に、コードのバージョンとプロジェクト資産をより適切に管理する必要があります。ソフトウェア開発プロジェクトでは、プロジェクトの以前の状態を再検討する必要がある場合があります。機械学習プロジェクトで同様のレビューを実装するにはどうすればよいでしょうか? プルリクエストに相当するものは何ですか?

個人的には、機械学習ツールを使い始めたばかりです。学習中に、いくつかのチュートリアルビデオを見ました。教師が投げかけた質問の中には、私がソフトウェア エンジニアとしてのキャリアの初期に直面した課題を思い出させるものもありました。たとえば、1993 年から 1994 年にかけて、私は電子メール ユーザー エージェントを開発する SSH エンジニア チームのメンバーでした。当社にはソースコード管理システム (SCM) がありません。私は毎日、他のチーム メンバーにその日にどのような変更を加えたか確認していました。つまり、他のメンバーのソース ツリーとメイン ソース ツリーの diff を実行し、手動でコードを変更する必要がありました。その後、チーム メンバーはマスター ソース ツリーからソース ツリーを手動で更新します。

初期の SCM システム (CVS) を発見するまでは、本当に混乱していました。 SCM ツールを使用すると、プロジェクトがよりスムーズに実行されます。

機械学習とデータサイエンス プロジェクトで使用されるツールについて学んだとき、機械学習のプロセスはまさに上で説明したとおりであることがわかりました。今日でも、機械学習の研究者は、1993 年に私が行ったように、差分レビューを容易にするために、実験 (データ、コードなど) を並列ディレクトリ構造に保存することがあります。

では、理想的な機械学習プロジェクト管理とはどのようなものでしょうか?

ML プロジェクト管理の原則

まず、ML プロジェクト管理の原則について簡単に説明します。

どの ML プロジェクトでも、プログラマーはターゲット シナリオに最適なトレーニング モデルを開発するために多くの実験を実施します。実験には通常、次の内容が含まれます。

• コードと構成: 実験で使用されたソフトウェアと構成パラメータ
• データセット: 入力データのあらゆる用途 - 音声認識や画像認識プロジェクトで使用されるデータなど、ギガバイト単位のデータになることもあります。
• 出力: トレーニングされた ML モデルと実験からのその他の出力

機械学習プロジェクトの本質はソフトウェア操作です。しかし、同僚とファイルを共有したり、結果を複製してプロジェクトを評価するために時間内にレビューしたりすることが難しい場合がよくあります。より包括的な管理ツールが必要です。

ソリューションでは、次の点をカバーする必要があります (Patrick Ball 氏の「Principled Data Processing」という講演から抜粋)。

（１）透明性：MLプロジェクトのあらゆる側面を便利に検査

• 使用するコード、構成、データファイル
• エンジニアリング プロジェクトではどのようなプロセスが使用され、プロセスの順序はどのようなものですか?

（２）監査可能性：パイプラインの中間結果を確認するのに便利である

（３）再現性：開発のどの段階でもプロジェクトを正確に再実行する能力、および同僚がプロジェクトを正確に再実行する能力

• 誰でも自動的に再実行できるように処理手順を記録します
• プロジェクトの進行状況を記録します。 「状態」とは、コード、構成、データセットを意味します
• プロジェクト履歴のどの時点でも利用可能な正確なデータセットを再作成する機能

（4）スケーラビリティ：複数の同僚が同時にプロジェクトに取り組むことをサポートする能力、および複数のプロジェクトに同時に取り組む能力。

機械学習プロジェクトに通常のソフトウェア エンジニアリング ツールを使用しないのはなぜですか?

確かに、通常のソフトウェア エンジニアリング プロジェクトで使用されるツールの多くは、機械学習の研究者にとって役立つ可能性があります。

コードと実験的な構成は、Git などの通常のソース コード管理システムで簡単に管理でき、これらのファイルの更新はプル リクエストなどの手法を使用して管理できます。 CI/CD (Jenkins など) システムを使用して、プロジェクト操作を自動化することもできます。

ただし、ML プロジェクトはさまざまな点で異なるため、一般的なソフトウェア開発ツールではすべてのニーズを満たすことはできません。重要な違いをいくつか挙げます。

• メトリクス駆動開発と機能駆動開発: 従来のソフトウェア エンジニアリングでは、製品をリリースするかどうかの決定は、チームがいくつかの機能を完了したかどうかに基づいて行われます。対照的に、機械学習の研究者は、生成された機械学習モデルの予測値という、まったく異なる種類の測定を研究しています。研究者たちは数十（またはそれ以上）のモデルを繰り返し生成し、それぞれの精度を測定します。最も正確なモデルを見つけることが目標であるため、プロジェクトは各実験で達成された指標によって導かれます。
• 機械学習モデルのトレーニングには多くのリソースが必要です。通常のソフトウェア プロジェクトではファイルをまとめて整理し、ソフトウェア製品をコンパイルしますが、機械学習プロジェクトでは AI アルゴリズムを記述する「モデル」をトレーニングします。ほとんどの場合、ソフトウェア製品のコンパイルには数分しかかからず、非常に高速であるため、多くのチームが継続的インテグレーション戦略を採用しています。機械学習モデルのトレーニングには長い時間がかかります。必要がない限り、継続的インテグレーションは避けてください。
• 膨大なデータセットとトレーニング済みモデル: 機械学習の開発フェーズでは、ほぼ常に膨大なデータセットが必要になります。さらに、トレーニング済みモデルも巨大になる可能性があります。通常のソースコード管理ツール (Git など) は大きなファイルをうまく処理できず、Git-LFS などのアドオンは ML プロジェクトには適していません。
• ワークフロー (パイプライン): 機械学習プロジェクトは、データのダウンロード、データの準備、データのトレーニング/検証セットへの分割、モデルのトレーニング、モデルの検証などの一連のステップです。多くの人は、パイプラインという言葉を全体的なプロセスを説明するために使用します。これは、すべてを 1 つのプログラムに詰め込むのではなく、各ステップごとに個別のコマンドを使用して機械学習プロジェクトを構成することを意味します。
• 専用ハードウェア: ソフトウェア開発者は、あらゆる種類のサーバー機器上でソフトウェア インフラストラクチャをホストできます。クラウド展開を希望する場合は、お気に入りのクラウド コンピューティング プロバイダーから VPS をレンタルできます。しかし、機械学習の研究者には膨大な計算能力が必要です。高性能 GPU は、ビデオ編集を高速化するだけでなく、ML アルゴリズムを「高速化」し、ML モデルのトレーニングに必要な時間を大幅に短縮します。

これで、機械学習プロジェクトを開発するための原則のリストができました。また、ML プロジェクトが通常のソフトウェア開発プロジェクトとどのように異なるかを理解できました。

次に、これらの原則を実装するのに役立つオープン ソース ソフトウェアをいくつか見てみましょう。

特に、MLFlow と DVC という 2 つのツールについて説明します。もちろん、同様の結果を達成できるソフトウェアは他にもたくさんあります。

機械学習プロジェクトにおけるデータとモデルの保存

私たちの議論は次のように要約できます。

• 機械学習モデルのトレーニングの各ラウンドで使用されるデータファイルを追跡します。
• トレーニングされたモデルと評価指標の追跡
• あらゆる形式のファイル共有システムを介して同僚とデータファイルを共有する簡単な方法

一般的に、結果を透過的に監査または再現するには、データ追跡システムが必要です。また、プロジェクトチームを複数の同僚に拡大するためのデータ共有システムも必要でした。

前述したように、機械学習プロジェクトで使用されるデータ ファイルを保存するために Git やその他の SCM (ソース コード管理システム) を使用することは現実的ではありません。

一部のライブラリは、リモート ストレージ上のファイル処理を簡素化し、リモート ストレージへのファイルのアップロードや取得を管理するための API を提供します。これはリモート データセットへの共有アクセスには便利ですが、私たちが直面している問題の解決には役立ちません。

まず、ファイル名がソフトウェアに埋め込まれているため、埋め込み構成の一種となります。ソース コードに構成設定を埋め込むプログラムは、他のコンテキストで再利用するのが難しくなります。 2 番目に、スクリプトのバージョンと、使用するデータ ファイルが関連付けられません。

次に、MLFlow のサンプル コードを見てみましょう。

 mlflow.pytorch.load_model("runs:/ < mlflow_run_id > /run-relative/path/to/model")

これによって、S3 などのクラウド ストレージ システムを含むさまざまなファイル アクセス「スキーマ」がサポートされます。ここでの例では、「実行」領域からファイル（この場合はトレーニング済みのモデル）をロードします。 MLFlow は、コードのセクションが実行されるたびに「実行」を生成します。 「実行」データを保存する場所を構成する必要があり、当然のことながら、データ ストレージ領域へのインデックス付けに使用される実行ごとに「実行 ID」が生成されます。

この方法は、対応する SCM ソース コード管理リポジトリ内のコードおよび構成ファイルのコミット バージョンにデータを効果的に関連付けます。また、MLFLow API には複数の実装言語があり、Python に限定されません。

DVC は異なるアプローチを採用しています。上記の ML スクリプトにファイル API を統合する場合と比較して、スクリプトでは通常のファイル システム API を使用するだけで、入力ファイルと出力ファイルを実装できます。例えば：

モデル= torch.load ('path/to/model.pkl')

上記のコードでは、パス名がこのコマンドを通じて渡されます。 DVC はトレーニング コードまたは検証モデル コードに必要な値を外部に渡すことができるため、コードを特別に変更する必要はありません。

DVC はこれを透過的にします。データ ファイルのバージョンはコードの Git バージョンと一致します。

次のコマンドを使用して、DVC バージョン管理にファイルまたはフォルダーを追加できます。

 $ dvc パスを/to/model.pkl に追加します

データは作業ディレクトリに保存されます。さまざまな実行の結果を参照することも簡単で、Git 履歴を参照するだけです。特定の結果を表示するのは git checkout と同じくらい簡単で、DVC が呼び出され、正しいデータ ファイルがワークスペースに接続されていることが保証されます。

各ファイルとディレクトリを追跡するための「DVC ファイル」が作成され、ワー​​クスペースに追加されます。これには 2 つの目的があります。1 つはデータとモデル ファイルを追跡すること、もう 1 つはワークフロー内のコマンドを記録することです。この部分については次のセクションで説明します。

これらの DVC ファイルには、ファイルとディレクトリの MD5 チェックサムが記録されます。これらは git ワークスペースにコミットされるため、DVC ファイルには各 git コミット内の各ファイルのチェックサムの合計が記録されます。 DVC は「DVC キャッシュ ディレクトリ」を使用して、各ファイルの複数のインスタンスを保存します。ファイル インスタンスはチェックサムによってインデックス付けされ、reflink または symlink を使用してワークスペースにリンクされます。 DVC が git checkout コマンドに応答すると、DVC ファイル内のチェックサムに基づいてリンクされたファイルをすばやく並べ替えることができます。

DVC は、ファイルとモデルを共有するためのリモート キャッシュ ディレクトリをサポートします。

 $ dvc リモート リモート1 を追加 ssh://[email protected]/path/to/dir$ dvc プッシュ$ dvc プル

DVC リモートは、データ共有を可能にするストレージ プールです。 S3、HTTP、FTP など、多くのストレージ サービスをサポートしています。 DVC リモートの作成は非常に簡単です。 dvc push コマンドと dvc pull コマンドは、git push コマンドと git pull コマンドとよく似ています。 DVC プッシュはリモート DVC キャッシュにデータを送信するのに使用され、DVC プルはリモート DVC キャッシュからデータをプルするために使用されます。

機械学習プロジェクトにおけるワークフローの説明

次に、機械学習プロジェクトのワークフローをより適切に記述する方法について説明します。すべてを 1 つのプログラムにまとめるべきでしょうか? それとも複数のツールを使うべきでしょうか?

柔軟性を最大限に高めるために、パイプラインまたは有向非巡回グラフ (DAG) を通じてワークフローを実装し、コマンドライン パラメータを構成オプションとして使用することができます。これは、小さくてすっきりしたツール (小さいながらも連携して動作する) という Unix 哲学に少し似ています。その動作はコマンドラインオプションまたは環境変数によって指定でき、必要に応じて任意の組み合わせで使用できます。

対照的に、多くの ML フレームワークは異なるアプローチを採用しています。特定のプロジェクトのワークフローを実行するために個別のプログラムを作成します。プログラムの最初のステップは、データをトレーニング セットと検証セットに分割し、モデルをトレーニングしてモデルを検証することです。この個別のプログラムセット全体では、コードを再利用する機会が限られています。

MLプロジェクトのパイプラインを構築すると、次のようなメリットが得られます。

• 複雑さを管理する: これらの手順を個別のコマンドとして実装すると、透明性が向上し、集中しやすくなります。
• 実行の最適化: 変更を行わず、値を返す必要のないステップはスキップできます。
• 再利用性: 同じツールを複数のプロジェクトで再利用できます。
• スケーラビリティ: さまざまなツールをさまざまなチーム メンバーが個別に開発できます。

MLFlow では、「ドライバー プログラム」を作成する必要があります。このプログラムには、機械学習モデルの処理や生成など、必要な実行ロジックが含まれています。舞台裏では、MLFlow API が MLFlow サーバーにリクエストを送信し、指定されたコマンドが生成されます。

次の MLFlow の複数ステップのワークフローの例は、これを明確に示しています。

 ...load_raw_data_run = _get_or_run ("load_raw_data", {}, git_commit) ratings_csv_uri = os .path.join(load_raw_data_run.info.artifact_uri, "ratings-csv-dir") etl_data_run = _get_or_run ("etl_data", {"ratings_csv": ratings_csv_uri, "max_row_limit": max_row_limit}, git_commit)… als_run = _get_or_run ("als", {"ratings_data": ratings_parquet_uri, "max_iter": str(als_max_iter)}, git_commit)…_get_or_run("train_keras", keras_params, git_commit, use_cache = False )…

_get_or_run 関数は mlflow.run のラッパーです。各呼び出し関数の最初のパラメーターは、MLproject ファイルで定義されたエントリポイントです。各エントリポイントには、環境変数、実行するコマンド、およびそのコマンドに渡す引数が含まれます。例えば：

 etl_data: パラメータ: ratings_csv: パス max_row_limit: {タイプ: int、デフォルト: 100000} コマンド: "python etl_data.py --ratings-csv {ratings_csv} --max-row-limit {max_row_limit}"

一見するととても良い感じです。しかし、ここで考えてみる価値のある質問がいくつかあります。

• ワークフローが直線的なプロセスよりも複雑な場合はどうすればよいでしょうか。mlflow.run に渡される同期パラメーターを false に設定し、SubmittedRun オブジェクトがタスクを完了としてマークするまで待機することができます。つまり、MLFlow API 上にプロセス パイプラインを構築できます。
• なぜサーバーが必要なのでしょうか? コマンドラインからコマンドを実行しないのはなぜでしょうか? サーバーとその構成を追加すると、MLFlow プロジェクトのセットアップがより複雑になります。
• こうした不要なタスクの実行を回避するにはどうすればよいでしょうか? 多くの ML プロジェクトでは、モデルのトレーニングに数日かかることがよくあります。リソースは、データの変更、パラメータやアルゴリズムの変更など、必要な場合にのみ使用する必要があります。

DVC は通常のコマンドライン ツールを使用でき、サーバーのセットアップやドライバーの作成は必要ありません。 DVC は、有向非巡回グラフ (DAG) としての DVC ファイルのセットを通じて、前述のワークフロー定義の使用をサポートします。

先ほど、DVC ファイルはワークスペースに追加されたファイルに関連付けられていると述べました。 DVC ファイルには、実行されるコマンドも記述されています。

 $ dvc run -d matrix-train.p -d train_model.py \ -o model.p \ python train_model.py matrix-train.p 20180226 model.p$ dvc run -d parsingxml.R -d Posts.xml \ -o Posts.csv \ Rscript parsingxml.R Posts.xml Posts.csv

dvc run コマンドは、実行されるコマンドを含む DVC ファイルを定義します。 -d パラメータはファイルへの依存関係を記録し、DVC はチェックサム コードに基づいてファイルの変更を検出します。 -o パラメータはコマンド出力設定を示します。あるコマンドの出力は、別のコマンドの入力としても使用できます。依存関係と出力を調べることで、DVC はコマンドを実行する順序を判断できます。

AI 出力 (トレーニング モデルを含む) は、ワークスペース内の他のデータ ファイルと同様に、DVC キャッシュに自動的に記録されます。

DVC はチェックサムを計算するため、変更されたファイルを検出できます。ユーザーが DVC にパイプラインの再実行を要求すると、変更された部分のみが実行されます。入力ファイルが変更されない場合、DVC はモデルトレーニングタスクに必要な時間を大幅に節約できます。

すべての実行には通常のコマンドラインが使用され、サーバーのセットアップは必要ありません。クラウド コンピューティング環境、または GPU が接続されたサーバー上で実行する場合は、コードとデータをサーバーにデプロイし、コマンド ラインから DVC コマンドを実行するだけです。

要約する

私たちは、機械学習の実践を改善するための原則を開発するという探求において長い道のりを歩んできました。ご存知のとおり、機械学習の分野では、機械学習チームがより効果的かつ確実に作業できるように、より優れた管理ツールが必要です。

再現可能な結果とは、他の人があなたの行った作業を評価したり、さらなる開発に協力したりできることを意味します。再現性には、システムのあらゆる部分をチェックし、ソフトウェアと入力データを正確に再実行する機能など、多くの前提条件があります。

機械学習プロジェクトでは、Jupyter Notebook など、非常に美しいユーザー インターフェイスを備えた GUI ツールもあります。これらのツールは機械学習の作業に役立ちます。ただし、GUI ツールはこの記事で説明した原則にはあまり適していません。コマンドライン ツールは、バックグラウンドで実行されるタスクの処理に最適で、上記で概説したすべての原則を簡単に満たすことができます。一般的な GUI はこれらの原則を妨げます。

この記事で説明したように、従来のソフトウェア エンジニアリングから多くのツールとプラクティスを借用することができます。ただし、機械学習プロジェクトの特殊性により、その目標に適したツールを使用する必要があります。これらの貴重なツールには、MLFlow、DVC、ModelDb、Git-LFS などが含まれます。

関連レポート: https://dev.to/robogeek/principled-machine-learning-4eho

[この記事は51CTOコラムBig Data Digest、WeChatパブリックアカウント「Big Data Digest（id: BigDataDigest）」からのオリジナル記事です]

この著者の他の記事を読むにはここをクリックしてください