Implement Metric Losses

[seanpmorgan]

Per the RFC, we need to move metric_losses from contrib to addons:

• pairwise_distance
• contrastive_loss
• triplet_semihard_loss
• npairs_loss
• npairs_loss_multilabel
• lifted_struct_loss

This will involve inheriting from base Keras Loss, modifying the code to match those APIs, and modifying test cases to run in TF2.

[supercontracts]

Hi @seanpmorgan, from tensorflow testing meeting of 5th Feb, I liked the idea of saving useful parts from tf.contrib and add it to a add-on repo for tf-2.0 and would like to contribute to the same :). Can I contribute to this as I am not a gde and is this a good issue to start with

[facaiy]

@tabshaikh Welcome, Tabish! I think, in all those functions, triplet_semihard_loss and lifted_struct_loss are easy to be implemented. I am in the process of moving triplet_semihard_loss (nearly finished), and I'll create a PR tomorrow if everything goes well (I'm on holiday).

I think lifted_struct_loss is a good starter issue, would you like to take a try?

[supercontracts]

@facaiy sure I would like to give lifted_struct_loss a try

[WindQAQ]

Hello @seanpmorgan and @facaiy, I think I can take a look at the remaining losses. Is there anyone already responsible for these? If not, I'd like to give it a try. Thank you!

[facaiy]

Welcome, @WindQAQ . I don't know anyone is working on them, so yes, just go head.

By the way, I think #25 is easier for new contributor. Perhaps you are interested on it as well. Anyway, thanks for your help. Just ping us (or join https://gitter.im/tensorflow/sig-addons) if you need any help :-)

[WindQAQ]

Okay. It's also free for me to deal with image functions first. Thanks for your quick reply 😃

[WindQAQ]

Hey guys, because all losses in addons must inherit from keras.losses.LossfunctionWrapper, I have some API design issues here:

Since fn, which is passed into LossFunctionWrapper, should be with two positional arguments, however, contrastive_loss, npairs_loss and npairs_loss_multilabel implemented in contrib are with three arguments.

My initial thought is that (take contrastive_loss for example):

embeddings_anchor and embeddings_positive can be stacked to one tensor, and we can split it manually in addons implementation. Thus, the interface should be like

def contrastive_loss(y_true, y_pred):
    embeddings_anchor = y_pred[0] # suppose they are stacked along with axis 0
    embeddings_positive = y_pred[1]
    # and so on

class ContrastiveLoss(LossFunctionWrapper):
    def __init__(self, name):
        super(ContrastiveLoss, self).__init__(fn=contrastive_loss, name=name)

One drawback here is that users should manipulate this stacked tensor on their own, which is not so intuitive though. Any feedback or thought would be really appreciated. Thanks!

[facaiy]

@martinwicke @fchollet Could you give us some advice for @WindQAQ 's question?

[fchollet]

The Loss class fundamentally assumes that a signature with 3 tensor arguments, y_true, y_pred, and sample_weight. We can't go around it.

I think the right pattern here isn't a Loss subclass but a Layer subclass. Here's how it would work.

class ContrastiveLossLayer(keras.layers.Layer):

  def __init__(self, name=None):
    super(ContrastiveLossLayer, self).__init__(name=name)

  def __call__(self, y_true, positive, negative):
    # Pack all arguments in the first argument (optional, to expose a better __call__ signature)
    return super(LogisticHead, self).__call__([y_true, positive, negative])

  def call(self, inputs):
    y_true, positive, negative = inputs[0], inputs[1], inputs[2]
    loss = ...
    inference_time_predictions = ...
    self.add_loss(loss)
    return inference_time_predictions

Then to use it, you just insert it in your model as you would do for a regular layer (see the logistic loss layer example I linked).

[WindQAQ]

Thanks for the suggestion! I do think this pattern is more flexible and beneficial to future extension.
@seanpmorgan and @facaiy, do you think addons can adopt this kind of design pattern instead of inheritance from LossFunctionWrapper as a unified interface. Or we can inherit from LossFunctionWrapper when it's possible but inherit from Layer when it comes to ContrastiveLoss case. Many thanks!

[facaiy]

I'm fine with inheriting from Layer, but I'm not sure which module is appropriate for this kind of loss, tfa.layer or tfa.loss. @WindQAQ Could you pick one loss, say ContrastiveLossLayer, and write an example to show us how to use it with keras model?