このページは Cloud Translation API によって翻訳されました。
Switch to English

TensorFlow Data Validation:データの確認と分析

データがTFXパイプラインに入ると、TFXコンポーネントを使用してデータを分析および変換できます。これらのツールは、モデルをトレーニングする前でも使用できます。

データを分析して変換する理由はたくさんあります。

  • データの問題を見つけるため。一般的な問題は次のとおりです。
    • 空の値を持つフィーチャなどの欠損データ。
    • ラベルは特徴として扱われるため、トレーニング中にモデルが正しい答えを確認できます。
    • 期待する範囲外の値を持つ機能。
    • データ異常。
  • より効果的な機能セットを設計するため。たとえば、次のことを識別できます。
    • 特に有益な機能。
    • 冗長機能。
    • 規模が大きく異なるため、学習が遅くなる可能性がある機能。
    • 固有の予測情報がほとんどまたはまったくない機能。

TFXツールは、データのバグの発見と機能エンジニアリングの両方に役立ちます。

TensorFlowデータ検証

概観

TensorFlow Data Validationは、トレーニングとサービスのデータの異常を識別し、データを調べることでスキーマを自動的に作成できます。コンポーネントは、データ内のさまざまなクラスの異常を検出するように構成できます。できる

  1. ユーザーの期待を体系化するスキーマに対してデータ統計を比較することにより、有効性チェックを実行します。
  2. トレーニングと配信データの例を比較して、トレーニングと配信のスキューを検出します。
  3. 一連のデータを見て、データのドリフトを検出します。

これらの機能を個別に文書化します。

スキーマベースの検証例

TensorFlow Data Validationは、データ統計をスキーマと比較することにより、入力データの異常を識別します。スキーマは、データタイプやカテゴリ値など、入力データが満たすことが期待されるプロパティをコード化し、ユーザーが変更または置換できます。

高度なスキーマ機能

このセクションでは、特別なセットアップに役立つ、より高度なスキーマ構成について説明します。

スパース機能

例でスパース機能をエンコードすると、通常、すべての例で同じ原子価を持つと予想される複数の機能が導入されます。たとえば、スパース機能:

 
WeightedCategories = [('CategoryA', 0.3), ('CategoryX', 0.7)]
 
インデックスと値に個別の機能を使用してエンコードされます:
 
WeightedCategoriesIndex = ['CategoryA', 'CategoryX']
WeightedCategoriesValue = [0.3, 0.7]
 
インデックスと値の機能の価数はすべての例で一致する必要があるという制限があります。この制限は、sparse_featureを定義することにより、スキーマで明示的にすることができます。
 
sparse_feature {
  name: 'WeightedCategories'
  index_feature { name: 'WeightedCategoriesIndex' }
  value_feature { name: 'WeightedCategoriesValue' }
}
 

疎機能の定義には、スキーマに存在する機能を参照する1つ以上のインデックスと1つの値の機能が必要です。スパース機能を明示的に定義すると、TFDVは、参照されるすべての機能の価数が一致することを確認できます。

一部のユースケースでは、機能間で同様の原子価制限が導入されますが、必ずしもスパース機能をエンコードするわけではありません。スパース機能を使用すると、ブロックが解除されますが、理想的ではありません。

スキーマ環境

デフォルトでは、検証では、パイプライン内のすべてのサンプルが単一のスキーマに準拠していると想定しています。場合によっては、わずかなスキーマのバリエーションを導入する必要があります。たとえば、トレーニング中にラベルとして使用される機能が必要です(検証する必要があります)が、提供中に欠落しています。このような要件、特にdefault_environment()in_environment()not_in_environment()を表すために環境を使用できます。

たとえば、トレーニングに「LABEL」という名前の機能が必要であるが、提供されないことが予想されるとします。これは次のように表現できます。

  • スキーマに2つの異なる環境を定義します:["SERVING"、 "TRAINING"]および 'LABEL'を環境 "TRAINING"のみに関連付けます。
  • トレーニングデータを環境「TRAINING」に関連付け、提供データを環境「SERVING」に関連付けます。
スキーマ生成

入力データスキーマはTensorFlow スキーマのインスタンスとして指定されます。

ゼロから手動でスキーマを構築する代わりに、開発者はTensorFlow Data Validationの自動スキーマ構築に依存できます。具体的には、TensorFlow Data Validationは、パイプラインで利用可能なトレーニングデータに対して計算された統計に基づいて、初期スキーマを自動的に構築します。ユーザーは、この自動生成されたスキーマを確認し、必要に応じて変更し、バージョン管理システムにチェックインし、さらに検証するためにパイプラインに明示的にプッシュできます。

TFDVには、スキーマを自動的に生成するinfer_schema()が含まれています。例えば:

 schema = tfdv.infer_schema(statistics=train_stats)
tfdv.display_schema(schema=schema)
 

これにより、次のルールに基づいてスキーマの自動生成がトリガーされます。

  • スキーマがすでに自動生成されている場合は、そのまま使用されます。

  • それ以外の場合、TensorFlow Data Validationは利用可能なデータ統計を調べ、データに適したスキーマを計算します。

注:自動生成されたスキーマはベストエフォートであり、データの基本的なプロパティのみを推測しようとします。必要に応じて、ユーザーが確認および変更することが期待されます。

トレーニングを提供するスキュー検出

概観

トレーニングサービングスキュー検出器は、TensorFlow Data Validationのサブコンポーネントとして実行され、トレーニングデータとサービングデータ間のスキューを検出します。

スキューの種類

さまざまな制作ポストポーテムに基づいて、さまざまなタイプのスキューを4つの主要なカテゴリに減らしました。次に、これらの各カテゴリについて説明し、それらが発生するシナリオの例を示します。

  1. スキーマスキューは、トレーニングデータと提供データが同じスキーマに準拠していない場合に発生します。スキーマはデータの論理プロパティを記述するため、トレーニングとデータの提供は同じスキーマに準拠することが期待されます。 2つの間の予想される偏差(ラベルフィーチャーがトレーニングデータにのみ存在し、提供されていないなど)は、スキーマの環境フィールドで指定する必要があります。

    トレーニングデータの生成はバルクデータ処理ステップですが、(オンライン)サービングデータの生成は通常レイテンシの影響を受けやすいステップであるため、トレーニングデータとサービングデータを生成するさまざまなコードパスが一般的です。これは間違いです。これら2つのコードパス間の不一致(開発者のエラーまたは一貫性のないバイナリリリースのいずれかが原因)は、スキーマスキューにつながる可能性があります。

    シナリオ例

    ボブはモデルに新しい機能を追加し、それをトレーニングデータに追加したいと考えています。オフラインのトレーニング指標は見栄えは良いですが、オンラインの指標ははるかに悪いです。何時間ものデバッグの後、Bobは同じ機能をサービスコードパスに追加するのを忘れていることに気付きました。このモデルはこの新機能を非常に重要視しており、提供時に利用できなかったため、予測が不十分で、オンライン指標が悪化しました。

  2. フィーチャースキューは、モデルがトレーニングするフィーチャー値が、提供時に表示されるフィーチャー値と異なる場合に発生します。これは、次のような複数の理由で発生する可能性があります。

    • 一部の機能値を提供する外部データソースがトレーニングと提供時間の間に変更された場合。

    • トレーニングと提供の間で機能を生成するための一貫性のないロジック。たとえば、2つのコードパスのいずれかにのみ変換を適用する場合などです。

    シナリオ例

    Aliceには継続的な機械学習パイプラインがあり、今日の提供データがログに記録され、翌日のトレーニングデータを生成するために使用されます。スペースを節約するために、彼女は配信時にビデオIDのみを記録し、トレーニングデータの生成中にデータストアからビデオプロパティをフェッチすることにしました。

    そうすることで、彼女は誤って、アップロード時間と配信時間の間で視聴時間が大幅に変化する可能性のある、新しくアップロードされたバイラルビデオ(特に以下に示す)に特に危険なスキューを導入します。

     
     Serving Example           Training Example
     -------------------------  -------------------------
     features {                 features {
       feature {                  feature {
         key "vid"                  key "vid"
         value { int64_list {       value { int64_list {
           value 92392               value 92392
         } }                         } }
       }                          }
       feature {                  feature {
         key "views"               key "views"
         value { int_list {       value { bytes_list {
           value " 10 "                value " 10000 "  # skew
         } }                         } }
       }                          }
     }                          }
     

    これは、トレーニングデータが膨らんだ数のビューを見るので、特徴スキューのインスタンスです。

  3. 分布スキューは、トレーニングデータの特徴値の分布がデータの提供と大きく異なる場合に発生します。分布スキューの主な原因の1つは、トレーニングデータの生成に完全に異なるコーパスを使用して、目的のコーパスに初期データがないことを克服することです。もう1つの理由は、トレーニングするサービングデータのサブサンプルのみを選択する、不完全なサンプリングメカニズムです。

    シナリオ例

    たとえば、データの不足しているスライスを補正するために、ダウンサンプリングされたサンプルを適切に重み付けせずにバイアスサンプリングを使用すると、トレーニングデータとサービスデータの間の特徴値の分布は、論理的に歪んでしまいます。

  4. スコアリング/配信スキューは検出が難しく、スコアリングされた例のサブセットのみが実際に配信されるときに発生します。ラベルは提供された例にのみ使用でき、スコア付きの例には使用できないため、これらの例のみがトレーニングに使用されます。スコアリングされた例はトレーニングデータで徐々に過小評価されるため、これにより、モデルは暗黙的にスコア付けされた例を誤って予測します。

    シナリオ例

    トップ10の広告を配信する広告システムを考えてみましょう。これら10個の広告のうち、ユーザーがクリックできるのはそのうちの1つだけです。これらの提供され例の10個すべてが翌日のトレーニングに使用されます。1個が陽性、9個が陰性です。ただし、配信時にはトレーニング済みモデルを使用して数百の広告をスコアリングしました。配信されなかった他の90個の広告は、暗黙的にトレーニングデータから削除されます。これにより、ランクの低いものがトレーニングデータに表示されないため、より低いランクのものが誤って予測される暗黙のフィードバックループが発生します。

なぜあなたは気にする必要がありますか?

スキューは検出が難しく、多くのMLパイプラインで蔓延しています。これがパフォーマンスの低下と収益の損失を引き起こしたいくつかの事件がありました。

現在サポートされているものは何ですか?

現在、TensorFlow Data Validationは、スキーマスキュー、機能スキュー、および分布スキューの検出をサポートしています。

ドリフト検出

ドリフト検出は、カテゴリ別の機能、およびトレーニングデータの異なる日の間など、連続するデータのスパン間(つまり、スパンNとスパンN + 1の間)でサポートされます。ドリフトはL無限距離で表します。しきい値の距離を設定して、ドリフトが許容範囲を超えたときに警告を受け取ることができます。正しい距離の設定は、通常、ドメインの知識と実験を必要とする反復的なプロセスです。

視覚化を使用してデータを確認する

TensorFlow Data Validationは、特徴値の分布を視覚化するためのツールを提供します。 ファセットを使用してJupyterノートブックでこれらの分布を調べることにより、データに関する一般的な問題を見つけることができます。

機能統計

不審な分布の特定

ファセットの概要表示を使用して、機能値の不審な分布を探すことにより、データ内の一般的なバグを特定できます。

不均衡なデータ

アンバランス機能は、1つの値が優勢な機能です。機能の不均衡は自然に発生する可能性がありますが、機能の値が常に同じである場合、データにバグがある可能性があります。ファセットの概要で不均衡な特徴を検出するには、[並べ替え]ドロップダウンから[不均一性]を選択します。

最も不均衡な機能は、各機能タイプのリストの一番上に表示されます。たとえば、次のスクリーンショットは、「数値特徴」リストの上部にある、すべてゼロの1つの特徴と、非常に不均衡な2番目の特徴を示しています。

不均衡なデータの視覚化

均一に分散されたデータ

均一に分散された機能は、すべての可能な値が同じ頻度に近い値で表示される機能です。不均衡なデータと同様に、この分布は自然に発生する可能性がありますが、データのバグによって生成されることもあります。

ファセットの概要で均一に分布した特徴を検出するには、[並べ替え]ドロップダウンから[不均一性]を選択し、[逆順]チェックボックスをオンにします。

均一データのヒストグラム

文字列データは、一意の値が20以下の場合は棒グラフを使用して、20を超える場合は累積分布グラフとして表されます。そのため、文字列データの場合、均一分布は上図のようなフラットバーグラフまたは下図のような直線として表示されます。

折れ線グラフ:均一データの累積分布

均一に分散されたデータを生成する可能性のあるバグ

以下は、均一に分散されたデータを生成する可能性があるいくつかの一般的なバグです。

  • 文字列を使用して日付などの非文字列データ型を表す。たとえば、「2017-03-01-11-45-03」のような表現を持つ日時機能には、多くの一意の値があります。一意の値は均一に分散されます。

  • 「行番号」などのインデックスを特徴として含みます。ここにも多くのユニークな値があります。

データがありません

機能に完全に値がないかどうかを確認するには:

  1. [並べ替え]ドロップダウンから[不足している量/ゼロ]を選択します。
  2. 「逆順」チェックボックスをチェックします。
  3. 「欠損値」列を見て、機能の欠損値を持つインスタンスの割合を確認します。

データのバグにより、機能値が不完全になることもあります。たとえば、機能の値リストには常に3つの要素があり、時には1つしかないことがわかる場合があります。不完全な値、または機能値リストに予期される要素数がない他のケースを確認するには:

  1. 右側の[表示するグラフ]ドロップダウンメニューから[値リストの長さ]を選択します。

  2. 各機能の行の右側にあるグラフを見てください。グラフは、フィーチャの値リストの長さの範囲を示しています。たとえば、以下のスクリーンショットで強調表示されている行は、長さゼロの値リストを持つ機能を示しています。

長さがゼロのフィーチャー値リストを持つフィーチャーを含むファセットの概要表示

機能間のスケールの大きな違い

機能のスケールが大きく異なる場合、モデルの学習が困難になる可能性があります。たとえば、一部の機能が0から1に変化し、他の機能が0から1,000,000,000に変化する場合、スケールに大きな違いがあります。機能全体の「最大」列と「最小」列を比較して、さまざまなスケールを見つけます。

これらの幅広い変動を減らすために、機能値を正規化することを検討してください。

無効なラベルのあるラベル

TensorFlowのEstimatorは、ラベルとして受け入れるデータのタイプに制限があります。たとえば、バイナリ分類子は通常、{0、1}ラベルでのみ機能します。

ファセットの概要でラベル値を確認し、それらがEstimators要件に準拠していることを確認してください。