Few-shot and zero-shot learning are fundamental prompting techniques that control how LLMs generalize to new tasks. In zero-shot prompting, you give the model a task description with no examples — relying entirely on its pre-trained knowledge to understand what you want. In few-shot prompting, you provide a small number of input-output examples (typically 2-6) that demonstrate the desired behavior, allowing the model to recognize patterns and produce more consistent, accurate responses.
These techniques are forms of in-context learning — the model adapts its behavior based solely on what appears in the current context window, without any weight updates or fine-tuning. This is one of the most powerful properties of large language models: they can learn new tasks at inference time just from examples in the prompt. The quality and selection of those examples (or the decision to omit them entirely) has a dramatic impact on output quality.
Understanding when to use zero-shot vs. few-shot prompting — and how to construct effective examples — is a core skill for AI engineers. The choice affects accuracy, consistency, token cost, and latency. Getting it right can mean the difference between a 60% and 95% success rate on structured tasks like classification, extraction, and formatting.
In zero-shot prompting, you describe the task and let the model figure out the response format and approach from its training data alone:
// Zero-shot classification
Classify the following customer message as one of:
[billing, technical, feature_request, general]
Message: "My virtual tour won't load on Safari and I've
tried clearing my cache twice."
Classification:Zero-shot works well when:
Zero-shot performance is entirely dependent on what the model learned during pre-training and instruction tuning. If the task closely matches patterns the model has seen (sentiment analysis, translation, summarization), zero-shot works well. For novel or domain-specific tasks (classifying hospitality property types, scoring lead quality), zero-shot performance drops significantly because the model has no reference for your specific taxonomy or criteria.
One-shot prompting provides a single example. It bridges the gap between zero-shot and few-shot, useful when you need to establish a format but have limited token budget:
// One-shot extraction
Extract property details from the description below.
Example:
Description: "Stunning 5-star beachfront resort in Cancun
with 320 rooms, 4 restaurants, and a full-service spa."
Output: {"type": "Resort", "location": "Cancun",
"rooms": 320, "amenities": ["restaurants", "spa"]}
Now extract from:
Description: "Boutique 45-room hotel in downtown Portland
featuring rooftop bar and co-working space."
Output:Few-shot prompting provides 2-6 examples that demonstrate the desired input-output mapping. The model identifies patterns across the examples and applies them to new inputs:
// Few-shot sentiment classification with nuance
Classify the review sentiment as: positive, negative, mixed
Review: "The lobby was gorgeous but our room had a broken AC
and the staff took 3 hours to fix it."
Sentiment: mixed
Review: "Everything exceeded our expectations. The virtual
tour was accurate and the actual property was even better."
Sentiment: positive
Review: "Terrible experience. The photos online looked
nothing like the actual rooms. Very misleading."
Sentiment: negative
Review: "Decent location and clean rooms, though the
breakfast options were limited and overpriced."
Sentiment:Few-shot prompting works through in-context learning (ICL). The model doesn’t update its weights — instead, its attention mechanism identifies patterns in the examples and applies those patterns to the new input. Research shows that the model effectively performs implicit gradient descent within its forward pass, treating the examples as a mini training set. This is why example quality matters so much: garbage examples produce garbage patterns.
The examples you choose dramatically affect performance. Research has identified several key principles:
Diversity: Examples should cover the range of expected inputs. For a classifier with 4 categories, include at least one example per category. For extraction tasks, vary the complexity and format of inputs.
Similarity: Examples that are semantically similar to the expected test inputs perform better than random examples. In production, you can dynamically select few-shot examples by finding the most similar examples from a curated set using embedding similarity:
async function selectFewShotExamples(userQuery, exampleBank, k = 3) {
// Embed the user's query
const queryEmbedding = await embed(userQuery);
// Find the k most similar examples from the bank
const similarities = exampleBank.map(ex => ({
example: ex,
score: cosineSimilarity(queryEmbedding, ex.embedding)
}));
similarities.sort((a, b) => b.score - a.score);
return similarities.slice(0, k).map(s => s.example);
}Boundary cases: Including examples that represent edge cases or ambiguous inputs teaches the model how to handle difficult scenarios. If “mixed” sentiment is important, include an example that’s clearly mixed, not just clear positive/negative cases.
The order of few-shot examples significantly impacts model behavior. Research by Zhao et al. (2021) demonstrated that simply reordering the same set of examples could swing GPT-3’s accuracy from near state-of-the-art to near random chance. While newer models (GPT-4, Claude, Llama 3) are less sensitive to ordering, the effect hasn’t disappeared.
Two key biases to watch for:
Best practice: place your most representative, “ideal” example last (to exploit recency bias), and balance label distribution evenly across examples.
The structural format of your examples matters. Three common patterns:
// Conversational format (recommended for chat APIs)
messages: [
{ role: "system", content: "Classify support tickets..." },
{ role: "user", content: "My tour won't load on mobile" },
{ role: "assistant", content: '{"category": "technical", "priority": "high"}' },
{ role: "user", content: "Can you add dark mode?" },
{ role: "assistant", content: '{"category": "feature_request", "priority": "low"}' },
{ role: "user", content: actualUserMessage }
]The decision between zero-shot and few-shot depends on several factors:
In production RAG systems, few-shot examples are often selected dynamically rather than hardcoded. When a user asks a question, the system retrieves similar past question-answer pairs from a curated examples database and injects them as few-shot demonstrations. This combines the pattern-teaching power of few-shot with the relevance of retrieval — the model sees examples that are semantically close to the current query.
AI systems frequently need to classify user inputs to route them to the right handler — determining intent, detecting language, categorizing support tickets, or scoring lead quality. Few-shot prompting is the standard approach here because it lets you define your exact taxonomy through examples without fine-tuning a model. A property platform might use few-shot to classify queries into “property search,” “booking inquiry,” “technical support,” and “general information.”
Extracting structured data from unstructured text (property descriptions, emails, contracts) benefits enormously from few-shot examples. The examples teach the model your specific schema, field names, and formatting conventions. Without examples, models may use different field names, inconsistent date formats, or miss optional fields entirely.
Few-shot examples serve as calibration anchors for subjective tasks. If you need the model to score “property description quality” on a 1-10 scale, zero-shot will produce inconsistent scaling. A few examples showing that a 3 looks like “basic listing, no photos, missing amenities” and a 9 looks like “professional copy, virtual tour, detailed amenity list” calibrates the model’s internal scale to match your expectations.