Why does a three-approve, one-deny shot set push a few-shot classifier toward approve?

## What majority-label bias is When a prompt contains solved examples, the model conditions on the whole block. That block carries the mapping you intended (this kind of application gets approved) and one you did not intend: a sample of the label distribution. If three of four demonstrations say `approve`, the sequence looks like evidence that approval is the usual outcome. The model duly raises its prior on `approve`, and the effect is largest exactly where you least want it — on borderline inputs whose evidence is close to balanced, such as a permit application with an incomplete site plan but an otherwise clean record. This is separate from the model being wrong about the task. The mapping may be learned correctly; the decision threshold has simply moved. ## How it interacts with position Majority-label bias and recency bias are different mechanisms that add or cancel: - Majority: three `approve` demonstrations out of four raise the `approve` prior regardless of where they sit. - Recency: the demonstration adjacent to the query pulls hardest. So `approve, approve, deny, approve` is worse than `approve, approve, approve, deny` — the second at least ends on the minority label. Neither ordering removes the underlying 3:1 skew. This is why teams that only shuffle exemplars see the bias wobble rather than disappear: shuffling changes the recency component, not the majority component. ## Diagnosing it in a real system Accuracy hides this failure. A skewed classifier on a task whose true base rate is already skewed can post a respectable headline number while being useless on exactly the cases a human reviewer cares about. The diagnostic moves: 1. **Compare distributions, not just scores.** Take the predicted label histogram over a representative sample and put it next to the true base rate. A 92% predicted approval rate against a 60% actual rate is the signature. 2. **Look at per-class recall.** Majority-label bias shows up as collapsed recall on the minority class — the denials the system was built to catch are exactly the ones it misses. 3. **Probe with a content-free input.** Send something carrying no task evidence at all and observe which label the model still prefers. A strong preference is a direct read-out of the prompt's induced prior. 4. **Check the confusion matrix by difficulty band.** The bias concentrates on ambiguous inputs; clear-cut cases stay correct, which is why spot-checking obvious examples never reveals it. ## Why this matters more in some domains than others In permitting, lending, triage, moderation and fraud review the minority class is the expensive one. A model tilted toward the majority label produces a system that agrees with the happy path and quietly waves through the cases that needed scrutiny. The cost is asymmetric, so a two-point accuracy loss in exchange for a correctly located threshold is usually a good trade — and it is a trade an interviewer expects a senior candidate to articulate rather than optimise accuracy blindly. ## Correcting it The corrections that belong to the bias itself, rather than to how you pick examples: - **Prior correction / calibration.** Estimate the model's label prior from a content-free probe and divide it out of the predicted probabilities, so the decision reflects the input rather than the prompt's induced base rate. - **Threshold tuning on held-out data.** If you have label probabilities, move the operating point until the predicted distribution matches the observed base rate, or until the precision-recall tradeoff matches the business cost. - **Permutation ensembling.** Run several orders and majority-vote. This attenuates the recency component and averages some of the noise, though it cannot fully undo a lopsided label mix. - **Explicit base-rate statements.** Telling the model in the instruction that roughly forty percent of applications are denied sometimes helps, but it is a weaker lever than probability correction and should be verified rather than assumed. - **More demonstrations.** Adding shots dilutes the influence of any single one and generally reduces variance, at token cost. The balance of the exemplar pool itself — how many of each class you keep and how you curate them — is decided when the exemplars are chosen, and a well-balanced pool is the cheapest prevention. What this failure mode adds is the reminder that the prompt's label mix is a *statistical* input to the model, so you must measure the output distribution the way you would measure a classifier's calibration, not just its accuracy. ## The interview answer in one line Demonstrations set a prior as well as a mapping; an imbalanced shot set moves the decision threshold; you find it by comparing predicted to actual base rates, and you fix it by correcting the prior rather than by hoping a reshuffle absorbs it.