ML のためのデータ前処理: オプションと推奨事項

このドキュメントは、教師あり学習タスクに焦点を当てて、機械学習（ML）のデータエンジニアリングと特徴量エンジニアリングのトピックについて説明する 2 部構成の記事の最初のドキュメントです。このパート 1 では、Google Cloud の ML パイプラインでデータを前処理するためのベストプラクティスについて説明します。このドキュメントでは、TensorFlow とオープンソースの TensorFlow Transform{: target="github" class="external" track-type="solution" track-name="gitHubLink" track-metadata-position="body" }（tf.Transform）ライブラリを使用してデータを準備し、モデルをトレーニングし、予測のためにモデルを提供することに焦点を当てています。このドキュメントでは、ML 向けにデータを前処理する際の課題に焦点を当て、Google Cloud でデータ変換を効果的に実行するためのオプションとシナリオを示します。

このドキュメントでは、BigQuery{: .external }、Dataflow{: .external }、Vertex AI{: .external }、および TensorFlow Keras API に精通していることを前提としています。

パート 2 の Google Cloud によるデータ前処理では、tf.Transform パイプラインを実装する方法をステップバイステップ方式のチュートリアルで説明しています。

はじめに

ML は、データ内の複雑で潜在的に有用なパターンを自動的に見つけ出すのに役立ちます。これらのパターンは ML モデルで考慮され、新しいデータポイントに使用されます。予測や推論と呼ばれるプロセスです。

ML モデルの構築はマルチステップのプロセスです。各ステップには特有の技術的・概念的な課題があります。この 2 部構成の連載記事では、教師あり学習タスクと、ソースデータの選択、変換、拡張を行って、ターゲット変数に対する強力な予測シグナルを作成することに焦点を当てています。これらの演算は、ドメインの知識とデータサイエンスの手法を組み合わせたものです。演算は、特徴量エンジニアリング{: .external }に欠かせません。

実用できな ML モデル用のトレーニングデータセットのサイズは、1 テラバイト（TB）を簡単に超えます。したがって、これらのデータセットを効率的かつ分散的に処理するには、大規模なデータ処理フレームワークが必要となります。ML モデルを使用して予測を立てる場合、トレーニングデータに使用した変換を新しいデータポイントに適用しなければなりません。同じ変換を適用することで、モデルが期待する方法で、ライブデータセットを ML モデルに示します。

このドキュメントでは、インスタンスレベル、フルパス、時間枠の集計といった、様々な粒度の特徴量エンジニアリングに係るこういった課題について説明しています。また、Google Cloud で ML のデータ変換を行うためのオプションとシナリオについても説明しています。

このドキュメントでは、データ前処理パイプラインを通じてインスタンスレベルとフルパスでのデータ変換を行えるようにする TensorFlow Transform{: .external }（tf.Transform）ライブラリの概要も説明しています。これらのパイプラインは、Apache Beam{: .external } で実行され、予測中に、モデルが提供されるときと同じ変換を適用できるようにするアーティファクトを作成します。

ML 用のデータの前処理

このセクションでは、データ前処理演算とデータレディネスのステージについて説明します。また、前処理演算のタイプとその粒度についても説明します。

データエンジニアリングと特徴量エンジニアリングの比較

ML 用のデータの前処理には、データエンジニアリングと特徴量エンジニアリングの両方が伴います。データエンジニアリングは未加工のデータを準備済みのデータに変換するプロセスです。特徴量エンジニアリングは、その後で、ML モデルが期待する特徴量を作成できるように、準備済みのデータを調整するプロセスです。これらの用語には以下の意味があります。

未加工のデータ（または、単にデータ）: このデータはソースの形態であり、ML 向けの事前の準備作業がありません。このコンテキストにおいて、データは未加工の状態（データレイク）または変換済みの状態（データウェアハウス）です。データウェアハウスにある変換済みのデータは元の未加工の状態から分析に使用できる形態に変換されている場合があります。ただし、このコンテキストにおいて、未加工のデータとは、データが ML タスク用に具体的に準備されていないことを指します。最終的に ML モデルを呼び出して予測を行うストリーミングシステムのデータも未加工のデータと見なされます。

準備済みのデータ: ML タスクでの使用準備が整っている形態のデータセットです。つまり、データソースの解析、結合、および表形式への変換が完了しています。準備済みのデータは集計され、適度な粒度にまとめられています。たとえば、データセットの各行は一意の顧客を表し、各列は、過去 6　週間の合計支出額といった顧客のサマリー情報を表します。準備済みのデータテーブルでは、無関係な列がドロップされており、無効なレコードが除外されています。教師あり学習タスクの場合は、ターゲット特徴量が存在します。

エンジニアリング済みの特徴量: モデルが期待する調整済みの特徴量を持つデータセット。つまり、特定の ML 特有の演算を準備済みデータセットに実行し、トレーニングと予測の過程でモデルの新しい特徴量を作成することで作成された特徴量です。これについては、後の前処理演算で説明しています。これらの演算の例には、数値カラムの値の 0 から 1 の間でのスケーリング、値のクリッピング、カテゴリカル特徴量のOne-Hot エンコーディング{: .external }などがあります。

以下の図 1 のダイアグラムは、前処理データの準備に伴うステップを示します。

実際には、同じソースのデータは通常、異なるレディネスのステージにあります。たとえば、データウェアハウスのテーブルのフィールドは、エンジニアリング済みの特徴量として直接使用することが可能です。同時に、同じテーブルの別のフィールドでは、エンジニアリング済みの特徴量となるまでに変換を行わなければならない場合があります。同様に、データエンジニアリングと特徴量エンジニアリングの演算を、同じデータ前処理ステップに合わせることも可能です。

前処理演算

データの前処理には、いくつかの演算が含まれます。各演算は、ML がより優れた予測モデルを構築できるように設計されています。これらの前処理演算の詳細についてはこのドキュメントでは触れませんが、一部の演算においてはこのセクションで簡単に説明しています。

構造化データの前処理演算には、以下の内容が含まれます。

• データクレンジング: 未加工のデータから、破損または無効な値を含むレコードを除去するかそれらを修正し、多数の列が欠落しているレコードを除去します。

• インスタンスの選択と分割: 入力データセットからデータポイントを選択し、トレーニングセット、評価（検証）セット、およびテストセット{: .external }を作成します。このプロセスには、繰り返し可能なランダムサンプリング、少数派クラスのオーバーサンプリング、および階層分割の手法が含まれます。

• 特徴量のチューニング: 特徴量の品質を ML 向けに改善します。これには、数値のスケーリングと正規化、欠損値の補完、外れ値のクリッピング、偏った分布を持つ値の調整が含まれます。

• 特徴量の変換: 数値特徴量からカテゴリカル特徴量への変換（バケット化{: .external }）と、カテゴリカル特徴量から数値表現への変換（One-Hot エンコーディング、カウントによる学習{: .external }、スパース特徴量の埋め込みなど）を行います。数値またはカテゴリカル特徴量でしか動作しないモデルもあれば、型が混合する特徴量を処理できるモデルもあります。モデルが両方の型を処理できる場合であっても、同じ特徴量の異なる表現（数値とカテゴリカル）からメリットを得ることができます。

• 特徴量の抽出: PCA{: .external }、埋め込み{: .external }抽出、ハッシュ化{: .external }などの手法を使って、より低次元でより強力なデータ表現を作成することで、特徴量の数を減らします。

• 特徴量の選択: モデルをトレーニングするために、フィルタやラッパーメソッド{: .external }を使って入力特徴量のサブセットを選択し、無関係または重複する特徴量を無視します。特徴量の選択には、特徴量に大量の値が欠落している場合に、単にそれらをドロップすることも含まれる場合があります。

• 特徴量の構築: 多項式展開{: .external }（一変量数学関数を使用）か特徴量交差{: .external }（特徴量の相互作用をキャプチャ）などの一般的な手法を使用して、新しい特徴量を作成します。特徴量は、ML ユースケース分野のビジネスロジックを使用して構築することも可能です。

非構造化データ（画像、音声、テキストドキュメントなど）を操作する場合、ドメイン知識ベースの特徴量エンジニアリングの代わりに、ディープラーニングをモデルアーキテクチャに組み込みます。畳み込みレイヤー{: .external }は、自動特徴量プリプロセッサです。適切なモデルアーキテクチャの構築には、データに関するある程度の経験的知識が必要となります。また、以下のような前処理も必要となります。

• テキストドキュメントの場合: ステミングとレンマ化{: .external }、TF-IDF{: .external } 計算、および n-gram{: .external } 抽出、埋め込みルックアップ。

• 画像の場合: クリッピング、サイズ変更、トリミング、ガウスぼかし、カナリア色フィルタ。

• 全データタイプ共通（テキストと画像を含む）: 転移学習{: .external }。これは、完全にトレーニングされたモデルの最後のレイヤー以外の全レイヤーを特徴量エンジニアリングステップとして処理します。

前処理の粒度

このセクションは、データ変換の種類の粒度について説明します。トレーニング データに適用される変換を使用して予測用の新しいデータ ポイントを準備するときに、なぜこの観点が重要となるのかを示しています。

前処理と変換の演算は、演算の粒度に基づいて以下のように区分されます。

• トレーニングと予測中のインスタンスレベルの変換。これらは単純な変換で、変換に必要なのは同じインスタンスの値のみです。インスタンスレベルの変換には、たとえば、特徴量の値をあるしきい値にクリッピングする、別の特徴量を多項式展開する、2 つの特徴量を乗算する、2 つの特徴量を比較してブール型フラグを作成するなどが含まれる場合があります。

  これらの変換はトレーニング中と予測中に同じように適用される必要があります。これは、モデルが未加工の入力値でではなく、変換済みの特徴量でトレーニングされるためです。データが同じように変換されなければ、トレーニングに使用されなかった値の分布を持つデータが提供されてしまうため、モデルがうまく動作しなくなります。詳細については、前処理の課題セクションのトレーニングサービングスキューの説明をご覧ください。

• トレーニング中のフルパス変換と予測中のインスタンスレベルの変換。このシナリオでは、変換はステートフルになります。事前計算済みの統計を使用して変換を実行するためです。トレーニング中には、トレーニングデータ全体を分析して、トレーニングデータ、評価データ、および新しい予測時のデータを変換するための最小、最大、平均、分散 などの数量を計算します。

  たとえば、トレーニング用に数値特徴量を正規化する場合、トレーニングデータ全体でその平均（μ）と標準偏差（σ）を計算します。これはフルパス（または分析）演算と呼ばれる計算です。予測目的でモデルをサービングすると、新しいデータポイントの値はトレーニングサービングスキューを回避するために正規化されます。したがって、トレーニング中に計算される μ 値と σ 値は特徴量を調整するために使用され、以下のような単純なインスタンスレベル演算が成立します。

  $$value_{scaled} = (value_{raw} - \mu) \div \sigma$$

  フルパス変換には、以下が含まれます。

  • トレーニングデータセットから計算される min と max を使用した、数値特徴量の MinMax スケーリング。

  • トレーニングデータセットで計算された μ と σ を使用した、数値特徴量の標準スケーリング（標準化）。

  • 分位数を使用した数値特徴量のバケット化。

  • 中央値（数値特徴量）またはモード（カテゴリカル特徴量）を使用した欠損値の補完。

  • 入力カテゴリカル特徴量のすべての個別の値（語彙）の抽出による、文字列（公称値）から整数（インデックス）への変換。

  • TF-IDF を計算する目的で、すべてのドキュメント（インスタンス）における用語（特徴量）の出現回数のカウント。

  • （一次従属特徴量で）データをより低い次元空間に投影するための、入力特徴量の PCA の計算。

  μ、σ、min、max などの統計を計算する場合は、トレーニングデータのみを使用することをお勧めします。これらの演算にテストデータと評価データを追加してしまうと、モデルのトレーニングに、評価データとテストデータの情報を漏らす{: .external }ことになるためです。これでは、テスト結果と評価結果の信頼性を損なってしまいます。すべてのデータセットに一貫した変換を確実に適用するには、テストデータと評価データの変換に、トレーニングデータから計算された統計と同じ統計を使用してください。

• トレーニングと予測中の履歴集計。これには、予測タスクへの入力信号としてのビジネス集計、派生、およびフラグの作成が含まれます。たとえば、顧客が傾向モデルを構築するためのRFM（リーセンシー、フリークエンシー、マネタリー）{: .external } 指標の作成です。こういった種類の特徴量は、モデルのトレーニング、バッチスコアリング、オンライン予測サービング中に使用できるように、事前に計算して、特徴量ストアに保存しておくことができます。また、トレーニングと予測の前に、これらの集計に対して追加の特徴量エンジニアリング（変換、調整など）を実行することもできます。

• トレーニング中の履歴集計と予測中のリアルタイム集計。このアプローチには、経時的なリアルタイム値の要約による特徴量の作成が伴います。このアプローチでは、集計されるインスタンスは時間枠の句を介して定義されます。たとえば、タクシーの走行時間をその経路の過去 5 分間、10 分間、30 分間、その他の間隔のトラフィック指標に基づいて見積もるモデルをトレーニングしたい場合に使用できるアプローチです。また、過去 3 分間に渡って計算された変化温度と振動の平均値に基づいてエンジン部品の故障を予測するためにも、このアプローチを使用できます。これらの集計はトレーニング用にオフラインで準備されますが、サービング中にはリアルタイムでデータストリームから計算されます。

  より厳密には、トレーニングデータを準備する際に、集計される値が未加工のデータでなければ、その値はデータエンジニアリングの段階で作成されます。未加工のデータは通常、データベースに (entity, timestamp, value) のフォーマットで保存されます。前の例を使うと、entity は、タクシーの経路のルートセグメント識別子であり、エンジン故障のエンジン部品識別子です。ウィンドウ演算を使用して、(entity, time_index, aggregated_value_over_time_window) を計算し、集計特徴量をモデルトレーニングの入力として使用することができます。

  リアルタイム（オンライン）予測のモデルがサービングされると、モデルは集計された値から派生する特徴量を入力として期待します。したがって、Apache Beam などのストリーム処理テクノロジーを使用すれば、システムにストリーミングされたリアルタイムデータポイントから集計を計算することができます。ストリーム処理テクノロジーは、新しいデータポイントが着信する過程で時間枠に基づくリアルタイムデータを集計します。また、トレーニングと予測の前に、これらの集計に追加の特徴量エンジニアリング（変換、調整など）を実行することもできます。

Google Cloud の ML パイプライン{: id="machine_learning_pipeline_on_gcp" }

このセクションでは、Google Cloud のマネージドサービスを使用して TensorFlow ML モデルのトレーニングとサービングを行う一般的なエンドツーエンドパイプラインの主なコンポーネントについて説明します。また、様々な種類のデータ前処理演算を実装できる場所や、変換を実装する際に直面する可能性のある一般的な課題についても説明します。tf.Transform の仕組みセクションでは、TensorFlow Transform ライブラリがこういった課題への取り組みにどのように役立つかを示します。

高レベルのアーキテクチャ

以下の図 2 は、TensorFlow モデルのトレーニングとサービングを行う一般的な ML パイプラインの高レベルのアーキテクチャを示しています。図中のラベル A、B、および C は、データ前処理が発生するパイプライン中の場所を示します。これらのステップの詳細は、次のセクションで説明します。

パイプラインは以下のステップで構成されています。

1. 未加工のデータがインポートされた後、表形式データは BigQuery に、画像、音声、動画などの他のデータは Cloud Storage に保存されます。この連載のパート 2 では、BigQuery に保存された表形式データを例として使用します。

2. Dataflow を使用して、データエンジニアリング（準備）と特徴量エンジニアリングが大規模に実行されます。この実行により、ML 対応のトレーニングセット、評価セット、およびテストセットが Cloud Storage に生成されます。これらのデータセットは TensorFlow 計算の最適化フォーマットである TFRecord ファイルとして保存されているのが理想です。

3. TensorFlow モデルのトレーナーパッケージ{: .external }が、モデルをトレーニングするために前のステップの前処理データを使用する Vertex AI Training に提出されます。このステップの出力は、Cloud Storage にエクスポートされるトレーニング済みの TensorFlow SavedModel です。

4. トレーニング済みの TensorFlow モデルは、オンライン予測に使用できるように、REST API を持つサービスとして Vertex AI Prediction にデプロイされます。バッチ予測ジョブにもこれと同じモデルを使用できます。

5. モデルが REST API としてデプロイされると、クライアントアプリと内部システムは、いくつかのデータポイントでリクエストを送信して API を呼び出し、モデルからレスポンスとして予測を受け取ることができます。

6. このパイプラインのオーケストレーションと自動化には、スケジューラとして Vertex AI Pipelines{: .external } を使用し、データの準備、モデルのトレーニング、およびモデルのデプロイのステップを呼び出すことができます。

入力特徴量の保存に Vertex AI Feature Store{: .external } を使用して、予測を行うこともできます。たとえば、最新の未加工のデータからエンジニアリング済みの特徴量を定期的に作成し、Vertex AI Feature Store に保存することが可能です。クライアントアプリは Vertex AI Feature Store から必要な入力特徴量をフェッチしてモデルに送信し、予測を受け取ることができます。

前処理を実行する箇所

図 2 のラベル A、B、および C は、BigQuery、Dataflow、または TensorFlow でデータ前処理演算を実施できることを示しています。以下のセクションでは、これらのプションがどのように動作するかについて説明します。

オプション A: BigQuery{: id="option_a_bigquery"}

通常 BigQuery には、以下の演算を行うロジックが実装されます。

• サンプリング: データからサブセットを無作為に選択します。

• フィルタリング: 無関係または無効なインスタンスを除去します。

• 分割: データをトレーニングセット、評価セット、およびテストセットに分割します。

BigQuery SQL スクリプトは、Dataflow 前処理パイプラインのソースクエリとして使用できます。これは、図2 のデータ処理ステップです。たとえば、システムがカナダで使用されており、データウェアハウスに世界中からのトランザクションがある場合、フィルタリングによってカナダ限定のトレーニングデータを取得する作業は BigQuery で行うのが最適です。BigQuery での特徴量エンジニアリングは単純で拡張可能であり、インスタンスレベルと履歴集計の特徴量変換の実装がサポートされています。

ただし、モデルをバッチ予測（スコアリング）に使用する場合、または特徴量が BigQuery で事前に計算されていても、オンライン予測中に使用できるように Vertex AI に保存されている場合は、BigQuery を特徴量エンジニアリングのみに使用することをお勧めします。オンライン予測向けにモデルをデプロイし、オンライン特徴量ストアにエンジニアリング済みの特徴量がない場合は、SQL 前処理演算を複製して、他のシステムが生成する未加工のデータを変換する必要があるためです。言い換えると、BigQuery でトレーニングデータを前処理する SQL でのロジックと、モデルを消費して、予測のためにオンラインデータポイントを前処理するアプリでのロジックの 2 つを実装する必要があるためです。

たとえば、クライアントアプリが Java で書かれている場合、Java でロジックを実装し直す必要があります。このようにすると、実装の違いにより、エラーが導入されてしまう可能性があります。これについては、このドキュメントの後の方にある前処理の課題のトレーニングサービングスキューのセクションで説明されています。また、2 つの異なる実装を保守するのは余分なオーバーヘッドでもあります。SQL でトレーニングデータを前処理するためのロジックを変更するたびに、それに合わせてサービング時にデータを前処理する Java 実装も変更しなくてはなりません。

バッチ予測のためだけにモデルを使用している場合（Vertex AI バッチ予測{: .external }などを使用）で、スコアリング用のデータが BigQuery にある場合であれば、これらの前処理演算を BigQuery SQL スクリプトの一環として実装できます。この場合には、同じ前処理 SQL スクリプトを使用して、トレーニングデータとスコアリングデータの両方を準備することが可能です。

フルパスのステートフルな変換は、BigQuery での実装に適していません。フルパス変換に BigQuery を使用する場合は、数値特徴量をスケーリングするための平均や分散など、ステートフルな変換で必要となる数量を保存する補助テーブルが必要となります。さらに、BigQuery で SQL を使ってフルパス変換を実装すると、SQL スクリプトの複雑さが増し、トレーニングとスコアリングの SQL スクリプトの間の依存関係が複雑化してしまいます。

オプション B: Dataflow{: id="option_b_cloud_dataflow"}

図 2 で示されるとおり、Apache Beam で計算コストのかかる前処理演算を実装し、Dataflow で大規模に実行することができます。Dataflow はバッチとストリームデータ処理用のフルマネージド自動スケーリングサービスです。BigQuery とは異なり、Dataflow を使用すると、外部のデータ処理専門ライブラリを使用することもできます。

Dataflow は、インスタンスレベルの変換と、履歴とリアルタイム集計の特徴量変換を実行できます。特に、ML モデルで total_number_of_clicks_last_90sec のような入力特徴量が期待されている場合、Apache Beam のウィンドウ関数{: .external } は、リアルタイム（ストリーミング）イベントデータ（クリックイベントなど）の時間枠の値の集計に基づいて、これらの特徴量を計算できます。前の「変換の粒度」において、これは「トレーニング中の履歴集計と予測中のリアルタイム集計」と呼ばれました。

以下の図 3 は、ほぼリアルタイムの予測を行うためにストリームデータを処理する際の Dataflow の役割を示します。

図 3 に示されるとおり、処理中は、データポイントと呼ばれるイベントが Pub/Sub{: .external } に取り込まれます。Dataflow はこれらのデータポイントを消費し、経時的な集計に基づいて特徴量を計算し、その上でデプロイされた ML モデル API を呼び出して予測します。予測はその後、外向きの Pub/Sub キューに送信され、Pub/Sub から監視や制御などの下流のシステムで消費されるか、元の要求元のクライアントにプッシュされます（通知など）。予測はまた、Cloud Bigtable{: .external } などの低レイテンシのデータストアに保存され、リアルタイムで取得されます。Cloud Bigtable は予測に必要となった場合にルックアップできるようにこれらのリアルタイム集計を蓄積して保存するためにも使用されます。

同様の Apache Beam 実装は、BigQuery などのオフラインデータストアからのトレーニングデータを一括処理し、オンライン予測でサービングするために、リアルタイムデータをストリーム処理するために使用できます。

図 2 に示されるような他の一般的なアーキテクチャでは、クライアントアプリはデプロイされたモデル API を直接呼び出して、オンライン予測を行います。この場合、トレーニングデータを準備するために前処理演算が Dataflow に実装されていれば、この演算は直接モデルに送られる予測データには適用されません。そのため、こういった変換は、オンライン予測用のサービング中にモデルに組み込まれている必要があります。

Dataflow は、必要な統計を大規模に計算することでフルパス変換を実施するために使用できますが、これらの統計は、予測データポイントを変換するために、予測中に使用できるようにどこかに保管されていなければなりません。TensorFlow Transform（tf.Transform）ライブラリを使用すると、これらの統計をどこか別の場所に保存する代わりに、直接モデルに埋め込むことができます。このアプローチについては、後の「tf.Transform の仕組み」で説明します。

オプション C: TensorFlow{: id="option_c_tensorflow"}

図 2 に示すとおり、データ前処理演算と変換演算を TensorFlow　 モデルそのものに実装することができます。この図のように、TensorFlow モデルのトレーニングのために実装する前処理は、モデルが予測向けにエクスポートされてデプロイされる際に、モデルの重要な部分となります。TensorFlow モデル内の変換は、次のいずれの方法で可能です。

• すべてのインスタンスレベルの変換ロジックを、input_fn 関数と serving_fn 関数に実装します。input_fn 関数は、tf.data.Dataset API を使用して、モデルのトレーニング用にデータセットを準備します。serving_fn 関数は、データを受け取って予測用に準備します。

• Keras 前処理レイヤー{: .external }を使用するかカスタムレイヤーを作成{: .external }して、直接 TensorFlow モデルに変換コードを投入します。

serving_fn 関数の変換ロジックコードは、オンライン予測を行うために、SavedModel のサービングインターフェースを定義します。トレーニングデータの準備に使用されたのと同じ変換を serving_fn 関数の変換ロジックコードに実装すると、サービングされたときに同じ変換が新しい予測データポイントに適用されることを保証できます。

ただし、TensorFlow モデルは各データポイントを独立して、または小さなバッチdえ処理するため、すべてのデータポイントの集計を計算できません。そのため、TensorFlow モデルにフルパス変換を実装することはできません。

前処理の課題

データ前処理を実装する際には、主に以下のような課題があります。

• トレーニングサービングスキュー。 トレーニングサービングスキュー{: .external }とは、トレーニング中とサービング中の有効性（予測パフォーマンス）の違いを指します。これは、トレーニングパイプラインとサービングパイプラインにおけるデータの処理方法の違いによって発生する歪みです。たとえば、対数的に変換された特徴量でモデルをトレーニングしたにもかかわらず、サービング中には未加工の特徴量が提供されれば、予測出力は正確でない可能性があります。

  変換がモデルそのものの一部となる場合、上記のオプション C: TensorFlow で説明されているとおり、インスタンスレベルの変換を処理するのが簡単です。この場合、モデルサービングインターフェース（serving_fn 関数）は未加工のデータを期待しながらも、モデルは出力を計算する前にこのデータを内部的に変換します。この変換は、未加工のトレーニングデータポイントと予測データポイントに適用されたものと同じです。

• フルパス変換。TensorFlow モデルにスケーリングや正規化変換などのフルパス変換を実装することはできません。オプション B: Dataflow で説明されているとおり、フルパス変換では、一部の統計（数値特徴量をスケーリングするための max や min 値など）を、あらかじめトレーニングデータで計算しておく必要があります。この値はその後で、予測用のモデルサービング中に使用して新しい未加工のデータポイントに変換できるように、どこかに保管しておかなければなりません。こうすることで、トレーニングサービングスキューを回避できます。TensorFlow Transform（tf.Transform）ライブラリを使用すれば、直接 TensorFlow モデルに統計を埋め込むことが可能です。このアプローチは、後の「tf.Transform の仕組み」で説明されています。

• トレーニングの効率を高めるために、最初にデータを準備する。モデルの一部としてインスタンスレベルの変換を実装すると、トレーニングプロセスの効率が低下してしまう可能性があります。この低下は、エポックごとに、同じ変換が同じトレーニングデータに繰り返し適用されることが原因で発生します。1,000 個の特徴量を持つ未加工のトレーニングデータがあり、インスタンスレベルの変換の混合を適用して 10,000 個の特徴量を生成するとします。これらの変換をモデルの一部として実装し、さらにモデルに未加工のトレーニングデータをフィードすると、これらの 10,000 個の演算がインスタンスごとに N 回適用されてしまします。この N はエポック数です。さらに、アクセラレータ（GPU または TPU）を使用していれば、CPU が変換を実行する間、アイドル状態となってしまうため、コストのかかるアクセラレータが有効に使用されていません。

  トレーニングデータは、オプション B: Dataflow に記述されている手法を使って、トレーニングの前に変換されているのが理想的です。この場合、10,000 個の変換演算が、トレーニングインスタンスごとに 1 回だけ適用されることになります。変換されたトレーニングデータは、その後モデルに提供されます。以降で適用される変換はないため、アクセラレータは常時ビジーになります。さらに、Dataflow を使用することで、フルマネージドサービスを使って大量のデータを大規模に前処理することができます。

  トレーニングデータを最初に準備しておくことで、トレーニングの効率を改善できますが、モデルの外で変換ロジックを実装する（「オプション A: BigQuery」または「オプション B: Dataflow」で説明されている手法）と、トレーニングサービングスキューの問題は解決しません。トレーニングと予測の両方で使用されるエンジニアリング済みの特徴量を特徴量ストアに保管しないのであれば、予測用に受け取る新しいデータポイントに適用できる場所に変換ロジックを実装する必要があります。モデルインターフェースは変換済みのデータを期待しているためです。この問題は、次のセクションで説明されるように、TensorFlow Transform（tf.Transform）ライブラリで解決できます。

tf.Transform の仕組み{:#how_tftransform_works}

tf.Transform ライブラリは、フルパスが必要な変換に有用です。tf.Transform ライブラリの出力は、インスタンスレベルの変換ロジックとフルパスから計算される統計を表現する TensorFlow グラフとしてエクスポートされ、トレーニングとサービングに使用されます。トレーニングとサービスの両方に同じグラフを使用すると、両方のステージで同じ変換が適用されるため、スキューを防止することができます。さらに、tf.Transform ライブラリは、トレーニングデータを最初に準備しておくために、Dataflow のバッチ前処理パイプラインで大規模に実行できるため、トレーニングの効率を改善することができます。

以下の図 4 では、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 グラフとして保管されます。エクスポート済みのグラフは、インスタンスレベルの演算としての変換ロジックと、フルパス変換で計算されたグラフ定数としてのすべての統計で構成されています。トレーニング済みのモデルがサービング用にエクスポートされると、serving_fn 関数の一部として、transform_fn グラフが SavedModel に添付されます。

予測を行うためにモデルをサービングしている間、モデルサービングインターフェースは未加工のフォーマット（変換が行われる前の状態）のデータポイントを期待しますが、モデルの内部インターフェースは変換済みのフォーマットのデータを期待しています。

モデルの一部となった transform_fn グラフは、着信するデータポイントにすべての前処理ロジックを適用します。予測中のインスタンスレベルの演算には、保存されている定数（数値特徴量を正規化するための μ や σ など）を使用します。そのため、transform_fn グラフは未加工のデータポイントを変換済みのフォーマットに変換します。図 4 に示されるとおり、予測を生成するために、モデルの内部インターフェースが期待するのが、この変換済みのフォーマットです。

トレーニングデータと評価データの変換に使用されたのと同じロジック（実装）が、予測サービング中に新しいデータポイントの変換に適用されるため、この仕組みによってトレーニングサービングスキューの前処理の課題が解決されます。

前処理のオプションに関するまとめ

以下は、このドキュメントで説明されたデータ前処理オプションを要約したテーブルです。テーブル内の「N/A」は 「適用外」を示します。

^* TensorFlow では、交差、埋め込み、One-Hot エンコーディングなどの変換は、feature_columns 列として宣言的に実行する必要があります。

次のステップ

• Dataflow を使って tf.Transform パイプラインを実装して実行するには、このシリーズのパート 2「TensorFlow Transform による ML のためのデータ前処理」をお読みください。

• TensorFlow on Google Cloud{: .external } で ML に関する Coursera の専門講座を受講してください。

• Rules of ML{: .external } で ML エンジニアリングのベストプラクティスをご覧ください。

• その他のリファレンスアーキテクチャ、ダイアグラム、およびベストプラクティスについては、TFX Cloud Solutions をご覧ください。