モデルを実装する場合は、シンプルに始めましょう。ML の作業のほとんどはデータ側で行われるため、複雑なモデルで完全なパイプラインを実行することは、モデル自体を反復処理するよりも困難です。データ パイプラインを設定し、いくつかの特徴を使用するシンプルなモデルを実装したら、より優れたモデルを作成するために反復処理できます。
シンプルなモデルは、最終的にリリースしない場合でも、優れたベースラインとなります。実際、シンプルなモデルを使用するほうが、思ったよりも効果的です。シンプルなモデルから始めることで、複雑なモデルが正当化されるかどうかを判断できます。
独自のモデルをトレーニングする、またはトレーニング済みのモデルを使用する
トレーニング済みモデルはさまざまなユースケースに存在し、多くの利点があります。ただし、トレーニング済みモデルが実際に機能するのは、ラベルと特徴がデータセットと完全に一致する場合のみです。たとえば、トレーニング済みモデルが 25 個の特徴を使用するのに、データセットに含まれる特徴が 24 個しかない場合、トレーニング済みモデルは誤った予測を行う可能性が高くなります。
通常、ML の実務担当者は、トレーニング済みモデルの入力の一致するサブセクションを使用して、ファインチューニングまたは転送学習を行います。特定のユースケースにトレーニング済みモデルが存在しない場合は、独自のモデルをトレーニングするときに、トレーニング済みモデルのサブセクションを使用することを検討してください。
トレーニング済みモデルの詳細については、以下をご覧ください。
モニタリング
問題のフレーム設定では、ML ソリューションに必要なモニタリングとアラートのインフラストラクチャを検討します。
モデルのデプロイ
場合によっては、新しくトレーニングされたモデルが、現在本番環境で使用されているモデルよりも劣ることがあります。問題がある場合は、本番環境へのリリースを防ぎ、自動デプロイが失敗したことを通知するアラートを受け取る必要があります。
トレーニング サービング スキュー
推論に使用される受信特徴の値が、トレーニングで使用されたデータの分布範囲外にある場合は、モデルが不正確な予測を行う可能性があるため、アラートを受け取る必要があります。たとえば、モデルが海抜で赤道の都市の気温を予測するようにトレーニングされている場合、サービング システムは、モデルがトレーニングされた範囲外の緯度、経度、高度を持つ受信データについてアラートを発する必要があります。逆に、モデルがトレーニング中に観測された分布範囲外の予測を行っている場合は、サービング システムからアラートが表示されます。
推論サーバー
RPC システムを介して推論を提供している場合は、RPC サーバー自体をモニタリングし、推論の提供が停止した場合にアラートを受け取る必要があります。