テンソルフロー検証モニタリングストリーミングauc

Question

tensorflowバリデーションモニタストリーミングaucでは、ストリーミングはどういう意味ですか？

モニタを100ステップごとに呼び出すようにevery_n_steps = 100を設定するとします。

また、検証モニタのinput_fn関数がデータのストリーミングを生成するとします。 10バッチを想定しましょう。

ケース1：検証モニタが呼び出されるたびにaucの状態がリセットされます。そこでは、各検証ステップで10バッチのストリーミングが実行されます。

ケース2：auc状態はリセットされないので、ストリーミングaucは検証モニタの最初の呼び出しから計算されます。すなわち、第1の出力（100ステップで）は10バッチから計算され、第2の検証出力（200ステップで）は第1のコール後のストリーミングaucおよびフィードされた10バッチに基づいて計算される。ステップ）は、2回目のコール後のストリーミングaucと10回分のバッチに基づいて計算されます。

Question1、どちらのシナリオが実装されていますか？

質問2、tf.metrics.aucを使用した場合、違いは何ですか？

これらの変数を更新してaucを返すupdate_op操作を作成します。

これもストリームAUCを計算しますか？

Answer 1

答えはケース1です。ValidationMonitorは、モデルをチェックポイントからリロードするEstimatorのevaluate（）を呼び出します。 Metricsがハングする統計を含むローカル変数はチェックポイントに保存されません。チェックポイントがリロードされた後、それらはゼロから再初期化されます。

複数の評価ステップ（の引数がValidationMonitorで制御）を組み合わせることができるように、メトリックは常にストリーミングされます。しかし、この集約はevaluate()のステップ内にのみあります。 tf.metrics.auc対tf.contrib.streaming_aucとして

、後者はコアTensorFlowにあり（それはおそらくビットについてstreaming_aucとしてcontribでぶらぶらした後、そこに移動された）APIの安定性を保証しています。それらは同等でなければなりません。contribのバージョンで、使いたいファンシーな新機能が追加されない限り、コアバージョンが適しています（ここでは該当しません）。