Few Shot Prompting

Few shot prompting means giving a language model a small set of examples in the prompt to demonstrate the task or response pattern. The examples are context supplied for the current request; they are not, by themselves, a training update to the model. They can show a classification boundary, an extraction convention or a desired writing format.

By Ai Flowi · Published 10 October 2026

The value comes from what the examples clarify. Repeating an easy case adds little when the real difficulty is distinguishing two similar labels. A useful few-shot prompt shows the borderline cases and leaves separate questions for evaluation, so apparent success is not simply repetition of an answer already included.

What is the difference between zero, one and several examples in few-shot prompting?

A zero-example prompt gives instructions without demonstrations: “Classify each request as access, fault or unclear.” A single demonstration shows one input and its target label. Several demonstrations can show how different labels apply, including a case where the correct response is to ask for clarification.

These are prompt-design choices, not a universal ranking of methods. Explicit definitions may be enough for a straightforward task. Examples are useful when the wording leaves an interpretation gap that a demonstrated boundary can resolve. They also add input text and can accidentally teach an unwanted shortcut.

For the broader discipline of designing constraints and evaluating outputs, read prompt engineering. This page concentrates on selecting demonstrations rather than repeating the component setup for a prompt.

An invented request-classification example

Assume an internal help desk uses three synthetic labels. “Access” means the person needs permission or an account. “Fault” means something they could use has stopped functioning. “Unclear” means the request lacks enough evidence to choose either label. These definitions belong to the example, not to a real customer process.

example configuration, not a recorded test. The demonstrations below show prompt content without configuring a model connection.

Instruction: classify the request using its stated facts.
Labels: access, fault, unclear.

Request: Please give me access to the design folder.
Label: access

Request: My existing folder access worked yesterday but fails now.
Label: fault

Request: I need help with the design folder.
Label: unclear

New request: [supply a separate request here]

The target labels above are authored demonstrations, not observed model results. The contrast between “give me access” and “existing access fails” supplies the useful boundary. The folder noun appears in every example, so it should not itself determine the category.

Keep the output contract modest: a label and a short reason tied to the request. If the task later needs a JSON object, specify the required structure separately. Showing well formatted examples does not ensure that every later output will be valid or semantically correct.

Choose examples and counterexamples deliberately

Include examples that resemble the difficult inputs, not just examples that are easy to label. A request saying “the page says permission denied” could describe either missing access or a fault, depending on whether access previously existed. Use an unclear demonstration to show that uncertainty is an allowed result.

A counterexample can demonstrate what must not be inferred. “I want access next week” does not establish that an account is already broken. Explain the target decision consistently; otherwise the model receives conflicting demonstrations and the evaluator has no stable rule to apply.

Do not place a correct and an incorrect answer next to each other without clear labels. The model should be able to distinguish the demonstration it should follow from the behavior being criticized. Use the same input and output arrangement throughout the examples.

Keep a held-out synthetic question set

Reserve requests that never appear in the prompt. An invented held-out request might say “I can open the folder, but the download button stopped working.” Under the stated rule, fault is the authored target. Another might say “Who can help me with this folder?” with unclear as the target.

Also include a request for a different object, such as a dashboard. If the demonstration taught a folder-specific shortcut, that new wording helps expose it. A paraphrase of an included example is useful, but it is a weaker check than a case that exercises a distinct boundary.

Compare the instruction-only and example-based prompts using the same held-out set and model settings. Record wrong labels, unsupported reasons and malformed output separately. No accuracy number is reported here because no model run was performed. A target answer is a test specification, not a passed test.

How few-shot content maps to AI Flowi Workflow

The Prompt Template documentation covers placing the demonstration block in the request.

The Language Model page covers connecting the chosen generation model.

Follow the Structured Output guide when the demonstration labels need a defined response structure.

For this classifier, the proposed fields are label and reason. The application-defined labels are access, fault and unclear; they are not catalogue options. Accept a reason only when it points to a stated need for permission, prior functioning that has stopped, or missing evidence. Reject a reason claiming the user previously had access when the request never says so.

A request can combine categories: “Please grant dashboard access; the printer also stopped working.” Decide whether the task classifies a whole request or separate issues before choosing demonstrations. Under a single-label design, this mixed request needs an explicit ambiguity rule. Under an issue-level design, demonstrations must show the split. Otherwise a model can imitate the examples accurately while satisfying the wrong unit of classification.

Keep the examples aligned with that decision. Adding a mixed request only to the evaluation set exposes a missing boundary; copying its answer into the prompt then evaluating it again hides the gap. After revising the demonstrations, retain a different mixed request to check whether the rule transfers beyond the wording that taught it.

documented in the catalogue; not production-tested by Ai Flowi

Review the catalogue before configuring demonstration-based classification; you need your own provider account and API key for those model requests, and the demonstration text contributes to provider usage charged separately.

Common mistakes and when to skip examples

Examples can bias a response toward whichever label appears most prominently or accidentally disclose private requests. Use invented material while designing the boundary and review any real example for permission before sharing it. Never include confidential credentials or identifiable support records in a public template.

Long demonstrations also compete with the current input and source evidence. Context engineering explains that selection trade-off. If a short deterministic rule can make the decision exactly, applying that rule may be preferable to asking a model to imitate examples.

An Agent is relevant when tools are needed, rather than because a prompt contains examples. For complete starting designs, use documented use cases and inspect their evidence. Few-shot prompting does not authorize actions, certify the labels or prove that the surrounding workflow executed successfully.