You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When optimizing for Recall (minimizing FNR), only label positive samples are considered for computing the loss or its gradient;
However, passing a gradient of zero for all label negatives leads to weird behavior in the GBM::Train function;
So, for now, we're scaling down the gradient of all label negatives by multiplying them with a tiny positive number: see the label_negative_weight in ConstrainedRecallObjective::GetGradients;
This shouldn't be needed, but seems to temporarily fix the issue with no unintended consequences (as the gradient flowing is very small);
Reproducible example
Omit the else clause in ConstrainedRecallObjective::GetGradients, which deals with label negative samples, and in theory should not be needed for optimizing for recall;
Compile and run, and observe weird "-inf split" messages, which can lead to training stopping too early;
The text was updated successfully, but these errors were encountered:
Description
GBM::Train
function;label_negative_weight
inConstrainedRecallObjective::GetGradients
;Reproducible example
ConstrainedRecallObjective::GetGradients
, which deals with label negative samples, and in theory should not be needed for optimizing for recall;The text was updated successfully, but these errors were encountered: