本番環境のMLを再現できない場合は、ワークフローに問題がある可能性があります。

機械学習コミュニティでは研究の再現性に関する議論が活発化していますが、こうした議論は主に学術的な環境に限定されています。実稼働環境での ML が再現可能であることをどのように確認すればよいでしょうか?最近、機械学習開発サービスプロバイダー maiot.io の CTO である Benedikt Koller 氏が、自身の経験に基づいて、再現可能な本番レベルの機械学習を開発する際に注意すべき 12 の要素を紹介するブログ記事を公開しました。

[[347115]]

ソフトウェア開発に対する私たちの理解は、過去 20 年間で劇的に進歩しました。その理由の大部分は、DevOps コンセプトの出現と、それがソフトウェア開発業界で広く適用されたことです。

大手ソフトウェア企業はすべて同じモデルに従っています。まず、ソフトウェア開発プロセスの迅速な反復、続いて継続的インテグレーション、継続的デリバリー、継続的デプロイメントです。すべての機能は価値を提供する能力についてテストされており、ソフトウェアは常に準備が整っており、自動化された方法で展開されます。

機械学習の分野は従来のソフトウェア開発とは異なりますが、ソフトウェア開発業界から多くの実践的な教訓を学ぶこともできます。過去数年間、私たちは実稼働用の機械学習プロジェクトを開発してきました。私たちの目標は概念実証だけではなく、ソフトウェア開発と同様に再現性です。そこで私たちは、プロセス オーケストレーターと強力な自動化機能を構築し、この目標を達成するための一連のワークフローを確立しました。

Jupyter Notebook を使わないのはなぜですか?すべての処理手順を含むメモのセットを最初から構築するにはどれくらいの時間がかかりますか?チームに新しいメンバーを追加するのは簡単ですか? 2 か月前の結果を再現できますか?どれくらい早く再現できるでしょうか?今日の結果と過去の結果を比較できますか?トレーニング中にデータがどこから来るのか注意できますか?モデルが古くなった場合はどうなりますか?

私たちはこれらすべての問題に遭遇しました。私たちはこれらの経験を、本番環境の機械学習をうまく構築するための 12 の要素 (ソフトウェア開発の 12 要素アプリに類似) にまとめました。

1. バージョン管理

バージョン管理は、ソフトウェア エンジニアにとっては基本的に当然のことですが、この方法論はデータ サイエンティストにはまだ広く採用されていません。 Gitlab の何人かの人が言ったことを引用しましょう:

バージョン管理により、ソフトウェア開発チーム全体での調整、共有、コラボレーションが容易になります。バージョン管理ソフトウェアを使用すると、チームは分散環境や非同期環境で作業し、コードやファイルの変更やバージョンを管理し、マージの競合や関連する異常を解決できます。

簡単に言えば、バージョン管理により、ソフトウェア開発の変更部分を安全に管理できます。

機械学習は、実際には独自の特定の要件を持つ特別な種類のソフトウェア開発です。まず、機械学習にはコードとデータという 1 つではなく 2 つの可動部分が存在します。 2 番目に、モデルのトレーニング方法は (急速に) 反復的であり、コードの違いが大きくなる可能性があります (例: 分割、前処理、モデル)。

データが変更されるたびに、結果を再現し、実験とトレーニング済みモデルを繰り返すことができるように、バージョンを保存する必要があります。ブルートフォース バージョン管理 (ハード コピー) には改善の余地が大いにありますが、特にチームで共有する場合は、変更のないバージョン管理を維持できることが重要です。

コードのバージョン管理はさらに重要です。上記の引用に加えて、前処理コードはトレーニング フェーズ中だけでなく、サービング フェーズでも重要であり、モデルと一定の相関関係を持つ必要があります。データ サイエンティストのワークフローと本番環境への移行要件の中間点を構築するには、サーバーレス関数を提供するのが便利なアプローチです。

概要: コードのバージョン管理を行う必要があり、データのバージョン管理も行う必要があります。

2. 機能の依存関係を明確にする

理想的な世界では、入力データを生成するものは、少なくとも構造的には常に同じデータを生成する必要があります。しかし、世界は完璧ではなく、上流のサービスから取得するデータは人間によって構築されるため、変更される可能性があります。最終的には特性も変化する可能性があります。最良の場合、モデルは単に失敗しますが、最悪の場合、モデルは静かに動作し続けますが、得られる結果はゴミになります。

明確に定義された機能の依存関係により、障害ケースができるだけ早く明らかになります。システムが適切に設計されていれば、サービスを提供しながら、依存関係を調整し、適応しながら継続的にトレーニングすることもできます。

概要: コード内の機能の依存関係を明示的に示します。

3. 記述的トレーニングと前処理

優れたソフトウェアには適切な説明とコメントがあり、コードのすべての行を読まなくてもコードの動作を簡単に読み、理解できます。

機械学習は特殊なタイプのソフトウェア開発ですが、実践者が既存のコード作成ガイドラインから逸脱することを推奨するものではありません。コード記述標準の最も基本的な原則は、人々が短時間で簡単に読めるようにすることです。

前処理とモデル コードは両方とも PEP8 仕様に従う必要があります。コードでは意味のあるオブジェクト名を使用し、理解を助けるコメントを含める必要があります。 PEP8 標準に従うことで、コードの読みやすさが向上し、複雑さが軽減され、デバッグが高速化されます。 SOLID のようなプログラミング パラダイムは、コードの保守性、理解しやすさ、将来のユース ケースに対する柔軟性を向上させる、よく考えられたフレームワークを提供します。

構成はコードから分離する必要があります。データ割り当て比率をコードにハードコードするのではなく、実行時に変更できるように構成を通じて提供します。これはハイパーパラメータ調整のコンテキストではすでによく知られています。個別の構成ファイルを使用すると、反復処理が大幅に高速化され、コードの再利用が可能になります。

概要: コードの読みやすさを改善し、コードと構成を分離します。

4. トレーニング結果の再現性

トレーニング結果を再現できない場合は、信頼できません。これがこの記事のテーマですが、再現性に関して説明すべき詳細がいくつかあります。トレーニング結果を再現できる必要があるだけでなく、チーム全体が同じことを実行できる必要があります。 Jupyter Notebook でトレーニング結果を難読化することは、PC でも AWS VM でも、再現性の妨げになります。

トレーニング ワークフローを設定することで、チーム全体が実行された実験やトレーニングの実行に透過的にアクセスできるようになります。再利用可能なコードベースと個別の構成ファイルをバンドルすることで、誰でもいつでも正常に再トレーニングできるようになります。

概要: パイプライン ワークフローと自動化を使用します。

5. テスト

テストにはさまざまな形式があります。ここに 2 つの例を示します。

1) ユニット テストは、原子レベルでのテストです。つまり、各機能と機能を独自の基準に基づいて個別にテストします。

2) 一方、統合テストでは、コードベースのすべての要素をまとめてテストするとともに、上流および下流のサービスのクローンまたはシミュレートされたバージョンもテストします。

どちらのパラダイムも機械学習に適応可能です。前処理コードはテスト段階まで事前に決定されます - 変換はさまざまな入力に対して正しい結果を生成しますか?モデルは統合テストの優れた例です。モデルは、評価したときと同じように、本番環境で提供されたときにもパフォーマンスが良好でしょうか?

要約: コードをテストし、モデルをテストします。

6. 逸脱と継続的なトレーニング

実稼働シナリオでは、タスクのドリフトは当然の問題です。データに変更が生じる可能性がある場合は、ドリフトの可能性を考慮する必要があります。このリスクに対処するには、次の 2 つのアクションが考えられます。

1) 運用システムのデータを監視します。明確に定義された機能の依存関係を超えてデータが変更された場合にチームに通知するための自動レポート メカニズムを確立します。

2) 新しい入力データに基づいてトレーニングを継続します。適切に自動化されたパイプライン プロセスは、新しいデータに基づいて繰り返し実行され、過去のトレーニング結果と比較してパフォーマンスの変化を示し、トレーニングされたモデルをすぐに本番環境に導入して、モデルのパフォーマンスを向上させることができます。

概要: データが変更された場合は、継続的なトレーニングのパイプラインを使用します。

7. 結果を追跡する

Excel は実験の結果を追跡するのに適していません。これは Excel に限ったことではありません。分散化された手動の追跡方法では、信頼性の低い情報が生成されます。

正しいアプローチは、集中型のデータ保存方法でトレーニング結果を自動的に記録することです。自動化により、各トレーニング セッションを確実に追跡できるため、後で各トレーニング セッションの結果を簡単に比較できます。結果を集中的に保存することで、チームに透明性がもたらされ、継続的な分析が可能になります。

概要: 自動化された方法で結果を追跡します。

8. 実験モデルと生産モデル

データセットを理解するには努力が必要です。通常、特に関心のあるドメインに暗黙のドメイン知識がたくさんある場合は、実験を通じて理解を深めます。 Jupyter Notebook を作成し、データの一部またはすべてを Pandas Dataframe にインポートし、数時間シャッフル調査を行い、最初のモデルをトレーニングして、結果を評価します。これでミッションは完了です。しかし幸いなことに、そうではありません。

実験には、機械学習のライフサイクルにおける目的があります。目的はモデルではなく理解です。探索的な Jupyter Notebook ベースのモデルは理解を目的としており、生産用に開発された完成品ではありません。一度理解したら、実稼働用のトレーニング プロセスの構築を開始する前に、さらに開発と適応を行う必要があります。

ただし、ドメイン固有の知識に関連しないすべての理解は自動化できます。使用するデータの各バージョンに基づいて統計を生成できるため、Jupyter Notebook で実行していた可能性のある 1 回限りのアドホック探索作業をすべてスキップして、最初のパイプラインに直接進むことができます。プロセスの早い段階で実験を行うほど、中間結果についての共同作業が早くなり、生産準備が整ったモデルを早く実現できるようになります。

要約: メモは本番環境に導入できないため、プロセスのできるだけ早い段階で実験してください。

9. トレーニングとサーブのアプローチの違い

トレーニングと実際の提供の間には方法論的な違いがしばしば存在しますが、すべてのデータ前処理をモデル提供環境に適切に組み込むには、これを軽減する必要があります。これは確かに真実であり、それに固執する必要があります。しかし、これは問題の部分的な解釈にすぎません。

まず、DevOps の古い歴史を簡単に振り返ってみましょう。2006 年に、Amazon の CTO である Werner Vogels 氏が「You build it, you run it.」というフレーズを生み出しました。これは、開発者の責任はプログラムを書くだけでなく、それを実行することでもあることを意味する説明的なフレーズです。

機械学習プロジェクトにも同様のメカニズムが必要です。上流のデータ生成と下流のモデルの使用を理解することは、どちらもデータ サイエンティストの責任です。トレーニングに使用するデータはどのシステムで生成されますか?うまくいかないでしょうか？このシステムのサービス レベル目標 (SLO) は何ですか?これは実際のサービスの目標と一致していますか?あなたのモデルはどのように機能しますか?ランタイム環境はどのようなものですか?サービング時に関数を前処理するにはどうすればよいですか?これらはデータ サイエンティストが理解して答える必要のある質問です。

概要: サービスに前処理を正しく組み込み、データの上流と下流を理解していることを確認します。

10. 比較可能性

2 番目のトレーニング スクリプトをプロジェクトに導入したときから、比較可能性は将来の作業の重要な部分になりました。 2 番目のモデルの結果を最初のモデルの結果と比較できない場合、プロセス全体が無駄になり、少なくとも 1 つは冗長になり、両方が冗長になる可能性もあります。

定義上、同じ問題を解決するようにトレーニングされたすべてのモデルは比較可能である必要があります。そうでない場合、同じ問題を解決していないことになります。反復プロセスによって比較対象が変更される場合がありますが、モデル トレーニングでの比較可能性を技術的に実現するには、この機能が最初から第一級の機能としてトレーニング アーキテクチャに組み込まれている必要があります。

概要: 独自のパイプラインを構築して、パイプライン間でトレーニング結果を簡単に比較します。

11. 監視

大まかに言えば、機械学習の目標は、データから学習して問題を解決することです。この問題を解決するには、コンピューティング リソースを割り当てる必要があります。最初に割り当てられたモデルのトレーニングが行われ、次に割り当てられたモデルが提供されます。トレーニング中にリソースを提供する責任がある個人または部門は、それらのリソースをサービスに転送する責任も負います。モデルの使用中にパフォーマンス低下の問題が発生する可能性が多数あります。データが歪んだり、モデルが全体的なパフォーマンスのボトルネックになったりする可能性があり、バイアスは深刻な問題となります。

効果: データ サイエンティストとチームは、作成したモデルを監視する責任を負います。特に組織が大きい場合、監視の実装については必ずしも責任を負うわけではありませんが、監視データの理解と解釈につ​​いては確実に責任を負います。最低限監視する必要があるのは、入力データ、推論の数、リソース使用量 (CPU、RAM)、および出力データです。

要約: 繰り返しになりますが、「構築したら、実行します。」運用中のモデルを監視することはデータ サイエンスの一部です。

12. モデルの展開可能性

技術的な観点から見ると、すべてのモデル トレーニング プロセスでは、実稼働環境に展開できる完成品を作成する必要があります。これらのモデルの結果がひどいものになる可能性は間違いありませんが、実稼働環境に展開できる形式にする必要があります。

これはソフトウェア開発における一般的なパターンであり、継続的デリバリーとも呼ばれます。チームはいつでもソフトウェアを展開できる必要があり、この目標を達成するには反復サイクルが十分に高速である必要があります。

機械学習にも同様のアプローチが必要です。これにより、チームはまず現実と期待のバランスを考慮する必要が生じます。すべての利害関係者は、モデルの結果に関して理論的にどのような結果が起こり得るかを明確に理解する必要があります。すべての関係者は、モデルがどのように展開され、大規模なソフトウェア アーキテクチャとどのように統合されるかについて合意する必要があります。ただし、これには自動化と上記の要素の一部も必要になる場合があります。

概要: すべてのトレーニング プロセスでは、モデルだけでなく、展開可能な製品を作成する必要があります。