What does class_weight='balanced' compute, and which scikit-learn estimators accept it?

## The formula `class_weight='balanced'` is a request for automatically computed weights that are inversely proportional to class frequency. The concrete formula, which `sklearn.utils.class_weight.compute_class_weight` implements and every supporting estimator uses, is: `weight_for_class_k = n_samples / (n_classes * count_of_class_k)` On a binary problem with 950 negatives and 50 positives, that is `1000 / (2 * 950) ≈ 0.526` for the majority class and `1000 / (2 * 50) = 10.0` for the minority. The weights are normalized such that a perfectly balanced dataset produces all-ones — that is why the majority weight is slightly below 1 rather than exactly 1. Each sample's contribution to the training loss is then multiplied by its class weight, so getting a minority sample wrong costs roughly nineteen times what a majority mistake costs. You are not limited to `'balanced'`. Passing an explicit dict — `class_weight={0: 1.0, 1: 8.0}` — sets the ratio yourself, which is what you want when the real cost asymmetry is a business fact rather than a frequency artifact. A false negative on a fraud model might cost 300x a false positive regardless of what the class balance happens to be this quarter. ## Which estimators expose it The parameter is a constructor argument, not universal. Present on: - `LogisticRegression`, `LogisticRegressionCV`, `SGDClassifier`, `RidgeClassifier`, `Perceptron`, `PassiveAggressiveClassifier` - `SVC`, `NuSVC`, `LinearSVC` - `DecisionTreeClassifier`, `ExtraTreeClassifier`, `RandomForestClassifier`, `ExtraTreesClassifier` - `HistGradientBoostingClassifier` Absent on `GradientBoostingClassifier`, on `KNeighborsClassifier`, on `GaussianNB`, and on every regressor (there are no classes to weight). Where it is absent but `fit` accepts `sample_weight`, you build the per-row weights yourself — `compute_sample_weight('balanced', y)` does exactly that — and pass them to `fit`. That is the standard workaround for `GradientBoostingClassifier`. `RandomForestClassifier` and `ExtraTreesClassifier` carry an extra option, `'balanced_subsample'`. Plain `'balanced'` computes the weights once from the full `y`; `'balanced_subsample'` recomputes them on every bootstrap sample, so a tree whose bootstrap happened to draw few minority rows reweights accordingly. On heavily imbalanced data the difference is real but usually second-order compared to whether you weighted at all. ## What weighting does and does not do **Does:** change the loss surface, so the fitted decision boundary moves toward the minority class. In a tree, weights flow into the impurity computation, so splits that isolate minority samples look more attractive. In a linear model, the weighted log-loss simply penalizes minority errors harder. **Does not:** change the decision rule that `predict` applies. For a classifier with `predict_proba`, `predict` still takes the argmax — effectively a 0.5 threshold in the binary case. Weighting shifts the probabilities, which shifts which side of 0.5 samples land on, but it is an indirect and blunt way to move an operating point. If what you actually want is "catch more positives at a known precision cost," thresholding `predict_proba` output directly is more controllable and does not require refitting. **Does, unhelpfully:** break probability calibration. A model fitted with `class_weight='balanced'` outputs probabilities that systematically overstate the minority class, because you told it the minority was more common than it is. If downstream systems consume those numbers as probabilities — expected-value calculations, risk scores, thresholds tuned against a prior — that is a real defect, not a cosmetic one. The usual resolution is to fit unweighted, keep calibrated probabilities, and move the threshold; or to weight and then calibrate on a held-out set. ## The evaluation trap The most common mistake around this parameter is not the parameter. It is turning it on, watching accuracy fall, and concluding it did not help. On a 95/5 split, an always-majority classifier scores 95% accuracy; a usefully weighted model that catches half the minority class will score lower on accuracy while being far more useful. Reweighting must be judged on the metric you actually care about, and the accuracy number will usually get worse by design. ## Interaction with cross-validation When `'balanced'` is used inside cross-validation, the weights are computed per fold from that fold's training labels. That is correct behaviour — the weights are learned from training data only — but it means the effective weighting varies slightly across folds on small or unevenly stratified datasets. It is one more reason to be explicit with a dict when the cost ratio is a business constant rather than a data artifact. ## What a strong answer sounds like Name the formula, name the estimators that have the parameter and at least one that does not, and reach immediately for the two consequences: probabilities are no longer calibrated, and accuracy is now the wrong scoreboard. That combination distinguishes someone who has shipped an imbalanced-data model from someone who has read that `class_weight='balanced'` is a thing you can set.