本番環境の ML での目標は、単一のモデルを構築してデプロイすることではありません。目標は、モデルを経時的に開発、テスト、デプロイするための自動パイプラインを構築することです。その世界が変化するとデータのトレンドが変化し、本番環境のモデルが古くなります。高品質の予測を長期にわたって提供し続けるには、通常、最新のデータでの再トレーニングが必要です。つまり、古くなったモデルを新しいモデルに置き換える方法が必要になります。
パイプラインがない場合、古くなったモデルの置き換えは、エラーが発生しやすいプロセスです。たとえば、モデルが不適切な予測の提供を開始した場合、新しいデータを手動で収集して処理し、新しいモデルをトレーニングして、その品質を検証し、最後にデプロイする必要があります。ML パイプラインは、これらの反復的なプロセスの多くを自動化し、モデルの管理とメンテナンスの効率と信頼性を高めます。
パイプラインの構築
ML パイプラインは、モデルを構築して明確に定義されたタスクにデプロイするステップを整理します。パイプラインには、予測の提供とモデルの更新の 2 つの機能のいずれかがあります。
予測の提供
サービング パイプラインが予測を提供します。モデルを実世界で公開し ユーザーがアクセスできるようにしますたとえば、ユーザーが予測（明日の天気や、空港までの移動の所要時間、おすすめの動画のリスト）を求める場合、サービング パイプラインはユーザーのデータを受信して処理し、予測を行い、ユーザーに配信します。
モデルの更新
モデルは、本番環境に移行した直後に陳腐化する傾向があります。要するに、古い情報を使用して予測を行っているのです。このトレーニング データセットは、1 日前、場合によっては 1 時間前の世界の状態をキャプチャしています。世界は必然的に変化しました。ユーザーはより多くの動画を視聴し、新しいおすすめリストを必要としています。雨によりトラフィックが遅くなり、ユーザーは到着時刻の予測を更新しなければなりません。人気のあるトレンドにより、小売業者は特定の商品の最新の在庫予測をリクエストする必要があります。
通常、新しいモデルは、本番環境モデルが陳腐化するかなり前にトレーニングを行います。場合によっては、継続的なトレーニングとデプロイのサイクルで、チームが毎日新しいモデルをトレーニングしてデプロイします。新しいモデルのトレーニングは、本番環境モデルが陳腐化するかなり前に行うのが理想的です。
次のパイプラインが連携して新しいモデルをトレーニングします。
- データ パイプライン。データ パイプラインは、ユーザーデータを処理して、トレーニング データセットとテスト データセットを作成します。
- トレーニング パイプライン。トレーニング パイプラインは、データ パイプラインの新しいトレーニング データセットを使用してモデルをトレーニングします。
- 検証パイプライン。検証パイプラインは、データ パイプラインによって生成されたテスト データセットを使用して、トレーニング済みモデルを本番環境モデルと比較します。
図 4 は、各 ML パイプラインの入力と出力を示しています。
ML パイプライン
図 4. ML パイプラインは、モデルの開発と維持のための多くのプロセスを自動化します。各パイプラインはその入力と出力を示しています。
ごく一般的なレベルで、パイプラインが本番環境で新しいモデルを保持する方法を示します。
まず、モデルが本番環境に移行され、サービング パイプラインが予測の提供を開始します。
データ パイプラインは、新しいトレーニング データセットとテスト データセットを生成するためのデータの収集を直ちに開始します。
トレーニングと検証のパイプラインは、スケジュールまたはトリガーに基づいて、データ パイプラインによって生成されたデータセットを使用して新しいモデルのトレーニングと検証を行います。
新しいモデルが本番環境モデルより悪くないことが検証パイプラインによって確認されると、新しいモデルがデプロイされます。
このプロセスが継続的に繰り返されます。
モデルの未更新とトレーニング頻度
ほぼすべてのモデルが古くなります。モデルの中には、他のモデルよりも早く古くなるものがあります。たとえば、洋服をおすすめするモデルは、消費者の好みが頻繁に変化することで有名であるため、通常はすぐに陳腐化します。一方、花を識別するモデルは古くなることはありません。花の識別特性は安定しています
ほとんどのモデルは、本番環境に投入された直後に陳腐化し始めます。データの性質を反映したトレーニング頻度を設定する必要があります。データが動的な場合は、頻繁にトレーニングします。動的さがあまりない場合は、それほど頻繁にトレーニングを行う必要はありません。
モデルが古くなる前にトレーニングする。早期トレーニングは、データやトレーニング パイプラインで障害が発生した場合や、モデルの品質が低い場合など、潜在的な問題を解決するためのバッファを提供します。
推奨されるベスト プラクティスは、新しいモデルのトレーニングとデプロイを毎日行うことです。ビルドとリリースのプロセスを毎日行う通常のソフトウェア プロジェクトと同様に、トレーニングと検証用の ML パイプラインは、多くの場合、毎日実行すると最も効果を発揮します。
サービス提供パイプライン
サービング パイプラインは、オンラインまたはオフラインのいずれかの方法で予測を生成して配信します。
オンライン予測。オンライン予測は、リアルタイムで行われます。通常、オンライン サーバーにリクエストを送信して予測を返します。たとえば、ユーザーが予測が必要な場合、ユーザーのデータがモデルに送信され、モデルは予測を返します。たとえば、Gmail はオンライン予測を使用して受信メッセージをリアルタイムで分類します。
オフライン予測。オフライン予測は事前に計算され、キャッシュに保存されます。予測を行うために、アプリはデータベース内にキャッシュに保存された予測を見つけて返します。たとえば、サブスクリプション ベースのサービスでは、サブスクライバーのチャーンレートを予測できます。このモデルは、すべてのサブスクライバーについてチャーンの可能性を予測し、キャッシュに保存します。アプリで予測が必要な場合（たとえば、離脱しそうなユーザーにインセンティブを与える場合など）、アプリは事前に計算された予測を検索するだけです。
図 5 は、オンライン予測とオフライン予測の生成と配信の仕組みを示しています。
オンライン予測とオフライン予測
図 5. オンライン予測は、リアルタイムで予測を提供します。オフライン予測はキャッシュに保存され、サービス提供時に検索されます。
予測の後処理
通常、予測は配信前に後処理されます。たとえば、有害なコンテンツや偏ったコンテンツを削除するために、予測を後処理することがあります。分類結果では、モデルの生の出力を表示するのではなく、ツイドリングを使用して結果を並べ替えることができます。たとえば、より信頼性の高いコンテンツの表示、結果の多様性の表示、特定の結果（クリックベイトなど）の順位の下げ、法的な理由による結果の削除などです。
図 6 は、サービス提供パイプラインと予測の提供に関連する一般的なタスクを示しています。
予測の後処理
図 6. 予測の提供に関連する一般的なタスクを示すサービング パイプライン。
通常、特徴量エンジニアリングのステップは個別のスタンドアロン プロセスではなく、モデル内で構築されます。サービング パイプラインのデータ処理コードは、多くの場合、データ パイプラインがトレーニング データセットとテスト データセットの作成に使用するデータ処理コードとほぼ同じです。
アセットとメタデータのストレージ
サービング パイプラインには、モデルの予測と、可能であればグラウンド トゥルースをログに記録するリポジトリを組み込む必要があります。
モデル予測をロギングすることで、モデルの品質をモニタリングできます。予測を集計することで、モデルの全般的な品質をモニタリングし、品質が低下しているかどうかを判断できます。通常、本番環境モデルの予測は、トレーニング データセットのラベルと同じ平均値を持つ必要があります。詳細については、予測バイアスをご覧ください。
正解の取得
場合によっては、グラウンド トゥルースがかなり遅れて利用可能になります。たとえば、天気アプリが 6 週間後の天気を予測する場合、グラウンド トゥルース（実際の天気）は 6 週間は利用できません。
可能であれば、フィードバック メカニズムをアプリに追加して、ユーザーにグラウンド トゥルースを報告してもらいます。Gmail は、ユーザーがメールを受信トレイから迷惑メールフォルダに移動すると、暗黙的にユーザー フィードバックを取得します。ただし、これはユーザーがメールを正しく分類した場合にのみ機能します。ユーザーが迷惑メールだとわかっていて開封していないため、受信トレイに迷惑メールを残すと、トレーニング データは不正確になります。「迷惑メール」であるべきメールには 「迷惑メールではない」というラベルが付けられますつまり、常にグラウンド トゥルースをキャプチャして記録する方法を見つけるよう努めますが、フィードバック メカニズムに存在する可能性のある欠点に留意してください。
図 7 は、ユーザーに配信され、リポジトリにログに記録される予測を示しています。
予測の記録
図 7. 予測をログに記録してモデルの品質をモニタリングします。
データ パイプライン
データ パイプラインは、アプリケーション データからトレーニング データセットとテスト データセットを生成します。トレーニングと検証のパイプラインは、データセットを使用して新しいモデルのトレーニングと検証を行います。
データ パイプラインは、最初にモデルのトレーニングに使用したものと同じ特徴とラベルで、新しい情報を含むトレーニング データセットとテスト データセットを作成します。たとえば、地図アプリは、何百万人ものユーザーの最近の移動時間から、天気などの他の関連データとともに、トレーニング データセットとテスト データセットを生成します。
動画レコメンデーション アプリでは、ユーザーがおすすめリストからクリックした動画（クリックされなかった動画）と、その他の関連データ（再生履歴など）を含むトレーニング データセットとテスト データセットを生成します。
図 8 は、アプリケーション データを使用してトレーニング データセットとテスト データセットを生成するデータ パイプラインを示しています。
データ パイプライン
図 8. データ パイプラインは、アプリケーション データを処理して、トレーニング パイプラインと検証パイプライン用のデータセットを作成します。
データの収集と処理
データ パイプラインでデータを収集して処理するタスクは、おそらくテスト フェーズ（ソリューションが実行可能であると判断）とは異なります。
データの収集。テスト中にデータを収集するには、通常、保存済みデータにアクセスする必要があります。データ パイプラインでは、データを収集するために、ストリーミング ログデータを検出し、アクセスの承認を得ることが必要になる場合があります。
人間がラベル付けしたデータ（医療画像など）が必要な場合は、データを収集して更新するプロセスも必要です。人間がラベルを付けたデータが必要な場合は、CrowdCompute ページをご覧ください。
データ処理。テスト中、適切な特徴はテスト データセットのスクレイピング、結合、サンプリングから得られました。データ パイプラインの場合、同じ特徴を生成するには、まったく異なるプロセスが必要になる場合があります。ただし、特徴とラベルに同じ数学演算を適用して、テストフェーズのデータ変換を複製してください。
アセットとメタデータのストレージ
トレーニング データセットとテスト データセットを保存、バージョニング、管理するためのプロセスが必要です。バージョン管理されたリポジトリには、次の利点があります。
再現性。モデルのトレーニング環境を再作成して標準化し、さまざまなモデル間で予測品質を比較します。
コンプライアンス。監査可能性と透明性に関する規制コンプライアンス要件を遵守します。
保持:データの保存期間について、データ保持の値を設定します。
アクセス管理。きめ細かい権限を使用して、データにアクセスできるユーザーを管理します。
データの整合性。経時的なデータセットの変更を追跡して把握し、データやモデルの問題を簡単に診断できるようにします。
見つけやすさ。他のユーザーがデータセットと特徴を簡単に見つけられるようにします。他のチームはその目的に役立つかどうかを判断できます。
データの文書化
優れたドキュメントは、タイプ、ソース、サイズ、その他の重要なメタデータなど、データに関する重要な情報を他のユーザーが理解するのに役立ちます。ほとんどの場合、設計ドキュメントまたは g3doc にデータを文書化するだけで十分です。データを共有または公開する場合は、データカードを使用して情報を構造化します。データカードを使用すると データセットを 簡単に見つけて理解できます
トレーニングと検証のパイプライン
トレーニング パイプラインと検証パイプラインは、陳腐化する前に本番環境モデルを置き換える新しいモデルを生成します。新しいモデルを継続的にトレーニングして検証することで、本番環境で常に最適なモデルを使用できます。
トレーニング パイプラインはトレーニング データセットから新しいモデルを生成し、検証パイプラインはテスト データセットを使用して、新しいモデルの品質と本番環境のモデルの品質を比較します。
図 9 は、トレーニング データセットを使用して新しいモデルをトレーニングするトレーニング パイプラインを示しています。
トレーニング パイプライン
図 9. トレーニング パイプラインは、最新のトレーニング データセットを使用して新しいモデルをトレーニングします。
モデルのトレーニング後、検証パイプラインはテスト データセットを使用して、本番環境モデルとトレーニング済みモデルの品質を比較します。
一般に、トレーニング済みモデルが本番環境モデルよりも有意に悪くなければ、トレーニング済みモデルは本番環境に移行します。トレーニング済みモデルの性能が悪い場合は モニタリングインフラがアラートを作成する必要がありますトレーニング済みモデルの予測品質が低い場合は、データ パイプラインまたは検証パイプラインに潜在的な問題があることを示している可能性があります。このアプローチにより、最新のデータでトレーニングされた最適なモデルが常に本番環境に存在するようになります。
アセットとメタデータのストレージ
モデルのデプロイを整理して追跡するには、モデルとそのメタデータをバージョニングされたリポジトリに保存する必要があります。モデル リポジトリには次の利点があります。
トラッキングと評価。本番環境でモデルを追跡し、評価と予測の品質指標を理解します。
モデルのリリース プロセス。モデルのレビュー、承認、リリース、ロールバックが 簡単にできます
再現性とデバッグ。デプロイ間でモデルのデータセットと依存関係をトレースすることで、モデルの結果を再現し、問題を効果的にデバッグします。
見つけやすさ。他のユーザーがモデルを簡単に見つけられるようにする。他のチームは、モデル（またはその一部）を目的に使用できるかどうかを判断できます。
図 10 は、モデル リポジトリに保存されている検証済みのモデルを示しています。
モデル ストレージ
図 10. 検証されたモデルは、追跡と検出可能性のためにモデル リポジトリに保存されます。
モデルカードを使用して、目的、アーキテクチャ、ハードウェア要件、評価指標などのモデルに関する重要な情報を文書化し、共有します。
パイプライン構築の課題
パイプラインを構築する際に、次のような課題に直面することがあります。
必要なデータにアクセスする。データアクセスに必要な理由を 説明しなければならない場合がありますたとえば、データの使用方法を説明し、PII の問題を解決する方法を明確にする必要があります。特定の種類のデータにアクセスして、モデルの予測精度を向上させる方法を示す概念実証を準備しておいてください。
適切な機能を利用する。テストフェーズで使用する機能は、リアルタイム データからは利用できない場合があります。そのため、テストを行う際は、同じ機能を本番環境で使用できることを確認してください。
データの収集方法と表示方法を理解する。データの収集方法、収集者、収集方法（およびその他の問題）を把握するには、時間と労力がかかる場合があります。データを十分に理解することが重要です。本番環境に移行する可能性のあるモデルのトレーニングには、自信のないデータを使用しないでください。
労力、費用、モデル品質のトレードオフを理解する。新しい機能をデータ パイプラインに組み込むには、多大な労力が必要になる場合があります。ただし、この追加の特徴によってモデルの品質がわずかに向上する可能性があります。新しい機能の追加が簡単な場合もあります。ただし、特徴を取得して保存するためのリソースは、非常に高コストになる可能性があります。
コンピューティングの取得。再トレーニングに TPU が必要な場合は、必要な割り当てを取得するのが難しい場合があります。また、TPU の管理は複雑です。たとえば、モデルやデータの一部を複数の TPU チップに分割し、TPU 専用に設計しなければならない場合があります。
適切なゴールデン データセットを見つけるデータが頻繁に変更される場合、一貫性のある正確なラベルを持つゴールデン データセットの取得が困難な場合があります。
テスト中にこの種の問題をキャッチすることで、時間を節約できます。たとえば、優れた特徴やモデルを開発して、本番環境で実現できないことを学習させるだけにすることは望ましくありません。したがって、ソリューションが本番環境の制約内で機能することをできるだけ早く確認するようにしてください。パイプライン フェーズでは克服できない問題が明らかになったため、テストフェーズに戻るよりも、ソリューションの動作確認に時間をかけることをおすすめします。