Learning by Example, Not by Lecture
When natural-language instructions fall short, the single most reliable upgrade is to show, not tell. Few-shot prompting hands the model a small set of input-output pairs, called demonstrations, and lets it infer the transformation from the pattern rather than from a paragraph of rules. This is powerful because it offloads a huge amount of ambiguity. A rule like "classify this email" leaves the category names, the formatting, and the edge-case behavior underspecified; three worked examples nail all of those at once with less text and more signal.
The key insight is that demonstrations act as a function signature. They communicate the input contract and the output contract far more compactly than prose. Where an instruction says "be concise," an example simply is concise, and the model mirrors it. Where an instruction says "output the sentiment in lowercase," an example demonstrates it, eliminating any chance of the model interpreting "sentiment" oddly. Examples convert commentary into observable behavior.
Choosing the Demonstrations That Matter
The quality of few-shot prompting lives or dies in the choice of examples, and most people choose badly. The naive approach is to pick a few "typical" cases. The better approach is to pick examples that span the decision boundary and your hardest edge cases. If you are classifying customer messages into angry, neutral, and joyful, your demonstrations should include at least one emotional, easily-confused borderline case that separates "angry" from merely "frustrated," because the model is most likely to slip exactly there.
There are a few concrete selection criteria worth internalizing:
- Diversity first: cover the range of inputs so the model does not collapse everything into one bucket.
- Include hard cases: the borderline and ambiguous demonstrations teach the subtle distinctions that typical cases never surface.
- Show formatting outliers: if some inputs contain noise like emojis or typos, include one so the model learns to handle it.
- Consistency is king: every example must follow the exact same output schema, because the model treats the schema as the contract.
- Recency bias: the last example in the prompt gets the most influence, so order your examples from hardest to easiest, or place your most important example last.
Each demonstration is also a little memory cost, so short examples are better than long ones, and every example should earn its place by changing the model's behavior.
An example is worth a thousand words of instruction, but only when it sits precisely on the decision boundary the model is most likely to get wrong.
Format: Structured Demonstrations Beat Prose
How you write the demonstrations matters almost as much as which ones you choose. A common and effective format is a compact labeled excerpt that looks like a mini-schema:
Input: "Where is my refund, this is ridiculous!!"
Label: angry
Input: "Just checking in on my order status."
Label: neutralStructured and terse. Notice there is no prose explaining the labels; the pattern teaches the mapping. For richer outputs, extend the pattern into JSON or a labeled table so the model learns a complex structure the same way. The more exactly your examples mirror the format you want the real output to use, the more reliable the final response will be.
One subtle but important rule: do not explain your examples. The instinct to add "note that 'ridiculous' signals anger" is strong, but the explanation competes with the pattern and can confuse the model. Put the pedagogy in the ordering and the selection, not in annotations. If a choice genuinely cannot be inferred from examples, that is a signal that natural-language instruction has a role after all, and you can add one line of prose to cover it.
How Many Examples Is Enough
More demonstrations are not always better. Accuracy tends to rise steeply from one to about four or five examples, then plateau and occasionally degrade as the prompt gets long and the model's attention spreads thin. There is also a sweet spot per-task. Sentiment and topic classification often work with two or three excellent examples. Structured extraction or format-sensitive tasks may need four to six. Very open-ended generation rarely needs any, because there is no "correct" shape to lock in.
The practical approach is empirical: start with two curated examples, test on a validation set, add the hardest failure case you observe, and repeat until the error rate stops shrinking. This is literally iterative training on your own failure modes, and it compounds. Keep your demonstration set in version control as part of the prompt, because an apparently harmless edit to one example can shift behavior across the whole task.
Few-Shot in Combination with Other Techniques
Few-shot prompting is not an either-or choice; it layers cleanly onto the other tools in this series. Combine it with a role to fix both the voice and the format: precede the examples with a one-line role that sets standards, then let the demonstrations carry the format. Combine it with chain-of-thought by making your demonstrations show reasoning as well as the answer, which teaches the model not just the output shape but the thinking process you want. Combine it with structured outputs by making the demonstrations valid JSON and stating the schema, and the model will reliably produce parseable structures.
This stacking is where experienced practitioners earn their advantage. Each technique handles a different failure axis: the role sets norms, the examples set the format and the edge cases, the reasoning sets the process, and the schema sets the machine readability. Used together, they turn a fragile instruction into a robust specification.
Debugging a Few-Shot Prompt
When a few-shot prompt underperforms, work through a short diagnostic checklist. First, check consistency: do all examples share the exact same schema? One stray field can derail everything. Second, check diversity: are you accidentally showing five near-identical inputs? Third, check placement: did you bury a decisive example in the middle where attention is weakest? Fourth, check contamination: is one example contributing most of the errors, and would removing it help? Finally, check quantity: you may simply need one more hard case or one fewer redundant one. Follow the data, not the intuition, and let your validation set tell you when the demonstrations have stopped earning their token cost.
