prompt-engineering.si
Technique

Few-shot prompting: examples that teach the right boundary

Few-shot prompting supplies a small set of input-and-output examples alongside a task. It can make an ambiguous label, writing pattern, or output convention more concrete. Examples should demonstrate the rule you want applied, including its boundaries.

When examples are worth adding

A zero-shot prompt gives instructions without worked examples. A few-shot prompt adds several demonstrations. The practical question is whether demonstrations resolve an ambiguity that prose has not resolved.

Examples are especially useful when two labels are easy to confuse or a house style is hard to describe. They are less useful when the model lacks the facts necessary to answer. Three examples of well-cited prose cannot provide an absent source document.

A boundary case: confirmed action or suggestion?

Suppose you want to extract commitments from meeting notes. You must distinguish a proposal, an accepted task, and a conditional task. If every demonstration contains the word “will,” the model might learn a surface cue instead of the business rule.

Label each statement as COMMITMENT, SUGGESTION, or CONDITIONAL.
A commitment explicitly assigns or accepts an action. A suggestion proposes an action without acceptance. A conditional action depends on a stated condition.

Input: “I will send the signed brief tomorrow.”
Output: COMMITMENT

Input: “Could someone check the numbers?”
Output: SUGGESTION

Input: “If approval arrives, I will schedule the rollout.”
Output: CONDITIONAL

Input: “Yes, I can own the final review.”
Output: COMMITMENT

Now label this statement. Return only one label.
Statement: [new statement]

The last demonstration removes dependence on “will.” The conditional example prevents the model from treating every future-tense statement as a firm commitment. These are deliberate contrasts.

Build a small, representative example set

  1. Write the rule in one sentence before choosing examples.
  2. Add a normal positive case and a similar negative case.
  3. Add an edge case that has caused a real error.
  4. Keep labels, field names, and formatting consistent.
  5. Reserve different examples for testing.

Remove names, numbers, and stylistic details that are irrelevant to the rule. If every urgent example happens to mention a particular department, the prompt may encourage an accidental association. Vary those incidental features while preserving the intended distinction.

Test on examples the prompt has never seen

Try “We should probably ask legal” and “I have accepted the legal review task.” Then try a messy sentence with both a proposal and a confirmed action. Decide in advance whether your task permits multiple labels or requires splitting the input. Otherwise you cannot fairly judge the response.

A correct answer on the demonstrations is not evidence of generalization. Keep a separate list of ordinary, ambiguous, and unusual cases. Compare the instruction-only version with the example-based version using the same list.

Three ways demonstrations mislead

Contradictory labels: the prose says one thing while a demonstration rewards another. Fix the rule or the example before adding more text.

Unrepresentative examples: the prompt sees neat sentences, while production inputs are fragmented and multilingual. Include realistic variation without exposing private data.

Overfitting the format: the model copies an example’s facts into the answer. Explicitly separate expected structure from case-specific content, and test with a missing-data case.

Use the optional example field in the builder. Add only examples that clarify a requirement you can explain.

Further reading

Official documentation for the general techniques discussed here. Worked examples and checklists on this page are original instructional material.

Try it in the builder ↗
Keep going