機械学習のバックボーン: モデル構築のためのインフラストラクチャ ツールは何ですか?

この記事は公開アカウント「Reading Core Technique」（ID: AI_Discovery）から転載したものです。

人工知能（AI）と機械学習（ML）はすでにあらゆる分野に「浸透」しており、企業は機械学習インフラストラクチャプラットフォームを通じてビジネスにおける人工知能の活用を促進することを期待しています。

[[328978]]

さまざまなプラットフォームや製品を理解するのは難しい場合があります。機械学習インフラストラクチャの領域は混雑しており、乱雑で、複雑です。多くのプラットフォームとツールは、モデル構築ワークフロー全体にわたって複数の機能をカバーしています。

エコシステムを理解するために、機械学習のワークフローをデータ準備、モデル構築、および制作の 3 つの段階に大まかに分けることができます。ワークフローの各段階での目標と課題を理解することで、企業のビジネスニーズに最適な機械学習インフラストラクチャ プラットフォームを正しく選択できるようになります。

機械学習インフラストラクチャプラットフォーム図

機械学習ワークフローの各主要段階には、多くの垂直機能があります。これらの機能の一部は、より大規模なエンドツーエンドのプラットフォームの一部ですが、その他の機能は特定のプラットフォームの主な焦点となっています。

この記事では、機械学習の第 2 段階であるモデル構築について説明します。

モデル構築とは何ですか?

モデル構築の最初のステップは、ビジネス要件を理解することから始まります。モデルではど​​のようなビジネス要件に対処する必要がありますか?

このステップは、機械学習ワークフローの計画およびアイデア創出フェーズ中に実行されます。このフェーズでは、ソフトウェア開発ライフサイクルと同様に、データ サイエンティストが要件を収集し、実現可能性を検討し、データの準備、モデルの構築、および生成の計画を策定します。彼らはまた、計画段階で検討されたさまざまなモデル構築実験を検討するためにデータを使用しました。

機械学習インフラストラクチャプラットフォーム図

機能の探索と選択

この実験プロセスの一環として、データ サイエンティストはさまざまなデータ入力オプションを検討して機能を選択します。特徴選択とは、機械学習モデルへの入力として特徴を見つけるプロセスです。

新しいモデルの場合、利用可能なデータ入力、入力の重要性、およびさまざまな機能間の関係を理解するのは、長いプロセスになる可能性があります。ここでは、より解釈可能なモデル、トレーニング時間の短縮、機能取得のコスト、過剰適合の緩和など、多くの決定を下すことができます。適切かつ適切な機能を見つけることは、継続的な反復プロセスです。

• 特徴抽出における機械学習インフラストラクチャ企業には、Alteryx/Feature Lab、Paxata (DataRobot) などがあります。

モデル管理

データ サイエンティストはさまざまなモデリング アプローチを試すことができます。特定のタスクでは、一部のタイプのモデルが他のモデルよりも適しています (たとえば、ツリーベースのモデルの方が解釈しやすい)。

アイデア創出フェーズの一部として、モデルが教師ありモデル、教師なしモデル、分類モデル、回帰モデルなどであるかどうかは明らかです。ただし、モデリング アプローチ、ハイパーパラメータ、および機能の選択は実験によって異なります。

一部の自動機械学習 (AutoML) プラットフォームでは、さまざまなパラメータを使用してさまざまなモデルを試行し、ベースライン アプローチを確立するのに役立ちます。手動で行う場合でも、さまざまなオプションを検討することで、モデル作成者はモデルの解釈可能性に関する洞察を得ることができます。

実験の追跡

さまざまなタイプのモデルには多くの利点とトレードオフがありますが、一般的に言えば、この段階では多くの実験が必要になります。多くのプラットフォームでは、これらの実験、モデリングの依存関係、およびモデル ストレージを追跡できます。これらの機能は、大まかにモデル管理に分類できます。

一部のプラットフォームは、主に実験の追跡に重点を置いています。トレーニングまたはサービング コンポーネントを持つ他の企業の中には、さまざまなモデルのパフォーマンスを比較したり、トレーニング/テスト データセットを追跡したり、ハイパーパラメータを調整および最適化したり、評価メトリックを保存したり、詳細な系統とバージョン管理を有効にしたりするためのモデル管理コンポーネントを備えているところもあります。

ソフトウェアの Github と同様に、これらのモデル管理プラットフォームは、バージョン管理、履歴の系統、再現性を可能にする必要があります。

さまざまなモデル管理プラットフォーム間のトレードオフは、統合のコストです。より軽量なプラットフォームの中には、実験の追跡のみを提供するものもありますが、現在の環境に簡単に統合して、データ サイエンス ノートブックにインポートできます。他のプラットフォームでは、より高度な統合が必要であり、モデルビルダーは集中型のモデル管理のためにそのプラットフォームに移行する必要があります。

機械学習ワークフローのこの段階では、データ サイエンティストは通常​​、ノートブックでモデルを構築およびトレーニングし、モデルの重みをモデル リポジトリに保存し、検証セットでモデルの結果を評価するために時間を費やします。

この段階では、トレーニングに必要なコンピューティング リソースを提供するプラットフォームが多数存在します。モデルには、チームがモデル オブジェクトを保存する方法に応じて、さまざまな保存オプションもあります。

• 機械学習インフラストラクチャ AutoML: H20、SageMaker、DataRobot、Google Cloud ML、MicrosoftML
• モデル管理のための機械学習インフラストラクチャ企業: Domino Data Labs、SageMaker
• ハイパーパラメータオプションの機械学習インフラストラクチャ企業: Sigopt、Weightsand Biases、SageMaker
• 実験追跡のための機械学習インフラストラクチャ企業: Weights and Biases、Comet ML、MLFlow、Domino、Tensorboard

モデル評価

選択された機能を含むトレーニング データセットで実験モデルをトレーニングしたら、テスト セットで評価できます。

このフェーズでは、データ サイエンティストはモデルのパフォーマンスと改善が必要な箇所を理解しようとします。より高度な機械学習チームの中には、履歴データを活用してモデルのパフォーマンスを評価できる自動化されたバックテスト フレームワークを備えているところもあります。

各実験では、ベースライン モデルのパフォーマンスを上回るか超えることを試み、計算コスト、解釈可能性、一般化可能性の間のトレードオフを考慮します。より規制の厳しい業界では、この評価プロセスに、モデルの再現性、パフォーマンス、要件を保証するために外部監査人が実施するコンプライアンスと監査も含まれる場合があります。

• モデル評価のための機械学習インフラストラクチャツール/フレームワーク: Fiddler AI、Tensorboard、Stealth Startups
• パイロット生産検証のための機械学習インフラストラクチャ: Fiddler AI、ArizeAI

上記のすべてのタスクを管理するプラットフォーム

AutoML またはモデル構築中心の企業の多くは、すべてを処理するために 1 つのプラットフォームのみを選択します。その結果、DataRobot、H20、SageMaker など、多くのプラットフォームが、企業がデータの準備、モデルの構築、および制作に使用する唯一の AI プラットフォームとなることを目指して競争しています。

コレクションは、ローコード ソリューションと開発者中心のソリューションに分かれています。 Datarobot は、ビジネス インテリジェンス (BI) チームや財務チームがデータ サイエンス プロジェクトに取り組めるようにするノーコード/ローコード オプションに重点を置いているようです。

これは、データ サイエンティストや開発者中心のチームなど、今日のより一般的なデータ サイエンス組織のニーズに対応していると思われる SageMaker や H20 などの企業とはまったく対照的です。

どちらの場合も市場は大きく、共存可能ですが、すべての機械学習インフラストラクチャ企業が同じ人やチームに販売しているわけではないことに注意する必要があります。

この分野に最近参入した企業の多くは、機械学習インフラストラクチャの食物連鎖の特定の部分に対する優れたソリューションとして見ることができます。良い類似例はソフトウェア エンジニアリングの分野です。GitHub、統合開発環境 (IDE)、運用監視などのソフトウェア ソリューションは、すべて同じエンドツーエンドのシステムではありません。

これらが異なるソフトウェアであることは事実ですが、提供する機能が大きく異なり、明確な違いがあります。

チャレンジ

ソフトウェア開発と並行して、モデルのトレーニングに使用されたデータのバージョン管理が不十分なため、モデルの再現性が課題となることがよくあります。

モデルのパフォーマンスを理解するには多くの課題があります。実験を比較して、どのモデル バージョンがパフォーマンスとトレードオフの最適なバランスであるかをどのように判断しますか? わずかに劣るモデルは妥協点ですが、解釈が容易になります。一部のデータ サイエンティストは、組み込みのモデル解釈機能を使用したり、SHAP/LIME を使用して機能の重要性を調査したりします。

もう 1 つのパフォーマンス上の課題は、実験段階でのモデルのパフォーマンスが現実世界にどのように反映されるかわからないことです。

これは、トレーニング データセット内のデータが、モデルが本番環境で目にする可能性のあるデータの代表的な分布であることを保証し、トレーニング データセットへの過剰適合を防ぐことで、大幅に軽減できます。ここで、クロス検証とバックテストのフレームワークが役立ちます。

その後何が起こりましたか?

データ サイエンティストにとって、モデルをいつ本番環境に導入するかの基準を決定することは重要です。既存のモデルが本番環境にデプロイされている場合は、新しいバージョンのパフォーマンスが向上する可能性があります。いずれにせよ、実験を現実世界の設定に移行するには、標準を設定することが重要です。

モデルがトレーニングされると、モデルの画像/重みがモデル リポジトリに保存されます。この時点で、モデルを本番環境にデプロイする責任を持つデータ サイエンティストまたはエンジニアは通常、モデルを取得してサービスに使用できます。

一部のプラットフォームでは、デプロイメントがさらに簡単になり、外部サービスが呼び出すことができる REST API を使用して、デプロイされたモデルを構成できます。