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