OpenAI prompt-engineering best practices
Reference for using examples to clarify the desired response and output format.
Compute College
Learn when examples improve AI behavior, how to choose representative cases, and how example tokens can change workload cost.
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.
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.
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.
Example figures are illustrative calculations, not current quoted market prices.
Current example
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.
Reference for using examples to clarify the desired response and output format.
Reference for few-shot examples, consistent formatting, and selecting useful demonstrations.
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.
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
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.
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
Step 5 of 18: Few shot examples and counterexamples