Tensorflowモデル分析のよくある質問

全般的

EvalSavedModelはまだ必要ですか?

以前は、TFMAでは、特別なEvalSavedModelを使用してすべてのメトリックをテンソルフローグラフ内に保存する必要がありました。これで、 beam.CombineFn実装を使用して、TFグラフの外部でメトリックを計算できます。

主な違いのいくつかは次のとおりです。

  • EvalSavedModelにはトレーナーからの特別なエクスポートが必要ですが、サービングモデルはトレーニングコードに変更を加えることなく使用できます。
  • EvalSavedModelを使用すると、トレーニング時に追加されたすべてのメトリックが評価時に自動的に使用可能になります。 EvalSavedModelがない場合、これらのメトリックを再度追加する必要があります。
    • このルールの例外は、kerasモデルが使用されている場合、kerasは保存されたモデルと一緒にメトリック情報を保存するため、メトリックを自動的に追加することもできます。

TFMAは、グラフ内のメトリックと外部のメトリックの両方で機能しますか?

TFMAを使用すると、一部のメトリックをグラフ内で計算でき、他のメトリックを外部で計算できるハイブリッドアプローチを使用できます。現在EvalSavedModelをお持ちの場合は、引き続き使用できます。

2つのケースがあります:

  1. 特徴抽出とメトリック計算の両方にEvalSavedModelを使用しますが、コンバイナーベースのメトリックを追加します。この場合、以前はサポートされていなかった可能性のあるコンバイナーベースの追加のメトリックとともに、 EvalSavedModelからすべてのグラフ内メトリックを取得します。
  2. 特徴/予測の抽出にはEvalSavedModelを使用しますが、すべてのメトリックの計算にはコンバイナーベースのメトリックを使用します。このモードは、スライスに使用したいが、グラフの外側ですべてのメトリック計算を実行したい場合に、 EvalSavedModelに機能変換が存在する場合に役立ちます。

設定

どのモデルタイプがサポートされていますか?

TFMAは、kerasモデル、汎用TF2シグネチャAPIに基づくモデル、およびTF Estimatorベースのモデルをサポートします(ただし、ユースケースによっては、EstimatorベースのモデルでEvalSavedModelを使用する必要がある場合があります)。

サポートされているモデルタイプの完全なリストと制限については、 get_startedガイドを参照してください。

ネイティブのkerasベースのモデルで動作するようにTFMAを設定するにはどうすればよいですか?

以下は、以下の仮定に基づくkerasモデルの設定例です。

  • 保存されたモデルはサービング用であり、署名名serving_defaultを使用します(これはmodel_specs[0].signature_nameを使用して変更できます)。
  • model.compile(...)からの組み込みメトリックを評価する必要があります(これは、 tfma.EvalConfig内のoptions.include_default_metricを介して無効にできます)。
from google.protobuf import text_format

config = text_format.Parse("""
  model_specs {
    label_key: "<label-key>"
    example_weight_key: "<example-weight-key>"
  }
  metrics_specs {
    # Add metrics here. For example:
    #  metrics { class_name: "ConfusionMatrixPlot" }
    #  metrics { class_name: "CalibrationPlot" }
  }
  slicing_specs {}
""", tfma.EvalConfig())

構成可能な他のタイプのメトリックの詳細については、メトリックを参照してください。

一般的なTF2シグニチャベースのモデルで動作するようにTFMAを設定するにはどうすればよいですか?

以下は、一般的なTF2モデルの構成例です。以下のsignature_nameは、評価に使用する必要がある特定の署名の名前です。

from google.protobuf import text_format

config = text_format.Parse("""
  model_specs {
    signature_name: "<signature-name>"
    label_key: "<label-key>"
    example_weight_key: "<example-weight-key>"
  }
  metrics_specs {
    # Add metrics here. For example:
    #  metrics { class_name: "BinaryCrossentropy" }
    #  metrics { class_name: "ConfusionMatrixPlot" }
    #  metrics { class_name: "CalibrationPlot" }
  }
  slicing_specs {}
""", tfma.EvalConfig())

構成可能な他のタイプのメトリックの詳細については、メトリックを参照してください。

推定量ベースのモデルで動作するようにTFMAを設定するにはどうすればよいですか?

この場合、3つの選択肢があります。

オプション1:サービングモデルを使用する

このオプションを使用すると、トレーニング中に追加されたメトリックは評価に含まれません。

以下は、 serving_defaultが使用されるシグニチャ名であると想定した設定例です。

from google.protobuf import text_format

config = text_format.Parse("""
  model_specs {
    label_key: "<label-key>"
    example_weight_key: "<example-weight-key>"
  }
  metrics_specs {
    # Add metrics here.
  }
  slicing_specs {}
""", tfma.EvalConfig())

構成可能な他のタイプのメトリックの詳細については、メトリックを参照してください。

オプション2:追加のコンバイナーベースのメトリックとともにEvalSavedModelを使用する

この場合、特徴/予測の抽出と評価の両方にEvalSavedModelを使用し、コンバイナーベースのメトリックを追加します。

以下は設定例です。

from google.protobuf import text_format

config = text_format.Parse("""
  model_specs {
    signature_name: "eval"
  }
  metrics_specs {
    # Add metrics here.
  }
  slicing_specs {}
""", tfma.EvalConfig())

構成可能な他のタイプのメトリックの詳細についてはメトリックを、 EvalSavedModelの設定の詳細についてはEvalSavedModelを参照してください。

オプション3:特徴/予測の抽出にのみEvalSavedModelモデルを使用する

option(2)に似ていますが、特徴/予測の抽出にEvalSavedModelのみを使用します。このオプションは、外部メトリックのみが必要であるが、スライスしたい機能変換がある場合に役立ちます。オプション(1)と同様に、トレーニング中に追加されたメトリックは評価に含まれません。

この場合、構成は上記と同じですが、 include_default_metricsのみが無効になっています。

from google.protobuf import text_format

config = text_format.Parse("""
  model_specs {
    signature_name: "eval"
  }
  metrics_specs {
    # Add metrics here.
  }
  slicing_specs {}
  options {
    include_default_metrics { value: false }
  }
""", tfma.EvalConfig())

構成可能な他のタイプのメトリックの詳細についてはメトリックを、 EvalSavedModelの設定の詳細についてはEvalSavedModelを参照してください。

TFMAをkerasモデルから推定量ベースのモデルで動作するように設定するにはどうすればよいですか?

keras model_to_estimatorの設定は、Estimatorの構成に似ています。ただし、モデルから推定量への動作に固有のいくつかの違いがあります。特に、model-to-esimtatorは、dictの形式で出力を返します。ここで、dictキーは、関連付けられたkerasモデルの最後の出力レイヤーの名前です(名前が指定されていない場合、kerasはデフォルトの名前を選択します) dense_1output_1など)。 TFMAの観点からは、この動作は、推定器へのモデルが単一のモデルのみである場合でも、複数出力モデルの場合に出力されるものと似ています。この違いを説明するために、出力名を設定するための追加の手順が必要です。ただし、同じ3つのオプションがEstimatorとして適用されます。

以下は、Estimatorベースの構成に必要な変更の例です。

from google.protobuf import text_format

config = text_format.Parse("""
  ... as for estimator ...
  metrics_specs {
    output_names: ["<keras-output-layer>"]
    # Add metrics here.
  }
  ... as for estimator ...
""", tfma.EvalConfig())

事前に計算された(つまり、モデルにとらわれない)予測を処理するようにTFMAを設定するにはどうすればよいですか? ( TFRecordおよびtf.Example

事前に計算された予測を処理するようにTFMAを構成するには、デフォルトのtfma.PredictExtractorを無効にし、他の入力機能とともに予測を解析するようにtfma.InputExtractorを構成する必要があります。これは、ラベルと重みとともに予測に使用される機能キーの名前を使用してtfma.ModelSpecを構成することによって実現されます。

以下はセットアップ例です。

from google.protobuf import text_format

config = text_format.Parse("""
  model_specs {
    prediction_key: "<prediction-key>"
    label_key: "<label-key>"
    example_weight_key: "<example-weight-key>"
  }
  metrics_specs {
    # Add metrics here.
  }
  slicing_specs {}
""", tfma.EvalConfig())

構成可能なメトリックの詳細については、メトリックを参照してください。

tfma.ModelSpecが構成されている間は、モデルが実際には使用されていないことに注意してください(つまり、 tfma.EvalSharedModelはありません)。モデル分析を実行するための呼び出しは、次のようになります。

eval_result = tfma.run_model_analysis(
    eval_config=eval_config,
    # This assumes your data is a TFRecords file containing records in the
    # tf.train.Example format.
    data_location="/path/to/file/containing/tfrecords",
    output_path="/path/for/metrics_for_slice_proto")

事前に計算された(つまり、モデルにとらわれない)予測を処理するようにTFMAを設定するにはどうすればよいですか? ( pd.DataFrame

メモリに収まる小さなデータセットの場合、 pandas.DataFrameの代わりにTFRecordを使用します。 TFMAは、 tfma.analyze_raw_data pandas.DataFrame操作できます。 tfma.MetricsSpecおよびtfma.SlicingSpecの説明については、セットアップガイドを参照してください。構成可能なメトリックの詳細については、メトリックを参照してください。

以下はセットアップ例です。

# Run in a Jupyter Notebook.

df_data = ...  # your pd.DataFrame

eval_config = text_format.Parse("""
  model_specs {
    label_key: 'label'
    prediction_key: 'prediction'
  }
  metrics_specs {
    metrics { class_name: "AUC" }
    metrics { class_name: "ConfusionMatrixPlot" }
  }
  slicing_specs {}
  slicing_specs {
    feature_keys: 'language'
  }
""", config.EvalConfig())

eval_result = tfma.analyze_raw_data(df_data, eval_config)

tfma.view.render_slicing_metrics(eval_result)

指標

どのような種類のメトリックがサポートされていますか?

TFMAは、次のようなさまざまなメトリックをサポートしています。

マルチ出力モデルのメトリックはサポートされていますか?

はい。詳細については、メトリックガイドを参照してください。

複数のモデルからのメトリックはサポートされていますか?

はい。詳細については、メトリックガイドを参照してください。

メトリック設定(名前など)をカスタマイズできますか?

はい。メトリック設定にconfig設定を追加することにより、メトリック設定をカスタマイズできます(たとえば、特定のしきい値の設定など)。詳細については、メトリクスガイドを参照してください。

カスタムメトリックはサポートされていますか?

はい。カスタムtf.keras.metrics.Metric beam.CombineFnを作成します。メトリックガイドに詳細があります。

どのタイプのメトリックがサポートされていませんか?

メトリックがbeam.CombineFnを使用して計算できる限り、 beam.CombineFnに基づいて計算できるメトリックのタイプに制限はありませtfma.metrics.Metrictf.keras.metrics.Metricから派生したメトリックを使用する場合は、次の基準を満たす必要があります。

  • 各例のメトリックの十分統計量を個別に計算し、すべての例にそれらを追加してこれらの十分統計量を組み合わせ、これらの十分統計量のみからメトリック値を決定することが可能である必要があります。
  • たとえば、正確さのために十分な統計は「完全に正しい」と「完全な例」です。個々の例についてこれら2つの数値を計算し、それらを例のグループに合計して、それらの例に適切な値を取得することができます。最終的な精度は、「完全な正しい/完全な例」を使用して計算できます。

アドオン

TFMAを使用して、モデルの公平性またはバイアスを評価できますか?

TFMAには、分類モデルにおける意図しないバイアスの影響を評価するためのエクスポート後のメトリックを提供するFairnessIndicatorsアドオンが含まれています。

カスタマイズ

さらにカスタマイズが必要な場合はどうなりますか?

TFMAは非常に柔軟性があり、カスタムExtractorsEvaluatorsWritersを使用してパイプラインのほぼすべての部分をカスタマイズできます。これらのアブストラクションについては、アーキテクチャドキュメントで詳しく説明されています。

トラブルシューティング、デバッグ、およびヘルプの取得

MultiClassConfusionMatrixメトリックが2値化されたConfusionMatrixメトリックと一致しないのはなぜですか

これらは実際には異なる計算です。二値化は、各クラスIDの比較を個別に実行します(つまり、各クラスの予測は、提供されたしきい値と個別に比較されます)。この場合、2つ以上のクラスがすべて、予測値がしきい値よりも大きかったため、予測に一致したことを示す可能性があります(これは、しきい値が低いほどさらに顕著になります)。マルチクラス混同行列の場合、真の予測値は1つだけであり、実際の値と一致するか、一致しないかのどちらかです。しきい値は、予測がしきい値よりも小さい場合に、クラスが一致しないように予測を強制するためにのみ使用されます。しきい値が高いほど、2値化されたクラスの予測が一致しにくくなります。同様に、しきい値が低いほど、2値化されたクラスの予測が一致しやすくなります。つまり、しきい値が0.5を超えると、2値化された値とマルチクラス行列の値がより近くに整列し、しきい値が0.5未満の場合はさらに離れます。

たとえば、クラス2が0.8の確率で予測された10個のクラスがあるが、実際のクラスは0.15の確率を持つクラス1であったとします。クラス1で2値化し、しきい値0.1を使用すると、クラス1は正しいと見なされるため(0.15> 0.1)、TPとしてカウントされます。ただし、マルチクラスの場合、クラス2は正しいと見なされます(0.8> 0.1)そしてクラス1が実際だったので、これはFNとしてカウントされます。より低いしきい値では、より多くの値が正と見なされるため、一般に、2値混同行列のTPおよびFPカウントは、マルチクラス混同行列よりも高くなり、同様にTNおよびFNも低くなります。

以下は、MultiClassConfusionMatrixAtThresholdsと、クラスの1つの2値化からの対応するカウントとの間に観察された違いの例です。

MultiClassConfusionMatrixAtThresholdsと2値化

Precision@1とrecall@1のメトリックが同じ値になるのはなぜですか?

最高のk値が1の場合、適合率と再現率は同じです。適合率はTP / (TP + FP)に等しく、再現率はTP / (TP + FN)に等しくなります。上位の予測は常に正であり、ラベルと一致するか一致しないかのいずれかです。つまり、 Nの例では、 TP + FP = Nです。ただし、ラベルが上位の予測と一致しない場合は、上位k以外の予測が一致し、上位kが1に設定されている場合、上位1以外のすべての予測は0になります。これは、FNが(N - TP)またはN = TP + FN 。最終結果は、 precision@1 = TP / N = recall@1です。これは、マルチラベルではなく、例ごとに単一のラベルがある場合にのみ適用されることに注意してください。

mean_labelとmean_predictionのメトリックが常に0.5であるのはなぜですか?

これは、メトリックがバイナリ分類問題用に構成されているために発生する可能性が最も高いですが、モデルは1つだけではなく両方のクラスの確率を出力しています。これは、テンソルフローの分類APIが使用されている場合に一般的です。解決策は、予測の基にするクラスを選択してから、そのクラスを2値化することです。例えば:

eval_config = text_format.Parse("""
  ...
  metrics_specs {
    binarize { class_ids: { values: [0] } }
    metrics { class_name: "MeanLabel" }
    metrics { class_name: "MeanPrediction" }
    ...
  }
  ...
""", config.EvalConfig())

MultiLabelConfusionMatrixPlotを解釈する方法は?

特定のラベルが与えられると、 MultiLabelConfusionMatrixPlot (および関連するMultiLabelConfusionMatrix )を使用して、選択したラベルが実際に真であった場合の、他のラベルの結果とそれらの予測を比較できます。たとえば、 birdplanesupermanの3つのクラスがあり、これらのクラスのいずれかが1つ以上含まれているかどうかを示すために写真を分類しているとします。 MultiLabelConfusionMatrixは、実際の各クラスのデカルト積を他のクラス(予測クラスと呼ばれる)に対して計算します。ペアリングは(actual, predicted)ですが、 predictedたクラスは必ずしも正の予測を意味するわけではなく、実際の行列と予測された行列の予測された列を表すだけであることに注意してください。たとえば、次の行列を計算したとします。

   (bird, bird)         ->    { tp: 6, fp: 0, fn: 2, tn: 0}
   (bird, plane)        ->    { tp: 2, fp: 2, fn: 2, tn: 2}
   (bird, superman)     ->    { tp: 1, fp: 1, fn: 4, tn: 2}
   (plane, bird)        ->    { tp: 3, fp: 1, fn: 1, tn: 3}
   (plane, plane)       ->    { tp: 4, fp: 0, fn: 4, tn: 0}
   (plane, superman)    ->    { tp: 1, fp: 3, fn: 3, tn: 1}
   (superman, bird)     ->    { tp: 3, fp: 2, fn: 2, tn: 2}
   (superman, plane)    ->    { tp: 2, fp: 3, fn: 2, tn: 2}
   (superman, superman) ->    { tp: 4, fp: 0, fn: 5, tn: 0}

   num_examples: 20

MultiLabelConfusionMatrixPlotには、このデータを表示する3つの方法があります。すべての場合において、テーブルを読み取る方法は、実際のクラスの観点から行ごとです。

1)合計予測カウント

この場合、特定の行(つまり実際のクラス)について、他のクラスのTP + FPカウントは何でしたか。上記のカウントの場合、表示は次のようになります。

予測される鳥予測される飛行機予測されるスーパーマン
実際の鳥6 4 2
実際の平面4 4 4
実際のスーパーマン5 5 4

写真に実際にbirdが含まれている場合、そのうちの6つを正しく予測しました。同時に、 plane (正しくまたは間違って)を4回、 superman (正しくまたは間違って)を2回予測しました。

2)誤った予測カウント

この場合、特定の行(つまり実際のクラス)について、他のクラスのFPカウントは何でしたか。上記のカウントの場合、表示は次のようになります。

予測される鳥予測される飛行機予測されるスーパーマン
実際の鳥0 2 1
実際の平面1 0 3
実際のスーパーマン2 3 0

写真に実際にbirdが含まれている場合、 planeを2回、 supermanを1回誤って予測しました。

3)偽の負のカウント

この場合、特定の行(つまり実際のクラス)について、他のクラスのFNカウントは何でしたか。上記のカウントの場合、表示は次のようになります。

予測される鳥予測される飛行機予測されるスーパーマン
実際の鳥2 2 4
実際の平面1 4 3
実際のスーパーマン2 2 5

写真に実際にbirdが含まれているとき、私たちはそれを2回予測できませんでした。同時に、 planeを2回、 supermanを4回予測できませんでした。

予測キーが見つからないというエラーが表示されるのはなぜですか?

一部のモデルは、予測を辞書の形式で出力します。たとえば、二項分類問題のTF推定器は、 probabilitiesclass_idsなどを含む辞書を出力します。ほとんどの場合、TFMAには、 predictionsprobabilitiesなどの一般的に使用されるキー名を検索するためのデフォルトがあります。ただし、モデルが非常にカスタマイズされている場合は、 TFMAが認識していない名前でキーを出力します。このような場合、出力が保存されているキーの名前を識別するために、 prediciton_key設定をtfma.ModelSpecに追加する必要があります。