pos_weight: Why Sigmoid Scores Shift from the Original Probability
After setting pos_weight in BCEWithLogitsLoss, a sigmoid output remains between zero and one. That range does not establish that it estimates the positive-class probability in the original data distribution. Positive weighting changes the objective. Under an ideal pointwise optimum, weight a maps the true conditional probability q to p*=aq/(aq+1−q).
Contents
- Positive weight changes the positive term
- Find the optimum for one fixed input
- The meaning of a 0.5 cutoff changes
- Twelve checks reproduce the algebra
- An inverse formula is not automatic calibration
- Validate training, probabilities and decisions separately
- Check label meaning and tensor alignment first
- Make the output meaning part of the interface
- Sources and backfill note
This explains why a familiar 0.5 cutoff deserves another look after weighting. The derivation below leads to twelve exact-arithmetic checks, followed by the limits of using the mapping for diagnosis. It is not a calibration guarantee for a trained network. 中文版.
Positive weight changes the positive term
The official PyTorch definition scales the positive-label logarithmic term using pos_weight. Here the setting is one binary label, hard targets y∈{0,1}, a constant a>0 and no additional sample weights. Multilabel problems can be examined class by class, but different class weights must not be collapsed into one number.
Let z be a model logit and p=sigmoid(z). Write the per-example loss as ℓ(p,y)=−ay log p−(1−y)log(1−p). The API itself takes logits. Rewriting the function in terms of p makes the optimum easier to see; it is not advice to apply sigmoid before passing a value into BCEWithLogitsLoss.
Multiplying an entire loss by the same constant for every example is different from increasing only the positive term. A common positive constant does not move an unregularized objective’s mathematical optimum, although it can affect finite-step optimization. Positive-only weighting changes the relative cost of the labels. Two settings containing the word weight need not have the same statistical meaning.
Find the optimum for one fixed input
Fix features x and let q=P(y=1|x), with 0<q<1. The model returns the same p for that x. Taking the expectation over labels gives conditional risk R(p)=−aq log p−(1−q)log(1−p). This turns the emphasis on positives into a function whose stationary point can be derived.
Set R′(p)=−aq/p+(1−q)/(1−p)=0. Rearranging yields aq(1−p)=(1−q)p, hence p*=aq/(aq+1−q). The second derivative is R″(p)=aq/p²+(1−q)/(1−p)²>0. It is therefore the unique minimum inside the interval.
When a=1, p*=q. For a>1 and q strictly between zero and one, p*>q. The upward shift is consistent with the objective requested. It does not establish that a finite-data training run reaches that analytical optimum exactly.
The meaning of a 0.5 cutoff changes
Under this ideal mapping, p*>0.5 is equivalent to q>1/(a+1). With a=4, a score of 0.5 corresponds to q=0.2; with a=9, it corresponds to q=0.1. Applying the same numerical cutoff to the weighted score therefore does not preserve a decision boundary at true probability 0.5.
In the synthetic q=0.2 case, increasing a from one to four moves the optimum from 0.2 to 0.5. The conditional label distribution has not become half positive. Specify how equality at a cutoff is handled as well: greater-than and greater-than-or-equal rules can classify a boundary example differently.
For a desired true-probability threshold t, with 0<t<1, the corresponding ideal weighted-score threshold is at/(at+1−t). At a=4 and t=0.5 it is 0.8. This conversion explains the score scale; it does not replace choosing and testing a threshold on real validation data.
Twelve checks reproduce the algebra
The code uses only Python’s Fraction type. Four (q,a) pairs each check the stationary derivative and inverse mapping. Two concrete scores and derivative signs on either side of one minimum complete twelve assertions.
# Exact population-risk algebra, not a trained PyTorch model.
from fractions import Fraction as F
def optimal_score(q, a):
return a*q / (a*q + 1-q)
def recover_q(p, a):
return p / (a-(a-1)*p)
def derivative(p, q, a):
return -a*q/p + (1-q)/(1-p)
for q,a in [(F(1,5),F(4)), (F(1,10),F(9)),
(F(3,5),F(2)), (F(2,5),F(1))]:
p = optimal_score(q,a)
assert derivative(p,q,a) == 0
assert recover_q(p,a) == q
assert optimal_score(F(1,5),F(4)) == F(1,2)
assert optimal_score(F(1,10),F(4)) == F(4,13)
assert derivative(F(2,5),F(1,5),F(4)) < 0
assert derivative(F(3,5),F(1,5),F(4)) > 0
print("12 weighted-BCE checks passed")
The local run printed “12 weighted-BCE checks passed”. These checks establish relationships in the specified risk function. No PyTorch model was trained, and accuracy, recall, calibration error and GPU performance were not measured. Together with strict convexity, the derivative signs explain why p=0.5 minimizes the chosen example.
An inverse formula is not automatic calibration
Solving the mapping backwards gives q=p*/[a−(a−1)p*]. Equivalently, at the ideal optimum logit(p*)=logit(q)+log a. Constant positive weighting therefore has an interpretation as a shift in log odds under these assumptions.
That provides a diagnostic question: if a changed but downstream code still treats the output as an unweighted probability, revisit the output contract. It does not justify subtracting log a from every measured logit and declaring calibration complete. Model capacity, regularization, optimization error, finite samples and label noise can all prevent the ideal relationship from holding exactly.
Sampling changes the problem too. After positive oversampling, q may already refer to the sampled training distribution. Adding pos_weight then weights that distribution’s objective. Recovering deployment probabilities requires the relevant sampling and distribution assumptions; a single a cannot correct every source of shift.
Validate training, probabilities and decisions separately
The scikit-learn threshold guide distinguishes learning scores from deciding actions, and warns against training a model and tuning its threshold on the same data. A project should first say whether it needs ranking scores, reliable probabilities or labels under a specific constraint. Those outputs need different acceptance evidence. A single fixed, strictly increasing transformation of ideal scores preserves their ordering, but changes their numerical interpretation; actual retraining can also change ordering because the fitted model need not attain the pointwise optimum.
During fitting, record the positive-label definition, sampling scheme, pos_weight and data version. During validation, inspect confusion matrices and the chosen metric across thresholds. If probabilities matter, assess calibration through a suitable hold-out or cross-validation design. Reserve final test data for reporting rather than repeatedly selecting the most attractive cutoff from it.
An increase in recall alone does not establish overall improvement. Moving a threshold can also change false positives and precision. Keep those changes in the same validation record. No application-specific threshold is recommended here because no project data, constraints or measured outcomes were supplied.
Check label meaning and tensor alignment first
In an actual investigation, first verify what y=1 means and which class receives each weight. A multilabel task can have a different a for every class. If class order changes while weight order stays fixed, the loss can still return a number while optimizing the wrong target.
Broadcastability is also weaker than semantic correctness. A shape that broadcasts may not act along the class dimension intended. Use small artificial logits and labels to inspect unreduced loss values term by term, checking the intended positive and negative contributions before connecting the complete training loop. A falling mean loss is not enough to establish correct alignment.
This connects to the earlier gradient accumulation loss-averaging article: plausible numbers do not prove the objective is right. That topic examines reduction across examples; this one examines relative positive and negative weighting. Check the two independently.
Make the output meaning part of the interface
If another component displays scores or compares them across model versions, record whether it receives raw logits, sigmoid scores or validated probability estimates. Preserve the training-weight and threshold versions too. A decimal constrained to zero through one leaves too much for downstream users to guess.
Positive weighting can be useful, but it changes the objective. State that change first, then use independent data to judge ranking, probability and decision performance. If the derivation and reproducible code help prevent a score-interpretation mistake, voluntary support through the section below is welcome.
Sources and backfill note
The definition was checked against PyTorch 2.8 documentation and threshold guidance against scikit-learn documentation. The derivation, twelve fraction checks and two figures are original teaching material. The article retains October 18, 2026 at 14:00 Beijing time as its planned date and was backfilled on October 19, 2026; that date does not establish earlier public availability.
Support
If the explanations or examples helped you solve a problem or save time, you’re welcome to support this site with a voluntary tip.
Click a QR code to enlarge. More options: support page。


