Update SequenceLoss for TensorFlow 2.2 compatibility

[guillaumekln]

For previous versions, we removed the reduction attribute to force tf.keras to call the main __call__ method. Otherwise, it calls the call method where we have no way of controlling the reduction logic.

In 2.2, tf.keras has a new way of dealing with loss objects (see the LossContainer class). It now always calls __call__ and requires the reduction attribute to exist.

This new logic is only enabled for V2 execution mode so this commit also disables the deprecated V1 graph mode for this test.

Related to #1320.

Note: this change is only compatible with TensorFlow 2.2 so I'm opening a draft PR for now.

[gabrieldemarmiesse]

I guess the easiest solution is to do a version check before deleting the reduction.

But having a custom reduction prevents us from using a distributed strategy (from what I remember). Would it be possible to use keras' built-in reductions for some use cases (not all)?

[guillaumekln]

I guess the easiest solution is to do a version check before deleting the reduction.

I suppose the project will shortly move to require TensorFlow 2.2, right? Then we could merge this PR as is (after a rebase).

But having a custom reduction prevents us from using a distributed strategy (from what I remember). Would it be possible to use keras' built-in reductions for some use cases (not all)?

I'm not sure it prevents the use of distribution strategies, but it requires the user to carefully scale the loss (or gradients) based on the global batch size.

We could indeed rely on the built-in reduction for some combinations. But these combinations are actually the ones that can be implemented with tf.keras.losses.{Sparse}CategoricalCrossentropy.

[gabrieldemarmiesse]

I suppose the project will shortly move to require TensorFlow 2.2, right?

To improve the UX, we'd like the python code to be compatible with as many versions of TF as possible. The custom ops will only be compatible with a specific python wheel. See #1317 (comment)

We could indeed rely on the built-in reduction for some combinations. But these combinations are actually the ones that can be implemented with tf.keras.losses.{Sparse}CategoricalCrossentropy.

Iet's let you do what you think is best here.

[seanpmorgan]

Thanks @guillaumekln!

Just wanted to note that this is the last component of #1320 and will block a release built with TF2.2 once it is released.

@qlzh727 Could you review when time allows and advise how best to handle this change in 2.2

[qlzh727]

@pavithrasv who works on all Keras losses for more input.

[guillaumekln]

Iet's let you do what you think is best here.

@gabrieldemarmiesse I propose to just make a bug fix in this PR and try to not change the behavior. Maybe @pavithrasv has more recommendation on how to deal with custom loss reduction.

[gabrieldemarmiesse]

Let's merge it as it's a good step forward. We can open an issue to see how to replace the __call__ which is a private keras API.

[gabrieldemarmiesse]

Thanks again for the fix!