実稼働機械学習システムの構築に関する考慮事項

データとコンピューティング能力の向上に伴い、「機械学習」（ML）と「ディープラーニング」という用語は、ここ数年間、熱く議論されてきました。 ML の流行に乗るのはクールに思えるかもしれませんが、企業にとって最初のステップは、ビジネスが実際に ML から利益を得られるかどうかを評価することです。これは別の立場です。会社が ML が次のステップとして必要であると判断した今、ML エンジニアとして、本番システム用の ML プロセスを構築するために実際に何が必要かを考える時が来ました。この記事がこれらの問題の理解に役立つことを願っています。

[[313730]]

この投稿では、「スタートアップ」という言葉が言及されている場合、ソフトウェア「サービス」会社が具体的に言及されていない限り、ソフトウェア「製品」会社を意味します。ソフトウェア製品会社は自社のソフトウェア製品の構築に重点を置いていますが、ソフトウェア サービス会社 (代理店やコンサルティング会社など) はクライアント向けのソフトウェアを構築します。この記事は、初期段階のソフトウェア製品スタートアップの ML エンジニア向けに書かれていますが、考慮事項の一部は他の段階や企業タイプにも当てはまる可能性があります。

適切なツールを見つける

PyTorch、TensorFlow、scikit-learn などのオープンソース ツールから、Google AI Platform、Amazon SageMaker、Azure Machine Learning Platform などのマネージド機械学習サービス プラットフォームまで、さまざまな機械学習ソフトウェア オプションが利用可能です。 PyTorch と TensorFlow のみを使用する場合、Hugging Face のトランスフォーマーのように、開始点として既成のモデルを提供するオープンソース ライブラリが多数あります。さらに、ML のさまざまな分野の研究論文が毎年発表されており、その中にはオープンソース コードを提供しているものもあります。コード付き論文: https://paperswithcode.com/ は、コード付き論文を見つけるのに適したリソースです。

適切なツールを選択する際に考慮すべき重要な要素は次のとおりです。

• ドキュメントの品質
• ツールの開発状況 (保守中か停止中または廃止中か、問題の重大度など)
• このツールを取り巻く他のツールのエコシステム
• 開発者コミュニティはこのツールに積極的に関与していますか?
• ツールに対するあなたの知識
• ツールを使用するチームの規模
• ツールに関連する金銭的コスト

個人的には、初期段階のスタートアップであれば、これらすべての要素を検討して理解する必要はないと感じています。強力な候補ツールから始めて、そこから進めていくことができます。さらに、メリットがコストを上回ると判断した場合は、最初からマネージド ML サービスを使用することもできます。

機械学習を始める時期と機械学習に関連する運用

最初は、シンプルなベースライン モデルから始めるのが最適です。より単純なモデルから始めると、パイプライン内の問題をデバッグし、より時間のかかるソリューションが価値があるかどうかを判断するのに役立ちます。では、シンプルなベースライン モデルをどのように構築するのでしょうか?

まず第一に、「シンプル」というのは相対的なものです。場合によっては、シンプルとは、いくつかのヒューリスティックをハードコーディングするなど、実際にはシンプルなモデルを意味します。他のケースでは、モデル自体は複雑でも適用が簡単な場合があります。最も広く使用されているデータセットの中には、スタンフォード質問回答データセット (SQuAD) のように、オープンソースで研究論文やリーダーボードなどの場所にリストされている最先端のモデルを持つものがあります。 1 つの方法は、いくつかのトップソリューションを調べて、関連する研究論文に添付されたコードを見つけることができるかどうかを確認することです。

スタートアップの初期段階では、すぐに ML プロセスを構築する時間がない可能性があります。通常は、投資家や顧客が簡単に見ることができるものを実行することに重点を置きます。チューニングのプロセスが彼らの頭に浮かぶことはほとんどありません。したがって、最初の展開が完璧かどうかを心配する必要はありません。機能する製品、つまり目に見える最終製品を用意するだけで十分です。基本的な製品が構築された後は、ML プロセスに小さな段階的な改善を加えるために通常より多くのダウンタイムが必要になるため、ML 関連のプロセスについてより注意を払うことができます。

逆に、代理店の場合は、完成品をさまざまなクライアントに提供し、事前にすべてのバグを修正しようとするため、エラーの余地が少なくなります。 1 つまたは一連のクライアント製品を提供した後、次のクライアント契約に移りますが、多くの場合、さらなる改善を行うためのエネルギーが足りません。それでも、すぐに行動しなければなりません。より速く進歩するには、より洗練された ML プロセスを採用することが望ましいです。したがって、代理店モデルの場合、最初に最適化と自動化に多くの時間を費やすことで、長期的には時間を節約できる可能性があります。

実験管理における考慮事項

ML で実験を管理するのは簡単な作業ではなく、できるだけ多くの実験を実行すると、プロジェクト ワークスペースが簡単に乱雑になる可能性があります。しかし、スタートアップでは、何百もの実験を実行するのに何ヶ月もかかるわけではありません。より良いものを目指して、できるだけ早く更新する必要があります。いずれにせよ、何らかの実験的な管理を行うことは、何もしないよりはましです。 ML 実験を管理する際に考慮すべき事項をいくつか示します。

モデルバージョン

Toucan AI では、コードのバージョンを保存するために GitHub を使用しています。 GitHub は素晴らしいですが、大きなデータ ファイルのバージョン管理には適していません。リポジトリは最大 100 GB まで可能ですが、GitHub ではリポジトリのサイズを 1 GB 未満に保ち、個々のファイルは 100 MB を超えないようにすることを推奨しています。

Google Cloud Storage や Amazon S3 などの他のクラウド ストレージ オプションを使用することもできます。クラウド プロバイダーのコマンド ライン ツールまたは Web ユーザー インターフェースを使用して、オブジェクト (ファイルまたはフォルダー) のバージョン管理を可能にするバケット (フォルダー) を作成します。ただし、クラウド ストレージ内のファイルを GitHub 上のプロジェクト リポジトリと同期する場合は、追加の手動作業が必要になります。

そのため、私たちは Git プラットフォームと他のクラウド ストレージ オプションの最高の機能を組み合わせた最も自然な統合である、「機械学習プロジェクト向けのオープン ソース バージョン管理システム」と呼ばれるデータ バージョン コントロール (DVC) を選択しました。 DVC は、サブコマンドが Git サブコマンドと非常によく似ているコマンドライン ツールです。 Git プラットフォームとクラウド ストレージをセットアップしたら、DVC の「add」コマンドと「push」コマンドを実行してバージョンを設定し、ファイルまたはフォルダーをクラウド ストレージに保存できます。同時に、DVC ファイル参照を通じて、Git プロジェクト リポジトリ内の大きなデータ ファイルを追跡できます。 DVC の利点の 1 つは、Git のようなコマンドをいくつか追加するだけで済むため、既存の Git ワークフローに大きな違いが生じないことです。

実験ドキュメント

ハイパーパラメータの調整を行っている場合、特定の日にモデルに有効だった特定の設定を見落としてしまう可能性が高くなります。また、上記のモデルに必要なデータセットを準備または前処理するために行った作業を確認することもお勧めします。 Jupyter Notebook にはわかりやすいファイル名が付けられていますが、最初に何が起こったか、または実験 7 に前処理 A または B を適用したかどうかを処理するには、かなりの時間がかかります。

1 つの解決策は、新しいノートブックを作成するときに、ノートブックの番号をファイル名の一部にすることです (私は「01_」ステップを使用します)。これは後で番号を付け直すことができます。ノートブックの番号付けに明確な命名規則を設定すると、同僚 (および将来の自分) が実験の実施方法を理解するのに非常に役立ちます。実験のノートブックに番号を付けるだけでなく、オープンソース プラットフォーム MLflow を使用して、実験のハイパーパラメータとメトリックの結果を表示するための Web インターフェイスも提供します。

さらに、実験を文書化するときは、論理的な構造と簡潔さを心がけてください。フォルダー構造と名前を有効に活用して、ノートブックとトレーニング スクリプトを整理します。読者がノートブックを表示するときは、最初から最後まで読むと想定して、一時的に挿入した「下書き」セルを削除します。経験則として、ノートブック内の実験は 1 つのモデルと 1 つのデータセットに制限し、現在のノートブックが長すぎる場合は新しいノートブックを作成します。ノートブックの最終バージョンにトレーニング コードや推論コードが含まれていないことを確認してください。これらは、ノートブックから呼び出すことができる別のスクリプトに配置する必要があります。最後に、MLflow などのソフトウェアを使用して実験レコードを生成する場合は、生成された実験出力ファイルに実験を実行したノートブックを自動的に参照するようにしてください。

テストフレームワーク

メトリック結果の改善は、必ずしも実際のサンプルでの推論パフォーマンスの向上と相関するわけではありません。さらに、実稼働 ML システムでは、ML モデルは独立して動作しません。たとえば、パイプラインの一部としてヒューリスティック、前処理、キャッシュが使用される場合があります。そのため、既存の ML モデルを改善しようとすると、現実世界の推論に適した例を生成するのに多くの時間がかかることがわかります。改善しようとしているモデルが実際に呼び出されている場所を見つけるには、より大きな本番コードを調べる必要があります。ただし、モデル自体の入力と出力だけでなく、ML システム パイプライン全体もチェックする必要があります。 「より良い」モデルはシステム全体にどのような影響を与えますか? 良くなりましたか、それとも悪くなりましたか?

推論の例を考え出したり、実稼働パイプラインで何かが壊れるのではないかと心配するのではなく、モデルの改善に集中するためには、自動化されたシステムまたはエンドツーエンドのテスト フレームワークが必要です。

Toucan AI では、主力製品が AI セールス エージェントであるため、ロジックの主要な分岐をカバーするサンプル会話をテストし、回帰テストの形式も提供すれば十分です。現在、一連の会話例に対して pytest アサーションを実行するコマンド ライン インターフェイス (CLI) ツールを開発しています。 1 つのコマンドですべての会話をテストでき、テスト ケースが壊れた場合は、手動でテストを更新したり、「より良い」モデルが実際には本番環境には適していないと判断したりできます。

つまり、テスト フレームワークを導入することは、現在のモデルと実験的なモデルが実稼働 ML システムでどのように機能するかを理解するために重要です。適切なテスト フレームワークを導入すると、モデル改善パイプラインがより効率的に進み、以前よりも多くの実験を実行できるようになります。

ツールを使った急速な進化

急速に進化するライブラリからコードを抽出し、変更された古いバージョンのライブラリを使用する実稼働システムに書き込むのは困難です。急速に進化するライブラリをニーズに合わせて変更し、最新のアップデートをできるだけ効率的に適用するにはどうすればよいでしょうか。

正しい答えはなく、たださまざまな道があるだけだと感じています。 1 つの方法は、相手のコードを自分のコードと組み合わせて動作させることです。別の方法としては、コードを使用して古いバージョンを完全にアップグレードする方法がありますが、通常は時間がかかります。つまり、リファクタリングにどれくらいの時間がかかるか、何を優先すべきかを考えます。独自のコードベースと迅速な開発ツールがより安定したら、優先順位付けに重点を置き、完全なリファクタリングを検討する必要があります。

実験の配置

結果を得ることに集中していると、整理整頓を無視しがちです。次に実行する一連の実験とそのハイパーパラメータのセットを検討します。エラーが発生しましたか? 問題ありません。出力フォルダーのタイムスタンプを変更して、実験を再実行してください。ただし、最終的には、不完全な実験によって生成された余分なファイルやフォルダーが残ります。その後、MLflow の長いレコード リストをスクロールして完了した実験を探しますが、結局は頭を悩ませることになります。

解決策は、保存したくないテスト実行を自動的に削除することです。たとえば、最初のトレーニング反復の実行が完了する前に、失敗した実行を削除するとよいでしょう。同僚や将来の自分たちのために、私たちは全員、研究室のプールを清潔に保つよう最善を尽くすべきです。

関心の分離

モデルを改善するためにさまざまな ML プロジェクトを調査して試してみると、矛盾する Python パッケージ要件に遭遇することになります。最初は 2 人の開発者間でクラウド サーバーを共有するかもしれませんが、自分のインストールによって同僚の環境が上書きされる可能性があるため、すぐに不便になります。

プロジェクト環境と依存関係を管理するための軽量のコンテナ化ソフトウェア プラットフォームである Docker エコシステムを導入しましょう。各 ML モデルとアプリケーション サービスに個別の Docker コンテナを使用することで、「自分のマシンでは動作する」という問題を積極的に減らし、プロジェクト間の依存関係の競合を防ぐことができます。より多くの開発サーバーをセットアップする代わりに、コスト効率が高ければ、同僚がそれぞれ 1 つの共有サーバー上に独自の Docker コンテナーをセットアップすることもできます。

また、Conda では異なるパッケージ バージョンで異なる環境を作成できるため、Conda ではなく Docker を選択する必要がある理由が疑問に思うかもしれません。 Docker を選択したのは、Docker が提供するツールが本番環境やクラウド環境に適しているためです。リモート マシンで Conda を使用する場合は、まずマシンに接続してファイル転送を処理する必要があります。ただし、Docker でいくつかのコマンドを実行するだけで、ローカル ファイルに変更を加え、それをリモート マシンの Docker コンテナーに反映させることができます。さらに、プロジェクトを実行するために必要なものはすべて、Dockerfile または Docker Compose ファイルで指定されます。

一方、Conda では、README を参照しないと追加の手順が必要かどうかが明確ではありません。最後に、Docker Compose のパワーを活用することで、ML プロジェクトで他のサービスを実行する必要がある場合、それらのサービスを他の Docker コンテナーで個別に実行し、Docker Compose ファイルの設定に従って相互に通信することができます。私の知る限り、Conda では環境間で通信することはできません。

拡張準備完了

初期段階のスタートアップの場合、今すぐに規模を拡大する必要はないかもしれませんが、規模を拡大できるテクノロジーについて考え始めるのは良い考えです。これらのテクノロジーの 1 つが、タスクを複数のワーカーに分散できる非同期タスク キュー システムである Celery です。現在、サービスの種類 (サーバー、クライアント、埋め込みモデルなど) ごとに個別のワーカーがありますが、必要に応じて同じサービスに対してさらに多くのワーカーを起動しても、それほど手間はかかりません。埋め込みによるキャッシュがボトルネックになっていませんか? 問題ありません。別の埋め込み Celery ワーカーを起動するか、現在のワーカーの「同時実行」数を増やして、複数の子プロセスを並行して実行できるようにします。当社の Toucan AI 構成では、Celery ワーカーは Docker コンテナ内で実行されるため、関心の分離も実現されます。

Celery は、本番システムの拡張を可能にするだけでなく、ML モデル推論タスクなどの長時間実行タスクの実行にも適しています。サーバー応答がハングするのを許可するのではなく、サーバー応答 (エージェントの回答) を Toucan AI エージェントと会話しているエンド ユーザーにすぐに返すことができ、同時に非同期タスク (キャッシュ メカニズムなど) をバックグラウンドで静かに実行できます。さらに、Celery beat を使用して、毎日スケジュールされた分析ワーカー タスクを実行します。

同僚や将来の自分と協力する

ML 研究が絶えず発表される中、ML エンジニアとして、試行から使用までのモデルやテクニックについてチーム メンバーに情報を提供するにはどうすればよいのでしょうか。彼らが得た知識、経験、洞察のすべてをあなたに伝える魔法の弾丸はありません。しかし、あなたができることはコミュニケーションをとることです。頻繁にコミュニケーションをとってください。

特に文書を作成するときは、できるだけコミュニケーションをとってください。通常、あなたは自分のプロジェクトに取り組んでいるので、あなたが取り組んでいる内容は同僚が取り組んでいる内容と完全には関連していない可能性があります。ただし、将来的には、実装した内容を確認したり拡張したりする必要があるかもしれません。数か月後に自分のプロジェクトに変更を加える必要が生じ、重要な部分を忘れてしまうこともあるかもしれません。ドキュメント、ドキュメント、ドキュメント。このことはいくら強調してもし過ぎることはありません。

一方で、ドキュメントだけでは不十分な場合も必ずあります。何かについて確信が持てず、率直な意見を聞きたい場合、また、話すことの方がコミュニケーションのより効果的な手段だと感じる場合は、同僚の精神的な集中力に注意を払い、プロジェクトの方向性について話し合うようにしてください。誤解や無駄な作業、後悔を防ぐために、最初からできる限り明確にしておくことが非常に重要です。

機械学習エンジニアとしての内なる葛藤

機械学習エンジニアとして、修正したいことのアイデアと、現在のニーズを達成するためにプロセスを改善するというアイデアのバランスを取ることを学ばなければなりません。仕事をやり遂げるためには、最も直接的なアプローチを取ることを受け入れることを学ばなければなりません。たとえば、サードパーティのトレーニング/評価コードの改善に時間を費やしたいのですが、当時は、推論結果が改善されるかどうかを確認するために最短経路をたどるだけで十分でした。

私はウェブ開発のバックグラウンドを持っているので、主に自分でコードを書く必要がありましたが、MLエンジニアリングでは他の人のコードを適用する方法を学ぶ必要がありました。自分のものではないコード (多くの場合、学生や研究者が数か月または数年かけて作成したコード) を常に扱っている場合、特に実稼働システムに直接展開されていないコードの側面を理解しようとしているときは、失敗したように感じずにはいられないことがあります。

結局のところ、私たちは本来好奇心旺盛な生き物であり、必要以上に学びたいと思っても問題ないということを覚えておいてください。探求したい道がある場合は、チームメイトに透明性を保つことが重要です。良い職場環境では、十分なタイミングで目標を達成すれば、さらに学びたいという気持ちを責めることはありません。優先順位を正しく設定していれば、心配を減らして、もっと楽しむことができます。

結論は

実稼働システム用の ML パイプラインの構築は簡単ではありません。この記事で述べたことすべてにもかかわらず、時には単に決断を下すことが最善の決断となることもあります。それでもうまくいかない場合は、次のパスに進みます。いずれにせよ、この記事がさまざまなアイデアをよりよく理解するのに役立つことを願っています。