産業機械学習：10の設計原則
今日では、SpaceXロケットを制御するためのソフトウェアから、スマートフォンを介して隣の部屋のやかんと対話するまで、信じられないほどのものを作成できる新しいサービス、アプリケーション、およびその他の重要なプログラムが毎日作成されています。
そして、時には、情熱的なスタートアップであろうと、通常のフルスタックまたはデータサイエンティストであろうと、すべての初心者プログラマーは、遅かれ早かれ、人生を大幅に簡素化するソフトウェアのプログラミングと作成に特定のルールがあることに気付きます。
この記事では、Herokuチームによって提案された12要素のAppメソッドに基づいて、アプリケーション/サービスに簡単に統合できるように産業用機械学習をプログラムする方法の10の原則について簡単に説明します。..。私のイニシアチブは、この手法の認知度を高めることです。これは、多くの開発者やデータサイエンスの人々を支援することができます。
この記事は、産業機械学習に関する一連の記事のプロローグです。その中で、実際にモデルを作成して本番環境で実行する方法、そのAPIを作成する方法、およびシステムにMLが組み込まれているさまざまな分野や企業の例について引き続き説明します。
原則1.1つのコードベース
最初の段階の一部のプログラマーは、それを理解するのが面倒であるため（または何らかの理由で）、Gitを忘れています。彼らは言葉から完全に忘れます。つまり、ドライブ内でファイルを互いにスローするか、テキストをスローするか、鳩を送信するか、ワークフローについて考えずに、それぞれが独自のブランチにコミットしてから、マスターにコミットします。
この原則は次のように述べています。1つのコードベースと多くの展開があります。
Gitは、生産と研究開発（R＆D）の両方で使用でき、使用頻度は低くなります。
たとえば、R＆Dフェーズでは、さまざまなデータ処理方法とモデルを使用してコミットを残し、最適なものを選択して、さらに簡単に作業を続けることができます。
第二に、本番環境では、これはかけがえのないものです。コードがどのように変化するかを常に確認し、どのモデルが最良の結果をもたらしたか、どのコードが最後に機能し、何が機能しなくなったか、発行を開始したかを知る必要があります。間違った結果。それがコミットの目的です！
また、プロジェクトのパッケージを作成するには、たとえばGemfuryに配置し、他のプロジェクト用に関数をインポートするだけで、1000回書き換えないようにすることができますが、それについては後で詳しく説明します。
原則2.依存関係を明確に宣言して分離する
各プロジェクトには、どこかに適用するために外部からインポートするさまざまなライブラリがあります。それがPythonライブラリであるか、さまざまな目的のための他の言語のライブラリであるか、またはシステムツールであるかどうか-あなたのタスクは次のとおりです：
- dependencies, , , , , (, Python Pipfile requirements.txt. , : realpython.com/pipenv-guide)
- dependencies . , , 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にアップロードし、翌日6,000ドル、さらには50,000ドルの負債で目を覚ますという話を聞いたことがあるでしょう。
もちろん、これらのケースは極端ですが、非常に明白です。構成に必要な資格情報やその他のデータをコード内に保存すると、間違いを犯していることになります。その理由を説明する価値はないと思います。
これに代わる方法は、構成を環境変数に格納することです。環境変数について詳しくは、こちらをご覧ください。
通常、環境変数に格納されるデータの例：
- ドメイン名
- API URL / URI
- 公開鍵と秘密鍵
- 連絡先（メール、電話など）
このように、構成変数が変更された場合でも、コードを絶えず変更する必要はありません。これにより、時間、労力、およびお金を節約できます。
たとえば、Kaggle APIを使用してテストを実行する場合（たとえば、モデルをダウンロードして実行し、起動時にモデルが正常に機能することをテストする場合）、KAGGLE_USERNAMEやKAGGLE_KEYなどのKaggleの秘密鍵を環境変数に格納する必要があります。
原則4：サードパーティのサービス
ここでの考え方は、コードに関してローカルリソースとサードパーティリソースの間に区別がないようにプログラムを設計することです。たとえば、ローカルのMySQLとサードパーティの両方に接続できます。 GoogleマップやTwitterAPIなどのさまざまなAPIについても同じことが言えます。
サードパーティのサービスを無効にしたり、別のサービスに接続したりするには、上記の段落で説明した環境変数の構成のキーを変更するだけです。
したがって、たとえば、コード内にデータセットを含むファイルへのパスを毎回指定するのではなく、pathlibライブラリを使用して、config.pyでデータセットへのパスを宣言することをお勧めします。これにより、使用するサービス（CircleCIなど）に関係なく、プログラムが新しいサービスの新しいファイルシステムの構造を考慮して、データセットへのパスを見つけることができました。
原則5.ビルド、リリース、ランタイム
データサイエンスの多くの人々は、ソフトウェアの作成スキルを学ぶことが役立つと感じています。プログラムができるだけ頻繁にクラッシュせず、できるだけ長くスムーズに実行されるようにするには、新しいバージョンのリリースプロセスを次の3つの段階に分割する必要があります。
- . , . .
- — config, . .
- . .
モデルの新しいバージョンまたはパイプライン全体をリリースするためのこのようなシステムは、管理者と開発者の間で役割を分割し、バージョンを追跡し、プログラムの不要な停止を防ぎます。
リリースタスクでは、.ymlファイルで自分自身を実行するプロセスを記述できるさまざまなサービスが作成されています（たとえば、CircleCIでは、これはプロセス自体をサポートするconfig.ymlです）。 Wheelyは、プロジェクトのパッケージを作成するのに優れています。
マシン学習モデルのさまざまなバージョンでパッケージを作成し、それらをパッケージ化して、そこから作成した関数を使用するために必要なパッケージとそのバージョンを参照することができます。これは、モデルのAPIを作成するのに役立ち、たとえば、パッケージをGemfuryに配置できます。
原則6.モデルを1つまたは複数のプロセスとして実行します。
さらに、プロセスにデータを共有してはなりません。つまり、プロセスは個別に存在する必要があり、すべての種類のデータは、必要に応じて、たとえばMySQLなどのサードパーティサービスに個別に存在する必要があります。
つまり、プロセスのファイルシステム内にデータを保存する価値はまったくありません。そうしないと、次のリリース/構成の変更またはプログラムが実行されているシステムの転送時にこのデータがクリアされる可能性があります。
ただし、例外があります。機械学習プロジェクトの場合、追加のライブラリやバージョンの変更が行われていない場合に、新しいバージョンを起動するたびに再インストールしないように、ライブラリキャッシュを保存できます。したがって、業界でのモデルの起動時間を短縮できます。
モデルを複数のプロセスとして実行するには、必要なプロセスとそのシーケンスを指定するだけの.ymlファイルを作成できます。
原則7.リサイクル可能性
アプリケーションのモデルで実行されるプロセスは、開始と停止が簡単である必要があります。したがって、コードの変更や構成の変更を迅速に展開し、迅速かつ柔軟にスケーリングして、動作中のバージョンの故障を防ぐことができます。
つまり、モデルを使用したプロセスは次のようになります。
- . ( , , ) . , — .
- . , , , . DevOps , , (, , , , !)
原則8：継続的な展開/統合
多くの企業は、アプリケーション開発チームと展開チームを分離して使用しています（エンドユーザーがアプリケーションを利用できるようにする）。これにより、ソフトウェア開発が大幅に遅くなり、改善に向けて進む可能性があります。また、開発と統合が大まかに組み合わされているDevOps文化を台無しにします。
したがって、この原則は、開発環境を本番環境にできるだけ近づける必要があることを示しています。
これにより、次のことが可能になります。
- リリース時間を10分の1に短縮
- コードの非互換性によるエラーの数を減らします。
- また、アプリケーションを展開する開発者と担当者が1つのチームになっているため、スタッフの負担も軽減されます。
これを使用できるツールは、CircleCI、Travis CI、GitLabCIなどです。
モデルにすばやく追加して更新し、すぐに起動できますが、障害が発生した場合は、エンドユーザーが気付かないうちに、作業バージョンにすばやく戻ることができます。良いテストがあれば、これは特に迅速かつ簡単に行うことができます。
違いを最小限に抑える!!!
原則9.あなたのログ
ログ（または「ログ」）は、アプリケーション（イベントストリーム）内で発生する、通常はテキスト形式で記録されたイベントです。簡単な例：「2020-02-02-システムレベル-プロセス名」。これらは、開発者がプログラムの実行中に何が起こるかを文字通り確認できるように設計されています。彼はプロセスの進行状況を見て、自分が開発者自身の意図したとおりであるかどうかを理解しています。
この原則は、ログをファイルシステム内に保存するべきではないことを示しています。たとえば、システムstdoutの標準出力でログを「表示」するだけです。このようにして、開発中にターミナルでフローを監視できます。
これは、ログをまったく保存する必要がないことを意味しますか？もちろん違います。アプリケーションがこれを行うべきではないというだけです-サードパーティのサービスに任せてください。アプリケーションは、ライブ表示のためにログを特定のファイルまたは端末にリダイレクトするか、汎用ストレージシステム（Hadoopなど）にリダイレクトすることしかできません。アプリケーション自体は、ログを保存したり操作したりしないでください。
原則10.テスト！
産業用機械の学習では、モデルが正しく機能し、必要なものが得られることを理解する必要があるため、このフェーズは非常に重要です。
テストはpytestで作成でき、回帰/分類タスクがある場合は小さなデータセットでテストできます。
深層学習モデルに同じシードを設定して、常に異なる結果が生成されないようにすることを忘れないでください。
これは10の原則の簡単な説明であり、もちろん、それらがどのように機能するかを試してみずに使用することは難しいため、この記事は、産業機械学習モデルの作成方法を明らかにする一連の興味深い記事のプロローグにすぎません。それらをシステムに統合する方法、そしてこれらの原則が私たち全員の生活をどのように楽にすることができるか。
また、必要に応じて誰かがコメントに残すことができるクールな原則を使用しようとします。