CompositeLossMetrics
now performs a weighted sum of losses.
#1251
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently,
CompositeLossMetrics
sums the losses without considering their weights (i.e., the number of live targets). To make this a weighted sum, downstream code has been implementingCompositeLossWeights
to inject the number of live targets intoloss_weights
. This is essentially patching a surprising logic (initail loss sum) with complex logic (CompositeLossWeights) into a straightforward one (weighted sum).Therefore, we’re changing the default loss aggregation logic to be straightforward from the beginning.
From now on, our standarized loss aggregation logic is
Historically, the complex logic was introduced because the weights of losses returned by child metrics were unknown. But now that child metrics return losses as
WeightedScalar
, we can adopt a simpler, cleaner aggregation logic.Note: alternative formulation could be
However, when num_each_samples is large and each_loss_weight is small, the denominator can become disproportionately large. So we discard this option.