Few-shot: Learn by Example

There comes a point when description alone isn’t enough. You’ve described your style with five adjectives, specified your format in eight lines, and ChatGPT still misses the mark. The solution isn’t to describe better—it’s to show. Few-shot prompting means providing examples of the desired output so the model can extract the pattern and apply it. This is the most reliable technique you have for getting consistent results every time.

The principle

“Few-shot” refers to a prompt accompanied by a few examples, as opposed to “zero-shot,” which has none. You provide one, two, or three examples of what you want, then ask the model to continue following that same pattern. The difference shows up most on subjective judgments, where the right answer depends on your scale rather than a universal truth. In zero-shot—that is, without any examples—the following request leaves the model hesitating between neutral and negative: nothing tells it whether a delivery delay counts as an incident or a minor detail in your book.

Classify this customer comment as positive, neutral, or negative:
"The delivery took 3 days longer than expected but the product is fine."

The same words, preceded by four calibrated examples, produce a classification aligned with your criteria. The fourth example is the most useful of all: it shows precisely that a slow delivery doesn’t cancel out a satisfactory review.

Classify each customer comment as positive, neutral, or negative.

Examples:
- "Excellent product, fast delivery, highly recommend!" -> Positive
- "The product works but nothing exceptional." -> Neutral
- "Disappointed, the quality doesn't match the photos." -> Negative
- "Good value for money, delivery a bit slow." -> Neutral

Now classify:
- "The delivery took 3 days longer than expected but the product is fine."

When the technique makes the difference

Few-shot prompting is essential whenever an instruction is easier to show than to formulate. This applies when you want ChatGPT to write in your voice, when your format doesn’t match any existing standard, or when classification relies on criteria you’d struggle to define in a single rule. It also excels at converting data from one format to another and at batch production, where twenty pieces of content need to resemble each other without repeating.

Replicating a writing style

Your best past work constitutes the best possible specification. The two descriptions below convey far more than tone: short sentence rhythm, opening with a benefit, planting a number in the middle, and ending with a concrete use case. No adjective could have communicated all that.

Here's how I write my product descriptions:

Example 1:
Product: Wireless headphones
Description: Say goodbye to tangled wires. These Bluetooth headphones
connect in 2 seconds, last 30 hours on a charge, and block out noise
as if you were alone in the world. Perfect for the office, the train, or the couch.

Example 2:
Product: Compact mechanical keyboard
Description: 65 keys, zero compromise. Tactile switches deliver
precise feedback without waking the neighbors. RGB backlighting
adjusts with a single gesture. Compact yet complete, it slips
into any bag.

Following the same pattern, write the description for:
Product: Vertical ergonomic mouse

This is exactly the move to try on content you produce every week. Paste two of your best past deliveries, add your raw notes, and let the model handle the formatting you used to do yourself.

Here are 2 examples of weekly summaries I send to my manager:

[Paste your week 1 summary]

[Paste your week 2 summary]

Following this exact format and style, write this week's summary
from these raw notes:
[Paste your week notes]

Transforming data

To normalize disorganized information, show the input/output pair. The model infers two things at once: which fields to extract, and how to translate casual phrasing into structured labels—“doesn’t mind doing some backend occasionally” becomes a “Versatility” line, something no general instruction could have achieved.

Transform these informal job descriptions into structured profiles.

Input: "Looking for a React frontend dev, 3-5 years exp, knows
TypeScript and doesn't mind doing some backend occasionally.
Remote OK, between 45 and 55K."
Output:
- Role: Frontend Developer
- Stack: React, TypeScript
- Experience: 3-5 years
- Versatility: Occasional backend
- Remote: Yes
- Range: 45-55K EUR

Input: "Need a senior PM to lead our SaaS product,
ideally someone who's worked in a scale-up before, we're in Paris
but hybrid 3 days/week, budget 65-75K."
Output:
- Role: Senior Product Manager
- Domain: SaaS
- Experience: Senior (scale-up environment)
- Location: Paris, hybrid 3 days/week
- Range: 65-75K EUR

Now transform:
"We need a data analyst who knows SQL and Python, someone
junior-mid who wants to build ML skills. Fully remote,
35-42K, start ASAP."

Generating content in batches

For recurring editorial formats, an annotated template beats a description. The skeleton below sets the block order and length for each; the raw data from the client case simply fills it in. You get a series of homogeneous posts, ready to publish without editorial debate each time.

Here's the format for our LinkedIn posts presenting a client case:

Example:
[Relevant emoji] [Catchy key figure]

[Client name] had a problem: [one-line problem].

In [duration], we implemented [brief solution].

Result:
- [Metric 1]
- [Metric 2]
- [Metric 3]

[One-sentence lesson or takeaway]

---

Case to write: our client DataViz (BI dashboard publisher)
had a churn rate of 15%/month. In 4 months, we redesigned
their onboarding. Churn dropped to 6%, NPS rose from 23 to 52,
and time-to-value went from 14 days to 3 days.

How many examples to provide

A single example—one-shot—is enough for a simple format. Two or three cover most common tasks; four to five become useful when the pattern is subtle. Beyond that, check that each example brings something new: redundant examples lengthen the prompt without improving it. Two qualities matter more than quantity: consistency and diversity. Examples in heterogeneous formats prevent the model from knowing which one to imitate; examples that are too similar make it learn a specific case rather than the principle, and it will then produce variants of the same text.

Starting without examples

The help center and OpenAI’s guide on reasoning models give the same advice: try without examples first, then add them if the result isn’t satisfactory. Current models often manage without examples when the instruction is clear, and a poorly chosen example can pull the response in a direction you didn’t intend. The same guide warns against a specific pitfall: your examples must match your instructions exactly. If the instruction asks for three bullet points and the example shows five, the result is likely to be poor.

Contrasted examples

For classification or rating tasks, include edge cases that define the scale and justify each rating in parentheses. The model then applies your rubric, not its own—here, the gap between 3 and 5 comes from the presence of numerical proof, which the justification makes explicit.

Rate the quality of these sales hooks (score from 1 to 5).

1/5: "Hello, we sell software." (too vague, no hook)
3/5: "Your teams lose 5 hours a week on admin tasks." (good angle but no proof)
5/5: "Carrefour cut admin costs by 34% in 3 months. Here's how." (number, social proof, curiosity)

Now rate:
"What if you could automate 80% of your reporting?"

Your turn

Go from zero to few-shot. Take a classification or writing task you repeat often. Run it first without an example and note what’s wrong. Then add two examples drawn from your best work, checking that they follow your instruction exactly, then add an edge case if the classification hesitates. Compare the three results and keep the shortest version that satisfies you.

Official sources: Best practices for prompt engineering with the OpenAI API (OpenAI Help Center) · Prompt engineering · Reasoning best practices (OpenAI API documentation)

Key takeaways

• Few-shot means showing a few examples so ChatGPT reproduces the expected pattern
• Try without examples first, then add them if the result isn’t satisfactory
• Two to three examples are enough for most tasks; they must follow your instruction exactly
• Use few-shot for style, format, classification, and batch production
• Contrasted, justified examples calibrate the scale for evaluation tasks