Use zero-shot prompting when the task and output rules are clear enough to state directly. Add a small set of representative input-output examples when labels, tone, boundaries, or edge cases remain ambiguous. Few-shot examples teach a local pattern, but poor or unbalanced examples can teach the wrong one.
Who this is for: Analysts, educators, operators, and developers deciding whether examples will improve a repeated AI task.
- Start with a clear zero-shot instruction to establish a simple baseline.
- Add examples only for distinctions that the baseline handles inconsistently.
- Test examples against fresh normal cases and edge cases instead of judging the demonstrations themselves.
Zero-shot is the clean baseline
A zero-shot prompt describes the task without showing completed examples. It is fast to write, uses less context, and makes the governing rule visible. Classification may need a label definition, while rewriting may need audience and tone. If those instructions produce stable results on a representative sample, examples may add little value.
The baseline should still be specific. 'Classify this ticket' is incomplete; 'assign billing, technical, account, or other using the customer's primary requested action' defines the choice. Evaluate the baseline across ordinary cases, ambiguous wording, and irrelevant detail. Record failures by type rather than changing the prompt after one surprising response.
Few-shot examples resolve local ambiguity
Few-shot prompting places several demonstrations before the new input. Each demonstration pairs an input with the desired output and may include a short rationale. Examples are especially useful when categories have organization-specific meanings, a writing style is difficult to describe, or a boundary case repeatedly receives the wrong treatment.
Choose examples for coverage, not convenience. Include a typical case, a close boundary, and a case containing distracting details. Keep the demonstrated format exact. If every example is easy or belongs to one label, the model may copy superficial features instead of learning the intended distinction.
Compare methods with held-out cases
Create a small test set before refining the prompt. The set should contain inputs that are not used as demonstrations and should have expected outcomes agreed by a knowledgeable reviewer. Run zero-shot and few-shot versions under the same conditions, then compare correctness, format compliance, and important failure rates.
Do not select the winner from one run. Generative output can vary, and a prompt may improve common cases while harming rare ones. Repeat important cases, inspect disagreements, and decide whether the added context and maintenance are justified. For consequential classification, retain human review even when aggregate performance improves.
Maintain examples as task data
Examples should be reviewed when labels, policies, or expected style change. Store them with an explanation of why each was selected. A demonstration copied from an old policy can silently preserve obsolete behavior. Remove duplicate examples that consume space without adding a distinct decision boundary.
Current models may respond differently to the same demonstration set. Re-test after a model or prompt change, and consult current provider documentation for recommended message structure. The durable principle is to use examples as controlled evidence of expected behavior, not as a substitute for defining the task.
Improve support-ticket routing
A team routes tickets into billing, access, bug, or feature request, but password-reset requests are often mislabeled as bugs.
- Write a zero-shot prompt with four label definitions and test it on twenty previously resolved tickets.
- Identify the repeated boundary error: access failures are being confused with product defects.
- Add three demonstrations covering a forgotten password, an outage after successful login, and a ticket mentioning both issues.
- Run both prompt versions on a separate labeled set and compare per-label errors plus invalid output formats.
- Keep the few-shot version only if it improves access-versus-bug decisions without degrading the other categories.
Shot-selection decision table
Use this table as a checklist before expanding a prompt with examples.
- Direct instruction works on normal and edge cases: retain zero-shot and monitor failures.
- Labels have local definitions: add one representative example per confusing boundary.
- Output style is hard to specify: show a short exact example and state which features matter.
- Examples increase bias toward one outcome: rebalance the set and retest held-out inputs.
- Policies or model behavior changed: review every demonstration before release.
Common mistakes
- Adding examples before testing whether clearer definitions solve the problem.
- Using demonstrations that all represent one easy category and calling the set representative.
- Measuring improvement on the same examples that appear inside the prompt.
Try one
A resume-screening prompt applies a clear required-license rule correctly but uses inconsistent wording in its explanation. Should you add few-shot examples, and how would you test them?
A good response keeps the decision rule explicit and uses examples only if explanation consistency has practical value. It proposes representative demonstrations without encoding protected traits, tests on held-out resumes, and separately scores license decisions and explanation format. Evaluation should reject an answer that assumes a few polished examples make employment screening fair or remove the need for human and legal review.
Sources
- Gemini API prompting strategiesOfficial Google strategies for clear instructions, examples, and constraints.
- OpenAI prompt engineering guideOfficial prompting practices and examples for current OpenAI models.