このドキュメントは、教師あり学習タスクに焦点を当てて、機械学習 (ML) のためのデータ エンジニアリングと特徴エンジニアリングのトピックを探求する 2 部構成のシリーズの第 1 部です。この最初のパートでは、Google Cloud 上の ML パイプラインでデータを前処理するためのベスト プラクティスについて説明します。このドキュメントでは、TensorFlow とオープンソースのTensorFlow Transform ( tf.Transform ) ライブラリを使用して、データを準備し、モデルをトレーニングし、予測用にモデルを提供することに焦点を当てています。このドキュメントでは、ML 用のデータの前処理の課題に焦点を当て、Google Cloud でデータ変換を効果的に実行するためのオプションとシナリオについて説明します。
このドキュメントは、読者がBigQuery 、 Dataflow 、 Vertex AI 、および TensorFlow Keras API に精通していることを前提としています。
2 番目のドキュメント「Google Cloud を使用した ML のデータ前処理」では、 tf.Transformパイプラインを実装する方法についてのステップバイステップのチュートリアルが提供されます。
導入
ML は、データ内の複雑で潜在的に有用なパターンを自動的に見つけるのに役立ちます。これらのパターンは ML モデルに凝縮されており、新しいデータ ポイントで使用できます。これは、予測の実行または推論の実行と呼ばれるプロセスです。
ML モデルの構築は複数のステップからなるプロセスです。各ステップには、独自の技術的および概念的な課題が存在します。この 2 部構成のシリーズは、教師あり学習タスクと、ターゲット変数に対する強力な予測シグナルを作成するためにソース データを選択、変換、および拡張するプロセスに焦点を当てています。これらの操作では、ドメインの知識とデータ サイエンスの技術が組み合わされます。この操作は特徴量エンジニアリングの本質です。
現実世界の ML モデルのトレーニング データセットのサイズは、簡単に 1 テラバイト (TB) 以上になることがあります。したがって、これらのデータセットを効率的かつ分散的に処理するには、大規模なデータ処理フレームワークが必要です。 ML モデルを使用して予測を行う場合は、トレーニング データに使用したのと同じ変換を新しいデータ ポイントに適用する必要があります。同じ変換を適用することで、モデルが期待する方法でライブ データセットを ML モデルに提示できます。
このドキュメントでは、特徴量エンジニアリング操作のさまざまな粒度レベル (インスタンス レベル、フルパス、およびタイム ウィンドウの集約) に関するこれらの課題について説明します。このドキュメントでは、Google Cloud で ML のデータ変換を実行するためのオプションとシナリオについても説明します。
このドキュメントでは、データ前処理パイプラインを通じてインスタンス レベルとフルパスのデータ変換の両方を定義できる TensorFlow のライブラリであるTensorFlow Transform ( tf.Transform ) の概要も提供します。これらのパイプラインはApache Beamで実行され、モデルの提供時と同じ変換を予測中に適用できるようにするアーティファクトを作成します。
ML 用のデータの前処理
このセクションでは、データの前処理操作とデータ準備の段階について紹介します。また、前処理操作の種類とその粒度についても説明します。
データ エンジニアリングと特徴量エンジニアリングの比較
ML 用のデータの前処理には、データ エンジニアリングと特徴エンジニアリングの両方が含まれます。データ エンジニアリングは、生のデータを準備されたデータに変換するプロセスです。次に、特徴エンジニアリングにより、準備されたデータが調整されて、ML モデルで期待される特徴が作成されます。これらの用語には次の意味があります。
- 生データ(または単なるデータ)
- ML 用の事前準備を行わない、ソース形式のデータ。このコンテキストでは、データは生の形式 (データ レイク内) または変換された形式 (データ ウェアハウス内) である可能性があります。データ ウェアハウス内にある変換されたデータは、分析に使用するために元の生の形式から変換されている可能性があります。ただし、この文脈では、生データは、データが ML タスク用に特別に準備されていないことを意味します。データが、最終的に予測のために ML モデルを呼び出すストリーミング システムから送信された場合も、生データとみなされます。
- 用意したデータ
- ML タスクの準備が整った形式のデータセット: データ ソースが解析され、結合され、表形式に変換されています。準備されたデータは適切な粒度で集約され、要約されます。たとえば、データセットの各行は一意の顧客を表し、各列は過去 6 週間の支出合計など、顧客の概要情報を表します。準備されたデータ テーブルでは、無関係な列が削除され、無効なレコードがフィルターで除外されています。教師あり学習タスクの場合、ターゲット特徴が存在します。
- 設計された機能
- モデルで期待される調整された特徴を含むデータセット。つまり、後で説明するように、準備されたデータセット内の列に対して特定の ML 固有の操作を実行し、トレーニングと予測中にモデルの新しい特徴を作成することによって作成される特徴です。前処理操作で。これらの操作の例には、数値列を 0 から 1 の間の値にスケーリングすること、値をクリッピングすること、およびカテゴリ特徴量のワンホット エンコーディングが含まれます。
次の図 (図 1) は、前処理されたデータの準備に含まれる手順を示しています。
実際には、同じソースからのデータが異なる準備段階にあることがよくあります。たとえば、データ ウェアハウス内のテーブルのフィールドは、エンジニアリング機能として直接使用される場合があります。同時に、同じテーブル内の別のフィールドは、エンジニアリング フィーチャになる前に変換が必要になる場合があります。同様に、データ エンジニアリングと特徴エンジニアリングの操作を同じデータ前処理ステップで組み合わせることができます。
前処理操作
データの前処理にはいくつかの操作が含まれます。各操作は、ML がより優れた予測モデルを構築できるように設計されています。これらの前処理操作の詳細はこのドキュメントの範囲外ですが、このセクションではいくつかの操作について簡単に説明します。
構造化データの場合、データ前処理操作には次のものが含まれます。
- データ クレンジング:破損した値または無効な値を持つレコードを生データから削除または修正し、多数の列が欠落しているレコードを削除します。
- インスタンスの選択と分割:入力データセットからデータ ポイントを選択して、トレーニング、評価 (検証)、およびテスト セットを作成します。このプロセスには、反復可能なランダム サンプリング、少数派クラスのオーバーサンプリング、層別分割の手法が含まれます。
- 特徴量の調整: ML の特徴量の品質を改善します。これには、数値のスケーリングと正規化、欠損値の代入、外れ値のクリッピング、分布の偏った値の調整が含まれます。
- 特徴変換:数値特徴をカテゴリ特徴に変換 (バケット化を通じて)、およびカテゴリ特徴を数値表現に変換 (ワンホット エンコーディング、カウントによる学習、スパース特徴埋め込みなどを通じて)。一部のモデルは数値またはカテゴリの特徴でのみ機能しますが、他のモデルは混合タイプの特徴を処理できます。モデルが両方のタイプを処理する場合でも、同じ特徴の異なる表現 (数値とカテゴリ) から恩恵を受けることができます。
- 特徴抽出: PCA 、埋め込み抽出、ハッシュなどの手法を使用して、低次元のより強力なデータ表現を作成することにより、特徴の数を削減します。
- 特徴の選択:フィルターまたはラッパー メソッドを使用して、モデルをトレーニングするための入力特徴のサブセットを選択し、無関係または冗長なものを無視します。特徴の選択には、特徴に多数の値が欠落している場合に単純に特徴を削除することも含まれます。
- 特徴の構築:多項式展開 (一変量数学関数を使用) や特徴交差(特徴の相互作用を捕捉するため) などの一般的な手法を使用して新しい特徴を作成します。 ML ユースケースのドメインのビジネス ロジックを使用して機能を構築することもできます。
非構造化データ (画像、音声、テキスト ドキュメントなど) を扱う場合、ディープ ラーニングはモデル アーキテクチャに組み込むことで、ドメイン知識ベースの特徴エンジニアリングを置き換えます。畳み込み層は、自動特徴プリプロセッサです。適切なモデル アーキテクチャを構築するには、データに関する経験的な知識が必要です。さらに、次のようなある程度の前処理が必要です。
- テキスト文書の場合:ステミングと見出し語化、 TF-IDF計算、 N グラム抽出、埋め込み検索。
- 画像の場合: クリッピング、サイズ変更、トリミング、ガウスぼかし、カナリア フィルター。
- すべてのタイプのデータ (テキストや画像を含む):転移学習。完全にトレーニングされたモデルの最後の層を除くすべての層を特徴量エンジニアリングのステップとして扱います。
前処理の粒度
このセクションでは、データ変換の種類の粒度について説明します。これは、トレーニング データに適用される変換を使用して予測用の新しいデータ ポイントを準備するときに、この観点が重要である理由を示しています。
前処理と変換の操作は、操作の粒度に基づいて次のように分類できます。
トレーニングおよび予測中のインスタンスレベルの変換。これらは単純な変換であり、変換には同じインスタンスの値のみが必要です。たとえば、インスタンス レベルの変換には、ある特徴の値を何らかのしきい値にクリップすること、別の特徴を多項式に拡張すること、2 つの特徴を乗算すること、または 2 つの特徴を比較してブール フラグを作成することが含まれる場合があります。
モデルは生の入力値ではなく、変換された特徴に基づいてトレーニングされるため、これらの変換はトレーニング中と予測中に同じように適用する必要があります。データが同一に変換されない場合、トレーニングされていない値の分布を持つデータがモデルに提示されるため、モデルの動作が低下します。詳細については、 「前処理の課題」セクションのトレーニングとサービングのスキューに関する説明を参照してください。
トレーニング中はフルパス変換ですが、予測中はインスタンス レベルの変換です。このシナリオでは、事前に計算された統計を使用して変換を実行するため、変換はステートフルになります。トレーニング中に、トレーニング データ全体を分析して、トレーニング データ、評価データ、予測時の新しいデータを変換するための最小値、最大値、平均、分散などの量を計算します。
たとえば、トレーニング用に数値特徴を正規化するには、トレーニング データ全体にわたってその平均 (μ) と標準偏差 (σ) を計算します。この計算はフルパス(または分析) 操作と呼ばれます。予測用にモデルを提供するとき、新しいデータ ポイントの値は、トレーニングと提供のスキューを避けるために正規化されます。したがって、トレーニング中に計算される μ 値と σ 値は、次のような単純なインスタンス レベルの操作である特徴値の調整に使用されます。
$$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$フルパス変換には次のものが含まれます。
- MinMax は、トレーニング データセットから計算された最小値と最大値を使用して数値特徴をスケーリングします。
- トレーニング データセットで計算された μ と σ を使用した標準スケーリング (Z スコア正規化) 数値特徴。
- 分位数を使用した数値特徴のバケット化。
- 中央値 (数値特徴) または最頻値 (カテゴリ特徴) を使用して欠損値を代入します。
- 入力カテゴリ特徴量のすべての個別の値 (語彙) を抽出することにより、文字列 (公称値) を整数 (インデックス) に変換します。
- すべての文書（インスタンス）内の用語（特徴量）の出現をカウントし、TF-IDF を計算します。
- 入力フィーチャの PCA を計算して、データを低次元空間に投影します (線形依存フィーチャを使用)。
μ、σ、 min 、 maxなどの統計量を計算するには、トレーニング データのみを使用する必要があります。これらの操作のテスト データと評価データを追加すると、モデルをトレーニングするために評価データとテスト データから情報が漏洩することになります。テストや評価結果の信頼性に影響します。すべてのデータセットに一貫した変換を確実に適用するには、トレーニング データから計算された同じ統計を使用して、テスト データと評価データを変換します。
トレーニングおよび予測中の履歴集計。これには、予測タスクへの入力信号としてビジネスの集計、派生、およびフラグを作成することが含まれます。たとえば、顧客が傾向モデルを構築するための最新性、頻度、金額 (RFM)メトリクスを作成します。これらのタイプの特徴は、モデルのトレーニング、バッチ スコアリング、およびオンライン予測の提供中に使用するために、事前計算して特徴ストアに保存できます。トレーニングや予測の前に、これらの集計に対して追加の特徴エンジニアリング (変換や調整など) を実行することもできます。
トレーニング中は履歴集計ですが、予測中はリアルタイム集計です。このアプローチには、時間の経過に伴うリアルタイム値を要約することによって特徴を作成することが含まれます。このアプローチでは、集約されるインスタンスは時間ウィンドウ句を通じて定義されます。たとえば、過去 5 分間、過去 10 分間、過去 30 分間などのルートの交通メトリックに基づいてタクシーの移動時間を推定するモデルをトレーニングする場合、このアプローチを使用できます。間隔。このアプローチを使用して、過去 3 分間に計算された温度と振動の値の移動平均に基づいてエンジン部品の故障を予測することもできます。これらの集計はトレーニング用にオフラインで準備できますが、提供中にデータ ストリームからリアルタイムで計算されます。
より正確には、トレーニング データを準備するときに、集計された値が生データにない場合、その値はデータ エンジニアリング フェーズで作成されます。生データは通常、
(entity, timestamp, value)の形式でデータベースに保存されます。前の例では、entityはタクシー ルートのルート セグメント識別子、およびエンジン故障のエンジン部品識別子です。ウィンドウ操作を使用して(entity, time_index, aggregated_value_over_time_window)を計算し、モデル トレーニングの入力として集計機能を使用できます。リアルタイム (オンライン) 予測のモデルが提供される場合、モデルは入力として集計された値から導出される特徴を期待します。したがって、Apache Beam などのストリーム処理テクノロジを使用して、システムにストリーミングされたリアルタイム データ ポイントから集計を計算できます。ストリーム処理テクノロジーは、新しいデータ ポイントが到着すると、時間枠に基づいてリアルタイム データを集約します。トレーニングや予測の前に、これらの集計に対して追加の特徴エンジニアリング (変換や調整など) を実行することもできます。
Google Cloud 上の ML パイプライン
このセクションでは、マネージド サービスを使用して Google Cloud 上で TensorFlow ML モデルをトレーニングし、提供するための一般的なエンドツーエンド パイプラインのコア コンポーネントについて説明します。また、さまざまなカテゴリのデータ前処理操作を実装できる場所と、そのような変換を実装するときに直面する可能性のある一般的な課題についても説明します。 「tf.Transform の仕組み」セクションでは、TensorFlow Transform ライブラリがこれらの課題の解決にどのように役立つかを示します。
高レベルのアーキテクチャ
次の図 (図 2) は、TensorFlow モデルをトレーニングおよび提供するための典型的な ML パイプラインの高レベル アーキテクチャを示しています。図内のラベル A、B、および C は、データの前処理が行われるパイプライン内のさまざまな場所を指します。これらの手順の詳細については、次のセクションで説明します。
パイプラインは次のステップで構成されます。
- 未加工データがインポートされた後、表形式のデータは BigQuery に保存され、画像、音声、動画などのその他のデータは Cloud Storage に保存されます。このシリーズの第 2 部では、例として BigQuery に保存されている表形式のデータを使用します。
- データ エンジニアリング (準備) と特徴量エンジニアリングは、Dataflow を使用して大規模に実行されます。この実行により、ML 対応のトレーニング、評価、テスト セットが生成され、Cloud Storage に保存されます。理想的には、これらのデータセットは、TensorFlow 計算に最適化された形式であるTFRecordファイルとして保存されます。
- TensorFlow モデルトレーナー パッケージはVertex AI Training に送信され、前のステップで前処理されたデータを使用してモデルをトレーニングします。このステップの出力は、Cloud Storage にエクスポートされるトレーニング済みの TensorFlow SavedModelです。
- トレーニングされた TensorFlow モデルは、REST API を備えたサービスとして Vertex AI Prediction にデプロイされ、オンライン予測に使用できるようになります。同じモデルをバッチ予測ジョブにも使用できます。
- モデルが REST API としてデプロイされた後、クライアント アプリと内部システムは、いくつかのデータ ポイントを含むリクエストを送信し、予測を含むモデルからの応答を受信することにより、API を呼び出すことができます。
- このパイプラインをオーケストレーションおよび自動化するには、 Vertex AI Pipelines をスケジューラーとして使用し、データの準備、モデルのトレーニング、モデルのデプロイのステップを呼び出すことができます。
Vertex AI Feature Store を使用して、予測を行うための入力フィーチャを保存することもできます。たとえば、最新の生データからエンジニアリング フィーチャを定期的に作成し、Vertex AI Feature Store に保存できます。クライアント アプリは、必要な入力特徴を Vertex AI Feature Store から取得し、モデルに送信して予測を受け取ります。
前処理を行う場所
図 2 のラベル A、B、C は、データ前処理オペレーションが BigQuery、Dataflow、または TensorFlow で実行できることを示しています。次のセクションでは、これらの各オプションがどのように機能するかについて説明します。
オプション A: BigQuery
通常、ロジックは次の操作のために BigQuery に実装されます。
- サンプリング: データからサブセットをランダムに選択します。
- フィルタリング: 無関係または無効なインスタンスを削除します。
- パーティショニング: データを分割して、トレーニング、評価、およびテスト セットを作成します。
BigQuery SQL スクリプトは、Dataflow 前処理パイプラインのソース クエリとして使用できます。これは、図 2 のデータ処理ステップです。たとえば、システムがカナダで使用されており、データ ウェアハウスに世界中からのトランザクションがある場合、カナダのみのトレーニング データを取得するには、BigQuery を使用するのが最適です。 BigQuery の特徴エンジニアリングはシンプルかつスケーラブルで、インスタンス レベルおよび履歴集計の特徴変換の実装をサポートします。
ただし、モデルをバッチ予測 (スコアリング) に使用する場合、または特徴が BigQuery で事前計算されているが、オンライン予測中に使用するために Vertex AI Feature Store に保存されている場合にのみ、特徴エンジニアリングに BigQuery を使用することをお勧めします。オンライン予測用にモデルをデプロイする予定で、オンライン特徴ストアにエンジニアリングされた特徴がない場合は、SQL 前処理操作を複製して、他のシステムが生成する生データ ポイントを変換する必要があります。つまり、ロジックを 2 回実装する必要があります。1 回目は SQL で BigQuery のトレーニング データを前処理し、2 回目はモデルを使用するアプリのロジックで予測用のオンライン データポイントを前処理します。
たとえば、クライアント アプリが Java で記述されている場合は、ロジックを Java で再実装する必要があります。これにより、このドキュメントの後半の前処理の課題のトレーニングとサービングのスキューのセクションで説明されているように、実装の不一致によるエラーが発生する可能性があります。また、2 つの異なる実装を維持するための余分なオーバーヘッドも発生します。トレーニング データを前処理するために SQL のロジックを変更するときは常に、提供時にデータを前処理するように Java 実装を変更する必要があります。
モデルをバッチ予測のみに使用しており（たとえば、 Vertex AIバッチ予測を使用）、スコアリング用のデータが BigQuery から供給されている場合は、これらの前処理オペレーションを BigQuery SQL スクリプトの一部として実装できます。その場合、同じ前処理 SQL スクリプトを使用して、トレーニング データとスコアリング データの両方を準備できます。
フルパス ステートフル変換は、BigQuery での実装には適していません。フルパス変換に BigQuery を使用する場合は、数値特徴をスケーリングするための平均や分散など、ステートフル変換に必要な量を保存するための補助テーブルが必要です。さらに、BigQuery で SQL を使用したフルパス変換を実装すると、SQL スクリプトの複雑さが増し、トレーニングとスコアリング SQL スクリプトの間に複雑な依存関係が生じます。
オプション B: データフロー
図 2 に示すように、計算コストのかかる前処理操作を Apache Beam に実装し、Dataflow を使用して大規模に実行できます。 Dataflow は、バッチおよびストリーム データ処理のためのフルマネージド自動スケーリング サービスです。 Dataflow を使用する場合、BigQuery とは異なり、データ処理に外部の特殊なライブラリを使用することもできます。
Dataflow は、インスタンス レベルの変換、および履歴およびリアルタイムの集計機能の変換を実行できます。特に、ML モデルがtotal_number_of_clicks_last_90secのような入力特徴を予期している場合、Apache Beamウィンドウ関数は、リアルタイム (ストリーミング) イベント データ (クリック イベントなど) のタイム ウィンドウの値の集計に基づいてこれらの特徴を計算できます。変換の粒度に関する前述の説明では、これは「トレーニング中は履歴集計、予測中はリアルタイム集計」と呼ばれていました。
次の図 (図 3) は、ほぼリアルタイムの予測のためにストリーム データを処理する際の Dataflow の役割を示しています。
図 3 に示すように、処理中に、データ ポイントと呼ばれるイベントがPub/Subに取り込まれます。 Dataflow はこれらのデータ ポイントを消費し、長期にわたる集計に基づいて特徴を計算し、予測のためにデプロイされた ML モデル API を呼び出します。その後、予測は送信 Pub/Sub キューに送信されます。 Pub/Sub から、予測は監視や制御などの下流システムで使用することも、元の要求側クライアントに (通知などとして) プッシュバックすることもできます。予測は、リアルタイムで取得するためにCloud Bigtableのような低レイテンシのデータ ストアに保存することもできます。 Cloud Bigtable を使用して、これらのリアルタイム集計を蓄積して保存し、予測に必要なときに検索できるようにすることもできます。
同じ Apache Beam 実装を使用して、BigQuery などのオフライン データストアから取得したトレーニング データをバッチ処理したり、オンライン予測を提供するためにリアルタイム データをストリーム処理したりできます。
図 2 に示すアーキテクチャなど、他の一般的なアーキテクチャでは、クライアント アプリはオンライン予測のためにデプロイされたモデル API を直接呼び出します。その場合、トレーニング データを準備するために前処理オペレーションが Dataflow に実装されている場合、そのオペレーションはモデルに直接送信される予測データには適用されません。したがって、このような変換は、オンライン予測の提供中にモデルに統合する必要があります。
データフローを使用すると、必要な統計を大規模に計算することにより、フルパス変換を実行できます。ただし、これらの統計は、予測中に予測データ ポイントを変換するために使用できるようにどこかに保存する必要があります。 TensorFlow Transform ( tf.Transform ) ライブラリを使用すると、これらの統計を他の場所に保存するのではなく、モデルに直接埋め込むことができます。このアプローチについては、 「 tf.Transform の仕組み 」で後述します。
オプション C: TensorFlow
図 2 に示すように、TensorFlow モデル自体にデータの前処理と変換操作を実装できます。図に示すように、TensorFlow モデルをトレーニングするために実装する前処理は、モデルが予測用にエクスポートおよびデプロイされるときに、モデルの不可欠な部分になります。 TensorFlow モデルの変換は、次のいずれかの方法で実行できます。
-
input_fn関数とserving_fn関数にインスタンス レベルの変換ロジックをすべて実装します。input_fn関数は、モデルをトレーニングするためにtf.data.DatasetAPIを使用してデータセットを準備します。serving_fn関数は、予測用のデータを受信して準備します。 - Keras 前処理レイヤーを使用するかカスタムレイヤーを作成することにより、変換コードを TensorFlow モデルに直接配置します。
serving_fn関数の変換ロジック コードは、オンライン予測用の SavedModel のサービス インターフェイスを定義します。トレーニング データの準備に使用したものと同じ変換を、 serving_fn関数の変換ロジック コードに実装すると、新しい予測データ ポイントが提供されるときに、同じ変換が確実に適用されます。
ただし、TensorFlow モデルは各データ ポイントを独立して処理するか、小さなバッチで処理するため、すべてのデータ ポイントから集計を計算することはできません。結果として、フルパス変換を TensorFlow モデルに実装することはできません。
前処理の課題
データ前処理の実装における主な課題は次のとおりです。
トレーニングとサービスのスキュー。トレーニングとサービングのスキューとは、トレーニング中とサーブ中の有効性 (予測パフォーマンス) の差を指します。この偏りは、トレーニング パイプラインとサービス パイプラインでのデータの処理方法の不一致によって発生する可能性があります。たとえば、モデルが対数変換されたフィーチャでトレーニングされていても、提供中に生のフィーチャが表示される場合、予測出力は正確ではない可能性があります。
変換がモデル自体の一部になる場合は、オプション C: TensorFlowで前述したように、インスタンス レベルの変換を簡単に処理できます。その場合、モデル提供インターフェイス (
serving_fn関数) は生データを期待しますが、モデルは出力を計算する前にこのデータを内部的に変換します。変換は、生のトレーニングおよび予測データ ポイントに適用されたものと同じです。フルパス変換。 TensorFlow モデルでは、スケーリングや正規化変換などのフルパス変換を実装することはできません。フルパス変換では、 「オプション B: データフロー」で説明されているように、一部の統計 (たとえば、数値特徴をスケーリングするための
max値とmin値) をトレーニング データに対して事前に計算する必要があります。この値は、新しい生データ ポイントをインスタンス レベルの変換として変換するための予測のためのモデルの提供中に使用できる場所に保存する必要があります。これにより、トレーニングと提供のスキューが回避されます。 TensorFlow Transform (tf.Transform) ライブラリを使用して、統計を TensorFlow モデルに直接埋め込むことができます。このアプローチについては、 「 tf.Transform の仕組み 」で後述します。トレーニングの効率を高めるために、事前にデータを準備します。インスタンスレベルの変換をモデルの一部として実装すると、トレーニング プロセスの効率が低下する可能性があります。この劣化は、各エポックで同じトレーニング データに同じ変換が繰り返し適用されるために発生します。 1,000 個の特徴を含む生のトレーニング データがあり、インスタンス レベルの変換を組み合わせて適用して 10,000 個の特徴を生成すると想像してください。これらの変換をモデルの一部として実装し、生のトレーニング データをモデルに供給すると、これらの 10,000 の操作が各インスタンスにN回適用されます ( Nはエポック数)。さらに、アクセラレータ (GPU または TPU) を使用している場合、CPU が変換を実行している間アクセラレータはアイドル状態になります。これは、高価なアクセラレータの効率的な使用法ではありません。
理想的には、オプション B: データフローで説明されている手法を使用して、トレーニング前にトレーニング データが変換されます。この手法では、10,000 の変換操作が各トレーニング インスタンスに 1 回だけ適用されます。次に、変換されたトレーニング データがモデルに提示されます。それ以上の変換は適用されず、アクセラレータは常にビジー状態になります。さらに、Dataflow を使用すると、フルマネージド サービスを使用して大量のデータを大規模に前処理することができます。
トレーニング データを事前に準備すると、トレーニングの効率が向上します。ただし、モデルの外部に変換ロジックを実装しても (オプション A: BigQueryまたはオプション B: Dataflowで説明されているアプローチ)、トレーニングとサービングのスキューの問題は解決されません。トレーニングと予測の両方に使用するためにエンジニアリングされた特徴を特徴ストアに保存しない限り、モデル インターフェイスは変換されたデータを想定しているため、予測のために来る新しいデータ ポイントに適用される変換ロジックをどこかに実装する必要があります。次のセクションで説明するように、TensorFlow Transform (
tf.Transform) ライブラリは、この問題の解決に役立ちます。
tf.Transform の仕組み
tf.Transformライブラリは、完全なパスを必要とする変換に役立ちます。 tf.Transformライブラリの出力は、インスタンス レベルの変換ロジックとフルパス変換から計算された統計を表す TensorFlow グラフとしてエクスポートされ、トレーニングとサービスに使用されます。トレーニングとサービスの両方に同じグラフを使用すると、両方の段階で同じ変換が適用されるため、スキューを防ぐことができます。さらに、 tf.Transformライブラリは、Dataflow 上のバッチ処理パイプラインで大規模に実行して、トレーニング データを事前に準備し、トレーニング効率を向上させることができます。
次の図 (図 4) は、 tf.Transformライブラリがトレーニングと予測のためにデータを前処理および変換する方法を示しています。このプロセスについては、次のセクションで説明します。
tf.Transformの動作。 トレーニングおよび評価データを変換する
tf.Transform Apache Beam API に実装された変換を使用して生のトレーニング データを前処理し、Dataflow 上で大規模に実行します。前処理は次のフェーズで行われます。
- 分析フェーズ:分析フェーズでは、ステートフル変換に必要な統計 (平均、分散、分位数など) がフルパス操作を使用してトレーニング データに対して計算されます。このフェーズでは、
transform_fnグラフを含む一連の変換アーティファクトが生成されます。transform_fnグラフは、インスタンス レベルの操作として変換ロジックを持つ TensorFlow グラフです。これには、分析フェーズで計算された統計が定数として含まれます。 - 変換フェーズ:変換フェーズでは、
transform_fnグラフが生のトレーニング データに適用され、計算された統計情報がインスタンス レベルの方法でデータ レコードを処理する (数値列のスケール変更など) ために使用されます。
このような 2 フェーズのアプローチは、フルパス変換を実行するという前処理の課題に対処します。
評価データが前処理されるときは、 transform_fnグラフのロジックとトレーニング データの分析フェーズから計算された統計を使用して、インスタンス レベルの操作のみが適用されます。つまり、評価データをフルパス方式で分析して、μ や σ などの新しい統計を計算して、評価データの数値特徴を正規化するわけではありません。代わりに、トレーニング データから計算された統計を使用して、インスタンス レベルの方法で評価データを変換します。
変換されたトレーニング データと評価データは、モデルのトレーニングに使用される前に、Dataflow を使用して大規模に準備されます。このバッチデータ準備プロセスは、トレーニング効率を改善するためにデータを前もって準備するという前処理の課題に対処します。図4に示すように、モデル内部インターフェイスは変換された機能を期待しています。
エクスポートされたモデルに変換を取り付けます
前述のように、 tf.Transformパイプラインによって生成されるtransform_fnグラフは、エクスポートされたTensorFlowグラフとして保存されます。エクスポートされたグラフは、インスタンスレベルの操作としての変換ロジックと、フルパス変換でグラフ定数として計算されたすべての統計で構成されています。訓練されたモデルがサービングのためにエクスポートされると、 transform_fnグラフは、そのserving_fn関数の一部としてsavedmodelに接続されます。
予測のためにモデルを提供している間、モデルサービングインターフェイスは、生形態のデータポイント（つまり、変換の前）を期待しています。ただし、モデル内部インターフェイスは、変換された形式のデータを期待しています。
現在、モデルの一部になっているtransform_fnグラフは、着信データポイントにすべての前処理ロジックを適用します。予測中にインスタンスレベルの操作で、保存された定数（μやσなどの数値の特徴を正規化する）を使用します。したがって、 transform_fnグラフは、生データポイントを変換された形式に変換します。図4に示すように、変換された形式は、予測を生成するためにモデル内部インターフェイスによって予想されるものです。
このメカニズムは、トレーニングと評価データを変換するために使用される同じロジック（実装）が予測中に新しいデータポイントを変換するために使用されるため、トレーニングを介したスキューの前処理課題を解決します。
前処理オプションの概要
次の表は、このドキュメントが説明したデータの前処理オプションをまとめたものです。テーブルでは、「n/a」は「該当なし」の略です。
| データプリプセッシングオプション | インスタンスレベル （ステートレス変換） | トレーニング中のフルパスとサービング中のインスタンスレベル（ステートフル変換） | トレーニングとサービング中のリアルタイム（ウィンドウ）集約（ストリーミング変換） |
|---|---|---|---|
BigQuery （SQL） | バッチスコアリング：OK - トレーニング中およびバッチスコアリング中のデータに同じ変換の実装が適用されます。 オンラインの予測：推奨されません- トレーニングデータを処理できますが、さまざまなツールを使用してデータを提供するため、トレーニングを提供するスキューが発生します。 | バッチスコアリング：お勧めしません。 オンライン予測：推奨されません。 たとえばレベルのバッチ/オンライン変換のためにBigQueryを使用して計算された統計を使用できますが、トレーニング中に統計ストアを維持し、予測中に使用する必要はありません。 | バッチスコアリング：n/a - このような集合体は、リアルタイムイベントに基づいて計算されます。 オンラインの予測：推奨されません- トレーニングデータを処理できますが、さまざまなツールを使用してデータを提供するため、トレーニングを提供するスキューが発生します。 |
データフロー（Apacheビーム） | バッチスコアリング：OK - トレーニング中およびバッチスコアリング中のデータに同じ変換の実装が適用されます。 オンライン予測：OK - サービング時間のデータがPub/Subからデータフローによって消費される場合。それ以外の場合は、トレーニングを介したスキューになります。 | バッチスコアリング：お勧めしません。 オンライン予測：推奨されません。 データフローを使用して計算された統計を使用して、例えばレベルのバッチ/オンライン変換を使用できますが、トレーニング中に統計ストアを維持し、予測中に使用する必要はありません。 | バッチスコアリング：n/a - このような集合体は、リアルタイムイベントに基づいて計算されます。 オンライン予測：OK - 同じApacheビーム変換がトレーニング中（バッチ）およびサービング（ストリーム）中にデータに適用されます。 |
データフロー（Apacheビーム + TFT） | バッチスコアリング：OK - 同じ変換の実装がトレーニングとバッチスコアリング中にデータに適用されます。 オンラインの予測：推奨- トレーニングを介したスキューを回避し、トレーニングデータを前もって準備します。 | バッチスコアリング：推奨。 オンライン予測：推奨。 トレーニング中の変換ロジックと計算された統計は、サービングのためにエクスポートされたモデルに添付されたTensorflowグラフとして保存されるため、両方の用途が推奨されます。 | バッチスコアリング：n/a - このような集合体は、リアルタイムイベントに基づいて計算されます。 オンライン予測：OK - 同じApacheビーム変換がトレーニング中（バッチ）およびサービング（ストリーム）中にデータに適用されます。 |
Tensorflow * | バッチスコアリング：お勧めしません。 オンライン予測：推奨されません。 どちらの場合もトレーニング効率を得るには、トレーニングデータを前もって準備することをお勧めします。 | バッチスコアリング：不可能です。 オンライン予測：不可能です。 | バッチスコアリング：n/a - このような集合体は、リアルタイムイベントに基づいて計算されます。 オンライン予測：不可能です。 |
* Tensorflowを使用すると、交差、埋め込み、1ホットのエンコードなどの変換をfeature_columns列として宣言的に実行する必要があります。
次は何ですか
tf.Transformパイプラインを実装してデータフローを使用して実行するには、このシリーズのパート2、 Tensorflow変換を使用してMLのデータ前処理を読みます。- Google CloudのTensorflowを使用して、MLでCourseraの専門化を行います。
- MLのルールにおけるMLエンジニアリングのベストプラクティスについて学びます。
- 参照アーキテクチャ、図、およびベストプラクティスについては、 TFXクラウドソリューションを調べてください。