You just got access to a powerful AI model, type a question, and… the answer is vague, incomplete, or worse, made up. The problem isn't the model — it's how you're asking. At Meteora Web, we work daily with AI APIs for real clients — support, automation, data analysis — and we've learned that the difference between a useful answer and a useless one lies in a handful of well-placed examples. No custom training, no fine-tuning. Just well-designed prompts. Welcome to the world of zero-shot, one-shot, and few-shot prompting.
Why the way you ask changes everything
Language models today (GPT-4, Claude, Gemini) are trained on billions of texts. They know a lot, but they don't know what you want from them at that precise moment. It's like having a brilliant but distracted consultant: if you don't give the right context, they'll answer with the first thing that comes to mind. Prompt engineering techniques guide their attention toward the output you need. And they rely on a simple principle: showing examples is more effective than explaining with words.
Zero-shot: no examples, only instructions.
One-shot: a single example in the prompt.
Few-shot: 2 to 5 examples.
The more examples you give, the better the model understands the pattern. But beware: every example costs tokens (and therefore money) and weighs down the request. Choosing the right number is a strategic skill.
Zero-shot: when it works and when it doesn't
Zero-shot is the base case: you write a request and the model answers without any example. It works well for simple, well-defined tasks: binary classification, known entity extraction, factual questions. For example:
Classify the following text as POSITIVE or NEGATIVE:
"The customer service was very slow, but I liked the final product."The model will likely answer "POSITIVE" or "NEGATIVE" with reasonable accuracy. But if the task requires a specific format (e.g., JSON, structured data), zero-shot often produces inconsistent outputs. We see this when a client asks us to extract data from invoices: without an example, the model tends to "imagine" non-existent fields.
Common mistake: thinking zero-shot always suffices. Instead, for complex outputs, just one example can save the day.
One-shot: the power of a single example
One example in the prompt changes the output quality radically. The model understands not only what you want, but how you want it. Let's try the same task with an example:
Extract the following information from the invoice text in JSON format:
Example:
Text: "Invoice no. 123 of 15/04/2025, total € 450,00 + VAT 22%"
Output: {"number": "123", "date": "2025-04-15", "total": 450.00, "vat": 22}
Now extract from:
Text: "Invoice no. 456 of 20/06/2025, total € 1,200.00 + VAT 10%"
Output:The result will be much more precise. At Meteora Web, we use this technique to auto-populate fields in our invoicing systems. A single, well-chosen, representative example is often enough for structured tasks. The rule of thumb: if the output structure is fixed, one-shot gives you 90% accuracy.
Few-shot: when complexity increases
With 2-5 examples you can teach the model more complex patterns: logical relationships, writing styles, conditional rules. Few-shot is ideal for:
- Linguistic transformations (summarization, tone, translation with specific register)
- Execution of rules (e.g., "if the name contains LTD, use legal denomination")
- Multi-step analysis (e.g., "first step: identify category; second step: assign a score")
Real example — classifying sentiment of mixed-tone reviews:
Classify sentiment as POSITIVE, NEGATIVE, or MIXED.
1. "Excellent product, but shipping took 3 weeks." -> MIXED
2. "Terrible product, never again." -> NEGATIVE
3. "Everything perfect, works great and fast delivery." -> POSITIVE
Now classify: "The price is good, but the quality is not up to par."With three examples, the model learns that "MIXED" exists and when to apply it. Without examples, it often chooses only positive/negative.
Advanced few-shot techniques
Choosing examples: representativeness vs variety
Not all examples are equal. Pick those that cover the most frequent cases plus a boundary case. Practical rule: 80% typical examples, 20% outliers. Avoid examples too similar — they don't teach anything new.
Order of examples: from simple to complex
The model tends to pay more attention to the last examples (primacy/recency bias). Place the most complex or critical examples toward the end. At Meteora Web, when building prompts for extracting data from heterogeneous invoices (different suppliers), we put the most atypical invoices as the last examples.
Prompt template: separate instructions, examples, and input
A clear format improves understanding. Use markers like --- or # to separate sections. Example template:
# INSTRUCTIONS
Extract the net total and VAT from the invoice text.
# EXAMPLES
1. Text: "Net 500€, VAT 22%" -> Net: 500, VAT: 22%
2. Text: "Total 1,000€ (including VAT 100€)" -> Net: 909.09, VAT: 100
# INPUT
Text: "Net base 2,000€ + VAT 22%"
# OUTPUTThis approach reduces parsing errors and makes the prompt maintainable. We use it in our accounting automation systems (yes, we come from accounting — we do this every day).
Avoid wasted context: token budget
Each model has a token limit (context). With few-shot, every example consumes precious tokens. For very long prompts, consider whether you really need 5 examples or if 2 suffice. We've seen cases where 3 well-crafted examples outperform 8 mediocre ones. Always measure your prompt length with tools like OpenAI Tokenizer before going to production.
Dynamic few-shot: pick examples on the fly
In real systems, examples can be selected automatically based on the input. For example, on an e-commerce platform we manage, we classify support requests by product category: if the request is about clothing, we use return/size examples; if it's about electronics, we use warranty/compatibility examples. This dynamic few-shot improves precision and saves tokens.
When to use zero-shot, one-shot, or few-shot? Practical criteria
- Zero-shot: simple tasks, binary classifications, direct questions, free-form output (e.g., brainstorming).
- One-shot: structured output (JSON, tables), specific formatting, predefined style. Always better than zero-shot if possible.
- Few-shot: complex tasks with implicit rules, multi-class classifications with nuances, transformations with exceptions, scenarios where the model tends to confuse.
At Meteora Web, we almost always start from one-shot and add examples only if testing on a sample shows systematic errors. Remember: each example costs, but an error costs more.
In summary — what to do now
- Identify your task: is it simple or complex? Do you have a fixed output structure? If yes, use one-shot.
- Prepare 2-3 representative examples for each use case. Keep them in a ready-to-use template file.
- Test in zero-shot mode on 10 sample inputs. Count errors. If more than 20%, switch to one-shot.
- Iterate: add one example at a time until accuracy satisfies you (but never exceed 5 examples — usually 3 are enough).
- Implement dynamic few-shot if you have many heterogeneous inputs: group examples by category and pick them automatically.
- Monitor tokens: use the model's tokenizer to avoid context overflow.
Zero-shot, one-shot, few-shot are not mysterious techniques — they are the difference between a model that fails and one that delivers. And in a business, every wrong answer is a cost. We work on this every day. Now it's your turn: take a prompt you currently use, add one example, and see the difference. For further reading, check our guide on ChatGPT for business or compare models with Claude vs others.
Sponsored Protocol
