Understanding Shot-Based Prompting
The term "shot" in prompt engineering refers to the number of examples provided in your prompt. This concept comes from machine learning, where models learn from training examples.
🎯 Types of Shot Prompting
- Zero-Shot: No examples provided, model relies on its training knowledge
- One-Shot: Single example provided to demonstrate the pattern
- Few-Shot: Multiple examples (typically 2-5) to establish the pattern
Zero-Shot Prompting
Zero-shot prompting asks the model to perform a task without any examples. The model uses only its pre-trained knowledge and your instructions.
// Zero-Shot Example 1: Classification
"Classify the following text as positive, negative, or neutral:
Text: 'The new update completely broke my workflow. Very frustrated.'
Sentiment:"
// Output: negative
// Zero-Shot Example 2: Translation
"Translate the following English text to Spanish:
'The quick brown fox jumps over the lazy dog.'
Translation:"
// Output: El rápido zorro marrón salta sobre el perro perezoso.
// Zero-Shot Example 3: Code Generation
"Write a JavaScript function that checks if a string is a palindrome."
// Output: Working function (model knows the task from training)
// When Zero-Shot Works Well:
// - Common, well-defined tasks
// - Tasks the model was trained on
// - When format is flexible
// - Simple transformations
One-Shot Prompting
One-shot prompting provides a single example to demonstrate the desired pattern or format.
// One-Shot Example: Custom Format
"Convert product descriptions to marketing copy.
Example:
Input: Wireless headphones with 40-hour battery life
Output: 🎧 Experience freedom! Our wireless headphones deliver
an incredible 40 hours of non-stop music. No more charging anxiety!
Now convert:
Input: Laptop stand with adjustable height and cooling fans
Output:"
// One-Shot Example: Code Style
"Refactor functions to use early returns.
Example:
Before:
function isValid(user) {
if (user) {
if (user.active) {
if (user.verified) {
return true;
}
}
}
return false;
}
After:
function isValid(user) {
if (!user) return false;
if (!user.active) return false;
if (!user.verified) return false;
return true;
}
Now refactor:
function processOrder(order) {
if (order) {
if (order.items.length > 0) {
if (order.paymentComplete) {
return { success: true };
}
}
}
return { success: false };
}"
Few-Shot Prompting
Few-shot prompting provides multiple examples to clearly establish the desired pattern. This is especially useful for complex or custom tasks.
// Few-Shot Example: Consistent JSON Extraction
"Extract structured data from text descriptions.
Example 1:
Text: John Smith is a 32-year-old software engineer from Boston.
JSON: { "name": "John Smith", "age": 32, "job": "software engineer", "city": "Boston" }
Example 2:
Text: Maria Garcia, 28, works as a data scientist in San Francisco.
JSON: { "name": "Maria Garcia", "age": 28, "job": "data scientist", "city": "San Francisco" }
Example 3:
Text: The 45-year-old CEO, Robert Chen, is based out of Seattle.
JSON: { "name": "Robert Chen", "age": 45, "job": "CEO", "city": "Seattle" }
Now extract:
Text: Lisa Wong is a 36-year-old product manager working in Austin.
JSON:"
// Few-Shot Example: Custom Code Transformation
"Convert Express routes to OpenAPI YAML specs.
Example 1:
Express: app.get('/users', getAllUsers)
OpenAPI:
/users:
get:
summary: Get all users
responses:
200:
description: Success
Example 2:
Express: app.post('/users', createUser)
OpenAPI:
/users:
post:
summary: Create a user
requestBody:
required: true
responses:
201:
description: Created
Now convert:
Express: app.delete('/users/:id', deleteUser)
OpenAPI:"
Choosing the Right Approach
| Approach | Best For | Considerations |
|---|---|---|
| Zero-Shot | Standard tasks, flexible format, simple requests | Fastest, uses least tokens, may be inconsistent |
| One-Shot | Custom formats, style guidance, simple patterns | Good balance, may not capture all edge cases |
| Few-Shot | Complex patterns, consistent output, edge cases | Most consistent, uses more tokens, needs good examples |
Few-Shot Best Practices
// 1. Diverse Examples - Cover different cases
"Classify customer feedback:
Example 1 (product issue):
Text: The app crashes when I try to upload photos
Category: Bug Report
Example 2 (feature request):
Text: It would be great if you could add dark mode
Category: Feature Request
Example 3 (praise):
Text: Love the new update! Everything runs so smoothly
Category: Positive Feedback
Example 4 (confusion):
Text: How do I change my password? Can't find the option
Category: Support Question
Now classify:
Text: The checkout button doesn't work on mobile
Category:"
// 2. Consistent Format - All examples follow same structure
// ✅ Good: All examples have same keys
{ "name": "...", "role": "...", "level": "..." }
{ "name": "...", "role": "...", "level": "..." }
// ❌ Bad: Inconsistent structure
{ "name": "...", "job": "..." }
{ "fullName": "...", "role": "...", "experience": "..." }
// 3. Representative Examples - Include edge cases
"Parse dates from various formats:
Input: 2024-01-15 → Output: { year: 2024, month: 1, day: 15 }
Input: January 15, 2024 → Output: { year: 2024, month: 1, day: 15 }
Input: 15/01/2024 → Output: { year: 2024, month: 1, day: 15 }
Input: Jan 15 '24 → Output: { year: 2024, month: 1, day: 15 }
Now parse:
Input: 03-22-2024"
Few-Shot for Code Tasks
// Generate TypeScript interfaces from examples
"Generate TypeScript interfaces from sample JSON data.
Example 1:
JSON: { "id": 1, "name": "Item", "price": 29.99 }
Interface:
interface Product {
id: number;
name: string;
price: number;
}
Example 2:
JSON: { "userId": "abc", "email": "user@test.com", "active": true }
Interface:
interface User {
userId: string;
email: string;
active: boolean;
}
Example 3:
JSON: { "posts": [{ "id": 1, "title": "Hello" }], "total": 100 }
Interface:
interface Post {
id: number;
title: string;
}
interface PostsResponse {
posts: Post[];
total: number;
}
Now generate:
JSON: { "orderId": "ord_123", "items": [{ "sku": "A1", "qty": 2 }], "shipped": false }
Interface:"
⚠️ Common Mistakes
- • Using too many examples (3-5 is usually optimal)
- • Providing incorrect or inconsistent examples
- • Examples that are too similar (lacking diversity)
- • Overly complex examples that confuse the model
- • Not matching example format to your actual use case