元データは特徴量エンジニアリング（変換）を行う必要がある。どのような場合に どうすればよいでしょうか。大まかに言うと、特徴量エンジニアリングは 次の 2 つの期間。
- モデルをトレーニングする前。
- モデルのトレーニング中。
トレーニング前のデータの変換
このアプローチでは、次の 2 つの手順を行います。
- コードを記述するか、専用ツールを使用する 元データを変換します
- 変換したデータは、モデルが取り込める場所（ 作成されます。
メリット
- システムが元データを変換するのは 1 回だけです。
- システムはデータセット全体を分析して 変革戦略を策定します。
デメリット
- 予測時に変換を再作成する必要があります。注意: トレーニング サービング スキューです。
システムが動的トレーニングを行う場合、トレーニング サービング スキューの危険性が高まる 推論について説明します。 動的推論を使用するシステムでは 元データセットは通常、予測を行うソフトウェアと トレーニングサービングスキューの原因となります 対照的に、静的（オフライン）推論を使用するシステムでは、 同じソフトウェアを使用します。
トレーニング中のデータの変換
このアプローチでは、変換はモデルコードの一部です。モデル 元データを取り込み、変換します。
メリット
- 変換を変更しても、同じ元データファイルを使用できます。
- トレーニング時と予測時に同じ変換が確実に行われる。
デメリット
- 複雑な変換により、モデルのレイテンシが増加する可能性があります。
- 変換はバッチごとに行われます。
バッチごとのデータの変換は簡単ではありません。たとえば、Kubernetes Engine の Z スコア正規化を使用します。 数値データに変換しますZ スコアの正規化には、平均値と 特徴量の標準偏差。 ただしバッチごとの変換では 1 つのバッチにまとめたものです。バッチが非常に多い場合は あるバッチ内の Z スコアが -2.5 などの場合、同じ意味を持ちません。 -2.5 という値を返します。 回避策として、システムで平均と標準偏差を事前に計算しておく モデルで定数として使用します