Learn AI compute, then follow the market
← Back to Compute College

Compute College

Few-shot examples and counterexamples

Learn when examples improve AI behavior, how to choose representative cases, and how example tokens can change workload cost.

Plain-English definition

Few-shot prompting supplies a model with a small number of input-and-output examples before the live request. The examples demonstrate the task, labels, tone, formatting, or boundary cases without changing the model’s trained weights. A counterexample shows an input that should not receive a tempting but incorrect answer, along with the behavior the application expects instead.

Memory trick: Examples show the center of the map. Counterexamples mark the edges. The test set checks whether the model can navigate beyond both.

Why it matters

Examples can make an abstract requirement concrete when a prose instruction is not enough, especially for classification, extraction, formatting, and style. But every example consumes context tokens on each request unless it is reused or cached, and poor examples can teach the wrong boundary. The right comparison is not “with examples always wins”; it is quality and accepted-task rate per unit of prompt and inference cost.

  • Representative examples reduce ambiguity about labels, formats, and what counts as a borderline case.
  • Counterexamples expose failure boundaries such as missing evidence, prohibited requests, or “other” categories.
  • Too many or inconsistent examples increase input tokens and can cause the model to imitate irrelevant details.

Simple example

A ticket classifier can show: “The invoice has two charges” → `billing`; “The login link expired” → `access`; “The customer asks whether a feature exists” → `product_question`. Add a counterexample: “The message contains the word invoice but asks why the account cannot log in” → `access`, with the evidence quote. The examples teach the decision boundary rather than just repeating the most common label.

  • Use examples that cover different valid labels and realistic wording, not three nearly identical inputs.
  • Include a boundary case when a keyword can point to the wrong category.
  • Keep the examples’ output format identical to the production output contract.

Example figures are illustrative calculations, not current quoted market prices.

Current example

Few-shot prompting references

OpenAI and Google both describe examples as a way to make the desired output and task behavior concrete. The examples below support the technique, while workload-specific quality and cost still require a representative evaluation set.

Source discipline: examples teach patterns, not guaranteed rules. Check that examples do not contain sensitive data, hidden assumptions, or labels that conflict with the written task contract.

Common mistake

Examples can mislead when nobody checks whether they are representative, internally consistent, or still current. A model can overfit to the wording, copy an accidental field, or learn a biased shortcut that fails on normal user input.

Practical takeaway

What you can do with this

Start with a small, versioned example set: one representative case per important category, one counterexample for each dangerous boundary, and one case with missing information. Evaluate against held-out cases that are not included in the prompt, then remove examples that do not improve the accepted result enough to justify their tokens.

  • Evaluators: keep test cases separate from prompt demonstrations so examples cannot make the score look better than generalization.
  • Builders: label examples clearly and keep input/output fields consistent.
  • Operators: review examples when policy, product terminology, model behavior, or user distribution changes.

Decision check: does each example teach a distinct behavior, and does the held-out test set show a benefit after its token and latency cost is included?

Compute College track

Prompt & Context Engineering

Step 5 of 18: Few shot examples and counterexamples