In few-shot prompting, do wrong labels in the demonstrations hurt accuracy?

## The claim, stated precisely A few-shot prompt shows the model several worked items — an input and its label — before the live query. The intuitive story is that the model reads those pairs, infers the input-to-label mapping, and applies it. If that story were the whole truth, corrupting the labels should wreck performance. A 2022 study titled "Rethinking the Role of Demonstrations: What Makes In-Context Learning Work?" tested exactly that. It took few-shot prompts across a dozen models and roughly sixteen classification and multiple-choice datasets, then replaced each gold label with a label sampled at random from the same task's label set. Accuracy dropped only marginally — typically a small single-digit gap, and far less than the drop from removing the demonstrations entirely. The conclusion was not that demonstrations are useless, but that the *ground-truth pairing* is a smaller part of their value than the field assumed. ## What the demonstrations are actually supplying The same work isolated the components that do carry the signal: - **The format.** The fact that each item appears as an input followed by a label, in a fixed shape, with fixed field names and separators. Strip the pairing — list all inputs, then all labels — and performance collapses. The shape is what tells the model "produce one more of these". - **The label space.** The set of strings that appear in the label position. Draw labels from a foreign vocabulary (English words unrelated to the task, or a different task's classes) and accuracy falls, because the model no longer knows which output tokens are legal. - **The input distribution.** Inputs drawn from the real task distribution beat random unrelated text, because they anchor what kind of thing is being classified. Put differently: the demonstrations are mostly a **task locator**, not a training set. A frontier model has already seen sentiment classification, entity extraction and triage a million times during pretraining. The prompt's job is to pick out which of those latent behaviours to run, and in what output shape. Getting the labels individually correct is a smaller lever than making the request unambiguous. ## Where label correctness does start to matter Do not overgeneralise the result. Three boundaries come up in interviews: 1. **Model scale and prior override.** Follow-up work in 2023 on "larger models do in-context learning differently" showed that with systematically flipped labels — not random noise, but a consistent inversion — small models keep following their semantic prior while sufficiently large models will actually learn the flipped mapping from context. That is direct evidence that big models *can* read the labels; the random-label result says only that a little noise does not throw them off. 2. **Novel or arbitrary mappings.** If the task is genuinely new to the model — mapping internal product codes to routing queues, applying a house style guide that contradicts common usage — the demonstrations are the only place the mapping exists. There is no prior to fall back on, so wrong labels teach a wrong rule. 3. **Generation and reasoning outputs.** The ablation covered classification and multiple choice, where the output is one token from a small set. When the demonstrated output is a paragraph, a derivation or a structured document, the exemplar output *is* the procedure being demonstrated, and errors in it propagate directly into the answer. ## What to do with this in practice The practical reading is a reallocation of effort, not a licence to ship garbage: - **Spend first on format discipline.** Identical field names, identical separators, identical casing and spacing across every exemplar and the live query. This is the cheapest and highest-leverage fix, and it is what breaks most often when prompts are edited by several people over months. - **Spend next on the label space.** Make sure every class you want the model to be able to emit appears in the demonstration block, spelled exactly as your parser expects. - **Still verify the labels**, because a mislabeled exemplar is also a documentation defect: the next engineer reads it as the specification of the task, and the error propagates into evals, into the style guide, and into the next revision of the prompt. Reviewers and downstream humans do not enjoy the model's robustness to noise. ## Diagnosing which one is broken When a few-shot prompt underperforms, the diagnosis order follows the finding. First check whether the outputs are the *right shape* — if the model is emitting prose where you expect a label, or wrapping the answer in commentary, the format is broken and no amount of label curation will help. Then check whether the outputs are *in the label set* — off-vocabulary answers point at label-space gaps. Only after those two should you audit whether the individual demonstration labels are correct. Doing it in the reverse order is how teams spend a week re-annotating exemplars for a prompt whose real defect was an inconsistent separator.