Select Few-Shot Examples

You've probably noticed that asking an LLM a question with zero examples can produce a surprisingly good answer — but then the next run drifts. Sometimes the model chooses the wrong format, other times it misses the nuance you expected. The fix isn't more prompt words; it's selecting and formatting few-shot examples — the craft of showing the model a handful of perfect input-output pairs so it consistently mirrors your intent. Without this step, you're leaving accuracy on the table, especially for niche formats or subtle classification tasks.

The problem this lesson solves

Picture this: you're building an app that classifies customer emails into "billing," "support," or "sales." You send a zero-shot prompt with just the email text, and the model returns something like Billing issue. — semantically correct, but then the next run returns BILLING in all caps, and the third returns a full sentence. In production, inconsistent labels break your downstream pipeline. Raw zero-shot prompting suffers from format drift and semantic ambiguity: the model doesn't know the exact verbosity, casing, or structure you expect.

The pain is real — you spend time writing regexes or retries to fix inconsistent output, and the model still misses edge cases. The core problem: you haven't shown the model what "correct" looks like. This lesson gives you a repeatable method to eliminate that guesswork by using few-shot examples that teach both the task and the output format.

Core concept / mental model

Think of few-shot prompting like teaching a new hire their first day on the job. You don't just describe the task — you show them three examples of completed work: "Here's what a correct report looks like." The LLM, like that hire, picks up patterns from the examples: the input structure, the output style, the level of detail.

Few-shot prompting is the technique of including a small number of input-output pairs (the "shots") in your prompt before the actual query. The key insight is that examples do double duty: they communicate the task (what to do) and the format (how to say it). Choosing the wrong examples — say, random ones or examples that don't match the query's domain — actively hurts performance.

The mental model: each example is a miniature lesson. A well-selected example isolates the transformation you want, such as classifying a sentiment or extracting a name. A poorly selected example confuses the model with irrelevant patterns, like mixing JSON and prose formats in the same shot.

Here's a diagram-in-words for the flow:

Query → Prepended examples → LLM → Output
         (3-5 pairs)         (mirrors format)

Examples sit between the instruction and the query. They're not decoration; they're the strongest signal you can give the model besides the instruction itself.

How it works step by step

Follow this systematic approach to select and format few-shot examples:

1. Identify the core task and output contract. What exactly do you want? Define the output schema before choosing examples. For classification: list the allowed labels. For extraction: list the fields. For summarization: note the desired length.
2. Brainstorm the hardest cases first. Start with edge cases and ambiguous inputs. The best examples show the model how to handle tricky inputs, not just the obvious ones.
3. Write clean, formatted pairs. Format each example consistently — same spacing, casing, punctuation, and structure. Use a separator like Input: and Output: to clearly delineate the pair.
4. Order examples for maximum impact. Put the most representative or hardest example last, closest to the query. LLMs often weight the final example more heavily.
5. Keep the number of examples small. Start with 3–5. More examples may increase token cost and can dilute the signal if they're redundant.
6. Test and iterate. Run the prompt with your examples. Check if the output stays consistent across several runs. If not, swap examples and retry.

Cause and effect: Each example sets up an expectation. If your examples use lowercase labels, the model will likely output lowercase. If one example uses JSON and another uses plain text, the model might mix formats. Consistency in examples breeds consistency in output.

Hands-on walkthrough

Let's put this into practice with a concrete task: classifying customer feedback as positive, negative, or neutral. Here's a minimal Python example that builds a few-shot prompt and calls an LLM (mock response for illustration, but the structure applies to any API):

# Build a few-shot prompt for sentiment classification
instructions = "Classify the sentiment as positive, negative, or neutral."
examples = [
    ("The product is amazing and works flawlessly!", "positive"),
    ("I'm frustrated with the slow shipping.", "negative"),
    ("It's okay, nothing special.", "neutral"),
]
query = "The battery lasts all day, love it!"

# Format the shots
formatted = instructions + "\n"
for input_text, output in examples:
    formatted += f"Input: {input_text}\nOutput: {output}\n\n"
formatted += f"Input: {query}\nOutput:"

print(formatted)

Expected output (the printed prompt):

Classify the sentiment as positive, negative, or neutral.
Input: The product is amazing and works flawlessly!
Output: positive

Input: I'm frustrated with the slow shipping.
Output: negative

Input: It's okay, nothing special.
Output: neutral

Input: The battery lasts all day, love it!
Output:

Now, the key: why did we pick those specific examples? We included a positive, negative, and neutral case, covering the entire label space. The neutral example is crucial — it teaches the model not to overhype. We also kept the responses simple: one word, lowercase, no punctuation. Watch what happens if you format them differently:

# Inconsistent formatting — see why it fails
bad_examples = [
    ("Great service!", "Positive!"),
    ("Meh.", "neutral"),
    ("This is the worst, never again.", "negative."),
]
formatted = instructions + "\n"
for input_text, output in bad_examples:
    formatted += f"Input: {input_text}\nOutput: {output}\n\n"
formatted += "Input: Wonderful!\nOutput:"
print(formatted)

Expected output: Notice the mixed casing and punctuation. The model may now mirror that inconsistency, producing Positive! in one run and positive. in another.

Let's try a second scenario — extracting a date from user messages:

# Few-shot for date extraction
examples = [
    ("Remind me to call John next Tuesday.", "2023-07-11"),
    ("Meeting moved to March 3rd.", "2023-03-03"),
]
query = "Flight departs on the 15th of May."
prompt = "Extract the date in YYYY-MM-DD format.\n"
for input_text, output in examples:
    prompt += f"Input: {input_text}\nOutput: {output}\n\n"
prompt += f"Input: {query}\nOutput:"
print(prompt)

Expected output (the prompt):

Extract the date in YYYY-MM-DD format.
Input: Remind me to call John next Tuesday.
Output: 2023-07-11

Input: Meeting moved to March 3rd.
Output: 2023-03-03

Input: Flight departs on the 15th of May.
Output:

In both cases, the model receives clear, consistent patterns. The date examples show the model how to convert conversational language into a strict format. After seeing two examples, it's far more likely to output 2023-05-15 instead of "May 15th."

Pro tip: Always include at least one example that covers an edge case — like a neutral sentiment or a relative date. Those are where models usually trip up.

Compare options / when to choose what

Few-shot prompting has several siblings. Here's a quick comparison to help you decide:

Choosing few-shot examples is a balancing act: too few examples and the model may miss the pattern; too many and you're paying for tokens without added accuracy. Start with 3–5 diverse examples. If the task is extremely straightforward (like a common sentiment), zero-shot might suffice. If the task requires deep reasoning, consider chain-of-thought few-shot where you include the reasoning steps in the output.

Pro tip: For most real-world applications, 3–5 well-chosen few-shot examples outperform 20 random ones. Quality beats quantity.

Troubleshooting & edge cases

Even with good examples, things can go wrong. Here are common issues and fixes:

• Output format still drifts. Even with examples, the model occasionally ignores the format. Solution: repeat the format instruction right before the query, or use stronger separators like --- between examples. You can also set temperature to 0 for deterministic outputs.
• Examples are too similar or too obvious. If all examples are easy, the model won't learn the hard patterns. Fix: deliberately include edge cases and tricky inputs that showcase the full range of behavior.
• Model picks up irrelevant patterns — like style or length — instead of the task. If your examples are verbose, the model may output verbose answers even when you need short labels. Fix: keep examples minimal and consistent with the desired output length.
• Inconsistent separators or spacing. Using Input: in one example and User: in another confuses the model. Fix: always use the exact same tags, punctuation, and newline structure.
• Too many examples cause "example overload." In extreme cases, the model may just repeat an example verbatim. Fix: trim to the most distinct examples and remove redundant ones.
• The query is too similar to an example. The model might copy the example's output verbatim, which is fine if that's correct, but dangerous if the query varies slightly. Fix: vary your examples enough to teach the transformation, not memorization.

Pro tip: Always test your few-shot prompt with at least 5 variations of the query. Run it multiple times and check for consistency. If the output is stable across runs, your examples are working.

What you learned & what's next

You've learned the core skill behind reliable LLM outputs: select and format few-shot examples. You now know how to pick examples that teach both the task and the output format, how to format them consistently, and how to troubleshoot common pitfalls. You've also seen hands-on Python examples that you can adapt to any LLM API.

Key takeaway: Few-shot examples are small but powerful. They bridge the gap between the model's raw capability and your exact requirements. By spending a few minutes curating examples, you can save hours of post-processing and bug fixing.

What's next: The next lesson in this track will build on this foundation by exploring chain-of-thought prompting — how to coax the model into showing its reasoning step-by-step, which is especially useful for complex problem-solving. You'll learn to combine few-shot examples with chain-of-thought for even greater accuracy.

Now, open your favorite code editor and try crafting a few-shot prompt for one of your own tasks. Start with an easy classification problem, apply the six-step method, and observe how the output becomes more consistent.