産業用機械学習: 10 の設計原則

産業用機械学習: 10 の設計原則

現在、新しいサービス、アプリケーション、その他の重要なプログラムが毎日作成されており、SpaceX ロケットを制御するためのソフトウェアから、スマートフォンを介して隣の部屋にあるやかんと対話するものまで、信じられないほどのものを作成できるようになります。

そして、情熱的なスタートアップ企業であれ、普通のフルスタックやデータサイエンティストであれ、すべての初心者プログラマーは、遅かれ早かれ、プログラミングとソフトウェアの作成には、作業を大幅に簡素化する特定のルールがあることに気づくことがあります。

この記事では、10 要素アプリ手法に基づいて、産業用機械学習をアプリケーション/サービスに簡単に統合できるようにプログラムする方法に関する 12 の原則について簡単に説明します。 Heroku チームによって提案されました。 私の取り組みは、多くの開発者やデータ サイエンス関係者を助けることができるこの手法の認知度を高めることです。

この記事は、産業用機械学習に関する一連の記事のプロローグです。 その中で、実際にモデルを作成して実稼働環境に導入する方法、その API を作成する方法、およびシステムに ML を組み込んださまざまな分野や企業の例についてさらにお話します。

原則 1: XNUMX つのコードベース

最初の段階では、それを理解するのが怠けて (または何らかの理由で)、Git のことを忘れてしまうプログラマーもいます。 彼らはその言葉を完全に忘れています。つまり、ドライブ内でファイルを互いに投げ合うか、テキストを投げ合うだけで、ハトによって送信されるか、またはワークフローを深く考えずにそれぞれを独自のブランチにコミットし、次にそのブランチにコミットします。マスター。

この原則は次のように述べています。 XNUMX つのコードベースと多数のデプロイメントがあります。

Git は運用環境と研究開発 (R&D) の両方で使用できますが、Git はあまり使用されません。

たとえば、研究開発フェーズでは、さまざまなデータ処理方法とモデルを使用してコミットを残すことができ、最適なものを選択して、さらに作業を簡単に続けることができます。

次に、運用環境では、これはかけがえのないものです。コードがどのように変化するかを常に観察し、どのモデルが最良の結果をもたらしたのか、どのコードが最終的に機能したのか、動作を停止したり誤った結果が生成され始めた原因は何なのかを把握する必要があります。 。 それがコミットの目的です。

また、プロジェクトのパッケージを作成して、たとえば Gemfury に配置し、そこから関数を他のプロジェクトにインポートするだけで、関数を 1000 回書き直さなくても済むようにすることもできます。これについては後ほど説明します。

原則 2: 依存関係を明確に宣言して分離する

各プロジェクトには異なるライブラリがあり、それらをどこかに適用するために外部からインポートします。 Python ライブラリであっても、さまざまな目的のための他の言語のライブラリであっても、システム ツールであっても、あなたのタスクは次のとおりです。

• 依存関係を明確に宣言します。つまり、プロジェクトで使用され、インストールする必要があるすべてのライブラリ、ツール、およびそれらのバージョンを含むファイルです (たとえば、Python では、Pipfile またはrequirements.txtを使用してこれを行うことができます)。理解するためのリンク: realpython.com/pipenv-guide)
• 開発中にプログラムに特化した依存関係を分離します。 Tensorflow など、バージョンを頻繁に変更したり再インストールしたりしたくないですか?

こうすることで、将来チームに参加する開発者は、プロジェクトで使用されるライブラリとそのバージョンにすぐに慣れることができ、特定のプロジェクトにインストールされているバージョンとライブラリ自体を管理する機会も得られます。これは、ライブラリまたはそのバージョンの非互換性を回避するのに役立ちます。

また、アプリケーションは、特定の OS にインストールされている可能性のあるシステム ツールに依存しないでください。 これらのツールは依存関係マニフェストでも宣言する必要があります。 これは、ツールのバージョン (およびその可用性) が特定の OS のシステム ツールと一致しない状況を避けるために必要です。

したがって、curl がほとんどすべてのコンピュータで使用できる場合でも、別のプラットフォームに移行するときに、curl が存在しなかったり、バージョンが当初必要だったものではなくなる可能性があるため、依存関係でそれを宣言する必要があります。

たとえば、requirements.txt は次のようになります。

# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0

# testing requirements
pytest>=5.3.2,<6.0.0

# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0

# fetching datasets
kaggle>=1.5.6,<1.6.0

原則 3: 構成

さまざまな開発者が、AWS のパスワードやその他のキーを使用してコードを GitHub のパブリック リポジトリに誤ってアップロードし、翌日目が覚めると 6000 ドル、さらには 50000 ドルの借金を抱えていたという話を聞いたことがある人は多いでしょう。

もちろん、これらのケースは極端ですが、非常に重要です。 資格情報や構成に必要なその他のデータをコード内に保存する場合、間違いを犯すことになります。その理由を説明する必要はないと思います。

これに代わる方法は、構成を環境変数に保存することです。 環境変数について詳しく読むことができます ここで.

通常、環境変数に保存されるデータの例は次のとおりです。

• ドメイン名
• API URL/URI
• 公開鍵と秘密鍵
• 連絡先（メール、電話など）

こうすることで、構成変数が変更された場合にコードを常に変更する必要がなくなります。 これにより、時間、労力、お金を節約できます。

たとえば、Kaggle API を使用してテストを実行する場合 (たとえば、ソフトウェアをダウンロードし、モデルを実行して、実行時にモデルが適切に機能するかどうかをテストする)、Kaggle の秘密鍵 (KAGGLE_USERNAME や KAGGLE_KEY など) は次のようになります。環境変数に保存されます。

原則 4: サードパーティのサービス

ここでの考え方は、コードの点でローカル リソースとサードパーティ リソースの間に違いがないようにプログラムを作成することです。 たとえば、ローカルの MySQL とサードパーティの MySQL の両方に接続できます。 Google Maps や Twitter API などのさまざまな API についても同様です。

サードパーティのサービスを無効にしたり、別のサービスに接続するには、上の段落で説明したように、環境変数の構成内のキーを変更するだけです。

したがって、たとえば、コード内でデータセットを含むファイルへのパスを毎回指定する代わりに、pathlib ライブラリを使用して、config.py でデータセットへのパスを宣言する方が良いでしょう。そうすれば、どのサービスを使用するかに関係なく、 CircleCI など)、プログラムは、新しいサービスの新しいファイル システムの構造を考慮して、データセットへのパスを見つけることができました。

原則 5. ビルド、リリース、ランタイム

データ サイエンスの多くの人々は、ソフトウェア作成スキルを向上させることが役立つと考えています。 プログラムができるだけクラッシュせず、できるだけ長く障害なく動作するようにしたい場合は、新しいバージョンをリリースするプロセスを 3 つの段階に分割する必要があります。

1. ステージ 集会。 個々のリソースを含むベア コードを、必要なすべてのコードとデータを含むいわゆるパッケージに変換します。 このパッケージはアセンブリと呼ばれます。
2. ステージ 解放する — ここでは構成をアセンブリに接続します。これがなければプログラムをリリースできません。 これで、完全にリリース準備完了のリリースとなりました。
3. 次はステージです 履行。 ここでは、リリースから必要なプロセスを実行してアプリケーションをリリースします。

モデルまたはパイプライン全体の新しいバージョンをリリースするためのこのようなシステムにより、管理者と開発者の間で役割を分離し、バージョンを追跡し、プログラムの不要な停止を防ぐことができます。

リリース タスク用に、自分で実行するプロセスを .yml ファイルに記述できるさまざまなサービスが作成されています (たとえば、CircleCI では、これはプロセス自体をサポートする config.yml です)。 Wheely はプロジェクトのパッケージを作成するのが得意です。

機械学習モデルのさまざまなバージョンを含むパッケージを作成し、それらをパッケージ化して、必要なパッケージとそのバージョンを参照して、そこから作成した関数を使用できます。 これはモデルの API を作成するのに役立ち、パッケージを Gemfury などでホストできるようになります。

原則 6. モデルを XNUMX つ以上のプロセスとして実行する

さらに、プロセスはデータを共有すべきではありません。 つまり、プロセスは個別に存在する必要があり、あらゆる種類のデータは必要に応じて、たとえば MySQL などのサードパーティ サービス上に個別に存在する必要があります。

つまり、プロセス ファイル システム内にデータを保存することは明らかに価値がありません。そうしないと、次回のリリース/構成の変更、またはプログラムが実行されるシステムの転送中に、このデータが消去される可能性があります。

ただし例外があります。機械学習プロジェクトの場合、追加のライブラリやバージョンに変更が加えられていない場合、新しいバージョンを起動するたびにライブラリを再インストールする必要がないように、ライブラリのキャッシュを保存できます。 こうすることで、モデルを業界に投入するまでにかかる時間を短縮できます。

モデルを複数のプロセスとして実行するには、必要なプロセスとその順序を指定する .yml ファイルを作成します。

原則 7: リサイクル可能性

モデル アプリケーションで実行されるプロセスは、簡単に開始および停止できる必要があります。 したがって、これにより、コードの変更や構成の変更を迅速に展開し、迅速かつ柔軟に拡張し、作業バージョンの故障の可能性を防ぐことができます。

つまり、モデルを使用するプロセスは次のことを行う必要があります。

• 起動時間を最小限に抑えます。 理想的には、起動時間 (起動コマンドが発行されてからプロセスが動作を開始するまで) は数秒以内である必要があります。 上で説明したライブラリ キャッシュは、起動時間を短縮するための XNUMX つの手法です。
• 正しく終了します。 つまり、サービス ポートでのリッスンは実際には一時停止され、このポートに送信された新しい要求は処理されません。 ここでは、DevOps エンジニアと良好なコミュニケーションを確立するか、それがどのように機能するかを自分自身で理解する必要があります (もちろん後者が望ましいですが、どのプロジェクトでもコミュニケーションは常に維持される必要があります)。

原則 8: 継続的な導入/統合

多くの企業は、アプリケーション開発チームと展開チームを分離しています (アプリケーションをエンド ユーザーが利用できるようにします)。 これにより、ソフトウェア開発とその改善の進行が大幅に遅くなる可能性があります。 また、大まかに言えば、開発と統合が組み合わされている DevOps 文化も台無しになります。

したがって、この原則では、開発環境は実稼働環境にできる限り近づけるべきであると述べています。

これにより、次のことが可能になります。

1. リリース時間を数十倍短縮
2. コードの非互換性によるエラーの数を減らします。
3. また、開発者とアプリケーションをデプロイする人々が XNUMX つのチームになるため、スタッフの作業負荷も軽減されます。

これを操作できるツールは、CircleCI、Travis CI、GitLab CI などです。

モデルにすばやく追加し、更新し、すぐに起動することができます。また、障害が発生した場合でも、エンド ユーザーが気づかないようにすぐに動作バージョンに戻すことも簡単です。 良好なテストがある場合、これは特に簡単かつ迅速に行うことができます。

差異を最小限に抑える!!!

原則 9. ログ

ログ (または「ログ」) は、アプリケーション (イベント ストリーム) 内で発生するイベントであり、通常はテキスト形式で記録されます。 簡単な例: 「2020-02-02 - システム レベル - プロセス名」。 これらは、開発者がプロ​​グラムの実行中に何が起こっているかを文字通り確認できるように設計されています。 プロセスの進捗状況を見て、開発者自身の意図どおりになっているかどうかを理解します。

この原則は、ログをファイル システム内に保存すべきではなく、単に画面に「出力」する必要があることを示しています。たとえば、これをシステムの標準出力で実行します。 このようにして、開発中にターミナル内のフローを監視することが可能になります。

これは、ログを保存する必要がまったくないことを意味しますか? もちろん違います。 アプリケーションはこれを行うべきではなく、サードパーティのサービスに任せてください。 アプリケーションは、リアルタイム表示のためにログを特定のファイルまたは端末に転送するか、汎用データ ストレージ システム (Hadoop など) に転送することしかできません。 アプリケーション自体は、ログを保存したり、ログとやり取りしたりしてはなりません。

原則 10. テストしてください!

産業用機械学習の場合、モデルが正しく機能し、意図したものが生成されることを理解する必要があるため、このフェーズは非常に重要です。

テストは pytest を使用して作成でき、回帰/分類タスクがある場合は小さなデータセットを使用してテストできます。

深層学習モデルが常に異なる結果を生成しないように、深層学習モデルに同じシードを設定することを忘れないでください。

これは 10 の原則の簡単な説明であり、もちろん、それらがどのように機能するかを実際に試してみることなしに使用することは困難です。そのため、この記事は、作成方法を説明する一連の興味深い記事の序章にすぎません。産業用機械学習モデル、それらをシステムに統合する方法、およびこれらの原則がどのように私たち全員の生活を楽にするかについて説明します。

また、希望に応じて誰でもコメントを残すことができるクールな原則を使用するよう努めます。

出所： habr.com