Few-shot prompting means showing the model a few worked examples of a task, each an input paired with the answer you want, before you give it the real input. The model reads the pattern and continues it. Examples are the fastest way to pin down things that are hard to say in words: where the line falls between two categories, the exact shape of the output, or the voice your team writes in.
How few-shot prompting works
Brown et al. 2020, "Language Models are Few-Shot Learners", showed that GPT-3 could pick up a new task from a handful of demonstrations placed in the prompt, with no retraining. This is called in-context learning: nothing about the model changes, and the examples only affect the reply to that one prompt. Next time, the examples have to be there again.
The naming follows the number of examples. A zero-shot prompt has none, a one-shot prompt has one, and a few-shot prompt has several, usually between two and a handful.
Zero-shot versus few-shot, side by side
Both tabs below ask for the same thing with the same instruction. The only difference is that the second tab adds four labelled examples before the real ticket.
Category: bug
The user reset their password, but the new password is rejected at sign-in. That points to a problem in the password reset flow, so this is most likely a bug in the authentication system.
The examples changed two things. The first is the format: the zero-shot reply added a bold heading and an explanation, while the few-shot reply matched the examples and gave one word, which a script can read directly. The second is the decision. "Bug" is a reasonable reading of the ticket, and most people would pick it. But this team files sign-in problems under account, and the third example says so without a single word of explanation. No instruction mentioned that rule; the examples carried it.
How many examples to use
Start with two to five. That is enough for most formatting and classification tasks, and it keeps the prompt short.
- One example shows a format, but the model tends to copy it too closely. If the only example is a 30-word summary of a pricing change, the next summary may come out 30 words long and oddly focused on money.
- Two or three different examples let the model see what they share (the pattern) and what varies (the details).
- For classification, include at least one example for every label, then add the borderline cases that went wrong without examples.
- Beyond a handful, gains usually shrink while every request gets longer, which costs tokens and time. If you need dozens of examples to get it right, the task may need a clearer instruction or a different approach altogether.
Choosing good examples
The model learns from everything your examples have in common, not only the thing you meant to teach.
- Cover the hard cases. Easy examples teach little. The most useful examples sit on the boundary, like the login ticket above.
- Vary the surface. Mix short and long inputs, different topics and different phrasings. If every positive review in your examples is short, the model may treat length as the signal.
- Balance the labels and shuffle the order. Models tend to lean toward the label that appears most often in the examples and toward the one that appears last.
- Check every example. A mistake in an example is an instruction to make that mistake.
- Use real inputs. Examples taken from your actual data match what the model will see far better than invented ones.
Keep the format identical
Every example should use the same labels, separators and casing, and the real input should look exactly like the example inputs. In the ticket prompt, each example is "Ticket:" then "Label:", and the prompt ends with an open "Label:" line, which leaves only one natural thing to write next.
For longer examples, wrap each one in clear markers such as <example> tags so the model can tell where one ends and the next begins; see delimiters and XML tags. In the API you can also supply examples as earlier turns of the conversation: a user message holding the example input, then an assistant message holding the answer, repeated for each example.
Few-shot prompts make good reusable prompt templates: the instruction and examples stay fixed and only the input changes. The block below rewrites a commit message in a team's style. Type your own message in the field and switch the examples part off to see how much of the style they carry.
feat(search): make search box case-insensitive
None of the rules are written down: a lowercase type, a scope in parentheses, the imperative mood, no final period. The examples show all four, and the reply follows them. With the examples switched off, the model still improves the message, but it has to guess at a style, and nothing makes its guess match yours.
Few-shot examples can also demonstrate reasoning, not only answers. Worked examples that show their steps are how chain of thought prompting was first introduced. With models that reason internally before answering, keep examples to inputs, answers and format: scripted reasoning steps can steer them away from a better route, and some providers advise trying zero-shot first with those models.
Frequently Asked Questions
What is few-shot prompting?
Few-shot prompting is including a few examples of a task in the prompt, each an input paired with the correct output, before the real input. The model continues the pattern the examples set. It is most useful for custom categories, unusual formats and house styles that are easier to show than to describe.
How many examples should a few-shot prompt have?
Two to five is a good starting point for most tasks. For classification, include at least one example per label, plus the borderline cases the model got wrong without examples. Past a handful, each extra example usually helps less while making every request longer.
What is one-shot prompting?
One-shot prompting gives the model exactly one example. It is enough to show a format, but the model tends to copy that single example too closely, including its length, wording and even its topic. A second, different example tells the model which features are the pattern and which are accidents.
Does the model learn from my examples?
Only for the current request. The examples shape the reply by being in the context; the model's weights do not change, and nothing is remembered in the next conversation. This is called in-context learning, and it is why a few-shot prompt has to carry its examples every time you use it.
Can bad examples make the output worse?
Yes. The model copies whatever the examples have in common, including mistakes, length and tone you did not intend. If most examples share one label, the model also tends to lean toward that label. Check that your examples are correct, varied and balanced.
