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