What Is Few-Shot Prompting?
Few-shot prompting places a small number of worked examples in the prompt so that the required answer is demonstrated rather than described. The examples are ordinary input: nothing is trained, nothing is stored, and they are re-read on every request.
What examples teach, and what makes a set good
Examples are most effective at fixing form ā the output format, the vocabulary, the granularity, the treatment of edge cases. They also demonstrate the boundary of a category better than a definition does, which is why classification is the recurring use.
A few properties distinguish a useful set. The examples should cover the distinctions the task actually turns on, including at least one case near the boundary. Their labels have to be consistent with each other, since an inconsistency is a demonstrated rule rather than an oversight. The format should be identical across all of them, punctuation and casing included. And the distribution of labels is itself a signal, so a set in which one class dominates has demonstrated that the class is the default answer.
The set need not be fixed, and the alternative is worth knowing because it changes what can be debugged. A bank of worked examples can be indexed the way a retrieval store is, with the incoming input used as the query and the closest few cases placed into the prompt for that request alone. The trade is clean. A fixed set is identical on every call, so behaviour can be reasoned about from the prompt and reproduced from it. A selected set resembles the case at hand more closely and is less likely to demonstrate a distinction the case does not turn on, at the price of a retrieval step before every request and of a prompt that is never twice the same ā which means an output produced from a selected set cannot be reproduced at all unless the selection was recorded alongside it.
| Approach | Where the examples live |
|---|---|
| Zero-shot | Nowhere. The task is described, not demonstrated. |
| One-shot | A single worked example, generally fixing the format. |
| Few-shot | A small set in the prompt, re-read on every request. |
| Many-shot | A large set, bounded by the context limit and the cost of resending it. |
| Fine-tuning | Consumed once during training; nothing is resent at request time. |
The rows differ mainly in where the cost falls. Prompt examples cost tokens on every request and can be changed between one request and the next; training examples cost a training run once and then cost nothing per request.
The costs, and the case where examples do harm
Every example is resent with every request, so a large set is a permanent addition to latency and to the token bill, and it occupies context that retrieved material might otherwise have used.
Examples can also narrow an answer to their own shape. A set drawn from one kind of input demonstrates that kind of input, and a request unlike any of them is answered in the demonstrated form regardless. Where the task genuinely varies, a small diverse set usually serves better than a large homogeneous one ā which is a claim about design, to be checked against an evaluation set rather than taken on trust from a page.
Where the examples sit in the request is a cheap decision with an expensive default. Several deployments will reuse work already performed for an identical leading portion of a prompt, so a long block of examples placed first and left untouched is processed and charged differently from the same block placed after the material that changes on every call, since a change invalidates everything after it. The layout that follows is the dull one: stable instruction, stable examples, request-specific input last. It is also precisely what a per-request selected set gives up, and the better reason a fixed set survives in production than any argument about which produces the better answer. One further point about the content rather than the position: an example is data. A worked case lifted from a real record ships that record with every request that carries the set.
How the Registry classifies a few-shot classification task
Classifying a batch of inbound support tickets using worked examples supplied in the prompt is filed as data processing in this registry's classification: existing records are consumed, and a derived label is produced for each one.
The Registry's canonical brief for this entry is filed as:
Classify a batch of inbound support tickets using five worked examples supplied in the prompt.
Submitted for assessment it is
classified as Data processing, and its wording is hashed once ā to
419dd7c79a5fad2eā¦, the first sixteen of sixty-four hexadecimal
characters ā with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/analysis.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration ā fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about few-shot prompting
How many examples a given task needs, and which ones, is settled by evaluation on that task. This registry publishes no recommended count and has measured none.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute ā from a published method, for one submitted task and one submitted configuration ā a verdict and a recommended execution window. It computes neither on this page.
Questions about few-shot prompting
- What is few-shot prompting?
- Few-shot prompting places a small set of worked examples in the prompt so that the required output is demonstrated rather than described. The examples are part of the request, re-read on every call, and nothing is trained.
- How many examples should a few-shot prompt contain?
- Enough to cover the distinctions the task turns on, and few enough that the context and the per-request cost stay acceptable. The number is settled by evaluating candidates on your own cases; this registry publishes no recommended count.
- Does the order of the examples matter?
- The order is part of the prompt, so changing it changes the input. Whether it changes the output for a specific task is a measurement on that task rather than a general property, and it is one of the cheapest things to test when a few-shot prompt behaves inconsistently.
- Is few-shot prompting better than fine-tuning?
- They differ in where the cost falls and how quickly they can be changed. Prompt examples cost tokens on every request and can be edited instantly; training examples cost a run once and nothing per request thereafter. Prompting is usually where a behaviour is established, and fine-tuning is where a stable one is moved when the prompt carrying it has grown expensive.
- Should the same examples be used on every request?
- A fixed set is identical on every call, which makes behaviour reproducible from the prompt and lets a deployment reuse work already done for an unchanged leading portion of it. A set selected per request, drawn from an example bank by similarity to the input, resembles the case at hand more closely and gives up both of those. Either way the examples actually used have to be recorded with the output, or the output cannot be reproduced.
Related entries
Prompt engineering Ā· Chain-of-thought prompting Ā· Fine-tuning
ā All entries Ā· The AFR-1 method Ā· Models in the registry
Order an assessment for data processing tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.